Vérifier SPF et DMARC : comment lire, tester et corriger vos enregistrements

Ce que vérifient SPF, DKIM et DMARC

SPF et DKIM peuvent tous deux réussir pour un domaine que le lecteur ne voit jamais. DMARC comble cet écart avec l’alignement : un message passe lorsque SPF ou DKIM réussit pour un domaine aligné sur le domaine du From, et une seule réussite alignée suffit. En mode relâché, le mode par défaut, il suffit que les deux partagent le même domaine organisationnel : bounce.example.com est donc aligné avec example.com. En mode strict, ils doivent être identiques.

Un service d’envoi de newsletters fictif montre pourquoi c’est important. Il envoie en tant que news@example.com, mais utilise comme expéditeur d’enveloppe son propre domaine de retour, example.net. SPF réussit pour example.net, qui n’est pas aligné : DMARC ne passe donc que si le service signe en DKIM avec d=example.com.

Interroger les enregistrements avec dig ou nslookup

dig (Linux, macOS) ou nslookup (Windows) suffisent :

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
nslookup -type=TXT _dmarc.example.com

L’enregistrement SPF est le TXT qui commence par v=spf1 ; les jetons de vérification d’autres services se trouvent souvent à côté. L’enregistrement DMARC est le TXT placé sur _dmarc qui commence par v=DMARC1. Vérifiez SPF sur le domaine de l’expéditeur d’enveloppe, qui peut différer du domaine du From ; l’en-tête Return-Path d’un message reçu l’indique.

Les clés DKIM ne peuvent pas être listées de l’extérieur, car chacune se trouve sous un sélecteur. Lisez les valeurs s= et d= de l’en-tête DKIM-Signature d’un message que vous avez envoyé, puis interrogez ce nom, par exemple dig +short TXT s1._domainkey.example.com.

Après une modification, les résolveurs peuvent servir l’ancienne réponse jusqu’à l’expiration de son TTL. Pour voir ce qui est publié à l’instant, trouvez les serveurs faisant autorité avec dig +short NS example.com et interrogez-en un directement : dig +short TXT example.com @ns1.example.net. Envoyez ensuite un vrai message vers une boîte que vous contrôlez et lisez son en-tête Authentication-Results. Il indique ce que le destinataire a décidé pour SPF, DKIM et DMARC, et c’est ce résultat qui compte.

Lire un enregistrement SPF

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

Les mécanismes sont évalués de gauche à droite, et le premier qui correspond décide du résultat. Chacun peut porter un qualificatif : + réussite (par défaut), - échec, ~ échec atténué (softfail), ? neutre.

L’ANSSI recommande de configurer SPF pour les domaines de messagerie, tout en rappelant dans son guide sur l’interconnexion d’un système d’information à Internet que le protocole n’est pas infaillible face à l’usurpation : un serveur autorisé mais partagé, ou compromis, passe le contrôle. SPF seul ne suffit donc pas ; DKIM et DMARC le complètent.

~all ou -all

~all indique que les serveurs non listés ne sont probablement pas autorisés, et les destinataires ne devraient pas rejeter sur ce seul motif. -all indique qu’ils ne sont pas autorisés ; la suite relève de la politique propre au destinataire. Les deux sont défendables, et le BSI allemand accepte l’un comme l’autre. La RFC 9989 ajoute une mise en garde : avec -all, un destinataire qui vérifie SPF tôt dans la session SMTP peut rejeter un message qu’une signature DKIM alignée aurait fait passer, typiquement un message transféré, et ce rejet n’apparaît jamais dans les rapports DMARC. ?all, ou l’absence de all, ne dit rien des serveurs non listés. +all fait réussir n’importe quelle adresse IP d’Internet ; ne le publiez jamais.

La limite des 10 requêtes DNS

Les destinataires évaluent au plus 10 termes qui déclenchent une requête DNS, y compris ceux des enregistrements inclus (section 4.6.4). Au-delà, le résultat est permerror, et SPF ne peut plus aider un message à passer DMARC. Une limite distincte vise les requêtes qui ne renvoient aucune réponse : au-delà de deux, le résultat devrait aussi être permerror. Un enregistrement qui affiche quatre termes peut dépasser la limite si les enregistrements inclus contiennent eux-mêmes des inclusions : comptez de façon récursive. Pour revenir sous la limite, retirez les services que vous n’utilisez plus, écrivez en ip4/ip6 les adresses que vous maîtrisez, et déplacez les services à gros volume vers leur propre sous-domaine de retour, avec son propre enregistrement SPF. L’aplatissement (flattening), qui recopie les plages IP d’un prestataire dans votre enregistrement, devient faux dès que le prestataire les modifie.

Un seul enregistrement par nom

Deux enregistrements TXT commençant par v=spf1 sur un même nom produisent un permerror : fusionnez-les. Un enregistrement de plus de 255 caractères se publie dans un seul TXT sous forme de plusieurs chaînes entre guillemets, que les destinataires concatènent sans espace. SPF ne s’hérite pas non plus : un enregistrement sur example.com ne couvre pas mail.example.com, et chaque nom utilisé comme expéditeur d’enveloppe a besoin du sien.

Lire un enregistrement DMARC

DMARC est désormais défini par la RFC 9989 (mai 2026), une spécification de l’IETF publiée sur la voie de normalisation (Standards Track), qui remplace la RFC 7489. L’enregistrement se trouve toujours sur _dmarc et commence par v=DMARC1 :

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Un enregistrement sur example.com couvre aussi les sous-domaines qui n’en ont pas ; les destinataires le trouvent par ce que la RFC 9989 appelle un parcours de l’arborescence DNS (DNS Tree Walk). Les destinataires qui envoient des rapports agrégés les livrent sous forme de fichiers XML, en général quotidiens, qui listent les adresses IP ayant envoyé au nom de votre domaine et leurs résultats. Si rua pointe vers un autre domaine organisationnel, par exemple un service d’analyse des rapports, ce domaine doit publier un enregistrement TXT comme example.com._report._dmarc.reports.example.net commençant par v=DMARC1 (RFC 9990, section 4), faute de quoi les destinataires ignorent l’adresse.

De none à reject

1. Listez tous les services qui envoient au nom du domaine : messagerie, newsletter, CRM, facturation, support, formulaires du site.
2. Publiez p=none avec rua et lisez les rapports.
3. Corrigez chaque source légitime jusqu’à ce qu’elle passe avec alignement, de préférence via DKIM, qui survit en général au transfert, contrairement à SPF.
4. Passez à quarantine, éventuellement avec t=y d’abord, puis envisagez reject.

Selon la RFC 9989, les domaines dont les utilisateurs écrivent sur des listes de diffusion NE DEVRAIENT PAS publier reject ; ceux qui le veulent malgré tout devraient d’abord passer au moins un mois en none, puis autant en quarantine, en comparant les résultats. Tout domaine qui publie reject DOIT signer son courrier avec DKIM. Le BSI allemand, dans sa directive technique TR-03182, est plus strict : un domaine expéditeur DEVRAIT exiger reject. Un domaine réservé aux factures et aux notifications n’est pas dans la même situation qu’un domaine que vos équipes utilisent sur des listes de diffusion. La RFC 9989 demande aussi aux destinataires de ne pas rejeter sur la seule base de p=reject, tout en reconnaissant qu’en pratique, les messages de liste dont la ligne From est restée inchangée sont souvent rejetés.

Les domaines qui n’envoient pas d’e-mails

Les domaines parqués, ceux réservés pour protéger une marque contre les fautes de frappe ou les déclinaisons (la version .com, .eu ou .be d’une marque en .fr, par exemple) et ceux qui ne servent qu’à rediriger peuvent tout de même apparaître dans une ligne From falsifiée. La RFC 7208 qualifie de bonne pratique bien établie la publication d’un enregistrement SPF pour les domaines qui n’envoient pas de courrier. Un jeu complet pour un domaine parqué fictif :

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
example.net.         MX   0 .

L’enregistrement SPF n’autorise personne, et p=reject ne coûte rien ici puisqu’il n’y a aucun courrier légitime à perdre. Le MX nul de la RFC 7505 indique que le domaine n’accepte aucun courrier ; les rapports partent donc vers example.com, qui doit publier example.net._report._dmarc.example.com. Le BSI TR-03182 impose cette même combinaison pour les domaines inutilisés. La politique DMARC couvre les sous-domaines, mais pas SPF : donnez aussi un v=spf1 -all à tout sous-domaine qui possède son propre enregistrement A ou MX.

Ce qu’exigent Gmail, Yahoo et Outlook.com des expéditeurs

Depuis novembre 2025, Gmail renforce progressivement l’application de ces règles, rejets compris. Les règles de Google visent les comptes Gmail personnels, pas les destinataires Google Workspace. Google et Yahoo exigent des clés DKIM d’au moins 1024 bits. Microsoft rejette le courrier qui ne respecte pas ses exigences avec le code 550 5.7.515. Les trois acceptent p=none, qui satisfait la règle mais n’exprime aucune préférence sur le courrier falsifié : voyez-y une étape, pas une configuration terminée.

MTA-STS et CAA : deux autres enregistrements à vérifier

MTA-STS (RFC 8461) protège le courrier entrant : il demande aux serveurs expéditeurs de ne livrer à vos hôtes MX que s’ils proposent TLS avec un certificat de confiance. Il lui faut un enregistrement TXT sur _mta-sts.example.com, par exemple v=STSv1; id=20261001000000Z;, et un fichier de politique à l’adresse https://mta-sts.example.com/.well-known/mta-sts.txt qui indique le mode, les noms MX et max_age. Commencez en mode testing, où les expéditeurs livrent quand même et signalent les échecs si les rapports TLS sont configurés sur _smtp._tls.example.com, puis passez en enforce. Changez l’id à chaque modification de la politique.

CAA (RFC 8659) désigne les autorités de certification (AC) autorisées à émettre des certificats TLS pour le domaine, par exemple CAA 0 issue "ca.example.net". Les AC publiques doivent le consulter avant toute émission ; il n’empêche pas une AC autorisée d’émettre un certificat à tort, et les navigateurs ne l’utilisent pas. Un enregistrement sur example.com couvre les sous-domaines qui n’en ont pas. Listez toutes les AC que vous utilisez, y compris celle de votre CDN, sinon des renouvellements peuvent échouer. Le guide TLS et en-têtes de sécurité détaille la partie certificats.

Erreurs SPF et DMARC courantes et comment les corriger

Ce que le snapshot gratuit vérifie dans votre DNS de messagerie

Le snapshot gratuit de Sitelemetry exécute huit contrôles passifs sur une origine publique, sans inscription. Ce n’est pas un test d’intrusion, ni l’audit des six domaines. L’un des huit contrôles lit les enregistrements DNS de messagerie :

• Nom d’hôte exact. MX, TXT, _dmarc, _mta-sts et CAA sont interrogés sur le nom d’hôte saisi, sans repli sur le domaine parent. Un enregistrement absent sur www.example.com ne signifie pas qu’example.com n’est pas protégé. Pour faire lire les enregistrements de votre domaine de messagerie, saisissez ce domaine lui-même (example.com plutôt que www.example.com) ; ce domaine doit avoir une adresse IP (enregistrement A ou AAAA) pour que le snapshot produise un score.
• SPF. Un enregistrement absent n’est signalé (gravité moyenne) que si l’hôte a des enregistrements MX. +all est signalé comme risque élevé et ?all comme faible ; ~all et -all ne déclenchent rien. Plus de dix termes à requête DNS sont signalés (gravité moyenne), mais seuls les termes de l’enregistrement de premier niveau sont comptés, car include: n’est pas suivi.
• DMARC. Un enregistrement absent n’est signalé (gravité moyenne) que si l’hôte a des enregistrements MX. p=none est signalé comme mode observation (faible), et quarantine ou reject comptent comme réussis. sp, pct, rua et l’alignement ne sont pas évalués.
• MTA-STS et CAA. L’absence d’enregistrement TXT _mta-sts n’est signalée (faible) que si l’hôte a des enregistrements MX ; le fichier de politique n’est pas téléchargé. Tout enregistrement CAA compte comme réussi, et son absence donne un signal faible ; son contenu n’est pas comparé à votre certificat.
• Non vérifiés : DKIM, les rapports TLS et DNSSEC.

Vous obtenez un score avec sa note, une note de durcissement, le nombre de signaux de risque et de contrôles réussis, et jusqu’à trois signaux, les plus graves en premier : un point sur la messagerie peut donc passer derrière un point sur le site web. Un nom sans adresse IP n’obtient pas de score. La checklist de mise en ligne passe en revue les huit contrôles, et le guide sur la sécurité des e-mails et du DNS couvre le suivi dans la durée.