SPF, DKIM et DMARC expliqués simplement

Le champ « De » d’un e-mail peut afficher n’importe quoi. Le protocole de messagerie date d’une époque où personne ne pensait aux expéditeurs falsifiés, et il ne vérifie rien de lui-même. C’est pour cela qu’existent SPF, DKIM et DMARC : trois enregistrements dans le DNS de ton domaine qui permettent aux serveurs destinataires de savoir si un e-mail vient vraiment de toi. Sans eux, tes e-mails finissent en spam, ou quelqu’un d’autre envoie des e-mails en ton nom.

SPF : qui a le droit d’envoyer pour ton domaine ?

SPF (Sender Policy Framework) est une liste des serveurs autorisés à envoyer des e-mails pour ton domaine. C’est un enregistrement TXT dans ton DNS, par exemple :

example.com.  TXT  "v=spf1 include:_spf.google.com include:mailgun.org ~all"

Le serveur destinataire regarde de quel serveur vient l’e-mail et le compare à cette liste. include: intègre la liste d’un prestataire, comme ton hébergeur de messagerie ou ton outil de newsletters. La fin décide de ce qui arrive à tous les autres : ~all signifie « suspect », -all signifie « rejeter ».

Bon à savoir :

• Un domaine a exactement un enregistrement SPF. Deux enregistrements comptent comme une erreur, même si chacun est correct pris isolément.
• SPF ne vérifie pas le « De » visible, mais l’adresse d’expéditeur sur l’enveloppe de l’e-mail (le « Return-Path »). Les logiciels de messagerie la cachent généralement.
• Dix requêtes DNS au maximum : chaque include: compte, y compris ceux imbriqués. Avec assez de services, tu atteins vite cette limite.
• +all laisse n’importe quel serveur tout envoyer et rend SPF inutile.

DKIM : une signature qui voyage avec l’e-mail

DKIM (DomainKeys Identified Mail) signe numériquement chaque e-mail sortant. Le serveur d’envoi calcule une signature à partir de parties de l’en-tête et du corps et l’écrit dans l’en-tête DKIM-Signature. Tu publies la clé publique correspondante dans ton DNS sous un nom de ton choix (le « sélecteur ») :

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Le serveur destinataire récupère la clé et vérifie si la signature correspond. Si c’est le cas, l’e-mail n’a pas été modifié en chemin et vient d’un serveur qui possède la clé privée du domaine.

Un avantage par rapport à SPF : la signature voyage avec l’e-mail. Si quelqu’un transfère ton message, elle reste valable tant que le contenu ne change pas.

DMARC : la règle qui relie le tout

SPF et DKIM ont une faille : ils vérifient des domaines que le destinataire ne voit jamais. Un e-mail frauduleux peut passer SPF pour arnaqueur.example et afficher quand même From: banque.example.

DMARC comble cette faille. Il exige qu’au moins l’un des deux contrôles réussisse et corresponde au domaine du « De » visible. Cette correspondance s’appelle l’alignement. DMARC décide aussi de ce qui arrive aux e-mails qui échouent :

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none : observer uniquement, ne rien bloquer.
• p=quarantine : déplacer les e-mails suspects en spam.
• p=reject : refuser les e-mails suspects.
• rua= : une adresse pour des rapports quotidiens sur les serveurs qui envoient des e-mails en ton nom.

Commence avec p=none et lis les rapports pendant quelques semaines. Tu repères ainsi les services oubliés dans SPF ou DKIM avant de passer à quarantine ou reject.

Pourquoi c’est désormais obligatoire

Depuis février 2024, Gmail et Yahoo exigent des expéditeurs de gros volumes (chez Gmail, plus de 5 000 messages par jour) qu’ils utilisent SPF et DKIM, publient un enregistrement DMARC d’au moins p=none, proposent la désinscription en un clic et gardent les plaintes pour spam à un niveau bas. Microsoft a introduit des règles similaires pour Outlook.com en 2025.

Les petits expéditeurs y gagnent aussi : les e-mails qui passent SPF, DKIM et DMARC finissent beaucoup moins souvent en spam, et personne ne peut facilement abuser de ton domaine pour du phishing.

Comment vérifier tes e-mails

Le plus simple est d’envoyer un vrai e-mail à une adresse de test et de regarder ce que le serveur destinataire a noté. Il écrit le résultat dans l’en-tête Authentication-Results, par exemple :

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounce.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Le mail tester de TossPost le fait pour toi : tu reçois une adresse de test, tu y envoies ta newsletter ou ton e-mail d’inscription et tu obtiens un rapport avec une note de 0 à 10. Il montre si SPF, DKIM et DMARC réussissent, s’ils correspondent au domaine de l’expéditeur et si les enregistrements DNS de ton domaine sont complets.

Erreurs fréquentes

• Un service oublié : l’outil de newsletters ou de support envoie des e-mails, mais il manque dans SPF et ne signe pas avec DKIM.
• Deux enregistrements SPF, parce qu’un nouveau service a demandé le sien. Regroupe les entrées include: dans un seul enregistrement.
• Trop de requêtes DNS dans SPF à cause d’entrées include: imbriquées.
• DKIM configuré, clé non publiée : le prestataire signe, mais l’enregistrement sous selecteur._domainkey manque.
• DMARC passé trop tôt à reject : des e-mails légitimes sont refusés parce qu’un service n’est pas encore aligné.

En bref

SPF dit quels serveurs peuvent envoyer. DKIM signe chaque e-mail. DMARC exige que les deux correspondent à l’expéditeur visible et décide de ce qui se passe sinon. Avec les trois en place, tes e-mails arrivent et ton domaine est protégé contre les abus.

Vérifie si tes e-mails passent les contrôles