SPF, DKIM et DMARC sont trois enregistrements DNS distincts qui travaillent ensemble pour authentifier vos emails : SPF autorise une liste de serveurs à envoyer en votre nom, DKIM signe cryptographiquement le contenu du message pour prouver qu'il n'a pas été modifié, et DMARC relie les deux en imposant qu'au moins l'un des deux soit aligné avec le domaine affiché à vos destinataires — et en décidant quoi faire si ce n'est pas le cas.
Pris séparément, aucun des trois ne protège vraiment votre domaine. C'est leur combinaison qui fait la différence entre un email qui arrive en boîte de réception et un email qui atterrit en spam, ou pire, qui permet à quelqu'un d'usurper votre nom de domaine sans que personne ne le remarque.
SPF : qui a le droit d'envoyer
SPF (Sender Policy Framework) répond à une question unique : « ce serveur a-t-il le droit d'envoyer des emails pour ce domaine ? ». La réponse est publiée en DNS sous forme d'un enregistrement TXT qui liste des adresses IP, des serveurs MX, ou des domaines tiers à inclure (comme votre fournisseur d'emailing).
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Le serveur receveur compare l'adresse IP de l'expéditeur à cette liste. Si elle n'y figure pas, le message est marqué suspect (softfail, ~all) ou rejeté (fail strict, -all), selon la fin de l'enregistrement.
La limite de SPF : il ne vérifie que l'adresse d'enveloppe (Return-Path), pas l'en-tête From que voit réellement votre destinataire. Un attaquant peut donc passer SPF avec son propre domaine tout en affichant le vôtre dans l'en-tête From — SPF seul ne l'en empêche pas.
DKIM : prouver que le contenu n'a pas été modifié
DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque email envoyé, calculée à partir d'une clé privée détenue par l'expéditeur. La clé publique correspondante est publiée en DNS sous la forme selecteur._domainkey.votredomaine.com. Le serveur receveur récupère cette clé et vérifie que la signature correspond bien au contenu reçu.
Contrairement à SPF qui autorise des adresses IP, DKIM authentifie le contenu lui-même : même si le message transite par un relais intermédiaire, la signature reste valide tant que le corps et les en-têtes signés ne sont pas modifiés en chemin.
La limite de DKIM : comme SPF, il ne garantit rien sur l'en-tête From affiché. Un message peut porter une signature DKIM parfaitement valide... pour un domaine différent de celui que voit votre destinataire.
DMARC : la politique qui relie les deux
DMARC (Domain-based Message Authentication, Reporting and Conformance) ne réinvente rien : il exploite les résultats de SPF et DKIM, mais ajoute une exigence décisive — l'alignement. Pour que DMARC valide un message, il faut qu'au moins un des deux (SPF ou DKIM) réussisse et que le domaine authentifié corresponde à celui affiché dans l'en-tête From.
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@exemple.com
DMARC ajoute aussi deux choses que SPF et DKIM n'ont pas : une politique explicite (p=none/quarantine/reject, que faire des messages non alignés) et un mécanisme de rapport (rua=, qui vous informe de qui envoie des emails avec votre domaine — légitimement ou non).
Pourquoi il faut les trois
- SPF seul : protège contre l'envoi direct non autorisé, mais pas contre l'usurpation de l'en-tête From.
- DKIM seul : protège l'intégrité du contenu, mais pas contre l'usurpation de l'en-tête From.
- DMARC seul : n'authentifie rien — il a besoin qu'au moins SPF ou DKIM soit configuré et aligné pour fonctionner.
C'est la combinaison des trois qui ferme la boucle : SPF et/ou DKIM authentifient, DMARC impose que cette authentification corresponde à ce que voit réellement votre destinataire, et sanctionne les emails qui ne passent pas ce test.