SPF, DKIM et DMARC : configurer l’authentification des e-mails dans le DNS

1. Recenser chaque service qui envoie des e-mails

Les enregistrements MX indiquent aux serveurs expéditeurs où livrer le courrier entrant du domaine. L’envoi obéit à une autre logique : une entreprise reçoit souvent ses e-mails chez un fournisseur de messagerie, mais expédie ses factures, ses réponses du support et ses newsletters par des services spécialisés, chacun avec ses propres serveurs.

Commencez par un inventaire des expéditeurs, à raison d’une ligne par service. Notez l’adresse visible dans le champ From (« De » dans la messagerie), le domaine d’enveloppe (celui du MAIL FROM, qui reçoit les avis de non-remise et apparaît dans l’en-tête Return-Path), le domaine qui signe en DKIM, la personne responsable et un exemple de message réel. Ces trois domaines peuvent légitimement différer, par exemple une adresse From en @example.com et un domaine d’enveloppe fourni par le prestataire ; les réunir sur une même ligne rend la configuration lisible.

Précisez aussi le nom exact utilisé pour l’e-mail, qui n’est pas toujours celui du site : le site peut se trouver sur www.example.com alors que les messages utilisent example.com ou news.example.com. L’inventaire devient précieux le jour où l’équipe ajoute un outil, en retire un ou confie la messagerie à quelqu’un d’autre.

Il concerne également les domaines qui n’échangent aucun courrier : un domaine qui ne sert qu’au site web, ou qui a été acheté pour protéger une marque, peut lui aussi être utilisé comme faux expéditeur. Un tel domaine peut indiquer qu’il n’envoie ni ne reçoit de courrier en combinant trois éléments : un MX nul (défini par la RFC 7505), un enregistrement SPF v=spf1 -all qui n’autorise aucun serveur et une politique DMARC p=reject. C’est la combinaison que demande l’office fédéral allemand pour la sécurité de l’information (BSI) dans sa directive technique sur l’authentification des e-mails.

2. Comprendre ce qu’apporte chaque mécanisme

Chaque mécanisme couvre une partie de l’identité, et aucun ne suffit seul. SPF ne regarde pas l’adresse que lit le destinataire ; DKIM permet à un domaine d’endosser la responsabilité d’un message, sans dire que ce domaine est celui du From ; DMARC fait le lien entre ces résultats et le domaine visible. Le chiffrement du transport relève d’une autre couche, TLS, que MTA-STS renforce pour le courrier que vous recevez. Avec ces rôles en tête, les en-têtes techniques d’un message livré deviennent bien plus faciles à lire.

3. Construire SPF à partir des circuits d’envoi réels

SPF compare l’adresse IP du serveur qui se connecte à la politique publiée par le domaine d’enveloppe. Cette politique se publie uniquement dans un enregistrement TXT qui commence par v=spf1. Un nom ne doit en porter qu’un seul : deux enregistrements v=spf1 sur le même nom produisent une erreur permanente (permerror). C’est un piège fréquent quand un nouveau prestataire vous demande d’« ajouter son SPF » : il faut intégrer son mécanisme include: dans l’enregistrement existant, et non en créer un second.

Les inclusions s’emboîtent, car l’enregistrement d’un prestataire peut lui-même en inclure d’autres. La spécification SPF (RFC 7208) limite à dix les termes qui déclenchent une requête DNS pendant l’évaluation (include, a, mx, ptr, exists, redirect) ; ip4, ip6 et all ne comptent pas. Au-delà, le résultat est une erreur permanente. Elle demande aussi aux vérificateurs de limiter à deux les recherches « vides », celles qui ne renvoient aucune donnée. Comptez donc les inclusions imbriquées, pas seulement celles qui figurent dans votre propre enregistrement.

Le mécanisme final mérite une décision réfléchie. +all autorise n’importe quelle adresse IP d’Internet à envoyer pour le domaine et n’a sa place nulle part. ~all (softfail) signale un échec atténué : le destinataire ne devrait pas rejeter le message sur ce seul résultat. -all (fail) déclare explicitement les autres sources non autorisées, la suite restant une décision locale du destinataire. La nouvelle spécification DMARC signale un effet de bord : avec -all, certains destinataires rejettent le message dès la session SMTP, avant même d’évaluer DMARC. Un message qu’une signature DKIM alignée aurait fait passer est alors perdu, et ce rejet n’apparaît pas dans les rapports DMARC.

L’ANSSI, dans son guide sur l’interconnexion d’un système d’information à Internet, recommande de configurer SPF pour les domaines de messagerie en portant une attention particulière à l’inventaire des serveurs d’envoi, internes comme externes. Elle rappelle aussi que le protocole n’est pas infaillible face à l’usurpation : si une adresse IP d’envoi est partagée entre plusieurs domaines, ou si un serveur autorisé est compromis, SPF ne peut pas distinguer la fraude. Quand un service change, mettez à jour l’inventaire et le DNS en même temps ; le lien entre ce qui est autorisé et la personne responsable de chaque service d’envoi reste ainsi visible.

Pour interroger avec dig ou nslookup les enregistrements SPF et DMARC que publie votre domaine et les lire terme par terme, suivez le guide pour vérifier SPF et DMARC.

4. Relier signatures, alignement et rapports

DKIM ajoute à chaque message une signature calculée sur certaines de ses parties. Le destinataire la vérifie avec une clé publique publiée dans le DNS sous un nom de la forme selecteur._domainkey.example.com ; le prestataire d’envoi vous indique le sélecteur et la valeur à publier. Pour que DKIM compte dans DMARC, signez avec votre propre domaine (ou un sous-domaine) plutôt qu’avec celui du prestataire. La RFC 8301 impose des clés RSA d’au moins 1024 bits et recommande au moins 2048 bits. Comme les clés se trouvent sous des sélecteurs qu’un contrôle externe ne peut pas énumérer, la vérification la plus fiable reste un vrai message : ouvrez-le dans la boîte de réception et lisez l’en-tête Authentication-Results, qui indique comment le serveur de réception a évalué SPF, DKIM et DMARC.

DMARC est désormais défini par la RFC 9989, publiée en mai 2026, qui remplace la RFC 7489 de 2015, un document informatif qui n’était pas une norme de l’IETF. Il relie l’authentification au domaine visible dans le champ From : un message passe DMARC si SPF ou DKIM réussit avec un domaine aligné sur celui du From. En mode relâché, le mode par défaut, il suffit que les deux partagent le même domaine organisationnel ; en mode strict, ils doivent être identiques. La politique se publie dans un enregistrement TXT sur _dmarc.example.com, qui commence par v=DMARC1.

La politique p=none n’exprime aucune préférence de traitement : c’est la phase d’observation, pendant laquelle les destinataires continuent d’appliquer leurs propres filtres. Indiquez dans la balise rua une adresse qui recevra les rapports agrégés (RFC 9990), lesquels résument les résultats d’authentification par source d’envoi. Ils servent à repérer le trafic habituel, à confirmer les services légitimes et à débusquer ceux qui manquent à l’inventaire avant de passer à quarantine, puis éventuellement à reject. Si un tutoriel vous propose la balise pct pour un déploiement progressif, sachez qu’elle a disparu de la RFC 9989. La nouvelle balise t=y sert à une phase de test : les destinataires appliquent le niveau inférieur à la politique publiée (reject est traité comme quarantine, et quarantine comme none).

La RFC 9989 tempère aussi le réflexe du « reject pour tout le monde ». Elle recommande au moins un mois en p=none, puis une durée équivalente en quarantine, en comparant à chaque étape les rapports agrégés. Elle déconseille p=reject aux domaines dont les utilisateurs écrivent sur des listes de diffusion : les listes modifient souvent les messages qu’elles relaient, ce qui peut faire échouer DMARC, et les rejets qui en découlent peuvent faire désinscrire automatiquement des abonnés de la liste. Un domaine qui publie reject doit signer avec DKIM et ne pas compter sur SPF seul, que le transfert de courrier met en échec. Côté fournisseurs de messagerie, les consignes de Google demandent depuis février 2024 aux expéditeurs qui envoient environ 5 000 messages par jour ou plus vers des comptes Gmail personnels de configurer SPF, DKIM et DMARC, avec un From aligné sur SPF ou DKIM ; une politique p=none suffit.

5. Coordonner certificats et transport du courrier

Les enregistrements CAA indiquent quelles autorités peuvent émettre des certificats pour le domaine. Une autorité publique doit les consulter avant d’émettre et, comme l’explique Let’s Encrypt, retient l’enregistrement le plus proche du nom demandé : un CAA posé sur example.com couvre donc aussi www.example.com tant que ce sous-domaine n’a pas le sien. L’absence de CAA est permise ; n’importe quelle autorité peut alors émettre. Partez des émetteurs réellement utilisés par le site, le CDN et les autres services, renouvellements automatiques compris, et mettez la liste à jour à chaque changement de fournisseur. La spécification CAA (RFC 8659) en précise aussi les limites : CAA n’empêche pas une erreur d’émission par une autorité que vous avez autorisée, et les navigateurs ne doivent pas s’en servir pour valider un certificat.

MTA-STS protège l’autre sens : le courrier que d’autres serveurs vous livrent. Il permet à votre domaine de demander aux serveurs expéditeurs compatibles de ne livrer à vos MX qu’en TLS, avec un certificat de confiance. Sa mise en place réunit un enregistrement TXT sur _mta-sts.example.com, un fichier de politique servi en HTTPS à l’adresse https://mta-sts.example.com/.well-known/mta-sts.txt, la liste des MX attendus et un certificat valide sur chacun d’eux. Le fichier fixe un mode : testing, enforce ou none.

Commencez en mode testing : un échec de validation ne bloque pas la livraison et, si vous publiez un enregistrement TLS-RPT sur _smtp._tls.example.com, les expéditeurs vous envoient des rapports sur leurs connexions TLS, échecs compris. Passez en enforce quand ces rapports ne montrent plus d’échecs inexpliqués. La spécification MTA-STS (RFC 8461) décrit le cycle de vie de la politique. Traitez ces éléments comme un seul service : en mode enforce, un expéditeur qui applique la politique refuse de livrer à un MX absent de la liste ou dont le certificat n’est pas valide.

6. Contrôler l’ensemble sur de vrais messages

Avant une modification DNS planifiée, sauvegardez les enregistrements existants, identifiez le fournisseur DNS qui fait autorité pour la zone et notez le TTL. Après publication, interrogez à la fois le serveur faisant autorité et un résolveur public (avec dig ou nslookup, par exemple), et tenez compte de la durée de cache avant de conclure qu’une ancienne valeur a disparu.

1. Envoyez un message représentatif depuis chaque service de l’inventaire.
2. Vérifiez sa réception et lisez l’en-tête Authentication-Results côté destinataire.
3. Notez les résultats SPF, DKIM et DMARC, ainsi que les domaines alignés.
4. Comparez ces observations aux rapports agrégés et mettez à jour les responsables dans l’inventaire.

Testez les messages que l’entreprise envoie vraiment : factures, réponses du support, notifications de compte, newsletters. Variez les messageries de réception, par exemple une messagerie grand public et une messagerie d’entreprise, pour comparer plusieurs évaluations. Conservez pour chaque circuit un exemple daté avec ses en-têtes : la personne qui reprendra le dossier verra la configuration attendue en action, et l’entretien du DNS devient une routine reproductible plutôt qu’une enquête.

Pour consulter dès maintenant les enregistrements SPF, DMARC, MTA-STS et CAA d’un domaine, utilisez le vérificateur SPF et DMARC gratuit.

7. Garder une trace claire de l’identité du domaine

Rassemblez au même endroit l’inventaire des expéditeurs, les enregistrements DNS, les émetteurs de certificats retenus et les messages d’exemple datés. Pour un premier relevé de la partie publique, le snapshot gratuit de Sitelemetry exécute huit contrôles passifs sur une origine publique, sans inscription ; ce n’est pas un test d’intrusion. Côté messagerie, il lit les enregistrements SPF, DMARC, CAA et MTA-STS du nom d’hôte exact saisi : pour www.example.com, il interroge www.example.com et non le domaine parent. Il ne signale l’absence de SPF, de DMARC ou de MTA-STS que si ce nom possède des enregistrements MX. Il ne vérifie pas DKIM et, pour MTA-STS, il regarde l’enregistrement DNS sans télécharger le fichier de politique. Les messages réels et les rapports agrégés restent donc la référence pour DKIM et l’alignement.

Pour la suite, le guide TLS et en-têtes de sécurité traite des connexions au site web, et le guide des intégrations couvre les services métier reliés au site.