SPF, DKIM et DMARC : ce que chaque enregistrement prouve

SPF, DKIM et DMARC sont trois enregistrements TXT dans le DNS de votre domaine qui permettent à un serveur de réception de décider si un message se réclamant de vous vient réellement de vous. Ce sont des mécanismes distincts, ils répondent à des questions distinctes, ils échouent de façons différentes — et l’ordre dans lequel vous les posez compte davantage que ne l’admettent la plupart des guides.

Que prouvent réellement SPF, DKIM et DMARC ?

Trois affirmations différentes, vérifiées indépendamment.

SPF est la liste des serveurs autorisés à envoyer du courrier pour votre domaine. Le destinataire prend l’adresse IP du serveur émetteur et demande si votre domaine l’a autorisée.

DKIM est une signature cryptographique portant sur le message. Le serveur émetteur signe un ensemble d’en-têtes et le corps avec une clé privée ; le destinataire récupère la clé publique correspondante dans votre DNS et vérifie que rien de ce qui a été signé n’a changé en route.

DMARC est la politique posée au-dessus. Elle indique aux destinataires quoi faire lorsque les deux premières échouent, et ajoute une exigence qu’aucune des deux ne formule seule : le domaine authentifié par SPF ou DKIM doit correspondre à celui qu’un humain voit dans l’en-tête From:. C’est tout l’enjeu. Sans cela, n’importe qui peut passer SPF pour un domaine qui lui appartient tout en plaçant votre adresse dans la ligne From:.

Que met-on dans un enregistrement SPF ?

Un seul enregistrement TXT à la racine du domaine, commençant par v=spf1 et se terminant par un mécanisme all :

example.com.  IN  TXT  "v=spf1 include:_spf.provider.net -all"

Quatre choses cassent SPF en pratique.

Deux enregistrements. Un domaine ne peut publier qu’un seul enregistrement v=spf1. À deux, l’évaluation renvoie permerror, ce qui compte comme un échec. Deux prestataires, cela veut dire un enregistrement avec deux termes include:.

La limite des dix résolutions. Chaque terme include:, a, mx, ptr et exists coûte une résolution DNS, et les includes imbriqués comptent aussi. Au-delà de dix, le résultat est permerror. Les longues chaînes d’includes de prestataires franchissent cette limite sans bruit.

Le mauvais all. -all demande aux destinataires de rejeter tout ce qui vient d’un serveur non listé. ~all est un softfail, que la plupart des destinataires acceptent en le marquant. Commencez par ~all et resserrez une fois les rapports propres.

La réexpédition. SPF authentifie l’expéditeur d’enveloppe, dans le Return-Path, pas l’en-tête From:. Un message réexpédié arrive du serveur du réexpéditeur, que votre enregistrement ne liste pas : SPF échoue donc sans que l’enregistrement soit en cause.

Comment fonctionne la signature DKIM ?

Le serveur émetteur génère une paire de clés. La moitié privée reste sur le serveur ; la moitié publique va dans le DNS sous un sélecteur que vous choisissez :

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

Au départ, le serveur hache le corps et un ensemble d’en-têtes choisi, signe le condensat et ajoute un en-tête DKIM-Signature qui nomme le domaine dans d= et le sélecteur dans s=. Le destinataire lit ces deux champs, récupère <selector>._domainkey.<domain> et vérifie.

Le sélecteur existe pour que vous puissiez détenir plusieurs clés à la fois, et c’est ce qui rend la rotation possible : publier la nouvelle clé, basculer la signature dessus, puis retirer l’ancien enregistrement une fois que plus rien n’est signé avec.

DKIM survit à la réexpédition, contrairement à SPF, parce que la signature voyage avec le message. Il casse quand quelque chose réécrit en route les parties signées — les listes de diffusion qui ajoutent un pied de page ou modifient l’objet sont le cas courant.

Que décide une politique DMARC ?

Un enregistrement TXT sur le sous-domaine _dmarc :

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:reports@example.com"

p est l’instruction donnée aux destinataires : none pour ne rien faire au-delà du signalement, quarantine pour traiter les échecs comme suspects, reject pour les refuser purement et simplement. rua est l’adresse où arrivent les rapports agrégés, et c’est la raison de publier l’enregistrement bien avant toute application.

DMARC passe quand SPF passe et que son domaine est aligné avec celui du From:, ou quand DKIM passe et que son d= est aligné. Un seul des deux suffit. L’alignement est relâché par défaut : les domaines organisationnels doivent correspondre, donc mail.example.com s’aligne avec example.com. L’alignement strict exige qu’ils soient identiques.

Dans quel ordre faut-il les poser ?

MX d’abord, puis SPF et DKIM, puis DMARC en p=none, puis l’application — et l’écart entre les deux derniers se mesure en semaines, pas en minutes.

1. MX. Le courrier doit arriver avant que l’authentifier ait un sens.
2. SPF et DKIM ensemble. Les deux ne font qu’ajouter et aucun ne rejette de courrier à lui seul.
3. DMARC en p=none avec une adresse rua. Rien ne change pour les destinataires ; les rapports commencent à arriver.
4. Lire les rapports. Ils nommeront des expéditeurs que vous aviez oubliés : le système de facturation, le CRM, les alertes de supervision, ce à quoi l’équipe marketing s’est inscrite. Chacun d’eux entre dans SPF, se met à signer en DKIM, ou cesse d’utiliser votre domaine.
5. p=quarantine, puis p=reject. Basculez une fois que les rapports ne montrent plus que des échecs que vous reconnaissez comme des falsifications.

Publier p=reject avant d’avoir lu les rapports est la manière classique de faire disparaître du courrier légitime. Les échecs sont silencieux pour vous et invisibles pour l’expéditeur.

Comment vérifier que les enregistrements sont corrects ?

Interrogez-les comme le fait un destinataire :

dig +short MX example.com
dig +short TXT example.com
dig +short TXT sel1._domainkey.example.com
dig +short TXT _dmarc.example.com

Envoyez ensuite un vrai message vers un compte ailleurs et lisez l’en-tête Authentication-Results avec lequel il arrive. Cet en-tête est le verdict du destinataire sur les trois vérifications, alignement compris — ce qu’aucune lecture de votre propre DNS ne vous dira :

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

Surveillez particulièrement header.d et header.from. Quand ces deux-là divergent, DMARC échoue, aussi vertes que soient les autres lignes.

Qu’est-ce que ces enregistrements ne font pas ?

Ils authentifient un domaine. Ils ne disent rien du contenu d’un message, ni du chiffrement.

Un message peut passer les trois vérifications et rester une fraude, pourvu qu’il soit honnête sur le domaine qui l’a envoyé — les attaquants enregistrent des domaines ressemblants et publient pour eux des enregistrements parfaits. Ces enregistrements ne chiffrent rien non plus : la sécurité du transport, c’est TLS entre les sauts, et savoir si le message est chiffré là où il se dépose est une autre question, avec une autre réponse.

Ce qu’ils corrigent, c’est la catégorie de falsification qui place votre domaine exact dans la ligne From:. C’était gratuit avant, et après p=reject ça ne l’est plus.