Meilleures pratiques M3AAWG pour les domaines d’envoi

Le consensus du M3AAWG (expéditeurs, serveurs de réception et organisations anti-spam réunis) sur le volet « noms de domaine » de la préparation d’un programme d’envoi : la liste de contrôle que les ESP repassent pour chaque nouveau client (Sending Domains Best Common Practices). Il complète les recommandations côté IP de la gestion des adresses IP et les guides de prestataires de Pratiques d’infrastructure d’envoi ; cet article présente les positions de référence du secteur et la mécanique de délégation DNS.

Recommandation phare : pour choisir un domaine d’envoi, il faut dans presque tous les cas retenir un sous-domaine du domaine organisationnel de l’expéditeur.

Choisir le domaine : domaine de la marque et sous-domaines, ou domaine sosie

Le choix se résume à deux options :

Un domaine sosie (cousin domain) ressemble au domaine principal de la marque mais n’a aucun lien DNS direct avec lui : il peut être chez un autre registraire, chez un autre hébergeur DNS, avec un autre WHOIS. Les domaines sosies, surtout lorsqu’ils servent à des envois ponctuels, ressemblent à des campagnes de phishing, aussi bien pour les utilisateurs que pour les systèmes anti-abus, ce qui entraîne davantage de plaintes pour spam ainsi que des blocages et du filtrage ; ils exposent aussi la marque à des problèmes de sécurité et sèment la confusion chez les utilisateurs, les employés et les outils de sécurité. (La surveillance des domaines sosies, c’est-à-dire la veille sur l’usage abusif de domaines ressemblants par des tiers, est traitée dans Pratiques d’infrastructure d’envoi.)

Utiliser plutôt un sous-domaine du domaine principal :

• rend l’expéditeur plus facile à identifier et beaucoup moins déroutant pour les destinataires et les systèmes de réception ;
• signale une segmentation active du trafic et une gestion de la qualité, avec un lien clair entre la marque et la réputation de chaque domaine ;
• permet au programme d’envoi de profiter de la réputation existante du domaine organisationnel (un domaine sosie tout neuf part de zéro).

Stratégie de segmentation

Les serveurs de réception demandent, et peuvent exiger, la séparation des différents types de trafic : marketing en masse, prospection individuelle, transactionnel (bienvenue, confirmation de commande), relevés mensuels, etc. La meilleure pratique sépare aussi le trafic par activité (par pays, par service de l’organisation) pour la visibilité, des réputations distinctes et un dépannage plus simple. Chaque séparation exige un sous-domaine distinct, et parfois aussi des adresses IP distinctes (l’équivalent, au niveau du domaine, de la segmentation avancée des adresses IP).

Contrainte : chaque segment doit pouvoir construire et entretenir sa propre réputation, ce qui exige un volume de trafic suffisant et relativement régulier. Les interruptions d’envoi ou les fortes variations de volume nuisent à la formation comme au maintien de la réputation : ne segmentez pas plus finement que votre volume ne le permet.

Choisir les noms de sous-domaines

• Attribuez un sous-domaine distinct à chaque finalité d’envoi ; réservez le domaine principal au courrier de l’entreprise (entre employés, échanges individuels avec l’extérieur).
• Le nom du sous-domaine devrait être en rapport avec le type de trafic : le filtrage peut inclure un examen humain, les « mots comptent » :

• Envoyer depuis un sous-domaine n’oblige pas le From: visible à utiliser ce sous-domaine : l’alignement sur le domaine organisationnel suffit pour l’authentification et la prévention des abus (certains cas d’usage justifient toutefois un From: visible identique).
• L’expéditeur doit avoir accès à la boîte de réception indiquée dans le From: visible (voir les recommandations contre le no-reply dans Pratiques d’infrastructure d’envoi).
• Des sous-domaines distincts sont la meilleure pratique, surtout pour les envois en masse ; pour de plus petits volumes, des parties locales différentes de l’adresse d’expéditeur sur un même domaine sont acceptables. Jugez selon les destinataires, la diversité géographique et les besoins de prévention des abus.

Cohérence des domaines dans le message

Utilisez un domaine organisationnel cohérent dans tout le message : Return-Path (RFC5321.MailFrom), From: visible (RFC5322.From) et domaine de signature DKIM d=. Aligner le Reply-To sur le domaine organisationnel est une bonne pratique, mais n’est pas obligatoire.

Deux schémas acceptables :

Alignement

Le document utilise partout l’alignement souple (RFC 7489 §3.1) : des domaines sont en alignement souple lorsque leurs domaines organisationnels correspondent.

Réputation du domaine et montée en charge

• La réputation se construit rapidement à partir de l’activité d’envoi sur un sous-domaine et sert au filtrage, aux côtés du contenu et de la réputation de l’IP.
• Inconnu ≈ mauvais : un domaine sans historique fait l’objet d’un examen et d’une prudence accrus ; un domaine avec historique permet au FAI de déduire la qualité du comportement dans le temps. Un usage correct des sous-domaines profite de la réputation du domaine organisationnel.
• La réputation s’attache à la combinaison des éléments, pas au domaine seul : changer de domaine d’envoi (du domaine organisationnel vers un sous-domaine ou l’inverse), changer d’IP d’envoi ou modifier les en-têtes peut chacun exiger une montée en charge pour la nouvelle combinaison. C’est pertinent lorsqu’on restructure un programme existant, et pas seulement lors d’un lancement.

Deux phases : la chauffe (d’inconnu à repéré), puis la montée en charge (atteindre progressivement le volume à long terme prévu). Les stratégies varient selon les fournisseurs, mais des règles communes s’appliquent :

• Restez régulier : les caractéristiques du contenu et les volumes ne devraient pas varier brutalement.
• Consultez les journaux SMTP pour repérer et trier les problèmes de livraison en cours.
• Inscrivez-vous aux programmes de supervision des données lorsqu’ils existent (Google Postmaster Tools ; Netease et Chengxin pour les fournisseurs chinois).
• Commencez bas et lentement ; comptez environ 6 semaines de chauffe en moyenne (des calendriers de volume jour par jour figurent dans Pratiques d’infrastructure d’envoi et Recommandations pour la chauffe d’IP).
• Surveillez le placement et les taux d’ouverture pour chaque fournisseur de messagerie.

Liste de contrôle de la configuration

Authentification

Chaque protocole stocke ses données dans des enregistrements DNS TXT vérifiés par le serveur de réception. Voir les articles détaillés pour la mécanique complète ; points propres aux domaines d’envoi :

MX, adresses de rôle, présence web

• Chaque domaine utilisé dans Return-Path, From: visible, Sender: et Reply-To: devrait avoir un enregistrement MX correct pointant vers un serveur de messagerie fonctionnel.
• abuse@ et postmaster@ doivent exister, être lues et ne jamais rebondir.
• Les domaines ou sous-domaines de premier niveau utilisés dans le From: visible devraient pointer ou rediriger vers une page web active et à jour en rapport avec l’expéditeur : les utilisateurs qui vérifient la légitimité d’un message consultent d’abord le site web du domaine d’envoi.

Configuration DNS : trois modèles de délégation

C’est le cœur du provisionnement des domaines des clients d’un ESP. Trois options, par ordre croissant de contrôle de l’ESP :

1. Configuration directe

La marque publie elle-même les enregistrements dans sa propre zone : c’est la seule option lorsqu’aucun tiers (ESP) n’intervient. Limite connue : des interfaces de registraire vieillissantes peuvent être incapables de publier des enregistrements DKIM avec des clés plus fortes ou certains caractères.

2. Délégation par CNAME : la préférée des ESP

La marque publie des CNAME pointant vers la zone de l’ESP, pour que l’ESP puisse mettre à jour les valeurs des enregistrements de façon transparente, par exemple faire tourner la clé publique DKIM sans demander au client de modifier sa zone. Cela lève les limites de la configuration directe tout en laissant à la marque la visibilité sur sa zone.

(SPF et MX ne peuvent pas être des CNAME sur un nœud qui porte d’autres données ; ces enregistrements restent donc directs même dans ce modèle. Les chaînes de CNAME comptent aussi dans les limites de requêtes DNS de SPF.)

3. Délégation de serveurs de noms (NS)

La marque délègue le sous-domaine (et tout ce qui se trouve en dessous) aux serveurs de noms de l’ESP :

Avantage : l’ESP prend en charge toute la configuration DNS et garantit que la configuration d’authentification est correcte. Inconvénient : la marque perd toute visibilité sur la zone, un abandon de contrôle qui exige une grande confiance dans l’ESP.

Migration : changer d’ESP ou de domaine d’envoi

La régularité est essentielle à la réputation d’un domaine : conservez le domaine choisi dans la durée. La réputation se construit progressivement et la régularité des schémas d’envoi dans le temps est primordiale. Lors d’une migration (nouvel ESP, ou changement de domaine imposé par un changement de nom ou de politique) :

• Appliquez les principes de ce document progressivement et avec discernement à un programme existant qui fonctionne ; surveillez les indicateurs de délivrabilité à chaque changement de configuration.
• Période de chevauchement : les deux ESP peuvent envoyer simultanément si l’on ajoute les IP du nouveau prestataire à l’enregistrement SPF et que l’on publie son sélecteur DKIM.
• L’enregistrement MX ne peut pointer que vers un seul prestataire : pendant le chevauchement, les plaintes et les rebonds asynchrones acheminés via le MX peuvent ne pas atteindre l’autre prestataire. Planifiez la migration en tenant compte de cette perte de données.
• N’effectuez la bascule complète qu’une fois que la cadence et le volume d’envoi avec le nouveau prestataire sont réguliers et maintenus au volume à long terme souhaité.

Documents M3AAWG cités

Documents référencés par ce BCP : BCP destiné aux expéditeurs (v3.0, févr. 2015), « Trust in Email Begins with Authentication » (févr. 2015, résumé dans Meilleures pratiques M3AAWG pour l’authentification des emails), « Best Practices for Managing SPF Records » (août 2017) et « DKIM Key Rotation BCP » (mars 2019). Voir l’index des documents M3AAWG.

Voir aussi

• Pratiques d’infrastructure d’envoi : le point de vue des guides de prestataires, avec les quatre domaines d’un message et les calendriers de chauffe des domaines
• Segmentation avancée des adresses IP : l’équivalent côté IP de la segmentation par sous-domaines
• SPF · DKIM · DMARC : la mécanique des protocoles derrière la liste de contrôle de la configuration