SPF, DKIM et DMARC expliqués à ceux qui gèrent des sites web

L’e-mail a été conçu dans un monde où tout le monde faisait confiance à tout le monde. L’adresse From d’un message est une ligne de texte que l’expéditeur tape lui-même ; rien dans le protocole d’origine ne la vérifie. Trois enregistrements DNS, ajoutés au cours des vingt dernières années, permettent au propriétaire d’un domaine de dire qui a le droit d’envoyer en son nom et ce que les destinataires doivent faire de tout le reste. Ensemble, ils font la différence entre « n’importe qui peut écrire à vos clients en se faisant passer pour vous » et « personne ne le peut ».

La plupart des domaines qui échouent à un audit Perimetry échouent d’abord ici, et la correction ne coûte que dix minutes dans l’interface DNS.

Les trois enregistrements, un paragraphe chacun

SPF (Sender Policy Framework) est un enregistrement TXT sur votre domaine qui liste les serveurs autorisés à envoyer des e-mails pour lui : votre messagerie, votre outil de newsletter, le service d’envoi des e-mails de votre site. Le serveur destinataire regarde l’adresse qui s’est connectée à lui, la compare à la liste, et obtient un résultat : réussite, échec, échec atténué (« soft fail ») ou neutre.

DKIM (DomainKeys Identified Mail) est une signature. Votre serveur d’envoi signe chaque message sortant avec une clé privée ; la clé publique correspondante est publiée dans le DNS sous un sélecteur, par exemple selector1._domainkey.votredomaine.fr. Le destinataire récupère la clé et vérifie que le message n’a pas été modifié et qu’il vient bien d’un serveur qui détient votre clé.

DMARC (Domain-based Message Authentication, Reporting and Conformance) est la politique qui relie les deux autres. Elle dit : « si un message prétend venir de mon domaine et ne réussit ni SPF ni DKIM d’une façon qui correspond à l’adresse From, alors faites ceci : rien, le mettre en quarantaine, ou le rejeter. » Elle donne aussi aux destinataires une adresse où envoyer des rapports quotidiens, pour que vous voyiez qui envoie en votre nom.

Sans DMARC, SPF et DKIM ne sont que des indications. Un destinataire qui constate un échec SPF sur un message sans politique DMARC le livre en général quand même, avec peut-être un score de spam un peu plus élevé. Avec une politique DMARC en p=reject, le même message est refusé.

Ce qui ne va pas, dans l’ordre où nous le voyons

Aucun enregistrement DMARC. C’est le constat le plus fréquent sur les domaines des petites entreprises. Le domaine peut avoir un SPF et un DKIM parfaits, n’importe qui peut quand même l’usurper, car aucune politique ne dit aux destinataires d’agir sur les résultats.

DMARC avec p=none. C’est le bon point de départ, car vous recevez des rapports sans rien changer à la distribution. C’est le mauvais endroit où rester. Une politique p=none ne protège rien ; elle observe seulement. Beaucoup de domaines ont été mis à none il y a des années par un administrateur bien intentionné et n’en ont jamais bougé.

Un SPF qui se termine par ?all ou ~all au lieu de -all. Le dernier mécanisme d’un enregistrement SPF dit quoi faire des expéditeurs absents de la liste. -all signifie échec. ~all signifie échec atténué, que la plupart des destinataires traitent comme « livrer, mais le noter ». ?all signifie neutre : « je n’ai pas d’avis », ce qui revient à ne pas avoir de SPF du tout. Avec DMARC en place, ~all est acceptable car c’est DMARC qui tranche ; sans lui, seul -all a du poids.

Un SPF qui dépasse 10 requêtes DNS. Chaque include:, a, mx, redirect= et exists: d’un enregistrement SPF coûte une requête DNS, et le destinataire abandonne au-delà de dix. L’enregistrement renvoie alors une erreur permanente, que DMARC traite comme un échec. Cela arrive sans bruit quand une entreprise ajoute un quatrième ou un cinquième service d’envoi ; l’include de chaque fournisseur peut lui-même en contenir plusieurs. Perimetry compte les requêtes de façon récursive et indique le total.

Un include mort. Votre SPF liste encore un fournisseur que vous n’utilisez plus depuis trois ans. Si l’enregistrement de ce fournisseur disparaît, le vôtre renvoie une erreur. Si le fournisseur est racheté ou réattribue ses adresses, vous avez autorisé un inconnu.

Pas de DKIM. Beaucoup de messageries n’activent DKIM que si vous le demandez, en ajoutant deux ou trois enregistrements CNAME qu’elles vous donnent. Sans lui, un transfert casse SPF (le serveur qui transfère n’est pas dans votre liste) et le message échoue à DMARC.

Les enregistrements à publier

Remplacez les noms entre chevrons. Chaque ligne est un enregistrement DNS distinct.

SPF

Un seul enregistrement TXT sur le domaine principal, qui liste uniquement les services qui envoient réellement pour vous :

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

Règles simples : un seul enregistrement SPF par domaine, jamais deux. Retirez tous les services que vous n’utilisez plus. Restez sous dix requêtes ; le rapport Perimetry en donne le nombre. Si vous n’y arrivez pas, demandez aux fournisseurs leurs plages d’adresses IP et utilisez des mécanismes ip4:, qui ne coûtent aucune requête.

Le générateur SPF gratuit écrit cet enregistrement à partir des services que vous cochez et compte ses requêtes ; le vérificateur SPF montre ce que coûte un enregistrement publié, include par include, et explique les erreurs comme permerror: too many DNS lookups.

DKIM

Votre messagerie vous donne les enregistrements. Ils ressemblent en général à ceci :

selector1._domainkey.votredomaine.fr.  CNAME  selector1-votredomaine-fr._domainkey.provider.net.
selector2._domainkey.votredomaine.fr.  CNAME  selector2-votredomaine-fr._domainkey.provider.net.

Activez ensuite la signature dans la console du fournisseur. Faites de même pour chaque service qui envoie en votre nom : newsletter, facturation, support. Chacun aura son propre sélecteur. Les clés doivent faire 2048 bits ; Perimetry estime la longueur de la clé à partir de l’enregistrement publié et signale les clés de 1024 bits.

Pour trouver le sélecteur d’un fournisseur, cherchez s= dans l’en-tête DKIM-Signature d’un message envoyé, puis vérifiez la clé avec le vérificateur DKIM gratuit.

DMARC

Commencez en mode surveillance :

_dmarc.votredomaine.fr.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr; fo=1"

Lisez les rapports agrégés pendant deux à quatre semaines. Chaque expéditeur légitime doit y apparaître comme réussi. Corrigez ceux qui échouent (en général un service oublié à qui il manque DKIM). Passez ensuite en quarantaine, puis en rejet :

_dmarc.votredomaine.fr.  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@votredomaine.fr; sp=reject; adkim=s; aspf=r"

_dmarc.votredomaine.fr.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@votredomaine.fr; sp=reject; adkim=s; aspf=s"

sp=reject applique la politique aux sous-domaines, que les attaquants préfèrent parce que personne ne les surveille. Les marqueurs d’alignement adkim et aspf règlent la rigueur avec laquelle le domaine de signature ou du SPF doit correspondre au domaine From ; le mode strict est préférable une fois que tout fonctionne.

Le générateur DMARC gratuit construit ces enregistrements réglage par réglage, et le vérificateur DMARC lit un enregistrement publié balise par balise, y compris l’autorisation des adresses de rapports externes.

Les domaines qui n’envoient jamais d’e-mails

Un domaine parqué, une variante de marque, un domaine produit qui ne sert qu’à un site : ils n’envoient rien, ils peuvent donc tout refuser. Publiez les trois enregistrements dans leur forme la plus stricte et ajoutez un MX nul, qui indique au monde que le domaine ne reçoit pas non plus d’e-mails :

variante-marque.fr.         MX   0 .
variante-marque.fr.         TXT  "v=spf1 -all"
_dmarc.variante-marque.fr.  TXT  "v=DMARC1; p=reject; sp=reject"
*._domainkey.variante-marque.fr.  TXT  "v=DKIM1; p="

Perimetry vérifie exactement cette configuration sur les domaines sans enregistrement MX et signale un domaine qui n’envoie rien mais reste ouvert.

Deux enregistrements facultatifs qui valent la peine

MTA-STS indique aux serveurs d’envoi que vos serveurs de messagerie gèrent TLS et qu’ils doivent refuser de livrer sur une connexion non chiffrée. C’est un enregistrement DNS plus un petit fichier de politique servi en HTTPS à l’adresse https://mta-sts.votredomaine.fr/.well-known/mta-sts.txt.

TLS-RPT donne aux expéditeurs une adresse où signaler les échecs TLS :

_smtp._tls.votredomaine.fr.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@votredomaine.fr"

Aucun des deux n’empêche l’usurpation, mais tous deux ne coûtent presque rien et apparaissent dans un rapport Perimetry comme des constats de faible gravité quand ils manquent.

Comment Perimetry lit ces enregistrements

L’audit résout l’enregistrement SPF, suit chaque include et redirect de façon récursive, compte les requêtes et signale les erreurs de syntaxe, les includes morts et les boucles. Il teste plus de cinquante sélecteurs DKIM courants (ceux de Google, Microsoft, Mailchimp, SendGrid, Postmark, Brevo, Amazon SES et d’autres) et estime la longueur de chaque clé trouvée. Il analyse l’enregistrement DMARC marqueur par marqueur, vérifie que les adresses de rapport sur d’autres domaines ont l’enregistrement d’autorisation requis, et compare la politique à la configuration réelle de la messagerie du domaine. Le rapport se termine par les enregistrements exacts à publier dans votre situation, pas par un modèle générique.