DKIM vs SPF vs DMARC n’est pas un choix entre des solutions concurrentes : les trois standards répondent à des questions différentes et ne fonctionnent qu’ensemble. SPF liste les serveurs autorisés à envoyer des e-mails pour le domaine d’enveloppe ; DKIM joint une signature produite avec une clé publiée sous un domaine ; DMARC exige qu’au moins l’un des deux réussisse pour un domaine correspondant à l’adresse From: visible, et publie la politique du propriétaire du domaine ainsi que les adresses auxquelles envoyer les rapports.
Vue d’ensemble
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Spécification | RFC 7208 (2014) | RFC 6376 (2011), RFC 8301, RFC 8463 | RFC 9989, 9990, 9991 (mai 2026), qui remplacent la RFC 7489 |
| Question traitée | Cette IP peut-elle envoyer pour le domaine d’enveloppe ? | Ce domaine a-t-il signé ce contenu, sans modification ? | Un domaine authentifié correspond-il au domaine From:, et que faire sinon ? |
| Identité vérifiée | MAIL FROM (Return-Path) et HELO | Le domaine d= dans DKIM-Signature | Le domaine de l’en-tête From: |
| Emplacement | TXT sur le domaine | TXT sur selector._domainkey.domain | TXT sur _dmarc.domain |
| Résiste au transfert simple | Non (l’IP du serveur de transfert n’est pas listée) | Oui, si le message n’est pas modifié | Oui, grâce à DKIM |
| Résiste aux listes de diffusion qui modifient les messages | Non | Non (le corps ou les en-têtes signés changent) | Seulement si la liste réécrit From: ou si le serveur destinataire fait confiance à ARC |
| Limites strictes | 10 termes nécessitant une requête DNS par évaluation, 2 requêtes vides | RSA d’au moins 1024 bits (2048 recommandés) ; rsa-sha1 interdit | Parcours de l’arborescence DNS en 8 requêtes au plus |
| Effet à lui seul | Résultat uniquement ; les serveurs destinataires décident | Résultat uniquement ; les serveurs destinataires décident | Politique du propriétaire du domaine : none, quarantine, reject |
| Rapports | Aucun | Aucun | Rapports agrégés XML (rua), rapports d’échec (ruf) |
Fonctionnement de chacun
SPF est évalué pendant la session SMTP : le serveur destinataire prend le domaine de l’expéditeur d’enveloppe (ou celui de HELO pour les rebonds), récupère son enregistrement TXT et compare l’IP qui se connecte aux termes ip4, ip6, a, mx et include listés. Le résultat est pass, fail (-all), softfail (~all), neutral, none ou une erreur. Chaque include, a, mx, ptr, exists et redirect coûte une requête DNS, et au-delà de 10, le résultat devient permerror (RFC 7208 §4.6.4), ce qui casse SPF pour tous les e-mails du domaine.
DKIM hache le corps canonicalisé (bh=) et les en-têtes listés (h=), puis les signe avec la clé privée du domaine. Le serveur destinataire récupère la clé publique dans un enregistrement TXT dont le nom est formé du sélecteur s= et du domaine d= (par exemple google._domainkey.github.com), puis vérifie la signature. La RFC 8301 interdit rsa-sha1 et exige des clés d’au moins 1024 bits ; la RFC 8463 ajoute ed25519-sha256, généralement publié à côté d’une signature RSA, car la prise en charge par les vérificateurs reste incomplète.
DMARC intervient après les deux : il réussit lorsque SPF réussit pour un domaine aligné sur From:, ou lorsqu’une signature DKIM est vérifiée pour un domaine aligné sur From:. L’alignement est en mode relaxed par défaut (même domaine organisationnel : mail.example.com est donc aligné sur example.com), ou en mode strict avec aspf=s et adkim=s.
Le script ci-dessous lit des enregistrements réels (20 octobre 2026, dig 9.10.6 et OpenSSL 3.6.5).
echo "== SPF: google.com and its include"
dig +short TXT google.com | grep "v=spf1"
dig +short TXT _spf.google.com
echo "== DMARC: google.com and github.com"
dig +short TXT _dmarc.google.com
dig +short TXT _dmarc.github.com
echo "== DKIM: key size behind two github.com selectors"
for sel in google pf2023; do
printf '%s: ' "$sel"
dig +short TXT "$sel._domainkey.github.com" | tr -d '" \n' | sed 's/.*p=//' \
| openssl base64 -d -A | openssl pkey -pubin -inform DER -noout -text | head -1
done
== SPF: google.com and its include
"v=spf1 include:_spf.google.com ~all"
"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56 ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all"
== DMARC: google.com and github.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"
"v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@github.com; ruf=mailto:dmarc@github.com; fo=1"
== DKIM: key size behind two github.com selectors
google: Public-Key: (2048 bit)
pf2023: Public-Key: (1024 bit)
Trois détails méritent l’attention. L’enregistrement SPF de Google se termine par ~all (softfail) alors que sa politique DMARC est reject : lorsque DMARC est appliqué, c’est le résultat DMARC qui décide, et le qualificateur SPF compte donc peu. GitHub publie encore pct=100, une balise que la RFC 9989 a supprimée ; les serveurs destinataires ignorent les balises inconnues et 100 était la valeur par défaut, elle est donc sans effet. Enfin, l’un des sélecteurs de GitHub utilise encore une clé de 1024 bits, le minimum qu’autorise la RFC 8301. L’analyseur d’authentification des e-mails effectue les mêmes vérifications pour n’importe quel domaine.
L’alignement décide du résultat
Le tableau présente des flux d’envoi typiques pour un message portant From: news@example.com.
| Flux | SPF | DKIM | DMARC |
|---|---|---|---|
Votre propre serveur, qui signe en tant que example.com | pass, aligné | pass, aligné | pass |
Prestataire d’envoi d’e-mails avec son propre domaine de rebond, qui signe en tant que example.com | pass pour le domaine du prestataire, non aligné | pass, aligné | pass (DKIM) |
| Prestataire qui signe uniquement avec son propre domaine | pass, non aligné | pass, non aligné | fail |
| Transféré tel quel par une règle de boîte aux lettres | fail (IP du serveur de transfert) | pass, aligné | pass (DKIM) |
| Une liste de diffusion ajoute un pied de page ou une étiquette dans l’objet | fail ou non aligné | fail (condensat du corps) | fail, sauf si From: est réécrit ou si ARC est jugé fiable |
From: usurpé, envoyé depuis le serveur d’un tiers | fail ou none | none | fail, politique appliquée |
La troisième ligne correspond à l’erreur de déploiement la plus courante : un expéditeur réussit SPF et DKIM, mais échoue à DMARC, car aucun des deux domaines authentifiés n’est le vôtre. Configurez chaque prestataire pour qu’il signe avec une clé placée sous votre domaine (généralement un CNAME vers la clé du prestataire), et utilisez un domaine de rebond personnalisé si vous voulez que SPF soit aligné lui aussi.
Transfert, listes de diffusion et ARC
SPF authentifie le dernier saut, si bien que tout transfert le casse ; les schémas de réécriture de l’expéditeur (Sender Rewriting Schemes) réparent SPF pour le propre domaine du serveur de transfert, mais ne l’alignent jamais. DKIM authentifie le contenu : il résiste donc aux relais qui laissent le message intact, et échoue lorsque les listes ajoutent des pieds de page ou des étiquettes. ARC (RFC 8617, statut expérimental) permet à un intermédiaire de sceller les résultats d’authentification qu’il a constatés, et les serveurs destinataires qui font confiance à l’auteur de ce sceau peuvent accepter le message malgré l’échec DMARC ; le visualiseur de chaîne ARC affiche cette chaîne. La faiblesse restante est le rejeu DKIM : un message valablement signé peut être renvoyé à de nouveaux destinataires, un problème qu’un groupe de travail de l’IETF traite dans ses Internet-Drafts DKIM2.
Ce qu’exigent les fournisseurs de messagerie
Depuis le 1er février 2024, Gmail exige de tout expéditeur SPF ou DKIM, un DNS direct et inverse valide, TLS et un taux de spam signalé inférieur à 0,3 %. Les expéditeurs qui envoient 5000 messages par jour ou plus vers des comptes Gmail personnels doivent en outre disposer de SPF et de DKIM, d’un enregistrement DMARC (p=none suffit), d’un From: aligné sur SPF ou DKIM, et du désabonnement en un clic (RFC 8058) pour les e-mails marketing. Yahoo a introduit des règles équivalentes au même moment. Microsoft a appliqué les mêmes seuils à Outlook.com à partir du 5 mai 2025 et rejette les e-mails non conformes avec 550 5.7.515. Les logos BIMI exigent en plus une politique DMARC à quarantine ou reject.
La RFC 9989 (mai 2026) a fait passer DMARC sur la voie de normalisation (Standards Track) et a modifié l’enregistrement : pct, rf et ri disparaissent, t=y remplace pct=0 pour les tests, np définit une politique pour les sous-domaines inexistants, psd signale les domaines de suffixe public, et un parcours de l’arborescence DNS remplace la Public Suffix List pour trouver le domaine organisationnel.
À quoi sert chacun
- SPF : autorisez vos propres serveurs sortants et les prestataires qui utilisent votre domaine comme adresse de rebond ; publiez
v=spf1 -allsur les domaines et sous-domaines qui n’envoient jamais d’e-mails. - DKIM : signez tous les e-mails sortants avec votre propre domaine, y compris ceux envoyés via des prestataires ; effectuez une rotation des sélecteurs au moins une fois par an et remplacez les clés de 1024 bits par des clés de 2048 bits.
- DMARC : collectez d’abord les rapports, puis appliquez la politique ; ajoutez
np=reject(ousp=reject) pour que des attaquants ne puissent pas utiliser des sous-domaines inventés. - Domaines parqués :
v=spf1 -all,v=DMARC1; p=reject;et aucun sélecteur DKIM. - La protection du transport et celle du contenu sont des problèmes distincts : utilisez MTA-STS pour TLS entre serveurs, et S/MIME ou OpenPGP pour la signature de bout en bout.
Notes de migration
- Recensez les expéditeurs à l’aide des rapports agrégés DMARC en
p=nonependant deux à quatre semaines ; chaque source légitime doit présenter un DKIM aligné, un SPF aligné, ou les deux. - Corrigez DKIM en premier : activez la signature avec votre propre domaine chez chaque prestataire, publiez des clés de 2048 bits (le générateur d’enregistrements DKIM les découpe en chaînes de 255 caractères) et vérifiez avec le débogueur DKIM.
- Réduisez SPF sous 10 requêtes en supprimant les mécanismes include inutilisés ; ne l’aplatissez en plages d’adresses IP que si vous pouvez les tenir à jour automatiquement.
- Appliquez progressivement :
p=quarantineavect=ypour observer, puisp=quarantine, puisp=reject; veillez à continuer de recevoir les rapportsrua. - Protégez les sous-domaines avec
spounp, et publiez des enregistrements nuls sur chaque domaine qui ne doit pas envoyer d’e-mails.
Références
- RFC 7208, SPF (§4.6.4, limites de requêtes)
- RFC 6376, DKIM, RFC 8301, mise à jour cryptographique de DKIM, RFC 8463, Ed25519 pour DKIM
- RFC 9989, DMARC, RFC 9990, rapports agrégés, RFC 9991, rapports d’échec
- RFC 8617, ARC
- RFC 8058, désabonnement en un clic
- Google : consignes pour les expéditeurs d’e-mails
- Microsoft : renforcement des exigences de l’écosystème e-mail pour les expéditeurs à fort volume