SPF valide, DMARC en échec : le malentendu de l’alignement

Vous avez publié votre enregistrement SPF. Vous l’avez vérifié avec trois outils différents, tous vous répondent que la syntaxe est correcte et que vos serveurs sont bien autorisés. Vos rapports DMARC vous annoncent pourtant que 40 % de vos messages échouent, et l’échec porte justement sur SPF.

Il n’y a ni bug ni erreur de configuration. Vous venez de rencontrer l’alignement, le mécanisme qui fait toute la valeur de DMARC et que presque personne n’explique correctement.

Un email a deux expéditeurs, et vos destinataires n’en voient qu’un

C’est le point de départ, et tout le reste en découle.

Quand un message circule, il transporte deux adresses d’expéditeur distinctes, écrites à deux endroits différents.

La première est l’adresse d’enveloppe. Elle est annoncée par le serveur émetteur pendant le dialogue SMTP, avant même que le message soit transmis. Elle sert au routage et au retour des erreurs, ce qui explique qu’on la retrouve dans l’en-tête Return-Path. Aucun utilisateur ne la voit jamais.

La seconde est l’adresse affichée, celle de l’en-tête From. C’est celle que votre client lit dans sa messagerie, celle sur laquelle il fonde sa confiance.

La comparaison postale tient bien. L’enveloppe porte une adresse qui sert au facteur et au retour à l’envoyeur. La lettre à l’intérieur porte un en-tête à l’attention du lecteur. Rien n’oblige les deux à correspondre.

SPF vérifie l’enveloppe. Uniquement l’enveloppe. Il regarde l’adresse IP du serveur émetteur, la compare à la liste publiée par le domaine de l’enveloppe, et répond par oui ou par non.

Vous voyez immédiatement la faille. Un fraudeur peut publier un SPF impeccable sur serveur-du-fraudeur.com, l’utiliser comme domaine d’enveloppe, et écrire comptabilite@votreentreprise.fr dans l’en-tête From. SPF passe, parfaitement. Votre client reçoit un message frauduleux authentifié. Pendant quinze ans, l’usurpation a fonctionné exactement comme cela.

Ce que DMARC vérifie réellement

DMARC comble ce trou avec une exigence supplémentaire, et une seule : le domaine authentifié doit correspondre au domaine affiché.

Un message est conforme à DMARC lorsqu’au moins une de ces deux conditions est remplie :

SPF réussit, et le domaine de l’enveloppe s’aligne avec le domaine de l’en-tête From.

DKIM réussit, et le domaine de la signature, le champ d=, s’aligne avec le domaine de l’en-tête From.

Retenez la formulation exacte, car c’est là que tout le monde se trompe. Il ne s’agit pas de « SPF passe » mais de « SPF passe et est aligné ». Une authentification réussie sur un domaine qui n’est pas le vôtre ne vous apporte strictement rien. C’est même précisément ce que fait un fraudeur.

Deux chemins vers la conformité, un seul suffit

Bonne nouvelle, et c’est celle qui débloque la plupart des situations : les deux conditions ne sont pas cumulatives. Un message dont la signature DKIM est valide et alignée passe DMARC même si son SPF échoue lamentablement.

Cette règle a une conséquence pratique immédiate. Quand un expéditeur pose problème et que vous n’arrivez pas à aligner son SPF, ne vous acharnez pas. Faites-lui signer en DKIM avec votre domaine, et le problème disparaît.

Strict ou relâché : ce que changent adkim et aspf

Reste à définir ce que veut dire « s’aligner ». DMARC propose deux définitions, que vous choisissez avec les tags aspf pour SPF et adkim pour DKIM.

En mode relâché, la valeur par défaut, deux domaines s’alignent s’ils partagent le même domaine organisationnel. Concrètement, bounce.votreentreprise.fr s’aligne avec votreentreprise.fr. Un sous-domaine et son domaine parent sont considérés comme la même entité.

En mode strict, obtenu avec aspf=s ou adkim=s, les deux domaines doivent être identiques au caractère près. bounce.votreentreprise.fr n’est alors plus aligné avec votreentreprise.fr.

Commencez toujours en mode relâché. Le mode strict ne se justifie que dans des contextes très cloisonnés, et il casse des flux légitimes sans apporter de sécurité supplémentaire dans la grande majorité des cas.

Une nouveauté de mai 2026 sur le calcul du domaine organisationnel

La notion de domaine organisationnel vient de changer de mécanique, et c’est important si vous lisez de la documentation ancienne.

Jusqu’à la publication de DMARCbis en mai 2026, les receveurs déterminaient le domaine organisationnel en consultant la Public Suffix List, une liste externe maintenue par la communauté qui recense les suffixes publics du monde entier. Cette liste posait deux problèmes : elle vivait en dehors du DNS, et elle traitait mal les structures de domaines imbriquées.

La nouvelle norme, portée par la RFC 9989, la remplace par un parcours DNS ascendant. Le receveur interroge directement le DNS en remontant de domaine parent en domaine parent jusqu’à trouver un enregistrement DMARC valide. Le résultat est plus cohérent et ne dépend plus d’un registre externe.

Pour vous, en pratique, rien ne change dans la façon d’écrire votre enregistrement. Mais si vos sous-domaines ont un comportement d’alignement que vous ne vous expliquez pas, sachez que la règle de calcul n’est plus celle décrite dans les articles antérieurs à 2026.

Le cas qui provoque neuf échecs sur dix

Voici la situation type, celle que vous allez retrouver dans vos propres rapports.

Vous utilisez un outil de facturation, un CRM ou une plateforme de newsletter. Vous avez configuré votre adresse d’expéditeur : facturation@votreentreprise.fr. Le prestataire envoie vos messages depuis ses serveurs, avec sa propre adresse d’enveloppe, quelque chose comme bounce-42871@mail.prestataire.com.

Déroulons ce que voit le receveur.

SPF est vérifié sur mail.prestataire.com. L’enregistrement existe, l’IP est autorisée, SPF réussit. Le prestataire a fait son travail correctement.

L’alignement est ensuite vérifié. mail.prestataire.com face à votreentreprise.fr. Ces deux domaines ne partagent aucun domaine organisationnel. L’alignement échoue, y compris en mode relâché.

Résultat : SPF passe et pourtant DMARC échoue. Votre enregistrement SPF est parfait, il ne sert simplement à rien dans ce flux, parce qu’il n’est jamais consulté. C’est celui du prestataire qui l’a été.

La solution n’est pas d’ajouter le prestataire à votre SPF, ce qui ne changerait rien puisque son domaine d’enveloppe reste le sien. La solution est de lui faire signer en DKIM avec votre domaine. Tous les prestataires sérieux proposent cette configuration, généralement sous la forme de deux ou trois enregistrements CNAME à publier chez vous. Une fois en place, d=votreentreprise.fr apparaît dans la signature, l’alignement DKIM réussit, et le flux devient conforme.

Pourquoi DKIM est votre meilleur allié

Au-delà de ce cas, DKIM présente un avantage structurel que SPF n’aura jamais : il survit au transfert.

Quand un destinataire fait suivre votre message vers une autre adresse, le serveur qui retransmet n’est évidemment pas dans votre enregistrement SPF. SPF échoue donc systématiquement sur tout message transféré, et vous ne pouvez rien y faire.

La signature DKIM, elle, voyage avec le message. Tant que le contenu signé n’est pas altéré, elle reste valide après un ou plusieurs transferts.

Si vous ne deviez retenir qu’une action de cet article : assurez-vous que chacun de vos expéditeurs signe en DKIM avec votre domaine. C’est le seul chemin qui tient dans la durée.

Les quatre situations possibles

SPF aligné et valide	DKIM aligné et valide	Résultat DMARC
Oui	Oui	Conforme, situation idéale
Oui	Non	Conforme, mais fragile au transfert
Non	Oui	Conforme et robuste
Non	Non	Échec, le message sera traité selon votre politique

La troisième ligne mérite votre attention. Un expéditeur dont le SPF n’est pas aligné n’est pas un problème tant que son DKIM l’est. Beaucoup d’administrateurs perdent des semaines à essayer d’aligner un SPF qui n’a pas besoin de l’être.

Retrouver tout cela dans vos rapports

Vos rapports DMARC contiennent exactement cette information, mais ils l’exposent de façon trompeuse pour qui les découvre. Ils affichent en effet deux séries de résultats pour SPF et DKIM : les résultats bruts d’authentification, et les résultats évalués après alignement. Les deux ne disent pas la même chose, et confondre l’une avec l’autre conduit à des statistiques fausses mais crédibles.

C’est le sujet de l’article suivant : lire un rapport DMARC agrégé, ligne par ligne.

Questions fréquentes

Pourquoi mon DMARC échoue-t-il alors que mon SPF est valide ? Parce que DMARC ne se contente pas de vérifier que SPF passe. Il exige en plus que le domaine authentifié par SPF corresponde au domaine affiché à votre destinataire. Un prestataire qui envoie avec sa propre adresse d’enveloppe fait passer SPF sans jamais l’aligner sur votre domaine.

Faut-il que SPF et DKIM soient tous les deux alignés ? Non, un seul suffit. Un message dont DKIM est aligné et valide passe DMARC même si SPF échoue complètement.

Quelle est la différence entre l’alignement strict et l’alignement relâché ? En mode relâché, le mode par défaut, deux domaines s’alignent s’ils partagent le même domaine organisationnel. En mode strict, ils doivent être identiques au caractère près.

Dois-je ajouter mes prestataires à mon enregistrement SPF ? Rarement, et cela ne résout pas l’alignement. Si le prestataire envoie avec sa propre adresse d’enveloppe, votre SPF n’est jamais consulté. Faites-le plutôt signer en DKIM avec votre domaine.

Combien d’expéditeurs une entreprise a-t-elle en général ? Bien plus qu’elle ne le croit. Entre cinq et vingt pour une PME, en comptant la messagerie, le CRM, la facturation, le marketing, le support et le site web. C’est le sujet de notre article sur l’inventaire des expéditeurs.

---

Vous voulez voir l’alignement de vos propres expéditeurs plutôt que ceux d’un exemple ? Alignmarc analyse vos rapports et vous dit, en français, lequel de vos outils n’est pas aligné et pourquoi. Le premier domaine est gratuit.