SPF, DKIM et DMARC en termes simples

Pourquoi vos e-mails atterrissent dans les spams et les trois enregistrements qui résolvent le problème.

Les fournisseurs de messagerie décident en une fraction de seconde si votre e-mail est digne de confiance. Trois enregistrements DNS répondent à leurs questions : qui est autorisé à émettre pour ce domaine, le message est-il resté intact, et que faut-il faire en cas de non-correspondance.

Depuis 2024, Gmail, Yahoo et Outlook les exigent pour quiconque envoie des e-mails en volume : SPF et DKIM pour chaque message, un enregistrement DMARC, ainsi qu'une adresse d'expédition (From) visible et cohérente. Les émetteurs de plus petite envergure sont jugés sur les mêmes signaux. En l'absence de ces enregistrements, une facture parfaitement légitime ressemble trait pour trait à une tentative de hameçonnage (phishing).

Le traitement d'un message par un serveur de réception

Imaginez une facture envoyée depuis [email protected] via votre logiciel de comptabilité. Avant qu'elle n'atteigne la boîte de réception, le serveur destinataire exécute trois vérifications successives :

1. 1SPF. Il examine le serveur qui s'est connecté et demande au domaine de l'adresse de rebond (bounce address) si ce serveur est autorisé à émettre. Les serveurs du logiciel de comptabilité doivent y être répertoriés.
2. 2DKIM. Il lit la signature située dans l'en-tête du message, récupère la clé publique désignée par le sélecteur et vérifie que le corps du texte et les en-têtes principaux n'ont pas été altérés.
3. 3DMARC. Il consulte l'adresse d'expédition visible (From), à savoir harborgoods.com, et vérifie qu'au moins l'une des deux vérifications précédentes a réussi pour ce même domaine. Il applique ensuite votre politique au résultat obtenu.

Ce n'est qu'ensuite qu'interviennent la réputation, le contenu et l'engagement. Un message échouant aux trois vérifications parvient rarement jusque-là.

SPF : qui est autorisé à émettre

Le SPF (Sender Policy Framework) est un enregistrement TXT situé à la racine du domaine, commençant par v=spf1. Il liste les serveurs autorisés à envoyer des e-mails pour votre domaine : votre fournisseur de messagerie, votre outil de newsletter, votre CRM, votre outil de support.

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

Chaque instruction include: incorpore la liste des serveurs publiée par un fournisseur. La terminaison indique aux serveurs de réception le comportement à adopter face aux autres émetteurs : ~all signifie « probablement pas nous, à traiter avec suspicion », -all signifie « assurément pas nous, à rejeter ». Commencez par ~all le temps de vérifier que chaque émetteur est répertorié, puis basculez vers -all.

Trois règles permettent au SPF de fonctionner correctement :

• Un seul enregistrement. Un domaine doit posséder un unique enregistrement SPF. Deux enregistrements, souvent laissés par l'assistant de configuration d'un nouveau fournisseur, invalident les deux.
• Dix recherches au maximum. Chaque include, a, mx et redirect engendre une recherche DNS, incluant celles imbriquées au sein des enregistrements des fournisseurs. Au-delà de dix, le SPF échoue pour chaque message. Retirez les outils que vous n'utilisez plus avant d'en ajouter de nouveaux.
• Le SPF vérifie l'expéditeur caché. Il valide l'adresse de rebond (bounce), et non l'adresse d'expédition visible (From). C'est pourquoi le SPF seul ne suffit pas à empêcher l'usurpation d'identité, d'où l'existence du DMARC.

DKIM : le message est-il resté intact

Le DKIM (DomainKeys Identified Mail) signe chaque e-mail à l'aide d'une clé privée détenue par le service d'expédition. La clé publique est publiée dans le DNS sous un sélecteur, un nom choisi par le fournisseur, par exemple google._domainkey ou s1._domainkey.

google._domainkey.harborgoods.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…"

Le serveur de réception lit le sélecteur dans l'en-tête du message, récupère la clé et vérifie la signature. Un message modifié en transit, ou forgé par une personne ne possédant pas la clé, échoue.

Chaque outil envoyant des e en votre propre nom requiert sa propre clé DKIM, publiée sous son propre sélecteur : vos boîtes aux lettres, votre outil de newsletter et votre système de facturation signent chacun séparément. Utilisez des clés de 2048 bits lorsque le fournisseur le propose, et effectuez une rotation de ces clés lorsqu'un collaborateur ayant y accès quitte l'entreprise ou qu'un fournisseur est remplacé. Supprimer un ancien sélecteur trop tôt brise la signature des messages encore en transit, laissez-le donc en place quelques jours après le changement.

DMARC : que faire en cas d'échec

Le DMARC (Domain-based Message Authentication, Reporting, and Conformance) est un enregistrement TXT placé en _dmarc commençant par v=DMARC1. Il associe le SPF et le DKIM à l'adresse d'expédition visible (From), indique aux destinataires la conduite à tenir en cas d'échec des deux vérifications, et précise où acheminer les rapports.

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

Les étiquettes importantes :

Un message réussit le contrôle DMARC lorsque le SPF ou le DKIM réussit et que le domaine validé est aligné avec l'adresse d'expédition (From). Une newsletter envoyée par l'intermédiaire d'un fournisseur signant avec son propre domaine valide le DKIM mais échoue au DMARC, tant que vous n'avez pas publié la clé DKIM du fournisseur sur votre propre domaine.

Lire un rapport DMARC

Les rapports agrégés parviennent une fois par jour de la part de chaque grand fournisseur de messagerie, sous forme de fichier XML compressé. Chaque ligne indique : cette adresse IP a envoyé tant de messages en se faisant passer pour votre domaine, le SPF a donné tel résultat, le DKIM tel autre, et voici l'action que nous avons menée. Un analyseur de rapports regroupe ces lignes par service émetteur pour vous permettre de répondre rapidement à trois questions :

• Quels services émettent en votre nom à votre insu ? Il s'agit souvent d'un module de formulaire oublié, d'un outil de support ou d'un scanner envoyant des PDF par e-mail.
• Quels services connus échouent à l'alignement ? Il s'agit généralement d'un fournisseur dont la clé DKIM n'a jamais été publiée sur votre domaine.
• Quelles sources relèvent purement de la falsification ? Ce sont ces messages que le DMARC bloquera dès son application stricte.

Déployer le DMARC sans perdre d'e-mails

Passer directement à p=reject constitue le moyen le plus sûr de bloquer vos propres factures. Procédez par étapes :

1. 1Publiez p=none muni d'une adresse rua et lisez les rapports pendant deux à quatre semaines. Un analyseur de rapports gratuit ou payant convertit le fichier XML en une liste claire des sources émettrices.
2. 2Pour chaque source légitime en échec, ajoutez-la au SPF ou publiez sa clé DKIM. Les sources inconnues émettant en votre nom sont précisément celles que le DMARC doit arrêter.
3. 3Passez à p=quarantine, éventuellement avec pct=25 puis pct=100, tout en continuant de surveiller les rapports.
4. 4Une fois que les rapports demeurent propres, basculez vers p=reject.

Vérifier vos enregistrements vous-même

N'importe quel terminal permet d'afficher ce que voient les serveurs de réception :

dig +short TXT harborgoods.com | grep spf1
dig +short TXT google._domainkey.harborgoods.com
dig +short TXT _dmarc.harborgoods.com
dig +short MX harborgoods.com

Envoyez ensuite un message à une adresse Gmail, ouvrez-le et choisissez « Afficher l'original » : le récapitulatif des en-têtes indique SPF: PASS, DKIM: PASS et DMARC: PASS lorsque tout est correctement aligné.

Transferts, listes de diffusion et sous-domaines

Le transfert de messages (forwarding) brise le SPF : lorsqu'un e-mail est transféré, le serveur de réacheminement se connecte au destinataire final avec sa propre adresse, que votre SPF ne liste pas. Le DKIM survit au transfert tant que le message n'est pas modifié, raison pour laquelle chaque émetteur doit signer en DKIM et ne pas s'en remettre au seul SPF. Les listes de diffusion qui ajoutent un pied de page ou modifient le préfixe du sujet brisent également le DKIM ; les logiciels de listes modernes réécrivent l'adresse d'expédition pour éviter les échecs DMARC.

Pour le marketing et l'e-mailing en volume, envisagez l'utilisation d'un sous-domaine dédié tel que news.harborgoods.com doté de ses propres enregistrements SPF, clé DKIM et DMARC. Les signalements liés à une campagne pèsent alors sur la réputation du sous-domaine, et non sur le domaine principal d'où partent vos factures et réinitialisations de mot de passe.

Protéger les domaines qui n'émettent jamais

Les domaines parqués et les anciennes marques constituent des cibles privilégiées pour l'usurpation d'identité, car personne ne les surveille. Faites savoir au monde entier qu'ils n'émettent rien :

parked-brand.com.         TXT  "v=spf1 -all"
_dmarc.parked-brand.com.  TXT  "v=DMARC1; p=reject"
parked-brand.com.         MX   0 .

La dernière ligne correspond à un enregistrement MX nul : elle indique que le domaine n'accepte aucun e-mail, de sorte que les émetteurs reçoivent un rebond immédiat au lieu d'itérer leurs tentatives pendant des jours.

Changement de fournisseur de messagerie

Une migration représente le moment critique où la plupart de ces enregistrements se rompent. Avant le basculement, ajoutez le nouveau fournisseur au SPF aux côtés de l'ancien et publiez sa clé DKIM sous son propre sélecteur, afin que les deux puissent émettre durant la transition. Réduisez le TTL des enregistrements MX la veille pour que le changement se propage rapidement. Le jour J, mettez à jour les MX, envoyez des messages de test vers quelques grands fournisseurs et contrôlez les en-têtes. Une semaine plus tard, lorsque plus rien ne transite par l'ancien canal, retirez l'ancien fournisseur du SPF et supprimez son sélecteur DKIM. Ne touchez pas au DMARC pendant toute l'opération : ses rapports constituent le meilleur moyen de s'assurer qu'aucun message légitime n'est passé entre les mailles du filet.

Erreurs courantes

• Deux enregistrements SPF suite au changement de fournisseur de messagerie.
• Un enregistrement SPF dépassant les dix recherches après des années d'adjonction d'outils.
• Une clé DKIM publiée avec une faute de frappe ou incorrectement répartie sur deux chaînes par l'hébergeur DNS.
• Des rapports DMARC acheminés vers une adresse que personne ne consulte.
• Un enregistrement DMARC présent uniquement sur le domaine principal, alors qu'aucun sous-domaine marketing n'en est doté et qu'aucune politique sp ne le couvre.
• Des enregistrements DNS laissés pour un service de messagerie ou de marketing que plus personne n'utilise : un enregistrement oublié peut permettre à un tiers de reprendre le sous-domaine (voir sous-domaines orphelins).