Un résultat de test ou un en-tête brut vient de vous annoncer dmarc=fail, et la première lecture qui vient à l’esprit est la plus inquiétante : un serveur de réception croit que votre e-mail est faux. C’est rarement l’histoire. Presque tous les échecs DMARC que j’examine sont des messages légitimes authentifiés sous le mauvais domaine. SPF s’est porté garant de l’ESP au lieu de vous. DKIM a bien vérifié, mais contre une clé partagée. Un serveur de transfert a réécrit un en-tête de trop. Le message était réel, les papiers désignaient quelqu’un d’autre.
La réponse en une phrase : DMARC échoue quand un message ne peut présenter aucun contrôle d’authentification à la fois réussi et correspondant au domaine de votre en-tête From. Le reste relève du diagnostic et de la réparation : de quoi le verdict est fait, les sept causes qui reviennent sans cesse dans les résultats de test de spam, ce qui corrige chacune, et à quel moment durcir votre politique ensuite.
Vous êtes en nombreuse compagnie, si cela peut consoler. Sur l’ensemble des contrôles passés par Unspam, 90 % des expéditeurs réussissent SPF et 88 % réussissent DKIM, mais seuls 55 % réussissent DMARC. Aucun autre maillon de la chaîne d’authentification n’échoue moitié aussi souvent, et la liste qui suit est pour l’essentiel l’anatomie de cet écart.
Ce que signifie vraiment dmarc=fail
DMARC n’inspecte ni le contenu, ni les liens, ni le volume d’envoi. Il pose exactement deux questions sur un message qui prétend venir de yourbrand.com :
- SPF a-t-il réussi, et le domaine pour lequel il a réussi est-il aligné avec le domaine From ? SPF valide l’expéditeur d’enveloppe (l’adresse Return-Path utilisée pendant la conversation SMTP), que le lecteur ne voit jamais. L’alignement signifie que ce domaine caché et votre domaine From visible concordent.
- DKIM a-t-il réussi, et le domaine signataire (le tag
d=dans la signature) est-il aligné avec le domaine From ?
Un seul résultat aligné suffit. SPF peut échouer complètement et DMARC réussir quand même si une signature DKIM alignée se vérifie, et inversement. Aucun fait de ce sujet ne rend plus de services pratiques que ce simple OU. Cela explique aussi pourquoi tant d’échecs déroutent : les deux contrôles peuvent réussir individuellement pendant que DMARC échoue, parce qu’aucun n’a réussi pour votre domaine.
DMARC ne demande jamais « l’authentification a-t-elle réussi ? » Il demande « l’authentification a-t-elle réussi pour le domaine que le lecteur voit vraiment ? »
Par défaut, l’alignement est souple (relaxed) : n’importe quel sous-domaine du même domaine organisationnel compte, donc un message signé par mail.yourbrand.com s’aligne avec un From en yourbrand.com. Votre enregistrement peut exiger un alignement strict (adkim=s, aspf=s), c’est-à-dire une correspondance exacte, ce qui est un durcissement délibéré et une cause d’échec auto-infligée très courante, comme nous le verrons. Pour une comparaison plus poussée des deux contrôles sous-jacents, voyez DMARC face à DKIM.
D’abord, identifiez la cause de votre échec
Ne corrigez pas à l’aveugle. Chaque verdict DMARC arrive avec ses preuves, à trois endroits.
Lancez un test avant l’envoi. Le test de spam gratuit d’Unspam authentifie le message exact que vous êtes sur le point d’envoyer et affiche les résultats SPF, DKIM et DMARC côte à côte, avec les domaines évalués par chaque contrôle, à côté des contrôles SpamAssassin, blacklist et contenu. C’est la seule voie qui attrape l’échec avant qu’un abonné ne le voie.
Lisez l’en-tête Authentication-Results. Sur tout message livré, le serveur de réception inscrit son verdict dans les en-têtes. Dans Gmail, ouvrez un message et choisissez « Afficher l’original ». Le résumé en haut et la ligne Authentication-Results brute racontent toute l’histoire :
Cet exemple est l’échec le plus courant sur le terrain. Les deux contrôles réussissent, et DMARC échoue quand même, parce que bounce.esp-mail.com et esp-mail.com ne s’alignent pas avec yourbrand.com. L’en-tête vous livre le diagnostic : les domaines qui suivent smtp.mailfrom= et header.d= sont ceux qui ont obtenu le pass, et aucun des deux n’est le vôtre.
Lisez vos rapports agrégés. Si votre enregistrement DMARC comporte une adresse rua, les serveurs de réception vous envoient chaque jour des résumés XML de toutes les sources qui ont envoyé sous votre domaine : les adresses IP, les volumes et la façon dont chacune s’est authentifiée. Les rapports sont le seul moyen de voir les échecs sur des messages qui ne sont jamais passés sous vos yeux, copies transférées et tentatives d’usurpation comprises.
Avant de toucher à quoi que ce soit d’autre, passez aussi votre domaine dans le DMARC checker gratuit pour confirmer que l’enregistrement lui-même est présent et syntaxiquement sain.
Les sept raisons d’un échec DMARC, et la correction de chacune
Presque tous les dmarc=fail remontent à l’une d’elles. Je les ai classées par fréquence d’apparition dans de vrais résultats de test : travaillez de haut en bas.
| # | Cause | Ce que montre l’en-tête | La correction en une ligne |
|---|---|---|---|
| 1 | L’ESP s’authentifie pour lui-même | spf=pass et dkim=pass pour les domaines de l’ESP | Activez l’authentification par domaine personnalisé |
| 2 | Un transfert a cassé SPF | spf=fail depuis une adresse IP qui n’est pas la vôtre, dkim=pass | Alignez DKIM, il survit au transfert |
| 3 | Une liste de diffusion a réécrit le message | dkim=fail (hachage du corps non concordant) | Rien de votre côté, c’est le rôle d’ARC |
| 4 | Alignement strict, expéditeur en sous-domaine | pass pour mail.yourbrand.com, échec sur l’alignement | Revenez au souple ou faites correspondre exactement |
| 5 | SPF permerror | spf=permerror | Repassez sous les 10 requêtes DNS |
| 6 | Enregistrement DMARC cassé | dmarc=none ou aucune politique vue par les outils | Un seul enregistrement valide sur l’hôte _dmarc |
| 7 | Une vraie usurpation | des adresses IP inconnues qui échouent partout | Rien, DMARC fait son travail |
1. Votre ESP s’authentifie pour lui, pas pour vous
Par défaut, la plupart des plateformes d’envoi utilisent leurs propres domaines d’infrastructure : l’expéditeur d’enveloppe ressemble à bounce.esp-mail.com pour qu’elles puissent traiter vos bounces, et la signature DKIM emploie leur clé partagée avec leur domaine dans d=. Les deux contrôles réussissent. Pour elles. Votre domaine From n’obtient aucun résultat aligné, et DMARC échoue exactement comme le montre l’en-tête ci-dessus.
La correction est le réglage que toute plateforme sérieuse propose sous un nom comme authentification par domaine personnalisé, vérification de domaine ou envoi sous votre marque : vous publiez quelques enregistrements CNAME qu’elle vous fournit, et à partir de là les messages sont signés en DKIM comme yourbrand.com (ou un sous-domaine, qui s’aligne en mode souple) et utilisent un domaine de bounce personnalisé comme bounce.yourbrand.com pour l’alignement SPF. Commencez par DKIM. Une signature DKIM alignée fait à elle seule basculer DMARC en pass, même si le versant SPF pointe encore vers l’ESP.
2. Un serveur de transfert a cassé SPF
Quand quelqu’un fait suivre automatiquement votre e-mail (une adresse universitaire qui redirige vers Gmail, un ancien domaine qui redirige vers un nouveau), le serveur de transfert le remet depuis son adresse IP, qui ne figure pas dans votre enregistrement SPF : SPF échoue. Les serveurs de transfert qui « réparent » cela en réécrivant l’expéditeur d’enveloppe vers leur propre domaine refont réussir SPF, mais pour leur domaine, ce qui casse l’alignement à la place. Dans les deux cas, la voie SPF est morte sur les messages transférés, définitivement et par construction.
Il n’y a rien à rafistoler côté SPF ici : la réparation consiste à ne plus en avoir besoin. Une signature DKIM voyage à l’intérieur du message et se vérifie quel que soit le serveur qui l’a relayé, donc un transfert propre conserve un dkim=pass aligné et DMARC réussit quand même. Si vos rapports agrégés montrent une traîne d’échecs SPF seuls depuis les plages d’adresses IP des fournisseurs de messagerie, c’est le transfert, c’est normal, et c’est précisément pour cela qu’il ne faut jamais publier une politique DMARC contraignante en s’appuyant sur le seul alignement SPF.
3. Une liste de diffusion a réécrit le message
Les listes de discussion sont la cousine plus difficile du transfert : elles ajoutent en général un tag dans l’objet, du type [members], collent un pied de page de désabonnement et renvoient le message depuis l’adresse de la liste. Ces modifications de l’objet et du pied de page changent le contenu signé, donc votre signature DKIM ne se vérifie plus. L’enveloppe de la liste casse l’alignement SPF. Les deux voies échouent sur un message que tout le monde voulait voir arriver.
Vos options sont honnêtement limitées, et je préfère le dire que de l’enrober. Les listes modernes atténuent le problème elles-mêmes, soit en réécrivant l’en-tête From vers le domaine de la liste (ce qui sort votre domaine de l’équation DMARC), soit en ajoutant un sceau ARC qui permet aux serveurs de réception de se porter garants des résultats d’authentification d’origine. De votre côté : gardez DKIM aligné pour que le transfert simple survive, et acceptez un petit résidu inoffensif d’échecs liés aux listes dans vos rapports. Si vous administrez la liste, activez ses options d’atténuation DMARC.
4. Un alignement strict là où il faut du souple
Si votre enregistrement fixe adkim=s ou aspf=s, seule une correspondance exacte de domaine compte : un message signé en DKIM par mail.yourbrand.com avec un From en yourbrand.com passe l’alignement souple mais échoue au strict. Le scénario derrière celle-ci est toujours le même. Une équipe active le mode strict par souci de durcissement, oublie que la plateforme de newsletter signe avec un sous-domaine délégué, et fabrique ses propres échecs.
Vérifiez si votre enregistrement porte adkim=s ou aspf=s (le DMARC checker affiche chaque tag). Si les domaines qui envoient légitimement pour vous comprennent un sous-domaine, revenez au souple (supprimez le tag, le souple est la valeur par défaut) ou reconfigurez l’expéditeur pour qu’il signe avec le domaine From exact. L’alignement strict ne vaut la peine qu’une fois que vos rapports montrent une longue série propre, avec chaque source exactement alignée.
5. SPF permerror : la limite de dix requêtes DNS
Les enregistrements SPF sont évalués avec un budget strict : les mécanismes qui déclenchent des requêtes DNS (include, a, mx, redirect, exists) ne peuvent pas dépasser dix au total, comptés récursivement à travers chaque include imbriqué. Empilez assez d’outils (un ESP, un CRM, un service d’assistance, un vieil include dont personne ne se souvient) et l’évaluation s’interrompt sur un permerror. Un permerror ne pourra jamais devenir un résultat aligné, donc la voie SPF s’éteint pour tous les serveurs de réception, sur tous les messages.
Passez votre domaine dans le SPF checker, qui compte les requêtes pour vous, puis retirez les include des services que vous n’utilisez plus et envisagez de consolider ou d’aplatir le reste. Pendant que vous y êtes, assurez-vous que l’enregistrement se termine par ~all ou -all : un +all annonce au monde entier que n’importe qui peut envoyer en votre nom, ce qui ruine tout l’intérêt de la pile d’authentification complète.
6. L’enregistrement DMARC lui-même est cassé
Une part surprenante des échecs se produit avant l’évaluation du moindre message, dans l’enregistrement DNS :
- Deux enregistrements DMARC. Une fusion de domaines, ou deux équipes qui en ajoutent chacune un, laisse plusieurs enregistrements TXT sur
_dmarc. La norme est sans pitié : un serveur de réception qui trouve plus d’un enregistrement n’en applique aucun. - Le mauvais hôte. L’enregistrement doit vivre sur
_dmarc.yourbrand.com, pas à la racine et pas surdmarc.sans le tiret bas. - Les glissements de syntaxe. L’enregistrement doit commencer par
v=DMARC1, les tags se séparent par des points-virgules, et les adressesruaont besoin du préfixemailto:. Une coquille commep=noninvalide la politique.
Collez votre domaine dans le DMARC checker et réparez ce qu’il signale. Si vous préférez ne pas assembler la chaîne à la main, le DMARC record generator gratuit en construit une valide à partir de menus déroulants.
7. Quelqu’un usurpe réellement votre domaine
Une fois les six erreurs de configuration écartées, ce qui reste dans vos rapports agrégés (des adresses IP inconnues, souvent géographiquement improbables, qui échouent aux deux contrôles sur un volume que vous n’avez jamais envoyé) est DMARC en train de faire son travail : attraper la falsification. C’est l’échec que vous voulez.
La seule correction à appliquer ici est la retenue : n’assouplissez pas votre politique parce que les rapports font peur. Confirmez que les sources ne sont pas les vôtres (le shadow IT existe vraiment, cette adresse IP inconnue est parfois le système de facturation que quelqu’un a branché en 2019), puis laissez votre politique p=quarantine ou p=reject avaler les faux. Cette protection est la raison pour laquelle la réputation d’expéditeur et l’application de DMARC vont de pair.
« No DMARC record found » : la correction en cinq minutes
Les outils et les pages postmaster signalent cela quand il n’existe aucun enregistrement TXT sur _dmarc.yourdomain.com. À strictement parler, ce n’est l’échec d’aucun message en particulier, mais cela a cessé d’être un manque cosmétique en 2024, quand Gmail et Yahoo ont commencé à exiger des expéditeurs d’e-mails en masse (Google place la limite à environ 5 000 messages par jour vers Gmail) la publication d’au moins une politique DMARC minimale, avec SPF ou DKIM aligné sur le domaine From. Microsoft applique la même exigence aux domaines grand public d’Outlook depuis mai 2025. Aujourd’hui, l’absence d’enregistrement signifie limitation de débit, mise en spam ou rejet pur et simple chez les plus grands fournisseurs de messagerie, ce qui produit exactement les e-mails non délivrés que l’on passe ensuite des journées à traquer.
L’enregistrement de départ tient sur une ligne, publiée en TXT sur l’hôte _dmarc :
v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com
Il n’applique rien, satisfait le minimum exigé par les fournisseurs de messagerie et commence à collecter les rapports agrégés dont vous avez besoin pour tout le reste de ce guide. Générez le vôtre avec le DMARC record generator cité plus haut si vous voulez que la syntaxe soit gérée pour vous.
Ce que les serveurs de réception font d’un message en échec
La conséquence d’un dmarc=fail est celle que demande votre propre enregistrement, appliquée à la discrétion du serveur de réception :
| Politique | Ce que vous avez publié | Ce qui arrive en général aux messages en échec |
|---|---|---|
p=none | Surveillance seule | Livré normalement, l’échec est enregistré et vous est signalé |
p=quarantine | Traiter avec méfiance | Envoyé dans le dossier spam |
p=reject | Le refuser | Rejeté pendant la remise, le lecteur ne le voit jamais |
Deux notes comptent en pratique. Les serveurs de réception peuvent passer outre votre politique dans les deux sens, et un tag pct vous permet de n’appliquer quarantine ou reject qu’à une part échantillonnée des messages en échec, le temps de prendre confiance. Plus important, p=none n’est pas sans conséquence. Les filtres de Gmail et d’Outlook pèsent les résultats d’authentification comme un signal de réputation, quelle que soit la politique publiée : un flux qui échoue chroniquement à DMARC voit son placement en boîte de réception se dégrader progressivement même si chaque message est techniquement livré.
Comment corriger les échecs DMARC, étape par étape
Voici l’ordre qui fonctionne, que vous débloquiez une seule campagne en échec ou un domaine entier :
- Publiez ou réparez l’enregistrement, en
p=none, avec une adresserua. Vérifiez-le avec le DMARC checker. L’application vient en dernier, pas en premier. - Inventoriez vos expéditeurs. Laissez les rapports agrégés tourner de deux à quatre semaines, puis listez chaque service qui envoie sous votre domaine : ESP, messages transactionnels, CRM, service d’assistance, facturation, l’imprimante du bureau.
- Alignez d’abord DKIM partout. Pour chaque expéditeur légitime, activez la signature avec domaine personnalisé afin que
d=porte votre domaine. DKIM survit au transfert : c’est l’alignement qui continue de fonctionner après que le message a quitté vos mains. - Alignez SPF ensuite. Configurez des domaines de bounce personnalisés là où la plateforme le permet, et repassez votre enregistrement sous la limite de dix requêtes avec le SPF checker.
- Vérifiez par message, pas par domaine. Envoyez un vrai message depuis chaque plateforme dans le test de spam et contrôlez les trois verdicts, avec le DKIM checker à côté. Les enregistrements peuvent être parfaits pendant qu’un flux précis signe encore avec la mauvaise clé.
- Serrez la politique cran par cran. Quand les rapports montrent vos sources légitimes en réussite, passez à
p=quarantine(éventuellement échantillonné avecpct), observez, puisp=reject. Cette dernière étape est tout l’intérêt de l’exercice : c’est ce qui empêche réellement vos clients de recevoir de fausses factures à votre nom.
Vérifiez le verdict avant vos abonnés
Un échec DMARC découvert dans un rapport agrégé vous a déjà coûté une campagne. Le test de spam gratuit d’Unspam affiche le même verdict avant l’envoi : SPF, DKIM et DMARC évalués sur votre message exact, avec les domaines vus par chaque contrôle, à côté du score de spam, des blacklists et des contrôles de contenu, en 30 secondes environ, sans inscription. S’il annonce pass et aligné, envoyez la conscience tranquille. S’il annonce dmarc=fail, vous savez désormais laquelle des sept causes corriger. Aucune ne prend plus d’un après-midi.
