MX, SPF, DKIM et DMARC : comprendre comment ils s'articulent

Quatre types d'enregistrements DNS déterminent la façon dont le courrier de votre domaine est acheminé et la confiance que lui accordent les destinataires. On les explique d'ordinaire un par un, ce qui masque l'essentiel : chacun comble une faille que les autres laissent ouverte.

Ce guide les présente tous les quatre, recense les erreurs les plus fréquentes dans les zones réelles, et propose un ordre de déploiement qui ne met pas en danger votre courrier légitime.

En bref

MX indique où remettre le courrier adressé à votre domaine.
SPF indique quels serveurs ont le droit d'envoyer du courrier en utilisant votre domaine comme expéditeur d'enveloppe.
DKIM appose une signature cryptographique prouvant qu'un message a été autorisé par un domaine et n'a pas été altéré en chemin.
DMARC relie SPF et DKIM à l'adresse From que les gens voient réellement, dit aux destinataires quoi faire quand les deux échouent, et vous envoie des rapports.

MX concerne la réception. Les trois autres concernent l'envoi.

MX : la destination du courrier

$ dig +short MX example.com
10 mx1.mail.example.net.
20 mx2.mail.example.net.

Les expéditeurs essaient d'abord le numéro de préférence le plus bas, puis se rabattent sur les suivants en cas d'échec. À valeur égale, la charge est partagée.

Les règles qui comptent :

La cible d'un enregistrement MX doit être un nom d'hôte doté d'un enregistrement A ou AAAA. Ce ne doit être ni une adresse IP, ni un CNAME.
En l'absence de MX, les expéditeurs se rabattent sur l'enregistrement A/AAAA du domaine lui-même. Ce n'est presque jamais ce que l'on souhaite.
Un domaine qui ne doit jamais recevoir de courrier peut publier un MX nul : 0 . (préférence zéro, cible réduite à un point). Les expéditeurs échouent alors immédiatement, au lieu de réessayer pendant des jours.

SPF : quels serveurs peuvent envoyer

SPF tient en un unique enregistrement TXT posé sur le domaine :

example.com.  TXT  "v=spf1 include:_spf.mail.example.net ip4:192.0.2.10 -all"

Le serveur destinataire prend le domaine de l'expéditeur d'enveloppe (le Return-Path, et non l'en-tête From visible), récupère son enregistrement SPF et vérifie si l'adresse IP qui se connecte y figure. Le all final décide du sort de tous les autres : -all signifie échec, ~all échec « doux » (softfail), ?all sans opinion.

Deux limites sont inhérentes au mécanisme :

SPF contrôle un domaine que le destinataire ne voit jamais. À lui seul, il n'empêche nullement quelqu'un d'usurper votre adresse From visible.
SPF ne résiste pas au transfert de courrier. Quand un message est réexpédié, c'est l'adresse IP du serveur qui réexpédie qui se présente au destinataire final, et cette adresse ne figure pas dans votre enregistrement.

DKIM : une signature qui voyage avec le message

Avec DKIM, le serveur d'envoi signe certains en-têtes ainsi que le corps du message avec une clé privée, puis ajoute un en-tête DKIM-Signature. La clé publique, elle, se trouve dans le DNS :

s2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

s2026 est le sélecteur. C'est une étiquette arbitraire choisie par le système d'envoi ; elle apparaît dans l'en-tête de signature sous la forme s=s2026, à côté du domaine signataire d=example.com. Un domaine peut compter autant de sélecteurs qu'il le souhaite : un par service d'envoi, un par rotation de clé.

Il en découle une conséquence sur laquelle beaucoup trébuchent : on ne peut pas rechercher « l'enregistrement DKIM » d'un domaine. Le DNS n'offre aucun moyen d'énumérer les noms situés sous _domainkey. Il faut connaître le sélecteur, et la façon fiable de l'obtenir consiste à ouvrir les en-têtes d'un message réellement envoyé par le domaine.

DKIM survit à un simple transfert, puisque la signature voyage avec le message. Il casse lorsqu'un intermédiaire modifie un contenu signé, ce que font beaucoup de listes de diffusion en ajoutant un pied de page ou un préfixe dans l'objet.

DMARC : alignement, politique et rapports

DMARC est un enregistrement TXT placé sous _dmarc :

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Il apporte trois choses.

L'alignement. Un message satisfait DMARC si SPF réussit et que le domaine d'enveloppe est aligné sur le domaine du From, ou si DKIM réussit et que le domaine d= est aligné sur le domaine du From. Une seule réussite alignée suffit. Par défaut, l'alignement est souple (relaxed) : mail.example.com est aligné sur example.com.

La politique. p=none demande aux destinataires de ne rien faire, p=quarantine de traiter les échecs comme suspects (en pratique, le dossier spam), et p=reject de refuser le message. sp= fixe une politique distincte pour les sous-domaines.

Les rapports. Les destinataires envoient chaque jour à l'adresse rua des rapports agrégés au format XML : quelles adresses IP ont émis du courrier en votre nom, combien de messages, et si SPF et DKIM ont réussi et étaient alignés. C'est grâce à ces rapports que vous retrouvez les expéditeurs que vous aviez oubliés.

L'alignement explique qu'un message puisse « passer SPF » et échouer quand même à DMARC. Une plateforme de newsletters qui utilise son propre domaine de rebond réussit SPF pour son domaine, lequel n'est pas aligné sur le vôtre. Le remède consiste normalement à configurer un return-path personnalisé ou, mieux, une signature DKIM avec votre propre domaine sur cette plateforme.

Les erreurs que nous voyons le plus souvent

Plusieurs enregistrements SPF

example.com.  TXT  "v=spf1 include:_spf.mail.example.net ~all"
example.com.  TXT  "v=spf1 include:spf.crm.example.org ~all"

Deux enregistrements commençant par v=spf1 constituent une erreur permanente (permerror). SPF échoue pour chaque message. Cela arrive en général lorsque l'on suit au pied de la lettre le guide d'installation d'un nouveau prestataire. Fusionnez-les en un seul enregistrement contenant les deux include.

La limite des 10 requêtes

Un destinataire peut effectuer au plus dix requêtes DNS pendant l'évaluation de SPF. include, a, mx, exists, redirect et ptr comptent chacun pour une, et les include s'emboîtent : l'include d'un seul prestataire peut en coûter trois ou quatre à lui seul. ip4, ip6 et all ne coûtent rien. Au-delà de dix, le résultat est de nouveau un permerror.

Les remèdes, par ordre de préférence : retirer les services que vous n'utilisez plus ; déplacer les envois en masse sur un sous-domaine doté de son propre enregistrement SPF ; pour les services qui le permettent, s'appuyer sur un DKIM aligné et supprimer leur include. Méfiez-vous de l'« aplatissement SPF » (SPF flattening), qui recopie les adresses IP du prestataire dans votre enregistrement : il devient obsolète sans prévenir le jour où le prestataire modifie ses plages.

`+all`

v=spf1 +all autorise tous les serveurs d'Internet. C'est pire que l'absence d'enregistrement, car cela affirme activement que le courrier usurpé est légitime. ?all ne vaut guère mieux.

Le mécanisme `ptr`

Lent, peu fiable et déconseillé par la spécification SPF elle-même. Retirez-le.

`p=none` pour l'éternité

p=none est un mode d'observation. Il vous procure des rapports, aucune protection : n'importe qui peut toujours placer votre domaine dans le champ From, et les destinataires remettront le message comme ils l'auraient fait de toute façon. Nombre de domaines publient p=none pour cocher une case dans une liste d'exigences pour expéditeurs en masse, et n'en bougent plus. Si les rapports sont propres depuis des semaines, rien ne justifie d'en rester là.

Oublier les domaines qui n'envoient rien

Les domaines parqués et ceux qui ne servent qu'à un site web sont usurpés justement parce que personne ne les surveille. Verrouillez-les :

example.org.         TXT  "v=spf1 -all"
_dmarc.example.org.  TXT  "v=DMARC1; p=reject"
example.org.         MX   0 .

Déployer DMARC sans casse

Recensez vos expéditeurs. Fournisseur de messagerie, courrier du site et des applications, CRM, outil de newsletters, facturation, support client, alertes de supervision. Ceux que vous oubliez sont ceux qui casseront.
Corrigez SPF. Un seul enregistrement, moins de dix requêtes, terminé par ~all ou -all.
Activez DKIM partout. Pour chaque service, activez la signature avec votre domaine dans d=. C'est le point le plus important, car c'est DKIM qui permet à DMARC de continuer à réussir malgré les transferts.
Publiez p=none avec une adresse rua. Utilisez une boîte dédiée ou un service d'analyse des rapports : le XML brut est pénible à lire à l'œil nu.
Lisez les rapports pendant deux à quatre semaines. Cherchez les sources légitimes dont l'alignement échoue. Corrigez chacune à la source.
Passez à p=quarantine. Si votre volume est important, servez-vous de pct= pour avancer par paliers, par exemple 10, puis 50, puis 100. Continuez à lire les rapports.
Passez à p=reject. Décidez séparément si les sous-domaines ont besoin de leur propre politique sp=.
Restez attentif. De nouveaux outils sont adoptés sans que personne ne prévienne le responsable du DNS. Ce sont les rapports qui vous l'apprennent.

Attendez-vous à un petit reliquat d'échecs impossibles à corriger, dus surtout aux listes de diffusion et à des redirections exotiques. Beaucoup de destinataires les traitent au moyen d'ARC ou d'heuristiques locales. C'est une raison d'avancer prudemment, pas une raison de rester à p=none.

Ce que les enregistrements ne peuvent pas faire

Des enregistrements MX, SPF, DKIM et DMARC corrects permettent aux destinataires de vérifier que le courrier est autorisé par votre domaine. Ils ne signifient pas que votre courrier arrive en boîte de réception. Les fournisseurs de messagerie pèsent aussi la réputation de votre domaine et de vos adresses IP d'envoi, le taux de plaintes, la qualité des listes, le contenu et la façon dont les destinataires réagissent à vos messages. Rien de tout cela ne se trouve dans le DNS.

L'authentification est le ticket d'entrée. Les grands fournisseurs l'exigent désormais des expéditeurs en masse ; sans elle, vous êtes filtré avant tout autre examen. Avec elle, vous êtes jugé sur vos pratiques d'envoi réelles. Si vos messages finissent malgré tout en indésirables, suivez la liste de contrôle DNS pour les e-mails qui arrivent en spam.

Une vérification DNS ne peut pas non plus prouver que le courrier circule. Elle peut montrer que la politique que vous publiez est cohérente, c'est-à-dire la partie que vous maîtrisez depuis la zone. Pour le détail de chaque type d'enregistrement, voyez les types d'enregistrements DNS expliqués.

Vérifiez avec OrbitProbe

La recherche MX d'OrbitProbe lit les enregistrements MX, SPF et DMARC d'un domaine et signale les problèmes décrits plus haut : plusieurs enregistrements SPF, trop de requêtes, +all, un enregistrement DMARC absent ou une politique figée à p=none. Pour DKIM, repérez votre sélecteur dans les en-têtes d'un message envoyé, puis interrogez selector._domainkey.votredomaine en tant qu'enregistrement TXT. Et si vous voulez être averti lorsque ces enregistrements changent, une surveillance des modifications DNS, dans l'espace de travail, en conserve l'historique.