Vos e-mails arrivent en spam ? La liste de contrôle DNS

Quand un courrier légitime atterrit dans les indésirables, la cause tient à l'une de ces deux choses : l'authentification (le destinataire ne parvient pas à confirmer que le message vient bien de votre domaine) ou la réputation (il y parvient, et ce qu'il voit ne lui plaît pas). Le DNS règle la première. Il ne règle pas la seconde, mais tant que la première n'est pas en ordre, rien de ce que vous ferez par ailleurs ne comptera.

Cette liste de contrôle parcourt le volet DNS dans l'ordre qui permet de trouver les problèmes le plus vite. Les notions sous-jacentes sont expliquées dans MX, SPF, DKIM et DMARC expliqués ; ici, on reste dans la pratique.

Étape 0 — Lisez les en-têtes d'un message arrivé en spam

Ne devinez pas. Envoyez un message vers une boîte que vous contrôlez chez le fournisseur où le problème se produit, ouvrez-le, puis choisissez « afficher l'original » ou « afficher la source ». Cherchez l'en-tête Authentication-Results ajouté par le destinataire :

Authentication-Results: mx.receiver.example;
   spf=pass smtp.mailfrom=bounces.mailer.example;
   dkim=pass header.d=mailer.example header.s=s1;
   dmarc=fail (p=NONE) header.from=example.com

Cette seule ligne vous apprend l'essentiel :

Champ	Question à laquelle il répond
`spf=` et `smtp.mailfrom=`	L'adresse IP d'envoi correspondait-elle à l'enregistrement SPF du domaine d'enveloppe, et quel était ce domaine ?
`dkim=` et `header.d=`	Y avait-il une signature valide, et pour quel domaine ?
`dmarc=` et `header.from=`	SPF ou DKIM ont-ils réussi pour le domaine que voit le destinataire ?

Dans cet exemple, tout « passe », et DMARC échoue quand même : SPF et DKIM ont réussi pour les domaines du service d'envoi, pas pour example.com. C'est, de loin, le constat le plus courant ; l'étape 4 s'en occupe.

Notez aussi l'adresse IP d'envoi qui figure dans la ligne Received: la plus haute, celle qu'a ajoutée le destinataire : vous en aurez besoin à l'étape 5.

Étape 1 — Recensez tout ce qui envoie du courrier au nom de votre domaine

L'authentification échoue le plus souvent pour un expéditeur auquel personne n'a pensé : le fournisseur de messagerie, l'outil de newsletters, le CRM, le logiciel de facturation, le support client, le formulaire de contact du site, le scanner du bureau, les alertes de supervision. Notez-les tous. Chacun doit être couvert par SPF ou par DKIM, de préférence par les deux.

Étape 2 — SPF

$ dig +short example.com TXT | grep spf1
"v=spf1 include:_spf.mailprovider.example include:spf.mailer.example -all"

À vérifier :

Un seul enregistrement commençant par v=spf1. Deux enregistrements constituent une erreur permanente (permerror), et le résultat est le même que si vous n'en aviez aucun.
Chaque expéditeur de l'étape 1 est couvert par un include:, un ip4: ou un ip6:.
Pas plus de 10 requêtes DNS au total. include, a, mx, exists et redirect comptent chacun pour une, et les include s'emboîtent. Dépasser la limite produit aussi un permerror. Retirez les services que vous n'utilisez plus avant de recourir à l'« aplatissement SPF » (SPF flattening).
L'enregistrement se termine par ~all ou -all. +all autorise tout Internet ; ?all ne dit rien.
Pas de mécanisme ptr. Il est lent, peu fiable et déconseillé par la spécification SPF elle-même.
Les sous-domaines qui envoient du courrier (news.example.com) ont leur propre enregistrement SPF. SPF ne s'hérite pas.

Rappelez-vous ce que SPF contrôle : l'expéditeur d'enveloppe (Return-Path), pas l'en-tête From. Si un service utilise son propre domaine de rebond, SPF réussit pour son domaine et n'améliore en rien votre résultat DMARC, à moins de configurer un return-path personnalisé.

Étape 3 — DKIM

Relevez le sélecteur (s=) et le domaine (d=) dans l'en-tête DKIM-Signature d'un message réel, puis interrogez la clé :

$ dig +short s1._domainkey.example.com TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

L'enregistrement existe et contient une valeur p=. Un p= vide signifie que la clé a été révoquée.
Les clés longues sont découpées en plusieurs chaînes entre guillemets, sans espace parasite ni retour à la ligne glissé par l'interface de gestion.
La clé fait 2048 bits lorsque le fournisseur le permet ; 1024 bits est le minimum accepté par les destinataires.
Si le fournisseur a demandé des enregistrements CNAME plutôt que TXT, ils sont bien présents, et votre fournisseur DNS ne les « aplatit » pas ni ne les fait passer par son proxy.
d= est votre domaine, pas celui du prestataire. La plupart des services signent avec leur propre domaine tant que vous n'avez pas terminé leur procédure d'« authentification du domaine ». C'est cela qui fait compter DKIM pour DMARC.
Chaque service d'envoi dispose de son propre sélecteur.

Il n'existe aucun moyen d'énumérer de l'extérieur les sélecteurs DKIM d'un domaine. On les trouve dans les en-têtes des messages ou dans les réglages du prestataire.

Étape 4 — DMARC et l'alignement

$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Un seul enregistrement sous _dmarc.example.com, commençant par v=DMARC1, avec un p= valide.
Une adresse rua= que quelqu'un, ou un outil, lit réellement. Si elle appartient à un autre domaine, celui-ci doit publier un enregistrement d'autorisation.
Pour chaque expéditeur, SPF ou DKIM (au moins l'un des deux) réussit avec un domaine qui correspond à celui du From (le même domaine organisationnel suffit dans le mode souple par défaut).

Depuis février 2024, Gmail et Yahoo exigent SPF, DKIM et un enregistrement DMARC (au minimum p=none) avec alignement de la part de quiconque envoie environ 5 000 messages ou plus par jour à leurs utilisateurs, ainsi que la désinscription en un clic pour les messages marketing et un faible taux de plaintes. D'autres grands fournisseurs ont annoncé des règles comparables. Les expéditeurs plus modestes doivent disposer au minimum de SPF ou de DKIM et sont, en pratique, jugés selon les mêmes critères.

p=none vous procure des rapports et satisfait au minimum requis. Il ne protège pas le domaine contre l'usurpation. Passez à quarantine puis à reject une fois que les rapports montrent que toutes les sources légitimes sont alignées.

Étape 5 — Le serveur d'envoi : DNS inverse et HELO

Cette étape ne vous concerne que si vous exploitez vous-même le serveur de messagerie. Avec l'adresse IP relevée à l'étape 0 :

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short mail.example.com
192.0.2.25

Un enregistrement PTR existe, et ce n'est pas le nom générique attribué par défaut par l'hébergeur.
Ce nom se résout à son tour vers la même adresse IP.
Le serveur se présente sous ce même nom dans EHLO.
Si le serveur dispose d'IPv6, il en va de même pour cette adresse, ou alors le courrier sortant est limité à IPv4.

Le principe est détaillé à l'entrée DNS inverse du glossaire.

Étape 6 — Les MX et le domaine lui-même

Le domaine possède des enregistrements MX fonctionnels qui pointent vers des noms d'hôte (ni adresses IP, ni CNAME) acceptant le courrier. Les destinataires se méfient des expéditeurs incapables de recevoir les rebonds et les réponses.
postmaster@ et abuse@ aboutissent à un être humain.
Les domaines qui n'envoient jamais de courrier le déclarent : v=spf1 -all, un MX nul (0 .) et v=DMARC1; p=reject. Les domaines parqués sont une cible de choix pour l'usurpation.

Étape 7 — TLS

Le courrier sortant utilise STARTTLS. Gmail signale les messages non chiffrés par un cadenas rouge, et les règles applicables aux expéditeurs en masse imposent TLS.
Votre propre MX propose STARTTLS avec un certificat qui n'a pas expiré :

$ openssl s_client -connect mail.example.com:25 -starttls smtp </dev/null 2>/dev/null \
    | openssl x509 -noout -enddate

Étape 8 — Listes de blocage et réputation

Recherchez l'adresse IP d'envoi et le domaine sur les pages de consultation des principaux opérateurs de listes de blocage. Figurer sur une liste obscure a rarement de l'importance ; figurer sur une liste très utilisée en a. Corrigez la cause (compte compromis, formulaire ouvert, liste achetée) avant de demander le retrait.
Inscrivez le domaine aux outils « postmaster » que proposent les grands fournisseurs de messagerie. Ils montrent comment ces fournisseurs perçoivent votre domaine : taux de plaintes pour spam, résultats d'authentification, réputation.

Quand le DNS est en ordre et que le courrier part quand même en spam

C'est alors une affaire de réputation ou de contenu, et aucun enregistrement n'y changera rien :

un nouveau domaine ou une nouvelle adresse IP qui envoie du volume dès le premier jour, sans montée en charge progressive ;
des destinataires qui n'ont jamais demandé ce courrier, et qui s'en plaignent ;
de vieilles listes pleines d'adresses mortes ;
des raccourcisseurs de liens, des liens vers des domaines mal considérés, des messages composés uniquement d'images ;
un domaine From différent de celui des liens et de celui de la signature ;
sur des adresses IP partagées : le comportement des autres clients.

Le DNS vous permet d'être jugé en tant que vous-même. La suite dépend de ce que vous envoyez.

Erreurs fréquentes

Ajouter un second enregistrement SPF pour un nouveau service au lieu de compléter celui qui existe.
Voir spf=pass et dkim=pass et s'arrêter là, sans vérifier quel domaine a réussi.
Sauter directement à p=reject sans lire les rapports, et perdre les factures émises par un système oublié.
Ne tester que depuis sa propre boîte vers sa propre boîte, chez le même fournisseur.
S'attendre à un effet immédiat : les enregistrements SPF et DMARC restent en cache pendant la durée de leur TTL.

Vérifiez avec OrbitProbe

La recherche MX d'OrbitProbe affiche les hôtes MX d'un domaine et leurs priorités, le fournisseur de messagerie probable, ainsi que les enregistrements SPF et DMARC, avec des constats sur les erreurs de configuration courantes. Elle ne peut pas énumérer les sélecteurs DKIM, car personne ne le peut de l'extérieur : contrôlez-les à partir d'un en-tête de message, comme décrit à l'étape 3. Lancez-la pour le domaine exact de votre adresse From, puis de nouveau pour chaque sous-domaine qui envoie du courrier.