Chaque e-mail porte deux adresses d’expéditeur. Vos lecteurs en voient une. SPF vérifie l’autre, et DMARC réussit ou échoue selon que les deux appartiennent au même domaine.
Celle que vos lecteurs voient est l’en-tête From. Celle que SPF vérifie est l’expéditeur d’enveloppe, que le serveur destinataire inscrit dans le message comme en-tête Return-Path au moment où il accepte la remise. Un message peut réussir SPF impeccablement sur un chemin de retour appartenant à votre plateforme d’envoi et échouer quand même à DMARC, parce que l’adresse de l’en-tête From est la vôtre et que celle qui a été authentifiée ne l’est pas.
Return-Path est l’expéditeur d’enveloppe, pas l’adresse From
SMTP comporte une enveloppe et un message, et chacun porte ses propres adresses. L’expéditeur d’enveloppe est donné dans la commande MAIL FROM au début de la transaction, avant l’envoi du moindre en-tête. L’en-tête From fait partie du message, écrit par ce qui l’a composé.
C’est le serveur destinataire qui transforme l’un en l’autre : en acceptant un message, il inscrit l’expéditeur d’enveloppe tout en haut sous forme d’en-tête Return-Path. Un Return-Path présent dans un message reçu est donc la trace de ce que le serveur émetteur a déclaré sur le fil, notée par le destinataire. L’expéditeur ne le pose pas comme en-tête, et un Return-Path ajouté par un expéditeur ne signifie rien.
Trois adresses sont couramment confondues et chacune fait un travail différent :
| Champ | Posé par | Sert à |
|---|---|---|
| Return-Path | Le destinataire, depuis MAIL FROM | SPF, et la destination des rejets |
| From | Qui compose | Ce que vos lecteurs voient, et ce que DMARC protège |
| Reply-To | Qui compose | Où part une réponse |
SPF authentifie le chemin de retour, et c’est pourquoi SPF seul n’arrête pas l’usurpation
SPF demande si le serveur qui se connecte est autorisé à envoyer pour un domaine, et le domaine qu’il emploie est celui de l’expéditeur d’enveloppe. La RFC 9989 compare RFC5321.MailFrom et jamais le nom HELO, si bien qu’un outil qui annonce un alignement SPF à partir de l’identité HELO répond à une autre question.
C’est toute la raison pour laquelle SPF à lui seul n’a jamais arrêté l’usurpation du nom affiché. N’importe qui peut envoyer un message avec MAIL FROM: bounces@a-domain-they-own.example et un en-tête From portant le nom de votre entreprise. SPF réussit, parce que l’expéditeur est bel et bien autorisé pour le domaine d’enveloppe qu’il a choisi. Le lecteur voit votre nom dans sa boîte. Rien là-dedans n’est un défaut de SPF : c’est SPF vérifiant l’identifiant qu’il a été conçu pour vérifier.
DMARC est la couche qui referme cela, en exigeant que l’identifiant authentifié se rapporte à l’identifiant visible.
DMARC exige que le domaine du chemin de retour s’aligne avec votre domaine From
L’alignement est la comparaison qu’effectue DMARC. Il ne demande pas si SPF a réussi. Il demande si SPF a réussi pour un domaine qui correspond à celui de l’en-tête From.
Votre plateforme marketing peut réussir SPF sur son propre domaine de rejets à chaque envoi, et votre résultat DMARC reste un échec du côté SPF, parce que les deux identifiants ne se rapportent pas l’un à l’autre. DKIM peut sauver le message si la plateforme signe au nom de votre domaine, et c’est souvent la seule chose qui le fasse. Sur les domaines que nous testons pour le Unspam 2026 Email Deliverability Benchmark, 48 % seulement publient une politique DMARC, et parmi ceux qui le font, un chemin de retour non aligné est l’une des raisons les plus courantes pour lesquelles un domaine reste un an en p=none.
Le symptôme visible, avant tout rapport, est la boîte de réception qui vous trahit. Gmail affiche un message comme envoyé « via » le domaine de la plateforme quand le chemin de retour ne correspond pas au domaine From, et d’autres logiciels impriment quelque chose de similaire. Si votre courrier dit « via » quelqu’un d’autre, votre chemin de retour n’est pas aligné.
L’alignement souple ne se décide pas à partir des seuls en-têtes
DMARC a deux modes d’alignement, et la différence compte quand on lit la sortie d’un outil.
- Strict signifie que les deux domaines sont identiques. Cela se décide à partir des en-têtes que vous avez sous les yeux.
- Souple, le mode par défaut, signifie que les deux partagent un domaine organisationnel. Cela ne se décide pas à partir des en-têtes, car savoir où passe la frontière organisationnelle est une question de DNS.
La RFC 9989 a remplacé la Public Suffix List par un parcours de l’arbre DNS exactement pour cette raison. Avec l’ancienne approche, un outil pouvait embarquer une copie de la liste et répondre hors ligne, au prix de se tromper chaque fois que la liste bougeait. Avec l’approche actuelle, la réponse exige de résoudre l’arbre, donc un analyseur d’en-têtes qui annonce « aligné » sans aucune requête n’a réglé que le cas strict ou bien a deviné.
Notre analyseur d’en-têtes d’e-mail règle l’alignement strict à partir des en-têtes et rapporte la relation entre les deux domaines : identiques, sous-domaine du domaine auteur, auteur lui-même sous-domaine, ancêtre commun, ou sans lien. L’alignement souple est réglé à part avec le parcours de l’arbre, car un résultat qui n’a pas été mesuré n’est pas un résultat.
Cette distinction est pratique et non tatillonne. bounces.example.com face à example.com est aligné en souple et non aligné en strict, ce qui est l’état normal d’un chemin de retour personnalisé correctement configuré, et un outil qui le signale comme un échec vous enverra réparer quelque chose qui va déjà bien.
Un chemin de retour personnalisé est la façon dont une plateforme obtient l’alignement SPF
La solution habituelle est un sous-domaine que vous déléguez à la plateforme. Vous publiez un CNAME sur quelque chose comme bounces.example.com pointant vers l’infrastructure de la plateforme, la plateforme utilise ce nom comme expéditeur d’enveloppe, et SPF réussit désormais sur un domaine qui partage votre domaine organisationnel, donc aligné en souple.
Quatre détails décident si cela fonctionne :
- Ce doit être un sous-domaine de votre domaine From. Un CNAME sur un autre domaine qui vous appartient aussi ne s’aligne avec rien.
- L’enregistrement SPF qui compte est celui du domaine du chemin de retour, pas celui de votre domaine From. C’est l’étape la plus souvent sautée, parce qu’on vérifie le mauvais enregistrement et qu’on y voit une réussite.
- La plateforme doit être configurée pour s’en servir. Publier le DNS n’est que la moitié ; la plateforme a un réglage, et un réglage laissé de côté veut dire qu’elle continue d’utiliser son propre domaine de rejets.
- Un sous-domaine hérite de votre politique DMARC par le parcours de l’arbre, sauf si vous publiez
sppour dire autre chose, il est donc couvert par l’application que vous avez mise en place.
Le guide des enregistrements SPF couvre l’enregistrement lui-même, et notre guide des enregistrements DMARC couvre la politique et ses balises.
Les rejets partent vers le chemin de retour, et nulle part ailleurs
L’autre travail de l’expéditeur d’enveloppe est d’être l’adresse à laquelle sont envoyés les rapports de non-remise. Un serveur qui ne peut pas remettre votre message envoie l’échec au chemin de retour, pas à votre adresse From et pas à Reply-To.
C’est pourquoi un chemin de retour personnalisé change qui voit les rejets. Déléguez-le à une plateforme et la plateforme les récupère, ce qui lui permet de supprimer automatiquement les adresses mortes. Pointez-le vers une boîte non surveillée de votre propre domaine et les rapports s’entassent là où personne ne les lit, et c’est ainsi qu’une liste pourrit en silence.
C’est aussi pourquoi existe le chemin de retour <>, l’expéditeur nul. Les messages de rejet eux-mêmes sont envoyés avec un expéditeur d’enveloppe vide pour qu’un rejet ne puisse pas rejeter à son tour, et un message arrivant avec un chemin de retour vide est un rapport automatique et non du courrier écrit par quelqu’un.
Comment lire le chemin de retour d’un message déjà envoyé
La vérification la plus rapide se fait sur un vrai message et non dans le DNS, car le chemin de retour n’existe qu’une fois qu’un destinataire l’a noté.
- Envoyez-vous un message via la plateforme que vous examinez, vers une boîte chez un autre fournisseur.
- Affichez les en-têtes d’origine et cherchez
Return-Path. Gmail appelle cela « Afficher l’original » ; la plupart des logiciels ont un équivalent. - Comparez son domaine au domaine From. Identique correspond à l’alignement strict, un sous-domaine de votre domaine From est le cas souple normal, un domaine sans lien signifie que SPF ne peut rien apporter à DMARC.
- Lisez
Authentication-Resultssur le même message. La propriétésmtp.mailfromest le domaine que le destinataire a réellement authentifié, ce qui fait la réponse faisant autorité quand elle est présente. - Recommencez pour chaque plateforme qui envoie en votre nom. Chacune a son propre réglage, et elles sont configurées à des moments différents par des personnes différentes.
L’alignement du chemin de retour est l’une des deux façons pour un message de satisfaire DMARC, et l’autre est DKIM, qui survit au réacheminement là où SPF ne survit pas. Notre guide de l’authentification des e-mails explique comment les trois enregistrements dépendent les uns des autres, et la panne silencieuse du côté SPF fait l’objet de notre guide du mécanisme include de SPF.
Pour voir les deux identifiants sur un vrai message, à côté de tout ce qu’un destinataire évalue, faites un test de spam gratuit.
