Problèmes de délivrabilité des e-mails après la migration de domaine

Qu'est-ce qui change lorsque vous migrez un domaine

Une migration de domaine semble simple sur le papier : diriger le trafic vers un nouveau domaine, copier le contenu et passer à autre chose. Les e-mails ne se déplacent pas aussi poliment. Le domaine d'envoi, les enregistrements DNS, la chaîne d'authentification et la confiance que vous avez construite avec les fournisseurs de boîtes aux lettres changent tous en même temps, et même un enregistrement manquant peut créer des problèmes de délivrabilité des e-mails après la migration du domaine.

Il y a 4 choses qui changent généralement en premier : la réputation de l'expéditeur, SPF, DKIM et DMARC. Le destinataire ne voit pas ces détails, mais Gmail, Outlook et Yahoo le font, et ils comparent les anciens signaux avec les nouveaux avant de décider si votre message atterrit dans la boîte de réception, l'onglet promotions ou nulle part utile. Un changement de nom sans plan est un pari.

La confiance est plus lente que le DNS. Si un nouveau domaine commence à envoyer 5 000 messages le jour 1, les fournisseurs de boîtes aux lettres peuvent le traiter comme un nouvel expéditeur sans historique. Une marque peut conserver son logo, son ton et la qualité de sa liste, mais perdre quand même son placement dans la boîte de réception parce que le domaine a changé et que le modèle d'envoi a changé avec lui.

Une complication pratique est que les anciens et nouveaux domaines peuvent coexister pendant des semaines. Ce chevauchement aide les utilisateurs, mais crée également de la confusion dans les en-têtes de message, le suivi des liens et la gestion des réponses. Une équipe de support peut penser que la migration est terminée, tandis que les serveurs de messagerie racontent encore une histoire différente.

Problèmes courants de délivrabilité des e-mails après migration

Le premier symptôme est souvent discret : les messages atterrissent dans le spam pour un seul fournisseur, puis se propagent à 2 ou 3 autres. Ce schéma indique généralement des problèmes de réputation ou d'authentification plutôt qu'un problème de contenu. De petites erreurs deviennent rapidement visibles.

Un autre problème courant est les reports. Les fournisseurs de boîtes aux lettres peuvent temporairement rejeter des messages et demander à l'expéditeur d'essayer à nouveau plus tard. Si le système d'envoi essaie de renvoyer trop agressivement, le retard peut se transformer en un ralentissement plus large, et une campagne qui aurait dû prendre 10 minutes s'éternise maintenant pendant des heures.

Certaines équipes constatent des pics de rebond après la migration. Un pic peut signifier que le nouveau domaine manque d'enregistrements DNS, que le flux de mails est mal acheminé, ou que les destinataires ne sont plus disposés à accepter des mails d'un expéditeur qu'ils ne reconnaissent pas. Le texte de rebond est important ici, car « temporaire » et « permanent » sont des échecs très différents.

L'envoi bloqué est la version sévère. Le fournisseur refuse simplement le mail. Cela peut se produire après un changement brusque de volume, un échec de vérification d'authentification, ou un mauvais signal de réputation lié au nouveau domaine. Une campagne bloquée peut également affecter les 3 campagnes suivantes si personne ne s'arrête pour inspecter le code de raison.

Comment la migration de domaine impacte SPF, DKIM et DMARC

SPF, DKIM et DMARC sont les trois enregistrements qui se cassent le plus souvent lors de la migration. SPF peut échouer si le nouveau service d'envoi n'est pas répertorié. DKIM peut échouer si le sélecteur change ou si la clé n'a jamais été copiée. DMARC peut échouer si l'alignement entre le domaine visible de l'expéditeur et le domaine authentifié ne correspond plus.

Ce problème d'alignement est facile à manquer. Un message peut passer DKIM sur un domaine et échouer DMARC parce que l'adresse From montre un autre domaine, et les fournisseurs de boîtes aux lettres se soucient des deux. Si l'identité de l'expéditeur et l'identité d'authentification se séparent, le placement dans la boîte de réception souffre généralement.

Certaines migrations conservent l'ancienne plateforme de messagerie mais déplacent uniquement le site web. Même dans ce cas, l'authentification peut échouer. Un changement d'hébergement DNS, un nouveau sous-domaine ou une nouvelle IP sortante peuvent modifier tout le chemin. Si vous souhaitez que le côté technique soit bien cartographié, l'article sur Configuration DKIM SPF DMARC pour les transactions est un bon complément.

Un autre problème : les clés DKIM sont parfois régénérées lors d'un déménagement de plateforme, mais la nouvelle clé n'est pas publiée dans le DNS avant le lancement. Cela laisse des e-mails signés avec une clé que aucun destinataire ne peut vérifier. L'e-mail peut toujours quitter le serveur, mais l'absence de preuve le rend beaucoup moins fiable.

Vérifications DNS, MX et de routage des e-mails

Le DNS est le panneau de contrôle, et les enregistrements MX décident où les e-mails entrants doivent aller. Après une migration, examinez à la fois les chemins d'envoi et de réception. Un domaine peut être actif pour le trafic web tandis que son chemin de messagerie est toujours dirigé vers le mauvais hôte, ce qui entraîne des réponses perdues, des vérifications échouées et des tickets de support confus.

Vérifiez d'abord l'enregistrement MX. Ensuite, confirmez les enregistrements A ou CNAME qui soutiennent l'hôte de messagerie, et assurez-vous que tous les sous-domaines utilisés pour l'envoi, le suivi ou les réponses se résolvent toujours. Un enregistrement qui semble inoffensif à 9 heures du matin peut casser une réinitialisation de mot de passe à midi.

La gestion des réponses mérite un passage à part. Si l'adresse visible de l'expéditeur est sur le nouveau domaine mais que la boîte aux lettres de réponse est toujours sur l'ancienne, les utilisateurs peuvent se retrouver dans des impasses. Cela ne nuit pas toujours directement à la délivrabilité, mais cela nuit à la confiance, et la confiance affecte l'engagement futur.

Pour les équipes qui envoient à la fois des e-mails marketing et transactionnels, le routage doit être testé sous les deux angles. Un enregistrement MX mal placé peut ne pas arrêter une newsletter, mais il peut bloquer les messages de vérification de compte ou les confirmations de commande. Si la pile de messagerie est mélangée, comparez-la avec ce que signifie le relais SMTP pour node.js avant de supposer que le chemin d'envoi est propre.

Considérations sur la réputation de l'expéditeur et le réchauffement

Une migration de domaine peut réinitialiser ou affaiblir les signaux de réputation même lorsque la liste reste la même. Les fournisseurs de boîtes aux lettres lisent des modèles, pas des promesses. Si un expéditeur passe de 200 messages par jour à 20 000 sur le nouveau domaine, ce saut semble risqué, surtout si l'engagement est encore inconnu.

Le réchauffement aide car il répartit le risque sur 7, 14 ou 30 jours au lieu de forcer le nouveau domaine à prouver sa valeur d'un seul coup. Commencez par les destinataires les plus engagés, puis passez aux segments plus anciens seulement après que le placement reste stable. Ce n'est pas glamour, mais cela fonctionne plus souvent qu'un grand lancement.

Le volume n'est qu'une partie de la réputation. Le taux de plainte, le taux de rebond et l'engagement positif alimentent tous l'image. Un expéditeur avec de bons taux d'ouverture sur l'ancien domaine peut encore trébucher après la migration si le nouveau domaine commence avec une histoire froide et une nouvelle IP en même temps.

Parfois, la solution est comportementale plutôt que technique. Ralentissez. Envoyez les 3 prochaines campagnes uniquement aux utilisateurs engagés. Surveillez le taux de réponse et le placement dans la boîte de réception avant d'ajouter des contacts moins actifs. Une migration de domaine récompense la patience bien plus que l'enthousiasme.

Étapes de diagnostic pour le dépannage de la délivrabilité

Commencez par le message de rebond. Lisez le code SMTP, le texte lisible par l'homme et toute note spécifique au fournisseur. Un code 4xx signifie un problème temporaire ; un code 5xx signifie un refus définitif. Cette différence détermine si vous réessayez, enquêtez ou arrêtez d'envoyer à cette adresse.

Ensuite, inspectez les en-têtes de message. Les en-têtes montrent le chemin que le mail a pris, les résultats d'authentification et parfois le point exact où le message a perdu sa confiance. Si les en-têtes sont manquants ou incomplets, vous dépannez à l'aveugle. C'est une mauvaise situation à avoir lors de toute migration de domaine.

Les listes noires comptent aussi, bien qu'elles ne soient pas la seule histoire. Si une IP ou un domaine d'envoi apparaît sur une liste majeure, vous devez savoir pourquoi et si l'inscription est actuelle. Une liste peut bloquer une campagne, mais une liste propre ne garantit pas le placement dans la boîte de réception.

Les outils de test font gagner du temps ici. Effectuez des vérifications avant et après chaque changement, et comparez les résultats plutôt que de fixer un seul feu vert. Le guide sur les outils de test de délivrabilité des e-mails · YourTrend peut vous aider à encadrer ces vérifications, surtout lorsque le problème n'est pas évident à partir de la boîte de réception seule.

Surveillez la chronologie. Si les plaintes commencent 2 heures après la migration, cela indique un problème d'authentification ou de routage. Si la chute commence après la troisième campagne, la réputation et le volume sont plus susceptibles d'être en cause. Les modèles surpassent les suppositions.

Corriger la délivrabilité après une migration de domaine

Tout d'abord, corrigez les enregistrements. Publiez les valeurs SPF include correctes, rafraîchissez les clés DKIM si nécessaire, et confirmez l'alignement DMARC. Ensuite, vérifiez que la plateforme d'envoi utilise bien les enregistrements mis à jour et non les paramètres mis en cache de l'ancien domaine. Un changement DNS qui n'atteint jamais le serveur de messagerie ne change rien.

Ensuite, corrigez l'infrastructure d'envoi. Mettez à jour le domaine MAIL FROM, le domaine de réponse, les liens de suivi et tous les sous-domaines utilisés pour l'authentification ou le traitement des rebonds. Si la gestion des rebonds est toujours liée à l'ancien domaine, les plaintes et les rebonds peuvent être collectés au mauvais endroit. Cela crée une fuite lente.

La communication avec les destinataires peut également aider, surtout pour les e-mails transactionnels. Si les avis de compte ou les alertes de facturation sont susceptibles d'atteindre un public prudent, informez les utilisateurs clés que le domaine a changé et que les messages arriveront désormais d'une adresse différente. Pour les équipes qui ont besoin d'une vue opérationnelle plus approfondie, les événements webhook d'e-mail pour les e-mails transactionnels peuvent aider à suivre les événements de livraison après la correction.

Les règles de suppression doivent être examinées avant de renvoyer quoi que ce soit. Les anciennes plaintes, désabonnements et rebonds durs doivent rester supprimés sur le nouveau domaine. Si vous avez besoin d'une politique plus stricte, l'article sur la gestion des listes de suppression d'e-mails · YourTrend vaut le coup d'œil avant que la prochaine campagne ne soit lancée.

Ne précipitez pas le renvoi. Si 2 grands fournisseurs de boîtes aux lettres ont montré des problèmes, corrigez d'abord la cause profonde, puis retestez avec un petit lot. Un deuxième échec peut être plus difficile à récupérer que le premier.

Meilleures pratiques pour prévenir les problèmes de délivrabilité futurs

Planifiez la migration avec l'e-mail dès le premier jour. Les équipes de site Web traitent souvent les déplacements de domaine comme un projet de contenu ou d'hébergement, mais l'e-mail a ses propres dépendances. Incluez le fournisseur de messagerie, le propriétaire DNS, l'équipe de support et quiconque contrôle l'authentification. Quatre personnes dans une réunion peuvent faire gagner 4 jours plus tard.

Créez une liste de contrôle de pré-lancement. Confirmez SPF, DKIM, DMARC, MX, routage des réponses, gestion des rebonds et domaines de suivi avant le changement. Ensuite, testez auprès d'au moins 2 grands fournisseurs, car un test de boîte de réception n'est pas suffisant. Si vous avez besoin d'un cadre plus large, les meilleures pratiques de délivrabilité des e-mails fournissent une base plus large pour le quotidien de l'envoi.

Le réchauffement doit être intégré dans le plan de migration, et non ajouté après la première plainte. Utilisez un calendrier échelonné avec 3 groupes de destinataires : utilisateurs très engagés, utilisateurs actifs récents et tous les autres. Cette séquence réduit la chance que le nouveau domaine commence sa vie avec des dommages évitables.

La surveillance doit rester active pendant au moins 30 jours après le lancement. Suivez les taux de rebond, les plaintes pour spam, les vérifications de placement dans la boîte de réception et les échecs d'authentification. Si un enregistrement échoue le jour 12, l'équipe doit le voir avant les utilisateurs. Il en va de même pour la gestion des désabonnements ; si le nouveau domaine change le chemin du lien ou la logique du pied de page, examinez pourquoi les meilleures pratiques de désabonnement par e-mail sont importantes avant le prochain envoi.

Une dernière habitude aide plus que les gens ne s'y attendent : tenir un journal de migration. Notez l'ancien enregistrement, le nouvel enregistrement, la date, le propriétaire et la raison de chaque changement. Lorsque des problèmes de délivrabilité des e-mails après la migration de domaine apparaissent 3 semaines plus tard, ce journal peut faire gagner des heures de conjectures.