Aller au contenu
DMARC
← Blog

DMARC échoue alors que SPF passe : comprendre l'alignement

Par Thomas · RSSI virtuel · 20 août 2026

C'est le symptôme le plus déroutant qu'un rapport DMARC puisse produire : pour le même lot de messages, la ligne affiche spf=pass — l'authentification SPF a réussi — et pourtant le verdict DMARC est fail. À première lecture, c'est une contradiction pure : comment un contrôle peut-il réussir et échouer à la fois ? Beaucoup de remédiations s'enlisent exactement là, des heures durant, à traquer une faute dans un enregistrement SPF qui, en réalité, fonctionne parfaitement.

Il n'y a pourtant ni bug ni paradoxe. SPF et DMARC ne vérifient tout simplement pas la même chose. SPF valide un domaine technique, invisible pour le destinataire : celui de l'enveloppe du message, le fameux Return-Path. DMARC, lui, exige que ce domaine validé corresponde — soit « aligné » avec — l'adresse que le destinataire voit réellement dans son client de messagerie. Un SPF qui passe pour le mauvais domaine ne vaut rien aux yeux de DMARC : c'est toute la logique de l'alignement, et c'est elle, presque toujours, qui explique le symptôme.

Cet article — socle du dépannage DMARC — déroule le raisonnement par le symptôme : ce que SPF valide réellement, ce que l'alignement ajoute, les trois situations types qui produisent un spf=pass inutile, la façon de les repérer dans un rapport agrégé, puis les corrections qui rétablissent un alignement durable. Condition non négociable avant tout passage à p=reject.

Le symptôme : un « pass » qui ne compte pas

Dans un rapport agrégé, chaque ligne décrit un lot de messages vus par un fournisseur destinataire — et elle contient en réalité deux verdicts SPF qui ne répondent pas à la même question. Le premier, le résultat brut de l'authentification, dit : « ce domaine a bien autorisé cette IP à émettre ». Le second, le résultat évalué par DMARC, dit : « ce pass profite-t-il au domaine affiché dans le From: ? ». Le symptôme classique ressemble à ceci :

<policy_evaluated>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>
…
<auth_results>
  <spf>
    <domain>bounces.routeur-mail.net</domain>
    <result>pass</result>
  </spf>
</auth_results>

En bas, SPF passe — mais pour bounces.routeur-mail.net. En haut, DMARC compte SPF comme un échec, parce que les messages affichaient From: exemple.fr et que routeur-mail.net n'a aucun lien avec exemple.fr. Le pass est parfaitement réel ; il profite simplement au mauvais domaine. Toute la suite de l'article tient dans cette phrase.

Ce que SPF valide : l'enveloppe, pas l'adresse affichée

Un e-mail transporte deux identités d'expéditeur, et la confusion entre les deux est la racine du problème. La première vit dans l'enveloppe SMTP : c'est le MAIL FROM, aussi appelé Return-Path ou adresse de rebond — celle à laquelle les serveurs renvoient les notifications d'échec de livraison. Elle est invisible dans le client de messagerie. La seconde est l'en-tête From:, celui que le destinataire lit. Rien, dans les standards, n'oblige les deux à coïncider ; dans l'envoi industrialisé, elles coïncident rarement.

SPF ne regarde que la première. Le serveur destinataire prend le domaine du MAIL FROM, interroge son enregistrement TXT SPF et vérifie que l'adresse IP de connexion y est autorisée. Si oui : spf=pass. À aucun moment SPF ne consulte l'adresse affichée. Ce n'est pas un oubli de conception : SPF est antérieur à DMARC et visait la falsification d'enveloppe, pas l'usurpation visuelle. La conséquence est brutale : un fraudeur qui envoie depuis un domaine qu'il contrôle — enveloppe à lui, enregistrement SPF irréprochable — tout en affichant From: exemple.fr obtient un spf=pass sans discussion. L'authentification réussit, l'usurpation aussi. Le partage des rôles entre les trois mécanismes est posé dans SPF, DKIM et DMARC expliqués.

L'alignement, l'exigence que DMARC ajoute

DMARC comble précisément ce trou, et le principe général de DMARC se résume à cela : rattacher l'authentification technique à l'adresse qu'un humain voit réellement. Le verdict DMARC est un pass si — et seulement si — au moins un des deux mécanismes réussit et que le domaine qu'il a validé s'aligne avec le domaine du From:. Pour SPF, le domaine comparé est celui du MAIL FROM ; pour DKIM, c'est le d= de la signature.

L'alignement existe en deux modes, réglés par deux balises de l'enregistrement DMARC. En mode relaxed (aspf=r, adkim=r — les valeurs par défaut, rarement écrites), il suffit que les deux domaines partagent le même domaine organisationnel : bounce.exemple.fr s'aligne avec exemple.fr. Depuis DMARCbis, ce domaine organisationnel se détermine par le DNS Tree Walk — la remontée de l'arbre DNS — et non plus par la Public Suffix List. En mode strict (aspf=s, adkim=s), l'égalité doit être exacte : bounce.exemple.fr ne s'aligne plus avec exemple.fr.

Un enregistrement typique n'a donc rien d'exotique :

v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr

Les modes relaxed s'appliquent implicitement. Et un point capital, souvent manqué : DMARC n'exige pas que les deux mécanismes s'alignent. Un seul suffit. Un SPF non aligné accompagné d'un DKIM aligné donne un dmarc=pass — c'est même, on le verra, la clé de la plupart des corrections.

Trois cas types derrière le symptôme

Un spf=pass non aligné n'arrive presque jamais par hasard. Trois configurations concentrent l'essentiel de ce que montrent les rapports.

Cas 1 : le routeur qui passe SPF avec son propre domaine. Le grand classique. Une plateforme d'envoi — Mailchimp, Brevo, SendGrid, Mailjet — expédie la newsletter d'exemple.fr avec, par défaut, une enveloppe posée sur son propre domaine : MAIL FROM bounces.routeur-mail.net. Le routeur maîtrise son SPF, l'IP est autorisée, spf=pass — pour routeur-mail.net. Le From: affiche exemple.fr : aucun alignement possible, les deux domaines sont étrangers l'un à l'autre. Si, en plus, la signature DKIM par défaut est posée en d=routeur-mail.net, l'échec est complet : tout est authentifié, mais rien ne l'est au nom du bon domaine.

Cas 2 : la redirection qui réécrit l'enveloppe. Un message parfaitement aligné au départ est envoyé à une adresse qui redirige — l'alias d'un ancien salarié, une boîte universitaire renvoyée vers une messagerie personnelle. Le serveur qui retransmet se retrouve à émettre depuis une IP absente du SPF de l'expéditeur d'origine ; pour éviter un rejet, beaucoup réécrivent l'enveloppe à leur propre nom (le mécanisme SRS). Résultat : spf=pass, mais pour le domaine du redirecteur — non aligné, encore. La mécanique complète est détaillée dans pourquoi la redirection casse SPF. La nuance qui sauve : la signature DKIM, elle, voyage avec le message et survit tant que le contenu n'est pas modifié — d'où l'importance du « un seul suffit ».

Cas 3 : le sous-domaine mal aligné. L'organisation envoie avec MAIL FROM sur newsletter.exemple.fr et From: sur exemple.fr. En mode relaxed, tout va bien : même domaine organisationnel. Mais si l'enregistrement impose aspf=s, le pass devient non aligné du jour au lendemain. Variante plus sournoise : un domaine technique séparé, exemple-mailing.fr, choisi il y a des années « pour isoler les envois ». Celui-là ne s'alignera jamais avec exemple.fr, même en relaxed : ce sont deux domaines organisationnels distincts.

Repérer le pass non aligné dans un rapport agrégé

Nul besoin de refaire ici la théorie des rapports — la lecture des rapports agrégés DMARC la couvre champ par champ. Pour ce symptôme précis, un seul réflexe suffit : comparer le domaine du header_from avec le domaine attaché au résultat SPF. Si le résultat est pass mais que les deux domaines diffèrent — et ne partagent pas le même domaine organisationnel —, la ligne décrit un pass non aligné, compté comme un échec côté DMARC.

La lecture gagne à être faite par source. Une IP de routeur qui n'affiche que des pass non alignés signale une configuration par défaut jamais personnalisée (cas 1). Des lignes éparses, à faible volume, portant des domaines SPF de fournisseurs d'accès ou d'universités trahissent des redirections (cas 2). Et un basculement soudain de tout un flux, d'aligné vers non aligné, accompagne souvent un changement de balise aspf ou une migration de plateforme (cas 3). Le symptôme est identique dans les trois cas ; le remède, lui, dépend du diagnostic.

Les corrections : domaine de retour personnalisé et DKIM aligné

Le domaine de retour personnalisé. Pour le cas du routeur, la correction porte un nom chez tous les fournisseurs sérieux : custom return-path, bounce domain, domaine d'enveloppe. Le principe : créer un sous-domaine dédié — bounce.exemple.fr — pointé par CNAME vers l'infrastructure du routeur. L'enveloppe des envois devient MAIL FROM bounce.exemple.fr : le SPF du routeur continue de faire passer l'IP, mais le pass profite désormais à un sous-domaine d'exemple.fr, aligné en mode relaxed. Quelques enregistrements DNS, aucune modification du contenu des messages.

La signature DKIM alignée. La correction la plus robuste est ailleurs : faire signer les messages en d=exemple.fr, via les clés ou les CNAME que la plateforme fournit à la configuration du domaine. Un DKIM aligné rend le verdict DMARC indépendant du sort de l'enveloppe : il survit aux redirections, ne dépend d'aucune réécriture SRS, et suffit à lui seul à produire dmarc=pass. C'est pourquoi la doctrine tient en une ligne : DKIM aligné en priorité, SPF aligné en ceinture de sécurité — et les deux quand la plateforme le permet, ce qui est aujourd'hui la norme.

Reste le cas du mode strict : avant d'imposer aspf=s ou adkim=s, l'inventaire des sous-domaines d'envoi s'impose, faute de quoi le durcissement du mode fabrique lui-même des pass non alignés. Le mode relaxed, valeur par défaut, couvre la grande majorité des besoins réels.

Ce que l'alignement change pour p=reject

Tant que la politique reste à p=none, un pass non aligné ne coûte rien : les messages arrivent, les rapports s'accumulent, le symptôme reste académique. À p=reject, la même ligne devient du courrier refusé. Chaque source légitime encore non alignée au moment du durcissement se transforme en incident de délivrabilité — factures qui n'arrivent plus, notifications RH silencieusement rejetées.

Le critère de passage est donc simple à énoncer : chaque source légitime doit produire au moins un pass aligné, DKIM de préférence, avant que la politique ne se durcisse. Les redirections ordinaires franchissent ce filtre grâce à DKIM ; le cas récalcitrant reste les listes de diffusion, qui modifient le contenu — cassant DKIM — tout en réécrivant l'enveloppe — désalignant SPF. Pour la transition elle-même, DMARCbis fournit un mode test explicite (t=y), successeur de l'ancien pct disparu du standard, qui permet d'annoncer une politique stricte tout en signalant aux destinataires une phase d'essai.

En résumé

spf=pass et dmarc=fail sur la même ligne, ce n'est ni un bug ni une contradiction : SPF a validé le domaine de l'enveloppe, et DMARC constate que ce domaine ne correspond pas au From: affiché. Le pass existe, mais il profite au mauvais domaine. Trois configurations produisent l'essentiel du symptôme — le routeur resté sur son enveloppe par défaut, la redirection qui réécrit le MAIL FROM, le sous-domaine ou domaine cousin mal aligné — et deux corrections en viennent à bout : le domaine de retour personnalisé, qui ré-aligne SPF, et la signature DKIM posée sur le d= du domaine, qui garde le verdict robuste jusque dans les redirections. Un seul mécanisme aligné suffit à DMARC ; les avoir tous les deux est la marge de sécurité qui autorise un p=reject serein.

Le diagnostic ne réclame pas d'ouvrir un seul fichier XML : une analyse DMARC gratuite du domaine met en évidence, source par source, les pass qui ne profitent pas au bon domaine et l'état réel de l'alignement. La création d'un compte permet ensuite de suivre, rapport après rapport, la montée en alignement de chaque source — jusqu'au jour où le passage à p=reject n'est plus une prise de risque, mais une formalité.

Guides liés

À propos de l'auteur

Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.