Meilleures pratiques M3AAWG pour les expéditeurs (version 4.0)

Si vous envoyez des emails commerciaux, ou si vous exploitez un fournisseur de services de messagerie (ESP), ce document est la base convenue par le secteur pour configurer votre infrastructure d’envoi, recueillir le consentement, traiter les rebonds et les désabonnements, et contrôler vos clients. Il est publié par le comité Senders du Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) sous la forme d’un document de meilleures pratiques (Best Common Practices, BCP).

L’édition actuelle est M3AAWG Sender Best Common Practices, Version 4.0 (August 2026), document M3AAWG-158, à l’adresse https://www.m3aawg.org/senderbcp. C’est une refonte majeure qui remplace la version 3.0 (février 2015) et la version 2.0 (octobre 2011), ainsi que leurs résumés (Executive Summary). Les références de page ci-dessous renvoient au PDF de la version 4.0.

Il s’adresse aux professionnels de la délivrabilité et de la conformité chez les ESP et les gros expéditeurs, ainsi qu’aux équipes marketing et aux dirigeants qui valident les pratiques d’envoi. Il ne porte que sur l’email, et il précise qu’il ne constitue pas un avis juridique (Abstract, p. 1). Son objectif est la transparence : les destinataires et les fournisseurs de messagerie devraient pouvoir distinguer les messages légitimes des abus (§1, p. 2).

Deux déclarations posent le cadre :

Le M³AAWG affirme catégoriquement qu’un consentement opt-in de l’abonné clair, visible, éclairé et vérifiable est la meilleure pratique en matière d’autorisation d’envoi.

La conclusion (§6, p. 22) ajoute que « l’utilisateur final et ses attentes devraient être la priorité absolue ». Ce qu’autorise une loi ou une politique de confidentialité compte moins que ce que le destinataire veut et attend.

Au minimum, les expéditeurs doivent respecter les politiques d’utilisation acceptable des fournisseurs de messagerie et le droit national et régional applicable (§1, p. 2 ; les ressources réglementaires figurent à l’annexe B, p. 25).

Ce qui change par rapport à la version 3.0

• Structure. L’infrastructure vient désormais en premier, avant la collecte des adresses.
• Nouvelles recommandations. Réputation, chauffe et surveillance des domaines ; IPv6 ; utilisation de vos propres adresses IP ; surveillance des services ; sécurité des protocoles et données personnelles ; bombardement d’inscriptions (list bombing) ; email froid.
• Nouvelles exigences liées aux grands fournisseurs de messagerie. SPF, DKIM et un résultat DMARC positif ; désabonnement en un clic selon la RFC 8058 ; DNS inverse qui correspond exactement au DNS direct.
• Suppressions. L’estimation de la version 3.0 sur la part des rebonds synchrones a disparu. Sender ID, DomainKeys et Identified Internet Mail de Cisco sont listés comme obsolètes (p. 27).

La version 4.0 ne fixe ni seuils de taux de plaintes ou de taux de rebonds, ni calendrier de nouvelles tentatives, ni durée de conservation, ni délai de désabonnement, ni calendrier de chauffe d’IP. Elle n’aborde ni BIMI, ni ARC, ni les contenus générés par IA.

Infrastructure

Authentification des emails

L’authentification identifie l’expéditeur, ce qui permet aux serveurs de réception de juger le courrier sur l’historique d’un domaine authentifié et de détecter les falsifications (§2.1, p. 3). Le document résume trois mécanismes et renvoie aux M3AAWG Email Authentication Recommended Best Practices (2020) pour le détail :

• SPF vérifie l’adresse IP d’envoi par rapport au domaine de l’expéditeur d’enveloppe (Return-Path).
• DKIM ajoute une signature cryptographique, vérifiée par rapport à un domaine présent dans les en-têtes.
• DMARC permet au propriétaire du domaine From de voir qui envoie du courrier en l’utilisant, et de fixer une politique pour le courrier qui échoue à SPF et à DKIM.

Pour satisfaire aux exigences des grands fournisseurs de messagerie, les expéditeurs et leurs clients doivent envoyer un courrier qui dispose d’un enregistrement SPF pour le domaine de l’expéditeur d’enveloppe, qui porte une signature DKIM, qui dispose d’un enregistrement DMARC pour le domaine From, et qui passe DMARC grâce à un résultat SPF ou DKIM aligné (pp. 3–4). Les autres recommandations (p. 4) :

• Encouragez les clients à aligner à la fois SPF et DKIM lorsqu’ils le peuvent.
• Vérifiez que les enregistrements DNS des clients sont corrects lors de la configuration, puis à intervalles réguliers.
• Vérifiez au moment de l’envoi que chaque message passera l’authentification, et corrigez-le avant l’envoi si ce n’est pas le cas.
• Les plateformes d’envoi doivent signer avec DKIM et authentifier avec SPF en utilisant leur propre domaine pour les clients qui ne peuvent pas authentifier le leur.
• Signez avec DKIM à la fois avec le domaine de la plateforme et avec celui du client, pour profiter des feedback loops et des rapports fondés sur DKIM.
• Respectez toutes les RFC pertinentes.

Voir Meilleures pratiques M3AAWG pour l’authentification des emails et DMARC pour les recommandations de déploiement.

Traitement des rebonds et des NDR

La livraison n’est jamais garantie. Un système d’envoi doit pouvoir recevoir et traiter le courrier renvoyé, ou rapports de non-remise (NDR), au même volume et au même rythme qu’il envoie ; prévoyez donc des ressources pour le trafic SMTP dans les deux sens (§2.2, p. 4). Les ESP devraient fournir à leurs clients le texte détaillé des NDR, et pas seulement des totaux de rebonds « définitifs » et « temporaires », car les clients ont besoin du vrai message pour diagnostiquer les problèmes.

• Les retours sont généralement synchrones : le serveur de réception rejette le message pendant la conversation SMTP. Plus rarement, ils sont asynchrones : un message de rebond arrive à l’adresse Return-Path, parfois des heures ou des jours plus tard. La plupart des retours sont synchrones, mais la répartition dépend de la liste, et le courrier entre entreprises (B2B) peut connaître davantage de rebonds asynchrones. Quelle que soit la façon dont un rebond arrive, les expéditeurs doivent pouvoir identifier quelle adresse a rebondi.
• Les retours comportent un code d’état numérique et un message descriptif. La RFC 5321 définit les réponses SMTP de base, et la RFC 3463 définit les codes d’état étendus. Les codes suivent généralement les RFC, mais chaque serveur de réception rédige son propre texte, qui peut ne les suivre que de loin. Les expéditeurs doivent pouvoir traiter, classer et suivre les deux.

Échecs temporaires (4xx). Les causes incluent un serveur de réception surchargé, ou un serveur de réception qui a remarqué des schémas inhabituels provenant d’une adresse IP et a cessé d’accepter son courrier pendant un certain temps. Fermez la connexion et réessayez plus tard (p. 5). Le document laisse au logiciel d’envoi le choix du moment et de la fréquence des nouvelles tentatives, mais les serveurs de réception de très gros volumes attendent des expéditeurs qu’ils s’adaptent en temps réel, pour tout le courrier issu de la même adresse IP à la fois. Certains serveurs de réception renvoient délibérément un échec temporaire à un premier message, ou le placent en liste grise, pour voir si l’expéditeur respecte les RFC, car les spammeurs ne le font généralement pas. Ne traitez jamais un 4xx comme définitif.

Échecs définitifs (5xx). Le plus courant est « user unknown » (utilisateur inconnu), et de nombreuses réponses 5xx décrivent une violation de politique dans leur texte. Quel que soit le texte, ne réessayez jamais le message.

Traiter les NDR pour l’hygiène de base de données (pp. 5–6) :

• Les codes d’état indiquent au serveur de messagerie quoi faire du message, mais ils n’ont pas été conçus pour les gestionnaires de listes et ne disent pas s’il faut retirer l’adresse. Lisez le texte descriptif pour décider. Il peut aussi révéler un problème d’infrastructure ou de contenu, ou montrer que l’adresse IP d’envoi figure sur une liste de blocage et doit en être retirée avant que davantage de courrier ne passe.
• Toute organisation qui envoie de gros volumes doit disposer d’une procédure de traitement des NDR. Si le serveur de réception indique que l’utilisateur n’existe pas, ne réessayez pas, et ajoutez l’adresse à la liste de suppression pour les envois futurs. Les serveurs de réception utilisent le volume d’échecs définitifs comme donnée de réputation. De gros volumes de rebonds définitifs indiquent généralement un processus d’inscription mal géré ou une liste ancienne ou mal utilisée, et ils font baisser le score de réputation d’une adresse IP.
• Règle de retrait recommandée : retirez une adresse qui continue de rebondir, quel que soit le code ou le texte d’échec, sur plusieurs campagnes consécutives. Le nombre de campagnes et la période relèvent du choix de l’expéditeur, mais la meilleure pratique habituelle est d’au moins deux rebonds consécutifs sur deux semaines ou plus, ce qui tient compte des problèmes de serveur temporaires côté réception.

Traitement des plaintes et des feedback loops (FBL)

• Les ESP reçoivent la plupart des plaintes par les feedback loops automatisées des fournisseurs de messagerie, et certaines directement dans leur boîte abuse. Ils doivent disposer d’un système pour traiter les deux, et d’une procédure pour décider de la suite à leur donner (§2.3, p. 6).
• Les plaintes sont un facteur clé pour déterminer si des clients enfreignent les conditions générales de l’expéditeur ou se comportent simplement mal.
• Les ESP devraient s’inscrire à toutes les feedback loops automatisées auxquelles ils ont accès, et surveiller chacune pour vérifier qu’elle continue d’envoyer des données.
• Référence : M3AAWG Recommendations for Senders Handling of Complaints. Voir l’index des documents M3AAWG pour l’écosystème des FBL (formats, liste des fournisseurs).

Services de transfert

Si un ESP fournit à de petits clients des adresses sur son propre domaine d’envoi (utilisées dans les en-têtes des messages), il peut devoir leur transférer les réponses. Il devrait alors exploiter un véritable service de transfert de courrier (§2.4, p. 6). Pour les détails, voir les M3AAWG Email Forwarding Best Common Practices, version 2 (https://www.m3aawg.org/documents/en/m3aawg-email-forwarding-best-common-practices-version-2).

Réputation, chauffe et surveillance des domaines

Chaque nom de domaine présent dans un message, dans les en-têtes comme dans le corps, contribue à la réputation de l’expéditeur, et les filtres en tiennent compte avec le contenu et la réputation de l’adresse IP (§2.5, p. 6). Un domaine nouvellement enregistré qui envoie un gros volume peu après son enregistrement éveille les soupçons. C’est aussi le cas d’un domaine établi qui n’a jamais envoyé de courrier et qui se met soudain à en envoyer beaucoup, car les spammeurs utilisent ces deux tactiques pour échapper à la détection.

Chauffe de domaine (pp. 6–7). Un nouveau domaine n’a pas d’historique d’envoi, et les fournisseurs de messagerie traitent une réputation inconnue avec presque autant de prudence qu’une mauvaise. La chauffe consiste à augmenter le volume progressivement pour que les fournisseurs puissent évaluer le courrier. Chauffez aussi un nouveau sous-domaine, même lorsque le domaine organisationnel a déjà une bonne réputation. Le document qualifie les pratiques de chauffe artificielle de « non recommandées » et de possiblement illégales. Ses recommandations :

• Commencez avec un faible volume et augmentez-le lentement. Le document propose d’envisager une chauffe de 6 semaines en moyenne, sans en faire une règle fixe.
• Répartissez les messages de chaque jour sur la journée plutôt que de les envoyer en un seul lot.
• Envoyez des campagnes régulièrement jusqu’à ce que le domaine soit chauffé.
• Surveillez les journaux SMTP pour repérer les reports de remise et les rebonds. Si les reports de remise augmentent brusquement, ralentissez pour certains domaines de réception ou pour tous, et vérifiez que le contenu et la liste reposent sur l’opt-in et l’engagement.
• Consultez les données de réputation du domaine et des adresses IP avec les outils du secteur, et surveillez les pics de désabonnements et de plaintes.
• Surveillez les ouvertures et les clics. Un pic important peut venir d’équipements de sécurité qui inspectent le courrier, et des pics persistants peuvent demander une correction. Une baisse peut signifier que le courrier arrive dans le dossier spam.

Surveillance des domaines (p. 7). Continuez à surveiller la réputation du domaine après la chauffe. L’annexe A (pp. 24–25) liste des outils, dont Google Postmaster Tools, Microsoft SNDS, Yahoo Sender Hub, Sender Score, Cisco Talos, Google Safe Browsing, la Spamhaus DBL, SURBL et DNS Twist.

Domaines sosies (pp. 7–8). Évitez d’envoyer depuis des domaines qui ressemblent au domaine principal de votre marque, comme example-promo.com à côté de example.com. Ils habituent les utilisateurs à faire confiance à des variantes de votre domaine, ce qui rend les domaines de phishing plus crédibles, et chacun multiplie les variantes par faute de frappe ou par homoglyphe que vous devez surveiller. Enregistrez à titre défensif les domaines sosies évidents, et n’envoyez pas depuis ces domaines. N’utilisez jamais un domaine sosie pour contourner des problèmes de réputation sur votre domaine principal : c’est un comportement de spammeur. Utilisez un sous-domaine lorsque vous devez séparer des parties de l’activité. Pour les cas où des domaines sosies sont acceptables à des fins de sécurité, le M3AAWG publie un document de meilleures pratiques distinct.

Enregistrements MX et A, et pages d’atterrissage (p. 8). Tout domaine utilisé dans l’expéditeur d’enveloppe ou dans l’en-tête From devrait avoir un enregistrement MX. Certains serveurs de réception refusent le courrier d’un domaine d’envoi qui n’a pas d’enregistrement A valide. Chaque domaine et sous-domaine présent dans un message, y compris le domaine de suivi des clics, devrait mener au site de l’organisation propriétaire ou à une page anti-abus lorsqu’on le saisit dans un navigateur.

Le domaine du client ou le sous-domaine de l’ESP (pp. 8–9). Les ESP devraient, chaque fois que c’est possible, faire placer par leurs clients leur propre domaine ou sous-domaine dans l’en-tête From visible, pour que chaque client construise sa propre réputation. Utilisez des sous-domaines nommés d’après la finalité du courrier, comme offers.mybrand.com pour le marketing et info.mybrand.com pour le courrier transactionnel. Envoyer depuis le domaine de l’ESP est une solution de repli pour les petits expéditeurs qui ne peuvent pas modifier leur DNS, et c’est mieux qu’envoyer sans authentification. Dans ce cas, l’ESP devrait donner à chaque marque son propre sous-domaine d’un domaine partagé, comme brand01.shared.esp.com. Un seul sous-domaine partagé par tous les clients, ou par pool, est possible mais non recommandé, car il complique le dépannage et masque l’origine des abus.

Cohérence et alignement (pp. 9–10). Les fournisseurs de messagerie peuvent utiliser n’importe quel domaine du message ou de la transaction SMTP pour juger la réputation : l’expéditeur d’enveloppe, l’en-tête From, le domaine de signature DKIM, le nom HELO, le nom de DNS inverse, l’adresse Reply-To et les liens. Utilisez un même domaine organisationnel ou sous-domaine partout, ce que DMARC peut de toute façon exiger. Soyez prudent avec les domaines partagés entre expéditeurs, comme un domaine de suivi des clics qu’un ESP fournit à tous ses clients : si un expéditeur le fait bloquer, les autres en pâtissent aussi. Lorsque des domaines uniques ne sont pas possibles, donnez à chaque expéditeur un sous-domaine unique. Voir Meilleures pratiques M3AAWG pour les domaines d’envoi.

Détails techniques des IP (DNS direct, DNS inverse, HELO)

Les recommandations du BCP sur les IP sont rédigées pour IPv4, et elles constituent le minimum à suivre (§2.6, p. 10). Leur intention est de rendre la propriété transparente, et la responsabilité claire aux yeux des systèmes de réputation et de filtrage.

DNS direct (pp. 10–11)

• Il DOIT être choisi un nom qui identifie clairement le domaine de la partie responsable : l’ESP ou le fournisseur lorsque l’adresse IP est partagée, et normalement le client ou l’annonceur lorsqu’elle est dédiée (dans ce cas, c’est l’administrateur du domaine du client qui configure le DNS direct).
• Le nom doit clairement désigner un serveur, et non un espace générique de pool : server03.espname.com, et non pool-dhcp-456.espname.com.
• Si plusieurs noms pointent vers la même adresse IP partagée, le nom retenu est le « nom principal ».
• Sauf pour les adresses IP dédiées, tous les serveurs de messagerie de l’ESP ou de l’annonceur doivent utiliser le même nom, ou un petit ensemble de noms, au « niveau du registre de domaine », avec des sous-domaines pour les distinguer : utilisez server1.espname.com et server2.espname.com, et non espname01.com et espname02.com.

DNS inverse (p. 11 ; voir la RFC 1912 sur l’exploitation du DNS)

• Chaque adresse IP d’envoi doit avoir un DNS inverse (un enregistrement PTR ou IN-ADDR) configuré.
• Chaque adresse IP n’a qu’un seul nom de DNS inverse.
• Il doit correspondre exactement au nom principal du DNS direct. La version 4.0 précise que les grands fournisseurs de messagerie l’exigent désormais pour le courrier qui leur est envoyé directement.

HELO et EHLO (p. 11 ; ils entrent en compte dans l’authentification SPF)

• Le nom doit être un nom d’hôte qui se résout. Un littéral d’adresse IP entre crochets ([]) n’est pas acceptable, sauf entre serveurs de messagerie internes.
• Adresse IP dédiée : le nom HELO DOIT correspondre exactement au nom principal du DNS direct.
• Adresse IP partagée, ou NAT vers plusieurs serveurs : le nom HELO doit correspondre au nom principal au moins au niveau du registre de domaine ; une correspondance exacte convient aussi. Il est recommandé de donner à chaque système de messagerie ou client derrière un NAT son propre sous-domaine HELO (par exemple server01.brand1.espname.com), pour faciliter le diagnostic.
• Le domaine utilisé dans le nom HELO et dans le DNS inverse devrait recevoir du courrier (un enregistrement MX et un serveur de messagerie), avec des adresses postmaster et abuse fonctionnelles, comme l’exigent la RFC 5321 et la RFC 2142. Il devrait aussi avoir un enregistrement A et un serveur web qui redirige vers le domaine principal du propriétaire.

IPv6 (pp. 11–12). Suivez au minimum les recommandations IPv4 sur le DNS inverse, conservez des enregistrements PTR et MX valides, et redoublez d’attention pour la réputation du domaine. Un fournisseur reçoit généralement un /32, qu’il peut diviser en réseaux /48 ou /64 pour ses clients. La plus petite allocation à attribuer à un client est un /64. Voir Envoyer des emails en IPv6.

Utiliser vos propres adresses IP (p. 12). Certains fournisseurs permettent aux expéditeurs d’utiliser des adresses IP qui leur appartiennent, ce qui évite de chauffer de nouvelles adresses et laisse l’expéditeur maître de son parc d’adresses. Peu de fournisseurs le proposent. Lorsqu’ils le font :

1. Vérifiez la propriété et le contrôle des adresses, par RDAP, par une lettre d’autorisation signée (Letter of Authorization, LOA) ou par d’autres moyens.
2. N’acceptez aucune plage IPv4 plus petite qu’un /24.
3. Les adresses doivent avoir un historique propre.
4. Publiez un DNS inverse qui pointe vers le domaine du propriétaire, et non vers celui de l’ESP.
5. Le fournisseur précédent doit cesser d’envoyer depuis ces adresses avant que la nouvelle annonce de routage soit terminée.

Voir IP Acquisition Diligence.

Environnements à adresses IP partagées ou dédiées

Définitions (p. 12) :

• Environnement dédié : une seule entité distincte a l’usage exclusif et la responsabilité du courrier sortant qui y transite (une ou plusieurs adresses IP, exactement une entité responsable).
• Environnement partagé : plusieurs entités sont affectées à une adresse IP ou à un pool d’adresses IP.
• Une « entité » est la partie responsable de l’envoi du message : une entreprise, une marque au sein d’une entreprise, ou un client d’ESP.

Raisons de choisir un environnement dédié (p. 13) :

• La qualité du courrier ou de la liste est inconnue ou inférieure à la moyenne. L’isoler protège les autres, ou permet d’établir et de suivre sa qualité.
• La qualité du courrier est connue pour être supérieure à la moyenne. L’isoler la protège des effets des autres.
• La maîtrise des schémas de volume. Mélanger courrier transactionnel et courrier marketing, ou plusieurs entités, crée un trafic irrégulier, et la régularité du volume fait partie intégrante de la réputation d’une adresse IP, en particulier chez les fournisseurs de messagerie gratuite, les grands domaines et les petites entreprises hébergées par de grands fournisseurs. (La régularité du volume n’est généralement pas un indicateur utile pour les petites entreprises qui hébergent leur propre messagerie et prennent des décisions automatisées.)
• L’entité veut assumer toute la responsabilité, plutôt que de voir son courrier attribué à l’ESP, ou a besoin de ses propres réglages de MTA sortant.
• Une certification, une inscription sur liste blanche ou d’autres services de délivrabilité avancés qui exigent un environnement dédié.

Raisons de choisir un environnement partagé (p. 13) :

• La combinaison des volumes maintient un volume d’envoi moyen régulier, ce qui établit et entretient la réputation de l’adresse IP.
• La réputation est partagée, si bien que les erreurs d’un expéditeur isolé sont diluées.
• Le coût est moindre, ce qui rend l’envoi économiquement possible pour les très petits expéditeurs.

Recommandations de provisionnement (pp. 13–14) :

• Les entités d’un environnement partagé devraient avoir un contenu et des indicateurs similaires (taux de plaintes et taux de rebonds). Le contrôle demande un soin particulier, car les mauvaises pratiques d’une entité peuvent « empoisonner » le pool.
• Dans les environnements partagés, signez le courrier de chaque entité avec DKIM en utilisant un domaine ou un sous-domaine unique. Cela permet aux serveurs de réception de distinguer les flux, permet à chaque entité de participer à DMARC, et permet à une entité de conserver la réputation qu’elle a acquise si elle est déplacée.
• Meilleure pratique, même si le document reconnaît qu’elle est difficile : authentifier en même temps le domaine de l’ESP et celui de l’entité.
• Les ESP qui proposent les deux modèles devraient définir à l’avance les critères de passage d’une entité du partagé au dédié, et surveiller si ces critères sont remplis.
• Meilleures pratiques pour les expéditeurs sur adresses IP dédiées : un DNS inverse propre à l’entité (par exemple entity.cust.esp.com, qui montre clairement qui est responsable) ; une procédure de chauffe d’IP bien définie et appliquée de façon cohérente ; une aide aux entités pour obtenir une inscription sur liste blanche lorsque c’est possible ; et une aide aux entités pour garder un volume d’envoi moyen régulier, afin que la réputation se construise.

Voir aussi Allocation de base des adresses IP et Segmentation et allocation avancées des adresses IP.

Surveillance des services

Au-delà de vérifier que les serveurs fonctionnent, la plateforme d’un expéditeur devrait surveiller les signes de compromission de clients, de prise de contrôle de comptes, d’abus des formulaires d’inscription et de problèmes de réputation (§2.7, pp. 14–15). Les ESP sont encouragés à combiner des règles automatisées et un examen humain. Voici les signaux que liste le document, qui précise que la liste n’est pas exhaustive :

• Volume anormal. Un client qui envoie plus de 40 % au-dessus de son volume habituel peut être signalé. La cause peut être un attaquant, ou une erreur du client qui appelle un accompagnement.
• Croissance anormale de la liste. Un bond soudain après une croissance régulière peut indiquer un relâchement de la conformité. Validez les adresses ajoutées.
• Taux de rebonds par fournisseur de messagerie. Les taux globaux montrent les problèmes majeurs. Les taux par fournisseur révèlent les échecs d’authentification, les boucles de routage, les enregistrements PTR absents ou invalides, les limites de connexion dépassées, et les problèmes de réputation d’IP ou de liste de blocage.
• Une authentification non conforme aux mécanismes choisis.
• Des connexions depuis des lieux inhabituels, qui peuvent signaler des comptes compromis.
• Un lien de désabonnement absent, ce qui compte au regard de CAN-SPAM, de la LCAP et de la directive ePrivacy, ainsi que pour la délivrabilité.
• Des tailles de message inhabituelles, qui peuvent signaler un logiciel malveillant ou des pièces jointes nuisibles.
• Formulaires d’inscription : pics d’abonnements pour un client, et une même adresse inscrite sur plusieurs comptes.
• Redirections de liens : variations du volume de clics, nombreux clics sur les liens d’un même destinataire, et liens signalés par les éditeurs anti-phishing.
• Contenu : changements soudains ou nouvelles URL, mots-clés abusifs, autres anomalies, et images hébergées au contenu abusif.

Voir Outbound Monitoring.

Sécurité des données

Les expéditeurs qui stockent les adresses de leurs abonnés ou d’autres données personnelles sont fortement encouragés à mettre en place un programme de sécurité complet, fondé sur les pratiques standard du secteur (§2.8, pp. 15–16). Le document cite OWASP et SANS comme points de départ, ainsi que le rapport de la Federal Trade Commission (FTC) américaine sur la vie privée des consommateurs. Son annexe A (p. 24) ajoute le « Data Protection and Breach Readiness Guide » de l’Online Trust Alliance et ISO/IEC 27002:2013 (Access Control ; Communications and Operations Management ; Information Security Incident Management). Le M3AAWG recommande fortement de faire de la sécurité une considération primordiale : les données d’adresses email stockées ont de la valeur pour les criminels, même lorsqu’il ne s’agit « que » d’adresses email.

Sécurité des protocoles (p. 16). Chiffrez chaque flux de messages en transit, quel que soit le type d’expéditeur. La référence TLS for Mail du M3AAWG couvre le TLS opportuniste, qui reste exposé aux attaques de l’intercepteur (machine-in-the-middle). Ses recommandations complémentaires couvrent DANE et MTA-STS, qui offrent une garantie plus forte mais tolèrent moins bien les défaillances. Les images, les vidéos et les liens d’appel à l’action devraient tous utiliser HTTPS. Des fournisseurs de messagerie ont laissé entendre que des ressources sans HTTPS peuvent nuire à la réputation et au placement. Voir TLS Baseline et MTA-STS.

Données personnelles (pp. 16–17). Les règles applicables (RGPD, DPA, HIPAA et autres) dépendent de l’endroit où se trouve le client de l’expéditeur, de l’endroit où se trouve le destinataire ou de sa nationalité, et de l’endroit où l’ESP exerce son activité. Les liens d’un message, comme les liens de suivi, de préférences et de désabonnement, sont journalisés par des équipements réseau et des serveurs ; ils devraient donc masquer l’adresse du destinataire et ses autres données personnelles. Ne placez pas de données personnelles dans une URL, ni en clair ni dans un encodage facilement réversible comme base64. Utilisez une valeur chiffrée, ou un identifiant sans rapport avec le destinataire que seul l’ESP peut faire correspondre. Les pages d’atterrissage devraient masquer les données personnelles qu’elles affichent (par exemple a**z@example.com), ne devraient pas être faciles à découvrir, et devraient recourir à la pseudonymisation.

WHOIS

• Tenez à jour des enregistrements WHOIS (ou rWHOIS) exacts pour les domaines qui assument la responsabilité de grands volumes de courrier (§3, p. 17).
• Les sous-allocations d’adresses IP de /29 ou plus (IPv4) et de /56 ou plus (IPv6) doivent être documentées de façon exacte et complète, comme l’exige la politique du registre Internet régional (RIR, par exemple l’ARIN).
• L’enregistrement de domaine anonyme ou par proxy va à l’encontre de la transparence. Les entités qui n’ont pas l’intention d’abuser des réseaux de messagerie n’ont aucune raison commerciale sérieuse d’avoir des enregistrements WHOIS volontairement vagues.

Consentement : les trois niveaux d’opt-in

Les recommandations sur la collecte des adresses s’appliquent au courrier marketing comme au courrier transactionnel (§4, p. 17). Le M3AAWG rédige aussi un document de meilleures pratiques distinct sur la gestion des listes.

La règle principale : l’expéditeur doit disposer du consentement explicite du destinataire avant l’envoi, et avant d’ajouter le destinataire à toute communication régulière (§4.1, p. 17). Chaque niveau ci-dessous s’appuie sur le précédent.

Niveau 1 : exigences du simple opt-in

Utilisez le simple opt-in avec une extrême prudence (p. 18). Des adresses non confirmées, qu’il s’agisse de fautes de frappe ou de falsifications pures et simples, peuvent être ajoutées sans aucun contrôle. Cela crée un consentement invalide, qui entraîne des plaintes, des rebonds et une dégradation de la réputation. Si vous l’utilisez :

1. Le destinataire doit donner son consentement en connaissance de cause au moment où l’adresse est collectée.
2. Le consentement doit être clair et évident, et non caché en petits caractères, noyé dans du jargon juridique ou placé sur une page séparée.
3. L’inscription doit indiquer clairement le type précis de liste, ou de listes, que la personne rejoint. Si possible, laissez les destinataires choisir les listes dans lesquelles ils sont inclus ou dont ils sont exclus. Plus les destinataires ont de contrôle, moins vous recevez de signalements d’abus.
4. Informez les destinataires de la fréquence et du type de communications prévus, et laissez-leur le choix pour chacun. Une hausse inattendue de la fréquence entraîne souvent davantage de plaintes pour abus.
5. N’utilisez les adresses que pour les finalités annoncées lors de l’inscription. Une finalité secondaire créée plus tard (par exemple une nouvelle newsletter au contenu différent) exige un opt-in distinct, qui ne doit pas être activé par défaut. Jugez de ce qui constitue une finalité secondaire du point de vue du destinataire. Certaines juridictions exigent légalement cette autorisation distincte.
6. Envisagez de montrer un exemple de l’email que l’abonné recevra, pour qu’il le reconnaisse à son arrivée.
7. Au moment de la collecte de l’adresse, envisagez de conserver des preuves du consentement : l’adresse IP, la date de collecte, et le site web ou l’événement où elle a eu lieu, et, dans les grandes entreprises, quel service a collecté l’adresse et comment (p. 19). Ces preuves devraient être faciles à retrouver s’il faut prouver le consentement à une personne, à un FAI, à un opérateur de liste de blocage (RBL) ou à une autorité de contrôle, et le droit applicable au stockage des données personnelles doit être pris en compte.

Niveau 2 : ajout du message de notification

Envoyez le message de notification ou de bienvenue immédiatement, ou dans les 24 heures suivant l’inscription (p. 19). Il devrait :

• inclure l’adresse fournie et toute autre information donnée par l’utilisateur ;
• être traité comme un rebond s’il rebondit, et l’adresse être retirée de la liste ;
• indiquer la fréquence et le type de contenu ;
• utiliser la même adresse From que les futurs messages, pour que les destinataires puissent l’ajouter à leur carnet d’adresses ;
• si possible, être envoyé depuis des adresses IP séparées des adresses IP d’envoi en masse habituelles.

Niveau 3 : opt-in confirmé

C’est le niveau le plus exigeant (p. 19). Il empêche les fautes de frappe et les adresses soumises par malveillance d’entrer dans les envois réguliers. En outre :

• quand l’utilisateur soumet le formulaire, indiquez-lui de consulter sa messagerie et de donner suite au message de confirmation ;
• gardez l’email de confirmation simple et sans publicité, pour qu’il ne soit pas filtré comme un abus ;
• lorsqu’un utilisateur change d’adresse email, confirmez la nouvelle adresse de la même façon.

Voir Méthodes de consentement.

Bombardement d’inscriptions (list bombing)

Lors d’une attaque par bombardement d’inscriptions, un script soumet l’adresse d’une victime à des centaines de formulaires d’inscription, si bien que les messages de confirmation et de bienvenue inondent la boîte de réception de la victime jusqu’à la rendre inutilisable (§4.2, pp. 19–20). Chaque formulaire contribue peu, et un site isolé remarque donc rarement qu’il participe à une attaque. Le M3AAWG recommande de superposer plusieurs défenses :

1. Un CAPTCHA sans lequel le formulaire ne peut pas être soumis.
2. Limitez les systèmes autorisés à soumettre des données à votre backend, pour que le formulaire ne puisse pas être cartographié et automatisé.
3. Des limites de débit sur les soumissions répétées depuis une même adresse IP.
4. Si vous hébergez de nombreux formulaires, surveillez l’ajout d’une même adresse à plusieurs d’entre eux.
5. Pour un service limité à une région, n’affichez le formulaire qu’aux adresses IP de cette région.
6. Un champ caché que seul un robot remplirait ; rejetez les soumissions qui le remplissent.
7. Un horodatage ou une clé posés au chargement de la page ; rejetez les soumissions qui arrivent trop vite ou qui en sont dépourvues.
8. Des noms de champs inhabituels, que les scripts qui cherchent les noms courants ne trouvent pas.
9. Déplacez vers une nouvelle URL un formulaire qui a été attaqué.
10. Envisagez d’ajouter l’en-tête Form-Sub proposé dans un Internet-Draft (https://datatracker.ietf.org/doc/html/draft-levine-mailbomb-header-02) à l’intention des fournisseurs de messagerie destinataires.

Voir Subscription Bombing.

Consentement implicite

Le consentement implicite est déduit d’une interaction. Le cas typique est une adresse email collectée en caisse sans aucune indication qu’elle sera ajoutée à des listes marketing. Il n’est pas considéré comme une meilleure pratique et devrait être évité lorsque c’est possible : il ne convient pas à tous les expéditeurs, et il risque de provoquer des plaintes pour abus (§4.3, p. 20).

Si vous l’utilisez, surveillez de près les plaintes, les ouvertures et les clics de ce segment. Il vaut mieux ajouter une case distincte non cochée de consentement explicite lors de la collecte de l’adresse, ou mener une campagne de confirmation de l’autorisation (permission pass) avant d’envoyer d’autres messages marketing. Quelle que soit la méthode, conservez pour chaque adresse la trace de la façon dont elle est entrée dans la liste : l’adresse IP d’inscription, l’heure, une capture d’écran du texte d’information, et les politiques de confidentialité en vigueur au moment de l’abonnement. Les lois sur la conservation des données varient d’une juridiction à l’autre.

Enrichissement de fichiers (email append)

Associer à une fiche client une adresse email que le client n’a jamais fournie à cette fin est une violation directe des valeurs fondamentales du M3AAWG (§4.4, pp. 20–21). C’est une pratique abusive, qui génère des plaintes et crée un risque juridique au regard du droit de la vie privée et des lois anti-spam. Voir la prise de position du M3AAWG sur l’enrichissement de fichiers (Position on Email Appending, mise à jour en 2019 : https://www.m3aawg.org/sites/default/files/doc_files/m3aawg_apending_position_update-2019-01.pdf).

Email froid

La version 4.0 résume en un paragraphe la position du M3AAWG sur l’email froid (§4.5, p. 21). Elle définit l’email froid comme un courrier non sollicité, envoyé par une entreprise par ailleurs légitime qui cherche à nouer une relation avec une personne sans relation préalable avec elle, et elle indique que le M3AAWG considère ces emails comme abusifs. Pour la position complète, elle renvoie au document distinct M3AAWG Position on Cold Email : voir Position du M3AAWG sur l’email froid.

Exigences de désabonnement

La liste ci-dessous suit la numérotation du §4.6 (pp. 21–22).

1. Rendez la procédure de désabonnement aussi claire et simple que raisonnablement possible.
2. Traitez toutes les demandes de désabonnement sans délai, à la fois pour respecter la loi et par respect pour le destinataire.
3. Fixez les attentes : indiquez le délai de traitement et les listes ou types de communications concernés. Plus le retrait prend de temps, plus il est probable que les emails suivants soient jugés abusifs et signalés.
4. Soyez en mesure de traiter les demandes de désabonnement envoyées par email aux adresses From et Reply-To de vos messages sortants.
5. Le lien de désabonnement devrait contenir tout ce qu’il faut pour mener le désabonnement à bien : l’identifiant de l’abonné, la liste concernée (s’il y en a plusieurs), et des jetons d’authentification propres à chaque utilisateur s’ils sont nécessaires pour empêcher des tiers de désabonner des personnes par malveillance.
6. Utilisez l’en-tête List-Unsubscribe (RFC 2369) dans chaque message :
   • variante mailto : une adresse encodée propre à chaque destinataire. Tout message reçu à cette adresse peut être traité comme un désabonnement de ce destinataire, même s’il n’a pas été envoyé depuis l’adresse abonnée.
   • variante URL : un lien en un clic vers la fonction de désabonnement de la plateforme (il peut s’agir du même lien que dans le corps). Encodez toute information personnelle dans le lien, pour éviter les abus et rendre le lien aussi simple que possible à utiliser.
   • Désabonnement en un clic : pour satisfaire aux exigences mises à jour des grands fournisseurs de messagerie, les expéditeurs « doivent mettre en place le désabonnement en un clic (List-Unsubscribe-Post) », comme le décrit la RFC 8058. La version 3.0 ne l’exigeait pas. Voir List-Unsubscribe et désabonnement en un clic.
7. Définissez une politique pour les désabonnements lorsqu’aucun centre de préférences ne peut être affiché : le désabonnement s’applique-t-il à tous les envois ou à une seule liste ? Le choix par défaut recommandé est de retirer le destinataire de tous les envois.
8. Dans un centre de préférences qui propose plusieurs options, l’option de désabonnement devrait être cochée par défaut pour les listes auxquelles l’utilisateur est actuellement abonné.
9. Utilisez des descriptions textuelles lisibles, et non des images, à côté des liens de désabonnement en un clic.
10. Envisagez des moyens de se désabonner hors ligne (une adresse postale, un numéro de téléphone), avec des numéros locaux ou gratuits, pour que le coût pour la personne soit faible ou nul.
11. Les offres de nouveaux abonnements présentées aux abonnés qui reviennent devraient être décochées par défaut.
12. Les abonnés doivent pouvoir se désabonner sans se connecter ni passer de contrôle de sécurité. Un centre de préférences protégé par une connexion est acceptable en complément, mais le désabonnement d’une liste précise doit fonctionner en dehors de toute zone sécurisée.
13. Fortement recommandé : indiquez dans le corps du message l’adresse email abonnée du destinataire. C’est particulièrement utile lorsque plusieurs adresses sont transférées vers une même boîte de réception. Tenez compte des lois sur les données personnelles lorsque vous le faites.
14. L’adresse de l’abonné « ne devrait pas être visible dans le lien de désabonnement lui-même ». Utilisez une référence encodée plutôt que l’adresse en clair.

Contrôle des clients (ESP)

Les ESP qui envoient de grands volumes d’emails pour le compte de leurs clients sont à la merci des pires pratiques de leurs pires clients.

• Tous les ESP doivent disposer d’une procédure de contrôle avant envoi, pour repérer les expéditeurs malveillants avant qu’ils n’envoient du courrier (§5, p. 22).
• Tous les ESP doivent disposer d’une procédure de contrôle après envoi, qui surveille les clients une fois qu’ils ont commencé à envoyer.
• Un bon contrôle distingue les vrais spammeurs des clients qui ont seulement besoin de conseils en hygiène de base de données. Le contrôle est essentiel à la réputation et à la réduction des abus.
• Guide détaillé : M3AAWG Vetting Best Common Practices (https://www.m3aawg.org/sites/default/files/doc_files/MAAWG_Vetting_BCP_2011-11.pdf). Voir Customer Vetting.

Termes clés du glossaire (annexe C, d’après la RFC 5598)

Voir aussi

• Meilleures pratiques M3AAWG pour l’authentification des emails
• Meilleures pratiques M3AAWG pour les domaines d’envoi
• Index des documents M3AAWG, qui recense d’autres documents du M3AAWG pour les expéditeurs et les ESP, et des ressources sur les FBL
• Fondamentaux de la délivrabilité des emails
• Les deux mondes de la délivrabilité email
• Recommandations pour la chauffe d’IP
• Segmentation et allocation avancées des adresses IP
• Pratiques d’infrastructure d’envoi