SPF, DKIM et DMARC : comment les trois fonctionnent ensemble

exemple.fr.  IN TXT
  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

DKIM : la signature qui prouve l'intégrité

DKIM (DomainKeys Identified Mail) adopte une autre approche. Le serveur d'envoi signe chaque message avec une clé privée ; le destinataire récupère la clé publique correspondante dans le DNS du domaine signataire et vérifie la signature. Si elle est valide, deux choses sont prouvées : le message n'a pas été altéré en transit, et il a bien été signé par le détenteur de la clé de ce domaine.

selector1._domainkey.exemple.fr.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkq... (clé publique)"

DKIM survit bien mieux au transfert que SPF, car la signature voyage avec le message. Mais — et c'est le piège que DMARC corrige — une signature DKIM valide prouve seulement que quelque domaine a signé le message. Elle n'exige pas, à elle seule, que ce domaine soit celui du From:.

La faille que les deux laissent ouverte

Voici l'attaque que SPF et DKIM, isolément, n'arrêtent pas. Un attaquant enregistre mechant.com, lui configure un SPF et un DKIM impeccables, et envoie un courrier qui passe les deux contrôles — pour mechant.com. Puis il met From: pdg@exemple-entreprise.fr dans l'en-tête. SPF passé (pour l'enveloppe, mechant.com). DKIM passé (signé par mechant.com). Pourtant le lecteur voit l'adresse du PDG de l'entreprise usurpée. Les deux couches sont au vert, et l'usurpation passe. Il faut quelque chose qui relie l'authentification au domaine visible. Ce quelque chose, c'est DMARC.

DMARC : l'alignement relie le tout

DMARC ajoute une règle décisive par-dessus SPF et DKIM : l'alignement. Un message passe DMARC seulement s'il passe SPF ou DKIM et que le domaine authentifié correspond au domaine du From:.

Rejouons l'attaque avec DMARC en place. Le courrier de l'attaquant passe SPF et DKIM pour mechant.com — mais mechant.com ne correspond pas à exemple-entreprise.fr dans le From: : l'alignement échoue, donc DMARC échoue, et la politique publiée (idéalement p=reject) refuse le message. Ce même contrôle d'alignement est ce qui rend DMARC plus fort que la somme de ses parties. Pour la vue d'ensemble fondamentale, lire qu'est-ce que DMARC.

Il existe deux formes d'alignement :

• Alignement SPF — le domaine du Return-Path correspond au domaine du From:.
• Alignement DKIM — le domaine signataire (d=) correspond au domaine du From:.

DMARC n'a besoin que d'un seul alignement (et passage) pour authentifier le message. En pratique, l'alignement DKIM est la cible la plus fiable, car il survit au transfert là où SPF échoue. Il reste de rares cas où un relais réécrit le message et casse les deux — certaines listes de diffusion, notamment ; pour ceux-là, un mécanisme complémentaire nommé ARC prend le relais, et son rôle est expliqué dans un guide dédié.

Pourquoi les trois sont nécessaires

Une configuration robuste utilise chaque couche pour ce qu'elle fait de mieux :

• SPF déclare les serveurs d'envoi légitimes et donne au destinataire un premier contrôle rapide.
• DKIM prouve l'intégrité et l'origine, et continue de fonctionner à travers les transferts et les listes de diffusion.
• DMARC relie les deux au domaine visible, dit aux destinataires quoi faire en cas d'échec, et — surtout — renvoie les rapports qui révèlent chaque source se réclamant du domaine.

En retirer une laisse un trou : SPF sans DMARC ne protège pas le From: ; DKIM sans DMARC n'impose pas l'alignement ; DMARC sans SPF/DKIM fonctionnels n'a rien à aligner.

Les mettre dans l'ordre

La bonne séquence de déploiement suit les dépendances. Publier d'abord SPF et DKIM, et s'assurer que les sources légitimes passent et s'alignent. Puis publier DMARC en p=none pour collecter les rapports, corriger les sources non alignées qu'ils révèlent, et enfin monter la politique vers quarantine puis reject. On déroule cette progression pas à pas dans atteindre p=reject sans casser ses emails. Et pour visualiser la syntaxe exacte à publier à chaque palier, nos exemples d'enregistrements DMARC commentés vont du plus prudent au plus strict.

Un exemple concret : suivre un message

La théorie s'éclaire plus vite avec un cas concret. Imaginons un CRM qui envoie un reçu en tant que facturation@exemple-entreprise.fr depuis les serveurs du prestataire CRM. Voici comment les trois couches évaluent ce message :

1. SPF vérifie le domaine d'enveloppe (Return-Path) contre l'enregistrement publié. La plupart des plateformes tierces utilisent leur propre domaine de rebond pour l'enveloppe : SPF passe donc — mais pour le domaine du CRM, pas pour celui de l'expéditeur. C'est un passage SPF techniquement valide qui ne fait rien pour DMARC, car il n'est pas aligné avec le From:.
2. DKIM vérifie la signature. Si le CRM a été configuré pour signer avec d=exemple-entreprise.fr — généralement via un CNAME fourni par le prestataire — la signature se vérifie contre la clé publique publiée dans le DNS de l'entreprise, et le domaine signataire est bien le sien.
3. L'alignement est l'étape décisive. SPF s'est-il aligné ? Seulement si le domaine d'enveloppe correspondait à exemple-entreprise.fr, ce qui n'est généralement pas le cas pour un tiers. DKIM s'est-il aligné ? Oui — d=exemple-entreprise.fr correspond au domaine du From:.
4. Verdict DMARC. DMARC n'a besoin que d'un seul passage aligné. DKIM aligné et passé : le message passe DMARC — même si SPF ne s'est pas aligné du tout. Le reçu est délivré et de confiance.

Cet exemple explique une règle qui surprend beaucoup d'équipes : l'alignement DKIM est le cheval de trait des déploiements réels. Les expéditeurs tiers alignent rarement SPF (leur enveloppe est la leur), mais peuvent presque toujours être amenés à aligner DKIM via un domaine de signature aux couleurs du client. Ainsi, à la lecture des rapports agrégés, une source affichant DKIM aligné est une source réglée ; une source en échec sur les deux alignements est la prochaine tâche.

Le constat se fait dans les en-têtes

Pas besoin d'un labo pour observer les trois couches à l'œuvre : chaque message reçu porte le verdict. Il suffit d'ouvrir les en-têtes complets d'un email et d'y chercher la ligne ajoutée par le serveur destinataire, généralement nommée Authentication-Results. Elle donne le résultat SPF avec le domaine d'enveloppe vérifié, le résultat DKIM avec le domaine signataire, et le verdict DMARC final. Lire ainsi quelques messages réels — un venant du domaine de l'entreprise, un d'un expéditeur tiers, une newsletter — rend la logique d'alignement tangible comme aucun schéma : l'identifiant évalué par chaque couche apparaît noir sur blanc, et avec lui la raison exacte du verdict DMARC. C'est aussi le premier réflexe, le plus rapide, quand un message isolé se comporte mal.

Trois erreurs qui cassent l'empilement

Même avec les trois enregistrements publiés, ce sont toujours les mêmes détails qui font tomber l'édifice :

• SPF qui dépasse dix résolutions DNS. Trop d'include: empilés et SPF renvoie un PermError — au-delà de la limite, l'évaluation s'arrête et le contrôle échoue d'un bloc. Face à cette erreur, notre guide dédié sur la limite des dix lookups SPF détaille la marche à suivre, à commencer par la consolidation des include:.
• DKIM mal aligné. Une signature valide ne suffit pas : il faut que le domaine signataire (d=) corresponde au From:. La signature par défaut d'une plateforme partagée (d=plateforme.com) passe DKIM mais ne s'aligne pas — c'est la cause n°1 d'un DMARC qui échoue alors que « tout est vert ».
• Confondre strict et relaxed. En alignement relaxed (adkim=r/aspf=r), un sous-domaine d'envoi suffit ; en strict (s), il faut une correspondance exacte. Passer en strict sans avoir vérifié que les sources signent bien sur le domaine racine casse du courrier légitime.

Et DMARCbis dans tout ça ?

En mai 2026, DMARCbis (RFC 9989) a modernisé DMARC — sans toucher au principe d'alignement décrit ici. SPF et DKIM gardent exactement le même rôle. Côté DMARC, la balise pct disparaît (remplacée par t=y pour le mode test), une nouvelle balise np couvre les sous-domaines inexistants, et le DNS Tree Walk remplace la Public Suffix List pour déterminer le domaine organisationnel. Autrement dit : l'empilement SPF + DKIM + DMARC reste valide tel quel — DMARCbis le précise, il ne le réécrit pas. Pour le détail des nouveautés, voir qu'est-ce que DMARC.

Les trois couches d'un coup d'œil

Reste à situer un domaine sur les trois couches. Notre analyseur gratuit vérifie SPF, DKIM et DMARC ensemble et montre exactement où sont les failles — y compris si les sources s'alignent réellement, pas seulement si les enregistrements existent. La comparaison avec la posture de tout un secteur est possible dans l'Observatoire DMARC, où l'on voit que l'alignement — pas l'existence des enregistrements — est ce qui distingue les domaines vraiment protégés.

Et quand vient le moment de combler ces failles, Thomas, le RSSI virtuel, identifie chaque source d'envoi, génère les enregistrements SPF, DKIM et DMARC précis à publier (balises DMARCbis comprises), et guide le domaine jusqu'à l'application complète. Analyser un domaine ou commencer ici.