SPF, DKIM et DMARC expliqués aux dirigeants d'entreprise

SPF, DKIM et DMARC sont 3 enregistrements DNS qui indiquent au reste d'Internet quels serveurs peuvent envoyer des e-mails pour votre domaine et que faire des messages qui échouent à ces contrôles. SPF liste les expéditeurs autorisés, DKIM ajoute une signature cryptographique à chaque message, et DMARC relie les deux à l'adresse que les destinataires voient réellement dans le champ From, tout en fixant une politique en cas d'échec.

Sans eux, n'importe qui peut envoyer un message indiquant From: billing@yourcompany.com, et de nombreux fournisseurs de messagerie n'ont guère de raison d'en douter. Correctement configurés, ils font échouer l'authentification d'un message falsifié, qui peut alors être rejeté ou classé en spam avant que votre client ne le lise.

La bonne nouvelle : ces 3 enregistrements sont visibles dans le DNS, vous pouvez donc vérifier les vôtres en quelques minutes avec les commandes ci-dessous.

SPF : qui peut envoyer pour votre domaine

SPF (Sender Policy Framework, RFC 7208) est un enregistrement TXT sur votre domaine qui liste les serveurs et services autorisés à envoyer des e-mails pour celui-ci. Un enregistrement typique ressemble à ceci :

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

C'est la terminaison qui compte le plus :

• -all (fail) : tout ce qui n'est pas listé n'est pas autorisé.
• ~all (softfail) : tout ce qui n'est pas listé est suspect.
• ?all (neutral) : l'enregistrement n'exprime aucun avis, ce qui ne donne presque rien aux destinataires.
• +all : tous les serveurs d'Internet peuvent envoyer en votre nom. Ce n'est jamais correct.

SPF a aussi une limite stricte : un destinataire qui évalue votre enregistrement peut effectuer au maximum 10 requêtes DNS pour des mécanismes comme include, a, mx et redirect (RFC 7208, section 4.6.4). Chaque nouvel outil marketing ajoute un include, et dès que le total dépasse 10, SPF renvoie une erreur au lieu d'un succès.

DKIM : une signature sur chaque message

Avec DKIM (DomainKeys Identified Mail, RFC 6376), le serveur d'envoi signe chaque message avec une clé privée. La clé publique correspondante se trouve dans le DNS sous un nom de sélecteur, ce qui permet aux destinataires de confirmer que le message n'a pas été modifié et qu'il a été signé par quelqu'un qui détient votre clé.

Chaque service qui envoie pour vous (votre fournisseur de messagerie, votre CRM, votre outil de facturation) devrait signer avec son propre sélecteur. L'enregistrement DNS ressemble à :

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

DKIM échoue en silence. Les e-mails partent quand même sans signature, et personne ne s'en aperçoit jusqu'à ce que les messages commencent à finir en spam ou qu'un fournisseur durcisse ses règles.

DMARC : la politique qui relie le tout

DMARC est désormais défini dans la RFC 9989, publiée en mai 2026, qui remplace l'ancienne RFC 7489. Il vérifie si SPF ou DKIM a réussi pour un domaine qui correspond (qui est aligné) à l'adresse From visible, et indique aux destinataires que faire lorsque ni l'un ni l'autre ne réussit :

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

• p=none : surveillance uniquement. Les messages en échec sont distribués normalement, vous recevez simplement des rapports.
• p=quarantine : les messages en échec doivent être traités comme suspects, généralement placés en spam.
• p=reject : les messages en échec doivent être refusés.

L'adresse rua reçoit les rapports agrégés des grands fournisseurs de messagerie. Ces rapports montrent toutes les sources qui envoient des e-mails en votre nom, y compris celles que vous avez oubliées et celles qui ne sont pas les vôtres.

Comment vérifier votre propre domaine

Lancez ces commandes depuis n'importe quel terminal (remplacez example.com par votre domaine) :

dig +short TXT example.com | grep spf1
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

Pour DKIM, il vous faut le nom du sélecteur. Ouvrez n'importe quel e-mail envoyé par votre entreprise, affichez la source du message d'origine et cherchez DKIM-Signature: et sa valeur s=. Les mêmes en-têtes affichent aussi Authentication-Results: avec spf=pass, dkim=pass et dmarc=pass, ou les échecs.

Ce qu'il faut vérifier :

1. Exactement un enregistrement SPF (2 enregistrements v=spf1 cassent complètement SPF).
2. Une terminaison SPF en ~all ou -all, et non ?all ou +all.
3. Une signature DKIM sur les e-mails de chaque service qui envoie pour vous.
4. Un enregistrement DMARC existant, avec une adresse rua que quelqu'un lit réellement.
5. Un plan pour passer de p=none à p=quarantine ou p=reject.

Erreurs courantes et comment les corriger

2 enregistrements SPF. Souvent oubliés après un changement de fournisseur. Fusionnez-les en un seul.

Trop de requêtes. Supprimez les services que vous n'utilisez plus et remplacez les includes par les plages précises lorsque votre fournisseur le permet.

Expéditeurs oubliés. Un outil de newsletter ou un help desk qui envoie sans DKIM échouera à DMARC dès que vous l'appliquerez. Lisez d'abord vos rapports DMARC pendant quelques semaines, puis activez DKIM pour chaque source légitime.

Rester indéfiniment en p=none. La surveillance est la bonne première étape, mais p=none demande aux destinataires de distribuer malgré tout les messages falsifiés. Lorsque les rapports montrent que tout le courrier légitime passe, passez à p=quarantine, puis à p=reject.

Domaines parqués et inutilisés. Un domaine qui n'envoie jamais d'e-mails peut tout de même être usurpé. Publiez v=spf1 -all et un enregistrement DMARC avec p=reject.

Ces enregistrements comptent aussi pour la délivrabilité. Gmail, Yahoo et Outlook les exigent désormais des expéditeurs à gros volume, ce que nous détaillons dans les exigences de Gmail et Yahoo pour les expéditeurs. Ils constituent aussi une couche de défense contre les arnaques aux fausses factures décrites dans comment fonctionne la compromission de messagerie professionnelle.

Une courte liste de contrôle

• Un seul enregistrement SPF, terminé par ~all ou -all, sous 10 requêtes.
• Signature DKIM activée pour chaque service qui envoie en votre nom.
• DMARC publié, avec des rapports envoyés à une boîte surveillée.
• Politique qui évolue vers p=reject dès que les rapports sont propres.
• Domaines parqués verrouillés avec -all et p=reject.

Comment Datahorses vous aide

L'authentification des e-mails fait partie des domaines que nous surveillons chaque jour depuis l'extérieur, avec vos domaines, vos certificats et votre site web. Lorsqu'un enregistrement SPF change, qu'un sélecteur DKIM disparaît ou que DMARC est affaibli, un spécialiste l'examine et vous recevez les enregistrements exacts à corriger. La liste complète figure dans ce que nous surveillons, avec la raison pour laquelle nous n'avons besoin d'aucun accès à vos systèmes. Pour une vue d'ensemble, lisez ce qu'est la surveillance de la surface d'attaque externe.