L’authentification des e-mails, ce sont trois enregistrements DNS, publiés sur votre propre domaine, qui permettent à un serveur de réception de décider si un message vient vraiment de vous. SPF nomme les serveurs autorisés à envoyer. DKIM signe chaque message pour qu’une altération se voie. DMARC dit quoi faire quand les deux premiers ne concordent pas avec l’adresse de l’en-tête From, et demande des rapports à ce sujet.
Publier les trois relevait autrefois des bonnes pratiques. Depuis février 2024, c’est une condition de remise chez les plus grands fournisseurs de messagerie, et la plupart des domaines n’ont pas fini. Sur les domaines que nous testons pour le Unspam 2026 Email Deliverability Benchmark, 93 % publient un enregistrement SPF valide et 90 % signent avec une clé DKIM qui fonctionne, mais seuls 48 % publient une politique DMARC. L’écart entre 90 et 48, c’est tout cet article.
Vous pouvez voir où en est votre propre domaine en une trentaine de secondes avec un bilan de santé e-mail gratuit, qui lit les trois enregistrements d’un coup et vous dit sur lesquels un récepteur agirait vraiment.
Les trois enregistrements répondent à trois questions différentes
Un serveur de réception ne pose pas une seule question sur votre courrier. Il en pose trois, et chaque enregistrement répond exactement à l’une d’elles.
| Enregistrement | La question à laquelle il répond | Ce que c’est |
|---|---|---|
| SPF | Ce serveur avait-il le droit d’envoyer pour ce domaine ? | Un enregistrement TXT listant les expéditeurs autorisés |
| DKIM | Ce message a-t-il été altéré, et qui l’a signé ? | Une clé publique dans le DNS, plus une signature dans l’en-tête |
| DMARC | Que faire quand les réponses ne collent pas à l’adresse From ? | Un enregistrement TXT avec une politique et une adresse de rapports |
L’ordre compte parce que DMARC n’est pas indépendant. C’est une couche de décision posée sur les deux autres, et elle n’a rien sur quoi agir tant qu’au moins l’un d’eux ne passe pas. Un domaine avec DMARC mais sans SPF ni DKIM fonctionnel a publié une instruction impossible à suivre.
SPF publie quels serveurs peuvent envoyer pour votre domaine
SPF est une liste des serveurs que vous avez autorisés, publiée comme enregistrement TXT du DNS sur votre propre domaine. Quand un serveur se connecte pour remettre du courrier en prétendant venir de vous, le récepteur consulte cette liste et vérifie si l’adresse IP qui se connecte y figure.
Un enregistrement ressemble à ceci : v=spf1 include:_spf.google.com include:sendgrid.net ~all. Chaque include délègue à la liste d’une autre organisation, et c’est ainsi que vous autorisez Google Workspace et votre plateforme marketing en même temps sans suivre vous-même leurs adresses IP.
Deux limites piègent beaucoup de monde. La première : SPF autorise au maximum dix requêtes DNS par vérification, et chaque include en dépense au moins une. Au-delà, le résultat est une erreur permanente, que la plupart des récepteurs traitent comme un échec et non comme un enregistrement absent. La seconde : SPF casse au transfert. Quand une liste de diffusion ou une adresse de renvoi retransmet votre message, le serveur qui se connecte est le leur et non le vôtre, et SPF échoue sans que vous y soyez pour rien. Cette seconde limite est précisément la raison d’être de DKIM. Notre guide sur les enregistrements SPF couvre la syntaxe et le budget de requêtes en entier. Que SPF casse au réacheminement est aussi le problème pour lequel ARC a été construit, et notre guide d’ARC explique pourquoi cette expérience prend fin.
DKIM signe le message lui-même, donc le transfert ne le casse pas
DKIM joint une signature cryptographique à chaque message sortant, produite avec une clé privée que détient votre plateforme d’envoi. Vous publiez la clé publique correspondante dans le DNS, et le récepteur s’en sert pour vérifier la signature.
Comme la signature couvre les en-têtes et le corps et non la connexion, DKIM survit au transfert. Elle prouve aussi que le message n’a pas été altéré en chemin, ce que SPF ne sait pas faire du tout. Cette combinaison en fait le plus solide des deux signaux, et celui sur lequel DMARC s’appuie le plus souvent quand votre courrier passe.
Toute plateforme d’envoi sérieuse fait tourner ses clés selon un calendrier, et le sélecteur présent dans l’en-tête est ce qui permet à un domaine de porter plusieurs clés à la fois : s1._domainkey.example.com et s2._domainkey.example.com peuvent être actifs tous les deux, et c’est ainsi qu’une rotation se fait sans trou. Un récepteur lit le sélecteur dans la signature et ne consulte que cette clé. Utilisez des clés de 2048 bits plutôt que de 1024 ; la longueur courte valide encore mais n’est plus jugée suffisante. Le format complet de l’enregistrement se trouve dans notre guide sur les signatures DKIM. Quelle longueur doit faire une clé, et comment une mise à jour la raccourcit en silence, se trouve dans notre guide de la longueur de clé DKIM.
DMARC ne fonctionne que si SPF ou DKIM s’aligne sur votre domaine From
L’alignement est la partie que la plupart des introductions sautent, et c’est là que des enregistrements qui fonctionnent échouent. DMARC ne demande pas si SPF ou DKIM a réussi. Il demande si l’un des deux a réussi pour le même domaine que votre lecteur voit dans l’en-tête From.
Votre plateforme marketing peut signer chaque message parfaitement avec son propre domaine et passer SPF sur son propre domaine d’envoi, et DMARC échouera quand même, parce qu’aucun des deux identifiants n’est le vôtre. La solution est de configurer cette plateforme pour qu’elle signe sous votre domaine, ce que toute plateforme d’envoi sérieuse permet et que beaucoup de clients n’activent jamais. L’adresse que SPF authentifie est l’expéditeur d’enveloppe et non celle que vos lecteurs voient, ce que notre guide du Return-Path couvre en entier.
Une fois que le récepteur a un résultat d’alignement, votre politique lui dit quoi faire :
p=noneveut dire ne rien faire et envoyer des rapports. C’est la position de départ, pas la destination.p=quarantineveut dire placer le courrier en échec dans le dossier spam.p=rejectveut dire le refuser à la porte.
Deux choses ont changé pour DMARC en mai 2026, et la plupart des documentations n’ont pas suivi. La RFC 9989 a remplacé la RFC 7489, faisant de DMARC une spécification de la voie des normes plutôt qu’un document informatif, et elle a retiré les balises pct, ri et rf. Si votre enregistrement porte un pct inférieur à 100 à côté de quarantine ou reject, votre application est désormais plus stricte que ce que vous aviez configuré, sans aucune modification de votre DNS. Notre guide sur les enregistrements DMARC passe en revue chaque balise.
Les fournisseurs de messagerie ont cessé de traiter DMARC comme optionnel en 2024
Tout guide qui vous dit que DMARC est recommandé mais pas obligatoire décrit le monde d’avant février 2024. Ce mois-là, Google et Yahoo ont tous deux commencé à exiger une politique DMARC des expéditeurs en masse vers leurs propres boîtes. Apple a suivi en février 2025 et Outlook.com en mai 2025.
Quatre détails méritent d’être exacts, parce qu’ils sont souvent mal rapportés :
- Le seuil de Google est de 5 000 messages par jour vers des adresses Gmail personnelles. Outlook.com utilise le même chiffre pour ses boîtes grand public. Yahoo a publiquement refusé d’en publier un, donc méfiez-vous de tout chiffre qu’on lui attribue.
p=nonesatisfait l’exigence. Les fournisseurs demandent une politique publiée, pas une application. Commencer à none est conforme, et c’est aussi la bonne façon de commencer.- La règle de Microsoft couvre le courrier grand public d’Outlook.com, pas les tenants Microsoft 365. Si vous vendez à des entreprises, cette exigence ne décrit pas vos destinataires.
- Les taux de plaintes pour spam ont leur propre seuil, 0,3 % chez Google et Yahoo, et un taux sous 0,1 % est ce que Google recommande plutôt qu’il n’exige.
L’authentification est nécessaire mais pas suffisante. Un message parfaitement authentifié finit quand même en spam si le contenu déclenche un filtre, ce qui se note à part et fait l’objet de notre guide sur les scores SpamAssassin.
Cinq façons dont ces enregistrements échouent en ayant l’air corrects
Chaque défaut ci-dessous produit un enregistrement qui paraît bon à un humain et ne fait rien chez un récepteur. Ce sont ceux autour desquels notre propre analyseur a été construit, grossièrement classés par fréquence.
Deux enregistrements SPF sur un domaine. Publier un second enregistrement TXT au lieu de modifier le premier ne les fusionne pas. Le résultat est une erreur permanente, et la plupart des récepteurs traitent une erreur permanente comme un échec et non comme une absence d’enregistrement. Un domaine, un enregistrement SPF, toujours.
Plus de dix requêtes DNS dans la chaîne SPF. Chaque include coûte au moins une requête, et le fournisseur derrière peut en dépenser plusieurs autres dans son propre enregistrement. Quatre ou cinq fournisseurs suffisent à faire sauter le budget. L’enregistrement continue de paraître court et lisible ; il cesse simplement d’être évalué en cours de route.
Une faute de frappe dans la balise sp ou np de DMARC. C’est la plus cruelle. Une politique de sous-domaine invalide jette l’enregistrement entier, y compris un p=reject impeccable. v=DMARC1; p=reject; sp=quarintine ne protège absolument rien, et un outil de vérification qui rapporte le p qu’il a réussi à lire vous dira que le domaine est verrouillé.
Rien d’aligné sur le domaine From. SPF passe sur le domaine de la plateforme, DKIM signe avec le domaine de la plateforme, les deux vérifications rapportent une réussite, et DMARC échoue quand même. Tous les résultats de vos journaux paraissent verts. C’est de loin la raison la plus fréquente pour laquelle un domaine soigneusement configuré reste un an sur p=none.
Prendre une politique p=none pour une protection. None est une instruction de ne rien faire. C’est le bon endroit pour commencer et le mauvais pour rester, et un domaine qui y est depuis deux ans publie une demande de rapports que personne ne lit.
Publiez-les dans l’ordre, parce que DMARC dépend des deux autres
La séquence ci-dessous n’est pas une préférence. L’inverser publie une politique sous laquelle il n’y a rien.
- Publiez SPF et vérifiez qu’il passe. Un enregistrement par domaine, sous les dix requêtes, terminé par
~allou-all. Deux enregistrements SPF sur un domaine, c’est une erreur permanente et non une fusion. - Activez la signature DKIM sur chaque plateforme qui envoie en votre nom. Votre ESP, votre CRM, votre support, votre outil de facturation. Chacune publie son propre sélecteur.
- Vérifiez qu’au moins l’un des deux s’aligne sur votre domaine From. C’est l’étape qu’on saute, et la sauter rend décoratif tout ce qui vient après.
- Publiez DMARC en
p=noneavec une adresse de rapports. Vous collectez des preuves, vous n’appliquez encore rien. - Lisez les rapports pendant deux à quatre semaines. Vous cherchez des expéditeurs légitimes que vous aviez oubliés, car ce sont eux qu’une politique d’application bloquerait.
- Passez à
p=quarantine, puis àp=reject. Seulement une fois que chaque source légitime passe et s’aligne.
C’est à l’étape cinq que l’outillage compte, car les rapports DMARC bruts arrivent en XML et sont quasi illisibles à la main. Nous avons comparé les options dans notre panorama des outils de surveillance DMARC, gratuits compris. Si vous voulez seulement confirmer que votre enregistrement est publié et correctement analysé, un outil de vérification DMARC gratuit suffit.
BIMI affiche votre logo dans la boîte, et presque personne n’y a droit encore
BIMI affiche le logo de votre marque à côté de vos messages dans les boîtes compatibles, et c’est la seule de ces normes que vos destinataires peuvent voir. C’est aussi la seule qui exige les autres d’abord : un domaine doit déjà être en p=quarantine ou p=reject pour qu’un récepteur montre le logo.
L’adoption est vraiment rare. 99 % des domaines que nous testons ne publient aucun enregistrement BIMI, ce qui en fait l’un des derniers moyens de se distinguer dans une boîte encombrée. Gmail exige en plus un Verified Mark Certificate, une attestation payante que la marque du logo vous appartient, et c’est la raison principale pour laquelle le chiffre reste où il est.
Traitez BIMI comme la récompense d’avoir terminé DMARC et non comme un projet à part. Si vous n’êtes pas en application, il n’y a encore rien à configurer.
Ce qu’il faut vérifier après la publication
Les enregistrements dérivent. Une plateforme est ajoutée sans mise à jour du SPF, une clé est mal tournée, quelqu’un modifie un enregistrement à la main et oublie un point-virgule. La panne est silencieuse, car rien dans votre propre flux de courrier ne vous dit qu’un récepteur s’est mis à refuser.
Quatre vérifications méritent d’être faites régulièrement :
- Les trois enregistrements s’analysent et disent ce que vous croyez. Une balise
spounpinvalide jette entièrement un enregistrement DMARC par ailleurs parfait, et un outil qui rapporte lepqu’il arrive à lire vous donnera un badge vert sur un domaine ouvert. - Chaque plateforme d’envoi s’aligne toujours. On achète de nouveaux outils, et ils ne s’authentifient pas tout seuls.
- Vos rapports DMARC arrivent toujours. Si votre adresse de rapports tombe de l’enregistrement, les rapports s’arrêtent et rien ne l’annonce.
- Le message lui-même passe toujours. Seuls 89 % des messages que nous testons passent une vérification complète de délivrabilité, 9 % récoltant un avertissement et 2 % échouant franchement, et l’authentification n’est qu’une partie de cette note.
Bien poser les trois enregistrements est le travail au plus fort effet de levier en délivrabilité, car c’est la seule partie qu’un récepteur vérifie avant de lire un seul mot de ce que vous avez écrit. Si les enregistrements dépassent ce que vous voulez garder en interne, un consultant en délivrabilité peut prendre en charge le déploiement. Sinon, lancez un test de spam gratuit sur un vrai message et lisez les résultats d’authentification à côté de ceux du contenu, c’est la façon la plus rapide de voir ce que voit un récepteur.
