Aller au contenu

NEWSLETTER ACCESS · NON CLASSÉ · ÉDITION DU 31/08/26

Non classé

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 1er 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

Mécanisme Type d’enregistrement DNS Emplacement Norme (RFC) Ce qu’il vérifie Ce qu’il NE vérifie PAS
SPF TXT, v=spf1… à la racine du domaine (exemple.fr) RFC 7208 le domaine de l’enveloppe (MAIL FROM) l’adresse From: affichée
DKIM TXT, selector._domainkey. sous-domaine du sélecteur RFC 6376 l’intégrité du message + le domaine signataire la légitimité de l’expéditeur affiché
DMARC TXT, _dmarc. sous-domaine _dmarc RFC 7489 l’alignement SPF/DKIM avec le From:, la politique, les rapports ne filtre pas le spam, ne garantit pas l’arrivée en boîte

source · RFC 7208 / 6376 / 7489, datatracker.ietf.org · relevé le 31/08/26

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.

Erreur Conséquence mesurable Correction
Deux enregistrements SPF sur le même domaine permerror, SPF invalidé pour tous les envoyeurs autorisés Fusionner en un seul v=spf1 avec tous les include:
Dépassement des 10 résolutions DNS SPF permerror silencieux dès le 11e lookup Compter les lookups (outil dédié), retirer les include inutiles
p=reject posé sans phase d’observation Emails légitimes non alignés rejetés sans préavis p=none → lecture des rapports rua → p=quarantine avec pct croissant → p=reject

source · RFC 7208 §4.6.4 (limite de résolutions) et RFC 7489 · relevé le 31/08/26

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 11e 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>

exemple pédagogique reconstruit · tous les domaines et l’adresse IP remplacés par des valeurs de documentation (exemple.fr, 192.0.2.25) · composé le 31/08/26

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é.

Exigence Gmail Yahoo Source officielle
Seuil qui déclenche le régime « gros expéditeur » 5 000 messages/jour vers des comptes Gmail personnels, effectif depuis le 1er février 2024 Même seuil de fait (régime aligné avec Google) support.google.com/mail/answer/81126
Authentification exigée SPF et DKIM sur le domaine d’envoi, DMARC publié pour le domaine SPF, DKIM, DMARC support.google.com/mail/answer/81126 · senders.yahooinc.com
Taux de plainte à ne pas dépasser 0,3 %, mesuré via Google Postmaster Tools 0,3 %, snapshot mesuré via Sender Hub support.google.com/mail/answer/81126 · senders.yahooinc.com
Désinscription en un clic Obligatoire sur tout email marketing ou en masse (en-têtes List-Unsubscribe + List-Unsubscribe-Post, RFC 8058) Obligatoire, lien visible dans le corps du message et traitement sous 2 jours ouvrés support.google.com/mail/answer/81126 · senders.yahooinc.com

source · support.google.com/mail/answer/81126 & senders.yahooinc.com · relevé le 31/08/26

Réserve — délivrabilité

Publier SPF, DKIM et DMARC lève une condition d’entrée : cela ne détermine pas où un message atterrit. La délivrabilité réelle — le placement en boîte de réception — n’est pas mesurable de l’extérieur, et aucun chiffre d’arrivée en boîte ne peut être attribué à ces trois enregistrements seuls. Aucune configuration DNS ne garantit l’arrivée en boîte de réception.

Questions fréquentes

Peut-on avoir deux enregistrements SPF si on utilise deux prestataires ?

Non. Un seul enregistrement SPF par domaine : deux enregistrements produisent un permerror et invalident SPF pour tous les envoyeurs autorisés, y compris ceux qui fonctionnaient. Les deux prestataires se déclarent par deux include: dans le même v=spf1.

DMARC en p=none protège-t-il mon domaine ?

Non. En p=none, DMARC observe et ne bloque rien : il collecte des rapports et n’applique aucune disposition. C’est une étape utile — c’est même l’étape à ne pas sauter — mais elle ne produit aucun effet de filtrage.

SPF empêche-t-il qu’on usurpe mon adresse d’expéditeur ?

Non, pas seul. SPF valide le domaine d’enveloppe (MAIL FROM) ; c’est l’alignement DMARC qui rattache la vérification à l’adresse From: affichée au destinataire, et c’est lui qui protège l’adresse visible.

Publier BIMI affichera-t-il mon logo dans les messageries ?

Pas automatiquement. BIMI suppose un DMARC déjà en application et, le plus souvent, un certificat payant. Ce n’est jamais la conséquence mécanique d’un enregistrement de plus.

Combien de temps rester en observation avant de passer à reject ?

La séquence documentée est : p=none, lecture des rapports rua, puis p=quarantine avec un pct croissant, et enfin p=reject — après plusieurs semaines de rapports propres. Il n’existe pas de durée standard applicable à tous les domaines : c’est la propreté des rapports qui commande, pas le calendrier.

⛔ Ce qu’on ne sait pas

  • La délivrabilité réelle n’est pas mesurable de l’extérieur. Le placement en boîte de réception ne peut être associé à aucun chiffre attribué à SPF, DKIM ou DMARC seuls. Cette page ne l’écrira donc jamais.
  • Le fonctionnement exact des filtres anti-spam de Gmail, Yahoo et Outlook n’est publié par aucun fournisseur. Toute description de « comment le filtre décide », au-delà de SPF, DKIM, DMARC et des rapports publiés, est de l’extrapolation — nous n’en écrivons pas.
  • Les seuils Gmail et Yahoo du tableau ci-dessus sont ceux relevés le 31/08/2026 sur les pages officielles citées. Ils ont déjà bougé en 2024 et peuvent bouger encore : à re-vérifier à la source avant toute décision technique.
  • La limite de 10 résolutions DNS SPF est fixée par la norme, mais le comportement précis de chaque résolveur en cas de dépassement partiel n’a pas été re-testé pour cette page. Le bon réflexe est de compter les lookups avec un outil dédié sur votre propre domaine, plutôt que de se fier à une affirmation générale.
  • Nous ne disposons d’aucune donnée de position pour cette page sur la requête « spf dkim dmarc » : ni Search Console ni tracker de positions n’ont été consultés au moment de sa rédaction.

Pour aller plus loin

Sources

H

Hélène Sertin

Rédaction · Newsletter Access

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