Meilleures pratiques M3AAWG pour les domaines d’envoi

Lorsque vous préparez un programme d’envoi, vous devez décider quels domaines les messages utiliseront, comment répartir le trafic entre eux et comment publier leurs enregistrements DNS. Si vous exploitez un fournisseur de services email (ESP), vous repassez cette liste de contrôle pour chaque nouveau client.

Les Sending Domains Best Common Practices (BCP) du Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) consignent le consensus des expéditeurs, des serveurs de réception et des organisations anti-spam sur ces questions de domaines. Pour le volet IP, voir la gestion des adresses IP. Pour les recommandations tirées des guides de prestataires, voir Pratiques d’infrastructure d’envoi. Cette page présente les positions de référence du secteur et la mécanique de délégation DNS.

Recommandation principale : pour choisir un domaine d’envoi, retenez dans presque tous les cas 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 et avoir d’autres informations 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. Ils entraînent davantage de plaintes pour spam, de blocages et de 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é. Pratiques d’infrastructure d’envoi traite de la surveillance des domaines sosies, c’est-à-dire de la veille sur l’usage abusif de domaines ressemblants par des tiers.

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 ;
• montre que le trafic est activement segmenté et que sa qualité est gérée, 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).

La version 4.0 des M3AAWG Sender Best Common Practices (août 2026) étend cette règle aux clients des ESP. Elle recommande fortement qu’un ESP fasse envoyer chaque client depuis le domaine du client ou l’un de ses sous-domaines. Le domaine de l’ESP est une solution de repli pour les petits expéditeurs qui ne peuvent pas modifier leur DNS, et même dans ce cas, l’ESP devrait donner à chaque marque son propre sous-domaine du domaine partagé. Un sous-domaine unique partagé par tous les clients, ou par tout un pool, n’est pas recommandé : tous ceux qui l’utilisent partagent une même réputation, et les abus deviennent difficiles à retracer.

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, courrier transactionnel (messages de bienvenue, confirmations de commande), relevés mensuels, etc. La meilleure pratique sépare aussi le trafic par activité, par exemple par pays ou par service, 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. C’est 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, à un niveau relativement régulier. Les interruptions d’envoi ou les fortes variations de volume rendent plus difficiles à la fois la construction et le 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, et é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, donc « 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, même si certains cas d’usage justifient 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 les adresses 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, utiliser des parties locales différentes de l’adresse d’expéditeur sur un même domaine est acceptable. Décidez en fonction des destinataires, de leur répartition géographique et des besoins de prévention des abus.

Cohérence des domaines dans le message

Utilisez le même domaine organisationnel dans tout le message : dans le Return-Path (RFC5321.MailFrom), le From: visible (RFC5322.From) et le 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 sont acceptables :

Alignement

Le document utilise partout l’alignement souple (RFC 7489 §3.1). Deux 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 les filtres l’utilisent avec le contenu et la réputation de l’IP.
• Un domaine inconnu est traité presque comme un mauvais domaine. Un domaine sans historique fait l’objet d’un examen et d’une prudence accrus. Un domaine qui a un historique permet au fournisseur de messagerie de juger la qualité de son comportement dans le temps. Un sous-domaine utilisé correctement 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’adresses IP d’envoi ou modifier les en-têtes peut chacun exiger une montée en charge pour la nouvelle combinaison. Cela compte lorsque vous restructurez un programme existant, et pas seulement lors d’un lancement.

Il y a deux phases : la chauffe, pendant laquelle le domaine passe d’inconnu à repéré, puis la montée en charge, pendant laquelle le volume atteint progressivement le niveau prévu à long terme. Les stratégies varient selon les fournisseurs, mais certaines règles sont communes :

• Restez régulier. Les caractéristiques du contenu et les volumes ne devraient pas varier brutalement.
• Consultez les journaux SMTP pour repérer et traiter les problèmes de livraison pendant l’envoi.
• Inscrivez-vous aux programmes de données lorsqu’ils existent (Google Postmaster Tools ; Netease et Chengxin pour les fournisseurs chinois).
• Commencez bas et avancez 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 que le serveur de réception vérifie. Les articles sur chaque protocole détaillent la mécanique complète. Les points propres aux domaines d’envoi sont les suivants :

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

• Chaque domaine utilisé dans le Return-Path, le From: visible, le Sender: et le Reply-To: devrait avoir un enregistrement MX correct qui pointe 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 veulent vérifier qu’un message est légitime consultent d’abord le site web du domaine d’envoi.

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

C’est le cœur de la configuration des domaines des clients chez un ESP. Il existe 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 (comme un ESP) n’intervient. Une 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 enregistrements CNAME qui pointent vers la zone de l’ESP, afin que l’ESP puisse mettre à jour les valeurs des enregistrements sans solliciter la marque. Il peut 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.

Les enregistrements SPF et MX ne peuvent pas être des CNAME sur un nœud qui porte d’autres données, donc ils restent 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 :

L’avantage : l’ESP prend en charge toute la configuration DNS et garantit que la configuration d’authentification est correcte. L’inconvénient : la marque perd toute visibilité sur la zone. Elle abandonne le contrôle, ce 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, donc conservez le domaine choisi dans la durée. La réputation se construit progressivement, et ce sont des schémas d’envoi réguliers dans le temps qui comptent le plus. Lorsque vous migrez (vers un nouvel ESP, ou vers un nouveau domaine à cause d’un changement de nom ou de politique) :

• Appliquez ces pratiques à un programme existant qui fonctionne progressivement et avec discernement, et surveillez les indicateurs de délivrabilité à chaque changement de configuration.
• Période de chevauchement : les deux ESP peuvent envoyer en même temps si vous ajoutez les adresses IP du nouveau prestataire à l’enregistrement SPF et publiez 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 souhaité à long terme.

Documents M3AAWG cités

Ce BCP fait référence au BCP destiné aux expéditeurs (v3.0, févr. 2015 ; remplacé depuis par la version 4.0, août 2026, qui renvoie à ce BCP pour l’usage des domaines), à « 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 au « DKIM Key Rotation BCP » (mars 2019). Voir l’index des documents M3AAWG.

Voir aussi

• Pratiques d’infrastructure d’envoi, notamment les quatre domaines d’un message et les calendriers de chauffe des domaines
• Segmentation avancée des adresses IP
• SPF, DKIM et DMARC