E-mail : enregistrements DNS mixtes — la faute de frappe qui tue la délivrabilité (et la correction)

Ce que “enregistrements DNS mixtes” signifie vraiment (et pourquoi l’e-mail en souffre d’abord)

“Enregistrements DNS mixtes” n’est pas un terme RFC formel. C’est la façon SRE de dire : les données DNS publiées pour votre domaine sont incohérentes en interne, partiellement migrées ou visibles de façon variable selon les résolveurs. Parfois c’est parce que vous êtes en plein basculement. Parfois parce que quelqu’un a collé les guides de configuration de deux fournisseurs dans la même zone. Parfois parce que votre DNS interne a des redirections “utiles” qui font réussir les tests depuis le bureau et échouer partout ailleurs.

L’e-mail est là où ça casse en premier parce que le routage et la confiance des e-mails sont une pile de résolutions DNS—pas une seule. Le trafic web se soucie généralement des A/AAAA et peut-être des CAA. Le courrier se soucie des MX, puis des A/AAAA des cibles MX, plus des enregistrements TXT SPF, plus des enregistrements TXT DKIM, plus des enregistrements TXT DMARC, plus du reverse DNS pour l’IP qui se connecte, et de plus en plus de MTA-STS ou de rapports TLS. Mélangez l’un de ces éléments et le système “fonctionne en quelque sorte” jusqu’à ce que vous rencontriez le fournisseur exigeant qui applique la partie que vous avez foirée.

Les trois schémas les plus fréquents d’“enregistrements mixtes”

• Routage divisé : plusieurs hôtes MX de fournisseurs différents présents à la fois (ou ancien MX plus nouveau MX), donc le courrier entrant va parfois au mauvais endroit.
• Autorisation divisée : SPF dit que le fournisseur A est autorisé, mais vous envoyez en réalité depuis le fournisseur B (ou votre propre MTA). Ou SPF est syntaxiquement valide mais logiquement cassé (trop de résolutions DNS, mauvais qualificatifs).
• Identité divisée : clés DKIM pour une plate-forme, DMARC exigeant un alignement que votre champ From/Return-Path réel ne satisfait pas. Tout “part” mais la délivrabilité s’effondre.

Un autre schéma mérite une mention spéciale : le split horizon DNS—où les résolveurs internes renvoient des réponses différentes du DNS public. C’est excellent pour des services internes. C’est un incendie pour l’e-mail à moins d’être discipliné, car les flux de mail traversent les frontières par définition.

Blague #1 : La propagation DNS est le seul endroit où “consistance éventuelle” signifie “finalement votre alarme sonnera”.

Méthode de diagnostic rapide (vérifier d’abord / ensuite / enfin)

Voici le flux à haute valeur quand la délivrabilité échoue et que vous devez trouver le goulot rapidement. N’ouvrez pas les tableaux de bord des fournisseurs en premier. Commencez par la vérité publique.

Première étape : le routage entrant est-il déterministe ?

1. Vérifiez les enregistrements MX depuis plusieurs résolveurs (votre résolveur, un résolveur public, et les serveurs de noms autoritatifs).
2. Résolvez les A/AAAA pour chaque cible MX—assurez-vous qu’ils existent, ne pointent pas vers des IP décommissionnées, et ne forment pas des chaînes de CNAME vers nulle part.
3. Recherchez des “fournisseurs mêlés” : anciens cibles MX toujours présentes, mauvaises priorités, ou un MX à l’apex pointant vers un nom d’hôte qui n’existe plus.

Deuxième étape : échouez-vous sur l’authentification d’une manière qui entraîne des refus ?

1. Validez la syntaxe SPF et le nombre de résolutions DNS. Si vous voyez permerror, considérez-le comme cassé.
2. Confirmez que les sélecteurs DKIM sont publiés et correspondent à ce que votre expéditeur utilise.
3. Vérifiez que DMARC existe, a une politique sensée, et ne pointe pas vers des adresses de rapport absurdes.

Troisième étape : l’IP qui se connecte a-t-elle l’air légitime ?

1. Vérifiez le PTR (reverse DNS) pour vos IP sortantes.
2. Vérifiez le reverse confirmé par une résolution directe (FCrDNS) : le nom PTR résout de nouveau vers la même IP.
3. Vérifiez si votre IP sortante provient inopinément d’un nouveau pool (un changement réseau “utile”, NAT, ou un nouveau relais SaaS).

Règle de décision

Si l’entrée est mal routée : corrigez les MX en premier. Si l’entrée est correcte mais que vos e-mails atterrissent en spam ou sont rejetés par de grands fournisseurs : corrigez l’alignement SPF/DKIM/DMARC et l’identité IP (PTR/HELO). Ne peaufinez pas DMARC pendant que les MX envoient encore la moitié des mails clients vers une boîte abandonnée chez votre précédent fournisseur.

Faits et contexte historique à connaître

• Les enregistrements MX ont remplacé le “routage par A record” tôt dans l’histoire du DNS, parce que “se connecter juste au domaine” ne permettait pas d’avoir plusieurs hôtes mail et des scénarios de basculement.
• Les enregistrements TXT sont devenus le tiroir à tout du DNS en partie parce qu’ils étaient largement supportés et flexibles ; SPF avait initialement son propre type RR mais TXT l’a emporté en pratique.
• La limite de 10 résolutions DNS de SPF existe parce que les récepteurs doivent l’évaluer pendant le temps SMTP, et une récursion sans bornes serait un cadeau DoS.
• DKIM a été conçu pour survivre au transfert mieux que SPF, car il signe le contenu du message plutôt que l’IP de connexion—mais il peut quand même casser sur des modifications comme des pieds de page ou certains logiciels de listes de diffusion.
• DMARC a introduit l’alignement : il ne suffit pas de “passer SPF”. SPF doit passer pour un domaine aligné avec le From visible, ou DKIM doit passer et être aligné.
• Les valeurs TTL DNS sont indicatives ; les résolveurs peuvent plafonner, étendre ou se comporter de façon étrange sous charge. Un TTL bas n’est pas un bouton universel “propager plus vite”.
• Certaines destinations mettent en cache les réponses négatives (NXDOMAIN) selon les règles SOA / TTL négatif, ce qui signifie qu’un DKIM brièvement manquant peut vous poursuivre pendant des heures.
• Le renforcement des règles chez les fournisseurs après des usurpations à grande échelle ; beaucoup de grandes boîtes traitent maintenant une authentification faible comme une pénalité de délivrabilité, pas seulement comme un “bien de confort”.

Comment l’e-mail utilise réellement le DNS : MX, SPF, DKIM, DMARC, PTR, TLSA et compagnons

MX : où va le courrier entrant (et comment les enregistrements mixtes répartissent votre boîte)

Les enregistrements MX sont les directeurs de trafic pour le courrier entrant. Chaque MX pointe vers un nom d’hôte, plus une valeur de préférence (priorité). Le plus petit nombre l’emporte. Si plusieurs MX partagent la même préférence, l’expéditeur va typiquement randomiser entre eux.

Où ça coince :

• Vous laissez d’anciens enregistrements MX en place “pour la sécurité”, créant une répartition aléatoire du courrier entre deux fournisseurs.
• Vous pointez un enregistrement MX vers un CNAME qui fonctionne chez certains résolveurs mais échoue chez d’autres (les cibles MX devraient être des noms d’hôte avec A/AAAA ; CNAME sur une cible MX est largement déconseillé et peut être rejeté par des expéditeurs stricts).
• Vous ajoutez un AAAA IPv6 pour un hôte MX qui n’accepte pas réellement le mail sur IPv6, provoquant des délais d’attente pour les expéditeurs qui préfèrent IPv6.

SPF : qui est autorisé à envoyer (et pourquoi “ça passe” n’est pas synonyme de “ça marche”)

SPF est un enregistrement TXT (souvent à la racine du domaine) qui indique au récepteur quelles IP/hosts sont autorisés à envoyer pour ce domaine. Il est évalué par rapport à l’expéditeur de l’enveloppe SMTP (Return-Path / MAIL FROM) ou, si celui-ci est vide, à l’identité HELO/EHLO.

Modes d’échec SPF qui ressemblent à du “DNS mixte” :

• Plusieurs enregistrements TXT SPF au même nom (deux chaînes v=spf1). Beaucoup de récepteurs traitent cela comme une erreur permanente.
• Migrations qui se chevauchent : include:_spf.oldvendor.example et include:_spf.newvendor.example présents tous les deux, vous faisant dépasser la limite de résolutions DNS.
• Bidouilles de test : quelqu’un ajoute +all ou ~all “temporairement”, et cela devient permanent, sapant l’application et la délivrabilité.

DKIM : signatures cryptographiques (et la faute de sélecteur qui ruine la semaine)

DKIM publie une clé publique dans le DNS à selector._domainkey.example.com. Votre système sortant signe les messages avec la clé privée et inclut le sélecteur dans l’en-tête DKIM-Signature. Les récepteurs récupèrent la clé publique et vérifient la signature.

Schémas d’enregistrements mixtes :

• Vous faites tourner les sélecteurs mais ne publiez pas le nouveau sélecteur partout (DNS multi-fournisseurs, ou seulement le DNS interne mis à jour).
• Vous publiez le sélecteur au mauvais sous-domaine (fréquent quand on envoie en tant que mail.example.com vs example.com).
• Vous cassez le format du TXT (guillemets, sauts de ligne) de sorte que certains outils DNS l’affichent mais certains récepteurs échouent à le parser.

DMARC : politique, alignement, rapports (et comment “none” peut quand même aider)

DMARC est publié à _dmarc.example.com et indique aux récepteurs quoi faire quand SPF/DKIM ne s’alignent pas avec le domaine visible From. Il fournit aussi des adresses de rapport pour recevoir des feedbacks agrégés et judiciaires (lorsque supporté).

Schémas d’enregistrements mixtes :

• DMARC existe sur example.com mais vous envoyez réellement depuis sub.example.com sans DMARC propre, ou vous comptez sur le comportement du domaine organisationnel sans le comprendre.
• La politique DMARC est réglée sur p=reject avant que DKIM ne signe de façon cohérente depuis toutes les sources sortantes.
• Plusieurs enregistrements DMARC existent (ça arrive), et les récepteurs le traitent comme invalide.

PTR et FCrDNS : le contrôle “ressemblez-vous à un vrai serveur mail”

Le reverse DNS (PTR) mappe une IP vers un nom d’hôte. Beaucoup de récepteurs accordent un poids important à la correction du PTR, surtout pour les MTAs auto-hébergés. Même pour les relais SaaS, un changement soudain de l’identité de l’IP sortante peut ruiner la délivrabilité. FCrDNS ajoute un second contrôle : le nom PTR doit résoudre de nouveau vers la même IP.

MTA-STS et TLSA : pas requis partout, mais de plus en plus pertinents

MTA-STS utilise un enregistrement TXT DNS (_mta-sts.example.com) et un hôte de politique HTTPS (mta-sts.example.com) pour signaler que le SMTP entrant doit utiliser TLS et pour épingler les hôtes MX attendus. TLSA (DANE) utilise DNSSEC pour publier des contraintes de certificat TLS. Ce ne sont pas des exigences “du jour un” pour beaucoup d’organisations, mais si vous les déployez, elles ajoutent d’autres manières dont le DNS mixte peut casser le courrier.

Blague #2 : La bonne nouvelle avec l’e-mail, c’est que c’est un protocole mature. La mauvaise nouvelle, c’est que c’est un protocole mature.

Un rappel de fiabilité, paraphrasant une voix notable de l’opérationnel : idée paraphrasée : optimiser pour une récupération et un apprentissage rapides, car les pannes sont inévitables dans des systèmes complexes — John Allspaw.

Tâches pratiques : commandes, sorties et la décision à prendre

Ces tâches sont destinées à être exécutées depuis n’importe quelle machine Linux avec des outils DNS courants installés. Exécutez-les depuis au moins deux réseaux si possible (LAN d’entreprise + VM cloud), parce que “ça marche d’ici” est le piège.

Tâche 1 : interroger les MX depuis votre résolveur par défaut

cr0x@server:~$ dig +nocmd example.com MX +noall +answer
example.com.     300 IN MX 10 mx1.newmail.example.
example.com.     300 IN MX 20 mx2.newmail.example.

Ce que ça signifie : Le DNS public (vu par votre résolveur) dit que le courrier va vers deux hôtes, préférence 10 puis 20.

Décision : Si vous attendiez un fournisseur unique et voyez deux ensembles non reliés (ancien et nouveau), arrêtez et nettoyez. Les MX mixtes ne sont pas une “redondance supplémentaire” à moins que vous ne contrôliez les deux systèmes et sachiez exactement comment ils interagissent.

Tâche 2 : interroger les MX depuis un résolveur public spécifique

cr0x@server:~$ dig @1.1.1.1 example.com MX +noall +answer
example.com.     300 IN MX 10 mx1.oldmail.example.
example.com.     300 IN MX 20 mx2.oldmail.example.

Ce que ça signifie : Résolveur différent, vérité différente. Vous êtes en propagation ou vous avez des réponses autoritatives incohérentes (ou un problème DNSSEC provoquant un comportement de repli).

Décision : Avant de changer davantage, interrogez les serveurs de noms autoritatifs. S’ils sont cohérents, vous attendez ; s’ils sont incohérents, corrigez le chemin de publication de la zone.

Tâche 3 : interroger directement les serveurs de noms autoritatifs

cr0x@server:~$ dig +short NS example.com
ns1.dns-host.example.
ns2.dns-host.example.

cr0x@server:~$ dig @ns1.dns-host.example example.com MX +noall +answer
example.com.     300 IN MX 10 mx1.newmail.example.
example.com.     300 IN MX 20 mx2.newmail.example.

cr0x@server:~$ dig @ns2.dns-host.example example.com MX +noall +answer
example.com.     300 IN MX 10 mx1.newmail.example.
example.com.     300 IN MX 20 mx2.newmail.example.

Ce que ça signifie : Les serveurs autoritatifs sont d’accord sur le nouveau MX.

Décision : Si les résolveurs publics sont en désaccord, vous attendez l’expiration des caches. Communiquez-le clairement : “Certains expéditeurs atteindront encore l’ancien MX jusqu’à l’expiration du TTL.” Si les serveurs autoritatifs sont en désaccord, vous avez un problème de publication/synchronisation de zone et la propagation ne vous sauvera pas.

Tâche 4 : confirmer que les cibles MX résolvent en A/AAAA

cr0x@server:~$ dig mx1.newmail.example A +noall +answer
mx1.newmail.example. 300 IN A 203.0.113.10

cr0x@server:~$ dig mx1.newmail.example AAAA +noall +answer

Ce que ça signifie : IPv4 existe, IPv6 n’existe pas (réponse AAAA vide).

Décision : C’est acceptable si vous ne servez pas IPv6. Ce que vous ne voulez pas, c’est un AAAA cassé qui pointe vers une IP où le port 25 est fermé, car certains expéditeurs préféreront IPv6 et subiront des délais d’attente.

Tâche 5 : détecter l’étrangeté “CNAME sur cible MX”

cr0x@server:~$ dig mx1.newmail.example CNAME +noall +answer
mx1.newmail.example. 300 IN CNAME vendor-lb.mailhost.example.

Ce que ça signifie : La cible MX est un CNAME.

Décision : Si vous la contrôlez et qu’elle est connue et fiable avec vos récepteurs, vous pouvez survivre. Si vous dépannez la délivrabilité, éliminez cette variable : utilisez les noms MX recommandés par le fournisseur qui résolvent directement en A/AAAA.

Tâche 6 : vérifier la présence et le nombre d’enregistrements SPF

cr0x@server:~$ dig example.com TXT +noall +answer
example.com. 300 IN TXT "v=spf1 include:_spf.newvendor.example -all"
example.com. 300 IN TXT "v=spf1 include:_spf.oldvendor.example -all"

Ce que ça signifie : Deux enregistrements SPF. Ce n’est pas “deux sources de vérité”, c’est la roulette du permerror.

Décision : Fusionnez en un seul enregistrement v=spf1. Si vous avez vraiment besoin des deux fournisseurs pendant la migration, combinez les includes dans une seule chaîne et restez sous la limite de résolutions.

Tâche 7 : évaluer SPF contre une IP d’envoi connue

cr0x@server:~$ spfquery -ip 203.0.113.55 -sender bounce@example.com -helo mail.example.com
result=permerror
smtp.comment=Two or more type TXT records found

Ce que ça signifie : L’évaluation SPF échoue de façon permanente à cause de plusieurs enregistrements.

Décision : Corrigez SPF maintenant. Beaucoup de récepteurs traitent le permerror comme un échec ou comme un signal fortement négatif.

Tâche 8 : vérifier l’explosion des résolutions DNS SPF

cr0x@server:~$ spfquery -ip 203.0.113.55 -sender bounce@example.com -helo mail.example.com
result=permerror
smtp.comment=SPF Permanent Error: too many DNS lookups

Ce que ça signifie : Vos includes/redirects dépassent la limite SPF.

Décision : Aplatissez SPF (avec prudence), supprimez les includes inutilisés, ou consolidez les expéditeurs derrière un relais unique avec un footprint SPF stable.

Tâche 9 : récupérer la clé publique DKIM pour un sélecteur supposé en usage

cr0x@server:~$ dig s1._domainkey.example.com TXT +noall +answer
s1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Ce que ça signifie : Le sélecteur existe et retourne une clé publique.

Décision : Si les messages échouent DKIM, le problème vient probablement de la configuration de signature (mauvais sélecteur, mauvais domaine, canonicalization body/header) ou d’une modification intermédiaire des messages.

Tâche 10 : attraper la faute de sélecteur DKIM / enregistrement manquant

cr0x@server:~$ dig s2._domainkey.example.com TXT +noall +answer

Ce que ça signifie : Aucun enregistrement TXT pour le sélecteur s2.

Décision : Publiez s2 ou reconfigurez l’expéditeur pour utiliser le sélecteur publié. Si vous êtes en rotation, publiez les anciens et nouveaux sélecteurs jusqu’à ce que le trafic ancien soit drainé et que tous les expéditeurs soient mis à jour.

Tâche 11 : vérifier la correction de l’enregistrement DMARC

cr0x@server:~$ dig _dmarc.example.com TXT +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com"

Ce que ça signifie : DMARC existe, la politique est quarantine, l’alignement strict est activé.

Décision : L’alignement strict est acceptable seulement si vous êtes discipliné sur les domaines From et la signature. Si vous avez de nombreux systèmes qui envoient du courrier, l’alignement strict peut se retourner contre vous. Envisagez l’alignement relâché pendant le nettoyage, puis renforcez-le ensuite.

Tâche 12 : détecter plusieurs enregistrements DMARC

cr0x@server:~$ dig _dmarc.example.com TXT +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Ce que ça signifie : Deux enregistrements DMARC. Les récepteurs peuvent traiter cela comme invalide et ignorer DMARC entièrement.

Décision : Publiez exactement un enregistrement DMARC à _dmarc. Fusionnez les tags en une seule politique.

Tâche 13 : vérifier le reverse DNS (PTR) pour l’IP sortante

cr0x@server:~$ dig -x 203.0.113.55 +noall +answer
55.113.0.203.in-addr.arpa. 3600 IN PTR mailout.example.com.

Ce que ça signifie : L’IP a un PTR pointant vers mailout.example.com.

Décision : Assurez-vous que ce nom d’hôte résout aussi en avant vers la même IP (FCrDNS). Si le PTR est manquant ou générique, corrigez-le avec votre ISP/fournisseur cloud ; c’est souvent non négociable pour une bonne délivrabilité.

Tâche 14 : vérifier le reverse confirmé (FCrDNS)

cr0x@server:~$ dig mailout.example.com A +noall +answer
mailout.example.com. 300 IN A 203.0.113.55

Ce que ça signifie : L’avant correspond au reverse. C’est la base ennuyeuse que beaucoup de récepteurs attendent.

Décision : Si l’avant ne correspond pas, corrigez soit le PTR soit l’A. Ne le laissez pas “assez proche”. Les systèmes de mail ne sont pas connus pour leur indulgence.

Tâche 15 : vérifier le split horizon DNS (public vs interne)

cr0x@server:~$ dig @10.0.0.53 example.com MX +noall +answer
example.com. 300 IN MX 10 mx1.internal.example.

cr0x@server:~$ dig @1.1.1.1 example.com MX +noall +answer
example.com. 300 IN MX 10 mx1.newmail.example.

Ce que ça signifie : Le DNS interne renvoie un MX différent du DNS public.

Décision : Sauf architecture très spécifique et bien testée, unifiez-les. Au minimum, assurez-vous que les clients internes qui envoient du mail vers l’extérieur n’utilisent pas d’identités internes-only qui cassent SPF/DKIM/DMARC et embrouillent le routage du courrier.

Tâche 16 : confirmer le TTL DNS et les hints de cache négatif

cr0x@server:~$ dig example.com SOA +noall +answer
example.com. 300 IN SOA ns1.dns-host.example. hostmaster.example.com. 2026010401 3600 900 1209600 300

Ce que ça signifie : Le SOA montre le serial de la zone et le dernier champ (minimum) influence souvent le comportement de cache négatif.

Décision : Si vous avez brièvement publié un sélecteur DKIM manquant (NXDOMAIN), certains résolveurs peuvent se souvenir de cette absence. Planifiez les rotations clés avec recouvrement et évitez les déploiements où “un enregistrement disparaît pendant une minute”.

Tâche 17 : inspecter les résultats d’authentification d’un vrai message (dans les en-têtes)

cr0x@server:~$ grep -E "Authentication-Results|Received-SPF|DKIM-Signature|DMARC" -n message.eml | head
12:Authentication-Results: mx.google.com; spf=fail (google.com: domain of bounce@example.com does not designate 203.0.113.55 as permitted sender) smtp.mailfrom=bounce@example.com; dkim=pass header.i=@example.com; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com
33:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; ...

Ce que ça signifie : DKIM passe, SPF échoue, DMARC échoue. Cela peut arriver si DKIM est aligné mais DMARC échoue quand même à cause d’un désalignement ou parce que l’évaluation du récepteur diffère de votre attente.

Décision : Concentrez-vous sur l’alignement : assurez-vous que le domaine DKIM d= et/ou le domaine mailfrom SPF s’alignent avec le From visible. Si DMARC est strict et que votre mailfrom est un domaine de rebond tiers, vous devrez peut-être un return-path personnalisé ou une configuration d’envoi différente.

Tâche 18 : confirmer que votre MX accepte réellement les connexions SMTP (réalité réseau)

cr0x@server:~$ nc -vz mx1.newmail.example 25
Connection to mx1.newmail.example 25 port [tcp/smtp] succeeded!

Ce que ça signifie : Le port 25 est joignable.

Décision : Si cela échoue depuis l’Internet public mais fonctionne en interne, vous avez des problèmes de pare-feu ou de routage—pas un problème DNS. N’éditez pas les enregistrements TXT pour corriger un port fermé.

Trois mini-récits en entreprise depuis le terrain

Mini-récit n°1 : l’incident causé par une mauvaise hypothèse

L’entreprise avait deux marques sous un même parent. L’équipe marketing a décidé d’unifier les envois pour que les campagnes proviennent d’une plate-forme unique. Le guide d’intégration du fournisseur disait : “Ajoutez ces includes SPF et ces clés DKIM.” Jusque-là, normal.

La mauvaise hypothèse est arrivée en silence : quelqu’un croyait que SPF était évalué par rapport au domaine visible From. Ils ont mis à jour le SPF de brandA.com pour inclure le fournisseur et ont considéré la tâche comme terminée. En réalité, les mails transactionnels utilisaient bounces.brandA-mail.com comme expéditeur d’enveloppe, car un système différent gérait les return paths. Le SPF de ce domaine pointait encore vers l’ancien relais.

La délivrabilité n’a pas échoué universellement. Elle a échoué pour certains récepteurs à fort signal qui accordaient beaucoup d’importance au SPF pour ce flux. Le support a reçu des tickets “certains clients ne reçoivent pas leurs réinitialisations de mot de passe”—toujours la pire catégorie, car les utilisateurs ne distinguent pas “mail marketing” et “mon compte est cassé”.

Le débogage a pris plus de temps que nécessaire car les tests ont été faits depuis un seul fournisseur de boîte et un seul réseau. L’équipe a finalement regardé les en-têtes Authentication-Results, a vu le SPF échouer sur l’expéditeur d’enveloppe, et a réalisé qu’ils avaient authentifié le mauvais domaine.

La correction fut ennuyeuse : publier SPF et DKIM pour le domaine de rebond réel, aligner DMARC sur le From visible, et standardiser la gestion des return-paths entre les systèmes. Ils ont aussi noté en grandes lettres quels domaines servaient à quoi. La production adore les grosses lettres.

Mini-récit n°2 : l’optimisation qui s’est retournée contre eux

Une organisation en forte croissance a déplacé son DNS vers un fournisseur qui supportait le “smart routing” et des vérifications de santé automatisées. Ils ont réduit les TTL dans toute la zone parce qu’ils voulaient un “basculement instantané” pendant les incidents. Cela semblait raisonnable en réunion.

Puis ils ont migré le courrier entrant. Pendant le basculement, leur automatisation n’a cessé de basculer les MX car un des nouveaux hôtes MX échouait intermittemment un contrôle TCP. Certains résolveurs ont mis en cache l’ancien MX, d’autres le nouveau, et d’autres une version d’il y a cinq minutes. Le courrier entrant est devenu probabiliste.

Cela a empiré : un TTL bas a augmenté le volume de requêtes et a exposé un second problème—la limitation de débit chez le fournisseur autoritatif pendant un pic. Les récepteurs ont commencé à voir des SERVFAIL occasionnels. Ces expéditeurs ont mis en file et réessayé (l’e-mail est patient), mais cela a créé une onde de livraisons retardées qui ressemblait à un bug applicatif.

La leçon post-incident n’était pas “ne jamais baisser le TTL”. C’était : n’utilisez pas le DNS comme un load balancer piloté par des checks de santé pour le mail à moins de bien comprendre l’écosystème des récepteurs. Les expéditeurs SMTP ont déjà une logique de retries. Votre boulot est un routage stable et une identité stable, pas des basculements sophistiqués.

Mini-récit n°3 : la pratique ennuyeuse mais correcte qui a sauvé la situation

Une autre équipe avait un plan de migration qui semblait presque trop conservateur : ils ont documenté chaque source d’envoi (système de ticketing, CRM, alertes de monitoring, mails produit, marketing). Pour chacun, ils ont enregistré le domaine From, le domaine expéditeur d’enveloppe, le sélecteur DKIM, et l’IP ou le relais sortant.

Ils exécutaient aussi une vérification hebdomadaire de “dérive DNS” : récupérer les enregistrements de la zone via l’API autoritative, comparer avec un template connu bon, et alerter sur les différences. Ce n’était pas glamour. Personne n’a été promu parce qu’un cronjob n’a pas déclenché. Mais cela a évité des surprises.

Quand ils ont migré vers un nouveau relais sortant, la vérification de dérive a signalé qu’un collègue avait ajouté un second enregistrement SPF au lieu de modifier l’existant. Cela n’est jamais arrivé en production car le changement a échoué une pré-validation.

La migration a quand même eu des heurts normaux—certains caches ont gardé l’ancien MX plus longtemps que prévu—mais le courrier n’a pas été divisé entre fournisseurs et DMARC n’a pas soudainement rejeté des envois légitimes. La pratique “ennuyeuse” n’était pas une surcharge ; c’était une ceinture de sécurité.

Erreurs courantes (symptômes → cause racine → correction)

1) Symptom : Certains expéditeurs rebondissent avec “host not found”, d’autres livrent normalement

Cause racine : Visibilité MX incohérente selon les résolveurs (fenêtre de propagation, caches obsolètes, ou réponses autoritatives inconsistantes). Parfois des ensembles NS mixtes lors de changements de registrar.

Correction : Interrogez directement les NS autoritatifs ; assurez-vous que tous servent le même serial de zone et les mêmes enregistrements. Évitez de changer NS et MX simultanément sauf si vous aimez le stress. Augmentez le TTL avant des migrations planifiées, pas pendant.

2) Symptom : Le courrier entrant atterrit aléatoirement chez l’ancien fournisseur

Cause racine : Anciens enregistrements MX toujours publiés, souvent avec la même préférence ou une préférence encore plus basse que les nouveaux.

Correction : Publiez seulement l’ensemble MX prévu. Si vous avez besoin d’une livraison double, faites-le intentionnellement avec une couche de routage contrôlée, pas en laissant des ordures dans le DNS.

3) Symptom : SPF affiche “permerror” dans les en-têtes

Cause racine : Plusieurs enregistrements TXT SPF, ou limite de résolutions SPF dépassée à cause de trop d’includes/redirects.

Correction : Consolidez en un seul enregistrement SPF. Réduisez les includes, retirez les fournisseurs inutilisés, et maintenez le nombre de résolutions sous 10.

4) Symptom : DKIM “selector not found” apparaît de façon intermittente

Cause racine : Sélecteur publié dans une vue DNS mais pas dans une autre (split horizon), ou enregistrement mis à jour sur un NS autoritatif mais pas sur l’autre, ou rotation de clé ayant supprimé l’ancien sélecteur trop tôt.

Correction : Publiez les sélecteurs de façon cohérente sur tous les serveurs autoritatifs. Pendant une rotation, chevauchez l’ancien et le nouveau. Ne “nettoyez” pas tant que vous n’avez pas vérifié que tous les expéditeurs sont passés.

5) Symptom : DMARC rejette du courrier légitime après un changement de fournisseur

Cause racine : Alignement cassé—le nouveau fournisseur utilise un domaine de rebond différent, ou DKIM signe avec un domaine qui ne s’aligne pas avec le From, surtout en alignement strict.

Correction : Configurez un return-path personnalisé quand c’est possible. Assurez-vous que le d= DKIM s’aligne avec le From. Envisagez l’alignement relâché pendant la migration, puis renforcez-le.

6) Symptom : Le courrier vers un grand fournisseur est retardé de plusieurs heures

Cause racine : Le récepteur ne peut pas atteindre vos MX de façon constante (préférence IPv6 vers un AAAA cassé, blocage pare-feu, greylisting + échecs d’auth), ou DNS intermittents SERVFAIL dus à des problèmes autoritatifs.

Correction : Validez le chemin IPv6 si vous publiez un AAAA. Vérifiez la joignabilité du port 25 depuis l’extérieur. Stabilisez le DNS autoritatif et évitez les enregistrements qui basculent.

7) Symptom : Vous passez SPF mais êtes toujours en spam

Cause racine : SPF passe sur un domaine non aligné (ou seule l’identité HELO passe). DMARC échoue ou manque. Ou la réputation IP et PTR/HELO sont faibles.

Correction : Mettez en place DKIM et DMARC avec alignement. Corrigez PTR/FCrDNS. Assurez-vous que le HELO sortant est stable et pertinent.

8) Symptom : Tout semble correct au bureau, mais échoue pour les clients

Cause racine : Split horizon DNS renvoyant des réponses MX/SPF/DKIM internes seulement, ou l’egress interne utilise une IP NAT différente des tests externes.

Correction : Testez depuis des réseaux externes. Retirez les overrides internes pour les identités e-mail publiques. Documentez et surveillez vos IPs d’egress.

Checklists / plan étape par étape

Étape par étape : corriger une outage e-mail due à un DNS mixte en toute sécurité

1. Geler les changements. Arrêtez d’éditer des enregistrements au hasard tant que vous devinez. Capturez l’état actuel de la zone (MX, TXT, A/AAAA, NS, SOA).
2. Établir la vérité autoritative. Interrogez chaque NS autoritatif directement pour MX, TXT SPF, sélecteurs DKIM, DMARC. Si ils sont en désaccord, corrigez cela en premier.
3. Rendre l’entrée déterministe. Publiez seulement l’ensemble MX prévu. Vérifiez que les cibles MX résolvent et acceptent le SMTP.
4. Corriger SPF en un seul enregistrement. Fusionnez les includes ; vérifiez le nombre de résolutions ; assurez-vous d’autoriser toutes les sources sortantes légitimes (ou routez-les via un relais unique).
5. Corriger les sélecteurs DKIM. Assurez-vous que chaque expéditeur signe et que le sélecteur existe dans le DNS public. Chevauchez les anciens/nouveaux sélecteurs pendant une rotation.
6. Régler DMARC en fonction de la réalité. Commencez par p=none si nécessaire, puis passez à quarantine et reject une fois l’alignement prouvé sur toutes les sources.
7. Vérifier l’identité IP. PTR + FCrDNS ; assurez-vous que HELO/EHLO est stable et correspond au PTR quand approprié.
8. Tester depuis plusieurs points de vue. Utilisez au moins une VM externe et un ISP grand public si possible.
9. Attendre les caches intelligemment. Suivez les TTL ; communiquez aux parties prenantes les fenêtres de convergence attendues. Ne promettez pas une récupération instantanée si le TTL est d’une heure et que des résolveurs sont collants.
10. Clore la boucle avec de vrais en-têtes. Validez les Authentication-Results depuis des récepteurs représentatifs. Si vous ne pouvez pas voir les en-têtes, vous dépannez à l’aveugle.

Checklist prévention : empêcher que le DNS devienne un générateur d’outage e-mail

• Un propriétaire pour la surface DNS e-mail. Pas “tout le monde peut éditer les TXT parce que c’est facile.” Le facile, c’est comment on finit avec plusieurs enregistrements SPF.
• Inventaire de tous les systèmes d’envoi. Pour chacun : domaine From, domaine expéditeur d’enveloppe, sélecteur DKIM, IP/relais sortant, et s’il supporte un return-path personnalisé.
• Gestion des changements pour le DNS. Revue en staging, approbation par un pair, et un plan de rollback qui n’implique pas des clics frénétiques dans une console web.
• Surveiller les réponses DNS depuis plusieurs résolveurs. Alertez si MX/SPF/DMARC/DKIM changent de façon inattendue, ou si les NS autoritatifs sont en désaccord.
• Playbook de rotation de clés. Publiez le nouveau sélecteur d’abord, puis basculez la signature, puis retirez l’ancien sélecteur plus tard.
• Ne pas sur-optimiser le TTL. Utilisez le TTL comme outil de planification. Baissez-le avant des changements planifiés, puis remontez-le pour la stabilité.
• Documenter les coupures de fournisseur. Surtout quand deux fournisseurs sont impliqués (ancien + nouveau). Les entrées DNS “temporaires” doivent avoir une date d’expiration et un propriétaire.

FAQ

1) Qu’est-ce qui compte exactement comme “enregistrements DNS mixtes” pour l’e-mail ?

Toute combinaison où le routage du courrier ou les données d’authentification sont incohérentes : deux ensembles MX de fournisseurs différents, plusieurs enregistrements SPF, DMARC dupliqué, sélecteurs DKIM manquants, ou DNS interne/public renvoyant des réponses différentes.

2) Puis-je garder anciens et nouveaux MX pendant une migration “au cas où” ?

Vous le pouvez, mais généralement vous ne devriez pas. Cela crée un routage nondéterministe à moins que vous ne contrôliez les deux bouts et ayez un plan pour la déduplication, la visibilité utilisateur et le support. La plupart des organisations veulent une livraison déterministe vers un seul système de boîte.

3) Pourquoi le courrier va-t-il encore chez l’ancien fournisseur même après la mise à jour du MX ?

Parce que les systèmes d’envoi mettent en cache le DNS. Certains mettent en cache plus longtemps que votre TTL. Certains réessayent aussi contre des cibles MX résolues précédemment pour des messages en file. C’est normal. Votre travail est de vous assurer que les réponses autoritatives sont correctes et stables.

4) Avoir deux enregistrements SPF est-ce toujours faux ?

Oui, pour des raisons pratiques. La spec SPF attend un seul enregistrement politique. Beaucoup de récepteurs traitent plusieurs chaînes v=spf1 comme une erreur permanente.

5) Si DKIM passe, ai-je encore besoin de SPF ?

Pour la délivrabilité moderne, vous voulez les deux. DKIM est souvent le signal le plus robuste en cas de transfert, mais SPF compte toujours, et DMARC peut passer via l’un ou l’autre—à condition d’être aligné.

6) Qu’est-ce que l’alignement DMARC, en termes simples ?

Cela signifie que le domaine authentifié (par SPF mailfrom ou DKIM d=) correspond au domaine visible From, soit exactement (strict), soit au sein du même domaine organisationnel (relâché).

7) Comment les configurations split horizon DNS cassent-elles l’e-mail ?

Si les résolveurs internes renvoient des MX/SPF/DKIM/DMARC différents de l’Internet public, les tests internes peuvent réussir tandis que les expéditeurs externes échouent. De plus, les apps internes peuvent envoyer avec des identités qui ne valident pas à l’extérieur.

8) Dois-je publier des enregistrements AAAA pour mes hôtes MX ?

Seulement si vous acceptez réellement SMTP via IPv6 de manière fiable (connectivité, pare-feu, configuration TLS, monitoring). Publier un AAAA sans préparation opérationnelle crée des délais d’attente et des retards pour les expéditeurs qui préfèrent IPv6.

9) À quel niveau de sévérité régler DMARC ?

Commencez par p=none pour observer, puis passez à quarantine, puis à reject une fois que vous avez vérifié que toutes les sources légitimes s’alignent et signent. L’application sans inventaire est la façon de bloquer vos propres mails.

10) Quel est l’indicateur le plus rapide que le DNS est en cause ?

Des résolveurs différents renvoyant des réponses MX ou TXT différentes pour le même nom. Si les serveurs de noms autoritatifs sont en désaccord, c’est presque certainement un problème de publication DNS plutôt qu’un problème de serveur de mail.

Conclusion : prochaines étapes à faire aujourd’hui

Si vous retenez une chose : l’e-mail casse quand le DNS raconte deux histoires en même temps. Votre travail est de le faire raconter une histoire ennuyeuse et correcte—de façon cohérente, depuis chaque résolveur, à chaque fois.

1. Exécutez les requêtes MX/SPF/DKIM/DMARC contre les serveurs de noms autoritatifs et au moins un résolveur public. Sauvegardez les sorties.
2. Rendez les MX déterministes : supprimez les entrées fournisseurs héritées et vérifiez que les cibles MX résolvent et acceptent le SMTP.
3. Réduisez l’entropie d’authentification : un seul enregistrement SPF, sélecteurs DKIM publiés correspondant à la signature réelle, un DMARC unique avec une politique adaptée à votre maturité actuelle.
4. Vérifiez l’identité sortante : PTR + correspondance avant/arrière, HELO stable, et pas de changements d’IP d’egress surprises.
5. Notez votre inventaire d’envoi et mettez une porte de changement avant les éditions DNS. Le vous du futur ne sera pas nostalgique des “correctifs rapides”.