SPF, DKIM, DMARC : ce que vérifie vraiment chaque enregistrement

NEWSLETTERACCESS · AUTHENTIFICATION DES ENVOIS · ÉDITION DU 31/08/26 · 3 MÉCANISMES, 3 RFC

SPF, DKIM et DMARC sont trois enregistrements DNS qui ne vérifient pas la même chose : SPF valide le domaine d’enveloppe (MAIL FROM), DKIM valide la signature du message et le domaine signataire, et DMARC est le seul des trois à relier ces vérifications à l’adresse From: que le destinataire voit — c’est l’alignement. Depuis le 1^er février 2024, Gmail exige les trois de tout expéditeur dépassant 5 000 messages par jour vers des comptes Gmail personnels, avec un taux de plainte maintenu sous 0,3 % (support.google.com/mail/answer/81126, relevé le 31/08/2026).

Temps de lecture : 7 min · 3 tableaux · 5 exemples DNS copiables · 1 en-tête commenté

Les trois mécanismes, et ce qu’ils font vraiment

SPF — la liste des serveurs autorisés

SPF publie dans le DNS du domaine la liste des serveurs autorisés à envoyer pour lui. Le serveur destinataire compare l’adresse IP qui se présente à cette liste et rend un verdict. Point capital, et c’est là que la plupart des explications dérapent : SPF vérifie le domaine de l’enveloppe — le MAIL FROM, aussi appelé Return-Path — et pas l’adresse From: affichée au destinataire. Un message peut donc passer SPF avec une enveloppe parfaitement valide tout en affichant une adresse d’expéditeur qui n’a rien à voir. SPF valide le domaine d’enveloppe ; c’est l’alignement DMARC qui protège l’adresse affichée. Norme : RFC 7208.

DKIM — la signature cryptographique

DKIM signe cryptographiquement le message au départ. Le destinataire récupère la clé publique publiée en DNS sous le sélecteur indiqué dans la signature, et vérifie. Ce que cela prouve : le message n’a pas été altéré en route, et il vient bien du domaine signataire. Ce que cela ne dit pas : rien sur la légitimité du contenu, rien sur l’expéditeur affiché. Un message de phishing correctement signé par le domaine de l’attaquant rend dkim=pass — le verdict est exact, il porte simplement sur autre chose que ce qu’on croit lire. Norme : RFC 6376.

DMARC — l’alignement, la politique, les rapports

DMARC est le seul des trois à s’intéresser à l’adresse From: visible. Il fait trois choses. Il relie les verdicts SPF et DKIM à ce From: — c’est l’alignement. Il publie une politique qui dit au destinataire quoi faire quand l’alignement échoue : none (observation seule, aucune action), quarantine (indésirables), reject (refus). Et il organise l’envoi de rapports à l’expéditeur : agrégés (rua) et forensiques (ruaf). En p=none, DMARC observe et ne bloque rien : c’est un mode d’écoute, pas une protection. Norme : RFC 7489.

Et les deux qu’on vous citera à côté : ARC et BIMI

ARC (RFC 8617) sert les intermédiaires — listes de diffusion, redirections — qui modifient un message en transit et cassent au passage les verdicts d’origine ; il ne concerne pas l’expéditeur direct. BIMI (bimigroup.org) permet d’afficher un logo dans certaines messageries, mais suppose un DMARC déjà en application et, le plus souvent, un certificat payant : ce n’est jamais automatique, et cela ne se déclenche pas parce qu’on a publié un enregistrement de plus.

Ce que chacun vérifie — et ne vérifie pas

Les enregistrements DNS exacts, copiables

Les exemples ci-dessous emploient le domaine fictif exemple.fr. Ils se recopient en remplaçant le domaine, les include: et les adresses de rapport par les vôtres.

SPF — un seul enregistrement TXT par domaine, jamais deux

exemple.fr.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

DKIM — sélecteur et clé publique

selector1._domainkey.exemple.fr  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

La valeur p= est tronquée ici : dans un enregistrement réel, c’est la clé publique complète fournie par le service d’envoi.

DMARC — trois étapes de durcissement, jamais un saut direct au rejet

# 1. Observation — on écoute, on ne bloque rien
_dmarc.exemple.fr  TXT  "v=DMARC1; p=none; rua=mailto:rapports@exemple.fr; pct=100"

# 2. Montée progressive — pct croissant après lecture des rapports
_dmarc.exemple.fr  TXT  "v=DMARC1; p=quarantine; rua=mailto:rapports@exemple.fr; pct=25"

# 3. Rejet — seulement après plusieurs semaines de rapports propres
_dmarc.exemple.fr  TXT  "v=DMARC1; p=reject; rua=mailto:rapports@exemple.fr"

Les trois erreurs qui cassent tout

Ce ne sont pas des subtilités de spécialiste : ce sont les trois configurations qui, une fois publiées, font échouer l’authentification pour tous les envois du domaine, y compris ceux qui marchaient la veille.

Pourquoi le SPF en double est si fréquent

Parce qu’il se fabrique tout seul : chaque prestataire qui demande « ajoutez cet enregistrement TXT » pousse à en créer un second au lieu de compléter l’existant. Résultat, un seul enregistrement SPF par domaine — c’est la règle, et la fusion des include: est la seule manière de l’appliquer quand on empile plusieurs services d’envoi.

Le plafond de 10 résolutions DNS

La limite de 10 résolutions DNS est fixée par la norme, et elle se dépasse plus vite qu’on ne l’imagine : chaque include: et chaque redirect compte, et un domaine qui empile une suite bureautique, un routeur d’emailing, un outil de facturation et un outil de support y arrive sans effort. Le 11^e lookup ne produit ni alerte ni message : il produit un permerror que personne ne voit avant que les envois ne se dégradent. D’où la règle pratique : compter les lookups avec un outil dédié avant de publier un nouvel include, pas après.

Le rejet posé trop tôt

Passer directement en p=reject fait disparaître les emails légitimes qu’on n’avait pas repérés : factures, notifications, outils tiers qui écrivaient au nom du domaine sans jamais avoir été alignés. Ils échouaient déjà, mais silencieusement — et le jour où la politique passe au rejet, ils cessent d’arriver, sans préavis et sans que personne fasse le lien. La séquence est donc : observer en p=none, lire les rapports rua, corriger les sources légitimes découvertes, puis monter pct progressivement en quarantine, et seulement ensuite passer à reject.

Lire un en-tête brut, ligne à ligne

Tout ce qui précède se lit directement dans un message reçu, via la fonction « afficher l’original » de la messagerie. C’est la seule façon de savoir ce qui s’est réellement passé, plutôt que de le déduire d’un tableau de bord. Voici un extrait d’en-tête, mis en page comme il apparaît à l’écran.

Delivered-To: contact@exemple-destinataire.fr
Authentication-Results: mx.exemple-destinataire.fr;
       spf=pass (domain of exemple.fr designates 192.0.2.25
              as permitted sender) smtp.mailfrom=exemple.fr;
       dkim=pass header.i=@exemple.fr header.s=selector1;
       dmarc=pass (p=QUARANTINE dis=NONE) header.from=exemple.fr
From: Lettre exemple <bonjour@exemple.fr>

Ce bloc est un exemple de lecture, pas un test : rien ici n’atteste du réglage d’un domaine tiers, et cette page ne procède à aucun audit pour le compte de qui que ce soit.

Le commentaire, ligne par ligne

• Authentication-Results: mx.exemple-destinataire.fr — c’est le serveur qui a rendu les verdicts qui suivent. Ils lui appartiennent : ils décrivent ce que ce serveur-là a constaté à ce moment-là, pas une vérité universelle sur le message.
• spf=pass … smtp.mailfrom=exemple.fr — le domaine d’enveloppe validé est exemple.fr, et l’adresse IP qui s’est présentée (192.0.2.25) figurait bien dans l’enregistrement SPF publié pour ce domaine. Ce verdict ne dit rien du From: affiché plus bas.
• dkim=pass header.i=@exemple.fr header.s=selector1 — la signature a été vérifiée avec la clé publique publiée sous le sélecteur selector1 du domaine exemple.fr. Le message n’a donc pas été altéré depuis sa signature, et le domaine signataire est bien celui annoncé.
• dmarc=pass (p=QUARANTINE dis=NONE) header.from=exemple.fr — c’est la ligne qui relie tout le reste. L’adresse From: visible est sur exemple.fr, le même domaine que celui validé par SPF et par la signature DKIM : l’alignement est établi. p=QUARANTINE est la politique publiée par ce domaine au moment de la réception, et dis=NONE indique qu’aucune disposition n’a été appliquée — puisque l’alignement a réussi, il n’y avait rien à appliquer.
• From: Lettre exemple <bonjour@exemple.fr> — la seule ligne que le destinataire voit. Sans DMARC, c’est aussi la seule que personne ne vérifie.

Ce qu’exigent Gmail et Yahoo, chiffres à l’appui

Les deux fournisseurs publient des exigences chiffrées pour les expéditeurs de volume. Ce sont les seuls chiffres de cette page, et ils portent tous leur source et leur date de relevé.

Questions fréquentes

⛔ Ce qu’on ne sait pas

Pour aller plus loin

• Comprendre la délivrabilité — ce que l’authentification règle, et tout ce qu’elle ne règle pas.
• Choisir son serveur d’envoi — c’est lui qui détermine l’IP et le domaine d’enveloppe validés par SPF.
• Créer une adresse professionnelle authentifiée.
• Le cas des emails transactionnels — souvent le premier flux légitime cassé par un p=reject posé trop tôt.
• Retour au dossier email marketing.

Sources

• RFC 7208 — Sender Policy Framework · datatracker.ietf.org/doc/html/rfc7208
• RFC 6376 — DomainKeys Identified Mail · datatracker.ietf.org/doc/html/rfc6376
• RFC 7489 — DMARC · datatracker.ietf.org/doc/html/rfc7489
• RFC 8617 — ARC · datatracker.ietf.org/doc/html/rfc8617
• BIMI Group · bimigroup.org
• Google — Directives pour les expéditeurs · support.google.com/mail/answer/81126 · relevé le 31/08/2026
• Yahoo Sender Hub · senders.yahooinc.com · relevé le 31/08/2026

Article publié le 25/08/2026, mis à jour le 31/08/2026.