# emailmarketing.net — full text (Français)

> Every published emailmarketing.net knowledge base article in Français. Published by the team behind Cakemail. Index: https://emailmarketing.net/llms.txt

# ARC (Authenticated Received Chain)

> Référence RFC 8617 : les trois champs d'en-tête ARC, les balises d'instance et de validation de la chaîne, les règles de scellement et de validation, et la façon dont les serveurs de réception s'appuient sur une chaîne intacte pour passer outre les échecs DMARC causés par le transfert.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/arc

Quand un message passe par un service de transfert ou une liste de diffusion, il peut échouer à [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) chez le serveur de réception final alors que l'expéditeur d'origine l'avait correctement authentifié. Les services de transfert et les listes de diffusion cassent couramment [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf), parce que l'adresse IP d'envoi change, et cassent souvent [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim), parce qu'ils ajoutent des balises d'objet ou des pieds de page, ou réécrivent le corps. C'est le problème du **flux de messagerie indirect**.

ARC, défini dans la RFC 8617 (statut expérimental), y répond. Chaque intermédiaire enregistre les résultats d'authentification qu'il a constatés à l'arrivée du message, et les scelle cryptographiquement, ce qui construit une chaîne de responsabilité vérifiable. Le serveur de réception final peut alors voir que le message était correctement authentifié **avant** que le service de transfert ne le modifie, et peut choisir de passer outre un échec DMARC.

ARC rapporte ce que les intermédiaires ont vu. C'est un signal supplémentaire, **pas** un remplacement de SPF, DKIM et DMARC, et il ne rend pas à lui seul un message digne de confiance. Un spammeur peut sceller son propre spam, donc la réputation de l'entité qui scelle compte.

## L'ARC Set : trois champs d'en-tête par saut

Chaque intermédiaire qui participe (un « scelleur ARC ») ajoute un **ARC Set** de trois en-têtes, qui portent tous le même numéro d'instance `i=` :

| En-tête | Abrév. | Contenu | Signe |
|---|---|---|---|
| `ARC-Authentication-Results` | AAR | Les résultats SPF, DKIM et DMARC (et ARC) que ce saut a constatés à la réception du message, dans le même format que l'[en-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results). | (pas une signature) |
| `ARC-Message-Signature` | AMS | Une signature semblable à celle de DKIM (avec la même syntaxe de balises : `a=`, `b=`, `bh=`, `d=`, `s=`, `h=`, …) sur les **en-têtes et le corps** du message tels que ce saut les a transmis. Par elle, le saut prend la responsabilité des modifications qu'il a apportées. Elle utilise la canonicalisation relaxed, et ne doit pas signer les champs ARC-Seal ou Authentication-Results existants. | En-têtes et corps |
| `ARC-Seal` | AS | Scelle la chaîne elle-même. Il signe **uniquement des champs d'en-tête** (pas le corps) : tous les ARC Sets précédents plus l'AAR et l'AMS de ce saut, dans l'ordre AAR, AMS, AS pour chaque instance. Il porte le verdict de validation de la chaîne `cv=`. | En-têtes ARC uniquement |

### Balises principales

| Balise | Sur | Valeurs et règles |
|---|---|---|
| `i=` | les trois | Le numéro d'instance qui relie un ensemble : **1–50**, augmenté de 1 à chaque saut. Les numéros d'instance doivent former une suite continue 1..N, avec exactement un champ de chaque type pour chaque instance. Plus de 50 ensembles, ou une suite rompue, font échouer la chaîne. |
| `cv=` | ARC-Seal | L'état de validation de la chaîne tel que ce scelleur l'a vu : `none` (aucune chaîne n'existait, il s'agit donc du premier saut), `pass` (la chaîne précédente a été validée) ou `fail` (la chaîne précédente a échoué à la validation). |
| `d=`, `s=`, `a=`, `b=`, `t=` | AMS, AS | Comme dans DKIM : le domaine de scellement, le sélecteur (la clé est publiée à `<selector>._domainkey.<domain>`), l'algorithme, la signature et l'horodatage. |

## Validation de la chaîne (algorithme du serveur de réception)

1. Rassemblez tous les ARC Sets. La chaîne **échoue** s'il y en a plus de 50, ou si la suite d'instances 1..N est rompue, dupliquée ou incomplète.
2. Si l'ARC-Seal de l'instance la plus élevée porte `cv=fail`, la chaîne **échoue**.
3. Validez la signature de l'**AMS la plus récente** (l'instantané du message pris par le dernier responsable). Les signatures AMS plus anciennes peuvent aussi être vérifiées, pour trouver le point le plus ancien où le message passait encore.
4. Validez **chaque ARC-Seal**, de l'instance la plus élevée à la plus basse. Chaque sceau doit être vérifié sur tous les ensembles qu'il couvre.
5. Si toutes les vérifications réussissent, l'état de la chaîne est **pass**. Sinon, il est **fail**.

Une chaîne en échec ou absente signifie simplement qu'ARC n'apporte aucune information exploitable. Jugez le message sur ses résultats SPF, DKIM et DMARC habituels.

## Règles de scellement

- Un scelleur enregistre les résultats qu'il a constatés dans un nouvel AAR, signe le message avec une AMS, puis le scelle avec un AS dont la valeur `cv=` reflète l'état de la chaîne qu'il a trouvée.
- Si le scelleur a trouvé une **chaîne mal formée ou en échec**, il ne doit pas la prolonger comme si elle était valide. Il scelle avec `cv=fail`, et la portée `b=` de l'AS **DOIT couvrir uniquement l'ARC Set créé par le MTA qui a détecté l'échec** (et non les ensembles précédents rompus).
- Les scelleurs devraient sceller uniquement le courrier qu'ils ont réellement traité et évalué. Sceller revient à affirmer une responsabilité, garantie par la réputation du domaine de scellement.

## Comment les serveurs de réception et les évaluateurs DMARC utilisent ARC

- Un évaluateur DMARC **peut, au titre de sa politique locale**, accepter les résultats d'authentification d'une chaîne ARC validée. Si le message échoue maintenant à DMARC, mais que l'AAR le plus ancien montre un pass SPF ou DKIM aligné au premier saut et que le serveur de réception fait confiance à chaque scelleur de la chaîne, le serveur de réception peut livrer le message malgré `p=reject` ou `p=quarantine`.
- C'est exactement la dérogation `local_policy` ou `mailing_list` que l'on voit dans les [rapports agrégés DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc). La RFC 8617 suggère d'indiquer, dans le commentaire du rapport sur la dérogation à la politique, l'état de validation de la chaîne, les valeurs `d=` et `s=` de chaque sceau, et l'adresse IP d'origine tirée du premier ARC Set.
- La confiance accordée aux scelleurs repose sur la réputation et varie d'un serveur de réception à l'autre. Les grands fournisseurs tiennent des listes de services de transfert et d'opérateurs de listes dont ils honorent les sceaux. Un pass ARC venant d'un scelleur inconnu, ou d'un scelleur à la réputation faible, ne change généralement rien.

## Ce qu'il faut retenir pour la délivrabilité

- **Les expéditeurs** ne peuvent pas déployer ARC pour améliorer leur propre délivrabilité. Ce sont les intermédiaires (services de transfert, listes de diffusion, passerelles de sécurité) qui le mettent en œuvre, et les serveurs de réception qui l'honorent. Ce que les expéditeurs devraient faire, c'est publier des enregistrements SPF, DKIM et DMARC solides, pour que l'AAR du premier saut enregistre un pass aligné.
- **Les opérateurs de services de transfert, de listes de diffusion ou de passerelles de filtrage** devraient sceller avec ARC (et conserver les en-têtes d'origine), pour que l'application de DMARC plus loin sur le trajet ne détruise pas leur trafic.
- Dans le cadre de ses consignes pour les expéditeurs, Gmail exige des en-têtes ARC sur le trafic des services de transfert de gros volumes. Microsoft, Google et d'autres grands fournisseurs scellent et honorent ARC.

## Voir aussi

- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc), la couche de politique qu'ARC aide à préserver d'un saut à l'autre
- [En-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results), le format que reprend l'AAR
- [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim), le mécanisme de signature sur lequel reposent l'AMS et l'AS

# Attaques par rejeu DKIM

> Le problème du rejeu DKIM (draft-ietf-dkim-replay-problem) : comment un message légitimement signé est renvoyé à des millions de destinataires, pourquoi l= et x= ne règlent rien, les mesures de protection actuelles et leurs compromis, et ce que cela implique pour l'infrastructure d'un ESP.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/attaques-par-rejeu-dkim

Si votre domaine signe ses emails avec DKIM, un attaquant qui met la main sur un seul message que vous avez signé peut le renvoyer, sans le modifier, à des millions de nouveaux destinataires, et chaque copie porte toujours votre signature valide. Le rejeu DKIM est une **attaque contre l'infrastructure des expéditeurs**, et non une attaque qui falsifie des messages à l'encontre des destinataires.

[DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim) (RFC 6376) authentifie le contenu d'un message, et non son chemin de transport ni son enveloppe. Le domaine `d=` se retrouve donc à « se porter garant » d'un spam qu'il n'a jamais envoyé à ces destinataires, et c'est sa réputation que l'attaquant dépense.

Le problème est décrit dans **draft-ietf-dkim-replay-problem** (Chuang/Google, Crocker, Robinson/Google, Gondwana/Fastmail). État en 2026-07 : la dernière révision du draft (-00) est datée du 2023-07-28 et a **expiré**. Le groupe de travail DKIM de l'IETF est depuis passé de la description du problème au travail sur une solution, [DKIM2](https://emailmarketing.net/fr/apprendre/authentification/dkim2). Le draft reste la description de référence de l'attaque.

## Mécanique de l'attaque

1. L'attaquant crée ou compromet un compte chez un expéditeur de haute réputation, comme un fournisseur de messagerie gratuit ou **un essai gratuit chez un ESP**, et obtient un message signé par le domaine `d=` visé. Le contenu est la charge utile de l'attaquant (spam ou phishing), ou un message anodin dans lequel la charge utile pourra être insérée plus tard (voir `l=` plus bas).
2. L'attaquant récupère le message entièrement signé. C'est trivial, car l'attaquant en est le destinataire : il se l'envoie à lui-même.
3. L'attaquant réinjecte le message, par sa propre infrastructure, vers une nouvelle liste de destinataires de n'importe quelle taille. L'enveloppe RFC 5321 (`MAIL FROM`, `RCPT TO`) **n'est pas signée**, donc elle peut être librement réécrite. Les en-têtes RFC 5322 et le corps sont intacts, si bien que `bh=` et `b=` sont toujours vérifiés.
4. Les serveurs de réception voient une signature DKIM valide, un `d=` aligné appartenant à un domaine de confiance, et une réussite DMARC. Les systèmes de réputation attribuent le volume de courrier, puis les plaintes et les classements en spam qui suivent, au domaine signataire.

Rien de cela n'enfreint la RFC 6376. La RFC note d'ailleurs que le renvoi d'un message signé ne peut pas être distingué d'un transfert légitime. C'est précisément cette propriété qui permet à DKIM de survivre au transfert là où SPF casse. **La difficulté centrale, selon le draft, est que les serveurs de réception ne peuvent pas distinguer le transfert légitime (transfert d'alias, listes de diffusion, « envoyer à un ami ») d'une attaque par rejeu.** Toute correction simple qui arrête le rejeu arrête aussi le transfert.

## Pourquoi les balises DKIM existantes ne règlent rien

| Balise | Pourquoi elle échoue |
|---|---|
| `l=` (longueur du corps) | Sans intérêt au mieux, nuisible au pire. Elle limite les octets du corps qui sont signés, mais ne lie en rien les destinataires. Pire, `l=` permet à l'attaquant d'**ajouter** un contenu malveillant non signé qui s'affiche après la partie signée, tandis que la signature reste valide (exploité en conditions réelles en 2024). Ne signez jamais avec `l=`. |
| `x=` (expiration) | Elle limite la durée de validité de la signature, mais ne peut pas distinguer un délai de transfert légitime de 2 heures d'une campagne de rejeu de 2 heures. Les campagnes de rejeu envoient leur volume dans les minutes qui suivent l'obtention du message signé, bien à l'intérieur de toute fenêtre `x=` assez longue pour les délais de livraison réels (nouvelles tentatives en file d'attente, liste grise, digests de listes de diffusion). La RFC 6376 elle-même indique que `x=` n'est pas une défense contre le rejeu. |
| `t=` (horodatage) | Purement informatif, avec le même problème de fenêtre que `x=`. |
| Signer `To:` | L'en-tête `To:` est généralement signé, mais le rejeu ne le modifie pas. Le spam est livré aux destinataires du `RCPT TO`, qui n'apparaissent pas dans le `To:` signé. Un écart entre le `To:` signé et le destinataire réel est par ailleurs normal (Cci, alias, transfert, listes de diffusion), donc les serveurs de réception ne peuvent pas faire échouer les messages sur cette base. |

## Mesures de protection actuelles et compromis

DKIM tel qu'il est spécifié n'a pas de correction complète. Les mesures ci-dessous réduisent l'exposition et limitent les dégâts. La correction au niveau du protocole est le chantier [DKIM2](https://emailmarketing.net/fr/apprendre/authentification/dkim2), qui lie les signatures à l'enveloppe SMTP à chaque saut.

### Côté expéditeur et ESP

| Mesure | Mécanisme | Compromis |
|---|---|---|
| **Sursignature** | Lister `To:`, `Subject:`, `From:`, `Reply-To:` et `Cc:` dans `h=` une fois de plus qu'ils n'apparaissent. Un attaquant ne peut alors pas ajouter une autre instance (par exemple, un second Subject que certains clients de messagerie affichent) sans casser la signature. | Peu coûteuse, donc à appliquer systématiquement. Elle ne bloque que les variantes qui ajoutent des en-têtes. Le rejeu pur du message inchangé n'est pas affecté. |
| **Expiration `x=` courte** | Signer avec un `x=` fixé quelques heures après `t=`. Cela réduit la fenêtre de rejeu, et les anciennes copies rejouées échouent. | La livraison légitimement retardée (nouvelles tentatives après un 4xx du serveur de réception, liste grise) échoue aussi à la vérification. De nombreux vérificateurs ignorent complètement `x=`, et les attaquants rejouent vite. |
| **Sélecteurs et domaines `d=` distincts pour chaque flux ou client** | Signer chaque client ou flux de messagerie avec son propre sélecteur ou sous-domaine, pour qu'un incident de rejeu n'endommage que l'identifiant d'un client, et non le domaine partagé de la plateforme. | N'empêche pas le rejeu. Limite les dégâts de réputation, et rend le client abusif identifiable et son sélecteur révocable (publiez un `p=` vide pour désactiver le sélecteur). La gestion des clés ajoute du travail à l'échelle d'un ESP. |
| **Signature par destinataire** | Calculer une signature distincte pour chaque RCPT TO, en liant le destinataire au contenu signé (par exemple, par un en-tête signé propre à chaque destinataire). | L'option la plus forte dans le protocole, mais elle exige une opération de signature et un ensemble distinct de corps et d'en-têtes pour chaque destinataire, ce qui supprime l'efficacité de la livraison à plusieurs destinataires à la fois. Elle casse le transfert légitime vers une autre adresse, et aucune norme ne dit comment les vérificateurs doivent contrôler ce lien. |
| **Contrôle du contenu et des destinataires avant la première signature** | L'attaque exige une charge utile signée, donc les contrôles d'abus sur les comptes d'essai, l'analyse du contenu sortant et la vérification de la réputation des URL au moment de la signature servent tous de protections contre le rejeu DKIM. | Une course sans fin. Les charges utiles d'apparence anodine (l'astuce `l=`, le contenu distant) échappent à l'analyse. |
| **Surveillance des anomalies de volume** | Surveiller les données de [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools) et des feedback loops (FBL) pour repérer des pics de taux de spam et de volume sur un domaine `d=` ou un sélecteur qui ne correspondent pas à vos propres journaux d'envoi. Cet écart est le signe d'un rejeu en cours. | Détecte, mais n'empêche pas. La réponse consiste à révoquer le sélecteur et à escalader auprès des fournisseurs. |

### Côté serveur de réception (ce que discute le draft)

- **Comptage et observation des débits :** la même signature (ou le même `bh=`) vue soudainement sur un ensemble anormalement grand de destinataires sans lien entre eux est l'empreinte d'un rejeu. Cela exige une visibilité à grande échelle, ce qui avantage les grands fournisseurs de messagerie, et une coordination entre systèmes.
- **Écarts entre enveloppe et en-têtes :** le courrier rejoué présente généralement des domaines `MAIL FROM` et `RCPT TO` sans rapport avec le domaine signataire et avec le `To:` signé. Cela peut servir de signal de score, mais pas de règle stricte, car le transfert produit le même schéma.
- Il est conseillé aux serveurs de réception de traiter une signature DKIM valide comme un **identifiant auquel rattacher une réputation**, et non comme une réussite qui garantit la confiance. Le rejeu exploite exactement le raccourci qui consiste à prendre une signature valide pour une preuve de confiance.

## Conséquences pour les ESP

- Les ESP sont une **cible de choix pour obtenir des messages signés**. Un essai gratuit donne aux attaquants un moyen de faire signer des messages par un domaine à la réputation déjà établie. Un seul message signé depuis un compte d'essai peut être rejoué à un volume supérieur à la totalité des envois légitimes quotidiens de l'ESP.
- Les dégâts retombent sur le domaine `d=` qui signe le message. Si tous les clients signent avec le domaine partagé de l'ESP, un seul incident dégrade la livraison de tous les clients. C'est l'argument d'architecture le plus fort en faveur d'un domaine `d=` et de sélecteurs propres à chaque client (voir les [meilleures pratiques M3AAWG pour les domaines d'envoi](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-domaines-d-envoi)).
- Réponse à incident : identifiez le message rejoué (à partir d'échantillons de FBL, ou d'un pic de taux de spam dans Postmaster Tools), révoquez le sélecteur (`p=` vide), suspendez le compte d'origine et passez le flux légitime sur un nouveau sélecteur. Gardez des clés distinctes par flux pour les anciens sélecteurs, afin de pouvoir révoquer avec précision.
- Ne répondez pas à un incident de rejeu en ajoutant `l=` ou en retirant `To:` de `h=`. Les deux aggravent la situation.

## Voir aussi

- [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim), notamment la sursignature et `l=`
- [DKIM2](https://emailmarketing.net/fr/apprendre/authentification/dkim2), la refonte du protocole en cours, dont la liaison à l'enveloppe est la véritable correction
- [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation), pour détecter le pic

# BIMI (Brand Indicators for Message Identification)

> Mettre en place BIMI : prérequis de politique DMARC contraignante, enregistrement DNS BIMI, exigences du logo SVG Tiny PS, certificats VMC/CMC et prise en charge par les fournisseurs de messagerie.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/bimi

Si vous voulez que le logo de votre marque apparaisse à côté de vos messages dans la boîte de réception des destinataires, BIMI est le moyen de le demander. Vous publiez le logo dans le DNS, et les fournisseurs de messagerie participants l'affichent à côté des messages authentifiés. Chaque fournisseur de messagerie décide de lui-même s'il affiche le logo, et comment.

BIMI n'est pas en soi un protocole d'authentification. C'est une **récompense de l'authentification complète** : un domaine n'y a droit qu'une fois sa politique [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) devenue contraignante. C'est pourquoi BIMI est souvent l'argument commercial qui finance un [déploiement de DMARC jusqu'à une politique contraignante](https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc).

## Prérequis : une politique DMARC contraignante

Avant qu'un enregistrement BIMI soit pris en compte, il vous faut :

- SPF, DKIM et DMARC déployés avec un alignement correct sur le domaine d'envoi.
- Une politique DMARC **contraignante sur le domaine organisationnel et ses sous-domaines** :
  - `p=quarantine; sp=quarantine` ou plus strict, ou
  - `p=reject; sp=reject`.
- **Non autorisé** : `p=none`, `sp=none`, ou toute valeur de `pct` inférieure à 100.

Les messages doivent réellement passer DMARC. Le logo ne s'affiche que sur les messages authentifiés, et les fournisseurs subordonnent aussi l'affichage à la réputation du domaine d'envoi.

## L'enregistrement DNS BIMI

Un enregistrement TXT publié avec le sélecteur `default`, sous le libellé `_bimi` :

```
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"
```

| Balise | Signification | Remarques |
|---|---|---|
| `v` | Version | `BIMI1`. Doit figurer en premier |
| `l` | URL HTTPS du fichier de logo SVG Tiny PS | Obligatoire pour que le logo s'affiche |
| `a` | URL HTTPS du document de preuve (un certificat VMC ou CMC, au format PEM) | Facultative selon la spécification, mais obligatoire en pratique chez les fournisseurs qui exigent un certificat (par exemple Gmail) |

Un enregistrement avec `l=` mais sans `a=` est un enregistrement BIMI **auto-déclaré** (*self-asserted*). La prise en charge des enregistrements auto-déclarés varie selon les fournisseurs de messagerie (voir le tableau ci-dessous). Des sélecteurs autres que `default` sont possibles, déclarés par un en-tête `BIMI-Selector` dans le message, pour afficher un logo différent pour chaque flux d'emails.

## Exigences du logo SVG (SVG Tiny PS)

Le logo doit respecter le profil **SVG Portable/Secure (SVG Tiny PS)**, fondé sur SVG Tiny 1.2 du W3C :

| Exigence | Valeur |
|---|---|
| Attribut `version` sur `<svg>` | `1.2` |
| Attribut `baseProfile` sur `<svg>` | `tiny-ps` |
| Élément `<title>` | **Obligatoire**. Il devrait reprendre le nom de l'entreprise |
| Élément `<desc>` | Recommandé (accessibilité) |
| Liens ou références externes | Interdits (hors espaces de noms XML déclarés) |
| Scripts, animations, éléments interactifs | Interdits |
| Attributs `x=` et `y=` sur la racine `<svg>` | Interdits |
| Taille du fichier | ≤ 32 Ko |
| Format | Carré |
| Arrière-plan | Une couleur unie est recommandée, car les arrière-plans transparents s'affichent de façon inégale selon les clients de messagerie |
| Composition | Centrez le logo. Les clients de messagerie le recadrent en cercle ou en carré aux coins arrondis |

Les fichiers SVG exportés par les outils de conception courants ne sont pas conformes tels quels. Adobe Illustrator peut exporter en SVG Tiny 1.2, mais vous devez généralement retoucher le fichier à la main pour définir `baseProfile="tiny-ps"` et supprimer les attributs `x` et `y` superflus. Le BIMI Group publie des fichiers de référence et des outils de conversion.

## Certificats : VMC et CMC

Des **autorités de vérification des marques** (*Mark Verifying Authorities*) délivrent des certificats de marque pour attester le lien entre un logo et un domaine. Deux autorités de certification qualifiées pour BIMI les délivrent : **DigiCert** et **Entrust**. Le certificat intègre le logo SVG, et la balise `a=` de l'enregistrement pointe vers lui sous forme de fichier PEM. Les certificats portent un champ `subject:markType` (OID `1.3.6.1.4.1.53087.1.13`) qui indique la méthode de validation employée.

| | VMC (*Verified Mark Certificate*, certificat de marque vérifiée) | CMC (*Common Mark Certificate*, certificat de marque d'usage) |
|---|---|---|
| Fondement du logo | Une **marque déposée** (les juridictions prises en charge sont listées dans les VMC Guidelines du BIMI Group) ou une marque reconnue par un gouvernement | Une **marque d'usage antérieur** (aucun dépôt nécessaire) ou une **marque déposée modifiée** (une variante d'une marque que vous possédez, par exemple des versions saisonnières) |
| Preuves exigées | L'enregistrement de la marque, et la validation de l'organisation | Le logo affiché publiquement pendant **au moins 12 mois** sur un site web que vous contrôlez, avec des preuves historiques (par exemple archive.org) ainsi que son affichage actuel en ligne |
| Affichage dans Gmail | Logo **et coche bleue de vérification** | Logo seul, sans coche |
| Prérequis communs | Une politique DMARC contraignante (`p=quarantine` ou `p=reject`, pas de `sp=none`, pas de `pct<100`), un logo SVG Tiny PS et un enregistrement BIMI publié | Identiques |

Les certificats sont « fortement recommandés » plutôt qu'obligatoires partout. Gmail exige un VMC ou un CMC et ignore les enregistrements auto-déclarés, tandis que Yahoo, Fastmail et La Poste affichent les logos auto-déclarés.

## Prise en charge par les fournisseurs (liste d'adoption du BIMI Group, mai 2025)

| Statut | Fournisseurs |
|---|---|
| Prend en charge BIMI | Apple, Google (Gmail), Yahoo Inc., Fastmail, Zoho Mail, Comcast, Cloudmark (Proofpoint), La Poste, WEB.DE, GMX, KDDI, NTT docomo, Onet Poczta, Zone, Zoner |
| À l'étude ou prévu | Yahoo Japan, Seznam.cz, mail.com, BT, AT Mail, Nifty, Qualitia |
| Ne prend pas en charge | Microsoft (Outlook.com et Microsoft 365 utilisent à la place leurs propres mécanismes de logo de marque) |

Les critères d'affichage qui vont au-delà des exigences publiées (réputation du domaine, historique d'envoi, volume) varient d'un fournisseur à l'autre, et chaque fournisseur les applique à sa seule appréciation. Un enregistrement et un certificat valides rendent un domaine admissible à l'affichage de son logo, mais ne garantissent pas qu'il sera affiché.

## Liste de contrôle de mise en place

1. Amenez tous les flux d'emails à un SPF et un DKIM alignés, et passez DMARC à une politique contraignante : `p=quarantine` ou `p=reject`, couvrant les sous-domaines et appliquée à tous les messages (voir [Déploiement de DMARC en détail](https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc)).
2. Produisez un logo SVG Tiny PS conforme aux exigences du tableau ci-dessus, et validez-le avec les outils du BIMI Group.
3. Obtenez un VMC (pour un logo déposé) ou un CMC (pour 12 mois d'usage antérieur) auprès de DigiCert ou d'Entrust. C'est obligatoire pour Gmail. Ne vous en passez que si les fournisseurs que vous visez acceptent les enregistrements auto-déclarés.
4. Hébergez le fichier SVG (et le fichier PEM, si vous avez un certificat) à des URL HTTPS stables.
5. Publiez l'enregistrement TXT `default._bimi`.
6. Vérifiez le résultat avec un outil de contrôle des enregistrements BIMI, et en envoyant des messages à des comptes de test chez des fournisseurs qui prennent en charge BIMI. Attendez-vous à ce que les fournisseurs appliquent leurs propres vérifications de réputation avant d'afficher le logo.

## Voir aussi

- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)
- [Déploiement de DMARC en détail](https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc), pour atteindre la politique contraignante qu'exige BIMI

# Déploiement de DMARC en détail

> Déploiement opérationnel de DMARC : référence complète des balises, politique des sous-domaines, échantillonnage pct, rigueur de l'alignement, traitement des rapports, échecs liés au transfert et aux listes de diffusion, et progression none → quarantine → reject.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc

Une fois que vous comprenez ce que fait DMARC, faire passer un domaine à une politique contraignante sans risque demande de régler correctement de nombreux détails : l'ensemble des balises, la politique des sous-domaines, l'échantillonnage par pourcentage, la rigueur de l'alignement, le traitement des rapports, les scénarios d'échec courants et l'ordre du déploiement. Pour les notions, l'alignement et l'enregistrement de base, commencez par [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

Les informations ci-dessous proviennent de dmarc.org, le site de référence de la spécification DMARC.

## État de la spécification

| Document | Rôle | Statut |
|---|---|---|
| RFC 7489 (mars 2015) | Spécification DMARC d'origine (statut informatif) | Obsolète |
| RFC 9989 (mai 2026) | Protocole DMARC de base (« DMARCbis », voie des normes) | En vigueur |
| RFC 9990 (mai 2026) | Rapports agrégés | En vigueur |
| RFC 9991 (mai 2026) | Rapports d'échec | En vigueur |

Les principales évolutions des nouvelles RFC ne cassent pas les enregistrements existants, qui commencent toujours par `v=DMARC1` :

- **Balises supprimées** : `pct`, `rf` et `ri`. `pct` a été supprimée parce que sa définition dans la RFC 7489 était ambiguë dès le départ (« pourcentage des messages du flux de courrier du propriétaire du domaine auxquels la politique DMARC doit être appliquée »).
- **Nouvelles balises** : `np` (politique des sous-domaines inexistants), `psd` (un indicateur pour les domaines de suffixe public) et `t` (un indicateur de test, qui remplace l'usage de type `pct=0` pour « surveiller sans appliquer »).
- **Découverte du domaine organisationnel** : la Public Suffix List est remplacée par un **DNS Tree Walk**. Le serveur de réception interroge `_dmarc.<author-domain>`, puis `_dmarc.<parent>`, et ainsi de suite en remontant l'arborescence, dans la limite de huit requêtes.

La plupart des enregistrements déployés et des serveurs de réception utilisent encore la sémantique de la RFC 7489, et la référence des balises ci-dessous couvre donc les deux.

## Référence complète des balises

Les enregistrements DMARC utilisent la syntaxe extensible balise-valeur empruntée à DKIM. Toutes les balises autres que `v` et `p` sont facultatives.

| Balise | Rôle | Exemple | Remarques |
|---|---|---|---|
| `v` | Version du protocole. Doit être en premier | `v=DMARC1` | Seule valeur valide |
| `p` | Politique du domaine organisationnel | `p=quarantine` | `none`, `quarantine` ou `reject` |
| `sp` | Politique des sous-domaines du domaine organisationnel | `sp=reject` | Prend la valeur de `p` en son absence |
| `pct` | Pourcentage des messages en échec auxquels la politique `p` s'applique | `pct=20` | RFC 7489 uniquement. Supprimée dans la RFC 9989 |
| `rua` | Un ou plusieurs URI pour les rapports agrégés | `rua=mailto:aggrep@example.com` | Séparer plusieurs URI par des virgules |
| `ruf` | Un ou plusieurs URI pour les rapports d'échec (« forensiques ») sur des messages individuels | `ruf=mailto:authfail@example.com` | |
| `adkim` | Mode d'alignement DKIM | `adkim=s` | `r` (souple, par défaut) ou `s` (strict) |
| `aspf` | Mode d'alignement SPF | `aspf=r` | `r` (souple, par défaut) ou `s` (strict) |
| `fo` | Options des rapports d'échec | `fo=1` | `0` les deux échouent (par défaut), `1` l'un ou l'autre échoue, `d` échec DKIM, `s` échec SPF |
| `rf` | Format des rapports d'échec | `rf=afrf` | RFC 7489 uniquement. Supprimée dans la RFC 9989 |
| `ri` | Intervalle demandé entre les rapports agrégés (en secondes) | `ri=86400` | RFC 7489 uniquement. Supprimée dans la RFC 9989 |
| `np` | Politique des sous-domaines **inexistants** | `np=reject` | Nouveauté de la RFC 9989 |
| `psd` | Signale un enregistrement publié sur un domaine de suffixe public | `psd=y` | Nouveauté de la RFC 9989 |
| `t` | Indicateur de test : évaluer sans appliquer | `t=y` | Nouveauté de la RFC 9989. Remplace le rôle d'échantillonnage de `pct` |

Exemple d'enregistrement :

```
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:postmaster@example.com"
```

## Politique des sous-domaines (`sp=`)

Sans `sp=`, les sous-domaines héritent de la politique `p=` du domaine organisationnel. Publier `sp=` vous permet d'appliquer des règles différentes selon les parties de l'organisation, par exemple :

- `p=none; sp=reject` : le domaine apex est encore en surveillance, tandis que les messages qui usurpent des sous-domaines n'envoyant pas d'emails sont rejetés.
- `p=reject; sp=none` : l'apex est verrouillé pendant que les flux d'emails d'un sous-domaine sont encore en cours d'alignement. Les attaquants peuvent exploiter ce point faible, alors comblez-le dès que possible.

Pour être éligible à BIMI, **les deux** doivent être en politique contraignante : `p=quarantine|reject`, sans `sp=none` (voir [BIMI](https://emailmarketing.net/fr/apprendre/authentification/bimi)). La RFC 9989 ajoute aussi `np=`, pour que les sous-domaines inexistants puissent être rejetés même lorsque les sous-domaines réels ont une politique plus souple.

## Échantillonnage par pourcentage (`pct=`, RFC 7489)

`pct` définit le pourcentage des messages en échec auxquels la politique `p=` s'applique. Les **messages restants reçoivent la politique immédiatement inférieure** :

- `p=reject; pct=60` signifie que 60 % du trafic en échec est rejeté et que 40 % est mis en quarantaine.
- `p=quarantine; pct=25` signifie que 25 % est mis en quarantaine et que 75 % est traité comme `none`.

Ce réglage intégré permet une application progressive : augmentez `pct` par paliers à chaque niveau de politique, et surveillez les rapports avant d'atteindre 100. Avec la RFC 9989, `pct` n'existe plus. L'indicateur de test `t=y` couvre le cas où l'on publie l'intention d'appliquer une politique sans effet, et un déploiement progressif passe d'un niveau de politique au suivant.

## Rigueur de l'alignement (`adkim=` / `aspf=`)

Les deux balises d'alignement acceptent :

- **`r` (souple, par défaut)** : le domaine authentifié (le `d=` de DKIM ou le RFC5321.MailFrom de SPF) doit seulement avoir le même domaine organisationnel que le domaine RFC5322.From. `news.example.com` est aligné avec `example.com`.
- **`s` (strict)** : les domaines doivent correspondre **exactement**.

Le mode souple est le bon choix par défaut pour presque tous les expéditeurs. Le mode strict s'adresse aux propriétaires de domaines qui veulent empêcher même des sous-domaines frères d'authentifier des messages les uns pour les autres, par exemple pour isoler des unités commerciales, ou pour se protéger d'un tiers compromis qui signe au nom d'un sous-domaine délégué. N'utilisez pas `s` avant que les rapports agrégés confirment que chaque flux légitime s'authentifie avec le domaine From exact.

## Traitement des rapports

### Rapports agrégés (`rua=`)

- Des documents XML, généralement produits **chaque jour** par chaque serveur de réception qui envoie des rapports. Attendez-vous aux premiers rapports 24 heures ou plus après la publication de l'enregistrement.
- Ils contiennent des décomptes pour chaque adresse IP source, avec les résultats bruts SPF et DKIM, l'évaluation de l'alignement et le traitement appliqué.
- Ils sont livrés compressés en gzip à des URI `mailto:`. Utilisez une boîte aux lettres dédiée et une analyse automatisée, jamais la boîte de réception d'une personne.
- C'est le jeu de données principal pour les décisions de déploiement. Il révèle toutes les sources qui utilisent votre domaine dans le RFC5322.From, y compris des tiers oubliés.

### Rapports d'échec (`ruf=`)

- Envoyés **immédiatement, pour chaque message en échec**. Si le domaine est usurpé à grande échelle, leur volume « pourrait représenter plusieurs fois le volume de vos emails légitimes ».
- Ils permettent une analyse forensique de messages individuels, mais de nombreux serveurs de réception ne les envoient pas (pour des raisons de confidentialité), et ils exigent de prévoir la capacité nécessaire. Ne déployez `ruf=` qu'après avoir compris votre trafic grâce aux rapports agrégés, voire pas du tout.

### Destinations de rapports externes

Si `rua=` ou `ruf=` pointe vers un autre domaine que celui qui publie l'enregistrement DMARC, les serveurs de réception vérifient que la destination est autorisée. Le **domaine qui reçoit les rapports** doit publier :

```
example.com._report._dmarc.thirdparty.com. IN TXT "v=DMARC1"
```

Cela signifie que `thirdparty.com` accepte de recevoir des rapports concernant `example.com`. Une forme générique (wildcard) accepte les rapports pour n'importe quel domaine, mais ouvre la porte aux abus :

```
*._report._dmarc.thirdparty.com. IN TXT "v=DMARC1"
```

Les services de traitement des rapports DMARC s'appuient sur ce mécanisme. C'est pourquoi faire pointer `rua=` vers l'adresse d'un prestataire fonctionne sans que ce prestataire contrôle votre DNS.

### Outils

dmarc.org tient à jour des répertoires d'[outils de déploiement](https://dmarc.org/resources/deployment-tools/) et de [code et bibliothèques](https://dmarc.org/resources/code-and-libraries/). Les solutions commerciales de traitement des rapports sont recensées dans la rubrique [produits et services](https://dmarc.org/resources/products-and-services/).

- Générateurs et assistants d'enregistrement : dmarcian, EasyDMARC, DMARCLY, Fortra (Agari), Kitterman, Proofpoint, Global Cyber Alliance.
- Vérificateurs d'enregistrement : les mêmes éditeurs, plus Sendmarc, Valimail et Mimecast.
- Réflecteurs et validateurs de messages : `autoreply@dmarctest.org`, aboutmy.email, Red Sift Investigate.
- Code et bibliothèques : le milter OpenDMARC, Mail::DMARC en Perl, mail-auth en Rust, les scripts rddmarc pour l'analyse des rapports, dmarc-report-processor pour la conversion en CSV, et Lafayette pour le stockage des rapports, entre autres.

## Scénarios d'échec courants

### Transfert

Le transfert simple réécrit le RFC5321.MailFrom (ou conserve celui d'origine mais envoie depuis une nouvelle adresse IP), si bien que **l'alignement SPF est perdu**. DKIM ne résiste au transfert **que si le service de transfert ne modifie pas le contenu signé**. Ajouter de nouveaux en-têtes ne pose généralement pas de problème, mais modifier l'objet ou le corps casse la signature.

C'est l'une des principales raisons de s'authentifier avec **les deux** protocoles, et de s'appuyer avant tout sur un DKIM aligné. Un message dont la signature DKIM reste intacte passe DMARC après le transfert, même si SPF échoue.

### Listes de diffusion

Les listes traditionnelles modifient les messages (étiquettes dans l'objet, pieds de page), ce qui casse DKIM, et les envoient depuis leur propre infrastructure, ce qui casse l'alignement SPF. Les messages postés depuis un domaine en `p=reject` rebondissent alors chez tous les abonnés. Les parades connues sont les suivantes :

| Parade | Mécanisme | Contrepartie |
|---|---|---|
| Transfert strict | La liste transmet le message intact, si bien que la signature DKIM d'origine reste valide | Perte des étiquettes d'objet et des pieds de page auxquels les membres de la liste s'attendent |
| Original Authentication Results (OAR) ou ARC | La liste consigne l'état d'authentification qu'elle a constaté à l'arrivée du message, afin que les serveurs de réception puissent s'y fier | Nécessite l'adoption par les serveurs de réception, qui est limitée mais en progression (ARC est le successeur moderne) |
| Réécriture du From (transfert de responsabilité) | La liste réécrit le RFC5322.From avec son propre domaine et signe elle-même avec DKIM | Le message vient désormais « de » la liste, ce qui affecte les réponses et les carnets d'adresses |

La réécriture du From est ce que font aujourd'hui la plupart des grands logiciels de listes lorsque le domaine de l'auteur est en politique contraignante. Si vos utilisateurs publient sur des listes de diffusion, attendez-vous à ce comportement dès que vous dépasserez `p=none`.

## Le chemin de déploiement : none, quarantine, reject

dmarc.org décrit pour les expéditeurs un processus de déploiement en cinq étapes :

1. **Déployer DKIM et SPF** sur chaque flux d'emails légitime : messagerie d'entreprise, plateforme marketing, CRM, système de facturation, service client, tous sans exception.
2. **Garantir l'alignement** : vérifier que les identifiants de chaque flux sont alignés avec le domaine RFC5322.From (le `d=` de DKIM et/ou le RFC5321.MailFrom).
3. **Publier `p=none`**, avec `rua=` pointant vers une boîte aux lettres ou un service de traitement de rapports dédié. Cela n'a aucun effet sur la livraison : vous ne faites que collecter des données.
4. **Analyser les rapports et corriger les flux.** Chaque source en échec est soit (a) un expéditeur légitime à aligner, soit (b) un abus que la politique contraignante arrêtera. Répétez jusqu'à ce que les rapports agrégés montrent que tout le courrier légitime passe.
5. **Durcir** : passer à `p=quarantine`, d'abord avec un échantillonnage `pct` faible (pour les serveurs de réception RFC 7489), et monter progressivement vers `pct=100`. Surveillez dans les rapports le courrier légitime mis en quarantaine. Quand il n'y en a plus, passez à `p=reject`, là encore en augmentant éventuellement `pct` par paliers.

Recommandations opérationnelles pour chaque phase :

- **La phase `p=none`** : prévoyez des semaines, pas des jours. Les expéditeurs tiers (facturation, RH, plateformes événementielles) apparaissent lentement dans les rapports, car certains envoient rarement.
- **La phase `p=quarantine`** : le courrier légitime en échec va dans le dossier spam au lieu de disparaître, si bien que les destinataires peuvent encore le récupérer. C'est ce filet de sécurité qui fait de la quarantaine l'étape intermédiaire obligatoire. Surveillez le trafic transféré et celui des listes de diffusion (voir plus haut), qui échouera par construction.
- **La phase `p=reject`** : n'y passez qu'une fois que les rapports agrégés ne montrent plus aucun message légitime mis en quarantaine. L'expéditeur voit un rejet (sous forme de rebond), ce qui aide à détecter les flux défaillants, mais tout ce qui vous a échappé est perdu.
- Pensez à `sp=` à chaque étape. Changer la politique de l'apex ne protège pas, et ne casse pas, les sous-domaines que vous avez exclus.

Une politique contraignante (`quarantine` ou `reject` à 100 %) est aussi la condition d'accès à [BIMI](https://emailmarketing.net/fr/apprendre/authentification/bimi).

## Voir aussi

- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc), sur les notions, les bases de SPF et DKIM, l'alignement et l'enregistrement de base
- [BIMI](https://emailmarketing.net/fr/apprendre/authentification/bimi), l'affichage du logo, qui exige une politique DMARC contraignante
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)

# DKIM (DomainKeys Identified Mail)

> Référence RFC 6376, complétée par la RFC 8301 (rsa-sha256 obligatoire, clés de 1 024 à 4 096 bits) et la RFC 8463 (ed25519-sha256) : syntaxe de la signature et de l'enregistrement de clé, signification des balises, canonicalisation, périmètre de signature et risques.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/dkim

DKIM permet à votre domaine de prendre la responsabilité d'un message en le signant. Les serveurs de réception vérifient la signature avec une clé publique que vous publiez dans le DNS. Une signature valide prouve que le contenu signé n'a pas été modifié après la signature, et elle rattache le message au domaine **d=**, l'identifiant dont DMARC vérifie l'alignement (voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)). Contrairement à [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf), DKIM résiste au transfert, tant que le contenu signé n'est pas modifié.

DKIM est défini dans la RFC 6376. Il authentifie le contenu du message : le signataire ajoute un en-tête `DKIM-Signature` qui contient des empreintes cryptographiques d'une sélection d'en-têtes et du corps.

## L'en-tête DKIM-Signature : référence des balises

| Balise | Obligatoire ? | Signification |
|---|---|---|
| `v=` | Obligatoire | Version ; doit valoir `1`. |
| `a=` | Obligatoire | Algorithme de signature : `rsa-sha256` ou `ed25519-sha256` (RFC 8463). `rsa-sha1` **NE DOIT PAS** être utilisé (RFC 8301). |
| `b=` | Obligatoire | La signature elle-même, en base64. Les espaces sont ignorées. |
| `bh=` | Obligatoire | L'empreinte du corps canonicalisé (limité par `l=` s'il est présent), en base64. |
| `c=` | Facultatif | Canonicalisation, écrite `header/body`, où chaque partie vaut `simple` ou `relaxed`. La valeur par défaut est `simple/simple`, et `c=relaxed` seul signifie `relaxed/simple`. |
| `d=` | Obligatoire | **SDID**, le domaine signataire qui revendique la responsabilité. Il doit avoir un enregistrement de clé dans le DNS. C'est l'identifiant utilisé pour l'alignement DMARC. |
| `h=` | Obligatoire | Une liste ordonnée des champs d'en-tête signés, séparés par des deux-points. Elle ne doit pas être vide et **ne doit pas** inclure la DKIM-Signature en cours de création. Elle peut citer plusieurs fois le même nom, et citer des champs qui n'existent pas (voir la sursignature ci-dessous). |
| `i=` | Facultatif | **AUID**, l'identité de l'agent ou de l'utilisateur : une adresse dont le domaine doit être identique à `d=` ou en être un sous-domaine (strictement identique si l'enregistrement de clé porte l'indicateur `t=s`). La valeur par défaut est `@` suivi de la valeur de d=. |
| `l=` | Facultatif | Longueur du corps : le nombre d'octets du corps canonicalisé couverts par `bh=`. La valeur par défaut est le corps entier. **C'est un risque de sécurité ; voir ci-dessous.** |
| `q=` | Facultatif | La méthode de récupération de la clé. Seule `dns/txt` est définie (la valeur par défaut). |
| `s=` | Obligatoire | Le sélecteur, qui désigne la clé au sein du domaine (voir l'enregistrement de clé ci-dessous). |
| `t=` | Recommandé | L'horodatage de la signature, en secondes Unix. Les vérificateurs peuvent ignorer les signatures dont l'horodatage est dans le futur. |
| `x=` | Recommandé | Un horodatage d'expiration absolu, qui doit être > `t=`. Ce n'est pas une protection contre le rejeu. |
| `z=` | Facultatif | Une copie de champs d'en-tête sélectionnés au moment de la signature, séparés par `|`, pour le diagnostic. |

### Périmètre de signature : quels en-têtes signer

- Le champ **From:** **DOIT** être signé. C'est l'identité que DKIM a pour raison d'être de protéger, et le champ qu'évalue DMARC. En pratique, signez aussi Subject, Date, To, Reply-To, Message-ID, les en-têtes MIME et les champs List-*.
- **Sursignature :** citer un nom d'en-tête dans `h=` une fois de plus que l'en-tête n'apparaît signe une instance « nulle » de cet en-tête. Tout en-tête de ce nom ajouté plus tard (par exemple un second From: ou Subject: inséré en cours de route) casse alors la signature. C'est recommandé pour From, Subject, To et Reply-To.
- Lorsqu'un en-tête apparaît plusieurs fois, ses instances sont signées **de bas en haut**. Vous ne pouvez pas choisir de n'en signer qu'une seule.

### Le risque de la balise de longueur de corps `l=`

`l=` permet à une signature de ne couvrir que les N premiers octets du corps, afin que des intermédiaires puissent ajouter du contenu (par exemple les pieds de page des listes de diffusion) sans casser la signature. Par conséquent, **tout ce qui est ajouté au-delà des N octets n'est pas vérifié**. Un attaquant peut rejouer un message signé en y ajoutant du contenu malveillant à la fin, et la signature reste valide. Cette faille a été exploitée en pratique (« DKIM l= vulnerability », 2024). **Ne signez pas avec `l=`. Les vérificateurs devraient traiter les signatures avec `l=` avec méfiance, ou ignorer l'exemption qu'accorde cette balise.**

## L'enregistrement de clé DNS

La clé est publiée sous forme d'enregistrement TXT à l'adresse :

```
<selector>._domainkey.<domain>
```

| Balise | Par défaut | Signification |
|---|---|---|
| `v=` | `DKIM1` | Version. Si elle est présente, ce doit être la première balise. |
| `p=` | — (obligatoire) | La clé publique, en base64. **Un `p=` vide signifie que la clé est révoquée.** |
| `k=` | `rsa` | Type de clé : `rsa` ou `ed25519` (RFC 8463). |
| `h=` | toutes autorisées | Les algorithmes d'empreinte acceptés, séparés par des deux-points (`sha256` ; `sha1` est obsolète). |
| `s=` | `*` | Type de service : `*` ou `email`. |
| `t=` | aucun | Indicateurs : `y` signifie le mode test ; `s` signifie que le domaine de `i=` doit être strictement identique à `d=` (pas d'AUID sur des sous-domaines). |
| `n=` | vide | Des notes destinées aux administrateurs. |

Exemple (Ed25519, tiré de la RFC 8463) :

```
brisbane._domainkey.football.example.com. IN TXT
  "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="
```

**Hygiène des sélecteurs :** les sélecteurs vous permettent d'avoir plusieurs clés en même temps (par système, par ESP ou par date). Pour changer de clé, publiez un nouveau sélecteur, faites passer la signature sur ce sélecteur, puis révoquez l'ancienne clé. Ne réutilisez jamais un sélecteur avec une nouvelle clé, car vous perdriez la possibilité de distinguer les anciens messages légitimement signés des falsifications.

## Algorithmes et tailles de clé (RFC 8301, RFC 8463)

| Règle | Exigence |
|---|---|
| Algorithme de signature | Les signataires **DOIVENT** signer avec `rsa-sha256`. `rsa-sha1` **NE DOIT PAS** être utilisé pour signer ni pour vérifier (SHA-1 est historique). |
| Taille de clé RSA pour les signataires | **DOIVENT** utiliser des clés de ≥ 1 024 bits. **2 048 bits sont recommandés** (la référence opérationnelle actuelle). |
| Taille de clé RSA pour les vérificateurs | **DOIVENT** valider les clés **de 1 024 à 4 096 bits**, et PEUVENT prendre en charge des clés plus grandes. **NE DOIVENT PAS** considérer comme valides les signatures faites avec des clés de < 1 024 bits. |
| Ed25519 (RFC 8463) | `a=ed25519-sha256`, enregistrement de clé `k=ed25519`, et `p=` est la clé publique Ed25519 en base64. Les clés font 256 bits, donc la clé encodée ne fait que 44 octets et tient dans une seule chaîne TXT de 255 octets (les grandes clés RSA doivent souvent être réparties sur plusieurs chaînes). |
| Double signature | Pour la compatibilité, signez **à la fois** avec `rsa-sha256` et `ed25519-sha256`, en utilisant **des sélecteurs différents** (un enregistrement de clé par sélecteur). La prise en charge d'Ed25519 par les vérificateurs n'est toujours pas universelle. |

## Canonicalisation

La canonicalisation normalise le contenu avant le calcul de l'empreinte, afin que la signature tolère les réécritures en transit. Elle ne modifie pas le message envoyé.

| Algorithme | Règles |
|---|---|
| `simple` (en-tête) | Les en-têtes sont pris exactement tels qu'ils apparaissent, donc toute modification casse la signature. |
| `relaxed` (en-tête) | Les noms d'en-tête sont mis en minuscules, les lignes de continuation sont dépliées, les suites d'espaces sont réduites à une seule espace, les espaces de fin sont supprimées, et les espaces autour des deux-points sont supprimées. |
| `simple` (corps) | Les lignes vides de fin sont supprimées, et le corps se termine par un seul CRLF. |
| `relaxed` (corps) | Les espaces en fin de ligne sont supprimées, les suites d'espaces à l'intérieur des lignes sont réduites à une seule espace, les lignes vides de fin sont supprimées, et le corps se termine par un CRLF. |

**`relaxed/relaxed` est la valeur par défaut en pratique.** La canonicalisation d'en-tête `simple` casse dès qu'un MTA replie ou remet en forme les en-têtes.

## Comportement de la vérification

- Chaque signature a l'une de ces trois issues : **SUCCESS**, **PERMFAIL** (un échec irrécupérable : signature incorrecte, clé révoquée ou trop courte, erreur de syntaxe) ou **TEMPFAIL** (un échec passager, par exemple un délai d'attente DNS dépassé).
- Une signature en échec est traitée **comme si le message n'était pas signé**. Un échec DKIM ne justifie pas en soi le rejet du message. Il ne fournit simplement aucun identifiant positif. C'est DMARC qui transforme l'absence de pass aligné en décision de politique.
- **Les signatures multiples** sont évaluées chacune séparément. Les vérificateurs continuent jusqu'à ce que l'une d'elles soit vérifiée. Un message peut légitimement porter une signature du domaine de l'auteur et des signatures d'un ou de plusieurs intermédiaires.
- Le résultat du vérificateur doit inclure le domaine `d=` et le résultat. Il apparaît plus loin dans l'[en-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results).

## Remarques sur la délivrabilité

- Les fournisseurs de messagerie rattachent de plus en plus la réputation au **domaine d= de DKIM**, et préfèrent DKIM à SPF pour l'alignement DMARC, l'inscription aux feedback loops et les outils destinés aux expéditeurs.
- Les exigences de Gmail et de Yahoo envers les expéditeurs de gros volumes rendent de fait obligatoire, à grande échelle, une signature DKIM alignée avec une clé de ≥1 024 bits (2 048 recommandés).
- DKIM n'empêche pas le **rejeu**. Un spammeur peut renvoyer tel quel un message légitimement signé à de nouveaux destinataires, et la signature reste valide, ce qui consomme la réputation du domaine d=. Les parades sont des expirations `x=` courtes, des sélecteurs par destinataire ou par flux, et la surveillance.

## Voir aussi

- [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf), qui authentifie plutôt le chemin d'envoi
- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc), sur l'alignement et la politique construits sur DKIM et SPF
- [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc), sur la chaîne de traçabilité lorsque des intermédiaires cassent les signatures

# DKIM2 (travaux de l'IETF en cours)

> La refonte de DKIM par le groupe de travail DKIM de l'IETF : signatures chaînées à chaque saut et liées à l'enveloppe SMTP, modifications documentées (« recipes »), rebonds authentifiés, résistance au rejeu, avec l'état du groupe de travail en juillet 2026. Ce n'est PAS une norme publiée.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/dkim2

Si vous signez vos messages avec DKIM, une refonte appelée DKIM2 est en préparation. Elle doit corriger le rejeu et les dégâts que les services de transfert et les listes de diffusion causent aux signatures. Elle n'est pas prête à être déployée, mais elle mérite d'être suivie, afin que vos systèmes de signature puissent s'adapter le moment venu.

> **Avertissement sur le statut : il s'agit de travaux de normalisation en cours, et non d'une norme que vous pouvez déployer.** Tout ce qui suit est tiré d'Internet-Drafts actifs du groupe de travail **dkim** de l'IETF, qui a reçu une nouvelle charte, tels que récupérés le 2026-07-20. Les Internet-Drafts sont des documents de travail. Les noms de balises, les noms d'en-têtes et leur signification **vont changer** d'une révision à l'autre, et le chantier peut aussi s'arrêter complètement. Ne construisez pas de systèmes de production qui dépendent de ces détails ; servez-vous-en pour suivre la direction des travaux. [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim) (RFC 6376, STD 76) reste la norme en vigueur.

## Pourquoi DKIM2 existe

DKIM v1 présente deux faiblesses de conception que l'écosystème de l'email contourne depuis 15 ans :

1. **Le rejeu.** Une signature est valide pour n'importe quel destinataire, indéfiniment (dans la limite de `x=`). Voir [Attaques par rejeu DKIM](https://emailmarketing.net/fr/apprendre/authentification/attaques-par-rejeu-dkim).
2. **La casse par les intermédiaires.** Les services de transfert et les listes de diffusion qui modifient les messages détruisent les signatures, et DMARC sanctionne ensuite ces messages. [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc) consigne ce qu'un intermédiaire a vu, mais pas ce qu'il a modifié, et vous oblige à faire confiance à l'intermédiaire.

La réponse de DKIM2 est que chaque saut qui traite le message le signe, que chaque signature est **liée à l'enveloppe SMTP de ce saut**, et que les modifications sont **enregistrées de façon réversible**, afin que le serveur de réception final puisse reconstituer et vérifier le message tel qu'il a été signé à l'origine. Par effet secondaire, les rebonds deviennent entièrement **authentifiés**, ce qui élimine le [backscatter](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/backscatter-et-batv).

## État du groupe de travail (au 2026-07-20)

| Document | Version et date | État |
|---|---|---|
| draft-ietf-dkim-dkim2-spec | -04, 2026-07-05, 43 p. | Document du groupe de travail, destiné à la voie normative (Standards Track). Auteurs : R. Clayton (Yahoo), W. Chuang (Google), B. Gondwana (Fastmail). Expire le 2027-01-06. |
| draft-ietf-dkim-dkim2-bcp | -00, 2026-06-18, 16 p. | Document du groupe de travail. Auteur : T. Herr (GreenArrow). Remplace le draft individuel draft-herr-dkim2-bcp (-01, expiré). Expire le 2026-12-20. |
| draft-ietf-dkim-dkim2-dns | -00, 2026-07-20, 13 p. | Document du groupe de travail (la spécification DNS de DKIM2). Adopté à partir du draft individuel draft-chuang-dkim2-dns. |
| draft-moccia-dkim2-deployment-profile | -06, 2026-07-19 | **Contribution individuelle, non adoptée par le groupe de travail.** Un profil conçu pour être déployable sous forme de milter (voir plus bas). |
| draft-ietf-dkim-replay-problem | -00, 2023-07-28 | Énoncé du problème, expiré, qui a mené à la nouvelle charte. |

Les auteurs travaillent chez Yahoo, Google et Fastmail, ce qui montre l'adhésion des serveurs de réception, et c'est cette adhésion qui a fait aboutir ou échouer les normes de messagerie par le passé. Les archives de la liste de diffusion se trouvent sur mailarchive.ietf.org/arch/browse/ietf-dkim/.

## Le mécanisme (selon draft-ietf-dkim-dkim2-spec-04)

### Deux nouveaux en-têtes

**`Message-Instance`** : un par révision du message, avec ces balises :
- `m=` le numéro de révision (la version de l'émetteur d'origine est 1, et tout saut qui modifie le message l'incrémente)
- `h=` les empreintes de cette instance, au format `sha256:<header-hash>:<body-hash>`
- `r=` des « recipes » JSON encodées en base64 pour reconstituer l'instance précédente (voir plus bas)

**`DKIM2-Signature`** : une par saut qui traite le message, avec ces balises :
- `i=` le numéro de séquence du saut (celui de l'émetteur d'origine est 1, et chaque signataire l'incrémente ; **un trou dans `i=` ou `m=` invalide la chaîne**)
- `m=` l'instance Message-Instance que ce saut a signée
- `t=` un horodatage Unix (rejeter les horodatages dans le futur ; PEUT ignorer les signatures datant de >14 jours)
- `mf=` le base64 du reverse-path `MAIL FROM` de la RFC 5321 utilisé à ce saut (`<>` pour les DSN)
- `rt=` le base64 des forward-paths `RCPT TO` de la RFC 5321 utilisés à ce saut
- `nd=` « next domain » (domaine suivant), qui relie des transmissions internes sans véritable transaction SMTP
- `n=` un nonce facultatif (≤64 caractères), et `f=` des indicateurs
- `d=` et `s=`, le domaine et le sélecteur comme dans DKIM1, avec la valeur de la signature écrite `<selector>:<alg>:<sig>`

### Chaîne de responsabilité et résistance au rejeu

- Chaque saut enregistre l'enveloppe qu'il a utilisée. Les vérificateurs contrôlent que le domaine `mf=` du saut i est aligné avec son `d=` (correspondance souple), et que le `rt=` du saut précédent (i−1) correspond au `mf=` du saut i.
- Le serveur du destinataire contrôle que le `RCPT TO` réel de la transaction qui livre le message correspond au dernier `rt=`. **Un message rejoué porte le destinataire d'origine dans le `rt=` signé, donc l'envoyer à de nouveaux RCPT TO casse la chaîne.** C'est la correction du rejeu que DKIM1 n'a aucun moyen d'exprimer.
- La diffusion légitime d'un expéditeur vers de nombreux destinataires doit être déclarée ouvertement. `f=exploded` signale une distribution délibérée à de nombreux destinataires (listes de diffusion), `f=donotexplode` demande une livraison à un seul destinataire, et `f=donotmodify` interdit toute modification du contenu (une violation entraîne un FAIL et bloque tout transfert ultérieur).

### Recipes : des enregistrements de modification réversibles

Un intermédiaire qui modifie un message (en ajoutant un pied de page de liste ou une balise dans l'objet) incrémente `m=` et publie dans `r=` une description JSON de la différence, afin que l'instance précédente puisse être reconstituée :

- `"h"` associe des noms d'en-têtes à des étapes, et `"b"` contient les étapes du corps.
- Les étapes sont soit `{"c":[start,end]}`, qui copie des plages (les en-têtes sont numérotés de bas en haut, et les lignes du corps de haut en bas à partir de 1), soit `{"d":[...]}`, qui insère des valeurs littérales.
- `"b": null` déclare une modification du corps qui ne peut pas être inversée.

Le vérificateur final remonte les recipes jusqu'à l'instance 1 et contrôle la signature de l'émetteur d'origine. Cela résout le problème des listes de diffusion face à DMARC sans la confiance aveugle qu'exige ARC.

Le BCP soulève une préoccupation de vie privée : les recipes peuvent réintégrer un contenu qu'un intermédiaire a délibérément retiré, comme des caviardages de prévention des pertes de données (DLP) ou des pièces jointes malveillantes supprimées. Les recipes nulles sont la porte de sortie, et les recommandations pour les juridictions soumises au RGPD restent une question ouverte.

### Cryptographie et canonicalisation simplifiées

- Empreinte : SHA-256 est obligatoire. Signature : `rsa-sha256` (PKCS#1 v1.5, e=65537, clés de ≥1024 bits ; les vérificateurs prennent en charge 1024–2048) et `ed25519-sha256` (PureEdDSA de la RFC 8032). Le BCP recommande de signer avec **les deux** algorithmes.
- Une canonicalisation unique remplace le choix de DKIM1 entre simple et relaxed. Pour l'entrée de la signature, les noms d'en-têtes sont mis en minuscules, les en-têtes sont dépliés, et **toutes les espaces sont supprimées**. L'empreinte des en-têtes trie les en-têtes par ordre alphabétique (les en-têtes de même nom gardent leur ordre de bas en haut). L'empreinte du corps fonctionne comme la canonicalisation simple (les lignes vides de fin sont réduites à un seul CRLF). Le calcul se fait sur la forme transmise sur le fil (après l'encodage de transfert du contenu, avant le dot-stuffing).
- Ces en-têtes sont exclus de l'empreinte des en-têtes : `Received`, `Return-Path`, `Delivered-To`, `DKIM-Signature`, `ARC-*`, `Authentication-Results`, `X-*`, `Message-Instance`, `DKIM2-Signature`.
- Il n'y a pas de balise `v=`, car le nouveau nom d'en-tête identifie la version. Les enregistrements de clé se trouvent **au même emplacement**, `<selector>._domainkey.<domain>`, avec un `k=` qui correspond à l'algorithme. DKIM1 et DKIM2 peuvent donc partager l'infrastructure de clés et coexister sur un même message, dans n'importe quel ordre.

### Résultats de vérification et DSN authentifiées

- Les résultats (compatibles avec la RFC 8601) sont PASS, FAIL, PERMERROR et TEMPERROR, avec des messages d'erreur normalisés que les personnes peuvent lire (par exemple `FAIL: Message Instance m=<x> body hash <value> mismatch`).
- **Les notifications d'état de livraison (DSN) sont envoyées au `mf=` de la DKIM2-Signature qui porte le numéro le plus élevé**, c'est-à-dire au saut qui vous a réellement remis le message, jamais à un inconnu usurpé. Aucune DSN n'est envoyée quand `mf=<>`. Chaque service de transfert renvoie la DSN d'un saut en arrière, après avoir vérifié que le message intégré correspond à ce qu'il avait signé et avoir retiré ses propres en-têtes DKIM2.
- Par conséquent, les rebonds sont authentifiés de bout en bout, et le [backscatter](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/backscatter-et-batv) ne peut pas se produire pour les messages qui restent dans l'écosystème DKIM2. Les indicateurs `feedback` et `feedhere` esquissent un canal de retour sur la livraison (détails pas encore définis).

## Recommandations du BCP (draft-ietf-dkim-dkim2-bcp-00)

- **Expéditeurs :** signez à la fois avec DKIM1 et DKIM2 « jusqu'à ce que le déploiement soit effectivement généralisé » (« until deployment is effectively ubiquitous »), avec RSA et Ed25519. Ne signez qu'au point où les messages quittent vos systèmes, et faites tourner les clés selon les pratiques du M3AAWG.
- **Services de transfert :** vérifiez les messages à leur arrivée, et signez chaque message à sa sortie (modifié ou non) pour garder la chaîne intacte. N'ajoutez votre signature qu'aux messages arrivés avec une chaîne DKIM2 valide. Les messages arrivés avec DKIM1 seulement doivent être examinés selon la politique locale avant que vous les ajoutiez à votre chaîne.
- **Serveurs de réception :** pour les messages entièrement à l'intérieur de l'écosystème DKIM2, une chaîne rompue **peut être rejetée sans risque**, car il est prouvé que la DSN atteint une partie responsable. Pour les chaînes partielles ou absentes, revenez à DKIM1 et à la politique locale pendant la transition.
- Le draft liste lui-même des questions ouvertes : des limites au nombre d'en-têtes Message-Instance et de signatures, le rôle futur de DMARC et de SPF, et la signification du feedback. Plusieurs sections contiennent littéralement « Need some text » (texte à rédiger).

## Le débat sur le profil de déploiement (draft-moccia-dkim2-deployment-profile-06)

Ce draft individuel, non adopté par le groupe de travail, soutient que la spécification complète est trop lourde pour les petits opérateurs et propose un profil à deux niveaux. Il se distingue parce qu'il utilise **d'autres dispositions d'en-têtes** (`DKIM2-Sig-mf`, `DKIM2-Sig-rt` et `DKIM2-Mod`) que la spécification du groupe de travail, ce qui montre à quel point le format sur le fil reste instable :

- **DKIM2-core** (le niveau obligatoire) : la liaison à l'enveloppe, la chaîne de responsabilité, les déclarations de modification des en-têtes et l'authentification des DSN. Le tout est sans état et peut être implémenté sous forme de **milter, sans modification du cœur de l'agent de transfert de courrier (MTA)**. Le coprésident du groupe de travail M. Kucherawy l'a confirmé, et un prototype fonctionnel a été publié. Limites : au plus `i≤20` sauts (~15–16 dans le pire cas réaliste), ≤500 destinataires par saut, et une correspondance souple de domaine limitée au retrait de 2 libellés.
- **DKIM2-extended** (facultatif) : les recipes complètes pour le corps et la reconstitution à partir des en-têtes Message-Instance. Il exige un état persistant, sera plus long à adopter, et implique une charge plus lourde en matière de vie privée.
- Règle en cas d'algorithmes multiples : si l'une des signatures d'un saut échoue, tout le saut est invalide (ce qui empêche les attaques par rétrogradation).

## Calendrier réaliste et ce qu'un ESP devrait faire

- Aucune RFC n'existe encore, et la spécification centrale en est à la version -04, avec d'importantes questions non résolues. Même après publication, DKIM2 n'apporte ses garanties que lorsque chaque saut d'un chemin y participe. Attendez-vous à une **transition de plusieurs années**, pendant laquelle signer à la fois avec DKIM1 et DKIM2 sera la norme, et DKIM1 avec DMARC restera ce qu'appliquent les fournisseurs de messagerie. Pour comparaison, ARC (RFC 8617, 2019) n'est encore que partiellement déployé.
- Ce qu'un fournisseur de services de messagerie (ESP) devrait faire maintenant : rien en production. Suivez les révisions du draft et la liste ietf-dkim. Assurez-vous que vos chaînes de signature peuvent ajouter un second type de signature et des données d'enveloppe pour chaque message, ce qui est la principale exigence d'architecture de DKIM2. Continuez d'appliquer les protections actuelles contre le rejeu ([sursignature, sélecteurs par flux](https://emailmarketing.net/fr/apprendre/authentification/attaques-par-rejeu-dkim)).
- Ce qu'il faut surveiller : le dernier appel du groupe de travail (WG last call) sur dkim2-spec, l'annonce de pilotes côté réception chez Gmail, Yahoo et Fastmail (les employeurs des coauteurs), et l'intégration ou non des simplifications du profil milter.

## Voir aussi

- [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim), la norme actuelle à laquelle DKIM2 succéderait à terme
- [Attaques par rejeu DKIM](https://emailmarketing.net/fr/apprendre/authentification/attaques-par-rejeu-dkim)
- [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc), le mécanisme provisoire pour les intermédiaires que DKIM2 vise à rendre obsolète
- [Backscatter et BATV](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/backscatter-et-batv)

# DMARC (Domain-based Message Authentication, Reporting, and Conformance)

> Ce que DMARC fait et ne fait pas, comment il s'appuie sur SPF et DKIM, l'alignement de domaine, l'enregistrement DNS et le choix d'une politique de traitement.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/dmarc

## Pourquoi les propriétaires de domaines publient DMARC

N'importe qui peut inscrire votre domaine dans la ligne From que voient les destinataires. DMARC vous donne, à vous qui possédez ce domaine, le moyen de montrer aux serveurs de réception lesquels de ces emails vous avez autorisés. Pour cela, il confronte les résultats de [SPF](https://datatracker.ietf.org/doc/html/rfc7208) (Sender Policy Framework) et de [DKIM](https://datatracker.ietf.org/doc/html/rfc6376) (DomainKeys Identified Mail) au domaine de l'en-tête RFC5322.From, que l'on appelle aussi le « Friendly From ».

Pour un domaine qui envoie en volume, DMARC n'est plus facultatif. Google et Yahoo exigent tous deux des expéditeurs de gros volumes qu'ils publient un enregistrement DMARC avant d'envisager d'accepter et de livrer leurs emails.

Les sections qui suivent présentent les idées sur lesquelles repose DMARC et la forme générale d'une mise en place. Elles ne forment pas un guide pas à pas complet.

## Quelle spécification s'applique

La RFC 7489 a décrit DMARC pour la première fois en 2015, sous la forme d'un document informatif (Informational). En mai 2026, son successeur, appelé DMARCbis, est devenu une **Proposed Standard** en trois parties : la [RFC 9989](https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc) pour le protocole de base, la [RFC 9990](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc) pour les rapports agrégés et la [RFC 9991](https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc) pour les rapports d'échec. Ensemble, elles rendent obsolètes la RFC 7489 et la RFC 9091.

Les notions de cette page valent sous les deux spécifications, et les quelques détails qui ont changé depuis la RFC 7489 sont signalés là où ils se présentent. Pour chaque balise de l'enregistrement, et pour le DNS Tree Walk qui remplace la Public Suffix List, voir la [référence de la norme DMARC](https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc). Pour un déploiement approfondi, notamment la politique des sous-domaines, les nouvelles balises `np` et `t` et le traitement des rapports, voir [Déploiement de DMARC en détail](https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc).

## Les trois fonctions de DMARC

Un enregistrement DMARC permet au propriétaire d'un domaine :

- d'empêcher des tiers d'utiliser le domaine sans permission dans l'en-tête RFC5322.From, ce qui constitue l'usurpation d'identité (spoofing)
- de demander aux fournisseurs de messagerie des rapports sur les emails qui affichent le domaine dans cet en-tête
- de demander aux serveurs de réception de traiter d'une manière précise tout message qui affiche le domaine à cet endroit mais échoue à la vérification DMARC

## Ce que DMARC ne résout pas

DMARC répond à une seule question : le propriétaire du domaine a-t-il autorisé cette utilisation du domaine From ? Un message qui réussit la vérification peut tout de même être du spam.

Deux procédés d'usurpation courants lui échappent aussi :

- **Domaines sosies.** Une politique DMARC sur « example.com » reste sans effet sur les emails venant d'une copie proche comme « ex4mple.com ». La copie est un autre domaine, avec son propre DNS.
- **Attaques par nom d'affichage.** L'attaquant envoie depuis un domaine qu'il contrôle et inscrit un nom de confiance dans le nom d'affichage, la partie que beaucoup d'applications de messagerie montrent en premier :

  > From: "Your Bank Security Team" \<alerts@unrelated-sender.example\>

## SPF et DKIM en bref

**SPF** vérifie le chemin qu'a suivi un message. Le propriétaire d'un domaine indique dans le DNS les serveurs et les réseaux autorisés à envoyer des emails dont l'adresse RFC5321.MailFrom, aussi appelée « Envelope From », utilise ce domaine. Les serveurs de messagerie s'appuient sur cette adresse lorsqu'ils se transmettent les emails. Elle aboutit dans l'en-tête `Return-Path`, et la plupart des destinataires ne la voient jamais.

**DKIM** vérifie le message lui-même. Le domaine qui prend la responsabilité d'un message ajoute un en-tête `DKIM-Signature`. Cet en-tête contient deux empreintes cryptographiques du message et les informations dont un serveur de réception a besoin pour les vérifier. Ajouter cet en-tête s'appelle signer le message, et le domaine qui y figure est le « domaine d= de DKIM ». Quand la vérification réussit, le serveur de réception sait que les parties signées du message n'ont pas changé depuis la signature.

## Domaine organisationnel et alignement

DMARC ajoute deux termes qui lui sont propres :

- **Domaine organisationnel** (*Organizational Domain*) : le domaine enregistré qui porte la présence sur Internet d'une entreprise, d'une marque ou de toute autre organisation, par exemple « example.com ».
- **Alignement de domaine** (*Domain Alignment*) : deux domaines sont alignés lorsqu'ils ont le même domaine organisationnel. Ainsi, « billing.example.com » est aligné avec « sales.example.com », et aussi avec « example.com » lui-même. En revanche, « example.net » n'est pas aligné avec « sales.example.com », même quand une seule entreprise possède les deux.

C'est l'alignement souple, que les serveurs de réception appliquent par défaut. Le propriétaire d'un domaine peut demander à la place un alignement strict, dans lequel les deux domaines doivent être identiques.

## Comment un message réussit DMARC

Le serveur de réception commence par chercher un enregistrement DMARC pour le domaine RFC5322.From. S'il en trouve un, le message réussit si au moins une de ces conditions est remplie :

- une signature DKIM est **vérifiée**, et son domaine d= est **aligné** avec le domaine From
- SPF **réussit** pour le domaine RFC5321.MailFrom, et ce domaine est **aligné** avec le domaine From

Une seule réussite alignée suffit : vous n'avez pas besoin des deux. Les [Email Authentication Recommended Best Practices du Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG)](https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf) demandent pourtant aux expéditeurs d'obtenir une réussite alignée avec **les deux**. Si vous ne pouvez en assurer qu'une, choisissez **DKIM**. Les fournisseurs de messagerie lui accordent plus de poids qu'à SPF, dans DMARC comme lorsqu'ils décident qui peut rejoindre les feedback loops et les autres programmes destinés aux expéditeurs.

## Publier l'enregistrement

Vous participez à DMARC en ajoutant un enregistrement **TXT** dans le DNS de votre domaine. Son format a d'abord été fixé par la [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489), et il est désormais défini par la [RFC 9989](https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc), sur la voie des normes. L'enregistrement est une liste de paires balise-valeur séparées par des points-virgules. Tout enregistrement doit contenir les deux premières balises ci-dessous, et la troisième est vivement recommandée :

| Balise | Contenu |
|---|---|
| `v=` | La version. Elle n'a aujourd'hui qu'une valeur valide, `DMARC1`, et doit ouvrir l'enregistrement sous la forme `v=DMARC1;` |
| `p=` | Ce que vous demandez aux serveurs de réception de faire des emails qui échouent à DMARC. `none` leur demande de les traiter comme si DMARC n'avait pas échoué, `quarantine` de les livrer dans le dossier spam, et `reject` de les refuser. Faites de votre **premier** enregistrement `p=none;` et durcissez-le plus tard, sauf si le domaine est tout nouveau ou n'envoie aucun email. |
| `rua=` | La boîte aux lettres qui reçoit les **rapports agrégés**, par exemple `rua=mailto:dmarc-reports@example.com`. Les fournisseurs qui vérifient DMARC envoient généralement ces rapports une fois par jour. Chacun est un fichier XML de statistiques sur les emails qui ont utilisé votre domaine dans l'en-tête From, regroupées par adresse IP d'envoi, par résultat d'authentification et selon d'autres champs. Ce sont des logiciels qui les lisent, pas des personnes : donnez-leur une boîte aux lettres à part. |

## Passer à une politique contraignante

Pour la plupart des domaines, `p=none` est le bon point de départ. Un domaine qui veut une protection forte contre l'usurpation d'identité, ou qui voudra peut-être afficher un jour son logo grâce à [BIMI](https://bimigroup.org/), passera ensuite à `p=quarantine` ou à `p=reject`. Chacune de ces politiques est dite **contraignante** (*enforcement*) : les emails qui utilisent le domaine sans autorisation n'atteignent plus la boîte de réception. Le M3AAWG va plus loin et voit dans la politique de surveillance un état transitoire, à quitter dès que possible.

Laissez les **rapports agrégés** décider du moment. Pour chaque source qui envoie avec votre domaine, ils montrent si elle s'authentifie avec DKIM, avec SPF ou avec les deux. Dès que toutes les sources légitimes y parviennent, durcissez la politique.

## Le faire soi-même ou faire appel à un spécialiste

Un propriétaire de domaine qui dispose de compétences techniques suffisantes peut mener en interne tout le travail lié à DMARC. Beaucoup trouvent plus simple de faire appel à un prestataire externe. [dmarcvendors.com](https://dmarcvendors.com/) tient une liste de prestataires de services DMARC, ainsi que des ressources pour se former à DMARC.

## Voir aussi

- [Référence de la norme DMARC](https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc) (RFC 9989 et DMARCbis)
- [Déploiement de DMARC en détail](https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc)
- [Rapports agrégés DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc) (RFC 9990)
- [Rapports d'échec DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc) (RFC 9991)
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)

# L'en-tête Authentication-Results

> Référence RFC 8601 : syntaxe de l'en-tête dans lequel les serveurs de réception consignent les résultats SPF/DKIM/DMARC/iprev, types de propriétés et propriétés, codes de résultat par méthode, et comment en lire un.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results

Pour voir exactement comment un serveur de réception a jugé votre authentification, ouvrez un message qu'il a livré et lisez son en-tête `Authentication-Results:`. C'est le moyen le plus rapide de le savoir.

La RFC 8601 définit cet en-tête. Un système de réception l'ajoute en tête du message pour consigner le résultat des vérifications d'authentification qu'il a effectuées ([SPF](https://emailmarketing.net/fr/apprendre/authentification/spf), [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim), [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc), iprev, SMTP AUTH et autres). Les filtres et les clients de messagerie (MUA) situés plus loin sur le parcours, ainsi que les personnes qui diagnostiquent un problème, peuvent ensuite exploiter ces résultats sans refaire les vérifications.

## Syntaxe

```
Authentication-Results: <authserv-id> [version];
    <method>=<result> [reason="..."] [<ptype>.<property>=<value>] ... ;
    <method>=<result> ... ;
```

- **authserv-id** identifie le système qui a effectué les vérifications, en général par un domaine DNS (par exemple `mx.google.com`). Il vous indique de qui vient le verdict que vous lisez.
- Chaque clause **resinfo**, séparée des autres par des points-virgules, rapporte le résultat d'une méthode. Elle peut comprendre un texte libre `reason` et une ou plusieurs paires `ptype.property=value` qui identifient ce qui a été évalué.
- `Authentication-Results: example.com; none` signifie que le serveur de réception n'a effectué aucune vérification.
- Plusieurs méthodes peuvent figurer dans un même en-tête, ou le serveur de réception peut ajouter plusieurs en-têtes (un par méthode ou par saut).

## Types de propriétés (ptypes)

| ptype | Valeurs tirées de |
|---|---|
| `smtp` | Commandes du protocole SMTP (par exemple `smtp.mailfrom`, `smtp.helo`, `smtp.auth`) |
| `header` | Champs d'en-tête du message ou parties de ceux-ci (par exemple `header.d`, `header.i`, `header.b`, `header.from`) |
| `body` | Contenu du corps du message (aucune propriété n'est enregistrée à ce jour) |
| `policy` | Informations de politique locale qui complètent ou remplacent les résultats bruts (par exemple `policy.iprev`) |

## Méthodes courantes et leurs codes de résultat

| Méthode | Codes de résultat | Propriétés principales |
|---|---|---|
| `spf` | pass, fail, softfail, neutral, none, policy, temperror, permerror | `smtp.mailfrom` (le domaine ou l'adresse MAIL FROM complète vérifiée), `smtp.helo` |
| `dkim` | pass, fail, none, neutral, policy, temperror, permerror | `header.d` (domaine signataire), `header.i` (AUID), `header.s` (sélecteur), `header.b` (les premiers octets de la signature, pour distinguer plusieurs signatures) |
| `dmarc` (enregistrée par la RFC 7489) | pass, fail, none, temperror, permerror | `header.from` (le domaine RFC5322.From évalué), souvent avec des commentaires `policy.dmarc` qui indiquent le traitement appliqué |
| `iprev` | pass, fail, temperror, permerror | `policy.iprev` (l'adresse IP du client dont le DNS inverse a été validé) |
| `auth` (SMTP AUTH) | pass, fail, none, temperror, permerror | `smtp.auth` (l'identité authentifiée), `smtp.mailfrom` |
| `arc` (enregistrée par la RFC 8617) | none, pass, fail | Voir [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc) |

Lorsque `policy` apparaît comme résultat, la vérification a abouti, mais la politique locale a supprimé ou remplacé le résultat normal.

## Lire un en-tête : exemple commenté

```
Authentication-Results: mx.google.com;
    dkim=pass header.i=@example.com header.s=s2048 header.b=Kx4pR2;
    spf=pass (google.com: domain of bounce.example.com designates 203.0.113.5
      as permitted sender) smtp.mailfrom=news@bounce.example.com;
    dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
```

Le serveur MX de Google a vérifié le message :

- Une signature DKIM de `example.com` (sélecteur `s2048`) a été vérifiée.
- SPF a réussi pour le domaine de rebond `bounce.example.com` depuis l'adresse IP 203.0.113.5.
- DMARC a réussi pour le domaine From: `example.com`. Sa politique publiée est reject, et le traitement appliqué est none, ce qui signifie que le message a été livré.

DKIM est aligné, car d= est identique au domaine From:. SPF réussit, et `bounce.example.com` est aligné avec `example.com` en alignement souple. Les deux voies vers un pass DMARC ont réussi.

## Confiance et règle de suppression

Un expéditeur peut facilement falsifier cet en-tête, donc sa sécurité repose sur un **traitement rigoureux à la frontière de confiance** :

- Un MTA conforme à la RFC 8601 **DOIT supprimer** toute instance de l'en-tête qui prétend (par son authserv-id) avoir été ajoutée à l'intérieur de la frontière de confiance du serveur de réception, mais qui ne provient pas réellement d'un MTA interne de confiance. Les MTA de bordure suppriment ou renomment les instances entrantes qui portent leur propre authserv-id avant d'ajouter la leur, authentique.
- Les filtres et les MUA ne devraient faire confiance qu'aux en-têtes dont l'authserv-id appartient à leur propre ADMD. Tout le reste est une donnée extérieure non fiable.
- Pour diagnostiquer un problème de délivrabilité, lisez donc l'en-tête Authentication-Results **le plus haut** dont l'authserv-id correspond au fournisseur de réception final. Les en-têtes plus bas peuvent être périmés (issus de sauts antérieurs) ou falsifiés.

## Relation avec les autres en-têtes

- `Received-SPF:` est l'en-tête plus ancien, propre à SPF, qui consigne le résultat à chaque saut (RFC 7208). Dans la pratique, Authentication-Results l'a remplacé comme moyen unique de rapporter les résultats.
- `ARC-Authentication-Results:` reprend exactement ce format pour consigner un instantané des résultats à chaque saut de transfert (voir [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc)).

## Voir aussi

- [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf)
- [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim)
- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)
- [Rapports agrégés DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc), les mêmes résultats rassemblés sur l'ensemble des serveurs de réception

# Rapports agrégés DMARC (RFC 9990)

> Le format XML des rapports agrégés : structure du rapport, transport, conventions de nom de fichier et d'objet, vérification des destinations externes et motifs de dérogation à la politique.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc

Quand l'enregistrement DMARC de votre domaine indique une adresse `rua=`, les serveurs de réception envoient régulièrement à cette adresse des récapitulatifs XML des emails qui utilisent votre domaine. Ces rapports agrégés sont la principale source de données pour décider quand un domaine peut passer à une politique contraignante (voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)).

La RFC 9990 définit le format du rapport. C'est une spécification sur la voie des normes publiée en mai 2026, et l'un des trois documents DMARCbis qui rendent ensemble obsolète la RFC 7489, avec la [RFC 9989](https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc) et la [RFC 9991](https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc).

## Contenu d'un rapport

Un rapport est un document XML dont l'élément racine est `feedback` et l'espace de noms `urn:ietf:params:xml:ns:dmarc-2.0`. Il comporte trois parties :

| Section | Contenu |
|---|---|
| **Métadonnées du rapport** | Le nom de l'organisation qui produit le rapport, une adresse email de contact, un identifiant unique du rapport, et le début et la fin de la période couverte, en secondes Unix. |
| **Politique publiée** | L'enregistrement DMARC que le serveur de réception a trouvé : le domaine, `p`, `sp` et `np`, `adkim` et `aspf`, et la façon dont l'enregistrement a été découvert (correspondance exacte ou Tree Walk). |
| **Enregistrements** (un ou plusieurs) | Les résultats pour chaque adresse IP source : la ligne, les identifiants et les résultats d'authentification bruts décrits ci-dessous. |

### Éléments de chaque enregistrement

| Élément | Champs |
|---|---|
| `row` | L'adresse IP source (IPv4 ou IPv6) ; le **nombre** de messages pour cette combinaison d'adresse IP et de traitement ; le **traitement** appliqué (`none`, `pass`, `quarantine`, `reject`) ; et les résultats d'**alignement** DKIM et SPF, pass ou fail, tels que DMARC les évalue. |
| `identifiers` | `header_from`, le domaine RFC5322.From (obligatoire) ; `envelope_from`, le domaine RFC5321.MailFrom (facultatif) ; et le domaine `envelope_to` (facultatif). |
| `auth_results` | Le résultat brut de chaque mécanisme. Les entrées DKIM donnent le domaine, le **sélecteur** (son signalement est obligatoire dans la 9990), le résultat et une note facultative destinée à être lue par des personnes. Les entrées SPF donnent le domaine, la portée (`mfrom`) et le résultat. |

Quand un message porte de nombreuses signatures DKIM, le serveur de réception les signale dans cet ordre de priorité : un pass avec alignement strict, puis un pass avec alignement souple, puis les autres signatures valides, puis les signatures en échec. La spécification recommande de signaler au plus environ 100 signatures par ligne.

### Motifs de dérogation à la politique

Quand le traitement appliqué par le serveur de réception diffère de la politique publiée, l'enregistrement en donne la raison :

| Motif | Signification |
|---|---|
| `local_policy` | Une exemption locale du serveur de réception, souvent fondée sur ARC (voir [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc)) |
| `mailing_list` | Les heuristiques du serveur de réception ont détecté une liste de diffusion |
| `policy_test_mode` | Le mode test `t=y` de l'enregistrement était actif |
| `trusted_forwarder` | Une exemption accordée à un service de transfert connu |
| `other` | Tout autre motif, avec un commentaire facultatif |

## Calendrier et transport

- La période couverte est généralement **un jour UTC, qui commence à 00:00 UTC**. Les périodes NE DEVRAIENT PAS se chevaucher.
- Les rapports sont envoyés **par email** à chaque URI mailto de `rua=`. Le serveur de réception écarte d'abord toute URI mal formée, puis doit tenter la livraison vers chacune des URI restantes.
- Le contenu DEVRAIT être du **XML compressé en GZIP** (`application/gzip`). À défaut, il est envoyé en `text/xml`.
- Le nom du fichier joint suit le modèle `receiver!policy-domain!begin-timestamp!end-timestamp[!unique-id].extension`, par exemple `mail.receiver.example!example.com!1013662812!1013749130.xml.gz`.
- La ligne d'objet suit le modèle `Report Domain: <policy-domain> Submitter: <reporter-domain> Report-ID: <id>`.
- Le flux d'emails qui transporte les rapports **doit lui-même réussir DMARC** avec un pass aligné. Un transport sécurisé (STARTTLS ou TLS) est recommandé.

## Destinations de rapport externes

Si une adresse `rua=` se trouve hors du domaine organisationnel du domaine de la politique, le serveur de réception confirme d'abord que la destination a accepté de recevoir les rapports. Il interroge cet enregistrement :

```
<policy-domain>._report._dmarc.<destination-host>   (TXT)
```

L'enregistrement doit contenir `v=DMARC1`, et il peut remplacer l'URI de rapport. Si l'enregistrement est absent, le serveur de réception n'envoie pas les rapports à l'adresse externe. C'est pourquoi les prestataires tiers de surveillance DMARC vous demandent soit de publier cet enregistrement de « vérification de destination externe » pour le compte de leur domaine, soit le publient déjà sur leur propre domaine.

## Changements par rapport à la RFC 7489

- Le schéma XML (XSD) est resserré et clarifié, et les identifiants de rapport sont structurés plus rigoureusement.
- **Le signalement du sélecteur DKIM est obligatoire.** Les rapporteurs soumis à la 7489 l'omettaient souvent. Avec le sélecteur, il est bien plus facile d'identifier quel système a produit une signature en échec.
- La prise en compte des domaines de suffixe public (*Public Suffix Domains*) est intégrée, et un mécanisme d'extension est ajouté.
- Le document unique de la RFC 7489 a été scindé en trois : 9989 (base), 9990 (rapports agrégés) et 9991 (rapports d'échec).

## Exploiter les rapports agrégés

- Les rapports sont des documents XML lisibles par des machines, et ils arrivent chaque jour de tous les grands serveurs de réception. Personne ne les lit à la main à grande échelle : dirigez donc `rua=` vers une boîte aux lettres dédiée ou vers un service d'analyse DMARC.
- Servez-vous-en pour répondre à une question : quelles sources envoient des emails au nom de mon domaine, et ces emails obtiennent-ils un pass aligné ? Des lignes en échec sur les deux mécanismes, depuis des adresses IP que vous reconnaissez, désignent une source légitime mal configurée ; corrigez [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf), [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim) ou l'alignement. Des lignes provenant d'adresses IP que vous ne reconnaissez pas désignent une usurpation d'identité (spoofing) ou de l'informatique parallèle (*shadow IT*).
- Quand toutes les sources légitimes affichent des pass alignés sur une période prolongée, le domaine est prêt pour `p=quarantine` ou `p=reject`.

## Voir aussi

- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)
- [Référence de la norme DMARC](https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc)
- [Rapports d'échec DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc)
- [En-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results), les mêmes données pour un seul message

# Rapports d'échec DMARC (RFC 9991)

> Les rapports d'échec DMARC par message (rapports « forensiques ») : format ARF, champs obligatoires, balises ruf et fo, contraintes de vie privée, et pourquoi peu de fournisseurs en envoient.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc

Lorsque vos rapports DMARC agrégés montrent qu'une source échoue, un rapport d'échec peut vous montrer un message précis en échec, pour que vous voyiez pourquoi il a échoué. Lorsque l'enregistrement DMARC de votre domaine indique une adresse pour les rapports d'échec, les serveurs de réception peuvent envoyer à cette adresse un rapport chaque fois qu'un message précis échoue à DMARC. Ces **rapports d'échec** sont souvent appelés « rapports forensiques » (*forensic reports*), et ils diffèrent des [rapports agrégés](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc) statistiques quotidiens.

La RFC 9991 les définit. C'est une spécification de la voie normative publiée en mai 2026, et l'un des documents DMARCbis, avec la [RFC 9989](https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc) et la [RFC 9990](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc). Elle met à jour la RFC 6591 et remplace la partie de la RFC 7489 consacrée aux rapports d'échec.

Les rapports d'échec ont deux usages : diagnostiquer des échecs d'authentification individuels repérés d'abord dans les données agrégées, et révéler rapidement qu'une personne abuse directement et activement de votre domaine.

## Déclenchement : les balises `ruf` et `fo`

Ces balises se configurent dans l'enregistrement DMARC du domaine (voir le [registre des balises](https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc)) :

| Balise | Rôle |
|---|---|
| `ruf=` | Une liste d'URI `mailto:` séparées par des virgules, qui reçoivent les rapports d'échec. Le serveur de réception doit tenter la livraison vers chaque destination listée. Les destinations externes doivent être vérifiées de la même manière que pour les rapports agrégés (`<policy-domain>._report._dmarc.<destination-host>`). |
| `fo=` | Quand envoyer un rapport. `0` (la valeur par défaut) signifie uniquement lorsque **aucun** mécanisme n'a produit de réussite alignée. `1` signifie lorsque **un** mécanisme quelconque a échoué. `d` signifie à tout échec DKIM, quel que soit l'alignement. `s` signifie à tout échec SPF, quel que soit l'alignement. Les valeurs peuvent être combinées, séparées par des deux-points (par exemple, `fo=1:d:s`). |

Les rapports sont « normalement générés et envoyés presque immédiatement après que le serveur de réception a détecté un échec DMARC ». Ils arrivent quasiment en temps réel, contrairement aux rapports agrégés quotidiens.

## Format des rapports

Les rapports d'échec utilisent l'**Abuse Reporting Format (ARF)** de la RFC 6591 (`message/feedback-report`, avec le type de feedback `auth-failure`), avec des champs ajoutés pour DMARC :

| Champ | Obligatoire ? | Contenu |
|---|---|---|
| `Identity-Alignment` | Obligatoire | Une liste, séparée par des virgules, des mécanismes qui ont échoué à l'alignement : `dkim`, `spf` ou `none`. |
| `DKIM-Domain`, `DKIM-Identity`, `DKIM-Selector` | Obligatoires pour les échecs DKIM | La signature qui a échoué (`d=`, `i=`, `s=`). |
| `SPF-DNS` | Obligatoire pour les échecs SPF | L'enregistrement DNS SPF concerné. |
| `Delivery-Result` | Facultatif | Ce que le serveur de réception a fait du message. |
| `DKIM-Canonicalized-Header`, `DKIM-Canonicalized-Body` | Facultatifs | Les formes canonicalisées, pour déboguer une signature cassée. |

Le rapport contient généralement les en-têtes du message en échec, et parfois son corps. C'est ce qui rend ce format à la fois utile et sensible pour la vie privée.

## Vie privée

Les rapports d'échec peuvent exposer des **données personnelles** : les adresses de l'expéditeur et du destinataire, le contenu du message et, pour le trafic des listes de diffusion, les membres de la liste. La RFC 9991 demande aux générateurs de rapports :

- de limiter les rapports à des diagnostics ciblés plutôt que de tout envoyer ;
- de valider soigneusement les URI de rapport (vérification des destinations externes) ;
- de caviarder le contenu des messages et les identifiants ;
- d'utiliser des canaux de transmission sécurisés.

**Dans la pratique, la plupart des grands fournisseurs de messagerie n'envoient aucun rapport d'échec**, ou en envoient de fortement caviardés, précisément à cause de ces risques pour la vie privée. Publier `ruf=` ne coûte rien, mais attendez-vous à recevoir peu de rapports. Les rapports agrégés sont le signal fiable, et les rapports d'échec ajoutent du détail quand vous en recevez.

## Sécurité

Les rapports d'échec peuvent servir à une **attaque par déni de service qui inonde une boîte aux lettres de rapports**. Un attaquant qui envoie en masse du courrier usurpé « provenant » du domaine d'une victime peut amener les serveurs de réception à bombarder la boîte `ruf` de la victime. Les générateurs sont tenus de réduire ce risque en regroupant les événements liés (le champ ARF `Incidents`) et en limitant le débit (un nombre maximal de rapports par unité de temps).

## Usage opérationnel

- Servez-vous des rapports d'échec pour comprendre pourquoi une source en échec dans les données agrégées échoue : un mauvais sélecteur, une signature cassée par une passerelle qui ajoute un pied de page (comparez les champs canonicalisés), un domaine de rebond non aligné, etc.
- Envoyez les rapports `ruf=` vers une boîte aux lettres à accès restreint, car les rapports peuvent contenir le contenu de messages d'autres personnes.
- Ne bâtissez pas votre surveillance sur les seuls rapports d'échec. Leur couverture dépend du serveur de réception, et ils proviennent surtout de petits fournisseurs.

## Voir aussi

- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)
- [Référence de la norme DMARC](https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc)
- [Rapports agrégés DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc)
- [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim), pour interpréter les champs de diagnostic DKIM-*

# Référence de la norme DMARC (RFC 9989 / DMARCbis)

> La spécification DMARC en voie normative qui rend obsolète la RFC 7489 : registre complet des balises de l'enregistrement, parcours de l'arborescence DNS (Tree Walk) qui remplace la Public Suffix List, règles d'alignement, découverte de la politique, et ce qui a changé.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc

Quand vous rédigez un enregistrement DMARC, ou que vous devez savoir exactement comment un serveur de réception va le trouver et l'appliquer, les règles viennent désormais de DMARCbis. Vous trouverez ci-dessous ses balises, ses règles d'alignement, la façon dont un serveur de réception découvre la politique applicable à un message, et ce qui a changé par rapport à la spécification précédente.

La RFC 9989 (voie normative, mai 2026) est la spécification DMARC actuelle, et rend obsolètes la RFC 7489 et la RFC 9091. Elle répartit DMARC en trois documents : la **RFC 9989** (protocole central), la **[RFC 9990](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc)** (rapports agrégés) et la **[RFC 9991](https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc)** (rapports d'échec). Pour une introduction à ce que fait DMARC, aux bases de l'alignement et à la stratégie de déploiement, voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Registre complet des balises

L'enregistrement est publié sous forme d'enregistrement TXT à `_dmarc.<domain>`. Les balises sont des paires `key=value` séparées par des points-virgules, et `v=` doit venir en premier.

| Balise | Valeurs | Par défaut | Signification |
|---|---|---|---|
| `v` | `DMARC1` | obligatoire, première balise | Version. |
| `p` | `none` \| `quarantine` \| `reject` | `none` si absente | Traitement demandé pour les messages du domaine qui échouent à DMARC. |
| `sp` | comme `p` | hérite de `p` | Politique pour les **sous-domaines existants** du domaine de l'enregistrement. |
| `np` | comme `p` | hérite de `sp`, puis de `p` | **Nouveau dans la 9989.** Politique pour les **sous-domaines inexistants** (sans enregistrement A, AAAA ou MX). Par exemple, vous pouvez fixer `p=none; np=reject` pour bloquer l'usurpation de sous-domaines inventés pendant que vous faites encore évoluer le domaine principal vers une politique contraignante. |
| `adkim` | `r` \| `s` | `r` | Mode d'alignement DKIM : souple (même domaine organisationnel) ou strict (domaine identique). |
| `aspf` | `r` \| `s` | `r` | Mode d'alignement SPF. |
| `rua` | URI `mailto:` séparées par des virgules | aucune | Destinations des [rapports agrégés](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc). |
| `ruf` | URI `mailto:` séparées par des virgules | aucune | Destinations des [rapports d'échec](https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc). |
| `fo` | `0` \| `1` \| `d` \| `s` (combinaisons séparées par des deux-points) | `0` | Quand envoyer des rapports d'échec : `0` signifie un rapport uniquement si **tous** les mécanismes échouent à produire un pass aligné ; `1` signifie un rapport si **un** mécanisme quelconque échoue ; `d` signifie un rapport des échecs DKIM quel que soit l'alignement ; `s` signifie un rapport des échecs SPF quel que soit l'alignement. |
| `psd` | `y` \| `n` \| `u` | `u` | **Nouveau dans la 9989.** Indique si ce domaine est un domaine de suffixe public (Public Suffix Domain, `y`), s'il n'en est certainement pas un (`n`), ou si c'est inconnu (`u`). Utilisé par le Tree Walk. |
| `t` | `y` \| `n` | `n` | **Nouveau dans la 9989.** Mode test : `t=y` demande aux serveurs de réception de traiter la politique comme indicative (évaluer et produire des rapports, sans appliquer le traitement). Remplace `pct`. |

**Retirées par rapport à la RFC 7489 :** `pct` (échantillonnage en pourcentage, remplacé par la balise `t`, qui s'applique à tous les messages ou à aucun) et `ri` (intervalle des rapports). Les serveurs de réception qui rencontrent encore d'anciens enregistrements ignorent simplement les balises inconnues ou retirées.

Si un enregistrement n'a pas de balise `p` valide mais possède une balise `rua` valide, les serveurs de réception le traitent comme `p=none` (surveillance seule) au lieu de l'écarter.

## Alignement

Un **identifiant authentifié** (*Authenticated Identifier*) est le domaine `d=` d'une signature DKIM valide, ou le domaine RFC5321.MailFrom validé par SPF.

- **Souple** (par défaut) : le domaine From: et l'identifiant authentifié ont le même **domaine organisationnel**.
- **Strict** : les domaines doivent être identiques.
- La comparaison ne tient pas compte de la casse. Un pass aligné de DKIM **ou** de SPF donne un pass DMARC.

## Le parcours de l'arborescence DNS (Tree Walk, qui remplace la Public Suffix List)

La RFC 7489 s'appuyait sur la Public Suffix List, une liste tenue pour les navigateurs web, pour trouver le domaine organisationnel d'un domaine. La RFC 9989 la remplace par un **parcours de l'arborescence** (*Tree Walk*) dans le DNS, limité à **8 requêtes** par parcours :

1. Interroger `_dmarc.<domain>` pour le domaine exact. Écarter tout ce qui ne commence pas par `v=DMARC1`.
2. Si le nom compte plus de 8 libellés, passer directement à ses 7 derniers libellés (les plus à droite) pour les étapes suivantes.
3. Retirer le libellé le plus à gauche, et interroger `_dmarc.` à chaque nom plus court, l'un après l'autre.
4. S'arrêter plus tôt lorsqu'un enregistrement avec `psd=n` ou `psd=y` est trouvé. Ces enregistrements marquent la frontière entre l'organisation et le suffixe public.
5. Le parcours se termine lorsqu'un enregistrement approprié est trouvé ou qu'il ne reste plus de libellés.

Le **domaine organisationnel** est déterminé à partir des résultats du parcours : c'est le domaine situé juste sous le point où apparaît `psd=y`, ou le nom le plus long qui porte un enregistrement ou `psd=n`. Par rapport à la PSL, cela modifie le comportement dans les cas limites, pour les zones à délégation profonde. Pour des configurations typiques comme `example.com` et `mail.example.com`, le résultat est le même.

## Découverte de la politique pour un message

1. Interroger `_dmarc.<RFC5322.From domain>`. Si un enregistrement DMARC valide existe, l'utiliser.
2. Sinon, effectuer le Tree Walk vers le haut. Le premier enregistrement valide trouvé s'applique.
3. Lorsque l'enregistrement applicable a été trouvé **au-dessus** du domaine From: (c'est-à-dire que le domaine From: est un sous-domaine), utiliser `sp` si le sous-domaine existe dans le DNS, et `np` s'il n'existe pas. À défaut, revenir à `p`.
4. S'il n'existe aucun enregistrement valide nulle part, DMARC ne s'applique pas au message (traitement `none`, résultat « none » dans [Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results)).

## Conséquences opérationnelles

- **Publiez `psd=n`** dans l'enregistrement d'un domaine organisationnel si vous déléguez des arborescences profondes de sous-domaines. Cela fixe le point où le Tree Walk s'arrête, et évite que des emails soient attribués au mauvais domaine.
- **Utilisez `np=`** pour vous protéger contre l'usurpation de sous-domaines inexistants, même tant que la politique principale est encore `p=none` pendant le déploiement.
- **`t=y` remplace l'augmentation progressive de `pct=`.** Avec la RFC 7489, `pct=25` donnait une application partielle. Avec la 9989, soit vous appliquez, soit vous testez. Planifiez les déploiements par étapes, d'abord `p=none`, puis `t=y` avec `p=quarantine/reject`, puis la politique contraignante, en vous guidant sur les données des rapports agrégés comme décrit dans [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).
- Les serveurs de réception adoptent DMARCbis progressivement. Attendez-vous à une longue période pendant laquelle la sémantique de la RFC 7489 (PSL, `pct`) et celle de la RFC 9989 (Tree Walk, `t`, `np`, `psd`) seront toutes deux utilisées. Les enregistrements qui ne contiennent que les balises communes aux deux (`v`, `p`, `sp`, `adkim`, `aspf`, `rua`, `ruf`, `fo`) se comportent de la même façon sous les deux.

## Voir aussi

- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc), sur les concepts, les bases de l'alignement et la stratégie de déploiement
- [Rapports agrégés DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc) (RFC 9990)
- [Rapports d'échec DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc) (RFC 9991)
- [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf)
- [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim)
- [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc)

# Rotation des clés DKIM

> Les meilleures pratiques M3AAWG pour la rotation des clés DKIM (rév. mars 2019) : rotation semestrielle, schémas de nommage des sélecteurs, procédure à deux clés actives, retrait par p= vide, délégation par CNAME ou sous-domaine pour les tiers, et audit des rotations.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/rotation-des-cles-dkim

Si vous signez votre courrier avec DKIM, vos clés doivent être remplacées selon un calendrier. Les *DKIM Key Rotation Best Common Practices* du M3AAWG recommandent à quelle fréquence et comment. Le document porte la référence M3AAWG078, a été publié pour la première fois en 2013 et révisé en mars 2019 (URL de référence m3aawg.org/DKIMKeyRotation). La révision de 2019 a fait passer le cycle recommandé de **trimestriel à tous les six mois**, et a remanié la convention de nommage des sélecteurs.

Ces recommandations portent sur la pratique de la rotation. Pour le fonctionnement de DKIM lui-même (la syntaxe des signatures et des enregistrements de clé, et les algorithmes), voir [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim).

## Pourquoi faire tourner les clés

- Les clés publiques DKIM sont publiées dans le DNS, où tout le monde peut les examiner, ce qui en fait une cible. Garder courte la durée de vie active d'une paire de clés limite les dégâts si une clé est cassée **ou volée** sur un système de signature compromis.
- Longueur de clé et cassage (RSA, selon le document) : les clés de 512 bits peuvent être cassées en quelques heures. Zachary Harris en a cassé une en ~72 heures pour ~75 $ de calcul AWS en 2012, et les clés de 512 bits ont été formellement rendues obsolètes par la RFC 8301 en janvier 2018. Une clé de 1024 bits est « à la limite de l'attaque » pour des systèmes généralistes. **Une clé de 2048 bits est considérée comme impossible à casser avec la puissance de calcul actuelle.** Des États pouvaient casser des clés de 768 bits dès ~2012.
- Une rotation régulière construit un savoir-faire au sein de l'organisation, si bien qu'une **rotation d'urgence hors du cycle normal** après une compromission peut être faite rapidement. (Google a fait tourner ses clés en quelques jours après la divulgation de 2012 ; d'autres entreprises ont mis des mois.)

## Fréquence

**Faites tourner les clés au moins tous les six mois.** Les membres du M3AAWG ont conclu qu'une rotation deux fois par an équilibre le risque de compromission et l'effort opérationnel, pour les organisations qui ont des flux de messagerie complexes et des dépendances envers des tiers. Les organisations aux flux plus simples peuvent faire tourner leurs clés plus souvent : une rotation trimestrielle réduit encore le risque de cassage, si l'exploitation le permet. Une rotation annuelle est déconseillée, car elle augmente le risque de compromission et laisse aussi s'effacer le savoir-faire de l'organisation sur la procédure. Choisissez des dates qui évitent les pics d'activité, par exemple avril et octobre pour l'e-commerce.

Une rotation régulière apporte d'autres avantages :

- Les services apprennent à travailler ensemble, puisque l'équipe DNS n'est pas l'équipe email.
- Les expéditeurs tiers pratiquent la procédure, si bien que les fournisseurs travaillent aussi ensemble.
- La rotation est conforme à ITIL et à ISO-IEC-20000, car une rotation planifiée est un « changement standard », et non un « changement d'urgence ».
- Elle mène à l'automatisation, comme des scripts qui génèrent les clés. Le M3AAWG insiste deux fois sur le développement de scripts.
- Elle crée de la redondance, avec davantage de personnes capables de faire le travail.

## La procédure de rotation

État de départ, pour un nouveau déploiement DKIM : générez **deux** paires de clés (≥1024 bits), publiez les deux clés publiques dans le DNS, attendez la propagation DNS, puis signez avec la clé privée 1. La clé 2 est prête, « prochaine en ligne ».

```
dkim1._domainkey.example.com   ← active public key 1, used to sign
dkim2._domainkey.example.com   ← public key 2 published for future use
```

À chaque rotation :

1. Générez la paire de clés suivante (clé 3) et publiez sa clé publique dans le DNS. Attendez la propagation avant de l'utiliser.
2. Faites passer le signataire de la clé privée 1 à la clé privée 2.
3. Laissez la clé publique 1 dans le DNS **sans modification pendant au moins 7 jours, et jusqu'à 30 jours**, pour que les serveurs de réception puissent encore valider le courrier en transit ou validé plus tard.
4. Retirez ensuite la clé 1 en laissant **vide le champ `p=`** de l'enregistrement (`"v=DKIM1; p="`). **Ne supprimez pas l'enregistrement du sélecteur.** Le `p=` vide signale que la clé a été retirée volontairement.

Répétez le cycle : 1→2, 2→3, 3→4 et ainsi de suite. Après la rotation de la clé 2 vers la clé 3, les enregistrements se présentent ainsi :

```
dkim1._domainkey.example.com   ← retired ("p=")
dkim2._domainkey.example.com   ← still validates old mail for 7–30 days
dkim3._domainkey.example.com   ← signs current mail
dkim4._domainkey.example.com   ← ready for future use
```

Remarques d'exploitation :

- Inscrivez les activités liées aux clés (génération, retrait) dans un calendrier opérationnel récurrent. Les étapes d'une rotation peuvent **toutes avoir lieu le même jour** : ajoutez la clé n+2 et retirez la clé n−1 le jour même où vous changez de clé de signature, au lieu d'étaler le travail sur plusieurs jours. Le calendrier doit seulement laisser le temps de la propagation DNS avant de signer avec une nouvelle clé, et le temps que le courrier en transit soit livré avant de retirer une ancienne clé.
- Les signatures DKIM prennent en charge une date d'expiration. Il s'agit de `x=` dans la signature selon la RFC 6376 ; le texte du BP l'appelle `t=`, que la RFC 6376 définit comme l'horodatage de la signature. Une date d'expiration peut garantir que les signatures ne survivent pas à la période de rotation, mais seulement s'il est garanti que la rotation aura lieu avant l'expiration des signatures.
- Les serveurs DNS doivent prendre en charge les enregistrements TXT longs pour les clés de ≥1024 bits, si bien que **la récupération des enregistrements par EDNS0 ou TCP** est nécessaire.
- Le BP cite les conseils d'exploitation de la RFC 4871 : ne signez pas avec une clé dont le sélecteur sera révoqué avant que les vérificateurs puissent valider la signature. Lors d'une rotation, commencez immédiatement à signer avec la nouvelle clé, et conservez l'ancienne clé publique « pendant un intervalle de validation raisonnable ».

## Schémas de nommage des sélecteurs

Un sélecteur devrait contenir assez d'informations pour faciliter la rotation. **Ne réutilisez jamais un nom de sélecteur.** La réutilisation fait échouer la validation des anciens messages avec la nouvelle valeur de clé, et elle pose problème aux serveurs de réception qui ont gardé l'ancien enregistrement en cache.

Une convention suggérée : commencez par le service ou le flux responsable, et incluez la longueur de clé et la date d'activation prévue. Par exemple, **`sales-201309-1024`** désigne le flux « sales », une clé mise en service en septembre 2013, et une clé de 1024 bits. Un sélecteur peut contenir la longueur de clé, la date, une chaîne aléatoire, ou une combinaison de ces éléments.

Les sélecteurs qui contiennent une date rendent l'audit possible (voir plus bas). Après une rotation le 1er avril, chaque message que vous échantillonnez devrait être signé avec un sélecteur daté dans le style de `20130401`.

## Domaines tiers et délégués

**La demande de rotation doit venir du propriétaire du domaine organisationnel**, en général le client de l'ESP. Le M3AAWG ne recommande pas que les tiers déclenchent la rotation pour leurs clients. Apprenez plutôt aux clients à faire tourner leurs clés selon ce BP. Ne partagez jamais les mêmes clés DKIM entre plusieurs entités.

Il existe trois modèles de délégation.

### 1. Délégation de clé via le domaine ou un sous-domaine (clés détenues par le client)
Le client génère les paires de clés, publie les clés publiques dans son domaine (ou un sous-domaine), et envoie la clé privée au tiers de façon sécurisée, **uniquement par email chiffré (GPG) ou par SFTP. N'envoyez jamais une clé privée par email non chiffré ni par tout autre moyen qui peut être intercepté, et n'enregistrez jamais de clés privées en local.** Ce modèle exige une coordination à chaque rotation.

Dans une variante, le tiers génère la paire de clés et remet la clé publique au client pour qu'il la publie dans le DNS. Aucune clé privée n'est transférée, mais le client doit confirmer les paramètres de la clé (comme sa taille) et convenir de la date à laquelle la clé sera retirée.

### 2. Délégation de clé via un sous-domaine délégué
Le client délègue un sous-domaine au tiers, qui crée lui-même tous les enregistrements. C'est souple, mais cela ajoute un risque sans rapport avec la rotation : **le tiers pourrait publier sur le sous-domaine un enregistrement DMARC qui remplace la politique de l'organisation.** Auditez tous les domaines délégués.

### 3. Délégation de clé via CNAME
Le détenteur du domaine publie **trois enregistrements CNAME** dans le domaine principal, qui pointent vers des enregistrements que contrôle le tiers. Le tiers garde une clé valide pendant qu'il fait tourner les autres (key_1 expirée, key_2 en signature, key_3 prochaine en ligne) :

```
key1._domainkey.example.com  CNAME  key1.example.com.acme.com
key2._domainkey.example.com  CNAME  key2.example.com.acme.com
key3._domainkey.example.com  CNAME  key3.example.com.acme.com

key1.example.com.acme.com  TXT  "v=DKIM1; p="            (expired)
key2.example.com.acme.com  TXT  "v=DKIM1; p=ADfe34556…"  (signing)
key3.example.com.acme.com  TXT  "v=DKIM1; p=A783Fg4556…" (next)
```

Le tiers peut alors faire tourner les clés selon son propre calendrier sans toucher de nouveau au DNS du client. La plupart des ESP utilisent ce modèle. Les [meilleures pratiques M3AAWG pour les domaines d'envoi](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-domaines-d-envoi) décrivent aussi les trois modèles de délégation.

## Préparation

- **Faites l'inventaire** de tous les flux de messagerie (transactionnel, marketing, et courrier conversationnel ou d'employés), et identifiez qui gère chaque domaine et chaque flux. Chacun d'eux est partie prenante de la génération, de la publication et de l'utilisation des clés DKIM. Vérifiez les fusions et acquisitions pour trouver des flux que vous ne connaissez pas. **Une politique DMARC `p=none` avec des rapports agrégés (RUA) est un bon moyen de découvrir les flux** : les rapports quotidiens montrent quel courrier est envoyé, ou prétend être envoyé, avec des signatures DKIM valides ou absentes.
- **Discutez des objectifs avec toutes les parties.** Personne, y compris les fournisseurs tiers, ne devrait être pris au dépourvu au moment de la rotation.
- **Les parties prenantes** comprennent les administrateurs email internes, les administrateurs DNS et le personnel de support, ainsi que les contacts clients et techniques chez les fournisseurs tiers. Documentez la façon dont les modifications d'un flux sont demandées (un ticket, une demande officielle, une clause contractuelle, etc.).
- **Soyez prêt en cas d'incident**, c'est-à-dire pour une rotation d'urgence non planifiée à tout moment. Si vous **publiez à l'avance la prochaine clé publique dans le DNS**, une rotation d'urgence ne demande l'intervention que de l'administrateur de messagerie, soit le plus petit groupe de personnes possible.

## Audit

- Planifiez un audit peu après chaque rotation (par exemple une semaine plus tard) pour confirmer qu'elle a eu lieu et qu'elle a réussi.
- Tenez un registre des rotations. Pour chaque flux de messagerie, notez tous les domaines et sous-domaines, tous les sélecteurs avec les périodes où ils étaient actifs, et les personnes responsables.
- Auditez en comparant les valeurs `d=` et `s=` des signatures des messages échantillonnés avec les valeurs attendues dans le registre. Un schéma de nommage strict des sélecteurs, surtout s'il inclut des dates, simplifie les audits ponctuels et rend possible l'**audit automatisé**. Un sélecteur erroné révèle à la fois l'échec de la rotation et, avec un bon schéma de nommage, l'endroit où chercher.

## Références

Le BP cite : RFC 6376 (signatures DKIM), RFC 5585 (présentation du service), RFC 5863 (déploiement et exploitation), RFC 8301 (mise à jour sur les algorithmes et l'usage des clés), RFC 3766 et keylength.com (robustesse des clés), les *Best Practices for Implementing DKIM To Avoid Key Length Vulnerability* du M3AAWG (rév. juillet 2017), et l'article de Wired
<!-- glossary-allow: e-mail -->
« How a Google Headhunter's E-Mail Unraveled a Massive Net Security Hole » (24 octobre 2012).

# SPF (Sender Policy Framework)

> Référence RFC 7208 : syntaxe de l'enregistrement (mécanismes, qualificateurs, modificateurs, macros), algorithme d'évaluation check_host(), limites de requêtes DNS, codes de résultat et pièges courants.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/spf

SPF vous permet de publier, dans le DNS, les hôtes autorisés à envoyer des emails avec votre domaine. Les serveurs de réception comparent l'adresse IP du client qui se connecte à cette liste. SPF vérifie l'identité **RFC5321.MailFrom** (l'expéditeur d'enveloppe, « Envelope From », ou `Return-Path`) et, séparément, l'identité donnée dans **HELO ou EHLO**.

SPF est défini par la RFC 7208. Il authentifie le chemin suivi par le message, au moyen d'un enregistrement DNS TXT publié par le domaine. Pour savoir comment SPF alimente l'alignement DMARC, voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Identités vérifiées

- Les vérificateurs **DOIVENT** vérifier l'identité `MAIL FROM` si aucune vérification HELO n'a été effectuée ou si elle n'a pas abouti à un résultat définitif.
- Il est **RECOMMANDÉ** que les vérificateurs vérifient aussi, séparément, l'identité `HELO`. Lorsque `MAIL FROM` est vide (rebonds, `MAIL FROM:<>`), le domaine HELO sert de domaine MAIL FROM (`postmaster@<HELO domain>`).

## L'enregistrement

- L'enregistrement est publié sous forme d'enregistrement DNS **TXT** sur le domaine vérifié. Il **doit commencer exactement** par `v=spf1` (par exemple, `v=spf10` ne correspond pas et est ignoré). La RFC 7208 a rendu obsolète le type d'enregistrement DNS propre à SPF (type 99) : publiez donc uniquement du TXT.
- S'il n'existe **aucun** enregistrement `v=spf1`, le résultat est **none**. S'il en existe **plus d'un**, le résultat est **permerror**.
- Les termes sont évalués **de gauche à droite**, et le **premier mécanisme qui correspond** décide du résultat, selon son qualificateur. Si rien ne correspond et qu'aucun `redirect=` n'est présent, le résultat par défaut est **neutral** (un `?all` implicite).

## Qualificateurs

| Qualificateur | Résultat quand le mécanisme correspond |
|---|---|
| `+` (par défaut s'il est omis) | pass |
| `-` | fail |
| `~` | softfail |
| `?` | neutral |

## Mécanismes

| Mécanisme | Syntaxe | Signification | Requête DNS ? |
|---|---|---|---|
| `all` | `all` | Correspond toujours. Placé en dernière position comme valeur par défaut explicite (`-all`, `~all`, …). Tout ce qui suit `all` est ignoré. | Non |
| `include` | `include:<domain>` | Évalue récursivement l'enregistrement SPF de `<domain>`. Si le résultat récursif est **pass**, le mécanisme correspond. S'il est **fail**, **softfail** ou **neutral**, le mécanisme ne correspond pas et l'évaluation continue. **temperror** et **permerror** sont transmis vers le haut. Un **none** récursif donne **permerror**. | Oui |
| `a` | `a[:<domain>][/<cidr4>][//<cidr6>]` | Correspond si l'adresse IP du client est égale à un enregistrement A (IPv4) ou AAAA (IPv6) du domaine cible (par défaut, le domaine courant), éventuellement dans un préfixe CIDR. | Oui |
| `mx` | `mx[:<domain>][/<cidr4>][//<cidr6>]` | Recherche les enregistrements MX de la cible, puis les enregistrements d'adresse de chaque nom MX, et correspond si l'adresse IP du client en fait partie. | Oui |
| `ptr` | `ptr[:<domain>]` | Une vérification par DNS inverse validé. **« Ce mécanisme NE DEVRAIT PAS être publié »** : il est lent, peu fiable et obsolète dans la pratique. | Oui |
| `ip4` | `ip4:<network>[/<cidr>]` | L'adresse IP du client est comprise dans le réseau IPv4. Le préfixe par défaut est `/32`. | Non |
| `ip6` | `ip6:<network>[/<cidr>]` | L'adresse IP du client est comprise dans le réseau IPv6. Le préfixe par défaut est `/128`. | Non |
| `exists` | `exists:<domain-spec>` | Développe les macros du domaine et effectue une requête **A** (même pour les connexions IPv6). Correspond si au moins un enregistrement A est renvoyé. Cela permet une politique pour chaque adresse IP grâce aux macros. | Oui |

Longueurs de préfixe CIDR : `/0`–`/32` pour IPv4 (par défaut `/32`), et `/0`–`/128` pour IPv6 (par défaut `/128`). Seul le nombre indiqué de bits de poids fort est comparé.

## Modificateurs

Les modificateurs sont des paires associant un nom et une valeur (nom=valeur). Chacun peut apparaître au plus une fois, n'importe où dans l'enregistrement.

| Modificateur | Syntaxe | Signification |
|---|---|---|
| `redirect` | `redirect=<domain>` | Si **aucun mécanisme n'a correspondu**, l'évaluation se poursuit avec l'enregistrement SPF de `<domain>`, dont le résultat est repris tel quel. Si la cible de la redirection n'a pas d'enregistrement SPF, le résultat est **permerror** (et non none). Il compte dans la limite de 10 requêtes. Il est ignoré lorsque l'enregistrement contient aussi `all` (puisque `all` correspond toujours en premier). |
| `exp` | `exp=<domain>` | En cas de résultat **fail**, un enregistrement TXT est demandé pour ce domaine, ses macros sont développées, et il est renvoyé comme explication destinée à être lue par des personnes. Il ne compte pas dans la limite de 10 requêtes. |

## Macros

Les macros (`%{x}`) peuvent être développées dans les champs `domain-spec` et dans le texte de `exp` :

| Macro | Se développe en |
|---|---|
| `%{s}` | Expéditeur (l'adresse MAIL FROM complète) |
| `%{l}` | Partie locale de l'adresse de l'expéditeur |
| `%{o}` | Domaine de l'expéditeur |
| `%{d}` | Domaine en cours de vérification |
| `%{i}` | Adresse IP du client (notation décimale pointée pour IPv4 ; quartets séparés par des points pour IPv6) |
| `%{p}` | Domaine DNS inverse validé de l'adresse IP du client (NE DEVRAIT PAS être utilisé, pour les mêmes raisons que `ptr`) |
| `%{v}` | `in-addr` pour IPv4, `ip6` pour IPv6 |
| `%{h}` | Le domaine donné dans HELO ou EHLO |
| `%%` / `%_` / `%-` | `%` littéral / espace / espace encodée pour URL (`%20`) |

Transformateurs : un chiffre limite le nombre de libellés conservés, en comptant à partir de la droite (`%{d2}` conserve les deux derniers libellés), `r` inverse l'ordre des libellés, et d'autres caractères délimiteurs peuvent suivre.

## Codes de résultat

| Résultat | Signification (RFC 7208 §2.6) | Traitement recommandé par le serveur de réception (§8) |
|---|---|---|
| **none** | Aucun domaine valide n'a été extrait, ou aucun enregistrement SPF n'a été trouvé | Aucune information ; non concluant |
| **neutral** | Le domaine n'affirme explicitement rien au sujet de l'adresse IP (`?`) | **DOIT** être traité exactement comme `none` |
| **pass** | Le client est autorisé à envoyer des emails pour le domaine | Le domaine est responsable ; poursuivre |
| **fail** | Le client n'est explicitement **pas** autorisé (`-`) | Politique locale. En cas de rejet, utiliser SMTP **550** avec le code d'état étendu **5.7.1** |
| **softfail** | L'hôte n'est probablement pas autorisé (`~`), et le domaine est en transition | **NE DEVRAIT PAS** rejeter sur ce seul motif ; **PEUT** examiner de plus près |
| **temperror** | Une erreur temporaire (généralement DNS) pendant l'évaluation | Accepter ou reporter. En cas de report, utiliser SMTP **451** avec le code d'état **4.4.3** |
| **permerror** | L'enregistrement publié n'a pas pu être interprété correctement (l'opérateur DNS doit le corriger) | En cas de rejet, utiliser SMTP **550** avec le code d'état **5.5.2** |

Remarque pour DMARC : `fail`, `softfail`, `neutral`, `none` et les deux erreurs comptent tous comme « non pass ». Seul **pass** (avec alignement) peut satisfaire le volet SPF de DMARC.

## Limites de requêtes DNS (§4.6.4)

| Limite | Valeur | En cas de dépassement |
|---|---|---|
| Termes qui interrogent le DNS dans une évaluation (`include`, `a`, `mx`, `ptr`, `exists`, `redirect`) | **10 au total**, comptés sur toute la récursion à travers `include` et `redirect` | **permerror** |
| « Requêtes vides » (*void lookups* : NXDOMAIN ou réponse vide) | DEVRAIENT être limitées à **2** | **permerror** |
| Requêtes d'adresse pour chaque mécanisme `mx` | **10** noms MX | **permerror** |
| Requêtes d'adresse pour chaque évaluation `ptr` | **10** noms PTR | Les enregistrements au-delà des 10 premiers sont **ignorés** |

`all`, `ip4`, `ip6` et `exp` ne comptent **pas** dans la limite de 10 termes.

## Pièges courants

- **Plus de 10 requêtes.** Les chaînes d'`include` imbriquées des ESP, des CRM et des outils de gestion de tickets s'additionnent vite. Le résultat est permerror, que DMARC traite comme une absence totale de SPF. Aplatissez les includes ou retirez les prestataires que vous n'utilisez plus, et préférez `ip4` ou `ip6` (qui ne coûtent aucune requête) à `a` ou `mx` quand c'est possible.
- **Plusieurs enregistrements `v=spf1`** sur un même nom donnent permerror. Fusionnez-les en un seul enregistrement.
- **`+all` (ou une valeur par défaut absente ou permissive)** autorise l'Internet entier, ce qui est pire que de n'avoir aucun enregistrement. Terminez les enregistrements par `-all` ou `~all`.
- **Un `include` d'un domaine sans enregistrement SPF** donne permerror (un none récursif). Vérifiez les includes de vos prestataires lorsque vous cessez d'utiliser un service.
- **Le mécanisme `ptr` et la macro `%{p}`** sont obsolètes, lents et peu fiables. Ne les publiez pas.
- **Le transfert casse SPF.** L'adresse IP du service de transfert ne figure pas dans l'enregistrement du domaine d'origine, si bien que SPF échoue après tout saut qui conserve le MAIL FROM d'origine. C'est inhérent à l'authentification fondée sur le chemin. C'est pourquoi DKIM, qui authentifie le contenu, est préféré pour réussir DMARC après un transfert, et c'est la raison d'être d'[ARC](https://emailmarketing.net/fr/apprendre/authentification/arc).
- **Un pass SPF n'est pas un pass DMARC.** De nombreux ESP utilisent leur propre domaine de rebond dans le MAIL FROM : SPF réussit donc, mais n'est pas aligné avec le domaine From:. Pour l'alignement, utilisez comme Return-Path (adresse de rebond) un sous-domaine personnalisé du domaine From:. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).
- **Les chaînes TXT de plus de 255 caractères** doivent être découpées en plusieurs chaînes entre guillemets au sein de l'enregistrement unique (elles sont concaténées). Les gros enregistrements peuvent aussi imposer le DNS sur TCP.
- **Un `redirect=` placé après `all`** ne prend jamais effet, car `all` correspond en premier.

## Voir aussi

- [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim), qui authentifie plutôt le contenu
- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc), sur la façon dont les résultats SPF et l'alignement alimentent la politique
- [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc), sur la conservation des résultats d'authentification à travers les transferts

# Allemagne : l'article 7 de l'UWG et le marketing par email

> La voie allemande du consentement à l'email, par le droit de la concurrence déloyale : consentement exprès préalable de l'UWG §7(2) n° 2 en B2C comme en B2B, les quatre conditions cumulatives de l'exception du §7(3), la jurisprudence sur le double opt-in et l'action des concurrents par mise en demeure.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/allemagne-article-7-de-l-uwg-et-marketing-par-email

Si vous envoyez des emails marketing à des destinataires en Allemagne, il vous faut leur consentement exprès préalable, qu'il s'agisse de consommateurs ou d'entreprises, et vous devez pouvoir le prouver par un double opt-in documenté.

> **Ceci n'est pas un avis juridique.** Cette page résume la loi contre la concurrence déloyale (Gesetz gegen den unlauteren Wettbewerb, UWG), citée d'après la traduction anglaise officielle publiée sur gesetze-im-internet.de. Cette traduction n'est pas contraignante et intègre les modifications jusqu'à la loi du 6 mai 2024 ; c'est le texte allemand qui s'applique. Les citations ci-dessous sont traduites de cette version anglaise, dont le texte est donné entre parenthèses. La traduction a été récupérée par l'Internet Archive (une capture du 15 mai 2026), car le site officiel était inaccessible au moment de la rédaction de cette synthèse.

L'Allemagne met en œuvre l'[article 13 de la directive ePrivacy](https://emailmarketing.net/fr/apprendre/conformite/directive-eprivacy-et-rgpd-marketing-par-email) non pas principalement par le droit de la protection des données, mais par le **droit de la concurrence déloyale** : le §7 de l'UWG, qui sert à transposer l'article 13 de la directive 2002/58/CE. Deux conséquences font de l'Allemagne le grand marché de l'email le plus strict :

1. **Il n'existe aucune exception pour le B2B.** Le §7(2) n° 2 exige « le consentement exprès préalable du destinataire » (*"the addressee's prior express consent"*) pour la publicité par courrier électronique, et le destinataire peut être un consommateur **ou une entreprise**. Le Royaume-Uni, la France et les pays nordiques ont des règles d'opt-out pour les destinataires professionnels ; l'Allemagne n'en a pas, donc le marketing par email B2B exige le même opt-in exprès que le B2C.
2. **Les concurrents font appliquer les règles.** Les violations sont poursuivies non pas principalement par une autorité de protection des données, mais par les **concurrents et les associations**, au moyen du système des mises en demeure (*Abmahnung*). La procédure est rapide, lancée par des acteurs privés et génératrice d'honoraires, donc les poursuites sont courantes en pratique.

## Le §7 : la règle

**§7(1) :** « Une pratique commerciale qui constitue une nuisance inacceptable pour un participant au marché est illicite. Cela vaut en particulier pour la publicité dans les cas où il est manifeste que le participant au marché sollicité ne souhaite pas cette publicité. » (*"A commercial practice which constitutes an unacceptable nuisance to a market participant is illegal. This in particular applies to advertising in cases where it is apparent that the solicited market participant does not want this advertising."*)

**§7(2) :** une nuisance inacceptable est **toujours présumée** pour :

- **n° 1** : la publicité par téléphone auprès d'un consommateur sans son consentement exprès préalable (ou auprès d'un autre participant au marché sans au moins son consentement présumé) ;
- **n° 2** : « la publicité au moyen d'un automate d'appel, d'un télécopieur **ou du courrier électronique sans le consentement exprès préalable du destinataire** » (*"advertising using an automated calling machine, a fax machine or electronic mail without the addressee's prior express consent"*) ;
- **n° 3** : les messages publicitaires (a) dans lesquels l'identité de l'expéditeur est dissimulée ou tenue secrète, (b) qui enfreignent l'article 6, paragraphe 1, du règlement sur les services numériques (Digital Services Act) ou qui mènent le destinataire vers un site web qui l'enfreint, ou (c) qui n'ont **aucune adresse valide** à laquelle le destinataire peut envoyer une demande d'arrêt, gratuitement hors coûts de transmission de base.

Les tribunaux allemands interprètent largement la notion de « publicité » : toute communication destinée à promouvoir des ventes, y compris les newsletters, les enquêtes de satisfaction utilisées à des fins promotionnelles et les emails qui cherchent à reconquérir des clients inactifs.

## §7(3) : l'exception (soft opt-in allemand), quatre conditions cumulatives

Par dérogation au §7(2) n° 2, la publicité par email n'est pas une nuisance inacceptable **que si les quatre** conditions suivantes sont toutes réunies :

1. « l'entrepreneur a obtenu du client l'adresse de courrier électronique de celui-ci **dans le cadre de la vente de biens ou de services** ;
2. l'entrepreneur utilise l'adresse pour la publicité directe de **ses propres biens ou services similaires** ;
3. le client **ne s'est pas opposé** à cette utilisation ; et
4. le client est **informé clairement et sans équivoque, lors de la collecte de l'adresse et à chaque utilisation**, qu'il peut s'opposer à tout moment à cette utilisation sans que cela entraîne d'autres frais que les coûts de transmission selon les tarifs de base. »

(Texte anglais : *"the entrepreneur has obtained from the customer the latter's electronic mail address in connection with the sale of goods or services; the entrepreneur uses the address for direct advertising of his or her own similar goods or services; the customer has not objected to this use; and the customer is clearly and unequivocally advised, when the address is collected and each time it is used, that he or she can object to such use at any time, without costs arising by virtue thereof, other than transmission costs in accordance with the basic rates."*)

En pratique, les tribunaux allemands exigent une véritable **vente**. Fieldfisher indique « transaction requise » : une simple demande de renseignements ne suffit pas, contrairement à la lecture britannique des « négociations ». La notion de « similaire » est interprétée de façon étroite. La condition 4 n'est pas remplie si l'information sur le droit d'opposition manquait lors de la collecte de l'adresse, et cela ne peut pas être corrigé après coup. Comme l'expéditeur doit prouver les quatre conditions, **le recours au §7(3) est rare dans la pratique allemande, et le conseil standard est un consentement par double opt-in documenté** (Fieldfisher, janvier 2024).

## La jurisprudence sur le double opt-in

La loi parle de « consentement exprès préalable », et la jurisprudence fait du **double opt-in documenté** la norme de preuve de fait :

- **BGH, arrêt du 10 février 2011, I ZR 164/09** (*Double-opt-in-Verfahren*). L'expéditeur supporte **l'entière charge de la preuve** de la déclaration de consentement concrète. Une simple inscription par formulaire web (simple opt-in) ne suffit pas, car « un usage abusif par des personnes non autorisées ne peut être exclu » (*"misuse by unauthorised persons cannot be ruled out"*) : n'importe qui peut saisir l'adresse d'autrui. Un consentement donné par voie électronique doit être conservé et pouvoir être imprimé à tout moment. Le double opt-in confirmé (une inscription suivie d'un clic sur un lien dans un email de confirmation) est le moyen reconnu de montrer que le titulaire de l'adresse a consenti personnellement.
- **OLG München, arrêt du 27 septembre 2012, 29 U 1682/12.** **L'email de confirmation lui-même constitue une publicité** si l'expéditeur ne peut pas prouver que le titulaire de l'adresse l'a demandé. Un message « vérifiez votre boîte de réception » envoyé à une adresse qui ne s'est jamais inscrite est donc déjà une violation du §7(2) n° 2. En pratique, gardez l'email de confirmation **strictement neutre** (aucune offre, aucune promotion, un habillage de marque minimal), n'en envoyez qu'un seul, et journalisez le contexte de l'inscription (horodatage, adresse IP, formulaire) afin de pouvoir prouver la demande elle-même. Depuis, les tribunaux ont généralement admis les confirmations de double opt-in neutres ; une confirmation promotionnelle perd cette protection.
- Le consentement doit aussi respecter la **norme du RGPD** ([article 4, point 11, et article 7 : granulaire, éclairé, révocable et sans case précochée](https://emailmarketing.net/fr/apprendre/conformite/directive-eprivacy-et-rgpd-marketing-par-email)). Les autorités allemandes de protection des données et les tribunaux appliquent les deux ensembles de règles côte à côte, et un consentement non valable au regard du RGPD ne peut pas être valable au regard de l'UWG.

Pour la publicité par téléphone, le §7a exige en outre de documenter le consentement d'un consommateur « sous une forme appropriée » (*"in an adequate form"*) et de **conserver la preuve pendant cinq ans** à compter de l'octroi du consentement et après chaque utilisation, afin de pouvoir la produire à l'Agence fédérale des réseaux (Bundesnetzagentur) sur demande. Aucune règle légale équivalente de conservation n'existe pour le consentement à l'email. Cependant, comme le BGH fait peser la charge de la preuve sur l'expéditeur, la norme pratique est de conserver les preuves de consentement sans limite de durée (jusqu'à la fin de la relation et à l'expiration des délais de prescription).

## Application

- **Qui peut agir (§8(3)).** Les actions en cessation et en abstention appartiennent (1) à **tout concurrent** ayant une présence réelle sur le marché, (2) aux **associations professionnelles qualifiées** inscrites sur la liste du §8b (par exemple la Wettbewerbszentrale), (3) aux **associations de consommateurs qualifiées** inscrites sur la liste prévue par la loi sur les actions en cessation (Unterlassungsklagengesetz), et (4) aux chambres de commerce et d'industrie et aux chambres des métiers. Le destinataire peut aussi agir personnellement sur le fondement du droit civil général (cessation ou dommages-intérêts, par application analogique des §§823, 1004 du BGB). Les entreprises dont les salariés reçoivent du spam agissent en tant que participants au marché.
- **Fonctionnement d'une Abmahnung.** Le demandeur envoie une mise en demeure formelle qui exige une **déclaration d'abstention assortie d'une pénalité contractuelle** (généralement plusieurs milliers d'euros par violation future), et le remboursement des frais d'avocat. Si l'expéditeur refuse, une **ordonnance de référé** suit rapidement. Un seul email non sollicité démontrable suffit à lancer ce mécanisme, ce qui explique qu'une seule campagne envoyée aux mauvaises personnes en Allemagne produise des courriers d'avocats comme nulle part ailleurs. Le §8c limite les séries abusives de mises en demeure (lorsque la génération d'honoraires est l'objectif principal, que les valeurs sont gonflées ou que les pénalités sont excessives), en réaction à ce qu'on appelle l'*Abmahnindustrie*, mais les demandes légitimes restent courantes.
- **Le risque de récidive** est présumé après une seule violation. Seule la déclaration assortie d'une pénalité, ou un jugement définitif, le fait disparaître.
- **Amendes.** Les amendes administratives du §20 (jusqu'à **300 000 €**) visent la publicité **par téléphone et par appel automatisé** sans consentement, et les manquements à l'obligation de documentation du §7a (jusqu'à 50 000 €). Elles ne **visent pas l'email**, qui est poursuivi par des actions civiles comme décrit ci-dessus. Les violations du consentement à l'email peuvent aussi entraîner des **amendes RGPD** infligées par les autorités de protection des données (jusqu'à 20 M€ ou 4 % pour les manquements relatifs à la base du consentement), car envoyer ces messages revient à traiter des données personnelles sans base légale.

## Lien avec la délivrabilité

La rigueur juridique de l'Allemagne et la rigueur de ses boîtes de réception forment un seul écosystème. Les principaux fournisseurs de messagerie allemands ([GMX, WEB.DE et mail.com, qui appartiennent à United Internet](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/gmx-web-de-exigences-postmaster)) soutiennent le programme de liste blanche de la **Certified Senders Alliance (CSA)**. Ses critères d'admission reflètent la norme juridique : un consentement documenté, l'attente d'un double opt-in, un désabonnement fonctionnel et la transparence de l'expéditeur exigée par le §7(2) n° 3.

Conseiller à un expéditeur d'écrire vers l'Allemagne sans double opt-in documenté est donc une erreur à double titre. Juridiquement, l'expéditeur ne peut pas satisfaire à la charge de la preuve et s'expose à une Abmahnung. Opérationnellement, il ne répond pas aux attentes de filtrage de la CSA et d'United Internet. Pour les listes qui mêlent plusieurs pays de l'UE, la base sûre est la norme allemande (voir le [tableau des divergences entre États membres](https://emailmarketing.net/fr/apprendre/conformite/directive-eprivacy-et-rgpd-marketing-par-email)).

# Application des lois sur l'email : affaires LCAP et détail légal de CAN-SPAM

> Synthèse de l'application de la LCAP par le CRTC (sanctions, engagements, bulletin sur la responsabilité des intermédiaires au titre de l'article 9, lignes directrices sur les programmes de conformité et statistiques du programme) et du texte même de CAN-SPAM (interdictions du 15 U.S.C. 7704, violations aggravées dont la collecte d'adresses, et responsabilité de l'entreprise promue au titre du 7705), avec l'enseignement de chaque élément pour un ESP.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/application-des-lois-sur-l-email-lcap-et-can-spam

Pour évaluer votre exposition réelle au titre de la Loi canadienne anti-pourriel (LCAP) ou du CAN-SPAM Act américain, vous devez savoir comment les règles sont appliquées, et pas seulement ce qu'elles disent. [LCAP](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel) et [CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis) exposent les règles elles-mêmes.

Cette page décrit ce qui se passe lorsqu'elles sont appliquées : les outils du Conseil de la radiodiffusion et des télécommunications canadiennes (CRTC), les affaires tranchées avec les noms et les montants, et les lignes directrices du CRTC sur la responsabilité des intermédiaires comme les ESP. Elle couvre aussi le texte légal des interdictions de CAN-SPAM, qui va plus loin que le guide de la Federal Trade Commission (FTC) destiné aux entreprises.

## Application de la LCAP : qui fait quoi

Trois organismes se partagent la responsabilité de la LCAP (selon le rapport de mesure du rendement 2024-25 d'ISDE) :

- Le **CRTC** fait appliquer les articles 6 à 9 (pourriel, modification des données de transmission, logiciels malveillants, aide) dans le cadre d'un régime administratif civil assorti de sanctions administratives pécuniaires (SAP), et exploite le **Centre de notification des pourriels**.
- Le **Bureau de la concurrence** poursuit les indications électroniques fausses ou trompeuses (sur l'expéditeur, l'objet, le message ou un localisateur comme une URL) au titre de la Loi sur la concurrence.
- Le **Commissariat à la protection de la vie privée (CPVP)** traite la collecte d'adresses et la collecte illicite au titre de la LPRPDE. Il n'a pas le pouvoir d'infliger des SAP, et s'appuie sur des engagements volontaires ou sur des ordonnances de la Cour fédérale.

L'organe national de coordination d'Innovation, Sciences et Développement économique Canada (ISDE) pilote la politique, et fightspam.gc.ca est le site de sensibilisation. Le CRTC a conclu des protocoles d'entente avec la FTC, la FCC, l'ICO, l'ACMA (Australie), le MIC japonais et le DIA néo-zélandais, et travaille avec le FBI, la GRC et l'AFP.

### Les instruments d'application du CRTC

| Instrument | Nature | Mécanique clé |
|---|---|---|
| **Procès-verbal de violation** | Un constat formel, par le personnel chargé de l'enquête, de violations des articles 6 à 9, assorti d'une SAP proportionnée à la gravité et au nombre de violations | 30 jours pour payer, ou pour présenter des observations écrites en vue d'un examen par le CRTC. Sans réponse, la violation est réputée commise. Le paiement est suspendu pendant l'examen. La décision est rendue selon la prépondérance des probabilités, et publiée |
| **Engagement** | Un règlement volontaire, négocié | Comporte généralement la reconnaissance des faits, un paiement et un programme de conformité. Il met fin à l'affaire et annule tout procès-verbal portant sur ces violations. Un refus entraîne généralement un procès-verbal. Un résumé est publié |
| **Lettre d'avertissement ou citation** | Une solution de rechange pour les violations moins graves | Aucune obligation formelle de réponse, et pas de publication. L'absence de mesures correctives expose à une escalade |
| **Avis de communication** | Une demande de documents utiles à une enquête | 30 jours pour répondre. Suspendu pendant que le CRTC examine une objection (demande déraisonnable, ou portant sur des documents protégés) |
| **Demande de préservation** | Un ordre, généralement adressé aux fournisseurs de télécommunications ou d'accès à Internet, de préserver des données de transmission | Jusqu'à 21 jours, avec une prolongation de 21 jours. Les fournisseurs de services de télécommunication (FST) disposent de 5 jours ouvrés pour demander un examen, mais doivent préserver les données entre-temps |

Conseils pratiques tirés des propres lignes directrices du CRTC : mettez tous vos arguments dans vos premières observations écrites, car l'examen n'admet normalement aucune observation ultérieure, et prenez les lettres d'avertissement au sérieux, car elles sont la sortie la moins coûteuse.

### Bulletin 2014-326 : programmes de conformité d'entreprise (la défense de diligence raisonnable)

Le Bulletin d'information sur la conformité et l'application de la loi CRTC 2014-326 (19 juin 2014) indique aux entreprises comment bâtir un programme capable de fonder une **défense de diligence raisonnable**, et de convaincre le Conseil qu'une violation était isolée plutôt que systémique.

Les éléments requis sont :

- l'engagement de la haute direction (un responsable de la conformité ou une personne-ressource désignée) ;
- une évaluation des activités exposées à un risque de violation ;
- une **politique écrite** couvrant les procédures, la formation (avec des attestations écrites des employés et des formations de rappel), la vérification et la surveillance, la conformité des tiers, la tenue de registres et la rétroaction des employés ;
- la tenue de registres propre à la LCAP, notamment **des demandes de désabonnement et des mesures prises, des preuves de consentement, des journaux de consentement des destinataires et des scripts des messages** ;
- des vérifications régulières, avec un suivi documenté ;
- un système de traitement des plaintes, avec des délais de résolution définis ;
- un code disciplinaire, avec des mesures correctives documentées.

Un programme mis en place au préalable ne constitue pas une défense complète, mais il montre que des précautions raisonnables ont été prises. Un ESP bien géré devrait pouvoir produire cette liste de contrôle pour lui-même, et l'exiger de ses clients.

### Bulletin 2018-415 : responsabilité des intermédiaires au titre de l'article 9 (le bulletin des ESP)

Le Bulletin d'information sur la conformité et l'application de la loi CRTC 2018-415 (5 novembre 2018) interprète l'**article 9**, selon lequel constitue une violation le fait d'aider, d'inciter ou d'amener une personne à commettre une violation des articles 6 à 8, ou d'obtenir qu'elle la commette. Les catégories exposées que nomme le CRTC sont **les courtiers en publicité, les spécialistes du marketing électronique, les développeurs et distributeurs de logiciels et d'applications, les fournisseurs de services de télécommunication et d'accès à Internet, et les processeurs de paiement**. C'est toute la chaîne de livraison, et les ESP en font clairement partie.

Les facteurs d'appréciation sont : (1) le **niveau de contrôle**, c'est-à-dire la capacité d'empêcher ou de faire cesser l'activité ; (2) le **degré de lien** entre les actes qui ont aidé et la violation sous-jacente ; et (3) les **mesures raisonnables**, c'est-à-dire les précautions et les garanties effectivement mises en place.

Le premier exemple du bulletin concerne directement les ESP. Une entreprise de marketing qui fournit des modèles d'email **dépourvus d'identification de l'expéditeur et de mécanisme de désabonnement**, ainsi que des listes de contacts **sans vérification du consentement**, aide son client à commettre une violation de l'art. 6 en « fournissant les outils ». D'autres exemples sont un hébergeur web qui ignore une campagne de phishing signalée, et une boutique d'applications qui distribue un logiciel aux fonctions dissimulées derrière une case de consentement précochée.

La diligence raisonnable attendue comprend :

- des évaluations régulières des menaces et des risques ;
- la **validation de l'identité des clients** (documents constitutifs, pièce d'identité délivrée par une autorité publique, documents fiscaux) ;
- le signalement des incohérences de localisation, et des clients qui recherchent l'anonymat (pseudonymes, boîtes postales, paiement en cryptomonnaie) ;
- des recherches sur la réputation du client et sur la légalité de ses produits ;
- des **contrats écrits qui obligent les clients à respecter la LCAP** ;
- la vérification de l'usage que les clients existants font du service ;
- la surveillance et le signalement des violations présumées ;
- des ressources pour un retrait et une correction rapides ;
- la documentation de l'ensemble.

Le bulletin avertit que « le simple respect des normes de l'industrie peut être insuffisant » (*"simply following industry standards may be insufficient"*). Des politiques figées, sans surveillance active, ne satisfont pas à l'obligation de l'art. 9.

### Synthèse des affaires LCAP

Les mesures formelles du CRTC ci-dessous proviennent de la liste des mesures d'application du CRTC consultée en juillet 2026, complétée par le rapport d'application de la LCAP du CRTC d'octobre 2020 à mars 2021. La liste publique est répartie sur plusieurs pages, donc les affaires plus anciennes qui lui sont antérieures, comme les engagements de 2015 à 2018, ne sont pas reprises ici.

**Procès-verbaux de violation (SAP)**

| Date | Partie | SAP | Violation | Enseignement pour un ESP |
|---|---|---|---|---|
| 2025-08-13 | Jimmy Genesse | 50 000 $ | art. 7(1)(a) (modification des données de transmission) | Rediriger ou modifier les données de routage est un type de violation à part, distinct du consentement |
| 2023-07-11 | Sami Medouni | 40 000 $ | art. 6 (MEC sans consentement) | Des particuliers, et pas seulement des entreprises, sont nommés et sanctionnés personnellement |
| 2022-01-17 | Marc-Anthony Younes | 50 000 $ | art. 6(1)(a) (absence de consentement) | Idem |
| 2021-03 | Scott William Brewer | 75 000 $ | art. 6 : plus de 670 000 emails de marketing d'affiliation envoyés selon une technique de « hailstorm » (des rafales envoyées rapidement pour échapper à la détection anti-spam) | L'envoi en rafales pour devancer le filtrage est traité comme une tactique aggravante. La liste des mesures mentionne aussi un engagement de Brewer daté du 2022-01-04 (7 500 $ et un programme de conformité) |
| 2019-12-12 | John Paul Revesz et Vincent Leo Griebel / Orcus Technologies | 115 000 $ | art. 9 (aide) | L'article 9 est appliqué, avec de vraies sanctions pécuniaires, contre ceux qui fournissent les moyens d'une violation |
| 2019-04-23 | Brian Conley | 100 000 $ | art. 6(1) et 6(2) | Les exigences de consentement et celles de contenu et d'identification ont été appliquées ensemble |

**Engagements (règlements négociés)**

| Date | Partie | Paiement | Remarques et enseignement pour un ESP |
|---|---|---|---|
| 2024-06-10 | Compagnie de la Baie d'Hudson | 120 000 $ | Un grand détaillant grand public, avec un programme de conformité. L'application de la LCAP ne vise pas seulement les spammeurs : les programmes marketing des marques connues concluent aussi des règlements |
| 2023-02-10 | NortonLifeLock Inc. | Aucun (programme de conformité) | Un engagement à mettre en place un programme peut à lui seul être le prix du règlement |
| 2021-12-06 | Gap Inc. | 200 000 $ | Avec un programme de conformité. Les marques dont le siège est à l'étranger et qui écrivent à des Canadiens peuvent être visées |
| 2020-09-21 | Notesolution Inc. / OneClass | 100 000 $ | Avec un programme de conformité |
| 2022-08-24 | Christos Tyrone Dracos | 40 000 $ | Un particulier, avec des conditions |
| 2022-05-10 | Souhail Amaarak / Moustapha Sabir | 10 000 $ / 17 000 $ | Des particuliers visés par la même enquête, chacun responsable séparément |
| 2022-01-04 | Scott William Brewer | 7 500 $ | Avec un programme de conformité (voir le procès-verbal ci-dessus) |

**Confirmation par les tribunaux.** Selon le rapport d'application 2020-21 du CRTC, en mars 2021, la Cour suprême du Canada a refusé d'entendre l'appel de **CompuFinder**. Cela a laissé en vigueur l'arrêt de la Cour d'appel fédérale qui a confirmé **la constitutionnalité de la LCAP** et précisé les dispositions sur le consentement fondé sur une relation d'affaires en cours et sur la publication bien en vue. Le rapport citait aussi CompuFinder comme exemple de violation liée à un mécanisme de désabonnement qui ne fonctionnait pas. Contester la LCAP pour des motifs constitutionnels ne mène nulle part, et les catégories de consentement implicite de la [LCAP](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel) s'interprètent telles qu'elles sont rédigées.

### Statistiques du programme : ce que fait réellement l'autorité

**Rapport d'application de la LCAP du CRTC, du 1er octobre 2020 au 31 mars 2021 (six mois).** Le CRTC a émis 143 avis de communication, 17 demandes de préservation, 10 lettres d'avertissement et 1 procès-verbal de violation, pour 75 000 $ de sanctions. Le total cumulé depuis 2014 dépassait alors **1,4 M $ à payer** (805 k $ de SAP et 668 k $ d'engagements).

Le Centre de notification des pourriels a reçu plus de 144 560 plaintes (environ 5 560 par semaine). Seulement 3 % sont arrivées par le formulaire web, et le reste a été envoyé à spam@fightspam.gc.ca. **93 % des plaintes invoquaient une absence de consentement**, 34 % des problèmes d'identification, 30 % du marketing trompeur et 3 % des logiciels ou des logiciels malveillants. **76 % des emails visés par les plaintes relevaient du marketing d'affiliation ou d'emails d'entreprises légitimes**, et non du spam criminel.

Les principales catégories d'affiliation étaient l'alimentation, les médicaments et la santé ; les enquêtes et les tirages au sort ; les casinos ; les achats en ligne ; et la technologie. Les principales catégories commerciales étaient les services marketing, la technologie, les achats en ligne, les mises à jour et notifications, et les newsletters. En novembre 2020, le CRTC, le CPVP et le Bureau de la concurrence ont adressé un avertissement conjoint à 36 entreprises d'applications mobiles sur la conformité de leurs applications à la LCAP (aucune fausse déclaration, aucun enregistrement des frappes sans consentement, aucune fonction dissimulée, aucun envoi de spam aux contacts des utilisateurs).

**Rapport de mesure du rendement de la LCAP d'ISDE 2024-25.** Le Centre de notification des pourriels a reçu 414 630 plaintes, dont seulement environ 2,1 % par le formulaire en ligne. Les totaux annuels du CRTC étaient de **260 avis de communication, 33 lettres d'avertissement, 14 demandes de préservation, 2 engagements et plus de 137 000 $ de SAP**. Les SAP cumulées du CRTC depuis 2014 dépassaient **3,6 millions $**.

En **novembre 2024, le CRTC a analysé environ 25 entreprises présentant des volumes de plaintes nettement élevés**, vérifié leurs pratiques de consentement et de désabonnement, et envoyé des lettres d'avertissement lorsque des violations potentielles apparaissaient. Autrement dit, le volume de plaintes au Centre de notification des pourriels sélectionne directement les cibles des mesures d'application. C'est le pendant réglementaire de la boucle entre taux de plaintes et réputation décrite dans [Fondamentaux](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email).

<!-- glossary-allow: courriel -->
Les mesures du Bureau de la concurrence liées à la LCAP cette année-là comprenaient un règlement avec **SiriusXM Canada** au sujet d'offres d'abonnement à prix partiel, promues « sur son site Web, ainsi que dans des courriels promotionnels et du publipostage » (*"on its website, as well as in promotional emails and direct mail"*) ; une procédure devant le Tribunal de la concurrence contre **Rogers Communications** au sujet d'allégations de données « illimitées » ; et une deuxième ordonnance judiciaire dans une enquête en cours sur le marketing trompeur d'**Amazon**. Le CPVP a reçu 14 plaintes liées à la LCAP (MEC non sollicités, absence d'option de désabonnement, désabonnements non respectés). Il a indiqué que plus de 90 % des attaques de phishing commencent par un email, et cité des constats de l'OCDE selon lesquels plus de la moitié des emails de spam et malveillants sont désormais générés par l'IA.

**Enseignements globaux pour un ESP tirés du bilan de la LCAP :** (1) la plupart des mesures d'application partent de plaintes de destinataires visant des lacunes de consentement chez des marketeurs légitimes, et non chez des criminels ; (2) les particuliers et les dirigeants sont nommés personnellement ; (3) un désabonnement qui ne fonctionne pas, ou qui n'est pas respecté, est une violation récurrente et facile à prouver ; (4) l'exposition propre d'un ESP relève de l'art. 9, et sa seule défense est une vérification documentée des clients et une surveillance active ; (5) un programme de conformité documenté est à la fois la monnaie des règlements et le fondement de la défense de diligence raisonnable.

## Détail légal de CAN-SPAM : 15 U.S.C. § 7704 et § 7705

Le [guide de conformité de la FTC](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis) paraphrase la loi. Le texte légal ajoute une structure qui compte lorsque vous répartissez les responsabilités dans une chaîne annonceur, ESP et fournisseur de listes.

### § 7704(a) : les interdictions principales

- **(a)(1) Informations d'en-tête substantiellement fausses ou trompeuses.** Cette interdiction s'applique aux emails commerciaux **et** aux emails transactionnels ou relationnels. Trois règles déterminent ce qui compte. Des en-têtes techniquement exacts sont tout de même trompeurs si l'adresse, le domaine ou l'adresse IP d'origine a été **obtenu par des manœuvres fausses ou frauduleuses**. Un champ « from » qui identifie correctement l'un quelconque des initiateurs réels est conforme. Les en-têtes sont substantiellement trompeurs lorsqu'ils n'identifient pas la machine qui a injecté le message parce que l'expéditeur **l'a sciemment relayé par un autre ordinateur protégé pour en dissimuler l'origine**. « Substantiellement » (défini au (a)(6)) désigne une modification ou une dissimulation qui empêcherait un service de réception, les autorités répressives ou le destinataire d'**identifier ou de localiser l'initiateur, ou de lui répondre**, ou d'enquêter.
- **(a)(2) Objets trompeurs.** Ils sont illicites lorsque l'expéditeur sait effectivement, ou lorsque des circonstances objectives permettent raisonnablement de déduire qu'il sait, que l'objet induirait probablement en erreur un destinataire raisonnable sur un **fait substantiel relatif au contenu ou au sujet** du message.
- **(a)(3) Une adresse de retour ou un opt-out par Internet fonctionnel**, affiché de manière claire et visible, et capable de recevoir les demandes d'opt-out pendant **au moins 30 jours après la transmission**. Un menu de préférences n'est autorisé que s'il comporte une option permettant de refuser **tous** les messages commerciaux de l'expéditeur. Une interruption temporaire indépendante de la volonté de l'expéditeur est excusée si elle est corrigée dans un délai raisonnable.
- **(a)(4) Interdictions après un opt-out.** Passé **10 jours ouvrés**, il est illicite pour l'expéditeur d'envoyer des messages qui entrent dans le champ de la demande ; pour toute personne agissant pour le compte de l'expéditeur, de le faire en ayant une connaissance effective ou raisonnablement déductible de la demande ; pour quiconque, d'**aider en fournissant ou en sélectionnant des adresses** en sachant que la transmission serait illicite ; et pour **toute personne ayant connaissance de la demande, de vendre, louer, échanger ou autrement transférer ou divulguer l'adresse** (sauf à un prestataire chargé de la conformité). Seul un consentement exprès ultérieur du destinataire permet de reprendre les envois. La clause sur la fourniture d'adresses est celle qui atteint directement les courtiers en listes et les équipes data des ESP.
- **(a)(5) Contenu obligatoire.** Une identification claire et visible du message comme publicité (écartée seulement si le destinataire a donné au préalable son consentement exprès), une mention claire et visible de l'opt-out, et une adresse postale valide de l'expéditeur.

### § 7704(b) : violations aggravées

Elles s'ajoutent aux violations du (a) et entraînent des sanctions plus lourdes :

1. **Collecte d'adresses** : envoyer des messages illicites (ou aider à le faire en fournissant ou en sélectionnant des adresses) à des adresses **obtenues par des moyens automatisés sur un site web ou un service en ligne dont l'exploitant a publié un avis indiquant qu'il ne communique, ne vend ni ne transfère d'adresses** à des fins d'envoi. Également, les **attaques par dictionnaire** : des adresses générées en combinant automatiquement des noms, des lettres ou des chiffres. La connaissance exigée est effective ou raisonnablement déductible. (La disposition précise expressément qu'elle ne crée aucun droit de propriété sur les adresses email.)
2. **Création automatisée de comptes** : utiliser des scripts ou d'autres moyens automatisés pour enregistrer plusieurs comptes email ou comptes utilisateur afin d'envoyer des emails commerciaux illicites, ou permettre à d'autres de le faire.
3. **Relais non autorisé** : relayer ou retransmettre sciemment un message contraire au (a) à partir d'un ordinateur ou d'un réseau protégé **auquel on a accédé sans autorisation**.

Au titre du (c), la FTC dispose d'un pouvoir réglementaire pour raccourcir ou allonger le délai de 10 jours ouvrés, et pour désigner d'autres pratiques aggravantes. Le paragraphe (d) est le régime des avertissements pour le matériel à caractère sexuel : des mentions dans la ligne d'objet, ou un « emballage » qui ne montre que les mentions, les informations obligatoires du (a)(5) et des instructions d'accès. Il est écarté par un consentement exprès préalable, et les violations commises sciemment sont passibles d'amendes et d'une peine allant jusqu'à **5 ans d'emprisonnement**.

### § 7705 : responsabilité de l'entreprise promue

Cette section écarte l'argument « nous les avons simplement engagés ». Au titre du (a), il est illicite pour une personne de promouvoir son commerce ou son entreprise, ou de laisser le promouvoir, dans un message commercial **dont la transmission enfreint le § 7704(a)(1)** (en-têtes faux ou trompeurs) si cette personne : (1) **savait, ou aurait dû savoir dans le cours normal de ses affaires**, que ses biens ou services étaient promus dans un tel message ; (2) **a reçu ou s'attendait à recevoir un avantage économique** de cette promotion ; et (3) **n'a pris aucune mesure raisonnable (A) pour empêcher la transmission, ou (B) pour la détecter et la signaler à la Commission**.

Au titre du (b), un tiers dont les biens apparaissent dans la promotion d'autrui n'est en général pas responsable, sauf s'il **possède ou détient plus de 50 %** du commerce ou de l'entreprise en infraction, ou s'il a une **connaissance effective** de la promotion illicite **et** en reçoit ou en attend un avantage économique. Au titre du (c), les §§ 7706(f) et (g) ne s'appliquent pas à cette section. Les procureurs généraux des États ne peuvent pas agir, et les fournisseurs d'accès à Internet ne peuvent pas intenter d'action privée, au titre du § 7705. Seule la FTC (avec les autorités de régulation fédérales) le fait appliquer.

**Enseignements pour un ESP tirés de la loi :** (1) l'obligation de véracité des en-têtes s'applique même aux emails transactionnels, donc des chaînes HELO, From et Return-Path exactes sont une exigence légale, et pas seulement une bonne pratique d'authentification (voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) et [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim)) ; (2) le délai de 30 jours pendant lequel l'opt-out doit fonctionner, et le délai de 10 jours ouvrés pour le respecter, sont des minimums légaux que l'infrastructure de suppression d'un ESP doit battre (comparez avec le couple de délais de 60 jours et de 10 jours ouvrés de la [LCAP](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel)) ; (3) accepter ou fournir une **liste collectée, ou générée en combinant des noms**, transforme des violations ordinaires en violations aggravées, et « aider en fournissant ou en sélectionnant des adresses » est un fondement de responsabilité distinct pour l'ESP lui-même, ce qui donne une base légale au refus des listes achetées (voir [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement) et [Adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges)) ; (4) les annonceurs ne peuvent pas externaliser leur responsabilité, donc la pratique de conformité d'un ESP fait partie de ce sur quoi ses clients s'appuient juridiquement, ce qui fait écho, dans l'autre sens, à l'art. 9 de la LCAP.

Ces synthèses sont tirées des publications des autorités et du texte légal cités, et ne constituent pas un avis juridique. Les montants des sanctions et les listes d'affaires évoluent, donc consultez la page des mesures d'application du CRTC et l'U.S. Code pour connaître la situation actuelle.

# Australie : le Spam Act 2003 et son application par l'ACMA

> Le régime d'opt-in australien : consentement exprès ou déduit, règles d'identification de l'expéditeur et de désabonnement (5 jours ouvrés, 30 jours, sans connexion), sanctions de l'ACMA dont le record de 3,55 M AU$ infligé à la Commonwealth Bank, ainsi que l'APP 7 de l'OAIC et ses lignes directrices sur les pixels de suivi.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/australie-spam-act-2003-et-application-par-l-acma

Si vous envoyez des emails marketing à des personnes en Australie, vous avez besoin de leur consentement, vous devez vous identifier, et votre désabonnement doit fonctionner sans connexion. L'Australie est une juridiction d'**opt-in**, et son autorité de contrôle est l'une des plus actives au monde en matière de sanctions.

Le **Spam Act 2003** (Cth) et les Spam Regulations régissent les **messages électroniques commerciaux** (email, SMS, MMS, messages instantanés). L'**Australian Communications and Media Authority (ACMA)** en assure le respect, et inflige régulièrement des avis d'infraction à sept chiffres à des marques grand public. Le motif le plus fréquent est une **défaillance du désabonnement**, notamment l'obligation de se connecter pour se désabonner, ce qui contraint directement la conception des parcours de désabonnement d'un fournisseur de services de messagerie (ESP).

> Sources : le texte de la loi cité ci-dessous provient de la compilation consolidée C2012C00030, récupérée par l'Internet Archive, car legislation.gov.au sert la compilation actuelle au moyen d'une application JavaScript. Les pages de l'ACMA ont également été récupérées par l'Internet Archive (captures de 2026), car acma.gov.au bloque les clients autres que les navigateurs.

## Champ d'application

- Un message est **commercial** s'il propose des biens ou des services (ou des terrains, ou des occasions d'affaires ou d'investissement), en fait la publicité ou la promotion, même si seule une **partie** du message est commerciale (fiche d'information de l'ACMA). Les messages purement **factuels** sont exemptés (annexe 1, voir ci-dessous).
- La loi s'applique aux messages qui présentent un **lien avec l'Australie** (s 7) : les messages envoyés depuis l'Australie, envoyés vers l'Australie ou consultés en Australie. Les expéditeurs étrangers qui écrivent à des destinataires australiens sont donc couverts.
- La loi **s'applique hors d'Australie** (aux actes commis hors d'Australie), et son respect est assuré par des dispositions de sanctions civiles, et non par le droit pénal (s 27).
- Moyens de défense : l'expéditeur ne savait pas, et ne pouvait pas découvrir avec une diligence raisonnable, que le message présentait un lien avec l'Australie ; ou le message a été envoyé **par erreur**. L'expéditeur supporte la **charge de la preuve** (ss 16(3)–(5)).

## Les trois obligations

### 1. Consentement (s 16 et annexe 2)

Un message électronique commercial qui présente un lien avec l'Australie ne doit pas être envoyé sans le **consentement du titulaire du compte électronique concerné**. Le consentement désigne (annexe 2, cl 2) :

- **Le consentement exprès.** L'ACMA le considère comme la meilleure pratique. Il peut être donné par un formulaire, une case à cocher sur un site web, par téléphone ou en personne. **Vous ne pouvez pas envoyer un message électronique pour demander le consentement**, car cette demande est elle-même un message marketing. Conservez la trace de qui a consenti, quand et comment, car **c'est à l'expéditeur de prouver le consentement**.
- **Le consentement déduit.** C'est le consentement raisonnablement déduit du **comportement et des relations d'affaires ou autres** du destinataire. L'ACMA l'interprète de façon étroite. Il exige une **relation continue** et prouvable, et le marketing doit être **directement lié** à cette relation. Une banque peut présenter un autre compte d'épargne à un client titulaire d'un compte d'épargne, mais ne peut *pas* se servir de cette relation pour vendre une assurance à ce même client. Un achat ponctuel ne crée **pas** de consentement déduit.
- **La publication bien en vue** (annexe 2, cl 4). Le consentement peut être déduit pour une **adresse électronique professionnelle** publiée bien en vue : l'adresse d'un salarié, d'un administrateur, d'un dirigeant, d'un associé, du titulaire d'une fonction ou d'un travailleur indépendant, ou l'adresse d'un rôle ou d'un poste. La publication doit raisonnablement sembler faite avec l'accord de la personne ou de l'organisation. Cela ne s'applique **pas** si la publication est accompagnée d'une mention indiquant que les messages commerciaux non sollicités ne sont pas souhaités, et cela ne couvre que les messages **en rapport avec l'activité, les fonctions ou les attributions professionnelles** du destinataire. En dehors de ce cas, publier une adresse **ne vaut pas** consentement (annexe 2, cl 4(1)). C'est la seule tolérance australienne pour le B2B ; pour le reste, les adresses professionnelles suivent les mêmes règles de consentement que les adresses de particuliers.
- **Le retrait du consentement** prend effet à la fin d'un délai de **5 jours ouvrés** à compter du jour de l'envoi du message de désabonnement (annexe 2, cl 6). Les jours ouvrés se comptent selon le lieu où se trouve le destinataire.
- Listes achetées ou louées : l'annonceur reste tenu de prouver le consentement pour chaque adresse utilisée.

### 2. Identification de l'expéditeur (s 17)

Chaque message électronique commercial, y compris les messages exemptés (dits « désignés »), doit :

- **identifier clairement et exactement** la personne ou l'organisation qui a **autorisé** l'envoi (utilisez la dénomination légale de l'entreprise, ou le nom et l'Australian Business Number (ABN)) ;
- comporter des **coordonnées exactes** ; et
- ces informations doivent **raisonnablement pouvoir rester valides pendant au moins 30 jours** après l'envoi.

Si un tiers, comme une agence ou un ESP, envoie pour le compte d'une marque, le message doit tout de même identifier l'**entreprise qui a autorisé l'envoi**, et cette entreprise reste responsable (« vous ne pouvez pas externaliser votre risque », *you cannot outsource your risk*, fiche d'information de l'ACMA).

### 3. Désabonnement fonctionnel (s 18 et fiche d'information de l'ACMA de 2024)

Chaque message commercial, sauf les messages désignés, doit comporter une mention de désabonnement claire et bien visible, et un dispositif qui répond à ces exigences :

| Exigence | Détail |
|---|---|
| Instructions claires | Présentées de manière claire et bien visible (s 18(1)(d)) |
| Fonctionnel pendant au moins 30 jours | L'adresse de désabonnement doit pouvoir recevoir le message du destinataire, ainsi qu'un nombre raisonnable de messages similaires d'autres destinataires, pendant **au moins 30 jours** après l'envoi (s 18(1)(e)) |
| Traité sous 5 jours ouvrés | Fiche d'information de l'ACMA ; c'est le même délai que pour le retrait du consentement de l'annexe 2, cl 6 |
| Gratuit | Ne doit exiger aucun paiement, et ne doit pas coûter plus que le coût habituel d'utilisation de l'adresse (par exemple le prix d'un SMS standard) |
| **Sans connexion, sans compte et sans information personnelle supplémentaire** | Le destinataire ne doit pas avoir à se connecter à un compte, à en créer un, ni à fournir des informations personnelles supplémentaires pour se désabonner |
| Adresse obtenue légitimement | L'adresse de désabonnement elle-même doit avoir été obtenue légitimement (s 18(1)(f)) |

De grandes marques continuent d'enfreindre la règle de l'absence de connexion (voir les sanctions ci-dessous). Le parcours de désabonnement d'un ESP pour des destinataires australiens doit fonctionner sans aucune authentification.

## Autres comportements interdits

- **Les logiciels de collecte d'adresses et les listes d'adresses collectées** ne doivent pas être fournis, acquis ou utilisés en lien avec un envoi contraire à la s 16 (ss 20–22).
- **La responsabilité accessoire.** Aider, faciliter ou inciter une contravention, y être sciemment impliqué ou s'entendre pour la commettre constitue en soi une contravention (ss 16(9), 17(5), 18(6)). Cela concerne les plateformes et les agences. La simple fourniture d'un service de transport de communications en est exclue.
- Les messages ne doivent pas être envoyés à des adresses dont l'expéditeur n'a aucune raison de croire qu'elles existent (s 16(6)).

## Exemptions : les messages électroniques commerciaux désignés (annexe 1)

Ces messages sont exemptés des règles de **consentement** (s 16) et de **désabonnement** (s 18), mais restent soumis à l'**identification de l'expéditeur** (s 17) :

| Catégorie | Conditions |
|---|---|
| Messages d'information factuelle | Ne contiennent rien de plus qu'une information factuelle, avec des commentaires directement liés et les informations d'identification autorisées (le nom, le logo et les coordonnées de l'auteur, de l'employeur ou du sponsor). Le message ne serait pas commercial sans ces informations ajoutées (annexe 1, cl 2) |
| Organismes publics, partis politiques enregistrés, organisations religieuses, associations caritatives | Le message porte sur des biens ou des services, et l'organisme en est le fournisseur (annexe 1, cl 3) |
| Établissements d'enseignement | Le destinataire, ou un membre de son foyer, est ou a été inscrit, et l'établissement fournit les biens ou les services (annexe 1, cl 4) |

## Sanctions et application

### Plafonds légaux (ss 24–25)

Les sanctions sont exprimées en **unités de pénalité** pour chaque contravention, et c'est la Cour fédérale qui les prononce. Une seule journée d'envoi peut comporter de nombreuses contraventions :

| Personne | Sans antécédent : par contravention / plafond journalier | Avec antécédent : par contravention / plafond journalier |
|---|---|---|
| Personne morale, violation de la s 16 | 100 unités / 2 000 unités | 500 unités / **10 000 unités** |
| Personne morale, autres dispositions de sanction civile | 50 unités / 1 000 unités | 250 unités / 5 000 unités |
| Personne physique, violation de la s 16 | 20 unités / 400 unités | 100 unités / 2 000 unités |
| Personne physique, autres dispositions | 10 unités / 200 unités | 50 unités / 1 000 unités |

La Cour peut aussi ordonner l'**indemnisation** des victimes et la **restitution des avantages financiers** (ss 28–29). Les actions peuvent être engagées jusqu'à **6 ans** après la contravention (s 26). L'ACMA peut aussi émettre des **avis d'infraction** (annexe 3 : payables sous 28 jours, et délivrés dans les 12 mois suivant les contraventions alléguées), adresser des **avertissements formels** et accepter des **engagements dont les tribunaux peuvent exiger l'exécution**.

L'unité de pénalité du Commonwealth est indexée périodiquement. Elle valait 330 AU$ fin 2024, si bien que le plafond journalier de 10 000 unités pour une personne morale récidiviste dépasse 3 M AU$ par jour.

### Pratique de l'application : le bilan

L'ACMA publie l'issue de chaque enquête. Les défaillances du désabonnement et les envois sans consentement en représentent la plus grande part. Voici une sélection de mesures qui concernent l'email :

| Entreprise | Manquement | Issue | Date |
|---|---|---|---|
| Commonwealth Bank of Australia | Plus de 61 M d'emails qui exigeaient une **connexion pour se désabonner** ; plus de 4 M sans désabonnement fonctionnel ; plus de 5 000 envoyés après un désabonnement | Avis d'infraction de **3 552 000 AU$** et engagement exécutoire de 3 ans (le plus élevé jamais infligé à l'époque) | Juin 2023 |
| Commonwealth Bank of Australia (de nouveau) | Emails et SMS sans consentement, désabonnement non fonctionnel | Avis d'infraction de **7 502 610 AU$** et engagement exécutoire (EE) | Août 2024 |
| Tabcorp (TAB) | SMS et WhatsApp : informations sur l'expéditeur insuffisantes, pas de désabonnement fonctionnel, pas de consentement | **4 003 270 AU$** + EE | Avril 2025 |
| Pizza Hut Australia | Emails sans consentement, sans coordonnées ni désabonnement fonctionnel | 2 502 500 AU$ + EE | Mai 2024 |
| Sportsbet | Emails et SMS sans consentement ni désabonnement | 2 508 600 AU$ + EE | Mars 2022 |
| DoorDash | Emails et SMS sans consentement ni désabonnement | 2 011 320 AU$ + EE | Août 2023 |
| Binance Australia | Emails sans consentement ni désabonnement | 2 000 220 AU$ + EE | Octobre 2022 |
| Latitude Finance | Emails et SMS sans consentement ni désabonnement | 1 549 560 AU$ + EE | Juillet 2022 |
| Luxottica | Emails sans consentement ni désabonnement | 1 512 500 AU$ + EE | Avril 2024 |
| Kmart | Emails sans consentement | 1 303 500 AU$ + EE | Septembre 2023 |
| Woolworths | Emails **après le retrait du consentement** et sans désabonnement | 1 003 800 AU$ + EE | Juin 2020 |
| Lululemon Australia | Plus de 370 000 emails à contenu commercial **sans désabonnement** | 702 900 AU$ | Mars 2026 |
| Betfair | Emails et SMS à des **clients VIP** sans consentement ni désabonnement | 871 660 AU$ + EE | Mai et juillet 2025 |
| Telstra | SMS sans consentement ni désabonnement | 626 000 AU$ + EE | Décembre 2024 |
| Singtel Optus | Emails et SMS marketing **après le retrait du consentement** et sans désabonnement | 504 000 AU$ + EE | Janvier 2020 |
| Ticketek | Emails et SMS sans consentement | 515 040 AU$ + EE | Octobre 2023 |
| Uber Australia | Emails sans consentement ni désabonnement | 412 500 AU$ | Septembre 2023 |
| Kogan | Emails sans désabonnement **fonctionnel** | 310 800 AU$ + EE | Janvier 2021 |

Rien que sur les 18 mois précédant la mi-2023, les entreprises ont payé **11 M AU$** de sanctions liées au spam et au télémarketing, ont pris 12 engagements exécutoires devant les tribunaux et ont reçu 1 avertissement formel.

Les schémas contre lesquels un ESP doit se prémunir dès la conception sont les liens de désabonnement qui exigent une connexion (CBA), les messages « transactionnels » à contenu promotionnel sans désabonnement (Lululemon, Kogan), les envois après le retrait du consentement (Woolworths, Optus, Ticketek), et le fait de considérer les segments VIP ou de fidélité comme exemptés de consentement (Betfair).

## Articulation avec le Privacy Act : l'APP 7 de l'OAIC (prospection directe)

L'Australian Privacy Principle 7, dont le respect est contrôlé par l'Office of the Australian Information Commissioner (OAIC), restreint l'utilisation d'informations personnelles à des fins de prospection directe. Toutefois, **l'APP 7 ne s'applique pas dans la mesure où le Spam Act (ou le Do Not Call Register Act) s'applique**. Pour la prospection par email, SMS ou MMS, c'est le Spam Act qui s'applique. L'APP 7 couvre les autres canaux (courrier, porte-à-porte, publicité en ligne ciblée, marketing dans les applications), et s'applique lorsqu'une organisation est exemptée de ces lois. Elle reste pertinente pour les programmes email :

- **APP 7.2.** Les informations collectées **directement** auprès de la personne peuvent être utilisées pour la prospection directe si la personne **s'y attendrait raisonnablement** (un critère objectif), si un **moyen simple de s'y opposer** est fourni et si la personne ne s'y est pas opposée.
- **APP 7.3.** Pour les informations provenant de **tiers**, ou lorsque la personne ne s'attendrait pas raisonnablement à la prospection, il faut un consentement (sauf s'il est impossible en pratique de l'obtenir), un opt-out simple, **et une mention d'opt-out bien visible dans chaque communication** (en langage clair, placée bien en vue, dans une police lisible).
- **APP 7.4.** Les **informations sensibles** ne peuvent être utilisées pour la prospection directe qu'avec un **consentement explicite**, et il n'existe pas d'exception pour impossibilité pratique.
- Sur demande, une organisation doit indiquer à la personne **où elle a obtenu ses informations personnelles** (sauf si c'est déraisonnable ou impossible en pratique), dans un délai d'environ 30 jours. Elle doit aussi respecter les demandes d'opposition à la « facilitation » de listes, c'est-à-dire la fourniture de données pour la prospection d'autres organisations.
- Un « moyen simple » de s'opposer comporte des instructions claires, demande peu d'effort, est gratuit ou très peu coûteux, et est disponible par le canal utilisé pour la prospection.

## Les lignes directrices de l'OAIC sur les pixels de suivi

Les lignes directrices de l'OAIC sur les pixels de suivi visent les pixels de tiers. Elles portent surtout sur les pixels des sites web, tout en notant que des pixels sont aussi utilisés dans les emails et les applications. Leurs principales positions utiles pour le suivi des ouvertures et des clics :

- Des données comme les **adresses IP, les URL ou les adresses email hachées** peuvent être des **informations personnelles** lorsqu'elles peuvent être rapprochées des données d'une plateforme tierce, même si la personne n'est pas directement identifiée. L'OAIC conseille aux organisations de « pécher par excès de prudence » (*err on the side of caution*).
- Les obligations en jeu sont :
  - **APP 1** : la politique de confidentialité doit indiquer l'utilisation de pixels de tiers.
  - **APP 3** : la collecte doit être raisonnablement nécessaire, et les pixels devraient être configurés pour la **minimisation des données**. Les informations sensibles exigent un consentement exprès par opt-in et devraient en général être exclues de toute divulgation par pixel.
  - **APP 5** : informer les personnes au moment de la collecte ou avant, y compris sur les destinataires tiers et les transferts à l'étranger.
  - **APP 6** : la divulgation au fournisseur du pixel doit correspondre à la finalité de la collecte, ou reposer sur une base valable d'utilisation secondaire.
  - **APP 7** : un opt-out simple du marketing ciblé alimenté par les pixels.
  - **APP 8** : des mesures raisonnables pour la divulgation à l'étranger.
- Avant le déploiement, vérifiez le fonctionnement du pixel, examinez les conditions du fournisseur, réalisez une **analyse d'impact sur la vie privée** (Privacy Impact Assessment), configurez le pixel pour qu'il ne puisse pas collecter de données sensibles, et réexaminez-le régulièrement. **L'organisation qui déploie le pixel est responsable** de sa configuration conforme.

## Liste de contrôle ESP pour le trafic australien

- Un désabonnement en un clic qui ne demande aucune authentification ([List-Unsubscribe et RFC 8058](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic)) satisfait à la règle de l'absence de connexion. Supprimez l'adresse sous 5 jours ouvrés ; la suppression immédiate est la meilleure pratique.
- Maintenez le point de terminaison de désabonnement actif pendant au moins 30 jours après chaque campagne, et maintenez les coordonnées de l'expéditeur valides pendant au moins 30 jours.
- Conservez les preuves du consentement (qui, quand et comment), car l'expéditeur doit pouvoir les produire si l'ACMA les demande.
- Identifiez le **client qui autorise l'envoi** (dénomination légale ou ABN) dans chaque message envoyé pour son compte. Le client est responsable, mais la responsabilité accessoire peut atteindre toute personne sciemment impliquée.
- Ne considérez pas que « le destinataire a acheté quelque chose un jour » suffit. Le consentement déduit exige une relation continue et directement liée. Voir [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement) sur les différences de qualité du consentement.
- N'acceptez jamais de listes constituées avec des logiciels de collecte d'adresses. Les fournir ou les utiliser constitue une contravention distincte.

Ceci n'est pas un avis juridique. Voir l'[avertissement sur la conformité](https://emailmarketing.net/fr/apprendre/conformite).

# Brésil : la LGPD et le marketing par email

> Les bases légales de la LGPD pour le marketing par email (consentement ou intérêt légitime selon le guide de l'ANPD), les rôles de contrôleur et d'opérateur appliqués aux ESP, l'état des transferts internationaux (Resolução 19/2024, adéquation de l'UE), la position sur les données des enfants et des sanctions pouvant atteindre 50 M R$.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/bresil-lgpd-et-marketing-par-email

Si vous envoyez du marketing par email à des destinataires au Brésil, les règles viennent d'une loi sur la protection des données, et non d'une loi anti-spam. Le Brésil n'a **aucune loi anti-spam dédiée**. Le marketing par email auprès de destinataires brésiliens est régi par la **Lei Geral de Proteção de Dados (LGPD, Lei nº 13.709/2018)**, une loi inspirée du RGPD.

L'**ANPD** en assure le respect. La MP 1.317/2025 et la Lei 15.352/2026 l'ont rebaptisée d'Autoridade en **Agência Nacional de Proteção de Dados**, et lui ont donné le statut d'agence de régulation. Contrairement à la LCAP, au PECR ou au Spam Act, la LGPD n'a pas de règle d'opt-in pour chaque message. En revanche, tout traitement d'une adresse email (une donnée personnelle, article 5, I) exige une **base légale**, de la transparence et le respect des droits de la personne concernée. Les sources ont été lues dans leur version originale en portugais.

## Bases légales du marketing (article 7)

L'article 7 énumère dix bases légales. Ces deux-là comptent pour le marketing :

| Base | Texte | Conséquences pour le marketing |
|---|---|---|
| **Consentement** (article 7, I) | Manifestation de volonté libre, éclairée et univoque pour une **finalité déterminée** (article 5, XII) | Écrit ou démontrable par un autre moyen (article 8). S'il est écrit, il doit figurer dans une **clause mise en évidence** par rapport aux autres clauses du contrat (article 8, §1). **Les autorisations génériques sont nulles** (article 8, §4). **La charge de la preuve pèse sur le contrôleur** (article 8, §2). Le consentement est révocable à tout moment par une **procédure gratuite et facilitée** (article 8, §5). Le partage avec **d'autres contrôleurs** exige un **consentement spécifique** (article 7, §5) : une liste achetée doit donc reposer sur un consentement qui nomme l'acheteur. |
| **Intérêt légitime** (article 7, IX) | Traitement nécessaire pour répondre aux intérêts légitimes du contrôleur ou d'un tiers, **sauf lorsque prévalent les droits et libertés fondamentaux de la personne concernée** | L'article 10 cite expressément « **le soutien et la promotion des activités du contrôleur** » (article 10, I) comme finalité légitime possible, ce qui fonde le marketing direct par l'entreprise elle-même. Les conditions : uniquement les données **strictement nécessaires** (article 10, §1), des mesures de transparence (article 10, §2), et l'ANPD peut exiger un rapport d'impact sur la protection des données (RIPD, article 10, §3). |

Les autres bases (exécution d'un contrat, obligation légale, protection du crédit, etc.) justifient rarement l'email promotionnel. Les données publiques, ou que la personne concernée a manifestement rendues publiques, exigent toujours une finalité, la bonne foi et le respect des droits de la personne concernée (article 7, §§3-4). Les données publiques ne sont pas librement utilisables pour le marketing.

### Le guide de l'ANPD sur l'intérêt légitime (Guia de Legítimo Interesse, février 2024)

Le guide de l'ANPD explique comment l'article 7, IX, et l'article 10 s'appliquent en pratique :

- Un intérêt est légitime lorsqu'il est (i) **compatible avec l'ordre juridique**, (ii) fondé sur des **situations concrètes** (et non abstraites ou spéculatives), et (iii) lié à des **finalités légitimes, spécifiques et explicites**.
- Un **test de mise en balance (teste de balanceamento)** doit précéder tout recours à l'intérêt légitime, pour chaque finalité précise. Il pèse la légitimité, la nécessité, les effets sur la personne concernée et ses **attentes légitimes** (article 10, II). Si le test n'est pas concluant, ou si des garanties adéquates ne peuvent pas être identifiées, **utilisez une autre base légale**.
- Facteurs relatifs aux attentes légitimes : une relation directe antérieure avec le contrôleur ; la source et le mode de collecte (directement, ou auprès d'un tiers ou d'une source publique) ; le contexte et le moment ; et la compatibilité de la finalité de marketing avec la finalité de la collecte.
- **L'exemple 5 est le cas de référence pour le marketing.** Une université privée a envoyé par email à ses étudiants et à son personnel des promotions pour des livres et des produits culturels de sa propre maison d'édition, et ce traitement a été admis au titre de l'intérêt légitime. Il existait une relation antérieure, la promotion soutenait les propres activités du contrôleur (article 10, I), les données n'étaient pas partagées avec des tiers, et chaque message comportait un **mécanisme de désabonnement (descadastramento)** à titre de garantie. En pratique, **le marketing direct par l'entreprise auprès de sa propre clientèle, avec un opt-out fonctionnel, peut reposer sur l'intérêt légitime**. L'email froid adressé à des inconnus ne le peut pas, car il n'y a ni relation antérieure ni attente légitime.
- **L'intérêt légitime d'un tiers** (exemple 6 : la promotion d'une école de langues partenaire auprès des salariés) est possible, mais plus difficile à justifier. Une information préalable, un moyen facile de refuser et un test de mise en balance sont attendus.
- L'intérêt légitime est généralement **inapproprié pour utiliser des données d'enfants et d'adolescents à des fins publicitaires**. Dans l'exemple 3, une application éducative qui montre à des enfants des publicités pour des aliments ultra-transformés échoue au test, car il n'y a pas d'attente légitime et le principe de l'intérêt supérieur de l'enfant est violé.
- Obligation de tenue de registres : conservez le test de mise en balance et les registres de traitement (l'article 37 met en avant les registres « en particulier lorsque le traitement est fondé sur l'intérêt légitime »). Un traitement à haut risque appelle un RIPD.

### Les droits des personnes concernées qui encadrent la gestion des listes (articles 18 et 19)

- La confirmation de l'existence d'un traitement et l'accès aux données (dans un format simplifié **immédiatement**, ou sous forme de déclaration complète **sous 15 jours**).
- La rectification ; l'anonymisation, le blocage ou la **suppression** des données inutiles ou non conformes ; la suppression des données traitées sur la base du consentement (article 18, VI) ; l'information sur le partage (article 18, VII) ; la **révocation du consentement** (article 18, IX) ; et l'**opposition** à un traitement qui ne repose pas sur le consentement (article 18, §2). Juridiquement, un désabonnement est une révocation ou une opposition, et il doit être gratuit (article 18, §5).
- Après une rectification, une suppression ou un blocage, le contrôleur doit en informer les parties avec lesquelles il a partagé les données, afin qu'elles fassent de même (article 18, §6). La suppression doit donc se propager.

## Agents de traitement : contrôleur et opérateur, et la place de l'ESP

Définitions (article 5) : le **controlador** (VI) prend les décisions relatives au traitement ; l'**operador** (VII) traite les données **pour le compte** du contrôleur. Ensemble, ils sont les **agentes de tratamento** (IX). Le Guia Orientativo de l'ANPD sur les agents de traitement (mai 2021) explique comment ces rôles s'appliquent :

- Ce qui les distingue est le **pouvoir de décision**. Le contrôleur fixe la finalité et les « éléments essentiels » (types de données, durée). L'opérateur ne peut décider que des **éléments non essentiels** (logiciels, mesures techniques de sécurité). Une **agence de publicité ou de marketing qui mène une campagne selon le cahier des charges de la marque est un opérateur**, et la marque est le contrôleur (guide, ¶¶10-11, exemple 5).
- **Un ESP est un opérateur** pour les listes de ses clients. Il doit traiter les données **uniquement selon les instructions du contrôleur** (article 39), et devrait encadrer ce régime par un contrat écrit qui couvre l'objet, la durée, la nature et la finalité, les types de données et les responsabilités. Le guide recommande ce contrat mais ne l'impose pas (¶¶53-54).
- Un **sous-opérateur** est une partie que l'opérateur engage pour l'aider à traiter les données pour le contrôleur. C'est une notion propre au guide ; il peut s'agir par exemple du prestataire cloud ou de stockage de l'ESP, ou d'un sous-traitant de livraison. L'opérateur devrait obtenir l'**autorisation formelle** du contrôleur pour sous-traiter, qui peut être générale ou spécifique. Vis-à-vis de l'ANPD, le sous-opérateur est traité comme un opérateur (¶¶61-66, exemples 11 et 12).
- Le **contrôle conjoint** existe lorsque deux contrôleurs ou plus prennent des décisions communes ou convergentes sur les finalités et les éléments essentiels. Dans l'exemple 5, deux marques qui partagent leurs bases clients pour une campagne co-marquée sont contrôleurs conjoints, tandis que leur agence de marketing reste opérateur. Les contrôleurs directement impliqués sont **solidairement** responsables (article 42, §1, II).
- **Responsabilité (article 42)** : le contrôleur ou l'opérateur qui cause un dommage doit le réparer. **L'opérateur répond solidairement**, comme le contrôleur, **lorsqu'il manque aux obligations de la LGPD ou ne suit pas les instructions licites du contrôleur** (article 42, §1, I). Les tribunaux peuvent renverser la charge de la preuve en faveur de la personne concernée (article 42, §2). La conséquence pratique pour un ESP : envoyer au-delà des instructions du client, ou ignorer une suppression, rend l'ESP responsable aux côtés du client, comme s'il était contrôleur.
- Les deux agents doivent tenir des **registres des opérations de traitement** (article 37). Le contrôleur (et l'opérateur) doit désigner un **encarregado** (un délégué à la protection des données, DPO, article 41) et publier ses coordonnées. L'ANPD peut en dispenser les petits agents. La Resolução CD/ANPD 2/2022 classe aussi l'utilisation de données d'enfants comme « à haut risque », même pour les petits agents.

## Transferts internationaux (articles 33 à 36, Resolução CD/ANPD nº 19/2024)

L'article 33 autorise les transferts :

- (I) vers des pays ou des organisations internationales offrant un niveau de protection **adéquat** ;
- (II) moyennant des garanties fournies par le contrôleur : **clauses contractuelles spécifiques, clauses contractuelles types (CCT), normes d'entreprise globales, ou labels, certificats et codes de conduite** ;
- (V) sur autorisation de l'ANPD ;
- (VIII) avec un **consentement spécifique et mis en évidence**, après que la personne concernée a été informée du caractère international de l'opération ;
- et dans des cas limités d'intérêt public, d'intérêt vital ou d'obligation légale (IX).

L'état actuel, selon la page des affaires internationales de l'ANPD (consultée en juillet 2026) :

- **Réglementation** : la Resolução CD/ANPD nº 19 du 23 août 2024 a approuvé le règlement sur les transferts, **y compris les CCT brésiliennes**. Les contrats existants disposaient d'un **délai de 12 mois** à compter de la publication pour intégrer les CCT (soit d'ici août 2025).
- **Décisions d'adéquation** : l'ANPD a reconnu l'**Union européenne** comme adéquate (Resolução CD/ANPD nº 32 du 26 janvier 2026). Aucun autre pays n'est listé. Cette décision est distincte du règlement sur les transferts ci-dessus. La **Resolução 19/2024** est le cadre national des transferts (les CCT brésiliennes), tandis que la **Resolução 32/2026** est la reconnaissance par l'ANPD de l'adéquation de l'UE pour les données qui quittent le Brésil. C'est la moitié brésilienne d'une reconnaissance **mutuelle** : à la même date (26 janvier 2026), la Commission européenne a adopté sa propre décision d'adéquation au titre de l'article 45 pour le Brésil (décision d'exécution (UE) 2026/179). Les transferts entre l'UE et le Brésil circulent désormais dans les deux sens sans CCT (voir [L'ESP sous-traitant au sens du RGPD](https://emailmarketing.net/fr/apprendre/conformite/l-esp-sous-traitant-au-sens-du-rgpd#transferts-internationaux-chapitre-v-du-rgpd)).
- **CCT étrangères équivalentes, clauses spécifiques et BCR (normes d'entreprise globales)** : le mécanisme existe, mais **aucune n'a été approuvée à ce jour**. Les demandes passent par le système SEI de l'ANPD.
- La conséquence pour les ESP : un ESP non brésilien qui traite des listes brésiliennes à l'étranger devrait intégrer les CCT brésiliennes à son contrat de sous-traitance (DPA) avec ses clients brésiliens, ou recourir à un autre mécanisme de l'article 33.

## Enfants et adolescents (article 14 et interprétation de l'ANPD)

- Article 14 : le traitement des données d'enfants et d'adolescents doit servir leur **intérêt supérieur**. L'article 14, §1, exige un **consentement spécifique et mis en évidence d'au moins un parent ou représentant légal** pour les données d'enfants. Le contrôleur doit faire des efforts raisonnables pour vérifier l'adulte qui consent (§5), ne doit pas subordonner la participation à des jeux ou à des applications à la fourniture de plus de données que nécessaire (§4), et doit publier ce qu'il collecte et comment (§2). Les données ne peuvent être collectées sans consentement que pour contacter les parents (pour un usage unique, sans conservation) ou pour protéger l'enfant (§3), et elles ne peuvent jamais être transmises ensuite (§3).
- Le document de l'ANPD cité dans les sources est le processus normatif de 2022 (Nota Técnica nº 34/2022/CGN et Estudo Preliminar). Il a examiné si le consentement parental est la **seule** base légale possible. Sa conclusion, l'interprétation 3, est devenue l'**Enunciado CD/ANPD nº 1 (22 mai 2023)** : les données d'enfants et d'adolescents **peuvent être traitées sur toute base légale de l'article 7 (ou de l'article 11 pour les données sensibles), à condition que l'intérêt supérieur de l'enfant prévale, apprécié au cas par cas** au titre du texte principal de l'article 14.
- Selon le guide sur l'intérêt légitime, toutefois, **la publicité auprès d'enfants fondée sur l'intérêt légitime échouera normalement au test de mise en balance**. Le traitement de données d'enfants est un critère désigné de **haut risque** qui exige un RIPD. Pour le marketing par email, considérez en pratique que les listes de destinataires de moins de 18 ans exigent un consentement parental.

## Sanctions (article 52)

L'ANPD applique les sanctions à l'issue d'une procédure administrative, de manière graduée, isolément ou cumulativement :

| Sanction | Détail |
|---|---|
| Avertissement | Avec un délai pour prendre des mesures correctives |
| **Amende** | Jusqu'à **2 % du chiffre d'affaires au Brésil de l'entité privée ou de son groupe** lors du dernier exercice (hors taxes), **plafonnée à 50 000 000 R$ par infraction** |
| Amende journalière | Dans la limite du même plafond de 50 M R$ |
| Publicité de l'infraction | Après confirmation |
| Blocage ou suppression | Des données personnelles concernées |
| Suspension partielle de la base de données | Jusqu'à 6 mois, prolongeable une fois |
| Suspension de l'activité de traitement | Jusqu'à 6 mois, prolongeable une fois |
| Interdiction partielle ou totale des activités de traitement | La plus sévère. La suspension ou l'interdiction ne s'applique qu'après une sanction préalable d'amende, de blocage ou de suppression dans la même affaire (§6) |

Les critères de fixation de la sanction (§1) comprennent la gravité, la bonne foi, l'avantage obtenu, la situation économique, la **récidive**, l'ampleur du dommage, la coopération, l'adoption de politiques de bonnes pratiques et de gouvernance, et la rapidité de la correction. La responsabilité civile (article 42) et les sanctions du droit de la consommation s'appliquent en parallèle (§2).

## Liste de contrôle ESP pour le trafic brésilien

- Associer chaque liste à une base légale : des preuves de consentement (qui, quand, comment, et pour quelle finalité précise), ou un test de mise en balance documenté au titre de l'intérêt légitime, avec la preuve d'une relation antérieure.
- Fournir dans chaque message un désabonnement fonctionnel et gratuit. C'est à la fois la voie de révocation de l'article 8, §5, et la garantie sur laquelle repose l'exemple de marketing de l'ANPD elle-même.
- Propager la suppression et l'effacement à tous les partenaires de partage (article 18, §6), et répondre aux demandes d'accès sous 15 jours.
- Contracter en tant qu'opérateur : un DPA écrit, un traitement limité aux instructions, l'autorisation du contrôleur pour les sous-traitants, et les CCT brésiliennes pour le traitement hors du Brésil.
- Refuser les listes de tiers dépourvues d'un consentement propre à l'acheteur (article 7, §5).

Ceci n'est pas un avis juridique : voir [Conformité](https://emailmarketing.net/fr/apprendre/conformite). Pour comparer les règles de consentement entre juridictions, voir la [LCAP](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel), le [PECR britannique](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email) et l'[Australie](https://emailmarketing.net/fr/apprendre/conformite/australie-spam-act-2003-et-application-par-l-acma).

# Conservation des preuves de consentement et charge de la preuve

> Ce qu'il faut recueillir et conserver pour prouver le consentement à une autorité ou à un opérateur de liste de blocage : les données à obtenir, enregistrer et gérer selon l'ICO, les normes émergentes de structure des preuves (Kantara Consent Receipt → ISO/IEC 29184 → ISO/IEC TS 27560 → W3C DPV), et un schéma de preuve de consentement applicable par un ESP, avec des repères sur la conservation et la production des preuves.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/conservation-des-preuves-de-consentement

> **Ceci n'est pas un avis juridique.** Une synthèse des lignes directrices et des normes sur la conservation des preuves de consentement, à l'intention des praticiens de la délivrabilité. Consultez un conseil qualifié pour toute décision de conformité.

Si vous invoquez le consentement comme base légale d'un envoi, ou comme défense lorsque votre délivrabilité est mise en cause, **la charge de la preuve pèse sur vous.** L'article 7, paragraphe 1, du RGPD dispose : « le responsable du traitement est en mesure de démontrer que la personne concernée a donné son consentement ». La question n'est pas seulement de savoir si la personne a consenti. Il s'agit de savoir si vous pouvez le prouver, pour chaque adresse, des années plus tard, devant une autorité ou devant un analyste de liste de blocage qui présume le pire.

Les sections ci-dessous présentent les données précises à recueillir, les normes de structure des preuves qui convergent vers un schéma commun, et une preuve de consentement qu'un ESP peut mettre en œuvre.

[Directive ePrivacy et RGPD](https://emailmarketing.net/fr/apprendre/conformite/directive-eprivacy-et-rgpd-marketing-par-email) explique quand le consentement est requis et la norme de qualité du Comité européen de la protection des données (CEPD), dont la ligne « Démontrable ». [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement) classe les manières d'acquérir des adresses. [Le RGPD et les listes de suppression des ESP](https://emailmarketing.net/fr/apprendre/conformite/rgpd-et-listes-de-suppression-des-esp) traite de la trace du retrait et de l'effacement. La **preuve** décrite ici sous-tend les trois.

## Pourquoi la preuve compte deux fois

Une preuve de consentement est mise à l'épreuve dans deux contextes très différents :

- **Une contestation réglementaire.** Une autorité de protection des données, comme l'ICO ou la CNIL, ou un plaignant, demande au responsable du traitement de justifier sa base légale. Sans preuve, il n'y a en pratique pas de consentement. Le CEPD indique explicitement que renvoyer à la configuration actuelle du site web ne suffit pas (lignes directrices 05/2020, ¶108) : vous devez reproduire ce que la personne a réellement vu et fait à ce moment-là.
- **Une contestation par une liste de blocage ou en délivrabilité.** Une [adresse piège touchée](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges), un [pic de plaintes via une feedback loop (FBL)](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes) ou une inscription chez Spamhaus soulève la question « d'où vient cette adresse ? ». Une trace de la manière dont chaque adresse a été acquise (source, horodatage, adresse IP, version du formulaire, événement d'opt-in) fait souvent la différence entre un [retrait de liste](https://emailmarketing.net/fr/apprendre/reference/inscriptions-spamhaus-en-detail) rapide et un retrait qui s'enlise. C'est aussi la première chose que demande l'enquête sur un [incident d'adresse piège](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response).

La même preuve répond aux deux. Construisez-la une seule fois.

## ICO : obtenir, enregistrer, gérer

Les lignes directrices de l'Information Commissioner's Office (ICO) britannique, *How should we obtain, record and manage consent?*, sont l'énoncé le plus concret d'une autorité sur ce qu'il faut conserver. L'ICO signale que ces lignes directrices sont en cours de révision à la suite du Data (Use and Access) Act 2025.

### Les cinq données à enregistrer

L'ICO indique : « vous devez disposer d'une piste d'audit efficace de la manière et du moment où le consentement a été donné » (*"you must have an effective audit trail of how and when consent was given"*). La preuve doit démontrer les cinq éléments suivants :

| N° | Donnée | Ce que l'ICO demande de conserver |
|---|---|---|
| 1 | **Qui a consenti** | Le nom de la personne, ou un autre identifiant (un nom d'utilisateur en ligne, un identifiant de session). |
| 2 | **Quand la personne a consenti** | Une copie datée du document, ou des enregistrements en ligne qui comportent un **horodatage**. Pour un consentement oral, une note de l'heure et de la date prise sur le moment. |
| 3 | **Ce qui lui a été dit à ce moment-là** | Un **exemplaire de référence** du document ou du formulaire de collecte contenant la mention de consentement en usage à ce moment-là, ainsi que toute politique ou information de confidentialité distincte, **avec des numéros de version et des dates correspondant à la date du consentement**. Pour un consentement oral, une copie du script utilisé à l'époque. |
| 4 | **Comment la personne a consenti** | Pour un consentement écrit, une copie du formulaire concerné. Pour un consentement en ligne, **les données soumises** et un horodatage qui les rattache à la version concernée du formulaire de collecte. Pour un consentement oral, une note prise sur le moment. |
| 5 | **Si elle a retiré son consentement** | Et, le cas échéant, **quand**. |

Deux autres points s'appliquent. Le consentement doit être spécifique et granulaire, donc « vos registres doivent aussi être spécifiques et granulaires pour démontrer exactement ce que couvre le consentement » (*"your records also need to be specific and granular to demonstrate exactly what the consent covers"*) : conservez une preuve par finalité, et non un indicateur global unique. Pour le consentement en ligne, l'ICO suggère « une fonction de hachage cryptographique appropriée pour garantir l'intégrité des données » (*"an appropriate cryptographic hash function to support data integrity"*), ce qui rend détectable toute falsification de la preuve conservée.

L'élément qui compte le plus, et qui est le plus souvent oublié, est le **n° 3**. Vous devez pouvoir reproduire la formulation exacte, la mise en page du formulaire et la version de la notice de confidentialité que la personne a vues, avec leurs versions et leurs dates. Un formulaire en ligne aujourd'hui ne prouve pas une inscription d'il y a trois ans.

### Gérer : réexaminer régulièrement le consentement

L'ICO présente le consentement comme « une composante dynamique de votre relation continue » (*"a dynamic part of your ongoing relationship"*), et non comme quelque chose que l'on recueille une fois puis que l'on classe :

- **Les outils de gestion des préférences et les tableaux de bord de confidentialité** sont une bonne pratique. Ils permettent aux personnes de consulter et de mettre à jour leurs propres paramètres de consentement.
- **Réexaminez régulièrement les consentements, et renouvelez-les dès que quelque chose change.** Une nouvelle finalité ou une évolution du traitement peut faire que le consentement initial ne soit plus spécifique ou éclairé.
- **Intervalle de renouvellement :** « En cas de doute, nous vous recommandons d'envisager de renouveler le consentement **tous les deux ans** » (*"If in doubt, we recommend you consider refreshing consent every two years"*). Un intervalle plus long peut se justifier. Le consentement parental peut devoir être renouvelé plus souvent, à mesure que les enfants atteignent l'âge de consentir eux-mêmes.
- Si vous n'êtes pas en contact régulier avec les personnes, envoyez-leur **de temps à autre un rappel** de leur droit de retirer leur consentement et de la manière de le faire.

Ce repère par défaut « tous les deux ans » sert de base pour décider à quelle fréquence redemander la permission, ou appliquer une [politique de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil), pour les listes fondées sur le consentement dans l'**UE et au Royaume-Uni**.

**La durée pendant laquelle un consentement reste frais dépend de la juridiction et du canal. Il n'existe pas de chiffre universel unique.** Les chiffres des autorités varient d'un facteur 8 environ, car ils répondent à des questions différentes :

| Autorité | Chiffre | Ce qu'il mesure réellement |
|---|---|---|
| **ICO** (Royaume-Uni et UE) | renouveler **environ tous les 2 ans** en cas de doute | la durée pendant laquelle une preuve de consentement reste fiable avant de redemander la permission |
| **ACMA** (Australie) | le consentement devient périmé après **environ 3 mois**, sauf si les conditions prévoient plus | l'érosion du consentement au **télémarketing**, en particulier. Voir [Évolutions des positions des autorités sur le consentement](https://emailmarketing.net/fr/apprendre/conformite/evolutions-des-positions-des-autorites-sur-le-consentement#australie--la-déclaration-de-2024-de-lacma-sur-les-attentes-en-matière-de-consentement) |
| **CNIL** (France) | **environ 6 mois** sans redemander, à titre de bonne pratique | le délai avant de redemander après une absence de réponse, dans la recommandation sur les pixels de suivi. Voir [France : les règles de la CNIL](https://emailmarketing.net/fr/apprendre/conformite/france-regles-de-la-cnil-sur-la-prospection-par-email#recueillir-le-consentement-aux-pixels) |

Fixez votre cadence selon la juridiction et le canal concernés. Ne considérez aucun de ces chiffres comme le chiffre universel de fraîcheur.

### Gérer le retrait (article 7, paragraphe 3)

Retirer son consentement doit être **aussi simple que de le donner**, « à tout moment » et à l'initiative de la personne elle-même, et pas seulement en répondant à un message. L'ICO demande un « processus en une seule étape facilement accessible » (*"easily accessible one-step process"*), idéalement par le même moyen que celui utilisé pour consentir. La bonne pratique consiste à proposer à la fois un mécanisme disponible à tout moment (comme un tableau de bord) **et** un moyen de refuser dans chaque message (le [lien de désabonnement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic) ou l'en-tête de désabonnement en un clic). L'ICO relève qu'un tiers peut retirer le consentement au nom de la personne s'il y est autorisé, ce qui ouvre la voie aux registres sectoriels d'opposition comme le Fundraising Preference Service. Chaque retrait alimente la donnée n° 5 et la [liste de suppression](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture).

## Les normes de structure des preuves

Dix ans de travaux ont produit une structure commune et lisible par machine pour la preuve de consentement. Savoir comment ces normes se sont construites indique sur quels champs il existe un consensus.

| Niveau | Document | Rôle |
|---|---|---|
| Prédécesseur | **Kantara Consent Receipt Specification v1.1.0** (Kantara Initiative CISWG, 2017 ; révision archivée du 13 juin 2018) | Le premier schéma JSON ouvert pour un « reçu » lisible du consentement donné. Désormais archivé, mais contribution directe aux travaux de l'ISO. |
| Base pour les notices et le consentement | **ISO/IEC 29184:2020**, *Online privacy notices and consent* | Exigences relatives au contenu des notices et à l'obtention et au retrait du consentement. |
| Structure de la preuve | **ISO/IEC TS 27560:2023**, *Privacy technologies – Consent record information structure* | Une spécification technique qui définit la structure des champs d'une **preuve** de consentement et d'un **reçu**. Elle remplace Kantara comme schéma de référence. |
| Mise en œuvre interopérable | **W3C DPV** (Data Privacy Vocabulary), guide *Consent Records and Receipts as per ISO/IEC TS 27560:2023* | Un vocabulaire lisible par machine qui met la 27560 en pratique. Il associe chaque champ à un terme concret, afin que les preuves puissent être échangées entre systèmes. |

L'**ISO/IEC TS 27560:2023** est une *spécification technique*, pas encore une norme internationale à part entière. Elle organise une preuve de consentement en quatre types d'informations : (1) le traitement des données personnelles ; (2) la ou les notices de confidentialité par lesquelles ces informations ont été fournies ; (3) la manière dont les données ou le consentement ont été obtenus ; et (4) les événements liés au consentement (donné, renouvelé, retiré). Elle distingue deux documents :

- **La preuve de consentement** (*consent record*, interne) : « documentation d'informations sur le consentement d'une personne concernée… les détails du traitement ainsi que les interactions liées au consentement » (*"documentation of information about a data subject's consent… the details about the processing as well as the interactions related to consent"*). L'organisation la conserve pour démontrer que le consentement est valide. C'est la preuve qui vous permet de satisfaire à la charge de la preuve.
- **Le reçu de consentement** (*consent receipt*, externe) : « un document faisant autorité servant à communiquer l'existence d'une preuve de consentement ou à fournir des informations qu'elle contient » (*"an authoritative document used to communicate the existence of a consent record or to provide information contained within it"*), remis à la personne. Il peut contenir tout, une partie ou rien du contenu de la preuve. La 27560 n'impose pour le reçu qu'un en-tête minimal (l'identifiant de la preuve et la version du schéma) et demande de réutiliser les champs de la preuve pour le reste.

### La structure des champs de l'ISO/IEC 27560

Selon le guide de mise en œuvre du W3C DPV, les champs se répartissent en trois groupes : **en-tête**, **traitement** et **événement de consentement**. Le gras signale un champ obligatoire. La norme permet aux profils ou aux schémas de modifier les champs obligatoires, par exemple un profil pour le RGPD de l'UE.

| Groupe | Champs obligatoires | Champs facultatifs |
|---|---|---|
| **En-tête et métadonnées** | **Version du schéma** (profil applicable) · **Identifiant de la preuve** (unique, UUID-4) · **Identité de la personne concernée** (l'identifiant de la personne) | Créateur ou éditeur, horodatages de création et de modification, origine de la preuve |
| **Traitement** | **Finalité(s)** · **Catégories de données personnelles** · **Responsable(s) du traitement** · **Destinataires** · **Condition(s) de stockage** (où et pendant combien de temps) · **Juridiction(s)** · **Notice de confidentialité** (une référence à la notice présentée) · **Langue de la notice** | Base légale (autre que le consentement), sources et méthodes de collecte des données, opérations de traitement, lieux de traitement, restrictions géographiques, informations sur les droits, codes de conduite, analyse d'impact relative à la protection des données (AIPD), description du service |
| **Événement de consentement** | **Type d'événement** (donné, renouvelé ou retiré) · **État ou statut de l'événement** · **Horodatage de l'événement** · **Durée de validité** (durée de validité du consentement) · **Identifiant de l'entité** (qui a exprimé le consentement) | Méthode de retrait ou de modification, méthode d'expression |

L'ensemble obligatoire correspond presque terme à terme aux cinq données de l'ICO. « Qui » correspond à l'identité de la personne concernée et à l'identifiant de l'entité. « Quand » correspond à l'horodatage de l'événement. « Ce qui a été dit » correspond à la notice de confidentialité et à sa langue. « Comment » correspond à la méthode de collecte et au type d'événement. « Retrait » correspond au type, au statut et à l'horodatage de l'événement. La norme ajoute le détail du traitement (finalité, catégories de données, responsable du traitement, destinataires, conservation, juridiction) qui rend la preuve spécifique et granulaire.

### Les champs du reçu Kantara (la référence antérieure)

Le schéma JSON Kantara v1.1.0 reste la liste de champs la plus concrète, et de nombreux outils l'implémentent. Il consigne l'autorisation qu'un **PII Principal** (la personne concernée) accorde à un **PII Controller** (le responsable du traitement) :

| Champ | Contenu |
|---|---|
| `version` | Version du schéma, par exemple `KI-CR-v1.1.0` |
| `jurisdiction` | Juridiction(s) applicable(s) |
| `consentTimestamp` | Moment de l'obtention du consentement (temps Unix) |
| `collectionMethod` | Manière dont le consentement a été recueilli |
| `consentReceiptID` | Identifiant unique du reçu (DEVRAIT être un UUID-4) |
| `publicKey` | Clé permettant de vérifier l'intégrité du reçu |
| `language` | Langue du reçu (ISO 639-1) |
| `piiPrincipalId` | Identifiant de la personne qui consent |
| `piiControllers[]` | Identité du responsable du traitement : `piiController`, `contact`, `address` (streetAddress, addressCountry), `email`, `phone` |
| `policyUrl` | Lien vers la politique de confidentialité en vigueur |
| `services[]` → `purposes[]` | Pour chaque finalité : `purpose`, `purposeCategory`, `consentType` (EXPLICIT, IMPLICIT ou N/A), `piiCategory`, `primaryPurpose` (booléen), `termination` (fin du consentement), `thirdPartyDisclosure` (booléen), `thirdPartyName` |
| `sensitive` / `spiCat[]` | Présence de données de catégorie particulière, et lesquelles |

### Ce que dit la recherche (arxiv 2405.04528)

Pandit, Lindquist et Krog, *Implementing ISO/IEC TS 27560:2023 Consent Records and Receipts for GDPR and DGA* (2024), est l'étude de référence sur la mise en œuvre. Ses constats utiles ici :

- La structure abstraite de la 27560 ne rend pas, à elle seule, les preuves interopérables entre machines. Deux organisations peuvent produire des preuves conformes à la 27560 et ne pas pouvoir les échanger. L'article comble cet écart en associant chaque champ au vocabulaire du **W3C DPV**, ce qui donne des preuves et des reçus réellement interopérables et vérifiables.
- Il aligne la 27560 (la structure de la preuve) sur l'**ISO/IEC 29184** (le contenu des notices et du consentement) et sur les obligations du RGPD. Il montre ainsi que la référence à la version de la notice (donnée n° 3 de l'ICO) est un champ central, et non un ajout accessoire.
- Il applique la même approche au **Data Governance Act (DGA)** de l'UE, ce qui montre que la structure de la preuve fonctionne au-delà du consentement au marketing, pour le partage de données et l'altruisme en matière de données.

En pratique, pour un ESP : adoptez **l'ensemble de champs de la 27560 comme schéma de vos preuves, et les termes du DPV comme format d'échange**, si vos preuves doivent résister à une transmission entre responsable du traitement et sous-traitant ou être lues par les outils d'une autorité. Si vous n'avez besoin que d'une preuve à usage interne, l'ensemble de champs suffit.

## Un schéma de preuve de consentement applicable par un ESP

En combinant les cinq données de l'ICO, les champs obligatoires de la 27560 et les besoins du travail de délivrabilité, un ESP (ou son client, le responsable du traitement) devrait conserver la preuve suivante pour chaque événement de consentement :

| Champ | Origine de l'exigence | Exemple |
|---|---|---|
| `record_id` | En-tête 27560 (UUID-4) | `a6f58318-72e6-46a2-bfd7-f36d795e30cd` |
| `schema_version` | En-tête 27560 | `esp-consent-v1` |
| `subject_id` | ICO n° 1, 27560 | empreinte de l'email ou identifiant de compte, ainsi que l'adresse email en clair |
| `consent_event` | Type d'événement 27560 | `given` \| `renewed` \| `withdrawn` |
| `consent_status` | État de l'événement 27560 | `active` \| `withdrawn` \| `expired` |
| `timestamp` (UTC) | ICO n° 2, 27560 | `2026-01-14T09:31:07Z` |
| `purpose` (une ligne par finalité) | Granularité ICO, 27560 | `newsletter`, `product_updates`, `third_party_offers` |
| `consent_type` | Kantara, CEPD | `explicit` \| `soft-opt-in` |
| `collection_method` | ICO n° 4, 27560 | `web_form_double_opt_in` \| `checkout_checkbox` \| `api` |
| `source_url` ou identifiant du formulaire | délivrabilité | `https://…/signup` |
| `notice_ref`, `notice_version` et `notice_date` | ICO n° 3 (essentiel) | `privacy-policy@v7`, `2025-11-02` |
| `form_snapshot_ref` | ICO n° 3 | une empreinte du HTML conservé du formulaire exact et de la formulation du consentement, ou un pointeur vers ce HTML |
| `submitted_data` | ICO n° 4 | les valeurs de champs réellement soumises par l'utilisateur |
| `ip_address` et `user_agent` | preuve pour la délivrabilité | `203.0.113.9` |
| `double_opt_in_confirmed_at` et l'adresse IP de confirmation | défense contre le [bombardement d'inscriptions](https://emailmarketing.net/learn/esp-operations/subscription-bombing) | `2026-01-14T09:44:12Z` |
| `controller_identity` | 27560, Kantara | la dénomination légale et les coordonnées du client de l'ESP |
| `jurisdiction` | 27560 | `GB`, `DE`, … |
| `withdrawn_at` et `withdrawal_method` | ICO n° 5, article 7, paragraphe 3 | `2026-06-01T…`, `one_click_unsubscribe` |
| `integrity_hash` | ICO (hachage cryptographique) | SHA-256 de la preuve figée |

Notes de conception :

- **Conservez une preuve par combinaison de personne, de finalité et d'événement.** Un renouvellement ou un retrait ajoute une nouvelle ligne d'événement. N'écrasez jamais une ligne, car l'historique constitue la piste d'audit. L'état du consentement à un instant donné est le dernier événement pour cette personne et cette finalité.
- **Figez la notice au lieu de renvoyer à la version en ligne.** Conservez l'instantané versionné du formulaire et de la notice (ou une empreinte de son contenu) pour que la donnée n° 3 soit reproductible. Conservez les versions des politiques de confidentialité et des textes de consentement comme des documents qui ne changent jamais.
- **Le double opt-in produit la preuve la plus solide.** Le clic de confirmation fournit un second horodatage et une seconde adresse IP, qui prouvent que le titulaire de l'adresse a agi. La même étape déjoue le [bombardement d'inscriptions](https://emailmarketing.net/learn/esp-operations/subscription-bombing), tient les [adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges) à l'écart de la liste, et correspond à la [méthode de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement) que les autorités acceptent comme preuve (l'Allemagne l'exige de fait).
- **Plateformes multi-locataires :** l'ESP conserve la preuve pour le compte du responsable du traitement, son client. Au regard du RGPD, le client est le responsable du traitement et doit pouvoir récupérer ou exporter la preuve. Alignez ce point sur les [obligations du sous-traitant](https://emailmarketing.net/fr/apprendre/conformite/l-esp-sous-traitant-au-sens-du-rgpd) et sur la remise des données en fin de contrat décrite dans [Le RGPD et les listes de suppression des ESP](https://emailmarketing.net/fr/apprendre/conformite/rgpd-et-listes-de-suppression-des-esp).

## Conservation

- **Conservez la preuve aussi longtemps que vous traitez des données sur la base de ce consentement** (ICO), puis pendant une durée défendable ensuite pour répondre aux plaintes tardives et aux actions dans les délais de prescription, mais « pas plus longtemps que nécessaire » (CEPD). Fixez une règle de conservation explicite pour chaque catégorie de preuve plutôt que de tout garder indéfiniment.
- **Un retrait ne signifie pas supprimer la preuve.** Après un retrait, vous cessez de traiter les données pour cette finalité, mais vous avez besoin de la preuve du consentement et de son retrait elle-même, pour prouver que vous avez respecté le retrait et pour maintenir l'adresse en suppression. [Le RGPD et les listes de suppression des ESP](https://emailmarketing.net/fr/apprendre/conformite/rgpd-et-listes-de-suppression-des-esp) résout cette tension entre effacement et suppression : l'enregistrement de suppression ou de retrait est conservé sur une base légale distincte (conformité et responsabilité), indépendamment du consentement au marketing.
- **Séparez les deux horloges.** La première est la durée de conservation de la preuve d'un consentement actif (pendant le traitement). La seconde est la durée de conservation de la trace du retrait ou de la suppression (indéfiniment, jusqu'à ce que l'adresse n'existe plus, pour éviter tout nouvel envoi).

### Conservation des preuves de consentement selon la juridiction

Il ne s'agit pas ici de la durée pendant laquelle un consentement reste frais (la cadence pour redemander la permission, comparée plus haut), mais de la durée de conservation de la **preuve du consentement elle-même**. Aucun régime ne fixe de durée pour la preuve. Chacun lie la conservation à la durée du traitement, augmentée d'une période de défense ou de prescription. Suivez la règle de la juridiction concernée :

| Régime | Ce que cela implique pour la durée de conservation de la preuve du consentement |
|---|---|
| **RGPD / ICO britannique** ([Directive ePrivacy et RGPD](https://emailmarketing.net/fr/apprendre/conformite/directive-eprivacy-et-rgpd-marketing-par-email), [PECR britannique](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email)) | Conserver la preuve aussi longtemps que vous traitez des données sur la base de ce consentement, puis pendant une durée défendable ensuite pour répondre aux plaintes tardives et aux actions dans les délais de prescription, mais « pas plus longtemps que nécessaire ». Aucun chiffre fixe. |
| **France / CNIL** ([France : les règles de la CNIL](https://emailmarketing.net/fr/apprendre/conformite/france-regles-de-la-cnil-sur-la-prospection-par-email)) | Le même principe (article 7, paragraphe 1) : conserver la preuve pendant toute la durée d'utilisation des données, et assez longtemps ensuite pour répondre à un contrôle. Aucun chiffre fixe. |
| **Canada / LCAP** ([LCAP](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel)) | Aucune durée prescrite. La charge de la preuve incombe à l'expéditeur, et le consentement exprès n'expire pas. L'avis du Conseil de la radiodiffusion et des télécommunications canadiennes (CRTC) sur la tenue de registres, combiné au **délai de prescription de 3 ans** applicable aux procédures, implique de conserver les registres tant que vous invoquez le consentement et pendant au moins environ 3 ans après la dernière fois que vous l'invoquez. |
| **États-Unis / CAN-SPAM** ([CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis)) | Un régime d'opt-out : il n'y a aucun consentement à prouver, donc aucune preuve de consentement à conserver. Conservez plutôt la **trace de l'opt-out ou de la suppression**, indéfiniment, pour que l'adresse reste supprimée (voir [Le RGPD et les listes de suppression des ESP](https://emailmarketing.net/fr/apprendre/conformite/rgpd-et-listes-de-suppression-des-esp)). |

Le point commun est que la conservation des preuves de consentement suit un principe (les conserver pendant le traitement, plus une période de prescription ou de défense), et non une durée fixe. Le délai de prescription de 3 ans de la LCAP est le seul chiffre concret.

## Produire les preuves sur demande

Lorsqu'une autorité, un plaignant ou une liste de blocage vous demande de prouver le consentement pour `x@example.com` :

1. Recherchez le `subject_id` et extrayez l'historique complet des événements pour cette adresse (donné, renouvellements, retrait).
2. Pour l'événement concerné, restituez **qui** (subject_id), **quand** (l'horodatage, et l'horodatage de la confirmation du double opt-in), **ce qui a été dit** (la `notice_version` et le `form_snapshot` figés), **comment** (collection_method, submitted_data, adresse IP et user agent) et le **statut du retrait**.
3. Pour une inscription sur liste de blocage ou une adresse piège touchée, ajoutez le contexte d'acquisition : source_url, la campagne, les adresses IP d'opt-in et de confirmation, et la position de l'adresse dans le cycle de [suppression](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture) et d'hygiène.
4. Vérifiez l'`integrity_hash` pour montrer que la preuve n'a pas été modifiée.

S'il manque l'un des éléments qui, quand, ce qui a été dit, comment ou retrait, vous ne pouvez pas satisfaire à la charge de la preuve. C'est la raison pratique de recueillir les cinq lors de l'inscription plutôt que de les reconstituer lorsqu'on vous les réclame. Une preuve qu'il faut reconstruire après coup n'est pas une preuve.

## Voir aussi

- [Directive ePrivacy et RGPD dans l'UE : le marketing par email](https://emailmarketing.net/fr/apprendre/conformite/directive-eprivacy-et-rgpd-marketing-par-email), notamment les normes du CEPD « Démontrable » (article 7, paragraphe 1) et « Révocable » (article 7, paragraphe 3)
- [Méthodes de consentement et échelle de qualité des listes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement), notamment pourquoi le double opt-in fournit la preuve la plus solide
- [Le RGPD et les listes de suppression des ESP](https://emailmarketing.net/fr/apprendre/conformite/rgpd-et-listes-de-suppression-des-esp)
- [L'ESP sous-traitant au sens du RGPD](https://emailmarketing.net/fr/apprendre/conformite/l-esp-sous-traitant-au-sens-du-rgpd), pour les preuves conservées pour le compte d'un client
- [Droit d'opposition et droit à l'effacement](https://emailmarketing.net/fr/apprendre/conformite/droit-d-opposition-et-droit-a-l-effacement)
- [Architecture des listes de suppression](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture)
- [Réponse aux incidents d'adresses pièges](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response)

# Directive ePrivacy et RGPD dans l'UE : le marketing par email

> La règle d'opt-in de l'UE pour le marketing par email : l'article 13 de la directive ePrivacy et son soft opt-in, la norme de consentement du RGPD selon les lignes directrices 05/2020 du CEPD, la base légale (consentement ou intérêt légitime), les pixels de suivi au regard de l'article 5, paragraphe 3, selon les lignes directrices 2/2023 du CEPD, et le tableau des divergences entre États membres.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/directive-eprivacy-et-rgpd-marketing-par-email

> **Ceci n'est pas un avis juridique.** Cette référence résume les directives, le règlement et les lignes directrices du Comité européen de la protection des données (CEPD) à l'intention des praticiens de la délivrabilité. Les sanctions, les transpositions nationales et les lignes directrices évoluent : consultez un conseil qualifié pour toute décision de conformité.

Si vous envoyez des emails de marketing à des personnes situées dans l'Union européenne, deux textes décident si vous pouvez les envoyer et comment vous devez traiter les données. Les confondre est la source de la plupart des malentendus :

- **La directive 2002/58/CE « vie privée et communications électroniques »** (dite directive ePrivacy, modifiée par la directive 2009/136/CE) est la **règle d'envoi**. Son article 13 dit quand un email de marketing peut être envoyé : avec un consentement préalable, sauf une exception.
- **Le RGPD (règlement (UE) 2016/679)** fixe les **règles de traitement**. Il définit le consentement valable (articles 4(11) et 7), prévoit les bases légales (article 6) et accorde un droit absolu de s'opposer à la prospection (article 21(2) et (3)).

Dire que « le RGPD exige le consentement pour le marketing par email » est une simplification excessive. L'exigence d'un consentement pour envoyer vient de l'**article 13 de la directive ePrivacy**, tandis que le RGPD fixe la norme de qualité que ce consentement doit respecter. Dans ses lignes directrices 05/2020, ¶ 7, le CEPD confirme que les renvois de la directive ePrivacy au consentement de la directive 95/46/CE s'entendent désormais comme des renvois au consentement du RGPD, et que les conditions du consentement du RGPD s'appliquent dans les situations relevant d'ePrivacy.

Comme ePrivacy est une **directive**, chaque État membre l'a transposée dans son droit national, avec de réelles différences (voir le tableau ci-dessous). Une proposition de **règlement** ePrivacy destinée à remplacer la directive a été négociée pendant des années, puis retirée par la Commission au début de 2025. La directive de 2002, telle que modifiée en 2009, reste le droit applicable.

## Article 13 : communications non sollicitées

Principales dispositions (texte de 2002 ; la modification de 2009 a étendu la protection aux « abonnés ou utilisateurs » et ajouté des dispositions sur l'application, sans changer la structure ci-dessous) :

- **13(1) : consentement préalable.** « L'utilisation de systèmes automatisés d'appel sans intervention humaine (automates d'appel), de télécopieurs ou de courrier électronique à des fins de prospection directe ne peut être autorisée que si elle vise des abonnés ayant donné leur **consentement préalable**. » L'opt-in est la règle par défaut.
- **13(2) : le « soft opt-in » (l'exception des clients existants).** Le marketing par email sans consentement n'est permis que si **toutes** les conditions suivantes sont réunies :
  1. une personne physique ou morale **a obtenu de ses clients leurs coordonnées électroniques** en vue d'un courrier électronique,
  2. **dans le cadre de la vente d'un produit ou d'un service** (dans le respect du droit de la protection des données),
  3. **la même personne physique ou morale** exploite ces coordonnées (et non une société du groupe, un partenaire ou un acheteur de liste),
  4. à des fins de prospection directe pour **des produits ou services analogues qu'elle-même fournit**, et
  5. les clients se voient donner **clairement et expressément la faculté de s'opposer, sans frais et de manière simple**, à la fois **au moment où les coordonnées sont recueillies** et **lors de chaque message** (au cas où ils n'auraient pas refusé d'emblée).
- **13(3)** : pour la prospection directe par d'autres moyens (par exemple le courrier postal ou les appels avec intervention humaine), les États membres choisissent entre opt-in et opt-out dans leur droit national.
- **13(4)** : quel que soit le consentement, il est **interdit** d'émettre des emails de prospection « en camouflant ou en dissimulant l'identité de l'émetteur au nom duquel la communication est faite », ou **sans adresse valable** à laquelle le destinataire peut transmettre une demande visant à faire cesser ces communications. (La modification de 2009 a ajouté l'interdiction des emails qui renvoient vers des sites enfreignant les règles d'identification du commerce électronique.)
- **13(5)** : les paragraphes 1 et 3 protègent les **personnes physiques**. Les États membres doivent aussi veiller à ce que les intérêts légitimes des **personnes morales** (les abonnés professionnels) soient « suffisamment protégés ». C'est pourquoi le traitement du courrier entre entreprises (B2B) varie d'un pays à l'autre (voir le tableau).

**« Courrier électronique »** (article 2, point h)) : « tout message sous forme de texte, de voix, de son ou d'image envoyé par un réseau public de communications qui peut être stocké dans le réseau ou dans l'équipement terminal du destinataire jusqu'à ce que ce dernier le récupère ». Cela couvre l'email, le SMS, la messagerie vocale et, selon les autorités de contrôle, les messages directs dans les applications et sur les réseaux sociaux. Cette définition est aussi large que la [définition du PECR britannique](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email), qui est la transposition britannique de cette directive.

## La norme de consentement du RGPD (lignes directrices 05/2020 du CEPD, v1.1, adoptées le 4 mai 2020)

Article 4(11) : le consentement est « toute manifestation de volonté, **libre, spécifique, éclairée et univoque** par laquelle la personne concernée accepte, par une déclaration ou par un acte positif clair, que des données à caractère personnel la concernant fassent l'objet d'un traitement ». Le CEPD le met en pratique comme suit :

| Élément | Exigences du CEPD |
|---|---|
| **Libre** | Un choix réel, sans préjudice. Un consentement intégré aux conditions générales est présumé ne pas être libre (considérant 43, article 7(4)). Subordonner un service au consentement à un traitement non nécessaire (le « couplage ») est présumé invalide, et les exceptions sont « hautement exceptionnelles ». Les situations de déséquilibre des pouvoirs (employeur et salarié, autorités publiques) font généralement obstacle au consentement. Les incitations sont admises si le refus ou le retrait ne coûte rien (perdre un avantage licite n'est pas un préjudice). |
| **Spécifique et granulaire** | Un consentement distinct pour chaque finalité (« granularité ») : une seule case couvrant à la fois « envoyez-moi du marketing par email » et « partagez mes coordonnées avec les sociétés du groupe » est invalide (exemple 7). La spécification des finalités protège contre le détournement de finalité, et une nouvelle finalité exige un nouveau consentement. |
| **Éclairé** | Contenu minimal : (i) l'identité du responsable du traitement, (ii) la finalité de chaque opération, (iii) les données concernées, (iv) le droit de retirer son consentement, (v) la prise de décision automatisée le cas échéant, (vi) les risques liés aux transferts le cas échéant. Tous les responsables du traitement qui s'appuient sur le consentement doivent être **nommés** ; les sous-traitants n'ont pas à l'être. Un langage clair et simple, séparé et distinct des conditions générales, et non enfoui dans une politique de confidentialité. |
| **Univoque** | Une déclaration ou un acte positif clair. **Les cases précochées, le silence, l'inactivité ou la simple poursuite de l'utilisation d'un service ne valent pas consentement**, et faire défiler une page ou balayer l'écran ne peut jamais constituer un consentement (exemple 16). Le consentement doit précéder le traitement. |
| **Démontrable** (article 7(1)) | La charge de la preuve pèse sur le responsable du traitement. Conservez assez de données pour établir le lien avec le traitement, par exemple les informations de session, le parcours de recueil du consentement et **une copie des informations présentées à ce moment-là**. Se contenter de renvoyer à la configuration actuelle du site web ne suffit pas (¶ 108). Le consentement n'a pas de date d'expiration légale, mais le CEPD recommande de le renouveler à intervalles appropriés. Ne conservez pas la preuve plus longtemps que nécessaire après la fin du traitement. |
| **Révocable** (article 7(3)) | Aussi simple à retirer qu'à donner, à tout moment, gratuitement et sans dégradation du service. Si le consentement a été donné en un clic, le retrait doit être tout aussi simple **par la même interface électronique** : un désabonnement uniquement par téléphone, pour une inscription en ligne, enfreint l'article 7(3) (exemple 22, la billetterie d'un festival de musique). Après le retrait, cessez le traitement et supprimez les données, sauf si une autre base légale s'applique. |

Deux règles ont des conséquences directes sur la gestion des listes :

- **Pas de changement discret de base légale** (¶¶ 121 à 123) : un responsable du traitement ne peut pas se rabattre sur l'intérêt légitime lorsque le consentement se révèle invalide ou est retiré. La base légale doit être choisie et annoncée avant la collecte.
- **Les consentements antérieurs au RGPD** (¶¶ 166 à 171) ne restent valables que s'ils respectaient déjà la norme du RGPD. Les consentements présumés sans trace et les consentements recueillis par case précochée « seront automatiquement en deçà des normes de consentement ». Il fallait les renouveler ou cesser le traitement, et c'est la raison juridique de la vague de campagnes de reconsentement de 2018.

Pour les enfants, l'article 8 fixe à **16** ans l'âge du consentement pour les services de la société de l'information, qu'un État membre peut abaisser jusqu'à **13** ans au minimum.

## Base légale : consentement ou intérêt légitime

Au regard du seul RGPD, le traitement à des fins de prospection peut reposer sur le **consentement (article 6(1)(a))** ou sur l'**intérêt légitime (article 6(1)(f))**. Le considérant 47 le dit expressément : « Le traitement de données à caractère personnel à des fins de prospection peut être considéré comme étant réalisé pour répondre à un intérêt légitime. » Mais l'intérêt légitime **ne peut pas l'emporter sur l'article 13 de la directive ePrivacy** : pour l'acte d'envoyer un email, seuls le consentement de l'article 13(1) ou le soft opt-in de l'article 13(2) conviennent. Le schéma établi, que reprennent les recommandations de l'Information Commissioner's Office (ICO) pour le [PECR britannique](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email), est le suivant :

- pour un envoi fondé sur le **consentement de l'article 13(1)**, la base légale au titre du RGPD est le **consentement** ;
- pour un envoi fondé sur le **soft opt-in de l'article 13(2)**, la base légale au titre du RGPD est généralement l'**intérêt légitime**, documenté par une mise en balance des intérêts.

Dans les deux cas, l'**article 21(2) et (3)** accorde un droit **absolu** de s'opposer au traitement à des fins de prospection : « les données à caractère personnel ne sont plus traitées à ces fins », sans mise en balance, sans avoir à justifier de motifs, et sans frais (considérant 70). C'est le fondement juridique de l'obligation de suppression permanente.

**Amendes** : les violations des conditions du consentement et des droits des personnes concernées relèvent du plafond supérieur du RGPD, jusqu'à **20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial**, le montant le plus élevé étant retenu (article 83(5)). Les autres obligations des responsables du traitement et des sous-traitants sont passibles d'amendes allant jusqu'à 10 millions d'euros ou 2 % (article 83(4)). Les sanctions au titre d'ePrivacy sont fixées au niveau national et varient fortement.

## Pixels de suivi et article 5(3) : lignes directrices 2/2023 du CEPD (v2.0, adoptées le 7 octobre 2024)

L'article 5(3) (tel que modifié en 2009) exige un **consentement**, après une information claire et complète, pour « le stockage d'informations, ou l'obtention de l'accès à des informations déjà stockées, dans l'équipement terminal d'un abonné ou d'un utilisateur ». Il prévoit deux exemptions : le stockage ou l'accès techniques visant exclusivement à effectuer la transmission, et le stockage ou l'accès **strictement nécessaires** à un service expressément demandé par l'utilisateur. La règle est neutre sur le plan technologique (elle ne se limite pas aux cookies) et s'applique aux « informations », pas seulement aux données à caractère personnel.

Les trois critères d'applicabilité du CEPD sont les suivants : (A) l'opération porte sur des **informations** ; (B) elle concerne un **équipement terminal** connecté ou pouvant être connecté à un réseau public de communications ; (C) elle constitue un **stockage** ou une **obtention de l'accès**, qui n'ont pas besoin d'intervenir dans la même communication ni d'être effectués par la même partie.

**Le suivi des ouvertures et des clics dans les emails entre clairement dans le champ** (section 3.1, ¶¶ 47 à 51) :

- Un **pixel de suivi** dans un email existe pour amener le client de messagerie à ouvrir, vers l'hébergeur du pixel, une connexion qui n'aurait pas lieu autrement, ce qui révèle le moment où l'email est lu. Il peut porter des identifiants propres à chaque destinataire. Les **liens de suivi** fonctionnent de la même façon, l'identifiant étant ajouté à l'URL.
- La distribution des pixels ou des liens sur l'appareil « constitue bien un stockage, au moins par le mécanisme de mise en cache du logiciel côté client… **même si ce stockage n'est pas permanent** » (*does constitute storage, at the very least through the caching mechanism of the client-side software… even if this storage is not permanent*) (¶ 50).
- L'identifiant de suivi ajouté « constitue une instruction donnée à l'équipement terminal de renvoyer l'information ciblée » (*constitutes an instruction to the terminal equipment to send back the targeted information*), c'est-à-dire une **obtention de l'accès** (¶ 51).

Par conséquent, la télémétrie d'engagement au cœur du métier d'un fournisseur de services de messagerie (ESP), à savoir les ouvertures par pixel et les clics par redirection avec des jetons propres à chaque destinataire, exige dans l'UE un **consentement au titre de l'article 5(3)**, sauf si une exemption s'applique. Le CEPD n'analyse que le champ d'application et laisse les exemptions au droit national et à l'appréciation au cas par cas (¶ 40), mais aucune des deux exemptions ne couvre de manière plausible l'analytique marketing. Points aux conséquences opérationnelles :

- **Qui recueille le consentement** : l'expéditeur, responsable du traitement (le client de l'ESP), en général à l'inscription en même temps que le consentement au marketing, comme une finalité granulaire à laquelle on peut consentir séparément au sens des lignes directrices 05/2020 du CEPD.
- Les lignes directrices font aussi entrer en partie dans le champ le **suivi fondé sur la seule adresse IP** (¶¶ 54 et 55), et rappellent que l'applicabilité de l'article 5(3) « ne signifie pas systématiquement qu'un consentement doit être recueilli » (*does not systematically mean that consent needs to be collected*), car l'analyse des exemptions est distincte (¶ 56).
- **Tension avec les pratiques de délivrabilité** : les [politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil) fondées sur l'engagement supposent des données d'ouverture et de clic. En l'absence de consentement aux pixels, les solutions de remplacement sont des signaux agrégés ou issus des journaux, que l'expéditeur maîtrise : l'activité de clic sur des liens consentis, les données de livraison au niveau SMTP, les événements de plainte et de désabonnement, et l'activité sur le site ou d'achat. Apple Mail Privacy Protection précharge déjà les pixels et rend les ouvertures moins utiles comme signal individuel. Les contraintes de consentement de l'UE accélèrent donc un abandon déjà engagé des automatisations fondées sur les ouvertures.

## Divergences entre États membres (Fieldfisher, « Email Marketing Across Europe », janvier 2024)

Les transpositions nationales d'ePrivacy diffèrent sur trois points : l'email B2B est-il exempté de l'opt-in, le soft opt-in exige-t-il une **vente** effective ou seulement une relation commerciale (une demande de renseignements ou un devis), et le **double opt-in** est-il attendu comme preuve. Définitions : l'« opt-in » désigne un acte positif univoque, et le « soft opt-in » désigne les quatre conditions de l'article 13(2) (coordonnées recueillies dans le cadre d'une vente ; même entité juridique ; produits ou services analogues ; opposition gratuite lors de la collecte et dans chaque message). Le marketing par email pour le compte de tiers (« partenaires ») exige en pratique partout un opt-in qui nomme l'expéditeur.

| Pays | B2C (propres données) | B2B (propres données) | Soft opt-in : vente nécessaire ? | Remarques |
|---|---|---|---|---|
| Autriche | Double opt-in ; soft opt-in possible | Double opt-in ; soft opt-in possible | Non | Le DOI doit être utilisé lorsqu'on s'appuie sur l'opt-in ; la liste nationale d'opposition (ECG-Liste) prime sur le soft opt-in |
| Belgique | Opt-in ; soft opt-in possible | Opt-in pour les adresses B2B individuelles ; soft opt-in possible | Oui | Arrêté royal du 4 avril 2003 |
| Bulgarie | Opt-in ; soft opt-in possible | Opt-in ; soft opt-in possible | Non | |
| Croatie | Opt-in ; soft opt-in possible | **Opt-out** | Oui | |
| Chypre | Opt-in ; soft opt-in possible | Opt-in | Oui | |
| République tchèque | Opt-in ; soft opt-in possible | Opt-in ; soft opt-in possible | Oui | |
| Danemark | Opt-in ; soft opt-in possible | Opt-in ; soft opt-in possible | Oui | Loi sur les pratiques commerciales (Marketing Practices Act), art. 10 |
| Estonie | Opt-in ; soft opt-in possible | **Opt-out** | Oui | |
| Finlande | Opt-in ; soft opt-in possible | Adresse individualisée : opt-in ; adresse non individualisée ou liée à une fonction : **opt-out** | Oui | |
| France | Opt-in ; soft opt-in possible | **Opt-out** | Oui | Article L34-5 du CPCE ; B2B permis si le message est en rapport avec la fonction professionnelle du destinataire |
| Allemagne | **Double opt-in** (norme de preuve) ; le soft opt-in existe mais on s'y fie rarement | **Double opt-in** ; pas d'exemption B2B | Oui | Voir [Allemagne : UWG, § 7](https://emailmarketing.net/fr/apprendre/conformite/allemagne-article-7-de-l-uwg-et-marketing-par-email) |
| Grèce | Opt-in ; soft opt-in possible | Opt-in ; soft opt-in possible | Non | Loi 3471/2006 |
| Hongrie | Opt-in ; **pas de soft opt-in** | **Opt-out** | s.o. | |
| Irlande | Opt-in ; soft opt-in possible | **Opt-out** si le message est lié à la fonction professionnelle du destinataire, sinon opt-in | Oui | S.I. 336/2011 |
| Italie | Opt-in ; soft opt-in possible (email uniquement, pas le SMS) | Opt-in | Oui | |
| Lettonie | Opt-in ; soft opt-in possible | **Opt-out** | Oui | |
| Lituanie | Opt-in ; soft opt-in possible (email uniquement) | Opt-in ; soft opt-in possible | Oui | |
| Luxembourg | Opt-in ; soft opt-in possible | **Opt-out** | Oui | |
| Malte | Opt-in ; soft opt-in possible | Opt-in ; soft opt-in possible | Oui | |
| Pays-Bas | Opt-in ; soft opt-in possible | Opt-in ; soft opt-in possible | Oui | |
| Norvège | Opt-in ; soft opt-in possible | Adresse individualisée : opt-in ; adresse non individualisée : opt-out | Oui | Loi sur le contrôle du marketing (Marketing Control Act) de 2009 |
| Pologne | Opt-in ; **pas de soft opt-in** | Opt-in | s.o. | |
| Portugal | Opt-in ; soft opt-in possible | Individualisée : opt-in ; non individualisée : opt-out, sauf inscription sur la liste nationale d'opposition | Oui | Liste nationale d'opposition mise à jour chaque mois |
| Roumanie | Opt-in ; soft opt-in possible | Opt-in ; soft opt-in possible | Oui | |
| Slovaquie | Opt-in ; soft opt-in possible | Opt-out lorsque les coordonnées professionnelles ont été rendues publiques | Oui | |
| Slovénie | Opt-in ; soft opt-in possible | **Opt-out** | Oui | ZEKom-2 |
| Espagne | Opt-in ; soft opt-in possible | Opt-in ; soft opt-in possible | Oui | LSSI, loi 34/2002 |
| Suède | Opt-in ; soft opt-in possible | **Opt-out** si le message est lié à la fonction professionnelle du destinataire, sinon opt-in | Oui | |
| Suisse (hors UE) | Opt-in ; **pas de soft opt-in** | Opt-in | s.o. | Loi fédérale contre la concurrence déloyale, art. 3(1)(o) |
| Royaume-Uni (hors UE) | Opt-in ; soft opt-in possible | **Opt-out** (abonnés personnes morales exemptés) | Non | Voir [PECR britannique](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email) |

Lecture pratique pour un ESP à qui l'on demande « puis-je écrire à cette liste européenne ? » : pour une liste qui mêle plusieurs pays de l'UE, prenez comme base le cumul des règles. **Un opt-in documenté pour chaque personne, avec un désabonnement fonctionnel dans chaque message**, satisfait tous les États. Le soft opt-in n'est sûr qu'à l'intérieur d'un seul pays, pour vos propres envois sur des produits analogues, avec une offre d'opposition lors de la collecte dont vous pouvez prouver qu'elle a été faite. Les exemptions B2B sont propres à chaque pays et ne couvrent jamais les entrepreneurs individuels, qui sont des personnes physiques.

### Rester à jour

Le tableau ci-dessus est un instantané de janvier 2024. Consultez deux références tenues à jour avant de vous fier à une ligne :

- **DLA Piper, *Data Protection Laws of the World*** (dlapiperdataprotection.com) : plus de 160 juridictions, une rubrique « Electronic marketing » pour chaque pays, et une comparaison côte à côte. Elle est mise à jour deux fois par an.
- **IAPP Global Privacy Directory** (iapp.org/resources/global-privacy-directory) : 240 juridictions, avec des liens vers chaque autorité de protection des données et vers la législation sous-jacente pour les juridictions moins courantes.

## Enjeux pour la délivrabilité

Les conditions de l'article 13 inscrivent dans la loi ce que les fournisseurs de messagerie récompensent de toute façon : des adresses collectées directement, une relation commerciale réelle, un consentement granulaire, une offre d'opposition lors de la collecte et un désabonnement dans chaque message ([méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement), [fondamentaux](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)). Les exigences d'identité et d'adresse valable de l'article 13(4) correspondent aux normes de transparence de l'expéditeur que tous les filtres appliquent. Le droit et la délivrabilité divergent sur le consentement au suivi : les règles de l'UE limitent la télémétrie d'engagement que suppose une hygiène de base de données pilotée par la réputation. Les expéditeurs dont l'audience est surtout européenne devraient donc fonder leur logique de mise en sommeil sur les clics, les conversions et les plaintes plutôt que sur les ouvertures.

# Droit d'opposition et droit à l'effacement dans les opérations marketing

> Comment les demandes d'opposition, d'opt-out, de retrait du consentement et d'effacement au titre du RGPD et de l'UK GDPR interagissent avec les listes marketing et la suppression : lignes directrices opérationnelles de l'ICO et tendances de la synthèse des décisions de guichet unique du CEPD (551 décisions sur l'article 17 et 80 sur l'article 21).

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/droit-d-opposition-et-droit-a-l-effacement

Quand une personne vous demande de cesser de lui adresser de la prospection ou de supprimer ses données, ce que vous devez faire dépend du droit qu'elle exerce. Au titre du RGPD, du UK GDPR et des règles ePrivacy, un destinataire dispose de quatre moyens distincts de faire cesser la prospection : l'**opposition** (article 21 du RGPD), l'**opt-out ou désabonnement** (le mécanisme issu des règles ePrivacy), le **retrait du consentement** (article 7, paragraphe 3) et l'**effacement** (article 17). Ils diffèrent par leur portée et par ce que l'expéditeur doit ensuite faire des données.

Ils semblent aussi entrer en conflit : respecter un opt-out pour toujours implique de conserver l'adresse, alors que l'effacement implique de la supprimer. La **liste de suppression** résout ce conflit. Les recommandations ci-dessous combinent les lignes directrices opérationnelles de l'Information Commissioner's Office (ICO) britannique et le bilan d'application de la synthèse des décisions de guichet unique du Comité européen de la protection des données (CEPD). Pour la construction de la liste de suppression elle-même (hachage, base légale de sa conservation, suppression au niveau de l'ESP), voir [Le RGPD et les listes de suppression des ESP](https://emailmarketing.net/fr/apprendre/conformite/rgpd-et-listes-de-suppression-des-esp).

## Le droit d'opposition (article 21)

- À des **fins de prospection**, le droit est **absolu**. Il ne connaît aucune exception ni aucun motif de refus, il peut être exercé **à tout moment**, et il couvre **le profilage lié à la prospection**, y compris la déduction de centres d'intérêt à des fins de ciblage et la communication de données à des tiers à des fins de marketing.
- Pour un traitement fondé sur une **mission d'intérêt public ou l'intérêt légitime**, l'opposition n'est pas absolue. La personne invoque des raisons tenant à sa situation, et le responsable du traitement ne peut poursuivre que s'il a des **motifs légitimes et impérieux qui prévalent** sur les intérêts de la personne, ou pour des droits en justice. Le marketing fondé sur l'intérêt légitime reste soumis à la règle absolue applicable à la prospection.
- **Obligation d'information :** le droit d'opposition doit être porté à l'attention des personnes **au plus tard au moment de la première communication**, clairement et **séparément de toute autre information**, et aussi lors de la collecte, au titre du droit à l'information.

### Mécanique de traitement (ICO)

| Aspect | Règle |
|---|---|
| Forme | Orale ou écrite. **N'importe quel service de l'organisation** peut la recevoir, et aucune formule particulière n'est nécessaire : « je demande la garantie que cela ne se reproduira pas » (*I ask for a guarantee that this will not repeat itself*) compte |
| Délai | Dans les meilleurs délais, et au plus tard **un mois calendaire** après la réception. Le mois court du jour de la réception à la même date du mois suivant, ou au dernier jour du mois si cette date n'existe pas, ou au jour ouvré suivant si cette date tombe un week-end ou un jour férié. Vous fixer un délai de 28 jours garantit la conformité |
| Prolongation | **+2 mois** pour les demandes complexes ou nombreuses. Informez la personne au cours du premier mois, avec les motifs |
| Frais | Aucuns, sauf des frais administratifs raisonnables (ou un refus) pour les demandes **manifestement infondées ou excessives**. Appréciez chaque cas séparément, jamais par une politique générale. Des demandes répétées ne sont pas automatiquement excessives |
| Vérification d'identité | Uniquement ce qui est **nécessaire et proportionné** pour confirmer l'identité (par exemple la confirmation de l'adresse email à placer en suppression). Voir la synthèse ci-dessous sur les demandes de pièces d'identité |
| Refus | Uniquement pour les demandes infondées ou excessives, ou en vertu d'une exemption (jamais pour les oppositions à la prospection). Dans un délai d'un mois, indiquez à la personne les motifs, son droit d'introduire une réclamation auprès de l'autorité de contrôle et son droit à un recours juridictionnel |
| Préparation du personnel | Formez le personnel en contact avec la clientèle à reconnaître les oppositions, et tenez un journal des oppositions orales |

## Opposition, opt-out et retrait comparés (ICO, « respect people's preferences »)

- **Un opt-out ou désabonnement** fonctionne comme une opposition **limitée à un canal ou à une activité**. Dans l'exemple de l'ICO, un client envoie STOP par SMS. La prospection par SMS doit cesser, mais la prospection par email peut continuer, car le client n'a pas exercé d'opt-out sur ce canal. Indiquez clairement, lors de la collecte, quels canaux un opt-out couvre.
- **Le retrait du consentement** doit être **aussi simple que le fait de donner son consentement**. Cessez immédiatement, ou dès que possible, la prospection que couvrait le consentement. Vous ne devez **pas basculer vers une autre base légale** (par exemple l'intérêt légitime) pour poursuivre la prospection après le retrait du consentement, car ce serait déloyal.
- **Pas de reconquête après une opposition.** Recontacter plus tard une personne pour lui demander si elle a changé d'avis constitue en soi une prospection adressée à une personne qui s'y est opposée. Sa dernière indication prévaut. Une opposition n'est écartée que si la personne la retire expressément ou accepte ultérieurement la prospection. Le fait de ne pas s'opposer à nouveau ne l'écarte jamais.
- **Contacts autorisés :** un **message de confirmation** immédiat après un désabonnement (avec les instructions pour se réabonner) est acceptable, à condition que l'opt-out prenne effet sans aucune autre action. Les **rappels de préférences** ne sont autorisés que comme un ajout mineur et accessoire à un message envoyé de toute façon pour une autre finalité (par exemple une ligne à la fin d'un relevé annuel), sans contenu marketing ni incitation à changer de choix.

## Listes de suppression

Selon l'ICO, la liste de suppression est le concept dont tout le reste dépend :

- Quand une personne s'oppose ou exerce un opt-out, **placez ses données en suppression au lieu de les supprimer.** Conservez juste assez d'informations pour garantir le respect de sa préférence, et signalez-les clairement afin qu'elles ne soient pas utilisées pour les finalités auxquelles elle s'est opposée.
- **Une liste de suppression n'est pas un traitement « à des fins de prospection ».** Elle existe pour respecter une obligation légale. Cela met fin à l'argument circulaire selon lequel conserver l'adresse d'une personne qui s'est opposée serait en soi une prospection illicite, et cela signifie qu'il **n'existe aucun droit automatique à l'effacement de son entrée dans une liste de suppression**.
- Ce qui se passe si vous supprimez à la place, dans l'exemple de l'ICO : une entreprise supprime le numéro de téléphone d'une personne qui s'est opposée, achète plus tard une liste filtrée par le Telephone Preference Service (TPS) qui contient encore (licitement) ce numéro, et rappelle la personne. C'est une violation du PECR, qu'un filtrage par liste de suppression aurait évitée. La même chose se produit avec les listes email achetées ou importées à nouveau.
- La **minimisation des données** s'applique : ne conservez que le minimum nécessaire pour placer l'adresse en suppression.
- **Une liste de suppression n'est pas une liste de filtrage.** Exclure les personnes qui ne correspondent pas à une campagne constitue en soi un traitement à des fins de prospection. Seule la suppression motivée par la conformité bénéficie de ce statut particulier. (D'autres canaux ont des registres légaux d'opposition : TPS et CTPS pour les appels, MPS pour le courrier postal.)

## Les demandes d'effacement (article 17) dans le marketing

L'effacement n'est **pas absolu**. Dans le marketing, il s'applique lorsque le consentement est retiré, lorsque les données ne sont plus nécessaires à leur finalité, ou lorsque la personne s'est opposée à la prospection. Les lignes directrices de l'ICO :

- Vous n'avez pas à traiter un retrait ou une opposition **automatiquement comme une demande d'effacement**. En pratique, toutefois, dès que vous ne pouvez plus utiliser les données, vous les supprimerez probablement, **à l'exception de l'entrée minimale de suppression**.
- Le cas type : un client s'oppose et demande la suppression de ses données. L'entreprise cesse la prospection et supprime tout **à l'exception d'une petite quantité de données conservées sur sa liste de suppression**, et les droits du client sont satisfaits. L'effacement peut aussi être refusé pour des données nécessaires à d'autres finalités ; les données doivent alors être clairement signalées comme exclues de toute utilisation marketing.
- Au titre de l'article 17, paragraphe 1, lorsque le consentement est retiré ou qu'une opposition aboutit, le responsable du traitement a une **obligation autonome de supprimer** les données qui ne sont pas placées en suppression. La personne concernée n'a pas besoin de formuler une demande d'effacement expresse (synthèse du CEPD, citant l'avis 39/2021 du CEPD).

## Tendances de l'application dans la synthèse des décisions de guichet unique du CEPD

La synthèse a été rédigée pour le Support Pool of Experts du CEPD par le Pr Alessandro Mantelero (première version en décembre 2022, mise à jour en mai 2026). Elle analyse les décisions définitives de guichet unique au titre de l'article 60 qui figurent dans le registre public du CEPD : **551 décisions sur l'article 17 et 80 sur l'article 21**, adoptées de 2018 à janvier 2026.

Les affaires relevant de l'article 17 ont culminé en 2022-2023, principalement menées par l'autorité irlandaise (84 en 2022, 150 en 2023, 35 en 2024), puis ont diminué. Le nombre d'affaires relevant de l'article 21 est resté stable. En pratique, les deux droits arrivent ensemble : **la plupart des affaires relevant de l'article 21 concernent la prospection**, souvent associée à une demande d'effacement des données collectées auparavant. Une décision allemande (DEBE:OSS:D:2018:9) juge qu'une opposition à la prospection déclenche une **obligation de suppression au titre de l'article 17, paragraphe 1, point c), à appliquer « immédiatement »**.

Constats récurrents qui s'appliquent directement à l'exploitation de systèmes marketing :

**Défaillances de conception et d'information**

- Aucune information n'était donnée sur le droit d'opposition, en violation de l'article 13, paragraphe 2, point b) (ES:2021:263). Une banque a envoyé des emails marketing **sans option d'opt-out lors de l'inscription**, et les préférences n'étaient modifiables que dans son service de banque en ligne ou par le service client (NO:2021:292, qui a abouti à un rappel à l'ordre, à des mesures ordonnées et au respect des délais de l'article 12, paragraphe 3).
- **Adresses d'expéditeur « no-reply » :** si les réponses sont impossibles, le corps de l'email doit l'indiquer clairement, et préciser que les oppositions envoyées par réponse seront sans effet (FR:2019:8). En revanche (NL:2022:376), le RGPD n'exige pas que les personnes puissent se désabonner en répondant, mais les emails marketing doivent comporter un **lien clair vers une page où il est possible de se désabonner**.
- **Les liens de désabonnement qui mènent à une page de compte client ne fonctionnent pas pour les prospects** qui n'ont pas de compte. Un lien qui désabonne directement est requis (FR:2020:84). Concevez les parcours d'exercice des droits pour chaque type de destinataire auquel vous écrivez.
- Procédures lourdes et barrières linguistiques : fournir une adresse de contact pour les demandes d'exercice des droits, mais y répondre automatiquement par une redirection vers un formulaire « Contactez-nous » sur un site web, constituait en soi une violation (FR:2022:326).
- Les emails d'accusé de réception doivent indiquer quand la demande sera mise en œuvre, et le résultat doit être communiqué (EE:2019:55 ; FR:2019:41).

**Défaillances de processus**

- Arriérés et manque de capacité du service client (NO:2021:292). Une opposition enregistrée sur **un seul des comptes** que détenait la personne (EE:2019:55). Des erreurs techniques dans les systèmes qui ont retardé la mise en conformité (CZ:2021:312). Des bases de données non synchronisées, et d'anciennes adresses de contact que personne ne surveillait (MT:2021:212 : une réponse automatique ou un transfert est obligatoire quand une adresse de contact est désactivée ; FR:2023:999 : une ancienne adresse de support qui fonctionne encore et figure encore sur le web ne doit pas rester sans lecture). Des demandes transmises au mauvais service (UK:2019:31), et des demandes mal qualifiées.
- **Le responsable du traitement répond des erreurs de ses employés.** La faute individuelle ne change rien à la responsabilité au titre du RGPD (DEBE:2021:184).
- Les demandes faites manuellement ou en dehors des canaux habituels doivent être traitées de la même manière que les demandes automatisées (SE:2021:178 : une demande envoyée par courrier postal n'a pas reçu les notifications que le système numérique aurait envoyées). Une réception semi-automatisée qui écarte les demandes ne suivant pas les instructions est illicite (DK:2020:151). En revanche, **les demandes informelles** (un tweet) peuvent être ignorées lorsque des canaux formels existent (SE:2021:276, confirmé par SE:2024:1550 : chaque canal officiel du responsable du traitement doit fonctionner, mais les demandes envoyées à des adresses quelconques ou erronées n'ont pas à être satisfaites).
- Tenez un registre des demandes d'opposition et de leur issue, au titre du principe de responsabilité.

**Vérification de l'identité**

- **Exiger par défaut une pièce d'identité officielle n'est pas acceptable**, et viole la minimisation des données (article 5, paragraphe 1, point c)). Exemples : la politique générale de Groupon qui exigeait une carte d'identité (IE:2020:166), et FR:2019:3 (une relation client en ligne ne crée pas en soi de doute raisonnable). L'authentification doit être « pertinente, adéquate et proportionnée » (*relevant, appropriate and proportionate*) au regard des données, de la demande, du contexte et du risque de divulgation (FR:2024:1286).
- Les demandes envoyées depuis l'adresse email utilisée lors de l'inscription ne nécessitent normalement aucune preuve supplémentaire (CY:2024:1120). Les alternatives aux pièces d'identité comprennent des identifiants uniques remis lors de l'inscription, une politique qui n'accepte que l'adresse email liée au compte, des lignes téléphoniques avec mot de passe, des appels en ligne et des questions de contrôle (pseudonymes, date d'inscription ; EE:2021:294). Lorsque la communication d'une pièce d'identité est justifiée, protégez sa transmission (NO:2024:1126 : une carte d'identité envoyée par email non chiffré).
- Pour les oppositions en particulier, l'autorité de contrôle suédoise relève qu'il n'y a normalement **aucune raison d'authentifier la personne qui s'oppose**, et parfois même pas de l'identifier (SE:2025:1757).
- Les responsables du traitement doivent se mettre en conformité même si leur processus est imparfait. Poursuivre le traitement après une demande d'effacement valable enfreint l'article 6, paragraphe 1, puisque les données auraient pu être supprimées au moment de la demande.

**L'effacement en particulier**

- La plupart des affaires d'effacement découlent d'oppositions à la prospection (y compris des emails non sollicités ; NO:2022:314) et du nettoyage de comptes inutilisés. Les **outils de suppression en libre-service** sont mis en avant, car ils réduisent à la fois les erreurs et la charge de travail des autorités.
- **Preuve de l'effacement :** le responsable du traitement doit pouvoir démontrer qu'il s'est mis en conformité, par exemple par une capture d'écran qui montre que la base de données ne renvoie aucun résultat pour la personne qui a fait la demande (DE:2023:929).
- Informez la personne concernée des mesures prises dans les délais de l'article 12, paragraphe 3. Lorsque vous accueillez la demande, il suffit d'indiquer que l'effacement a commencé et combien de temps il prendra au maximum. Vous n'avez pas à confirmer son achèvement, sauf si la personne le demande (SE:2021:303).
- **Des motifs prépondérants** peuvent faire obstacle à l'effacement : la conservation d'identifiants de paiement pour prévenir la fraude (SE:2021:196) ; les durées de conservation légales (DK:2021:210, même si maintenir un compte actif pendant deux ans au seul motif que la personne a le droit de faire une réclamation n'était pas nécessaire, puisque les réclamations peuvent être faites par email ou par téléphone) ; les obligations au titre du droit de la lutte contre le blanchiment et du droit bancaire (MT:2022:340 ; MT:2021:272, où **la source juridique précise doit être indiquée à la personne qui fait la demande**) ; les dettes ; la conservation des dossiers passagers (PNR) ; et les registres publics. Les obligations légales doivent être interprétées conformément aux principes de protection des données, sans abus, et les données qui excèdent ce qu'exige l'obligation doivent tout de même être supprimées (l'« archivage intermédiaire » a des limites ; FR:2021:279, FR:2021:310).
- La plupart des affaires se terminent par des **règlements amiables et des rappels à l'ordre**. Les amendes sont rares, et reflètent généralement des manquements plus larges. Il est fréquent que les responsables du traitement se mettent en conformité d'eux-mêmes dès qu'une autorité de contrôle ouvre une enquête.

## Liste de contrôle opérationnelle pour une plateforme marketing

1. Traitez un désabonnement comme une opposition sur ce canal : placez l'adresse en suppression immédiatement, appliquez la suppression à tous les comptes et enregistrements du destinataire, et n'exigez jamais de connexion ni de compte.
2. Acheminez les oppositions rédigées en texte libre (réponses, tickets de support, appels téléphoniques) dans le même circuit de suppression que les clics sur un lien. Formez le personnel du support, et consignez les demandes orales.
3. Accusez réception de chaque demande en indiquant un délai, traitez-la dans un délai d'un mois et confirmez le résultat.
4. Lorsqu'un contact marketing demande l'effacement, supprimez les données de profil, conservez une entrée minimale de suppression, et soyez en mesure de prouver les deux (preuve de la suppression et enregistrement de suppression).
5. N'exigez pas de pièce d'identité par défaut. Considérez les demandes envoyées depuis l'adresse abonnée comme une preuve d'identité en elles-mêmes.
6. Rendez la suppression permanente, et filtrez chaque import de liste à partir de celle-ci, y compris les imports de listes que vous aviez déjà et de listes achetées.
7. Lorsque vous refusez un effacement en raison d'une obligation de conservation, indiquez la base juridique précise.

Ces obligations rejoignent les bonnes pratiques de délivrabilité. Des désabonnements instantanés et sans effort réduisent les plaintes pour spam qui pèsent sur la [réputation](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email). Le [désabonnement en un clic de la RFC 8058](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic), que Gmail, Yahoo et Microsoft exigent des expéditeurs de gros volumes, est exactement le mécanisme direct, sans compte, que les autorités de protection des données ne cessent d'ordonner aux expéditeurs de mettre en place.

# Évolutions des positions des autorités sur le consentement : ce qu'il faut suivre

> Une synthèse suivie des lignes directrices et des mesures d'application récentes sur le consentement que la base de connaissances doit suivre : les études de cas du DIA néo-zélandais sur le spam (issues réelles), la déclaration de 2024 de l'ACMA sur ce qu'exige désormais le « consentement » en Australie, et les règles de la CNIL pour la transmission de données B2C à des partenaires commerciaux, chacune avec l'enseignement opérationnel.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/evolutions-des-positions-des-autorites-sur-le-consentement

Si vous recueillez un consentement pour du marketing par email, ce que les autorités acceptent change plus souvent par leurs interprétations publiées que par de nouvelles lois. Voici des lignes directrices et des issues de procédures récentes qui précisent ce que le consentement exige en pratique, chacune avec l'enseignement à en tirer pour vos opérations.

Ces positions sont postérieures aux lois elles-mêmes, ou les affinent. Pour le droit de base, voir [Australie : le Spam Act](https://emailmarketing.net/fr/apprendre/conformite/australie-spam-act-2003-et-application-par-l-acma), [France : les règles de la CNIL](https://emailmarketing.net/fr/apprendre/conformite/france-regles-de-la-cnil-sur-la-prospection-par-email) et, pour la Nouvelle-Zélande, [Lois sur l'email en Asie-Pacifique](https://emailmarketing.net/fr/apprendre/conformite/lois-sur-le-marketing-par-email-en-asie-pacifique). Ce contenu n'est pas repris ici.

Ceci n'est pas un avis juridique. Voir [compliance/README.md](https://emailmarketing.net/fr/apprendre/conformite).

## Nouvelle-Zélande : les études de cas du DIA sur le spam

Le Department of Internal Affairs (DIA) publie des études de cas détaillées au titre de l'**Unsolicited Electronic Messages Act 2007** (pour le détail de la loi, voir [Lois sur l'email en Asie-Pacifique](https://emailmarketing.net/fr/apprendre/conformite/lois-sur-le-marketing-par-email-en-asie-pacifique#nouvelle-zélande--unsolicited-electronic-messages-act-2007)). Elles sont utiles parce qu'elles montrent le bas de l'échelle des sanctions, les avertissements formels et les avis d'infraction, là où aboutissent la plupart des situations réelles impliquant les clients d'un ESP, plutôt que les sanctions spectaculaires.

| Affaire | Comportement | Constat | Issue |
|---|---|---|---|
| **Base de données achetée** | L'expéditeur a acheté une base de données à un courtier et l'a utilisée pour ses envois, sans pouvoir démontrer que les destinataires avaient consenti. Les adresses n'avaient pas été « publiées bien en vue », et les messages étaient sans rapport avec les fonctions professionnelles des destinataires. | **11 violations** de la loi. L'achat de la base de données n'établissait **pas** le consentement : la charge de la preuve pèse sur l'expéditeur. | **Avertissement formel écrit** (le bas de l'échelle, sans sanction financière) |
| **Désabonnement défaillant** | L'expéditeur a continué d'envoyer une quantité importante d'emails commerciaux **sans dispositif de désabonnement fonctionnel** (s 11), même après un avertissement formel reçu en 2010 pour des violations des s 9 et s 11. | Un manquement persistant à la s 11 malgré l'avertissement antérieur. | **Avis d'infraction civil** (septembre 2011), alourdi parce que l'avertissement avait été ignoré |
| **Consentement déduit présumé** | L'expéditeur s'est fondé sur un consentement déduit d'une transaction sur Trade Me et a envoyé de la prospection **plusieurs mois après** la transaction. | « Le consentement déduit n'existait pas en l'espèce, faute de relation d'affaires » (*"Inferred consent did not exist in this instance, as a business relationship did not exist."*). | **Avertissement formel** (mai 2011) |

**Enseignements pour un ESP :**
- Une liste achetée ne vaut pas consentement, même dans le régime relativement souple de la Nouvelle-Zélande. L'expéditeur doit pouvoir prouver le consentement pour chaque adresse. Filtrez les clients qui arrivent avec des bases achetées (voir [Intégrité de l'acquisition d'adresses](https://emailmarketing.net/fr/apprendre/gestion-des-listes/integrite-de-l-acquisition-des-adresses) et [Vérification des clients](https://emailmarketing.net/learn/esp-operations/customer-vetting)).
- Le DIA alourdit la réponse lorsque le comportement **se répète** : un avertissement ignoré devient un avis d'infraction. Face au premier pic de plaintes d'un client, réagissez en partant du principe que l'autorité traitera le second bien plus sévèrement.
- **Le consentement déduit s'érode.** Une transaction passée unique, suivie de prospection plusieurs mois plus tard, n'est pas une « relation d'affaires continue ». L'Australie applique la même lecture étroite (ci-dessous).

## Australie : la déclaration de 2024 de l'ACMA sur les attentes en matière de consentement

Le **1er juillet 2024**, l'Australian Communications and Media Authority (ACMA) a publié *« Consumer consent: expectations for businesses conducting telemarketing and e-marketing »*. Cette déclaration est axée sur les résultats et précise ce que l'ACMA acceptera comme consentement valable au titre du [Spam Act 2003](https://emailmarketing.net/fr/apprendre/conformite/australie-spam-act-2003-et-application-par-l-acma). Elle ne modifie pas la loi. Elle indique aux expéditeurs comment l'autorité interprète en pratique le consentement « exprès » et « déduit ».

**Le consentement exprès (nettement préféré par l'ACMA)** est « une décision claire et univoque d'un client de recevoir de la prospection directe » (*"a clear and unambiguous decision by a customer to receive direct marketing"*), donnée par un formulaire, une case à cocher sur un site web, par téléphone ou en personne. Pour que le consentement soit valable, ses conditions doivent être **accessibles au moment de la collecte** et indiquer quatre éléments :

1. **à quoi** sert la prospection,
2. **qui** utilisera le consentement (quelles entreprises),
3. **pendant combien de temps** il sera invoqué, et
4. **comment** le client peut le retirer.

Interdictions explicites et mises en garde :
- **Pas de cases précochées.**
- Le consentement ne doit **pas être enfoui** dans les petits caractères ou dans de longues politiques de confidentialité. Il doit être transparent au moment de la collecte.
- Ne vous fondez que sur un consentement **actuel**, et renouvelez-le périodiquement. L'ACMA indique que le consentement au **télémarketing** devient « périmé » après **3 mois**, sauf si les conditions prévoient une durée plus longue. C'est une indication utile de la façon dont l'autorité envisage la fraîcheur du consentement en général, même si elle n'a pas fixé de chiffre pour l'email.

**Le consentement déduit (à utiliser avec prudence)** n'est admis qu'en présence d'une **relation claire, actuelle ou continue**, et lorsque le produit ou service promu est **directement lié** à cette relation. Si l'une des deux réponses est « non », ne vous fondez pas sur le consentement déduit. **Un achat ponctuel ne crée pas de consentement déduit**, ce qui est conforme à la lecture étroite de longue date de l'ACMA et à l'affaire néo-zélandaise Trade Me ci-dessus.

**Tenue de registres.** L'expéditeur doit conserver une trace fiable de la **méthode** de consentement, de ses **conditions** et de la **date et l'heure** de son obtention. Externaliser auprès d'un prestataire de marketing ou d'un ESP ne **transfère pas** cette responsabilité : « vous restez chargé de vous assurer… que votre prestataire externe » (*"you remain responsible for ensuring... your outsourced service provider"*) conserve aussi ces registres. Cela renforce le principe du Spam Act selon lequel vous ne pouvez pas externaliser votre risque ([australia-spam-act.md](https://emailmarketing.net/fr/apprendre/conformite/australie-spam-act-2003-et-application-par-l-acma#2-identification-de-lexpéditeur-s-17)).

**Enseignements pour un ESP :**
- Les formulaires de recueil du consentement pour le trafic australien devraient afficher les quatre informations obligatoires **à côté de la case à cocher**, et non dans une politique accessible par un lien. C'est la contrainte de conception que signale l'ACMA.
- Prévoyez l'**expiration du consentement** : considérez les consentements anciens comme périmés, et redemandez la permission plutôt que d'écrire indéfiniment. Le chiffre de 3 mois pour le télémarketing est la durée la plus claire que l'**ACMA** ait fixée pour la fraîcheur, mais il vaut précisément pour le **consentement au télémarketing en Australie** et ne constitue pas un repère universel. La fréquence de renouvellement du consentement dépend de la juridiction et du canal (ICO environ 2 ans, CNIL environ 6 mois, ACMA environ 3 mois). [Conservation des preuves de consentement](https://emailmarketing.net/fr/apprendre/conformite/conservation-des-preuves-de-consentement#gérer--réexaminer-régulièrement-le-consentement) compare ces chiffres.
- Conservez les métadonnées du consentement (méthode, conditions et horodatage) sous une forme que le client peut produire à l'ACMA. L'ESP conserve les registres pour le compte du client, mais le client reste responsable. Ces métadonnées vont avec les métadonnées d'acquisition décrites dans [Intégrité de l'acquisition d'adresses](https://emailmarketing.net/fr/apprendre/gestion-des-listes/integrite-de-l-acquisition-des-adresses#acquisition-metadata-to-capture-at-signup).

## France : les règles de la CNIL pour la transmission de données B2C à des partenaires

La CNIL a publié des lignes directrices sur la **transmission de données personnelles de consommateurs à des partenaires pour leur propre prospection**. Elles répondent à une question que [France : les règles de la CNIL](https://emailmarketing.net/fr/apprendre/conformite/france-regles-de-la-cnil-sur-la-prospection-par-email) soulève sans la détailler : si une entreprise française peut transmettre les données d'un abonné à des tiers, et comment. La règle dépend du **canal que le partenaire utilisera**, car la base légale diffère.

### Le partenaire utilisera le courrier postal : intérêt légitime

L'entreprise qui transmet les données peut les partager pour la prospection **postale** d'un partenaire sur la base de son **intérêt légitime**, à condition que :
- les personnes aient été **informées lors de la collecte** de la transmission, de ses objectifs et des **catégories de partenaires** ; et
- un **opt-out simple et gratuit** soit proposé à la fois lors de la collecte et à tout moment ensuite.

La CNIL recommande, comme bonne pratique, de fournir une **liste exhaustive et à jour des partenaires** par leur identité, avec des liens vers leurs politiques de confidentialité. Au minimum, indiquez leur secteur d'activité, les types de contacts et le nombre approximatif de partenaires.

### Le partenaire utilisera l'email, le SMS ou les appels automatisés : consentement préalable

La prospection électronique relève de l'opt-in ([article L. 34-5 du CPCE](https://emailmarketing.net/fr/apprendre/conformite/france-regles-de-la-cnil-sur-la-prospection-par-email#b2c--consentement-préalable-obligatoire)), donc le partage de données pour la prospection **électronique** d'un partenaire exige un **consentement préalable explicite**. Deux schémas sont admis.

**Scénario 1 : l'entreprise qui collecte recueille d'emblée le consentement pour la prospection des partenaires.** La personne doit savoir clairement **quels partenaires** la contacteront, donc une **liste exhaustive des partenaires** est fournie au moment du consentement. Une **case à cocher unique** peut couvrir à la fois la transmission des données et la prospection des partenaires, par exemple : *« J'accepte que mon adresse email soit transmise aux partenaires [lien] de la société X à des fins de prospection commerciale. »*

**Scénario 2 : l'entreprise transmet les données sans recueillir de consentement à la prospection.** Dans ce cas, chaque **partenaire doit obtenir son propre consentement** avant de prospecter. Le premier contact du partenaire ne peut reposer sur l'**intérêt légitime** que si la personne a reçu au préalable une information suffisante sur l'étendue des sollicitations et sur les catégories de partenaires, et si le partenaire **limite la fréquence de ses contacts** afin d'éviter toute nuisance.

**Deux limites strictes :**
- **Le consentement ne se transmet pas en cascade.** Le consentement obtenu par un partenaire ne s'étend **pas** aux propres partenaires de celui-ci. Chaque acteur doit recueillir séparément le consentement pour toute transmission ultérieure. C'est le principe selon lequel « le consentement n'est pas transférable », tiré de l'[acquisition d'adresses](https://emailmarketing.net/fr/apprendre/gestion-des-listes/integrite-de-l-acquisition-des-adresses#the-core-principle-consent-is-not-transferable), appliqué à une chaîne.
- **Le partenaire destinataire doit informer la personne dans un délai d'un mois** à compter du premier contact, en indiquant notamment l'**identité de l'entreprise source** et les droits de la personne en matière de consentement et d'opposition (l'exigence de transparence de l'article 14 du RGPD).

**Enseignements pour un ESP :**
- Une formule comme « partagé avec nos partenaires » n'est valable pour la prospection électronique **que** si la liste des partenaires est exhaustive et présentée au moment du consentement. Le schéma d'affiliation et de co-inscription critiqué dans [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement) est exactement ce que la CNIL restreint.
- Un ESP qui intègre une liste française constituée à partir de données transmises par des partenaires devrait vérifier **quel scénario** l'a produite : une preuve de consentement du scénario 1, ou une chaîne du scénario 2 dans laquelle cet expéditeur a recueilli son propre consentement. Une affirmation générale de « consentement partenaire », sans preuve qu'une liste exhaustive a été présentée lors de la collecte, n'est pas défendable.
- L'obligation du partenaire destinataire d'**indiquer la source dans un délai d'un mois** est une tâche concrète que le parcours de bienvenue ou de premier contact de l'ESP doit prendre en charge pour les contacts français issus de partenaires.

## Voir aussi

- [Australie : le Spam Act](https://emailmarketing.net/fr/apprendre/conformite/australie-spam-act-2003-et-application-par-l-acma), avec les règles de désabonnement et le bilan complet des sanctions de l'ACMA
- [France : les règles de la CNIL](https://emailmarketing.net/fr/apprendre/conformite/france-regles-de-la-cnil-sur-la-prospection-par-email), avec les règles de la prospection B2C et B2B et la recommandation de 2026 sur les pixels de suivi
- [Lois sur l'email en Asie-Pacifique](https://emailmarketing.net/fr/apprendre/conformite/lois-sur-le-marketing-par-email-en-asie-pacifique), sur le consentement et les sanctions de l'Unsolicited Electronic Messages Act néo-zélandais
- [Application des lois sur l'email](https://emailmarketing.net/fr/apprendre/conformite/application-des-lois-sur-l-email-lcap-et-can-spam), sur l'application de la LCAP et de CAN-SPAM, la responsabilité des intermédiaires et la collecte d'adresses comme violation aggravée
- [Intégrité de l'acquisition d'adresses](https://emailmarketing.net/fr/apprendre/gestion-des-listes/integrite-de-l-acquisition-des-adresses)
- [Méthodes de consentement et échelle de qualité des listes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement)
- [Vérification des clients](https://emailmarketing.net/learn/esp-operations/customer-vetting), sur le filtrage des clients dont les pratiques d'acquisition ou de consentement ne sont pas documentées

# France : les règles de la CNIL sur la prospection par email et la recommandation sur les pixels de suivi

> Les règles de la CNIL pour l'email commercial (opt-in en B2C, exception pour les clients existants, critère du rapport avec la profession en B2B) et la recommandation de 2026 qui soumet la plupart des pixels de suivi dans les emails au consentement, y compris l'exemption pour la mesure de la délivrabilité que tout ESP doit connaître.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/france-regles-de-la-cnil-sur-la-prospection-par-email

Si vous envoyez des emails commerciaux à des personnes en France, ou si vous suivez les ouvertures des messages destinés à des destinataires français, les règles à respecter viennent du droit français et de son autorité de contrôle. La France transpose la règle de la directive ePrivacy sur le marketing par email à l'**article L.34-5 du Code des postes et des communications électroniques (CPCE)**, et sa règle sur l'équipement terminal (cookies et pixels) à l'**article 82 de la loi Informatique et Libertés**. L'autorité de contrôle est la **CNIL**.

Comme le [PECR britannique](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email) et la [LCAP](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel), la France applique un régime d'**opt-in** pour les consommateurs. Elle a toutefois un critère propre, le « rapport avec la profession », pour les emails entre entreprises (B2B), là où le Royaume-Uni exempte les abonnés personnes morales. Depuis 2026, elle a aussi une règle phare pour les fournisseurs de services de messagerie (ESP) : **la plupart des pixels de suivi des ouvertures dans les emails nécessitent le consentement du destinataire**.

**Ceci n'est pas un avis juridique.** Vérifiez les seuils et les délais auprès des sources primaires (ci-dessous) et d'un conseil avant de vous y fier. Voir la [présentation de la conformité](https://emailmarketing.net/fr/apprendre/conformite).

## Typologie des messages

La CNIL distingue trois types de messages, et le classement détermine les règles applicables :

| Type | Définition | Base légale |
|---|---|---|
| **Prospection commerciale** | Promeut des produits, des services ou l'image de l'entreprise | Consentement (B2C), avec les exceptions ci-dessous |
| **Transactionnel** | Nécessaire à la gestion du contrat ou du service : confirmations, alertes, réinitialisations de mot de passe | Exécution du contrat, ou intérêt légitime |
| **Relationnel** | Suivi sans finalité promotionnelle directe : conseils d'utilisation, gestion du compte | Intérêt légitime |

Les messages transactionnels et relationnels ne doivent **pas contenir de contenu promotionnel significatif**. Y ajouter du contenu commercial requalifie le message en prospection et déclenche les règles de consentement. (Le principe est le même que le critère de l'objet principal de CAN-SPAM, mais la conséquence est ici l'opt-in.)

## B2C : consentement préalable obligatoire

La prospection commerciale par email ou par SMS auprès de particuliers (entre une entreprise et des consommateurs, ou B2C) exige un **consentement préalable** (art. L.34-5 du CPCE) conforme à la norme de l'article 4, point 11, du RGPD : libre, spécifique, éclairé, univoque, et exprimé par un **acte positif et spécifique**.

- **Les cases précochées sont interdites.** Le mécanisme recommandé est une case à cocher décochée par défaut.
- L'acceptation des conditions générales ne peut pas tenir lieu de consentement.
- Le consentement peut être retiré à tout moment.
- Références juridiques : RGPD, article 4, point 11 (définition), article 6 (bases légales), article 7 (conditions applicables au consentement), article 21 (droit d'opposition) ; CPCE, articles L.32 et L.34-5.

### Exception 1 : clients existants et produits ou services analogues

Aucun consentement préalable n'est nécessaire pour prospecter un **client existant** au sujet de **produits ou services analogues fournis par la même entreprise**, à condition que :

1. la personne ait été informée, **au moment de la collecte de son adresse**, que celle-ci serait utilisée à des fins de prospection pour des produits ou services analogues ; et
2. elle ait pu s'y opposer, simplement et gratuitement, **lors de la collecte et dans chaque message ultérieur**.

Les limites que souligne la CNIL :

- **Une vente ou une prestation de service effectuée est nécessaire** : « cette exception ne peut pas être mobilisée lorsqu'aucune vente ou prestation de service n'a été effectuée ». La simple création d'un compte (par exemple l'ouverture d'un compte sur un site marchand sans commande) ne confère **pas** la qualité de client, et le consentement est donc requis.
- **Cour de justice de l'Union européenne (CJUE), 13 novembre 2025 (Inteligo Media)** : le titulaire d'un compte gratuit sur un site d'information qui reçoit une newsletter faisant la promotion d'abonnements payants peut relever de l'exception des clients existants. Un service gratuit qui ouvre une relation client peut compter.
- **Exemples de produits analogues** : l'acheteur de billets de train qui reçoit des offres de services de transport analogues relève de l'exception (avec une possibilité d'opposition). Une réservation d'hôtel utilisée pour envoyer des offres d'une **compagnie aérienne partenaire** n'en relève **pas** (autre entreprise, autres produits), et le consentement est donc requis.

### Exception 2 : prospection non commerciale (associations caritatives et assimilées)

Les associations caritatives et les organismes comparables peuvent prospecter sur la base de l'**intérêt légitime** plutôt que du consentement, à condition que la personne ait été informée lors de la collecte que ses coordonnées seraient utilisées pour de la « prospection non commerciale », et qu'elle dispose d'un moyen simple et gratuit de s'y opposer, lors de la collecte comme dans chaque message.

## B2B : le critère du rapport avec la profession

La prospection par email auprès de professionnels n'exige **pas** systématiquement de consentement. La base légale est l'**intérêt légitime**, sous trois conditions :

1. le message est **en rapport avec la profession de la personne démarchée**. Dans l'exemple de la CNIL, proposer un logiciel au directeur informatique d'une entreprise répond à ce critère ;
2. la personne a été **informée** que ses coordonnées pourraient être utilisées à des fins de prospection, ainsi que de l'origine des données et de l'objet du message. Cette information a lieu lors de la collecte ou, pour les données déjà détenues ou acquises auprès de tiers, de manière vérifiable ;
3. un **moyen simple et gratuit de s'opposer** est proposé.

Les **adresses génériques d'organisation** (info@company.fr, contact@company.fr, commande@company.fr) concernent des personnes morales et non des personnes physiques, et échappent **entièrement** à ces règles de consentement et d'opposition. Avec le PECR britannique, en revanche, les adresses de rôle des abonnés personnes morales sont elles aussi exemptées de la règle du consentement, mais les obligations d'identifier l'expéditeur et de proposer un opt-out s'appliquent toujours. Voir [Pays-Bas et la question du B2B](https://emailmarketing.net/fr/apprendre/conformite/pays-bas-et-la-question-du-b2b) pour la comparaison entre pays.

## Exigences générales (toute prospection)

- Identifier clairement l'organisme expéditeur.
- Proposer un mécanisme de désabonnement simple dans chaque message.
- Respecter les oppositions **de façon permanente**. La CNIL recommande une **liste repoussoir** (le terme de la CNIL pour une liste de suppression) pour éviter toute nouvelle sollicitation (la même architecture que dans [RGPD et listes de suppression](https://emailmarketing.net/fr/apprendre/conformite/rgpd-et-listes-de-suppression-des-esp)).
- Répondre aux demandes des personnes concernées qui exercent leurs droits (accès, rectification, opposition, effacement) **dans un délai d'un mois au maximum**.
- Fournir l'information prévue par le RGPD lors de la collecte.
- Un manquement peut faire l'objet d'une plainte auprès de la CNIL, et les SMS indésirables peuvent être signalés à la plateforme **33700**.

La liste de contrôle de la CNIL pour les expéditeurs : classer le type de message ; vérifier que les messages transactionnels et relationnels ne contiennent pas de promotion significative ; déterminer la base légale ; informer les personnes lors de la collecte ; valider le consentement lorsqu'il est requis ; proposer l'opposition lors de la collecte et dans chaque message ; tenir à jour la liste repoussoir ; encadrer les prestataires ; sécuriser les données ; définir des durées de conservation ; et tout documenter.

---

# La recommandation de la CNIL sur les pixels de suivi (2026)

**Délibération n° 2026-042, adoptée le 12 mars 2026, publiée le 14 avril 2026** (la consultation publique s'est tenue du 12 juin au 24 juillet 2025). C'est le premier corpus de règles opérationnelles publié par une autorité de contrôle pour les pixels de suivi des ouvertures dans les emails, et il encadre directement la façon dont les ESP qui servent des destinataires français peuvent suivre les ouvertures. Elle applique l'article 82 de la loi Informatique et Libertés (la transposition française de l'article 5, paragraphe 3, de la directive ePrivacy), dans le prolongement des **lignes directrices 2/2023 du Comité européen de la protection des données (CEPD)** sur le champ d'application technique de la directive ePrivacy, qui ont confirmé que ces dispositions s'appliquent aux pixels insérés dans les emails.

**Pourquoi les pixels sont concernés** : le pixel est une image hébergée à distance dont l'URL comporte des paramètres individualisés. Son affichage conduit le terminal du destinataire à renvoyer des informations ciblées (l'identifiant du pixel, l'adresse IP, etc.) à l'acteur qui l'a déposé. Cette collecte constitue une **opération de lecture sur le terminal de l'utilisateur**, ce qui déclenche l'article 82. La recommandation ne vise que l'email ; les messageries fermées, comme les messageries des banques, reposent sur d'autres protocoles et sont hors champ. Elle n'est pas réglementaire, mais la CNIL a annoncé des webinaires et veillera à son respect **dans le cadre de ses contrôles**.

## Qui est responsable (rôles au sens du RGPD)

| Acteur | Qualification |
|---|---|
| **Expéditeur de l'email** (la marque qui a décidé l'envoi) | **Responsable du traitement**, même lorsque le suivi est sous-traité. En principe, il est **responsable conjoint** des opérations de lecture et d'écriture réalisées par des tiers qu'il accepte contractuellement dans ses emails |
| **Prestataire de service d'emailing** (l'ESP : la solution technique d'envoi, qui propose en général la fonction de pixel) | **Sous-traitant**, agissant sur instruction du responsable du traitement |
| **Prestataire de location de listes et d'envoi** (campagnes « clés en main » vers des listes louées) | Au cas par cas : **sous-traitant en principe**. S'il utilise aussi les pixels pour ses propres finalités (améliorer la pertinence de ses listes, ou sa propre délivrabilité auprès des fournisseurs de messagerie) et que le client l'accepte contractuellement, la **responsabilité conjointe du traitement** s'applique (article 26 du RGPD, qui exige une répartition claire des obligations en matière d'information et de droits) |
| **Fournisseur de la technologie de suivi** (un fournisseur tiers de pixels) | **Sous-traitant** s'il agit uniquement pour l'expéditeur ; **responsable conjoint du traitement** s'il utilise aussi les données pour ses propres finalités (par exemple l'amélioration de son produit) avec l'accord contractuel du client |
| **Fournisseur de messagerie** (reçoit et affiche les emails, et peut bloquer le chargement des images) | **Ni responsable du traitement ni sous-traitant**, car il n'utilise pas les données du pixel |

C'est l'un des rares textes d'une autorité de contrôle qui nomme explicitement le rôle de l'ESP. Un ESP qui réutilise les données d'ouverture de ses clients pour ses propres optimisations devient responsable conjoint du traitement.

## Finalités soumises au consentement

Un consentement préalable libre, spécifique, éclairé et univoque est requis pour les pixels utilisés pour :

- **l'analyse du taux d'ouverture pour mesurer et optimiser les performances des campagnes** : personnaliser le contenu, adapter la fréquence d'envoi ou changer de canal (email, SMS, notification push). Cela inclut les procédés de fiabilisation, comme la lutte contre la fraude publicitaire ;
- **la création de profils de destinataires** à partir des préférences et centres d'intérêt observés, pour les cibler **en dehors de l'email** (sites web, applications mobiles, autres canaux) ;
- **la détection et l'analyse de suspicions de fraude** (par exemple des ouvertures inhabituelles ou massives révélant une automatisation : inscriptions massives à un jeu concours, tentatives d'exfiltration) ;
- **la mesure individuelle du taux d'ouverture à des fins de délivrabilité** lorsqu'elle est réalisée **en dehors du périmètre exempté ci-dessous**.

## Finalités exemptées de consentement

Les pixels utilisés **exclusivement** pour les finalités suivantes peuvent fonctionner sans consentement :

1. **Les mesures de sécurité participant à l'authentification de l'utilisateur** : par exemple, s'assurer que l'email contenant un code d'authentification a bien été ouvert sur un terminal connu pour appartenir à l'utilisateur visé.
2. **La mesure individuelle du taux d'ouverture à des fins de délivrabilité.** La CNIL admet que la gestion d'une liste de diffusion « requiert presque systématiquement » des statistiques d'ouverture pour repérer les problèmes de délivrabilité. Le responsable du traitement doit toutefois démontrer que les opérations se limitent à ce qui est strictement nécessaire pour **adapter la fréquence des envois aux destinataires dits « inactifs », ou les arrêter (nettoyage des bases)**. Dans cette limite, les données du pixel peuvent aussi servir à :
   - évaluer et adapter le canal de communication (choisir d'autres moyens de contacter la personne) ;
   - contribuer à démontrer le respect d'une obligation légale de transmission d'informations (preuve que les informations exigées par la loi avant ou après la conclusion du contrat ont bien été délivrées).

**Contrainte de minimisation** : en principe, seule la **date de la dernière ouverture connue devrait être conservée, à la journée et sans l'heure, mise à jour à chaque nouvelle ouverture avec suppression de la date précédente**.

**Limite de périmètre des exemptions** : parce que l'exemption de l'article 82 repose sur la « demande expresse » de l'utilisateur, les exemptions ne s'appliquent qu'aux emails **demandés par le destinataire ou rattachés à un service qu'il a demandé**, c'est-à-dire aux **emails transactionnels** ou aux emails que le destinataire a consenti à recevoir. La recommandation définit les emails transactionnels comme des messages déclenchés par une action ou un événement propre à l'utilisateur, informatifs ou fonctionnels, et nécessaires à la relation contractuelle : emails de bienvenue, alertes de compte, notifications d'expédition, confirmations de commande et factures, rappels et réinitialisations de mot de passe, réponses du service client, rappels de rendez-vous ou de réservation, notifications de paiement, et notifications de violation liées au service demandé. Les pixels des emails de l'**administration** envoyés dans le cadre d'une mission de service public (y compris l'information proactive sur les droits) relèvent eux aussi des exemptions.

**Réutilisation de données anonymisées** : une fois les données collectées par un pixel effectivement anonymisées, leur réutilisation ne nécessite aucun consentement (le traitement d'anonymisation lui-même reste soumis au RGPD).

**Conséquence pratique pour les ESP** : un suivi généralisé des ouvertures de chaque destinataire, destiné à des tableaux de bord d'engagement, à l'optimisation de l'heure d'envoi ou au déclenchement d'automatisations, exige le consentement pour les destinataires français. Un suivi des ouvertures dont le seul résultat conservé est une date unique de dernière ouverture, utilisée pour appliquer des [politiques de mise en sommeil et d'inactivité](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil), peut être exempté sur les emails transactionnels et consentis. **Le régime du consentement des pixels est indépendant de celui de l'email lui-même** : le consentement aux pixels peut être nécessaire dans des emails qui n'exigent eux-mêmes aucun consentement (confirmations de commande, prospection pour des produits analogues, prospection caritative, prospection B2B en rapport avec la profession).

## Recueillir le consentement aux pixels

- **Présentez les finalités une par une** : chaque finalité devrait porter un intitulé court et un bref descriptif. La CNIL fournit des modèles de formulation :
  <!-- glossary-allow: courriel -->
  - pour la délivrabilité : « [Nom de l'expéditeur des courriels] et [des sociétés tierces] utilisent des traceurs (pixels de suivi) pour savoir si vous ouvrez les courriels et la date à laquelle vous le faites afin d'établir des statistiques de diffusion et entreprendre les actions (adaptation de la fréquence ou arrêt des envois) nécessaires à la gestion des listes de diffusion » ;
  <!-- glossary-allow: courriel -->
  - pour la performance des campagnes : « […] pour savoir si vous ouvrez les courriels, l'heure à laquelle vous le faites ainsi que des informations sur le terminal que vous utilisez afin de personnaliser le contenu des messages, adapter la fréquence d'envoi ou le canal de communication utilisé ».

  Le profilage dans d'autres contextes et la détection de la fraude ont des modèles analogues. Les descriptions détaillées devraient être accessibles depuis l'interface de recueil du consentement, par un bouton de déroulement ou un lien hypertexte au premier niveau.
- Bonne pratique : mentionner dans la politique de confidentialité même les pixels exemptés de consentement.
- **Clarté du périmètre** : le destinataire doit pouvoir identifier **l'adresse email** concernée par les pixels, et comprendre que les traceurs fonctionneront sur **tous les terminaux** sur lesquels il consulte cette boîte.
- **Moment à privilégier** : recueillez le consentement aux pixels **au moment de la collecte de l'adresse email elle-même**, en ajoutant au formulaire d'inscription le résumé des finalités (avec un lien vers la politique relative aux traceurs).
- **Recueil a posteriori** : lorsque le consentement n'a pas été recueilli avec l'adresse (ou que l'adresse vient d'un tiers sans preuve du consentement aux pixels, ou a été recueillie à l'oral), envoyez un **email sans pixel** contenant un lien vers une interface de recueil du consentement. Le lien doit mener à une page qui exige une **action positive** (un clic sur un bouton), afin que le préchargement automatique des liens par certains clients de messagerie ne puisse pas enregistrer un consentement fantôme. C'est la même protection que pour les points de terminaison du [désabonnement en un clic](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic). Utilisez un **lien de suivi propre à chaque destinataire**, afin que seul le titulaire de l'adresse puisse exprimer son choix. Ces liens servent la sécurité et l'authentification de l'utilisateur, et sont eux-mêmes exemptés de consentement au titre de l'article 82.
- **L'inactivité vaut refus.** L'absence de réponse à une demande de consentement doit être traitée comme un refus, et la demande ne doit ni exercer de pression sur les destinataires ni gêner la lecture. Proposez une option « refuser » explicite, aussi simple que « accepter », enregistrez le choix, et ne sollicitez plus la personne pendant un certain temps : **l'absence de nouvelle sollicitation pendant 6 mois est citée comme une bonne pratique**. (Ce délai de 6 mois est un intervalle avant une nouvelle sollicitation qui s'applique spécifiquement au consentement aux pixels, et non une règle générale sur la fraîcheur du consentement. Pour le comparer avec les durées de fraîcheur d'autres juridictions, voir [Conservation des preuves de consentement](https://emailmarketing.net/fr/apprendre/conformite/conservation-des-preuves-de-consentement#gérer--réexaminer-régulièrement-le-consentement).)
- **Granularité** : le consentement devrait être demandé séparément pour chaque finalité. Une interface à deux niveaux (une acceptation globale au premier niveau, et des choix par finalité au second) est admise. Un **consentement unique** peut couvrir à la fois la prospection directe par voie électronique (art. L.34-5) et les pixels qui servent des finalités **connexes** : par exemple une prospection expressément présentée comme personnalisée et les pixels qui la personnalisent, ou des emails de jeu concours et des pixels antifraude. Les finalités non connexes exigent des consentements distincts, et **la publicité display et la prospection par email sont toujours des finalités distinctes**.
- **Prudence avec les plateformes de gestion du consentement (CMP)** : recueillir le consentement aux pixels au moyen d'une CMP sur un site web ou dans une application est possible, mais demande une attention particulière. La personne doit comprendre que son choix concerne un autre environnement (sa messagerie), et quelle adresse est concernée.

## Retrait

- Proposez le retrait au moyen d'un **lien de suivi dans le pied de page de chaque email**. Retirer son consentement doit être aussi simple que le donner.
- Si le lien ouvre une page web, le retrait doit s'effectuer **sans aucune action supplémentaire**, notamment sans avoir à saisir de nouveau l'adresse email.
- Le retrait doit être **effectif** : les emails à venir ne doivent plus déclencher les opérations et, pour les emails déjà envoyés, l'expéditeur peut devoir prendre des mesures pour que les pixels insérés auparavant ne soient plus exploités lorsqu'un message est rouvert.

## Preuve du consentement

- Le responsable du traitement doit pouvoir démontrer le consentement à tout moment (article 7, paragraphe 1, du RGPD) au moyen de **traces individualisées** du consentement de chaque personne et des conditions dans lesquelles il a été obtenu.
- Lorsqu'un tiers a collecté l'adresse et le consentement, **une clause contractuelle obligeant le partenaire à recueillir un consentement valable ne constitue pas une preuve suffisante**. Le contrat peut en revanche encadrer les mécanismes de recueil du consentement, la mise à disposition des éléments de preuve pour l'organisme qui s'en prévaut, les conditions de conservation des preuves pour qu'elles gardent leur valeur probante, et les **audits réguliers des mécanismes de recueil du consentement**. Les engagements contractuels n'exonèrent pas le responsable du traitement de sa responsabilité s'il ne peut pas produire la preuve.

## Transition pour les listes existantes

Pour les adresses collectées avant la publication, le suivi peut se poursuivre **uniquement si une information claire et accessible est envoyée aux destinataires dans un délai de 3 mois au plus à compter de la publication de la recommandation**, afin que toute personne dont le consentement n'a pas été valablement recueilli puisse s'opposer à ces opérations pour les emails futurs. Lorsqu'un nouveau consentement est de toute façon nécessaire (par exemple pour transmettre les données à de nouveaux responsables du traitement à des fins de prospection), un consentement valable aux pixels doit être recueilli pour les opérations non exemptées.

## Enjeux pour la délivrabilité

La France est la première juridiction à encadrer en détail les mécanismes du suivi des ouvertures, et elle aboutit à la position que les praticiens de la délivrabilité avaient déjà atteinte pour des raisons techniques. Les données d'ouverture ne sont pas fiables (Apple Mail Privacy Protection précharge les pixels, et Gmail fait passer les images par un proxy), et leur usage opérationnel légitime est l'**hygiène de base de données**, précisément la finalité que la CNIL exempte. Les ESP devraient traiter l'analyse des ouvertures de chaque destinataire français comme une fonction soumise au consentement, conserver une date minimale de dernière ouverture pour les [politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil), et privilégier les signaux de clic et de conversion pour mesurer l'engagement. Pour la position britannique, voir le [PECR](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email) : les pixels y relèvent aussi des règles sur le stockage et l'accès, mais il n'existe pas (encore) de recommandation opérationnelle équivalente.

# L'ESP sous-traitant au sens du RGPD : rôles, contrat de sous-traitance, transferts

> Les obligations propres de l'ESP au regard du RGPD : les rôles de responsable du traitement et de sous-traitant selon les lignes directrices 07/2020 du CEPD, les clauses de l'article 28 que doit proposer le contrat de sous-traitance (DPA) d'un ESP, les règles applicables aux sous-traitants ultérieurs, les transferts internationaux (CCT 2021/914, cadre de protection des données UE–États-Unis 2023/1795) et le traitement des demandes des personnes concernées en tant que sous-traitant.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/l-esp-sous-traitant-au-sens-du-rgpd

> **Ceci n'est pas un avis juridique.** Synthèse de référence, à l'intention des exploitants d'ESP, des lignes directrices 07/2020 du CEPD (v2.1, adoptées le 7 juillet 2021), de l'article 28 du RGPD et des instruments de la Commission européenne pour les transferts internationaux. Consultez un conseil lorsque vous rédigez des contrats.

Si vos clients importent des listes de destinataires dans votre ESP et envoient des campagnes par son intermédiaire, vous traitez des données personnelles (adresses email, noms, événements d'engagement) **pour le compte** de ces clients. Au regard du RGPD, le client est alors **responsable du traitement** et l'ESP **sous-traitant**. Un sous-traitant a des obligations qui s'appliquent directement à lui, et pas seulement par le contrat.

Les obligations ci-dessous sont celles qui s'appliquent au niveau de la plateforme. Les règles relatives au contenu et à l'envoi des emails de marketing figurent dans [Directive ePrivacy et RGPD](https://emailmarketing.net/fr/apprendre/conformite/directive-eprivacy-et-rgpd-marketing-par-email).

## Rôles (lignes directrices 07/2020 du CEPD)

Les notions sont **fonctionnelles**, car elles suivent les rôles que les parties jouent réellement plutôt que des étiquettes, et **autonomes**, car c'est le droit de l'UE qui les définit, et non le contrat. Les définitions :

- **Responsable du traitement** : détermine les **finalités et les moyens** (le « pourquoi » et le « comment ») du traitement. Il doit décider des deux, mais peut laisser au sous-traitant les « moyens non essentiels », comme la mise en œuvre pratique (choix du matériel ou des logiciels) et le détail des mesures de sécurité. Les **moyens essentiels** (quelles données, de quelles personnes, pour combien de temps, qui y a accès) relèvent de la décision du responsable du traitement.
- **Sous-traitant** (article 4(8)) : une **entité distincte** qui traite des données personnelles **pour le compte du responsable du traitement**, c'est-à-dire qu'elle sert les finalités du responsable du traitement selon ses instructions, éventuellement avec une certaine marge d'appréciation sur les choix techniques et organisationnels.

Appliqué à un ESP :

- Pour **les listes de destinataires des clients et les données de campagne et d'engagement**, le client est responsable du traitement et l'ESP est sous-traitant. L'exemple du service cloud donné par le CEPD s'applique exactement. Un service standardisé et mondial reste une relation de sous-traitance, mais le client doit pouvoir imposer ses instructions (durées de conservation, suppression) « indépendamment de ce qui est généralement proposé dans le service standardisé » (*regardless of what is generally offered in the standardized service*).
- **L'article 28(10) fixe la ligne qu'un ESP ne doit jamais franchir.** Un sous-traitant qui utilise les données pour ses propres finalités « enfreint le RGPD en allant au-delà des instructions du responsable du traitement » (*infringes the GDPR by going beyond the controller's instructions*) et devient responsable du traitement pour ce traitement. L'exemple MarketinZ du CEPD est littéralement celui d'un prestataire de services marketing qui a utilisé la base de clients d'un client « à d'autres fins que la publicité pour [le client], par exemple pour développer sa propre activité » (*for other purposes than advertising for [the client], such as developing their own business activity*). Ce changement de rôle constitue en lui-même une infraction. **Un ESP ne doit pas exploiter les listes de ses clients pour son propre marketing, pour des produits d'enrichissement ou pour constituer des audiences communes à plusieurs clients sans disposer de sa propre base légale distincte en tant que responsable du traitement.**
- L'ESP **est responsable du traitement** pour les données des comptes de ses propres clients (facturation, utilisateurs, support), pour son propre marketing, pour l'analyse d'audience de son site web, et pour les opérations de sécurité et de lutte contre les abus qu'il mène pour sa propre conformité et pour protéger son réseau. Une même entité est couramment responsable du traitement pour certains traitements et sous-traitant pour d'autres, et chaque activité est qualifiée séparément.
- **Une zone grise à analyser délibérément** : les systèmes de lutte contre les abus et de réputation qui fonctionnent pour l'ensemble des clients de la plateforme (agrégation des plaintes, [listes de suppression](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic), renseignement sur les adresses pièges). Lorsque l'ESP détermine lui-même les finalités et les moyens de ces traitements, il agit en tant que responsable du traitement pour ceux-ci. Il doit alors identifier sa propre base légale (généralement l'intérêt légitime à protéger son infrastructure et ses autres utilisateurs) et la communiquer, au lieu de prétendre que le traitement suit les instructions d'un seul client.
- **La responsabilité conjointe du traitement** suppose que les parties participent conjointement à la détermination des finalités et des moyens, par des décisions communes ou par des décisions convergentes indissociablement liées. Une relation normale entre un ESP et son client n'est pas une responsabilité conjointe du traitement, et le simple fait d'utiliser la même plateforme ne la crée pas.

## Choix du sous-traitant et forme du contrat

- Le responsable du traitement « fait uniquement appel à des **sous-traitants qui présentent des garanties suffisantes** » (article 28(1)). Ces garanties s'apprécient au regard des **connaissances spécialisées, de la fiabilité et des ressources** du sous-traitant, et sa réputation sur le marché est pertinente. L'application d'un **code de conduite ou d'un mécanisme de certification** approuvé (article 28(5)) peut servir de preuve. Les documents échangés comprennent généralement la politique de confidentialité, les conditions d'utilisation, les registres des activités de traitement, la politique de sécurité, les rapports d'audit externe et les certifications reconnues (par exemple la série ISO 27000). Cette obligation est **continue** : le responsable du traitement vérifie de nouveau périodiquement, y compris par des audits, et pas seulement à la signature. Pour un ESP, cela définit le dossier de diligence raisonnable à tenir prêt pour les grands comptes.
- Le contrat de sous-traitance (DPA) doit être **écrit, y compris sous forme électronique** (article 28(9)), et contraignant. Son absence constitue en elle-même une infraction commise par **les deux** parties. Il peut faire partie d'un accord plus large, mais le CEPD recommande que les éléments de l'article 28 se trouvent en un seul endroit (par exemple une annexe).
- Les parties peuvent rédiger leur propre DPA ou utiliser les **clauses contractuelles types prévues à l'article 28(7)**. La décision d'exécution **(UE) 2021/915 du 4 juin 2021** de la Commission publie un jeu officiel de CCT entre responsable du traitement et sous-traitant, à utiliser **au sein** de l'UE et de l'EEE. Ces clauses sont facultatives, et ce **ne** sont **pas** les mêmes que les CCT de transfert international décrites plus bas.
- **Une mise en garde du CEPD qui vise directement les ESP (¶ 110)** : les sous-traitants qui proposent des conditions standard peuvent les mettre à jour, mais « toute modification proposée par un sous-traitant des accords de traitement de données inclus dans des conditions générales devrait être **directement notifiée au responsable du traitement et approuvée par celui-ci**. La **simple publication de ces modifications sur le site web du sous-traitant n'est pas conforme** à l'article 28 » (*any proposed modification, by a processor, of data processing agreements included in standard terms and conditions should be directly notified to and approved by the controller. The mere publication of these modifications on the processor's website is not compliant with Article 28.*). Quand un ESP modifie son DPA, son processus doit prévoir une notification active des clients.

## Les clauses de l'article 28(3) que doit contenir le DPA d'un ESP

Le contrat doit définir l'**objet, la durée, la nature et la finalité** du traitement, le **type de données personnelles**, les **catégories de personnes concernées** (soyez précis : « abonnés ou destinataires des envois du client », « membres des listes de contacts ») et les **obligations et les droits du responsable du traitement**. Il doit aussi couvrir les points de l'article 28(3)(a) à (h) :

| Clause | Exigence | Remarques de pratique pour un ESP |
|---|---|---|
| a) Instructions documentées | Ne traiter les données que sur instruction documentée du responsable du traitement, **y compris pour les transferts** vers des pays tiers. Une dérogation n'est admise que lorsque le droit de l'UE ou d'un État membre l'exige, avec information préalable du responsable du traitement, sauf si ce droit interdit cette information. | Annexer une procédure ou un modèle d'instructions ; formuler par écrit les instructions ponctuelles (un email suffit). Si les instructions n'autorisent pas les transferts vers des pays tiers, aucun sous-traitant ultérieur ni aucune division de l'ESP hors de l'UE ne peut accéder aux données. |
| b) Confidentialité | Les personnes autorisées à traiter les données sont soumises à une obligation contractuelle ou légale de confidentialité. | Doit couvrir les salariés et les intérimaires ; l'accès est limité au personnel qui en a besoin. |
| c) Sécurité (article 32) | Prendre toutes les mesures requises en vertu de l'article 32. | Le contrat doit inclure ou référencer les mesures concrètes (et non reprendre le RGPD), une obligation d'obtenir **l'approbation du responsable du traitement avant de les modifier**, et un réexamen périodique. Le niveau de détail doit permettre au responsable du traitement de juger si les mesures sont appropriées. |
| d) Sous-traitance ultérieure | Respecter l'article 28(2) et (4). Voir la section suivante. | |
| e) Droits des personnes concernées | Aider le responsable du traitement, par des mesures techniques et organisationnelles appropriées, dans toute la mesure du possible, à répondre aux demandes relevant du chapitre III. | Voir « Demandes des personnes concernées » ci-dessous. |
| f) Assistance au titre des articles 32 à 36 | Aider pour la sécurité, la **notification des violations**, les analyses d'impact relatives à la protection des données (AIPD) et la consultation préalable. | Le sous-traitant doit notifier au responsable du traitement toute violation affectant ses systèmes (ou ceux d'un sous-traitant ultérieur) **dans les meilleurs délais**. Les parties peuvent fixer un délai précis (par exemple **un nombre d'heures**), un point de contact, des modalités et un contenu minimal. Le sous-traitant peut être autorisé à notifier directement l'autorité, mais la responsabilité juridique reste au responsable du traitement. Une obligation d'assistance ne transfère pas la responsabilité : les AIPD restent à l'initiative du responsable du traitement. |
| g) Fin du contrat | Au choix du responsable du traitement, **supprimer ou renvoyer** toutes les données personnelles et détruire les copies existantes, sauf si le droit de l'UE ou d'un État membre en exige la conservation. | Le contrat devrait permettre au responsable du traitement de modifier son choix avant la résiliation, et la suppression sécurisée devrait être confirmée dans un délai convenu. |
| h) Information et audits | Mettre à disposition toutes les informations nécessaires pour démontrer le respect de l'article 28, et **permettre la réalisation d'audits et d'inspections et y contribuer**, par le responsable du traitement ou un auditeur qu'il a mandaté. | Les informations comprennent le fonctionnement des systèmes, les mesures de sécurité, la gestion de la conservation, la localisation des données, les transferts, les accès, les destinataires et les sous-traitants ultérieurs. Le sous-traitant peut proposer un auditeur, mais c'est le responsable du traitement qui décide. Les clauses qui imposent des frais d'audit manifestement disproportionnés, et dissuadent ainsi le responsable du traitement d'exercer ce droit, ne sont pas conformes. |

En outre, le sous-traitant doit **informer immédiatement le responsable du traitement si, selon lui, une instruction constitue une violation** du RGPD ou d'autres dispositions du droit de l'UE ou des États membres relatives à la protection des données (dernière phrase de l'article 28(3)). Le CEPD recommande de prévoir les conséquences dans le contrat : un droit de suspendre l'exécution de l'instruction, ou de résilier si le responsable du traitement persiste. L'ESP dispose ainsi d'une base juridique pour refuser, par exemple, l'instruction d'un client d'écrire à une liste achetée lorsque ce serait un traitement illicite.

Certaines obligations pèsent directement sur le sous-traitant en vertu de la loi, quoi que dise le contrat : le registre des activités de traitement (article 30(2)), la sécurité (article 32), la notification des violations au responsable du traitement (article 33(2)), la désignation d'un délégué à la protection des données (DPO) lorsqu'elle est requise (article 37), les règles de transfert du chapitre V et, pour les sous-traitants établis hors de l'UE qui servent des personnes concernées dans l'UE, la désignation d'un représentant dans l'UE au titre de l'article 27. Les sous-traitants peuvent être sanctionnés directement pour la violation de ces obligations ou pour avoir excédé des instructions licites.

## Sous-traitants ultérieurs

Tout prestataire en aval qui accède aux données de listes ou d'événements pour le compte de l'ESP est un **sous-traitant ultérieur**. Cela comprend les hébergeurs et les fournisseurs d'infrastructure en tant que service (IaaS), les MTA ou passerelles SMS sous-traités, les services de validation, les outils d'analyse et les outils de support :

- Le responsable du traitement doit donner une **autorisation écrite préalable**, qui peut être **spécifique ou générale** (article 28(2)).
  - En cas d'autorisation générale, le modèle praticable pour un ESP multi-locataire, tenez une liste des sous-traitants ultérieurs dans le DPA ou dans une annexe, avec la **localisation, la fonction et la preuve des garanties** de chaque prestataire. **Informez activement** le responsable du traitement de tout ajout ou remplacement envisagé, en désignant chaque nouveau prestataire, et non par « un accès général à une liste susceptible d'être mise à jour de temps à autre » (*generalized access to a list which might be updated from time to time*) (¶¶ 152 à 156 et note 54). Donnez au responsable du traitement une possibilité réelle et un délai raisonnable pour s'y opposer, et prévoyez dans le contrat les mesures pratiques qui suivent une opposition, y compris une éventuelle résiliation. En cas d'autorisation générale, le silence pendant le délai vaut autorisation.
  - En cas d'autorisation spécifique, une demande restée sans réponse vaut **refus**.
- **Les mêmes obligations se répercutent en aval** (article 28(4)). Le contrat du sous-traitant ultérieur doit imposer en substance les mêmes obligations en matière de protection des données que le DPA principal, y compris l'obligation de contribuer aux audits, adaptées au rôle réel du sous-traitant ultérieur. Toute la chaîne doit être couverte par des accords écrits.
- **La pleine responsabilité demeure** : « le premier sous-traitant demeure pleinement responsable devant le responsable du traitement de l'exécution par l'autre sous-traitant de ses obligations » (article 28(4)). Choisissez des sous-traitants ultérieurs qui présentent des garanties suffisantes.

## Demandes des personnes concernées traitées en tant que sous-traitant

Les demandes d'accès, de rectification, d'effacement, de limitation, de portabilité et d'opposition relèvent du **responsable du traitement**, c'est-à-dire le client de l'ESP. Le rôle du sous-traitant (article 28(3)(e), CEPD ¶¶ 130 à 132) :

- **Transmettre rapidement** au client concerné toute demande qu'un destinataire adresse à l'ESP. Cela arrive souvent, lorsqu'un abonné répond à une campagne ou écrit au service abus de l'ESP. Ne répondez pas sur le fond sans instructions.
- **Assister** conformément au contrat. L'assistance va de la simple possibilité donnée au responsable du traitement d'extraire et de gérer les données jusqu'à des obligations techniques précises lorsque le sous-traitant détient les données (outils d'export, API de suppression, extractions de l'activité de chaque destinataire).
- Le **responsable du traitement décide de la recevabilité d'une demande**, et supporte le **délai d'un mois** du chapitre III. Ce délai **n'est pas prolongé** du fait que les informations se trouvent chez le sous-traitant : le DPA devrait donc fixer les délais de réponse internes en conséquence.
- Une exception pratique : les signaux de **désabonnement et d'opposition** doivent continuer de fonctionner opérationnellement, quels que soient les circuits de traitement des demandes des personnes concernées. La suppression est à la fois un [droit absolu au titre de l'article 21](https://emailmarketing.net/fr/apprendre/conformite/directive-eprivacy-et-rgpd-marketing-par-email) et une [exigence de délivrabilité](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic).

## Transferts internationaux (chapitre V du RGPD)

Les transferts hors de l'Espace économique européen (EEE) exigent un mécanisme prévu au chapitre V. Cela comprend les transferts vers l'infrastructure ou les divisions de l'ESP situées hors de l'UE, et vers des sous-traitants ultérieurs hors de l'UE. Voici les mécanismes pertinents pour un sous-traitant :

**1. Décisions d'adéquation (article 45)** : les données peuvent être transférées comme à l'intérieur de l'UE. La liste actuelle : Andorre, Argentine, Brésil (depuis le 26 janv. 2026), Canada (organisations commerciales relevant de la LPRPDE uniquement), îles Féroé, Guernesey, île de Man, Israël, Japon, Jersey, Nouvelle-Zélande, République de Corée, Suisse, Royaume-Uni (renouvelée en décembre 2025), Uruguay, l'Organisation européenne des brevets (15 juil. 2025), et les **États-Unis, limités aux organisations certifiées au titre du cadre de protection des données UE–États-Unis (EU-U.S. Data Privacy Framework)** :

- **La décision d'exécution (UE) 2023/1795 de la Commission du 10 juillet 2023** constate l'adéquation des États-Unis **pour les transferts vers les organisations certifiées au titre du Data Privacy Framework (DPF)**. Le **Department of Commerce des États-Unis** administre la certification et tient une liste publique, et la FTC en assure le respect. Les réclamations peuvent être adressées à l'organisation (qui répond sous 45 jours), à un mécanisme indépendant de règlement des litiges, aux autorités de protection des données et, en dernier ressort, à un arbitrage contraignant. La décision repose sur l'**Executive Order 14086**, qui impose des limites de nécessité et de proportionnalité au renseignement d'origine électromagnétique, et sur le mécanisme de recours de la **Data Protection Review Court**. Ce sont les corrections apportées après l'arrêt Schrems II, qui avait invalidé le Privacy Shield.
- **État des recours (vérifié en juillet 2026)** : le DPF a résisté à sa première contestation juridictionnelle. Dans l'affaire *Latombe c. Commission* (affaire T-553/23), le **Tribunal de l'Union européenne a rejeté le recours en annulation le 3 septembre 2025** et confirmé la décision d'adéquation. Il a jugé la Data Protection Review Court suffisamment indépendante et impartiale, et les limites américaines à la collecte en masse, ainsi que les voies de recours disponibles, substantiellement équivalentes aux normes de l'UE. **La décision d'adéquation reste donc valable en juillet 2026.** M. Latombe a formé un pourvoi devant la Cour de justice (CJUE) le 31 octobre 2025, et une nouvelle décision est donc attendue. Un ESP ou un sous-traitant ultérieur établi aux États-Unis qui s'appuie sur le DPF devrait continuer de surveiller sa certification et le pourvoi en cours.

**2. Clauses contractuelles types (article 46(2)(c))** : la **décision d'exécution (UE) 2021/914 de la Commission du 4 juin 2021**, en vigueur depuis le 27 juin 2021. C'est un document unique en quatre modules :

| Module | Transfert |
|---|---|
| Un | Du responsable du traitement au responsable du traitement |
| Deux | Du responsable du traitement au sous-traitant (d'un client dans l'UE vers un ESP hors UE) |
| Trois | Du sous-traitant au sous-traitant (d'un ESP dans l'UE vers un sous-traitant ultérieur hors UE) |
| Quatre | Du sous-traitant au responsable du traitement |

Le fonctionnement des clauses :

- Les anciennes décisions relatives aux CCT (2001/497/CE et 2010/87/UE) ont été abrogées le 27 septembre 2021. Les contrats conclus sur leur base sont restés valables jusqu'au **27 décembre 2022** si le traitement était inchangé.
- Une **clause d'adhésion (clause 7)** permet à de nouvelles parties d'adhérer ultérieurement.
- La **clause 14** met en œuvre l'arrêt Schrems II. Les parties doivent évaluer si la législation et les pratiques du pays de destination empêchent le respect des clauses, documenter une **analyse d'impact des transferts** et appliquer des **mesures supplémentaires** (techniques, organisationnelles ou contractuelles) si nécessaire.
- Les modules deux et trois tiennent aussi lieu de DPA conforme à l'article 28 pour la relation de transfert : aucun DPA distinct au titre de la décision 2021/915 n'est donc nécessaire pour la même relation.

**3. Autres garanties de l'article 46** : règles d'entreprise contraignantes (au sein d'un groupe), codes de conduite approuvés et mécanismes de certification. Les **dérogations de l'article 49** (consentement explicite, nécessité contractuelle, etc.) sont réservées aux transferts occasionnels et non répétitifs, et ne peuvent pas fonder les flux de données courants d'un ESP.

Le chapitre V s'impose **aux sous-traitants comme aux responsables du traitement**. Un ESP établi dans l'UE est lui-même exportateur de données vis-à-vis de ses sous-traitants ultérieurs hors de l'UE, et doit avoir mis en place des CCT du module trois (ou un autre mécanisme), conformément aux instructions documentées du responsable du traitement en matière de transferts.

## Enjeux pour la délivrabilité

La discipline du sous-traitant et celle de la délivrabilité mènent au même endroit :

- Les instructions documentées, et l'obligation de refuser les instructions illicites, sont le fondement de conformité pour [vérifier les clients](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs) et pour [refuser les listes achetées](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement).
- Les processus de notification des violations recoupent les voies d'escalade du service abus qu'attendent les fournisseurs.
- Garder des rôles nettement séparés, et ne jamais exploiter les listes des clients pour les propres finalités de l'ESP, est aussi ce qui tient un ESP à l'écart de la catégorie de réputation des courtiers en données, que surveillent à la fois les autorités et [Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus).

# La réglementation d'application de CAN-SPAM (16 CFR Part 316)

> Le détail réglementaire de la FTC derrière CAN-SPAM : les définitions codifiées de l'expéditeur, de l'objet principal et de l'adresse postale valide, le critère de désignation d'un expéditeur unique, la responsabilité des messages « transférer à un ami », l'opt-out en 10 jours ouvrés et les violations aggravées.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/reglementation-d-application-de-can-spam

Savoir si CAN-SPAM couvre un message donné, qui en est juridiquement l'« expéditeur » et si un bouton « transférer à un ami » engage une responsabilité : tout cela est tranché par des règles que la Federal Trade Commission (FTC) a rédigées en vertu de la loi. Ces règles sont codifiées au **16 CFR Part 316**.

Elles définissent les termes qui déterminent si un message est couvert et qui est l'expéditeur responsable. Elles règlent aussi les cas limites : les emails qui font la publicité de plusieurs entreprises, les fonctions « transférer à un ami » et les adresses postales qui sont des boîtes postales.

Commencez par [Loi CAN-SPAM (États-Unis)](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis), qui résume en termes simples les sept règles principales de la loi. Ces règles ne sont pas reprises ci-dessous.

## Comment les règles ont été adoptées

Le CAN-SPAM Act a été promulgué le 16 décembre 2003 et est entré en vigueur le 1er janvier 2004. Il a donné à la FTC un pouvoir discrétionnaire pour définir ses termes et adopter des règles d'application. La FTC a publié les définitions dans plusieurs actes du Federal Register :

| Acte | Date | Contenu |
|---|---|---|
| Avis préalable de procédure réglementaire (ANPR) | 11 mars 2004 | A lancé un appel à commentaires publics sur l'« objet principal » et les définitions |
| **Primary Purpose Final Rule** | 19 janvier 2005 (70 FR 3110) | A codifié les **critères de l'objet principal du §316.3** |
| **Avis de projet de règle (NPRM)**, le document source de cette référence | 12 mai 2005 (70 FR 25426) | A proposé les définitions du §316.2 : *person*, *sender* et *valid physical postal address*. A proposé de ramener le délai d'opt-out à 3 jours ouvrés. A proposé l'interdiction des frais d'opt-out. A analysé les fonctions « transférer à un ami » |
| **Final Rule** | 21 mai 2008 (73 FR 29654) | A adopté les définitions et l'interdiction des frais. **A renoncé à raccourcir** le délai d'opt-out de 10 jours ouvrés |

<!-- glossary-allow: e-mail -->
**Ce que signifie « reporting requirements » dans le titre.** Le document source s'intitule « Definitions, Implementation, and Reporting Requirements ». Les rapports mentionnés dans ce titre sont ceux que la loi imposait à la FTC elle-même de remettre au Congrès, comme l'étude sur un registre Do-Not-E-mail. Ils ne désignent **pas** une quelconque obligation de tenue de registres ou de déclaration pour les expéditeurs. Le NPRM indique que la règle n'impose à la profession aucune nouvelle collecte d'informations au titre du Paperwork Reduction Act.

## Comment la règle est organisée

La numérotation adoptée du 16 CFR Part 316 diffère de celle que proposait le NPRM, car la section proposée sur un opt-out en 3 jours ouvrés a été abandonnée :

| Section | Objet |
|---|---|
| § 316.1 | Champ d'application : met en œuvre le 15 U.S.C. 7701–7713 |
| § 316.2 | Définitions |
| § 316.3 | Objet principal |
| § 316.4 | Mentions d'avertissement pour le matériel à caractère sexuel |
| § 316.5 | Interdiction des frais d'opt-out et des exigences superflues |
| § 316.6 | Divisibilité |

## Les critères de l'objet principal (§316.3)

Le fait que la loi couvre un message dépend de son **objet principal** (résumé dans [CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis#messages-commerciaux-transactionnels-ou-relationnels)). La règle transforme cette notion de la loi en critères mécaniques. L'objet principal d'un message est réputé **commercial** si :

**(1) Le contenu est uniquement commercial.** Le message se compose uniquement de la publicité ou de la promotion commerciale d'un produit ou d'un service commercial.

**(2) Le contenu est commercial et transactionnel ou relationnel** (double objet). Le message est commercial si **l'une** des conditions suivantes est remplie :
- (i) un destinataire qui interprète raisonnablement la **ligne d'objet** conclurait probablement que le message contient une publicité ou une promotion commerciale ; **ou**
- (ii) le contenu transactionnel ou relationnel **n'apparaît pas**, **en totalité ou pour une part substantielle, au début du corps** du message.

**(3) Le contenu est commercial et « autre »**, c'est-à-dire un contenu ni transactionnel ou relationnel, ni commercial. Le message est commercial si **l'une** des conditions suivantes est remplie :
- (i) le même critère de la ligne d'objet est rempli ; **ou**
- (ii) un destinataire qui interprète raisonnablement le **corps** du message conclurait probablement que son objet principal est commercial. Parmi les facteurs qui l'illustrent figurent la place du contenu commercial au début du corps du message, la part commerciale du message, et l'usage de la couleur, des graphismes, de la taille et du style des caractères pour mettre en valeur le contenu commercial.

L'objet principal d'un message n'est **transactionnel ou relationnel** que s'il se compose **exclusivement** des cinq catégories de contenu transactionnel ou relationnel du §316.3(c) :

1. Faciliter, finaliser ou confirmer une transaction commerciale que le destinataire a précédemment accepté de conclure ;
2. Fournir des informations de garantie, de rappel, de sécurité ou de sûreté sur un produit ou un service que le destinataire a utilisé ou acheté ;
3. Pour un abonnement, une adhésion, un compte, un prêt ou une relation comparable en cours : notifier au destinataire un changement des conditions ou des fonctionnalités, ou un changement de sa situation ou de son statut ; **ou** fournir à intervalles réguliers et périodiques des informations sur le solde du compte ou un autre type de relevé de compte ;
4. Fournir des informations directement liées à une relation de travail ou à un régime d'avantages associé dans lequel le destinataire est actuellement impliqué, participant ou inscrit ;
5. Livrer des biens ou des services, y compris des mises à jour ou des mises à niveau de produits, que le destinataire est en droit de recevoir aux termes d'une transaction précédemment convenue.

Dans son analyse du NPRM, la FTC interprète ces catégories **de façon étroite**, afin qu'elles n'érodent pas la protection de l'opt-out :

- La « transaction commerciale » de la catégorie 1 n'exige **pas** de contrepartie. L'inscription à un service gratuit, comme des invitations à des événements, peut être une transaction commerciale acceptée par le destinataire. Mais un **message initial non sollicité qui se borne à proposer** une transaction est commercial, et non transactionnel.
- Une **norme de raisonnabilité** détermine le nombre de messages de confirmation qu'une transaction peut justifier. Des « confirmations » envoyées toutes les heures et contenant des promotions seraient considérées comme commerciales.
- Au titre de la catégorie 3, les relevés de facturation ou de compte envoyés à intervalles réguliers restent admissibles même s'ils contiennent un peu de publicité. Si la publicité **submerge** le contenu transactionnel, en revanche, le critère du double objet du §316.3(a)(2) requalifie le message en message commercial.
- Un message qu'un tiers envoie aux salariés **avec l'autorisation de l'employeur**, pour promouvoir les biens propres de ce tiers, n'est **pas** transactionnel au titre de la catégorie 4. Seules les véritables informations sur la relation de travail en relèvent.
- La FTC **a rejeté** les demandes répétées de la profession visant à élargir les catégories, par exemple par une exemption générale pour les emails d'une association à ses membres, ou pour les emails entre entreprises (B2B). La loi ne permet de modifier les catégories que si la modification est nécessaire pour tenir compte de l'évolution des technologies ou des pratiques de l'email, et la FTC a estimé que cette condition n'était pas remplie. Les emails d'une association à ses membres et les emails B2B ne bénéficient donc **d'aucune exemption particulière**. Chaque message est classé d'après son contenu selon le critère de l'objet principal.

## Qui est l'expéditeur quand un message fait la publicité de plusieurs entreprises (§316.2)

La loi définit l'**expéditeur** (*sender*) comme la personne qui initie un message commercial et dont le produit, le service ou le site web y fait l'objet d'une publicité ou d'une promotion. Les notions d'« initier » et d'« expéditeur » peuvent toutes deux s'appliquer à **plusieurs personnes** pour un même message.

La règle résout le cas des annonceurs multiples au §316.2(m). Lorsque les produits ou services de **plusieurs personnes** font l'objet d'une publicité ou d'une promotion dans un même message, **chacune** d'elles est un « expéditeur ». Il existe une exception : si une seule d'entre elles répond à la fois à la définition de l'« expéditeur » donnée par la loi **et** à **un ou plusieurs** des critères suivants, seule cette personne est l'« expéditeur » du message :

1. Elle **contrôle le contenu** du message ;
2. Elle **détermine les adresses email** auxquelles le message est envoyé ; **ou**
3. Elle est **identifiée comme expéditeur dans le champ « From »**.

Cela permet à plusieurs annonceurs de **désigner un expéditeur unique** chargé de la conformité : un opt-out fonctionnel, une adresse postale valide et le respect des opt-out. Sinon, chaque annonceur devrait fournir ses propres suppressions, sa propre adresse et son propre opt-out. Selon les commentateurs, cela aurait obligé les annonceurs à révéler leurs listes de clients à des concurrents, et aurait dérouté les destinataires avec plusieurs mécanismes d'opt-out et plusieurs adresses postales.

**Exemple détaillé tiré du NPRM.** Les vendeurs X, Y et Z font tous l'objet d'une publicité dans un même message, et ils désignent X comme expéditeur unique. Cela ne fonctionne **que si**, parmi les trois, **seul X** contrôle le contenu, contrôle la liste des destinataires ou apparaît dans le champ « From ». X peut recourir à des tiers pour les critères qu'il ne remplit pas lui-même, mais **ni Y ni Z** ne peuvent remplir aucun d'entre eux. Le même exemple est résumé dans [CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis#désigner-lexpéditeur-quand-plusieurs-annonceurs-figurent-dans-un-même-message).

**Le champ « From » et les en-têtes « substantiellement » faux.** Cette règle rejoint l'interdiction par CAN-SPAM des informations d'en-tête substantiellement fausses ou trompeuses (15 U.S.C. 7704(a)(1)). Un champ « From » n'a pas à indiquer la raison sociale complète de l'initiateur, mais il doit donner au destinataire assez d'informations pour savoir qui envoie. Un « From » indiquant « John Doe » sur un message de la société XYZ n'identifierait pas correctement l'initiateur. Un champ « From » est « substantiellement » faux lorsqu'il empêche un destinataire, un fournisseur d'accès à Internet (ISP) ou une autorité répressive d'identifier ou de localiser l'initiateur, ou de lui répondre.

## Ce qui constitue une adresse postale valide (§316.2)

La règle définit, au §316.2(p), ce qui satisfait à l'exigence d'adresse physique de la loi (15 U.S.C. 7704(a)(5)(A)(iii)). Une adresse postale valide est **l'une quelconque** des adresses suivantes :

1. L'**adresse postale actuelle** de l'expéditeur ;
2. Une **boîte postale** (*Post Office box*) que l'expéditeur a enregistrée auprès de l'U.S. Postal Service (USPS) ; **ou**
3. Une **boîte aux lettres privée** que l'expéditeur a enregistrée auprès d'une **agence commerciale de réception du courrier (CMRA)** établie selon la réglementation de l'USPS.

La FTC a admis les boîtes postales et les boîtes CMRA pour deux raisons. Les deux ont une présence physique reconnue par l'USPS, et l'enregistrement auprès de l'USPS vérifie l'adresse du locataire lors de l'ouverture. Les autoriser « ne crée [donc] pas un risque plus grand qu'un expéditeur falsifie des informations pour contourner les objectifs de la loi » (*"creates no greater risk that a sender will falsify information to thwart the purposes of the Act"*) qu'une adresse postale classique, puisqu'un expéditeur malveillant peut mentir sur une adresse postale tout aussi facilement.

## L'opt-out en 10 jours ouvrés : 3 jours proposés, 10 maintenus

La loi (15 U.S.C. 7704(a)(4)) interdit d'initier un message commercial **plus de 10 jours ouvrés** après la réception de l'opt-out du destinataire. La loi permettait à la FTC de modifier ce délai.

Le NPRM **proposait de le ramener à 3 jours ouvrés**. Il faisait valoir qu'un traitement quasi instantané de l'opt-out est techniquement faisable, puisque certains expéditeurs et Go Daddy indiquaient traiter les opt-out « en quelques secondes » (*"within seconds"*), et qu'un délai plus court sert mieux l'objectif de protection de la vie privée de la loi. Les commentateurs se sont partagés en trois camps : maintenir 10 jours, raccourcir le délai, ou l'allonger à 15–30 jours pour les montages complexes impliquant plusieurs parties.

**Dans la Final Rule de 2008, la FTC a renoncé à raccourcir le délai. L'exigence de 10 jours ouvrés est maintenue.** Appliquez la règle adoptée : traitez les opt-out **sous 10 jours ouvrés**, et maintenez le mécanisme d'opt-out en fonctionnement **pendant au moins 30 jours** après l'envoi du message. Voir [La mécanique de l'opt-out dans CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis#mécanique-de-lopt-out).

## Ni frais ni démarches supplémentaires pour se désinscrire (§316.5)

Ni l'expéditeur ni aucune personne agissant pour son compte ne peut exiger du destinataire :

- de **payer des frais** ;
- de **fournir des informations** autres que son adresse email et ses préférences d'opt-out ; ou
- **d'effectuer une démarche autre que** l'envoi d'un email de réponse **ou** la visite d'une **seule** page web,

comme condition de l'acceptation ou du traitement d'une demande d'opt-out. Exiger du destinataire qu'il visite plusieurs pages web, qu'il se connecte ou qu'il divulgue des données personnelles pour se désabonner est interdit, car cela « entraverait la capacité des destinataires à exercer leur droit d'opt-out » (*"frustrate recipients' ability to exercise their opt-out rights"*). Un **menu de préférences** n'est autorisé que s'il comporte une option globale « se désinscrire de tout ».

## Les fonctions « transférer à un ami » : initier, procurer et acheminement de routine

CAN-SPAM ne contient aucune disposition spécifique sur les fonctions « transférer à un ami ». La responsabilité découle de trois définitions liées que la règle intègre :

- **Initier** (*initiate*) signifie émettre ou transmettre un message, **ou procurer** son émission ou sa transmission, **à l'exclusion** des actes qui relèvent de l'acheminement de routine.
- **Procurer** (*procure*) signifie intentionnellement **payer ou fournir une autre contrepartie à une autre personne, ou l'inciter**, pour qu'elle initie un message pour son compte.
- **L'acheminement de routine** (*routine conveyance*) désigne la transmission, le routage, le relais, le traitement ou le stockage d'un message par un processus technique automatique pour lequel **une autre personne a identifié les destinataires ou fourni les adresses des destinataires**.

Appliquées au transfert, ces définitions donnent les résultats suivants :

| Scénario | Résultat |
|---|---|
| Un destinataire transfère à d'autres un message commercial **non conforme** d'un annonceur | La **personne qui transfère** peut engager sa responsabilité en tant qu'initiateur de ce message |
| Le vendeur offre une **contrepartie** pour le transfert : argent, bons de réduction, remises, récompenses, participations à un tirage au sort ou paiements de parrainage | Le vendeur a **procuré** le transfert, il est donc expéditeur et initiateur. Il doit s'assurer que le message transféré comporte l'opt-out et l'adresse postale, et il doit respecter les opt-out |
| Le vendeur fournit seulement un mécanisme **« cliquez ici pour transférer »** ou **« Tell-A-Friend »** et n'offre aucune contrepartie | C'est un **acheminement de routine**, car la personne qui transfère identifie les destinataires. Le mécanisme lui-même est une incitation de minimis et **n'« incite » pas** au sens de la loi, si bien que le vendeur n'a **aucune responsabilité au titre de CAN-SPAM** |

« Inciter » (*induce*) est plus large que « payer » : cela signifie entraîner ou influencer par la persuasion. Le simple fait de proposer un bouton de transfert n'est toujours pas une incitation. Le Royaume-Uni aboutit à un résultat comparable par la notion d'« instigation » (voir le [PECR britannique](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email)).

## Violations aggravées et dommages-intérêts triplés

Un défendeur qui commet une **violation aggravée** en plus d'une violation du §7704(a) s'expose à des **dommages-intérêts triplés** dans une action en justice. La loi (15 U.S.C. 7704(b)) énumère **quatre** pratiques aggravantes :

1. **La collecte automatisée** d'adresses email (logiciels qui moissonnent les adresses) ;
2. **Les attaques par dictionnaire** : générer automatiquement des adresses en combinant des noms, des lettres ou des chiffres ;
3. **La création automatisée de multiples** comptes email depuis lesquels envoyer ;
4. **Le relais ou la retransmission** par un accès non autorisé à un ordinateur protégé (relais ou proxys ouverts, et botnets).

La FTC **a refusé d'ajouter** de nouvelles violations aggravées par voie réglementaire. Les commentateurs proposaient d'y ajouter le hashbusting (mots aléatoires insérés pour déjouer les filtres), la collecte manuelle d'adresses, les informations WHOIS inexactes et la vente de listes de proxys ouverts. La FTC a estimé que ces pratiques étaient **soit déjà interdites** par d'autres dispositions de la loi, **soit dépourvues de preuves** d'une contribution substantielle à l'email commercial illicite. Par exemple, le hashbusting dans une ligne d'objet enfreint déjà l'interdiction des objets trompeurs, et le relais par un virus enfreint déjà le §7704(a)(1)(C). La FTC a indiqué qu'elle continuerait de contester ces pratiques au titre de la section 5 du FTC Act le cas échéant.

## Les injonctions n'exigent pas de prouver l'élément intentionnel

Lorsqu'une disposition de CAN-SPAM ou de la règle comporte un **élément intentionnel**, cet élément est **écarté** lorsqu'un État, la FTC, la Federal Communications Commission (FCC), ou un responsable ou organisme d'un État, demande une **ordonnance de cessation ou une injonction** pour faire respecter la loi. Les autorités n'ont pas à alléguer ni à prouver l'état d'esprit du défendeur pour obtenir une injonction. Le NPRM proposait de codifier cette règle au §316.4(b), en suivant les articles 7706(e) et (f)(2) de la loi. La règle adoptée ne contient pas cette disposition, et le § 316.4 actuel porte sur les mentions d'avertissement : cette dispense repose donc sur la loi elle-même.

## Enseignements pratiques pour un fournisseur de services email (ESP)

- Les **critères de l'objet principal sont des critères de contenu, appliqués à chaque message**. Un ESP ne peut pas classer en bloc un compte ou un flux comme « transactionnel ». Un email à double objet dont les promotions apparaissent en haut du message est commercial et doit respecter toutes les exigences de CAN-SPAM.
- Pour les envois **multi-annonceurs, d'affiliation ou co-marqués**, assurez-vous qu'**un seul** expéditeur désigné remplit le critère (il contrôle le contenu, détermine les adresses ou est nommé dans le champ « From ») et apparaît dans le champ « From ». Sinon, chaque annonceur devient expéditeur avec toutes les obligations. Pour le volet opérationnel, voir [Authentification des domaines clients](https://emailmarketing.net/learn/esp-operations/customer-domain-authentication) et [Architecture des listes de suppression](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture).
- Les fonctions **« transférer à un ami »** sont sûres tant qu'elles relèvent du simple acheminement de routine. Dès que la plateforme ou le client offre une incitation au transfert, la marque à l'origine du message devient expéditeur de l'email transféré.
- La présence de l'une des quatre **pratiques aggravantes** dans l'historique d'acquisition d'un client est à la fois un signal d'alerte juridique et un problème grave de délivrabilité. Recherchez-les lors de la [vérification des clients](https://emailmarketing.net/learn/esp-operations/customer-vetting), dans les [méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement) et dans la [réponse aux incidents d'adresses pièges](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response).

# LCAP (CASL) : la Loi canadienne anti-pourriel

> Les règles du CRTC pour les messages électroniques commerciaux envoyés au Canada : consentement exprès ou implicite (avec délais), exigences d'identification et de désabonnement des MEC, exemptions et sanctions pouvant atteindre 10 M$.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel

Si vous envoyez des emails, des messages texte ou d'autres messages électroniques commerciaux à des personnes au Canada, vous avez besoin de leur consentement avant l'envoi. La Loi canadienne anti-pourriel (LCAP, en anglais CASL) encadre ces messages électroniques commerciaux (MEC).

Contrairement au [CAN-SPAM Act](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis) américain, qui est une loi d'opt-out, la LCAP est un régime d'**opt-in**. Un consentement, exprès ou implicite, est requis **avant** l'envoi, et c'est à l'expéditeur d'en apporter la preuve.

Ceci n'est pas un avis juridique. Vérifiez les sanctions et les seuils auprès de la source primaire (ci-dessous) et d'un conseil avant de vous y fier. Voir [Conformité](https://emailmarketing.net/fr/apprendre/conformite).

## Ce que régit la LCAP

La LCAP établit quatre interdictions et obligations principales :

1. **Messages électroniques commerciaux** : l'expéditeur doit obtenir le consentement préalable du destinataire (exprès ou implicite), fournir des renseignements d'identification et des coordonnées, et inclure un mécanisme de désabonnement fonctionnel.
2. **Installation de programmes informatiques** : installer un logiciel sur le système d'autrui exige le consentement exprès du propriétaire ou d'un utilisateur autorisé, ainsi qu'une description claire et simple de ce que fait le programme et pourquoi.
3. **Données de transmission des messages** : les informations de routage ne doivent pas être modifiées de sorte qu'un message soit livré à une destination autre que celle indiquée (ou en plus de celle-ci) sans le consentement approprié.
4. **Aide aux violations** : les organisations ne doivent pas aider d'autres personnes à enfreindre ces exigences (responsabilité pour « aide » au titre de l'article 9).

## Qu'est-ce qu'un MEC ?

Un message électronique commercial est un message dont **l'un quelconque des objectifs** est d'encourager le destinataire à participer à une activité commerciale. Il peut s'agir d'offres d'achat, de vente ou de location de produits ou de services, d'occasions d'affaires ou d'investissement, ou de la promotion des activités commerciales d'une personne. Ce critère est plus large que celui de l'« objet principal » de CAN-SPAM : un seul objectif commercial parmi plusieurs suffit.

### Messages couverts et exclus

| Couverts | Exclus ou exemptés |
|---|---|
| Email | Appels de télémarketing vocaux en direct et automatisés (réglementés séparément) |
| SMS et messages texte | Diffusions unidirectionnelles sur les réseaux sociaux (tweets, publications sur un mur) |
| Messagerie instantanée | Messages politiques dont l'objectif principal est de solliciter des contributions |
| Messages privés sur les réseaux sociaux | Interentreprises (B2B) : messages entre employés d'organisations qui entretiennent une relation existante |
| Notifications push (si commerciales) | Communications aux membres de clubs ou d'associations |
| | Messages dans des comptes sécurisés à accès limité (par exemple les portails bancaires) |
| | Collecte de fonds par des organismes de bienfaisance enregistrés (lorsque c'est l'objectif principal) |

## Consentement

### Consentement exprès

- La personne a **clairement accepté** de recevoir des MEC, par écrit ou oralement, en faisant une démarche active d'opt-in.
- **Les cases précochées, le silence ou l'inaction ne sont pas valables.** Une action positive est requise.
- Le consentement exprès **n'expire pas**. Il reste valable jusqu'à ce que le destinataire le retire.
- **Il incombe à l'expéditeur** de prouver que le consentement a été obtenu.

### Catégories de consentement implicite et délais

| Catégorie | Fondement | Validité |
|---|---|---|
| Relation d'affaires en cours (RAC) | Achat ou location de biens, de services ou d'un terrain | **2 ans** à compter de la transaction |
| RAC | Acceptation d'une occasion d'affaires, d'investissement ou de jeu | **2 ans** |
| RAC | Contrat écrit (en vigueur ou expiré) | **2 ans** à compter de l'expiration |
| RAC | Demande de renseignements ou demande concernant des produits ou services | **6 mois** |
| Relation privée en cours (organismes de bienfaisance, partis politiques et candidats, clubs et associations) | Don ou cadeau | **2 ans** |
| Relation privée en cours | Bénévolat ou participation à une réunion | **2 ans** |
| Relation privée en cours | Adhésion | Durée de l'adhésion (aucun délai fixe tant qu'elle est en cours) |
| Publication bien en vue | L'adresse est publiée publiquement (par exemple sur un site web) **sans aucune mention** qui décourage l'envoi de MEC, et le message concerne le rôle, les fonctions ou les attributions officielles du destinataire dans l'entreprise | Tant que l'adresse est publiée |
| Carte professionnelle ou adresse communiquée | Le destinataire a communiqué son adresse (par exemple sur une carte professionnelle) et le message concerne son rôle professionnel | Aucun délai indiqué |
| Recommandation | Une personne en recommande une autre | **Un seul MEC**, qui doit identifier la personne à l'origine de la recommandation |
| Transitoire (historique) | Une RAC ou une relation privée qui existait avant le 1er juillet 2014, avec un historique de MEC | 3 ans, du 1er juillet 2014 au 1er juillet 2017 (désormais expiré) |

### Registres et charge de la preuve

L'expéditeur doit pouvoir démontrer le consentement. Conservez l'adresse électronique, la date d'obtention du consentement, la méthode (un formulaire, oralement, un achat, etc.) et le contexte (historique d'achat, bénévolat, échange de cartes professionnelles). Le CRTC a publié un avis d'application de la loi qui porte spécifiquement sur la tenue de registres du consentement.

## Exigences de contenu des MEC

Chaque MEC doit :

1. **Identifier l'expéditeur**, ainsi que toute personne pour le compte de laquelle le message est envoyé. S'il n'est pas pratique d'inclure ces renseignements dans le corps du message, ils peuvent être fournis par un lien vers une page web **présentée de façon claire et bien visible** et accessible gratuitement.
2. **Fournir des coordonnées**, dont une adresse postale valide (une boîte postale est acceptable). Les coordonnées doivent rester **valides pendant au moins 60 jours** après l'envoi du message.
3. **Inclure un mécanisme de désabonnement** qui peut être « exécuté facilement » (*readily performed*), c'est-à-dire de façon simple, rapide et aisée (par exemple un lien de désabonnement, ou une réponse « STOP » ou « Unsubscribe » par SMS). Le mécanisme doit :
   - rester fonctionnel pendant **au moins 60 jours** après l'envoi du message ;
   - être traité **sans délai, et au plus tard 10 jours ouvrés** après la demande.

## Sanctions et responsabilité

| Exposition | Détail |
|---|---|
| Sanction administrative pécuniaire (particulier) | Jusqu'à **1 000 000 $ par violation** |
| Sanction administrative pécuniaire (organisation) | Jusqu'à **10 000 000 $ par violation** |
| Administrateurs et dirigeants | Personnellement responsables s'ils ont **ordonné ou autorisé la violation, ou y ont consenti, acquiescé ou participé** (*directed, authorized, assented to, acquiesced in, or participated in*) |
| Aide | Responsabilité au titre de l'article 9 pour avoir aidé d'autres personnes à commettre des violations |
| Spécialistes du marketing tiers et affiliés | Responsabilité partagée : la marque comme la partie qui envoie pour son compte sont responsables de la conformité |

Un programme de conformité documenté au sein de l'entreprise (diligence raisonnable) réduit le risque. Le Conseil de la radiodiffusion et des télécommunications canadiennes (CRTC) est chargé de l'application de la loi. Son site décrit ses processus de conformité et d'application, et publie ses mesures d'application. Le spam peut être signalé au Centre de notification des pourriels (fightspam.gc.ca).

## Enjeux pour la délivrabilité

Comme le consentement prévu par la LCAP expire, la loi impose de fait les pratiques d'hygiène de base de données qui protègent aussi la réputation d'expéditeur. N'écrivez qu'aux adresses liées à une relation récente que vous pouvez prouver, et retirez les adresses à mesure qu'elles arrivent à expiration (après 6 mois pour une demande de renseignements, et 2 ans pour un achat). Les expéditeurs qui respectent ces délais évitent naturellement les adresses anciennes et inactives qui génèrent des plaintes et des adresses pièges touchées. Voir [Fondamentaux de la délivrabilité email](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email).

# Le RGPD et les listes de suppression des ESP

> La tension entre effacement et suppression : le document de support du M3AAWG de décembre 2024 sur les cas où la suppression d'une adresse laisse l'ESP sous-traitant et ceux où elle en fait un responsable du traitement, avec l'analyse des 13 événements de suppression.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/rgpd-et-listes-de-suppression-des-esp

Si vous exploitez un fournisseur de services de messagerie (ESP) dont les clients ou les destinataires se trouvent dans l'UE, placer une adresse en suppression peut changer votre rôle au regard du Règlement général sur la protection des données (RGPD). Selon qui a décidé de la suppression, vous restez sous-traitant ou vous devenez responsable du traitement.

Les recommandations ci-dessous proviennent du document *M3AAWG Support Document: The GDPR and ESP Suppression Lists*, de décembre 2024. La mise en garde du document s'applique aussi ici : **ce n'est pas un avis juridique**. C'est un contexte pour les ESP qui examinent leurs pratiques de listes de suppression, et les questions juridiques précises relèvent d'un conseil. Le document a été récupéré à l'URL de sa révision finale (`the_gdpr_and_esp_suppression_listsfinal.pdf`). L'URL diffusée à l'origine renvoie désormais des erreurs 404.

## Le conflit entre suppression et effacement

Un ESP place des adresses en suppression pour qu'aucun email ne leur soit envoyé. Toute la profession l'attend, car cela protège la délivrabilité (voir [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil), et la conception opérationnelle dans [Architecture des listes de suppression](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture)).

Au regard du RGPD, cependant, tout traitement de données à caractère personnel exige une base légale, et les adresses email sont des données à caractère personnel. Lorsqu'un ESP place en suppression une adresse **que son client ne lui a pas demandé de supprimer**, l'ESP agit en dehors des instructions du client. Cela peut faire passer l'ESP du statut de **sous-traitant**, peu exposé, à celui de **responsable du traitement**, soumis à toutes les obligations d'un responsable du traitement.

Dans le même temps, une demande de « droit à l'oubli » (effacement) semble exiger que l'ESP supprime l'enregistrement même qu'il doit conserver pour garantir que la personne ne recevra plus jamais d'email.

## Définitions (article 4 du RGPD)

- **Responsable du traitement** : tout « organisme qui, seul ou conjointement avec d'autres, détermine les finalités et les moyens du traitement… » (article 4, point 7).
- **Sous-traitant** : tout « organisme qui traite des données à caractère personnel pour le compte du responsable du traitement… » (article 4, point 8).

Être sous-traitant comporte **moins de risques et de responsabilité**, à condition que l'ESP puisse démontrer qu'il a suivi les instructions du responsable du traitement et qu'il n'a traité les données pour aucune finalité, ni par aucun moyen, au-delà de ce que le responsable du traitement a décidé.

## Les adresses email sont-elles des données à caractère personnel ?

En règle générale, oui. Il existe des exceptions, comme les adresses de rôle génériques (`info@example.com`) ou les adresses de réponse génériques (`lotteryentry@example.com`), mais **concevez les systèmes en partant du principe que toutes les adresses email concernées sont des données à caractère personnel**. Le domaine lui-même peut être une donnée à caractère personnel, par exemple `js@john-smith.example.com`.

Lorsque l'ESP envoie des emails pour le compte d'un client en tant que sous-traitant, sa base légale est le **contrat avec le client (article 6, paragraphe 1, point b)**. Les ESP peuvent placer en suppression des **données non personnelles (comme des adresses pièges connues)** sans que le RGPD s'applique du tout, à condition que l'adresse piège ne soit réellement pas une donnée à caractère personnel.

## Les 13 événements qui déclenchent une suppression

Le M3AAWG énumère les situations dans lesquelles une suppression intervient. Chacune a une portée différente au regard du RGPD :

| N° | Événement | Remarques au regard du RGPD |
|---|---|---|
| 1 | **Adresses invalides** (un domaine de premier niveau qui n'existe pas, par exemple `example.con`) | Objectivement invalides. Placer en suppression des adresses qui ne peuvent en aucun cas être valides n'implique aucun traitement de données à caractère personnel en dehors du contrat |
| 2 | **Adresses probablement invalides** (domaines issus de fautes de frappe courantes, par exemple `hotmial.com` pour `hotmail.com`) | Les ESP peuvent bloquer le domaine pour tous les clients |
| 3 | **Suppression par code pays** (régimes de sanctions, et règles propres à un pays, par exemple sur les jeux d'argent) | Une appréciation propre à chaque ESP. `.de` (Allemagne) est traité différemment de `.tv` (Tuvalu, largement utilisé sans aucun lien avec le pays) |
| 4 | **Adresses jetables ou à usage unique** | ⚠ Les placer en suppression **alors que le contrat client ne le prévoit pas peut faire de l'ESP un responsable du traitement** |
| 5 | **Adresses de rôle** (`noreply@…`) qui ne correspondent pas à la nature des emails | Décider au cas par cas. Certaines adresses de rôle sont directement attribuables à des personnes connues, et sont donc des données à caractère personnel |
| 6 | **Échecs de livraison** (le serveur refuse : l'adresse n'existe pas, la boîte est « pleine », ou le contenu est jugé inacceptable) | Lorsque l'échec a de très fortes chances de se reproduire pour un message donné (ou un type de message), cesser les tentatives |
| 7 | **Messages de rebond** (un échec signalé plus tard, après que le message a semblé être accepté) | Analyser la cause. Elle peut justifier de ne plus faire de tentatives |
| 8 | **Informations de feedback loop** (le fournisseur signale que le message est arrivé en spam ou a été signalé comme spam) | Peut indiquer qu'il faut placer en suppression les livraisons futures |
| 9 | **Informations d'ouverture et d'engagement** (emails avec suivi, et longues périodes sans engagement) | La mise en sommeil fondée sur l'engagement est elle-même un traitement |
| 10 | **Demandes de désabonnement** (rédigées à la main, clics sur un lien, désabonnements déclenchés par les en-têtes dans le client de messagerie) | Les emails suivants **doivent** être supprimés |
| 11 | **Plaintes pour abus** (correspondance qui montre que les emails de cet expéditeur sont indésirables) | Placer en suppression pour cet expéditeur |
| 12 | **Adresses pièges connues** | Leur envoyer des messages nuit à la réputation de l'adresse IP et du domaine d'envoi, ce qui dégrade la livraison pour tous. L'ESP peut les placer en suppression (ce sont souvent des données non personnelles) |
| 13 | **Demandes d'oubli** | Une demande d'effacement d'une personne concernée située sur un territoire couvert par le RGPD (ou par une loi similaire), ou une instruction de cesser de traiter ses données à caractère personnel |

Par ailleurs, retirer une adresse parce que son titulaire est connu pour être **décédé** n'implique aucune donnée à caractère personnel, car **les personnes décédées n'ont pas de droits au titre du RGPD**.

## Listes de suppression par client : le terrain sûr du sous-traitant

Un ESP peut gérer des listes de suppression **séparément pour chaque client**, composées des personnes qui ont signalé comme spam les emails de cet expéditeur, qui se sont désabonnées ou dont les adresses ont généré un rebond, tout en restant « simple sous-traitant ». Le contrat entre l'ESP et le client devrait rendre ces conditions explicites :

- Le fonctionnement concret de la suppression. Après un rebond, l'ESP en assure-t-il le suivi pour le compte du client, ou le client doit-il mettre à jour sa propre liste ?
- **La fin du contrat.** Comment le client (le responsable du traitement) prend-il connaissance des demandes de désabonnement que l'ESP a reçues ? Le client est **tenu de respecter ces demandes même s'il envoie ensuite par un autre ESP.**

## Listes de suppression globales : le terrain du responsable du traitement

Les ESP peuvent considérer une liste de suppression globale, commune à tous les clients, comme indispensable à la survie de leur activité. Il est difficile de bien servir un client quel qu'il soit si des clients continuent d'écrire à des adresses pièges ou à des personnes qui se plaignent à répétition. Toutefois :

- Utiliser la liste de suppression **propre** à l'ESP pour bloquer des adresses auxquelles le client lui a demandé d'écrire va à l'encontre du contrat qui l'oblige à agir « pour son compte ». L'ESP « détermine » alors « les finalités et les moyens du traitement », ce qui signifie qu'il **est devenu responsable du traitement**.
- Il est « très probable » que l'ESP agisse au-delà du rôle de sous-traitant s'il tient sa propre liste de suppression pour bloquer des adresses précises, par exemple des personnes hostiles à l'activité de l'ESP, des comptes de rôle, des domaines pièges, des rebonds définitifs connus, et ainsi de suite.
- Si un ESP exploite une liste de suppression globale, **le contrat client devrait préciser comment elle s'applique**, afin que le client puisse remplir ses propres obligations de responsable du traitement. Des complications en matière de protection des données apparaissent généralement dès que l'ESP prend des mesures que le client n'a pas demandées.
- Un ESP devenu responsable du traitement doit agir comme tel. Le document renvoie à la **liste de contrôle de l'ICO britannique pour les responsables du traitement** comme point de départ : https://ico.org.uk/for-organisations/sme-web-hub/checklists/data-protection-self-assessment/controllers-checklist/

## Traiter les demandes d'oubli : la solution pratique

Le document n'énonce pas explicitement de solution au conflit entre effacement et suppression, mais il en suggère une :

1. Une demande d'effacement ou d'arrêt du traitement que l'ESP reçoit concerne des données que l'ESP traite **pour le compte de ses clients**. Acheminez-la et enregistrez-la de la manière prévue par le contrat.
2. **Le contrat entre l'ESP et son client devrait préciser comment ce type de suppression fonctionnera en pratique.** C'est la phrase décisive. La manière licite de conserver un enregistrement de suppression après une demande d'effacement est que le contrat ait défini cet enregistrement comme faisant partie du traitement demandé par le responsable du traitement.
3. Distinguez les types de suppression. Placer en suppression des adresses objectivement invalides ou non personnelles (adresses pièges) ne pose aucun problème. La suppression par client, motivée par le consentement, relève du travail de sous-traitant encadré par le contrat. La suppression globale à l'initiative de l'ESP relève du travail de responsable du traitement, et l'ESP doit en assumer les obligations.

## Liste de contrôle opérationnelle pour un ESP

- Inscrivez explicitement le comportement de suppression (par client, et toute liste globale) dans le contrat de sous-traitance (DPA) ou le contrat, y compris la suppression des adresses jetables et des adresses pièges.
- Définissez la remise des données en fin de contrat : les désabonnements et les plaintes doivent parvenir au client, qui reste lié par eux chez son ESP suivant.
- Traitez par défaut toutes les adresses comme des données à caractère personnel, et ne faites d'exception que pour les cas objectivement non personnels.
- Si vous exploitez une liste de suppression globale, acceptez d'être responsable du traitement : documentez les finalités, la base légale, la durée de conservation et le traitement des droits des personnes concernées (voir la liste de contrôle de l'ICO ci-dessus).
- Adressez à un conseil juridique la question de savoir si vous êtes sous-traitant ou responsable du traitement dans un cas donné. Le document le répète deux fois.

## Voir aussi

- [Architecture des listes de suppression](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture), sur la façon dont se construit la séparation entre suppression par client et suppression globale
- [CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis)
- [LCAP](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel)
- [PECR britannique](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email)
- [Feedback loops de plaintes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes)
- [List-Unsubscribe](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic)

# Loi CAN-SPAM (États-Unis)

> Les exigences de conformité de la FTC pour l'email commercial aux États-Unis : les sept règles principales, la distinction entre messages commerciaux et transactionnels, la responsabilité de l'expéditeur et les sanctions.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis

Si vous envoyez des emails commerciaux à des personnes aux États-Unis, le CAN-SPAM Act s'applique à vous. Il fixe des exigences pour les messages commerciaux, donne aux destinataires le droit d'obtenir qu'un expéditeur cesse de leur écrire et précise les sanctions en cas de violation. La Federal Trade Commission (FTC) fait appliquer la loi et la CAN-SPAM Rule qui l'accompagne.

Ceci n'est pas un avis juridique. Vérifiez les sanctions et les seuils auprès de la source primaire (ci-dessous) et d'un conseil avant de vous y fier. Voir [compliance/README.md](https://emailmarketing.net/fr/apprendre/conformite).

Ce que couvre la loi :

- Malgré son nom, CAN-SPAM ne s'applique **pas** qu'aux envois en masse. La loi couvre **tous les messages commerciaux**, définis comme « tout message électronique dont l'objet principal est la publicité ou la promotion commerciale d'un produit ou d'un service commercial » (*"any electronic mail message the primary purpose of which is the commercial advertisement or promotion of a commercial product or service"*), y compris les emails qui font la promotion de contenus sur des sites web commerciaux.
- Il n'existe **aucune exception pour les messages entre entreprises**. Un message adressé à d'anciens clients pour annoncer une nouvelle gamme de produits doit être conforme.
- CAN-SPAM est un régime d'**opt-out**. Vous n'avez pas besoin d'un consentement préalable pour envoyer un email commercial, mais vous devez proposer et respecter l'opt-out. Comparez avec les régimes d'opt-in de la [LCAP canadienne](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel) et du [PECR britannique](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email).

## Sanctions

| Exposition | Détail |
|---|---|
| Sanction civile | Jusqu'à **53 088 $ par email distinct** en infraction. C'est le plafond prévu au §5(m)(1)(A) du FTC Act, indexé sur l'inflation. **Le montant de 53 088 $ est entré en vigueur le 17 janvier 2025**, en remplacement du montant précédent de 51 744 $, et reste d'actualité : l'ajustement annuel de 2026 a été annulé après l'interruption de l'indice CPI-U, donc vérifiez-le dans le [16 CFR 1.98](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-A/part-1/subpart-L/section-1.98) |
| Plusieurs responsables | Plusieurs personnes peuvent être responsables du même message : l'entreprise dont le produit est promu **et** l'entreprise qui a émis ou envoyé le message |
| Allégations trompeuses | Des allégations trompeuses sur un produit ou un service peuvent en outre enfreindre le droit de la publicité trompeuse (section 5 du FTC Act) |
| Réparation pour les consommateurs | Au titre de la section 19 du FTC Act, la réparation peut inclure ce que les consommateurs ont payé **plus la valeur du temps qu'ils ont perdu** |
| Violations aggravées | Certaines violations entraînent des amendes supplémentaires |
| Sanctions pénales | Y compris l'emprisonnement (voir ci-dessous) |

Des sanctions pénales, y compris l'emprisonnement, s'appliquent au fait de :

- accéder à l'ordinateur d'autrui sans autorisation pour envoyer du spam ;
- utiliser de fausses informations pour enregistrer plusieurs comptes email ou noms de domaine ;
- relayer ou retransmettre de nombreux messages de spam par un ordinateur afin de tromper autrui sur l'origine du message ;
- collecter des adresses email, ou les générer par une attaque par dictionnaire (envoi à des adresses composées de lettres ou de chiffres aléatoires dans l'espoir de tomber sur des adresses valides) ;
- utiliser des relais ouverts ou des proxys ouverts sans autorisation.

## Les sept exigences principales

| N° | Exigence | Détail |
|---|---|---|
| 1 | Aucune information d'en-tête fausse ou trompeuse | Les champs « From », « To », « Reply-To » et les informations de routage, y compris le nom de domaine et l'adresse email d'origine, doivent être exacts et identifier la personne ou l'entreprise qui a initié le message |
| 2 | Aucune ligne d'objet trompeuse | La ligne d'objet doit refléter fidèlement le contenu du message |
| 3 | Signaler que le message est une publicité | Indiquer de façon claire et visible que le message est une publicité (la loi laisse une certaine liberté sur la manière) |
| 4 | Inclure une adresse postale valide | Une adresse postale actuelle, une boîte postale enregistrée auprès de l'U.S. Postal Service, ou une boîte aux lettres privée enregistrée auprès d'une agence commerciale de réception du courrier établie selon la réglementation du Postal Service |
| 5 | Indiquer aux destinataires comment se désinscrire | Une explication claire et visible, qu'une personne ordinaire peut facilement repérer, lire et comprendre. Fournir une adresse email de réponse ou un autre moyen simple, par Internet, de communiquer ce choix |
| 6 | Traiter rapidement les demandes d'opt-out | Voir les règles détaillées ci-dessous |
| 7 | Surveiller ce que d'autres font en votre nom | Vous ne pouvez pas transférer la responsabilité juridique à un prestataire de marketing par email par contrat. L'entreprise promue comme l'entreprise expéditrice peuvent être tenues responsables |

## Mécanique de l'opt-out

- Le mécanisme d'opt-out doit pouvoir **traiter les demandes pendant au moins 30 jours** après l'envoi du message.
- Les demandes d'opt-out doivent être traitées **sous 10 jours ouvrés**.
- Un expéditeur ne peut **pas** facturer de frais, exiger d'autre information d'identification personnelle qu'une adresse email, ni exiger une démarche autre que l'envoi d'un email de réponse ou la visite d'une **seule** page web.
- Un menu de préférences (pour se désinscrire de certains types de messages) est autorisé, mais il **doit comporter une option permettant d'arrêter tous les messages marketing**.
- Veillez à ce que votre propre filtre anti-spam ne bloque pas les demandes d'opt-out entrantes.
- Une fois qu'une personne s'est désinscrite, vous ne pouvez **ni vendre ni transférer** son adresse, même au sein d'une liste de diffusion. La seule exception est le transfert à une entreprise engagée pour vous aider à respecter CAN-SPAM.
- **Les abonnés et les membres peuvent aussi se désinscrire.** Un abonnement ou une adhésion ne supprime pas le droit de refuser les emails marketing. Avant d'envoyer à des abonnés ou à des membres un message sans lien de désabonnement, vérifiez que son objet principal relève de l'une des cinq catégories transactionnelles ou relationnelles ci-dessous. Sinon, vous devez inclure un opt-out.

## Messages commerciaux, transactionnels ou relationnels

Ce que couvre la loi dépend de l'**objet principal** du message. Un email peut contenir trois types de contenu :

1. **Contenu commercial**, qui fait la publicité ou la promotion d'un produit ou d'un service commercial, y compris le contenu d'un site web exploité à des fins commerciales ;
2. **Contenu transactionnel ou relationnel**, qui facilite une transaction déjà convenue ou informe un client au sujet d'une transaction en cours ;
3. **Autre contenu**, qui n'est ni l'un ni l'autre.

Si le message ne contient que du contenu commercial, il est commercial et toutes les exigences de CAN-SPAM s'appliquent. S'il ne contient **que** du contenu transactionnel ou relationnel, il est exempté de la plupart des dispositions, mais il **ne doit toujours pas contenir d'informations de routage fausses ou trompeuses**.

### Les cinq catégories transactionnelles ou relationnelles

L'objet principal d'un message n'est transactionnel ou relationnel que s'il se compose **uniquement** d'un contenu qui :

1. facilite, finalise ou confirme une transaction commerciale que le destinataire a déjà acceptée ;
2. donne des informations de garantie, de rappel, de sécurité ou de sûreté sur un produit ou un service que le destinataire a acheté ;
3. informe le destinataire d'un changement des conditions ou des fonctionnalités d'une adhésion, d'un abonnement, d'un compte, d'un prêt ou d'une autre relation commerciale continue, ou d'un changement de la situation du destinataire dans cette relation, ou fournit des informations régulières et périodiques sur le solde d'un compte ;
4. fournit des informations sur une relation de travail ou sur des avantages sociaux ;
5. livre des biens ou des services dans le cadre d'une transaction que le destinataire a déjà acceptée.

La FTC interprète ces catégories **de façon étroite**. Ne partez pas du principe que tout message adressé à des abonnés ou à des membres est transactionnel. Le critère est de savoir si un consommateur raisonnable qui lit l'email comprendrait que son objet principal relève de l'une des cinq catégories.

### Contenu mixte : commercial et transactionnel

Le message est **commercial** au sens de CAN-SPAM si l'une des conditions suivantes est remplie :

- un destinataire qui interprète raisonnablement la **ligne d'objet** conclurait probablement qu'il contient une publicité ou une promotion ; **ou**
- le contenu transactionnel ou relationnel **n'apparaît pas principalement au début** du message.

Un exemple tiré du guide de la FTC : un relevé de compte qui présente d'abord les détails de livraison et de paiement, avec une ligne sur un site web à la fin, est très probablement transactionnel. La même ligne d'objet sur un message qui s'ouvre sur des promotions et relègue l'avis de livraison à la fin est très probablement commercial.

### Contenu mixte : commercial et « autre »

L'objet principal est commercial si :

- un destinataire qui interprète raisonnablement la ligne d'objet conclurait probablement que le message fait la publicité ou la promotion d'un produit ou d'un service ; **ou**
- un destinataire qui interprète raisonnablement le **corps** du message conclurait probablement que son objet principal est la publicité ou la promotion.

Les facteurs pertinents sont l'emplacement du contenu commercial (par exemple, au début ?), la part commerciale du message, et l'usage de la couleur, des graphismes, de la taille et du style des caractères pour mettre en valeur le contenu commercial.

## Désigner l'expéditeur quand plusieurs annonceurs figurent dans un même message

Lorsqu'un même email fait la publicité des biens, des services ou des sites web de plusieurs annonceurs, ceux-ci peuvent **désigner un « expéditeur » unique** responsable de la conformité, à condition que l'annonceur désigné :

1. réponde à la définition de l'« expéditeur » donnée par la loi (il initie un message commercial qui fait la publicité ou la promotion de ses propres biens, services ou site web) ;
2. soit expressément identifié dans le **champ « From »** ; et
3. respecte les dispositions applicables à l'**initiateur** : aucune information de transmission ni ligne d'objet trompeuse, une adresse postale valide, un lien d'opt-out fonctionnel et l'identification correcte du message comme commercial ou sexuellement explicite.

Si l'expéditeur désigné manque à ces obligations, **tous les annonceurs présents dans le message peuvent être tenus responsables en tant qu'expéditeurs**.

## Messages « transférer à un ami »

Savoir si c'est le vendeur ou la personne qui transfère le message qui est l'« expéditeur » ou l'« initiateur » dépend des faits, et avant tout de la question de savoir si le vendeur **paie ou offre un avantage** en échange du transfert. Si le vendeur offre de l'argent, des bons de réduction, des remises, des récompenses, des participations à un tirage au sort ou quelque chose de similaire en échange du transfert, ou s'il paie ou récompense quiconque pour générer du trafic web ou toute forme de recommandation, il a probablement des obligations de conformité. Le Royaume-Uni aboutit à un résultat comparable par la notion d'« instigation » (voir le [PECR britannique](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email)).

## Emails à caractère sexuellement explicite

Une règle de la FTC prise en application de CAN-SPAM ajoute des exigences pour les messages contenant du matériel à caractère sexuel :

- La ligne d'objet doit commencer par l'avertissement **« SEXUALLY-EXPLICIT: »**.
- Le corps du message doit utiliser l'équivalent électronique d'un « emballage en papier kraft ». À l'ouverture du message, le seul contenu visible peut être la mention « SEXUALLY-EXPLICIT: » et les mentions obligatoires de l'email commercial (identification de la publicité, adresse postale, procédure d'opt-out). **Aucun graphisme** n'est autorisé sur cet emballage, et le destinataire doit faire une action délibérée (défilement, clic) pour voir le contenu explicite.
- L'exigence d'emballage ne s'applique pas si le destinataire a donné au préalable son **consentement exprès** à recevoir les messages à caractère sexuel de l'expéditeur.

## Enjeux pour la délivrabilité

CAN-SPAM est un minimum légal, pas une stratégie pour atteindre la boîte de réception. Les critères de filtrage des fournisseurs de messagerie (taux de plaintes, engagement) sont bien plus stricts que le droit de l'opt-out. Des messages légaux que les destinataires n'ont jamais demandés génèrent quand même les plaintes et le faible engagement qui détruisent la réputation d'un expéditeur. Voir [Fondamentaux de la délivrabilité email](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email) et [Les deux mondes de la délivrabilité email](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email).

# Lois sur le marketing par email en Asie-Pacifique : Japon, Nouvelle-Zélande, Singapour, Corée du Sud

> Référence pays par pays : la loi japonaise d'opt-in sur les emails électroniques spécifiés et l'APPI, l'Unsolicited Electronic Messages Act néo-zélandais (consentement exprès, déduit ou réputé), le Spam Control Act de Singapour (<ADV>, désabonnement sous 10 jours ouvrés) et la PDPA, et l'opt-in de l'article 50 du Network Act coréen avec la mention (광고) et la règle des envois nocturnes.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/lois-sur-le-marketing-par-email-en-asie-pacifique

Si vous envoyez des emails marketing à des destinataires au Japon, en Nouvelle-Zélande, à Singapour ou en Corée du Sud, prévoyez d'avoir besoin de leur consentement. Les quatre pays imposent de fait l'**opt-in pour le marketing par email**. Le Spam Control Act de Singapour fonctionne par opt-out pour chaque message, mais sa Personal Data Protection Act (PDPA) y ajoute une exigence de consentement par opt-in pour utiliser des données personnelles à des fins de prospection directe. Un tableau récapitulatif vient d'abord, suivi du détail pour chaque pays.

| Pays | Loi | Norme de consentement | Mention | Délai de désabonnement | Sanction maximale (email) | Autorité |
|---|---|---|---|---|---|---|
| Japon | Act on Regulation of Transmission of Specified Electronic Mail (2002, opt-in depuis 2008) et Act on the Protection of Personal Information (APPI) | Opt-in. Exceptions : la personne a communiqué sa propre adresse, une relation d'affaires existe, ou l'adresse professionnelle a été publiée | Mentions des « emails électroniques spécifiés » fixées par l'ordonnance du ministère des Affaires intérieures et des Communications (MIC) | Immédiat dès l'opt-out (plus aucun envoi) | ≤ 1 an d'emprisonnement ou 1 M ¥ (personne physique) ; 30 M ¥ (personne morale) | Le MIC et la Consumer Affairs Agency ; la Personal Information Protection Commission (PPC) pour l'APPI |
| Nouvelle-Zélande | Unsolicited Electronic Messages Act 2007 | Exprès, déduit ou réputé (publication bien en vue) | Aucune | 5 jours ouvrés ; le dispositif doit fonctionner ≥ 30 jours | 200 000 NZ$ (personne physique) / 500 000 NZ$ (organisation) | Department of Internal Affairs (DIA) |
| Singapour | Spam Control Act 2007 et PDPA 2012 | Spam Control Act (SCA) : opt-out pour chaque message (expéditeurs en masse). PDPA : opt-in exprès pour la prospection directe qui utilise des données personnelles | `<ADV>` dans l'objet | 10 jours ouvrés ; le dispositif doit rester valide ≥ 30 jours | Civil : 25 $ par message, jusqu'à 1 M $ au total. Amendes de la Personal Data Protection Commission (PDPC) jusqu'à 10 % du chiffre d'affaires à Singapour au titre de la PDPA | PDPC (et actions civiles au titre du SCA) |
| Corée du Sud | Network Act, article 50 (et Personal Information Protection Act (PIPA)) | Opt-in exprès préalable. Exception : contacts issus des propres transactions de l'expéditeur, pour les mêmes biens, dans un délai fixé par décret (6 mois) | « (광고) » (« publicité ») en début d'objet | L'envoi doit cesser immédiatement après un refus ; le résultat doit être notifié | Amende administrative ≤ 30 M ₩ ; ≤ 1 an d'emprisonnement ou 10 M ₩ d'amende pour les tactiques de contournement | Korea Communications Commission (KCC) et Korea Internet & Security Agency (KISA) pour le spam ; Personal Information Protection Commission (PIPC) pour la PIPA |

---

## Japon : Act on Regulation of Transmission of Specified Electronic Mail

La **特定電子メール法** (loi n° 26 de 2002) est dite « loi anti-spam ». Elle a été adoptée en 2002 sous la forme d'un régime d'opt-out fondé sur l'étiquetage. Elle a été modifiée en 2005 (sanctions renforcées) et en **2008 (loi n° 54), date à laquelle elle est passée à l'opt-in** et a été étendue au spam envoyé depuis l'étranger.

> Sources : le portail officiel Japanese Law Translation (JLT) propose une traduction anglaise à jour seulement pour la **version de 2005**, antérieure à l'opt-in, avec l'ancienne numérotation des articles. Elle présente encore le régime d'opt-out d'« étiquetage » de l'article 3. Les énoncés ci-dessous sur le droit en vigueur suivent l'« Overview of Japanese Anti-Spam Law » en anglais du MIC, publié par Dekyo, l'Anti-Spam Consultation Center. N'utilisez le texte du JLT que pour les définitions.

- **Champ d'application.** Un « email électronique spécifié » (*specified electronic mail*) est un email envoyé **comme moyen de publicité** pour les activités commerciales de l'expéditeur ou d'autrui, par une organisation à but lucratif ou par une personne physique exerçant une activité commerciale.
- **Opt-in (article 3 actuel).** Les emails publicitaires ne peuvent pas être envoyés sans le **consentement préalable** du destinataire. Les exceptions visent les personnes qui ont notifié leur demande ou leur consentement ; qui **ont communiqué leur propre adresse email** à l'expéditeur (par exemple par écrit ou sur une carte professionnelle) ; qui ont une **relation d'affaires** avec l'annonceur ; ou, pour les expéditeurs professionnels, qui **ont publié leur adresse** dans le cadre de leur activité. Les expéditeurs doivent **conserver une trace des consentements** (article 3(2)). La violation d'une injonction administrative relative à cette tenue de registres est sanctionnée par une amende distincte.
- **Interdiction après l'opt-out** (article 3(3) actuel). Dès que le destinataire notifie son refus, plus aucun email publicitaire ne peut lui être envoyé.
- **Obligation de mentions (article 4 actuel).** Selon l'ordonnance du MIC, le message doit indiquer le **nom et l'adresse** de l'expéditeur, l'**adresse email destinée aux notifications d'opt-out** et les autres informations prescrites. Avant 2008, les messages devaient porter la mention « 未承諾広告※ » (« publicité non sollicitée ») ; le régime d'opt-in l'a remplacée par ces exigences d'information.
- **La falsification des informations sur l'expéditeur est interdite** (article 5), et c'est une **infraction pénale directe**. L'envoi à des **adresses fictives générées par un programme** est également interdit (article 6). Les fournisseurs d'accès à Internet peuvent refuser leurs services à ces expéditeurs (article 11).
- **Comment la loi est appliquée.** Le MIC et la **Consumer Affairs Agency** prononcent des injonctions administratives (article 7), et peuvent procéder à des inspections sur place et exiger des rapports (article 28), demander aux fournisseurs d'accès à Internet des informations sur leurs cocontractants (article 29), et échanger des informations avec les autorités répressives étrangères (article 30). Les destinataires et les fournisseurs d'accès à Internet signalent le spam à l'organisme agréé (l'Anti-Spam Consultation Center de Dekyo).
- **Sanctions.** La violation de l'article 5 (fausses informations sur l'expéditeur) ou d'une injonction administrative est punie d'**un emprisonnement de 1 an au plus ou d'une amende de 1 000 000 ¥ au plus**. La **personne morale employeuse encourt une amende de 30 000 000 ¥ au plus** (articles 34 et 35).
- Un régime d'opt-in distinct pour les emails publicitaires du commerce électronique existe dans le **Specified Commercial Transactions Act**, sous la tutelle du ministère de l'Économie, du Commerce et de l'Industrie (METI). Les annonceurs doivent respecter les deux.

### Les points de contact de l'APPI pour les marketeurs

L'**Act on the Protection of Personal Information** (APPI), dont le respect est assuré par la **PPC** (Personal Information Protection Commission), régit les données d'adresse elles-mêmes. La PPC publie des traductions anglaises. Le PDF consolidé utilisé ici est le texte modifié en juin 2020, et une version consolidée au 1er avril 2023, avec des articles renumérotés, figure sur la page juridique de la PPC. Seul le texte japonais a force juridique.

Les obligations qui comptent pour le marketing :

- Préciser et publier la **finalité d'utilisation**, et s'y tenir.
- **Communiquer des données personnelles à un tiers exige un consentement préalable**, ou le **mécanisme d'opt-out** notifié, qui est déclaré auprès de la PPC et ne peut pas servir pour les données sensibles. C'est ce qui encadre la vente et le partage de listes.
- Tenir un registre des données communiquées.
- Obtenir le consentement pour les transferts à des tiers **hors du Japon**, avec des informations sur le pays de destination, sauf si le pays figure sur la liste approuvée (l'UE et le Royaume-Uni ont des décisions d'adéquation mutuelles avec le Japon).
- Cesser d'utiliser les données sur demande lorsqu'elles sont traitées de manière illicite.

La modification de 2020 (en vigueur depuis avril 2022) a porté les amendes des personnes morales **jusqu'à 100 M ¥** pour certaines violations, comme le non-respect des injonctions de la PPC ou la communication illicite d'une base de données.

---

<a id="new-zealand--unsolicited-electronic-messages-act-2007"></a>

## Nouvelle-Zélande : Unsolicited Electronic Messages Act 2007

L'Electronic Messaging Compliance Unit du **Department of Internal Affairs (DIA)** administre et applique la loi. Elle couvre les **messages électroniques commerciaux** (email, SMS, télécopie, messages instantanés, messages image) présentant un **lien avec la Nouvelle-Zélande** : les messages envoyés vers, depuis ou à l'intérieur de la Nouvelle-Zélande, et pas seulement aux adresses en .nz. Les fenêtres pop-up et les appels vocaux sont exclus. Le régime reproduit délibérément celui de l'Australie ([Spam Act](https://emailmarketing.net/fr/apprendre/conformite/australie-spam-act-2003-et-application-par-l-acma)), et le DIA le présente en trois étapes :

1. **Consentement**
   - **Exprès** : une manifestation directe, comme un formulaire, une case à cocher ou un accord oral. Conservez-en la trace, car l'expéditeur doit prouver le consentement.
   - **Déduit** : à partir du comportement et d'une relation d'affaires continue, lorsque le destinataire peut raisonnablement s'attendre à recevoir des messages. Le DIA qualifie son usage de « limité ». Un **achat unique ne crée pas de consentement déduit continu**. Une carte professionnelle ne permet que des messages en rapport avec la relation dans laquelle elle a été échangée. Un établissement d'enseignement supérieur qui écrit à ses étudiants inscrits au sujet des services du campus est admis.
   - **Réputé (publication bien en vue)** : une adresse **publiée bien en vue à titre professionnel ou officiel** (sur un site web, dans une brochure ou dans un annuaire) vaut consentement, **sauf si** elle est publiée avec une mention indiquant que les messages non sollicités ne sont pas souhaités. Il ne couvre que les messages **en rapport avec l'activité, le rôle, les fonctions ou les attributions de la personne**.
2. **Identification** : identifier clairement l'entreprise qui a autorisé le message et la manière de la contacter. Les coordonnées doivent rester exactes pendant **30 jours** après l'envoi.
3. **Désabonnement** : chaque message doit comporter un dispositif de désabonnement fonctionnel, clair et bien visible, **gratuit**, et qui utilise le **même support** que le message. Une campagne SMS doit accepter une réponse STOP, et proposer un désabonnement uniquement par email pour des SMS enfreint la loi. Le dispositif doit fonctionner pendant **≥ 30 jours**, et les demandes doivent être traitées sous **5 jours ouvrés**, à compter du lendemain de la demande.

Les **logiciels de collecte d'adresses**, et les listes d'adresses collectées utilisées pour envoyer des messages commerciaux non sollicités, sont également interdits.

**Sanctions.** Le DIA procède par étapes, des avertissements formels et avis d'infraction civils jusqu'aux poursuites judiciaires. Le non-respect expose à des amendes pouvant atteindre **500 000 NZ$ pour les organisations**. Le DIA indique le montant de 500 k $ ; la loi, en son article 45, fixe 200 000 NZ$ pour les personnes physiques. Les destinataires transfèrent leurs plaintes pour spam au DIA (au 7726 pour les SMS).

---

## Singapour : Spam Control Act 2007 et PDPA

Il existe deux couches. Le **Spam Control Act (SCA)** régit l'envoi de messages électroniques commerciaux non sollicités **en masse** : emails et messages mobiles, y compris les messages vers des comptes de messagerie instantanée, présentant un lien avec Singapour. La **Personal Data Protection Act 2012 (PDPA)** régit l'utilisation de l'adresse, et la PDPC exige un consentement par **opt-in** pour la prospection directe.

> Sources : le texte du SCA provient de la transcription de Wikisource et de captures de Singapore Statutes Online par la Wayback Machine, car sso.agc.gov.sg charge son contenu en différé et bloque la récupération automatisée. Les Advisory Guidelines on Key Concepts de la PDPC (PDF, révisé le 29 avril 2026) ont été récupérées via la Wayback Machine à partir de l'URL pdpc.gov.sg citée dans les sources.

### La mécanique du Spam Control Act

- **« Envoi en masse »** (article 6) : plus de **100** messages portant sur un même sujet ou un sujet similaire en **24 heures**, **1 000** en **30 jours** ou **10 000** en **1 an**.
- **Attaques par dictionnaire et logiciels de collecte d'adresses** (article 9). Aucun message ne peut être envoyé à des adresses générées ou obtenues par l'un ou l'autre de ces moyens, quels que soient le consentement ou le contenu.
- **Exigences de la deuxième annexe** pour les messages commerciaux non sollicités envoyés en masse (article 11) :
  - **Dispositif de désabonnement** : une adresse email (et, pour les messages mobiles, un numéro capable de recevoir des SMS) valide et capable de recevoir des demandes pendant **au moins 30 jours** après l'envoi, sans coût supérieur au coût habituel. Après une demande de désabonnement, plus aucun message ne peut être envoyé une fois écoulés **10 jours ouvrés**.
  - **Mention** : la marque `<ADV>`, afin que le message soit clairement identifié comme une publicité. Selon la loi et ses règlements, elle figure dans la ligne d'objet ou, en l'absence d'objet, de manière bien visible dans le message.
  - **En-tête et informations sur l'expéditeur exacts** : aucune ligne d'objet ni aucun en-tête faux ou trompeur, et une adresse email ou un numéro de téléphone de l'expéditeur exact et fonctionnel.
- **L'application passe par des actions civiles, et non par une autorité.** Toute personne qui subit un préjudice peut agir en justice (articles 13–14). **Les dommages-intérêts légaux vont jusqu'à 25 $ par message, avec un plafond total de 1 million $**, sauf si le préjudice réel est supérieur. L'aide ou la complicité à une violation peut aussi faire l'objet d'une action (article 12). La première annexe exclut certains messages, comme les messages des pouvoirs publics ou d'urgence d'intérêt public.

### La couche PDPA (Advisory Guidelines on Key Concepts de la PDPC)

- **Les coordonnées professionnelles sont exclues** des dispositions sur la protection des données : un nom, une fonction, un numéro de téléphone, une adresse ou une adresse email professionnels qui n'ont pas été fournis uniquement à des fins personnelles. La prospection B2B vers des adresses d'entreprise n'exige pas de consentement au titre de la PDPA, mais le SCA s'applique toujours aux envois en masse.
- **La prospection directe exige un consentement exprès par opt-in.** Les Personal Data Protection Regulations 2021 prévoient que **le consentement réputé par notification ne s'applique pas à l'envoi de messages de prospection directe** (¶12.27), et la PDPC « ne considère pas la méthode de l'opt-out (par exemple une case précochée) comme appropriée » (*"does not consider the opt-out method (e.g., a pre-checked box) appropriate"*) pour le consentement au marketing (¶12.28).
- Le consentement réputé par le comportement ne couvre que les finalités objectivement évidentes au regard de la transaction. Réserver un taxi ne vaut pas consentement à recevoir la promotion d'un service de limousine.
- **Listes de tiers.** Une organisation qui achète des données doit s'assurer avec diligence que le vendeur a valablement obtenu le consentement à leur communication, au moyen d'engagements contractuels, d'une confirmation écrite ou de copies des preuves de consentement (¶¶12.33–12.34).
- **Le retrait du consentement** (article 16 de la PDPA) doit être permis et facilité. La règle empirique de la PDPC pour un « préavis raisonnable » est qu'un retrait prend effet sous **10 jours ouvrés** (¶12.41). En cas de retrait, l'organisation doit aussi faire cesser le traitement par ses **intermédiaires de données et ses mandataires** (¶12.52). Un clic générique sur « se désabonner » est interprété comme un retrait portant uniquement sur le **canal par lequel le message a été envoyé** (¶¶12.47–12.48).
- **Les ESP sont des « intermédiaires de données »** (*data intermediaries*). Un intermédiaire qui traite des données pour le compte d'une autre organisation, aux fins de celle-ci et dans le cadre d'un contrat écrit, n'est soumis qu'aux obligations de **protection, de limitation de la conservation et de notification des violations de données** (pour cette dernière, il doit prévenir son client). L'organisation cliente reste pleinement responsable, comme si elle avait traité elle-même les données (article 4(3), ¶¶6.15–6.27). Un traitement à l'étranger déclenche l'**obligation de limitation des transferts** du client.
- Le **Do Not Call Registry** de Singapour couvre les numéros de téléphone (voix, SMS et télécopie), pas l'email.

---

## Corée du Sud : article 50 du Network Act (et PIPA)

L'article 50 de l'**Act on Promotion of Information and Communications Network Utilization and Information Protection** (le « Network Act ») régit la « transmission d'informations publicitaires à des fins lucratives » par tout moyen électronique. La **Personal Information Protection Act (PIPA)**, sous la tutelle de la PIPC, régit les données sous-jacentes. La **Korea Communications Commission (KCC)** applique les règles sur le spam, avec l'appui opérationnel de l'Illegal Spam Response Center de la **KISA**.

> Sources : le texte des articles provient de la traduction anglaise officielle du Network Act par le Korea Legislation Research Institute (KLRI), consolidée jusqu'aux modifications du 23 janvier 2024. La page law.go.kr citée dans les sources (une modification partielle de 2026, lsiSeq=282481) ne fonctionne qu'avec JavaScript et n'a pas pu être lue directement ; la traduction du KLRI a donc été utilisée à la place.

- **Opt-in (article 50(1)).** Le **consentement exprès préalable** du destinataire est requis. Exception 1 : un expéditeur qui a **collecté directement les coordonnées lors d'une transaction** peut faire la publicité **du même type de biens ou de services qu'il commercialise** auprès de ce client, dans un délai fixé par décret présidentiel. Le décret d'application fixe **6 mois** à compter de la fin de la transaction (un chiffre du décret, auquel la loi renvoie). L'exception 2 concerne les télévendeurs relevant du Door-to-Door Sales Act (appels vocaux).
- **Refus ou retrait (article 50(2)).** Dès que le destinataire refuse ou révoque son consentement, l'envoi est interdit, même lorsque l'exception de transaction s'appliquait.
- **Règle des envois nocturnes (article 50(3)).** Les envois entre **21 h 00 et 08 h 00** le lendemain exigent un **consentement exprès distinct**, sauf pour les supports prévus par décret présidentiel. Le décret **exempte le courrier électronique** : la règle s'applique donc aux SMS et aux notifications push, pas à l'email (un détail du décret).
- **Mentions obligatoires (article 50(4)).** La publicité doit indiquer le **nom et les coordonnées de l'expéditeur** et les **moyens permettant au destinataire de refuser ou de révoquer facilement son consentement**. Pour l'email, le décret d'application impose la mention **« (광고) »** (« publicité ») au **début de la ligne d'objet** (un détail du décret).
- **Tactiques de contournement interdites (article 50(5), modifié en janvier 2024).** Bloquer ou contourner l'opt-out ; **générer automatiquement des adresses** en combinant des caractères (attaques par dictionnaire) ; **enregistrer automatiquement** des numéros de téléphone ou des adresses email pour l'envoi ; dissimuler l'identité de l'expéditeur ou la source de la transmission ; et recourir à des procédés trompeurs pour susciter des réponses.
- **Opt-out gratuit (article 50(6)).** Le destinataire ne doit supporter aucun coût (par exemple des frais d'appel) pour refuser ou révoquer son consentement.
- **Notification du résultat (article 50(7)).** L'expéditeur doit informer le destinataire du **résultat du traitement** de son consentement, de son refus ou de sa révocation. Selon le décret, cela se fait sous 14 jours, comme couramment appliqué (un détail du décret).
- **Reconfirmation périodique (article 50(8)).** Les expéditeurs doivent **vérifier régulièrement** que le destinataire consent toujours. Le décret d'application fixe un cycle de **2 ans** (un chiffre du décret).
- **Envoi externalisé (article 50-3).** Une entreprise qui confie l'envoi de ses publicités à un tiers doit **le contrôler et le superviser**. Pour la responsabilité en cas de dommages, l'expéditeur mandaté est **réputé être un employé de l'entreprise**. C'est l'équivalent coréen de « vous ne pouvez pas externaliser votre risque », et cela s'applique directement aux ESP.
- Les fournisseurs d'accès à Internet peuvent refuser les services utilisés pour des envois contraires aux règles (article 50-4). Les programmes qui affichent des publicités ou collectent des données exigent le consentement de l'utilisateur (article 50-5). Publier des publicités sur des sites web exige le consentement de l'exploitant (article 50-7).
- **Sanctions.**
  - Les violations de l'article 50(1)–(3) (envoi sans consentement, après un refus ou la nuit), (4) (mentions absentes ou fausses), (6) (report du coût sur le destinataire) et (8) (absence de reconfirmation) sont passibles d'une **amende administrative de 30 000 000 ₩ au plus** (article 76(1)7–9-2).
  - Les tactiques de contournement de l'article 50(5) relèvent du **pénal** et sont punies d'un emprisonnement de **1 an** au plus ou d'une amende de **10 000 000 ₩** au plus (article 74(1)4), avec responsabilité conjointe de la personne morale (article 75).
  - La PIPA ajoute des sanctions distinctes, et plus lourdes, pour la collecte ou l'utilisation illicite des données personnelles elles-mêmes.

---

## Vue de tri pour un ESP

- Les quatre pays sanctionnent les **défaillances du désabonnement** indépendamment du consentement. Le même parcours en un clic, gratuit et sans connexion, conçu pour l'[Australie](https://emailmarketing.net/fr/apprendre/conformite/australie-spam-act-2003-et-application-par-l-acma) et la [LCAP](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel), satisfait la Nouvelle-Zélande (5 jours ouvrés), Singapour (10 jours ouvrés), le Japon (arrêt dès le refus) et la Corée (arrêt immédiat et envoi d'une notification du résultat).
- Les mentions sont le piège propre à ces pays. `<ADV>` (Singapour, pour les envois en masse non sollicités) et **(광고)** (Corée) se placent dans la ligne d'objet. La Corée restreint en outre la nuit les canaux autres que l'email.
- La Corée et le Japon font tous deux de la **falsification de l'expéditeur** et des **listes d'adresses générées automatiquement** des infractions pénales. Refusez ces listes dès l'intégration d'un client (voir [Adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges) et [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement)).
- Le Japon (APPI), Singapour (PDPA) et la Corée (PIPA) ajoutent chacun une couche de protection des données, avec ses propres règles de consentement et de transfert pour les données d'adresse. Pour un ESP qui agit comme sous-traitant, le modèle de l'« intermédiaire de données » de la PDPA de Singapour énonce le plus clairement la répartition des responsabilités.

Ceci n'est pas un avis juridique. Voir l'[avertissement sur la conformité](https://emailmarketing.net/fr/apprendre/conformite).

# Mineurs et marketing par email : COPPA, le Children's Code britannique et l'article 8 du RGPD

> Quand la collecte de l'adresse email d'un enfant déclenche la COPPA américaine (règle des moins de 13 ans, consentement parental vérifiable, plan en six étapes de la FTC), les 15 normes de l'Age Appropriate Design Code britannique, les seuils d'âge de l'article 8 du RGPD, et ce que tout cela implique pour les formulaires d'inscription et les contrôles d'âge des ESP.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/mineurs-et-marketing-par-email

Si un formulaire d'inscription peut recueillir l'adresse email d'un enfant, les lois de protection de la vie privée des enfants s'appliquent avant même l'envoi du moindre message. Chacun de ces régimes considère une adresse email comme une **information personnelle concernant l'enfant** : c'est sa collecte qui déclenche l'application de la loi.

Un ESP et ses clients ont le plus de chances de rencontrer trois cadres : la COPPA Rule américaine (moins de 13 ans), le Children's Code britannique (moins de 18 ans) et les âges de consentement de l'article 8 du RGPD (de 13 à 16 ans, selon l'État membre). Les pratiques générales du consentement sont présentées dans [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement), et les lois sur le marketing qui s'appliquent aux adultes dans [CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis), la [LCAP](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel) et le [PECR britannique](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email).

## COPPA (États-Unis) : la règle des moins de 13 ans

Le Children's Online Privacy Protection Act (1998) et la COPPA Rule de la Federal Trade Commission (FTC) donnent aux parents le contrôle de ce qui est collecté en ligne auprès des enfants de **moins de 13 ans**. La règle figure au 16 C.F.R. Part 312. Elle est entrée en vigueur le 21 avril 2000, a été modifiée avec effet au 1er juillet 2013, puis **modifiée de nouveau le 22 avril 2025** : consultez la règle révisée pour le texte en vigueur.

La FTC fait appliquer la règle, tout comme les procureurs généraux des États et les autorités sectorielles. Les sanctions civiles peuvent atteindre **53 088 $ par violation**. Elles sont fixées selon des critères qui comprennent la gravité de la violation, les violations antérieures, le nombre d'enfants, le type d'informations, le partage avec des tiers et la taille de l'entreprise. Certaines affaires se règlent sans sanction, d'autres pour des millions.

La COPPA s'applique si l'une de ces conditions est remplie :

1. le site ou le service **s'adresse aux enfants de moins de 13 ans** et collecte des informations personnelles auprès d'eux ;
2. il s'adresse aux enfants de moins de 13 ans et **permet à d'autres de collecter** des informations personnelles auprès d'eux (réseaux publicitaires, plug-ins : l'exploitant est responsable de la collecte par des tiers sur son service) ;
3. c'est un service **grand public** qui a **effectivement connaissance** du fait qu'il collecte des informations personnelles auprès d'un enfant de moins de 13 ans ; ou
4. il exploite un réseau publicitaire ou un plug-in en ayant effectivement connaissance du fait qu'il collecte des informations personnelles directement auprès des utilisateurs d'un service destiné aux enfants.

La notion de « service en ligne » est large : applications mobiles, plateformes de jeu, plug-ins, réseaux publicitaires, voix sur IP (VoIP), jouets connectés et autres objets connectés (IoT), enceintes intelligentes. Les services étrangers destinés aux enfants américains, ou qui collectent sciemment auprès d'eux, sont couverts, tout comme les services américains qui collectent auprès d'enfants étrangers. Les organismes à but non lucratif hors du champ de la section 5 du FTC Act sont en général exemptés. Le Congrès s'est délibérément arrêté à 13 ans, et les adolescents sont donc hors du champ de la COPPA.

### Les « informations personnelles » incluent l'adresse email

La règle énumère : le prénom et le nom ; une adresse postale (rue et ville ou commune) ; les **coordonnées en ligne, c'est-à-dire une adresse email ou tout identifiant permettant un contact direct** (identifiants de messagerie instantanée, de VoIP ou de visioconférence, numéros de mobile) ; un pseudonyme ou nom d'utilisateur qui fait office de coordonnées en ligne ; un numéro de téléphone ; les identifiants délivrés par une autorité publique (numéro de sécurité sociale, carte d'identité d'un État, acte de naissance, passeport) ; les **identifiants persistants** (identifiant de cookie, adresse IP, numéro de série ou identifiant unique de l'appareil) ; une photo, une vidéo ou un fichier audio contenant l'image ou la voix d'un enfant ; une géolocalisation assez précise pour identifier une rue et une ville ou commune ; les identifiants biométriques ; et toute information sur l'enfant ou le parent combinée à l'un de ces éléments.

« Collecter » comprend le fait de demander ou d'inciter un enfant à fournir une information **même si elle est facultative**, de permettre à un enfant de la publier, et le **suivi passif**.

### Quand la collecte de l'adresse email d'un enfant déclenche la COPPA, et quand elle ne la déclenche pas

Les points de la FAQ qui concernent l'email, en résumé :

| Scénario | Conséquence au regard de la COPPA |
|---|---|
| Une newsletter ou un autre **contact répété par email** demandé par l'enfant | Autorisé au titre de l'**exception du contact multiple** (§ 312.5(c)(4)). Collectez les coordonnées en ligne de l'enfant et d'un parent, et adressez au parent une **information directe et la possibilité de s'y opposer** avant le début du contact continu. Ne les utilisez à aucune autre fin, ne les divulguez pas et ne les combinez pas avec d'autres données. Si l'information revient en rebond, vous n'avez pas fait d'« efforts raisonnables », et l'exception ne s'applique pas |
| Une **réponse unique** à une demande précise de l'enfant (répondre à une question, « Ask the Author ») | L'exception du contact unique (§ 312.5(c)(3)). Répondez une fois, puis **supprimez rapidement l'adresse**. Ne recontactez pas l'enfant, ne divulguez pas l'adresse et ne l'utilisez à aucune autre fin. Si vous choisissez de ne pas répondre, vous devez quand même la supprimer immédiatement |
| Une participation à un concours | L'exception du contact unique ne fonctionne que si vous ne collectez **que** les coordonnées en ligne, contactez l'enfant une seule fois (pour lui dire s'il a gagné), puis les supprimez. Si vous prévoyez de contacter l'enfant plusieurs fois, l'exception du contact multiple s'applique (information du parent et possibilité de s'opposer). Si vous collectez une adresse postale pour un lot, il vous faut une information complète du parent et un consentement vérifiable, ou vous pouvez envoyer le lot par les coordonnées du **parent** |
| Un **rappel de mot de passe** lors de l'inscription | L'exception du contact multiple (information et opposition du parent) si vous conservez l'adresse sous une forme récupérable. **Aucune information n'est nécessaire** si vous ne collectez rien d'autre, que l'enfant ne peut divulguer aucune information personnelle sur le service, et que vous hachez immédiatement et définitivement l'adresse de sorte qu'elle ne puisse être ni reconstituée ni utilisée pour contacter l'enfant |
| Collecter les coordonnées en ligne du **parent** pour demander le consentement | Autorisé (§ 312.5(c)(1)). Si vous n'obtenez pas le consentement dans un délai raisonnable, supprimez-les. Un numéro de mobile n'est **pas** une « coordonnée en ligne » et ne peut pas être collecté auprès de l'enfant pour engager la demande de consentement (une exception de la règle permet toutefois de collecter un numéro de mobile utilisé uniquement pour envoyer un SMS au parent afin de demander le consentement) |
| Cartes électroniques ou fonctions « transférer à un ami » sur un service destiné aux enfants | L'exception du contact unique ne s'applique que si le système collecte l'adresse email du destinataire (et au plus les prénoms), envoie le message immédiatement, supprime immédiatement les données et ne comporte **aucun champ de texte libre**. Un envoi différé relève de l'exception du contact multiple (information et opposition du parent au préalable). Si la fonction offre une possibilité quelconque de révéler d'autres informations personnelles, un consentement parental vérifiable complet est nécessaire (la méthode « email plus » n'est pas admise) |
| **Notifications push** d'une application destinée aux enfants | Le jeton de l'appareil est une coordonnée en ligne. L'exception du contact multiple peut s'appliquer (information et opposition du parent) si l'enfant a demandé les notifications et qu'elles portent sur le contenu de l'application |
| Informations collectées **auprès des parents ou d'autres adultes** au sujet d'enfants | Non couvertes : la COPPA ne vise que les informations collectées en ligne auprès des enfants |
| Un service grand public reçoit un email d'un utilisateur qui dit avoir moins de 13 ans | Le service peut répondre une fois au titre de l'exception du contact unique, puis supprimer l'email. Mais le message peut lui donner une **connaissance effective** concernant des données collectées auparavant (par exemple une adresse fournie à l'inscription), ce qui impose alors un consentement ou une suppression |

Les identifiants persistants utilisés uniquement pour le **fonctionnement interne** du service (communication réseau, authentification, publicité contextuelle, plafonnement de la fréquence, sécurité, conformité, analyse d'audience, protection anti-spam, débogage) ne nécessitent ni information ni consentement. La publicité comportementale et la constitution de profils sont explicitement exclues de cette définition.

### Le plan de conformité en six étapes de la FTC

1. **Déterminez si la COPPA vous concerne** en appliquant les quatre critères ci-dessus. Le fait qu'un service soit « destiné aux enfants » dépend de son sujet, de son contenu visuel et sonore, des personnages animés, des activités et incitations adaptées aux enfants, de l'âge des modèles, des célébrités enfantines, des publicités destinées aux enfants et des données empiriques sur l'audience. Une clause des conditions d'utilisation qui interdit l'accès aux moins de 13 ans n'empêche pas le service d'être destiné aux enfants.
2. **Publiez une politique de confidentialité conforme à la COPPA.** Placez un lien clair et visible sur la page d'accueil et à chaque point de collecte d'informations. Listez **tous les exploitants** qui collectent des informations par le service (nom, et adresse, téléphone ou email ; un seul exploitant peut répondre aux demandes, mais tous doivent être listés). Décrivez les types d'informations collectées, leurs utilisations et ce qui est divulgué à des tiers. Indiquez une **politique de conservation des données avec un délai de suppression** (la conservation indéfinie est interdite, un point sur lequel insiste la modification de 2025). Décrivez les droits des parents.
3. **Informez directement les parents avant la collecte.** L'avis doit contenir les faits essentiels dans l'avis lui-même. Un simple lien vers la politique de confidentialité n'est pas conforme, même si un lien doit aussi être inclus. L'avis indique que vous avez collecté les coordonnées du parent pour demander son consentement, ce que vous souhaitez collecter, comment ce sera utilisé et divulgué, comment consentir, et que vous supprimerez les coordonnées du parent si le consentement n'arrive pas dans un délai raisonnable. Tout changement important exige une nouvelle information et un nouveau consentement.
4. **Obtenez un consentement parental vérifiable** avant de collecter, d'utiliser ou de divulguer des informations. Les méthodes admises sont : un formulaire de consentement signé (par courrier, télécopie ou numérisation) ; une carte de crédit, une carte de débit ou un paiement en ligne **avec notification de la transaction** au titulaire du compte ; un appel à un numéro gratuit ou une visioconférence avec un personnel formé ; la vérification d'une pièce d'identité officielle dans une base de données (supprimez la pièce après la vérification) ; des questions de contrôle fondées sur des connaissances ; et une pièce d'identité avec photo comparée par reconnaissance faciale à une seconde photo que le parent soumet (supprimez les deux après la comparaison). Si les données sont utilisées **en interne uniquement** (aucune divulgation, rien de public), la méthode **« email plus »** suffit : un consentement par email de retour, suivi d'une étape de confirmation, comme un appel, une télécopie ou une lettre de suivi, ou un message de confirmation différé qui rappelle l'information et explique comment révoquer le consentement. La simple saisie d'un mot de passe de boutique d'applications ne garantit pas suffisamment que c'est le parent qui consent. La divulgation à des tiers exige un consentement distinct, sauf si elle fait partie intégrante du service.
5. **Respectez les droits continus des parents.** Sur demande, permettez aux parents de consulter les données de l'enfant, de révoquer le consentement ou de refuser toute nouvelle collecte, et de supprimer les données. Vérifiez que vous avez bien affaire au parent (un code PIN ou un mot de passe remis lors du consentement aide). Vous ne pouvez mettre fin à l'utilisation du service par l'enfant après une révocation que si les données sont raisonnablement nécessaires à sa participation.
6. **Sécurisez, conservez et supprimez correctement les données.** Tenez un programme écrit de sécurité de l'information, avec des garanties proportionnées à la sensibilité des données et à la taille de l'entreprise. Ne communiquez les données qu'à des parties capables de les protéger, avec des assurances écrites. Tenez une politique écrite de conservation et de suppression. Collectez le moins possible, ne conservez les données que le temps raisonnablement nécessaire, puis détruisez-les de manière sécurisée.

### Les contrôles d'âge au regard de la COPPA

- Un service **grand public** n'est pas tenu de demander l'âge, et **peut bloquer** entièrement les moins de 13 ans. S'il contrôle l'âge, ce contrôle doit être **neutre**. Laissez les utilisateurs saisir librement leur mois et leur année de naissance. N'utilisez pas de listes déroulantes qui ne proposent que des années de naissance correspondant à 13 ans et plus, de cases « j'ai plus de 12 ans », ni d'avertissements indiquant que les moins de 13 ans ne peuvent pas participer ou doivent demander à un parent (cela apprend aux enfants à mentir). Le personnel de la FTC recommande un **cookie qui empêche les utilisateurs de revenir en arrière** pour saisir un autre âge. Un service qui demande l'âge sans ensuite exclure les enfants ou obtenir le consentement engage sa responsabilité (affaires de la FTC : Path, Playdom, Sony BMG, Yelp).
- Un service **à audience mixte** (destiné aux enfants au regard des critères ci-dessus, mais dont les enfants ne sont pas l'audience principale) peut contrôler l'âge, mais **ne peut pas bloquer** les moins de 13 ans. Il doit soit ne pas collecter d'informations auprès d'eux, soit obtenir le consentement parental. Il ne doit collecter aucune information personnelle avant la question sur l'âge. Un problème de mathématiques à la place d'une question sur l'âge n'est pas adéquat (il n'est admis qu'en complément).
- Un service **destiné aux enfants** (dont les enfants sont l'audience principale) ne peut pas du tout contrôler l'âge : chaque visiteur bénéficie des protections de la COPPA.
- Les exploitants peuvent se fier à l'âge que les utilisateurs saisissent sur un écran neutre, même s'il est faux. Une connaissance effective peut survenir plus tard (par exemple par la plainte d'un parent, ou une publication modérée qui révèle l'âge ou la classe d'un utilisateur), et elle impose alors un consentement ou une suppression.

## Le Children's Code britannique (Age Appropriate Design Code)

L'Information Commissioner's Office (ICO) a publié ce code légal en application du Data Protection Act (DPA) 2018. Il s'applique aux **« services de la société de l'information susceptibles d'être utilisés par des enfants »** (*information society services likely to be accessed by children*), les enfants s'entendant de toute personne de **moins de 18 ans**, un groupe bien plus large que celui des moins de 13 ans de la COPPA. « Susceptibles d'être utilisés » couvre les services que les enfants utilisent même lorsqu'ils n'en sont pas le public cible. Le code s'étend aux applications, jeux, moteurs de recherche, plateformes sociales, places de marché, services de streaming, sites d'information et éducatifs et jouets connectés, ainsi qu'aux **entreprises situées hors du Royaume-Uni** qui traitent les données d'enfants britanniques. Il ne s'applique pas aux écoles, même si les fournisseurs de technologies éducatives au service des écoles peuvent être concernés. L'ICO apprécie la conformité à l'UK GDPR et au DPA 2018 pour les données d'enfants au regard du respect du code, et les manquements sont donc sanctionnés avec les pouvoirs habituels de l'UK GDPR.

Les 15 normes (celles qui concernent l'email et le marketing sont en gras) :

| N° | Norme | Exigence en une ligne |
|---|---|---|
| 1 | Intérêt supérieur de l'enfant | La considération primordiale dans la conception et le développement |
| 2 | AIPD | Évaluer et réduire les risques pour les enfants, selon l'âge et le stade de développement, dans une analyse d'impact relative à la protection des données |
| 3 | **Application adaptée à l'âge** | Établir l'âge des utilisateurs avec un degré de certitude proportionné au risque du traitement de données, **ou appliquer les normes du code à tous les utilisateurs** |
| 4 | Transparence | Des informations de confidentialité concises, visibles et adaptées à l'âge de l'enfant, avec des explications courtes au moment où elles sont utiles |
| 5 | **Utilisation préjudiciable des données** | Aucune utilisation dont il est démontré qu'elle nuit au bien-être, ou qui enfreint des codes sectoriels, des dispositions réglementaires ou des recommandations des pouvoirs publics |
| 6 | Politiques et règles communautaires | Respecter réellement les conditions, restrictions d'âge et politiques que vous publiez |
| 7 | **Paramètres par défaut** | « Haut niveau de confidentialité » par défaut, sauf raison impérieuse tenant à l'intérêt supérieur de l'enfant |
| 8 | **Minimisation des données** | Ne collecter et ne conserver que le minimum nécessaire aux fonctions que l'enfant utilise activement, avec un choix distinct pour chaque fonction |
| 9 | **Partage des données** | Aucune divulgation des données d'enfants sans raison impérieuse tenant à l'intérêt supérieur de l'enfant |
| 10 | Géolocalisation | Désactivée par défaut, avec un signal visible lorsqu'elle est active. La visibilité par autrui revient à « désactivée » à la fin de chaque session |
| 11 | Contrôle parental | Des informations adaptées à l'âge de l'enfant, et un signal visible pour l'enfant lorsqu'il est surveillé |
| 12 | **Profilage** | Désactivé par défaut, et uniquement avec des mesures qui protègent l'enfant contre les effets préjudiciables |
| 13 | **Techniques d'incitation** | Ne pas pousser les enfants à fournir des données inutiles ou à affaiblir leurs protections de confidentialité |
| 14 | Jouets et appareils connectés | Inclure des outils de conformité efficaces |
| 15 | Outils en ligne | Des outils bien visibles permettant aux enfants d'exercer leurs droits et de signaler leurs préoccupations |

Pour le marketing par email, ce sont les normes 3, 7, 8, 12 et 13 qui ont le plus d'effet. Un parcours d'inscription « susceptible d'être utilisé » par des moins de 18 ans ne peut pas précocher les options de marketing, pousser les mineurs à accepter l'opt-in, les profiler par défaut à des fins de ciblage, ni recueillir une adresse email au-delà de ce qu'exige la fonction demandée. Si le service ne vérifie pas l'âge des utilisateurs, il doit appliquer ces paramètres par défaut prévus pour les enfants **à tout le monde**.

## L'article 8 du RGPD : âges du consentement pour les services de la société de l'information

L'article 8 s'applique lorsqu'un service de la société de l'information est proposé **directement à un enfant** et repose sur le **consentement** (article 6(1)(a)), la base légale qu'utilise normalement le marketing par email. Le consentement de l'enfant lui-même n'est valable qu'**à partir de 16 ans**. En dessous de cet âge, « ce traitement n'est licite que si, et dans la mesure où, le consentement est donné ou autorisé par le titulaire de la responsabilité parentale à l'égard de l'enfant ».

Les États membres peuvent abaisser ce seuil par la loi, **mais pas en dessous de 13 ans** : l'âge du consentement numérique varie donc de 13 à 16 ans dans l'UE. Le Royaume-Uni a fixé 13 ans dans le Data Protection Act 2018, ce qui explique que les lignes directrices de l'ICO sur le marketing retiennent 13 ans comme âge minimal pour le consentement propre d'un mineur. Le responsable du traitement **« s'efforce raisonnablement de vérifier »** que le consentement est donné ou autorisé par le titulaire de la responsabilité parentale, « compte tenu des moyens technologiques disponibles ».

Ce que cela implique pour un formulaire d'inscription destiné à l'Europe : en dessous de l'âge national applicable, l'opt-in donné par l'enfant lui-même n'est pas un consentement valable. À partir de cet âge, un simple opt-in fonctionne, mais les règles de qualité du consentement du [PECR](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email) et d'ePrivacy s'appliquent toujours.

## Conséquences pour la politique d'un ESP

Pris ensemble, les trois régimes ont les conséquences suivantes pour les règles de la plateforme d'un ESP et pour les formulaires de ses clients :

- **Contrôles d'âge sur les formulaires d'inscription.** Les formulaires hébergés destinés au grand public qui veulent exclure les mineurs devraient utiliser un champ de date de naissance neutre. N'utilisez jamais un sélecteur qui ne propose que les âges de 13 ans et plus ou de 16 ans et plus, n'utilisez jamais de case « j'ai plus de N ans », et n'ajoutez aucun texte dissuasif. Conservez la réponse (dans un cookie) pour que les utilisateurs ne puissent pas revenir en arrière et réessayer. Bloquer les répondants qui n'ont pas l'âge requis est licite pour les services grand public dans tous les régimes. Le risque consiste à demander l'âge puis à ignorer la réponse, ce qui transforme l'ignorance en connaissance effective.
- **Les clients dont l'audience est composée d'enfants constituent une catégorie de risque à part.** Ils ont besoin du processus de la COPPA (information directe, consentement parental vérifiable, et opposition proposée aux parents au titre de l'exception du contact multiple pour les newsletters), qu'un parcours standard d'inscription puis de confirmation ne fournit pas. Un ESP devrait soit prendre en charge un consentement recueilli par l'intermédiaire du parent (adresse du parent collectée avec celle de l'enfant, information envoyée au parent, opposition respectée avant tout envoi continu), soit interdire les listes destinées aux enfants dans sa politique d'utilisation acceptable (AUP).
- **Les preuves de consentement doivent montrer de qui émane le consentement.** Pour les mineurs, la [preuve du consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement) doit comporter l'identité ou les coordonnées du parent et la méthode de vérification utilisée. Un opt-in horodaté provenant de l'adresse de l'enfant lui-même ne prouve rien dans aucun de ces régimes.
- **La suppression fait partie du cycle de vie.** Les exceptions de contact unique de la COPPA et le droit de révocation du parent, les normes du Children's Code sur la minimisation et la conservation des données, et l'effacement au titre du RGPD imposent tous que les adresses d'enfants soient supprimées rapidement, d'une manière que vous pouvez prouver, et pas seulement placées en liste de suppression.
- **Surveillez la connaissance effective.** Les tickets de support, les réponses et les plaintes qui révèlent qu'un abonné est un enfant donnent à l'expéditeur une connaissance effective (et, on peut le soutenir, à l'ESP qui traite les données pour son compte). Les réponses conformes sont le consentement parental ou la suppression. Continuer d'envoyer des messages constitue la violation.
- **Le droit du marketing s'applique toujours en plus.** Rien de ce qui précède ne remplace [CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis), la [LCAP](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel) ou le [PECR](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email). Une newsletter pour enfants consentie par un parent exige toujours des en-têtes véridiques, l'identification de l'expéditeur et un désabonnement fonctionnel.

Ces synthèses suivent les lignes directrices publiées par les autorités (celles de la FTC dans sa révision du plan en six étapes de mai 2026 et la modification de la COPPA Rule du 22 avril 2025, et le texte du code de l'ICO tel que publié). Elles ne constituent pas un avis juridique.

# Pays-Bas (ACM) et la question de l'email B2B selon les juridictions

> Les règles néerlandaises sur le spam au titre de l'article 11.7 de la Telecommunicatiewet (ACM), les lignes directrices de l'ICO sur le marketing B2B, et une réponse comparée à la question « puis-je écrire à des adresses professionnelles sans consentement ? » pour le Royaume-Uni, la France, l'Allemagne et les Pays-Bas.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/pays-bas-et-la-question-du-b2b

Si vous envoyez des emails de marketing à des adresses professionnelles en Europe, la nécessité d'un consentement dépend du pays de chaque destinataire. « L'email B2B n'a pas besoin de consentement » est l'une des généralisations les plus dangereuses de la conformité email.

La règle d'opt-in de la directive ePrivacy (article 13) protège les **personnes physiques** et laisse chaque État membre décider jusqu'où protéger les **personnes morales** : la réponse pour l'email entre entreprises (B2B) change donc à chaque frontière. Vous trouverez ci-dessous les règles néerlandaises, que fait appliquer l'Autorité des consommateurs et des marchés (ACM), les lignes directrices B2B de l'Information Commissioner's Office (ICO) au Royaume-Uni, et une comparaison détaillée entre le Royaume-Uni, la France, l'Allemagne et les Pays-Bas.

Une campagne adressée à une liste B2B européenne mixte doit respecter **la règle la plus stricte applicable à chaque destinataire**. C'est le pays du destinataire qui détermine la règle, et non celui de l'expéditeur.

## Pays-Bas : article 11.7 de la Telecommunicatiewet (autorité : ACM)

L'interdiction néerlandaise du spam figure à l'**article 11.7 de la Telecommunicatiewet**, et l'**Autoriteit Consument en Markt (ACM)** la fait appliquer. L'ACM est l'autorité de la consommation et des marchés. Ce n'est pas l'autorité de protection des données : celle-ci est l'Autoriteit Persoonsgegevens (AP), qui s'occupe du volet RGPD.

**La règle de base est l'opt-in.** Les messages commerciaux électroniques non sollicités (email, SMS et, explicitement, des canaux comme **WhatsApp**) exigent le consentement préalable du destinataire. Le consentement ne peut pas être obtenu par :

- des cases précochées ;
- des tactiques de pression ;
- une mention enfouie dans les conditions générales.

La demande de consentement doit viser clairement les **messages promotionnels ou de sollicitation**. Exigence propre aux Pays-Bas, l'expéditeur doit pouvoir **prouver le consentement jusqu'à 5 ans après l'envoi**. C'est la durée de conservation du consentement la plus concrète qu'une autorité de l'UE publie : concevez vos preuves de consentement pour la respecter.

**Portée B2B.** Depuis le **1er octobre 2009**, l'interdiction couvre aussi les **personnes morales**. Le droit néerlandais a étendu l'opt-in aux destinataires professionnels et mis fin au régime d'opt-out qui s'appliquait auparavant au B2B. Les lignes directrices actuelles de l'ACM ne font aucune distinction entre le courrier B2B et le courrier destiné aux consommateurs (B2C) : les règles s'appliquent de la même façon à tous les destinataires. La page de l'ACM ne retrace plus cet historique, et la date de l'extension de 2009 est donc confirmée par des commentaires juridiques : la note de CMS « Dutch new law prohibits B2B spam » et des synthèses de cabinets d'avocats néerlandais.

**Exception pour les clients existants.** Des messages non sollicités peuvent être envoyés à des clients existants au sujet de **produits ou services liés à des achats antérieurs**, à condition que :

- les destinataires puissent facilement se désabonner ; et
- l'identité de l'expéditeur soit clairement indiquée.

**Identification de l'expéditeur.** L'expéditeur doit être clairement identifiable par sa raison sociale ou son adresse email. **Les pseudonymes ne sont pas autorisés.**

**Désabonnement.** Chaque message doit comporter un opt-out qui soit :

- **rapide**, sans questionnaire complexe ;
- **gratuit**, sans paiement ni demande de données personnelles supplémentaires.

**Les campagnes « parlez-en à un ami »** ne sont licites que si ces cinq conditions sont toutes réunies :

1. la personne qui partage transfère le message volontairement, et **aucune incitation** ne peut être offerte ;
2. le message transféré affiche des coordonnées pour les réclamations ;
3. la personne qui partage peut voir le message complet avant son envoi ;
4. les données personnelles utilisées pour le transfert sont **supprimées ensuite** et ne sont pas réutilisées ;
5. le site web est protégé contre les abus automatisés à des fins de spam.

Au Royaume-Uni, à titre de comparaison, l'ICO conclut que le parrainage par email assorti d'une incitation ne peut généralement pas être pratiqué licitement (voir le [PECR britannique](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email)).

**Champ d'application et responsabilité.** Les règles s'appliquent aux envois dans tout l'**Espace économique européen (EEE)** : l'UE, plus l'Islande, la Norvège et le Liechtenstein. Hors de l'EEE, les règles locales s'appliquent. La responsabilité ne pèse pas seulement sur la partie qui transmet le message, mais aussi sur l'**instigateur** et sur les prestataires tiers qui aident à le diffuser. Le PECR et la LCAP visent de la même manière expéditeurs et instigateurs, et c'est pourquoi les conditions d'utilisation des ESP doivent obliger les clients à respecter ces règles.

## Royaume-Uni : les lignes directrices de l'ICO sur le marketing entre entreprises

Les lignes directrices B2B dédiées de l'ICO sont en cours de révision à la suite des modifications apportées par le Data (Use and Access) Act. Elles reposent sur la distinction que font les Privacy and Electronic Communications Regulations (PECR) entre **abonnés personnes morales** et **abonnés individuels**, présentée dans [Royaume-Uni : le PECR et le marketing par email](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email) et développée ici pour le courrier B2B.

### Qui est un abonné personne morale

Les abonnés personnes morales sont les entités dotées de leur propre personnalité juridique : sociétés, *corporations sole*, **limited liability partnerships**, **sociétés de personnes écossaises**, certains organismes publics et toute autre personne morale distincte de ses membres. **L'adresse email ou le numéro de téléphone professionnel d'un salarié d'une personne morale relève de l'abonné personne morale**, car l'abonné est l'employeur.

Certaines entreprises sont traitées comme des **abonnés individuels** : les **entrepreneurs individuels**, les sociétés de personnes qui ne sont pas des limited liability partnerships (LLP) en Angleterre, au pays de Galles et en Irlande du Nord, et les autres groupements de personnes non constitués en société. Ils bénéficient de toutes les protections accordées aux personnes physiques.

### La règle du PECR sur l'email pour le B2B

| Destinataire | Un email de marketing exige-t-il un consentement au titre du PECR ? |
|---|---|
| Abonné personne morale (toute adresse de salarié d'une société ou d'une LLP) | **Non**, mais vous ne devez pas déguiser ni dissimuler votre identité, et vous devez fournir une adresse valable pour l'opt-out ou le désabonnement |
| Entrepreneur individuel, ou société de personnes qui n'est pas une LLP | **Oui** : consentement ou soft opt-in |

Pour les abonnés personnes morales, le PECR n'impose pas littéralement de respecter l'opt-out. L'ICO considère toutefois que l'adresse d'opt-out obligatoire signifie clairement que les abonnés personnes morales doivent pouvoir se désabonner : **vous devriez donc respecter l'opt-out d'un abonné personne morale**. Lorsque des données personnelles sont en jeu, le droit d'opposition peut vous y obliger. Tenez une liste « ne pas écrire » des opt-out des personnes morales, et filtrez chaque nouvelle liste B2B à partir de celle-ci.

**Le soft opt-in pour les entrepreneurs individuels et les sociétés de personnes** exige les quatre conditions : les coordonnées ont été obtenues lors d'une vente ou de la négociation d'une vente ; vous ne faites la promotion que de vos propres produits ou services similaires ; vous avez proposé un opt-out clair lors de la collecte ; et vous proposez un opt-out dans chaque message. L'ICO donne l'exemple d'une entreprise en ligne de fournitures de construction dont les clients sont en majorité des entrepreneurs individuels. Elle applique le soft opt-in à **tous** ses clients lors du paiement, avec une explication, une case d'opt-out et un lien de désabonnement dans chaque email. Cette conception uniforme est la plus sûre.

**Si vous ne connaissez pas le type d'abonné, traitez le destinataire comme un abonné individuel.** Si vous ne pouvez pas déterminer si une adresse appartient à un abonné personne morale ou individuel, présumer qu'il s'agit d'une personne morale risque d'enfreindre le PECR, et l'ICO recommande d'appliquer les règles des abonnés individuels. En pratique, deviner à partir du domaine (« cela ressemble à un domaine d'entreprise ») ne permet pas de distinguer une société à responsabilité limitée d'un entrepreneur individuel. C'est une raison de plus de préférer les listes B2B fondées sur le consentement aux listes issues du scraping.

### L'UK GDPR en plus du PECR

- Un contact professionnel nommé (un nom et un numéro enregistrés, ou une adresse du type prenom.nom@company.com) est une **donnée personnelle**, même dans un cadre professionnel. L'UK GDPR s'applique pleinement, y compris le **droit absolu de s'opposer** à la prospection directe. Les contacts non nominatifs (« le service informatique », info@company.com) ne sont pas des données personnelles.
- **Cartes professionnelles.** Une carte rangée dans un tiroir échappe à l'UK GDPR. Dès que ses coordonnées sont ajoutées à une base de contacts, l'UK GDPR s'applique.
- **Base légale.** Lorsque le PECR exige le consentement, utilisez le consentement. Lorsqu'il ne l'exige pas, l'**intérêt légitime** convient généralement, sous réserve du test en trois étapes : identifier l'intérêt, démontrer la nécessité, et le mettre en balance avec les intérêts de la personne.
- **Transparence.** Lors de la collecte, indiquez aux contacts professionnels que vous leur enverrez du marketing. Pour les coordonnées obtenues auprès de sources publiques ou de tiers, fournissez l'information sur la confidentialité dans un délai raisonnable, d'**un mois** au plus.
- **Utiliser des données pour une nouvelle finalité.** L'exemple de l'organisateur de conférences donné par l'ICO montre qu'écrire après coup aux adresses professionnelles vérifiées des participants peut passer une évaluation de compatibilité et de ce que les participants peuvent attendre. **Vendre** les coordonnées des participants sans les en avoir informés ne passe pas le test de loyauté. Les acheteurs de telles listes enfreindraient le PECR pour tout abonné individuel, car le consentement doit nommer l'expéditeur.
- **Données accessibles au public** (sites d'entreprise, Companies House, réseaux sociaux, presse). Être accessible au public ne vaut pas consentement. Le PECR s'applique toujours aux appels, emails et télécopies envoyés à partir de coordonnées issues du scraping, et l'UK GDPR s'applique dès que les données identifient une personne. Les personnes présentes sur des **réseaux sociaux professionnels** y sont généralement à titre personnel, même si ce titre est professionnel. Leur écrire n'est pas du « marketing B2B », et l'UK GDPR comme le PECR s'appliquent aux messages directs.
- **Oppositions.** Respectez les opt-out et les retraits du consentement. Placez les personnes qui s'opposent sur une **liste de suppression plutôt que de les supprimer**, afin de pouvoir filtrer les futures listes (voir [Droit d'opposition et droit à l'effacement](https://emailmarketing.net/fr/apprendre/conformite/droit-d-opposition-et-droit-a-l-effacement)). Dans l'exemple de l'ICO, un cabinet de recrutement qui écrit à la directrice des ressources humaines nommée d'une société à responsabilité limitée n'a besoin d'aucun consentement au titre du PECR. Quand la directrice lui demande d'arrêter, il arrête et place l'adresse en liste de suppression, car l'adresse nominative est une donnée personnelle et l'opposition est absolue.

## Le tableau B2B comparé

« Puis-je écrire à une adresse professionnelle sans consentement préalable ? » dans les quatre principaux marchés :

| | **Royaume-Uni** | **France** | **Allemagne** | **Pays-Bas** |
|---|---|---|---|---|
| Texte et autorité | PECR, appliqué par l'ICO | Article L.34-5 du CPCE, appliqué par la CNIL | UWG §7, appliqué par les tribunaux (les concurrents et les organismes de consommateurs agissent en justice ; les autorités de protection des données traitent le volet RGPD) | Article 11.7 de la Telecommunicatiewet, appliqué par l'ACM |
| Email à un salarié d'une personne morale | **Autorisé sans consentement** (abonné personne morale) ; identité et adresse d'opt-out obligatoires | **Autorisé sans consentement** si le message **est en rapport avec la profession du destinataire**, que celui-ci a été informé et qu'il peut s'opposer simplement et gratuitement | **Consentement requis** : le §7(2) exige un consentement exprès préalable pour la publicité par email, sans exception pour le B2B | **Consentement requis** : opt-in étendu aux personnes morales le 1er oct. 2009 |
| Adresse de rôle générique (info@, contact@) | Le PECR s'applique toujours (la règle dépend du type d'abonné, pas de la forme de l'adresse), mais faute de donnée personnelle, l'UK GDPR ne s'applique pas | **Hors du champ des règles de consentement et d'opposition** (une personne morale, aucune personne physique) | Consentement toujours requis (le §7(2) protège les participants au marché en général) | L'opt-in s'applique (les personnes morales sont couvertes) |
| Entrepreneurs individuels | **Abonnés individuels** : consentement ou soft opt-in | Personnes physiques : consentement (ou exception pour les clients existants) | Consentement | Consentement (les personnes physiques sont toujours couvertes) |
| Exception pour les clients existants | Soft opt-in : coordonnées obtenues lors d'une vente ou d'une négociation, vos propres produits similaires, opt-out lors de la collecte et dans chaque message | Même idée ; exige une vente ou une prestation effectivement réalisée ; opt-out lors de la collecte et dans chaque message | §7(3) : adresse obtenue **dans le cadre d'une vente**, vos propres biens ou services **similaires** (selon les tribunaux : interchangeables, ou répondant au même besoin), absence d'opposition, avis indiquant que l'opposition est gratuite, donné lors de la collecte **et à chaque utilisation** | Produits ou services liés à un achat antérieur ; désabonnement facile ; identité claire de l'expéditeur |
| Particularités notables | Droit absolu d'opposition lorsque l'adresse désigne une personne | Les pixels utilisés pour la délivrabilité exigent un consentement en dehors du périmètre exempté (voir [France (CNIL)](https://emailmarketing.net/fr/apprendre/conformite/france-regles-de-la-cnil-sur-la-prospection-par-email)) | Le **double opt-in** documenté est de fait la norme de preuve (jurisprudence de la Cour fédérale de justice (BGH) sur la preuve du consentement), et la certification de la Certified Senders Alliance (CSA) l'intègre (voir [GMX et WEB.DE](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/gmx-web-de-exigences-postmaster)) | Consentement à prouver **5 ans** après l'envoi ; WhatsApp dans le champ |

Pour l'Allemagne, les conditions légales résumées ci-dessus pour le §7(2) et le §7(3) sont vérifiées par rapport à la traduction anglaise officielle publiée sur gesetze-im-internet.de, qui n'est pas contraignante et qui est citée dans [Allemagne : l'UWG, §7, et le marketing par email](https://emailmarketing.net/fr/apprendre/conformite/allemagne-article-7-de-l-uwg-et-marketing-par-email). Seul le texte allemand fait foi.

La conséquence pratique est que l'affirmation « la prospection B2B à froid est acceptable en Europe » est **fausse dans deux des quatre plus grands marchés**, car l'Allemagne et les Pays-Bas exigent l'opt-in même pour les adresses de personnes morales. Elle n'est **vraie que sous conditions en France** (le message est en rapport avec la profession du destinataire, celui-ci a été informé et il peut s'opposer). Elle n'est **vraie que pour les véritables abonnés personnes morales au Royaume-Uni**, où aucune liste achetée ne permet de distinguer les entrepreneurs individuels.

La délivrabilité ajoute une couche supplémentaire. Les emails destinés aux entreprises passent par des passerelles et des environnements professionnels dotés de leurs propres systèmes de réputation, et les emails à froid génèrent les plaintes et les adresses pièges touchées décrites dans [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement). La collecte du consentement reste la seule stratégie qui fonctionne dans chacun de ces marchés.

# Royaume-Uni : le PECR et le marketing par courrier électronique

> Les lignes directrices de l'ICO sur la prospection directe par courrier électronique au titre du PECR et de l'UK GDPR : norme de consentement, les deux soft opt-in, abonnés individuels et abonnés personnes morales, listes achetées et parrainage.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email

Si vous envoyez des emails ou des SMS de prospection à des personnes au Royaume-Uni, vous avez en général besoin de leur consentement, sauf si l'une des deux exceptions dites « soft opt-in » s'applique. Les règles sont fixées par les Privacy and Electronic Communications Regulations (PECR). Lorsque des informations personnelles sont utilisées, l'UK GDPR et le Data Protection Act 2018 s'appliquent aussi.

L'Information Commissioner's Office (ICO), l'autorité britannique, publie ces lignes directrices et en assure le respect. Comme la [LCAP canadienne](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel), et contrairement au [CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis) américain, le PECR est un régime d'**opt-in** pour les abonnés individuels, assorti des deux exceptions de soft opt-in.

Ceci n'est pas un avis juridique. Vérifiez les sanctions et les seuils auprès de la source primaire (ci-dessous) et d'un avocat avant de vous y fier. Voir l'[avertissement sur la conformité](https://emailmarketing.net/fr/apprendre/conformite).

## Définitions clés

**Prospection directe** (*direct marketing*). Le Data (Use and Access) Act a inséré dans le PECR cette définition reprise du Data Protection Act (DPA), avec effet au 20 août 2025 : « la communication (par quelque moyen que ce soit) de matériel publicitaire ou marketing adressé à des personnes déterminées » (*"the communication (by whatever means) of advertising or marketing material which is directed to particular individuals."*). Elle couvre le marketing commercial **et la promotion d'objectifs et d'idéaux**. Les messages purement de service ou administratifs ne sont pas de la prospection directe, mais l'ajout de tout élément promotionnel à un message de service en fait de la prospection directe.

**Courrier électronique** (*electronic mail*) : « tout message textuel, vocal, sonore ou image envoyé sur un réseau public de communications électroniques, qui peut être stocké dans le réseau ou dans l'équipement terminal du destinataire jusqu'à ce que ce dernier le récupère, y compris les messages envoyés au moyen d'un service de messages courts » (*"any text, voice, sound or image message sent over a public electronic communications network which can be stored in the network or in the recipient's terminal equipment until it is collected by the recipient and includes messages sent using a short message service."*). Cela couvre :

- l'email et le SMS ;
- les messages photo et vidéo ;
- les messages vocaux laissés sur une messagerie ;
- les messages dans les applications ;
- les messages directs (privés) sur les réseaux sociaux.

Cela ne couvre **pas** les publicités display ou les bannières en ligne, ni les publicités dans le fil des réseaux sociaux (même ciblées), car elles sont publiques et ne sont pas stockées pour un destinataire précis. D'autres règles du PECR, comme celles sur les technologies de stockage et d'accès, peuvent s'y appliquer.

**Prospection sollicitée et non sollicitée.** La prospection n'est *sollicitée* que lorsqu'une personne demande expressément un message ou un type d'information précis (par exemple « envoyez-moi par email votre brochure d'été »). Tout le reste, y compris les relances adressées à cette personne, est *non sollicité*. La prospection sollicitée ne nécessite ni consentement ni soft opt-in.

**Abonné** (*subscriber*) : la personne ou l'organisation dont le nom figure sur la facture de la ligne téléphonique, de la connexion Internet ou de l'autre service de communications. Il en existe deux types :

- **les abonnés individuels** : les personnes physiques, les entrepreneurs individuels et les sociétés de personnes ordinaires ;
- **les abonnés personnes morales** : les organisations dotées de leur propre personnalité juridique (sociétés à responsabilité limitée, limited liability partnerships (LLP), sociétés de personnes écossaises).

Le PECR s'applique **même aux adresses génériques ou de rôle** : il n'est donc pas nécessaire de connaître le nom du destinataire pour qu'il s'applique. Si des informations personnelles sont utilisées, le droit de la protection des données s'applique aussi.

## Quelles règles s'appliquent à qui (B2B ou B2C)

| Message | Abonné individuel | Abonné personne morale |
|---|---|---|
| Prospection sollicitée | Autorisée sans consentement | Autorisée sans consentement |
| Prospection non sollicitée | Exige un **consentement** ou un **soft opt-in** | Autorisée sans consentement ni soft opt-in |
| Divulgation de l'identité | Ne pas déguiser ni dissimuler l'identité de l'expéditeur | Idem |
| Adresse de contact pour l'opt-out | Obligatoire | Obligatoire |

Prudence avec le « B2B ». Les entrepreneurs individuels et les sociétés de personnes ordinaires comptent comme des abonnés **individuels**, et les règles de consentement s'appliquent donc à eux. Les adresses professionnelles des salariés de sociétés à responsabilité limitée restent des données personnelles : l'UK GDPR, y compris le droit absolu d'opposition, s'applique donc même lorsque le PECR n'exige pas de consentement.

## Qui doit se conformer

Le PECR s'applique à quiconque **envoie ou fait envoyer** (*instigates*) de la prospection par courrier électronique. Faire envoyer comprend le fait d'encourager, d'inciter, d'offrir une incitation à quelqu'un d'autre ou de lui demander de l'envoyer. Si une autre organisation envoie de la prospection pour le compte d'une marque, **les deux** sont responsables : l'instigateur et l'expéditeur. Un service de webmail ou une plateforme d'envoi en masse qui ne fournit que la livraison technique n'est normalement **pas** responsable.

Si un tiers envoie pour le compte d'un expéditeur de la prospection qui utilise des informations personnelles, un contrat écrit est requis, ainsi que des vérifications de conformité appropriées. Un abonné ne doit pas non plus permettre à d'autres d'utiliser sa ligne ou sa connexion pour enfreindre les règles.

## Consentement

Le PECR reprend la norme de consentement de l'UK GDPR : « toute manifestation de volonté, libre, spécifique, éclairée et univoque, par laquelle la personne concernée accepte, par une déclaration ou par un acte positif clair » (*"any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement."*).

Lorsque vous demandez le consentement, il doit être :

- **Libre.** Un véritable choix, que les personnes peuvent refuser sans aucun préjudice, et séparé des conditions générales. Faire de l'acceptation de la prospection une condition d'un achat ou d'un don a peu de chances d'être valable.
- **Spécifique et éclairé.** La demande doit nommer l'organisation et indiquer clairement qu'elle porte sur la prospection par courrier électronique. « Je souhaite recevoir du marketing », sans nommer le canal, n'est pas assez spécifique. Demandez séparément pour chaque canal (email et SMS).
- **Univoque, par un acte positif clair.** Les cases précochées, le silence et l'inaction ne comptent pas.
- **Enregistré.** Conservez une trace de qui a consenti, quand et comment, afin de pouvoir démontrer que le consentement est valable.
- **Non transférable.** Le consentement s'applique à l'adresse ou au numéro communiqué, et ne s'étend pas aux autres adresses de la personne.
- **Révocable.** Il doit être facile de le retirer à tout moment ; le consentement ne vaut que « pour le moment ».

## Les soft opt-in

Deux exceptions limitées permettent d'adresser de la prospection non sollicitée par courrier électronique à des abonnés individuels sans consentement.

### 1. Le soft opt-in pour les produits et services (toute organisation, y compris les associations caritatives)

Les cinq conditions doivent toutes être remplies :

1. **Vous avez obtenu les coordonnées du destinataire** directement : pas par un tiers, et pas même par une autre société de votre propre groupe. « Une liste de prospection de tiers conforme au soft opt-in, cela n'existe pas » (*"There is no such thing as a third-party marketing list that is compliant with the soft opt-in."*).
2. **Vous les avez obtenues lors de la vente, ou de la négociation de la vente, d'un produit ou d'un service.** Un achat n'est pas requis. Les « négociations » supposent que la personne a manifesté activement son intérêt pour un achat (inscription à un essai gratuit, demande de devis, question sur un produit). La simple navigation sur un site web, ou une question sans rapport avec un achat, ne suffit pas.
3. **Vous ne faites la promotion que de vos propres produits et services similaires.** Le critère est de savoir si, au vu des échanges précédents, les personnes s'attendraient raisonnablement à cette prospection. Une personne qui achète des produits d'épicerie peut recevoir de la prospection pour d'autres produits du supermarché, mais pas pour les produits bancaires ou d'assurance de l'enseigne. Ce soft opt-in ne couvre jamais les produits d'autres organisations. Les associations caritatives, les partis politiques et les autres organismes à but non lucratif ne doivent **pas** l'utiliser pour leurs campagnes ou leurs collectes de fonds, même auprès de soutiens existants.
4. **Vous avez donné aux personnes la possibilité de refuser, ou de s'opposer, lors de la collecte des coordonnées.** Une case d'opt-out bien visible sur le formulaire, ou un opt-out proposé oralement, convient. Un opt-out enfoui dans une politique de confidentialité, ou proposé seulement dans un email de confirmation ultérieur, ne convient pas.
5. **Vous proposez un opt-out dans chaque message ultérieur.** Il s'agit d'un lien de désabonnement clair ou d'une réponse directe, ou pour les SMS de « envoyez STOP au [numéro] », gratuitement, hors coût normal d'un message. Exiger un appel téléphonique, la création d'un compte ou la connexion à un centre de préférences n'est pas acceptable.

### 2. Le soft opt-in pour les finalités caritatives (associations caritatives uniquement), en vigueur depuis le 5 février 2026

Les six conditions doivent toutes être remplies :

1. **Vous êtes une association caritative**, selon la définition légale de chaque nation du Royaume-Uni.
2. **Vous avez obtenu les coordonnées directement**, et non par une filiale commerciale, une plateforme de collecte de fonds tierce ou tout autre intermédiaire.
3. **Vous les avez obtenues parce que la personne a manifesté son intérêt pour vos finalités caritatives, ou a offert ou apporté son soutien à ces finalités** : par exemple en demandant des informations sur l'action de l'association, en faisant un don d'argent ou de biens, ou en faisant du bénévolat. Les interactions qui ne révèlent rien d'un intérêt pour les finalités caritatives ne suffisent pas, comme l'inscription au wifi invité, l'achat d'un café dans un café solidaire ou une demande d'aide d'urgence. Certains achats manifestement effectués par un soutien, en cette qualité, peuvent suffire (une adhésion annuelle, le parrainage d'un animal, une tombola caritative, des événements de collecte de fonds payants). Les achats accessoires ou de commodité ne suffisent pas.
4. **La prospection a pour seul objet de servir vos finalités caritatives** : solliciter des dons (d'argent ou de biens), recruter des bénévoles, ou informer sur des programmes, projets et campagnes liés à la mission. Elle ne doit pas promouvoir d'autres organisations, y compris d'autres associations caritatives ou des sponsors commerciaux.
5. **Vous avez proposé un opt-out lors de la collecte des coordonnées** (selon la même norme que ci-dessus).
6. **Vous proposez un opt-out dans chaque message ultérieur** (selon la même norme que ci-dessus).

**Calendrier.** Ce soft opt-in ne s'applique qu'aux coordonnées obtenues **le 5 février 2026 ou après**. Les coordonnées collectées auparavant sans consentement ne peuvent pas être utilisées sur ce fondement, sauf si elles sont collectées de nouveau après cette date avec un opt-out conforme.

### Utiliser les deux soft opt-in ensemble

Une association caritative peut s'appuyer sur les deux. Pour cela, elle doit :

- présenter **des cases d'opt-out distinctes** pour chacun lors de la collecte (et uniquement lorsque les conditions de collecte de ce soft opt-in sont remplies) ;
- offrir dans chaque message un moyen de refuser chaque type ;
- n'inclure que le contenu de prospection autorisé par les soft opt-in qu'elle invoque ;
- tenir un registre (indicateurs ou champs de préférence) de la base légale applicable à chaque personne.

## Listes achetées

Pour envoyer de la prospection par courrier électronique à une liste que vous avez achetée, louée ou prise sous licence, chaque personne de la liste doit avoir donné un consentement valable qui **nomme expressément votre organisation** (et non des « partenaires de confiance » ou une formule similaire). Le consentement doit porter sur le canal précis (email ou SMS), et être libre, spécifique, éclairé, univoque et enregistré (qui, quand et comment). Sinon, n'envoyez pas. Les soft opt-in ne peuvent **jamais** être utilisés avec des listes achetées, car ils exigent que les coordonnées soient collectées directement.

## Coordonnées accessibles au public

Le fait qu'une adresse soit accessible au public (sur des sites web, des réseaux sociaux ou des annuaires) ne vaut **pas** consentement. La prospection non sollicitée auprès d'abonnés individuels, y compris les entrepreneurs individuels et les sociétés de personnes ordinaires, exige toujours un consentement ou un soft opt-in. Le scraping d'informations personnelles fait aussi entrer en jeu le droit de la protection des données. La LCAP, en revanche, prévoit une catégorie de consentement implicite pour la « publication bien en vue » ; le PECR, non.

## Parrainage et marketing viral

Une organisation qui encourage des personnes à transférer sa prospection devient un **instigateur**. Aucune incitation n'est nécessaire : un encouragement actif suffit. Les soft opt-in ne peuvent pas être utilisés pour ces messages. Il faudrait le consentement valable de l'ami ou du proche qui reçoit le message, ce qui est peu envisageable en pratique, si bien que les programmes de parrainage par email assortis d'une incitation enfreignent généralement le PECR.

Une organisation n'est pas responsable des messages que des personnes choisissent d'envoyer sans son encouragement, comme des recommandations spontanées, le partage d'une promotion, un lien vers un site ou des demandes de parrainage personnelles.

## Changements d'avis : retrait et opt-out

- Le consentement peut être retiré à tout moment. Toute nouvelle prospection exige alors un nouveau consentement.
- Refuser un soft opt-in met aussi fin à la prospection sur ce fondement, et seul un nouveau consentement permet de la reprendre.
- Un opt-out s'applique à un seul canal si sa formulation le précise clairement (se désabonner des emails n'implique pas nécessairement l'arrêt des SMS).
- Le droit de la protection des données donne aux personnes un **droit absolu de s'opposer** à la prospection directe. Il ne peut être refusé pour aucun motif, et ne pas avoir refusé un soft opt-in ne prime pas sur ce droit.
- Tenez une **liste « ne pas contacter » (une liste de suppression)** et vérifiez-la avant d'envoyer.
- Une réponse qui confirme un désabonnement et explique comment se réabonner est acceptable. Des rappels de préférences peuvent être de petits ajouts à des messages que vous envoyez déjà, à condition de ne pas encourager les personnes à changer de choix.

## Articulation du PECR et de l'UK GDPR

Lorsque des informations personnelles sont utilisées, les deux ensembles de règles s'appliquent. Le traitement doit être loyal, licite et transparent : informez donc les personnes, lors de la collecte de leurs coordonnées, que vous prévoyez de leur envoyer de la prospection. Parmi les sept bases légales de l'UK GDPR, le **consentement** et l'**intérêt légitime** sont généralement les bases pertinentes :

- Si vous vous appuyez sur le consentement au titre du PECR, votre base légale est probablement le consentement.
- Si vous vous appuyez sur un soft opt-in, votre base légale est probablement l'**intérêt légitime**. Réalisez une évaluation de l'intérêt légitime (finalité, nécessité, mise en balance). Lorsque les destinataires peuvent se trouver en situation de vulnérabilité, la mise en balance peut échouer et le soft opt-in ne devrait pas être utilisé. L'exemple de l'ICO est celui de personnes qui reçoivent un soutien après des violences conjugales, et qui pourraient être mises en danger si un conjoint voyait l'email.

**Pixels de suivi.** Les règles de prospection par courrier électronique s'appliquent à l'email lui-même, pas aux pixels de suivi (qui enregistrent l'heure d'ouverture, la localisation et le système d'exploitation). Les pixels relèvent des règles distinctes du PECR sur les **technologies de stockage et d'accès**, que vous devez aussi respecter.

## Enjeux pour la délivrabilité

Les conditions du PECR pour le consentement et le soft opt-in correspondent étroitement aux meilleures pratiques de délivrabilité. Des adresses collectées directement auprès de personnes ayant acheté récemment, un consentement granulaire pour chaque canal, des opt-out bien visibles, le désabonnement en un clic et les listes de suppression réduisent tous les plaintes et maintiennent l'engagement des listes, et ce sont les principaux facteurs de réputation décrits dans [Fondamentaux de la délivrabilité email](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email). L'affirmation catégorique de l'ICO selon laquelle aucune liste achetée ne peut satisfaire au soft opt-in fait écho à la règle de délivrabilité selon laquelle les listes achetées détruisent la réputation d'un expéditeur.

# Ce que mesurent les fournisseurs de messagerie, et qui s'en charge dans votre équipe

> Les signaux que notent les fournisseurs de messagerie (plaintes, engagement, rebonds, adresses pièges, authentification et régularité des volumes), chacun attribué à la personne qui peut agir dessus (le marketing, la personne qui gère le DNS ou la plateforme d'envoi), avec la première action de chacun.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fondamentaux/ce-que-mesurent-les-fournisseurs-de-messagerie

Les fournisseurs de messagerie décident du sort de vos emails à partir d'une poignée de signaux. Aucun n'appartient à une seule personne. Le marketing décide à qui l'on écrit et à quelle fréquence, la personne qui gère le DNS de votre domaine contrôle les enregistrements d'authentification, et votre plateforme d'envoi (votre ESP, ou l'équipe qui gère vos serveurs de messagerie) contrôle la façon dont les emails sont envoyés et dont les rebonds et les plaintes sont traités. Quand la livraison se dégrade, la correction la plus rapide vient de savoir lequel des trois peut agir.

[Le modèle de livraison en sept étapes](https://emailmarketing.net/fr/apprendre/fondamentaux/modele-de-livraison-en-sept-etapes) répartit ce travail entre l'expéditeur et la plateforme. Cet article descend d'un niveau et répartit la part de l'expéditeur entre les personnes de votre équipe.

## Les rôles

- **Marketing :** la personne qui décide qui figure sur la liste, ce qui est envoyé et quand. Dans une petite entreprise, c'est peut-être vous.
- **Responsable du DNS :** la personne qui peut modifier les enregistrements DNS de votre domaine. Souvent le service informatique, une agence web ou la personne qui a enregistré le domaine.
- **Plateforme d'envoi :** votre ESP, ou l'équipe qui gère vos propres serveurs de messagerie. Elle envoie les emails, les signe et traite les rebonds et les plaintes.

## En un coup d'œil

| Signal | Qui s'en charge | Première action |
|---|---|---|
| Plaintes | Le marketing, avec la plateforme | Avoir votre taux de spam sous les yeux et trouver quels envois génèrent des plaintes. |
| Engagement | Le marketing | Définir « inactif » par les clics ou les achats, demander une reconfirmation aux abonnés inactifs et envisager de ne plus écrire à ceux qui ne répondent pas. |
| Rebonds | La plateforme, avec le marketing | Vérifier que les adresses en rebond définitif sont supprimées et jamais réimportées. |
| Adresses pièges | Le marketing | Vérifier la provenance de vos adresses. |
| Authentification | Le responsable du DNS, avec la plateforme et le marketing | Lancer le diagnostic de domaine, puis dresser la liste de tous les services qui envoient au nom de votre domaine. |
| Régularité des volumes | Le marketing, avec la plateforme | Prévenir votre plateforme avant tout envoi beaucoup plus gros que d'habitude. |

## Plaintes

**Ce que mesurent les fournisseurs :** la fréquence à laquelle les destinataires marquent vos emails comme spam. Google demande aux expéditeurs de maintenir le taux de spam indiqué dans Postmaster Tools sous 0,1 % et de ne jamais le laisser atteindre 0,3 % ([FAQ de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/14229414?hl=en)). Yahoo demande moins de 0,3 %, calculé sur les emails livrés en boîte de réception ([Yahoo](https://senders.yahooinc.com/best-practices/)). Google indique que des signalements de spam fréquents rendent vos futurs messages plus susceptibles d'être marqués comme spam et, à terme, nuisent à la réputation de votre domaine ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)).

**Le marketing est responsable** des raisons pour lesquelles les destinataires se plaignent : écrire à des personnes qui ne se sont pas inscrites, écrire plus souvent qu'elles ne s'y attendaient, ou compliquer le désabonnement. Gmail exige que les messages marketing des expéditeurs de plus de 5 000 messages par jour incluent un lien de désabonnement clairement visible dans le corps du message (même source).

- **Première action :** avoir le taux de spam sous les yeux. Postmaster Tools l'affiche pour les emails envoyés à des comptes Gmail personnels, une fois votre domaine validé ([Google](https://support.google.com/mail/answer/9981691?hl=en)). Le responsable du DNS ajoute l'enregistrement de validation. Comparez ensuite les plaintes d'un envoi à l'autre pour trouver ceux qui les génèrent.

**La plateforme est responsable** du traitement des plaintes et de la mécanique du désabonnement. Le M3AAWG indique que les ESP doivent disposer d'un système pour traiter à la fois les messages des feedback loops et les plaintes directes ([Sender Best Common Practices du M3AAWG, version 4.0, août 2026](https://www.m3aawg.org/senderbcp)). Gmail exige le désabonnement en un clic pour les messages marketing et les messages envoyés aux abonnés, de la part des expéditeurs de plus de 5 000 messages par jour ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)). Yahoo l'exige des expéditeurs de gros volumes, recommande la méthode POST définie dans la [RFC 8058](https://datatracker.ietf.org/doc/html/rfc8058) et demande que les désabonnements soient pris en compte sous 2 jours ([Yahoo](https://senders.yahooinc.com/best-practices/)).

- **Première action :** vérifier avec votre plateforme que les plaignants sont supprimés automatiquement et que vos emails marketing portent les en-têtes de désabonnement en un clic.

## Engagement

**Ce que mesurent les fournisseurs :** si les destinataires lisent vos emails et y donnent suite. Yahoo indique qu'envoyer des emails à des personnes qui ne les lisent pas « nuira à vos indicateurs de livraison et à votre réputation » ([Yahoo](https://senders.yahooinc.com/best-practices/)). Google suggère aux expéditeurs : « Envisagez de désabonner les destinataires qui n'ouvrent pas vos messages ou ne les lisent pas » ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)).

**Le marketing est responsable** de ce signal : le ciblage, la fréquence et l'offre.

- **Première action :** définir « inactif » par les clics ou les achats plutôt que par les seules ouvertures. Apple Mail Privacy Protection télécharge le contenu distant « que vous interagissiez avec l'email ou non » ([Apple](https://www.apple.com/legal/privacy/data/en/mail-privacy-protection/)) : une ouverture enregistrée ne montre donc pas que quelqu'un a lu le message. Suivez ensuite ce que suggèrent les deux fournisseurs. Yahoo recommande d'envoyer périodiquement aux abonnés inactifs un email de reconfirmation ([Yahoo](https://senders.yahooinc.com/best-practices/)), et Google suggère de confirmer périodiquement que les destinataires veulent rester abonnés, et d'envisager de désabonner ceux qui n'ouvrent pas vos messages ou ne les lisent pas ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)).

[Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil) explique comment mettre cela en place.

## Rebonds

**Ce que mesurent les fournisseurs :** la part de vos emails qui part vers des adresses inexistantes. Le M3AAWG indique que le volume d'échecs définitifs « est l'un des indicateurs qu'utilisent les serveurs de réception pour se forger une idée de la réputation d'un expéditeur », et qu'un serveur de réception pénalise souvent une IP d'envoi qui en produit trop ([Sender Best Common Practices du M3AAWG, version 4.0, août 2026](https://www.m3aawg.org/senderbcp)). La politique de Microsoft est qu'après une erreur définitive (5xx), l'expéditeur ne doit pas retenter l'envoi de ce message à ce destinataire ([politiques postmaster d'Outlook.com](https://substrate.office.com/ip-domain-management-snds/postmaster/policies)).

**La plateforme est responsable** du traitement des rebonds : retenter les échecs temporaires, supprimer les échecs définitifs et retirer les adresses qui continuent de produire des rebonds. Le M3AAWG considère comme une meilleure pratique de retirer une adresse qui produit des rebonds consécutifs au moins deux fois sur une période de deux semaines ou plus.

- **Première action :** vérifier avec votre plateforme que les adresses en rebond définitif sont supprimées automatiquement.

**Le marketing est responsable** de ce qui est ajouté. Le M3AAWG associe les gros volumes de rebonds définitifs à « un processus d'inscription mal géré ou une liste de diffusion ancienne ou mal utilisée », et Yahoo recommande l'opt-in confirmé pour réduire les destinataires invalides ([Yahoo](https://senders.yahooinc.com/best-practices/)).

- **Première action :** ne jamais réimporter les adresses que votre plateforme a supprimées, et confirmer les nouvelles adresses à l'inscription.

## Adresses pièges

**Ce que mesurent les fournisseurs :** si vous écrivez à des adresses que personne n'a inscrites. Spamhaus décrit une adresse piège comme une adresse « traditionnellement utilisée pour démasquer les expéditeurs illégitimes qui ajoutent des adresses email à leurs listes sans autorisation », et qui repère aussi les marketeurs « aux pratiques de collecte des données et de gestion des listes insuffisantes » ([Spamhaus, Email Deliverability 101](https://info.spamhaus.com/hubfs/Know%20How%20-%20Email%20Deliverability/Spamhaus%20eBook_Email%20Deliverability%20101.pdf)).

**Le marketing est responsable** de ce signal, parce qu'il découle de la façon dont les adresses ont été collectées et conservées. Spamhaus conseille de consacrer ses efforts « à corriger le problème de collecte, de conservation et d'hygiène des données, et non à chercher à localiser l'adresse piège » (même source).

- **Première action :** vérifier la provenance de vos adresses. Cessez d'écrire à tout segment acheté, ou collecté sans confirmation et auquel vous n'avez pas écrit depuis longtemps. Google demande aux expéditeurs de ne pas acheter d'adresses email ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)).

[Adresses pièges : types et ce qu'elles révèlent](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges) explique les types d'adresses pièges.

## Authentification

**Ce que mesurent les fournisseurs :** si vos emails prouvent qu'ils proviennent de votre domaine. Gmail exige SPF ou DKIM de tous les expéditeurs, et SPF, DKIM et DMARC des expéditeurs de plus de 5 000 messages par jour, avec un domaine From aligné sur le domaine SPF ou DKIM ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)). Yahoo exige la même chose de ses expéditeurs de gros volumes ([Yahoo](https://senders.yahooinc.com/best-practices/)), et Microsoft l'exige des domaines qui envoient plus de 5 000 emails par jour à Outlook.com ([politiques postmaster d'Outlook.com](https://substrate.office.com/ip-domain-management-snds/postmaster/policies)).

Trois personnes partagent ce signal, et il se casse quand l'une d'elles n'est pas prévenue.

**Le responsable du DNS** publie les enregistrements.

- **Première action :** lancer le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) et corriger tout résultat **Mauvais**. S'il n'y a pas d'enregistrement DMARC, en publier un avec une adresse de rapport. Le M3AAWG indique que tout enregistrement DMARC, même avec `p=none`, devrait inclure au minimum une balise `rua` pour les rapports agrégés, et recommande `p=reject` comme politique lorsque c'est possible ([meilleures pratiques M3AAWG pour l'authentification des emails](https://www.m3aawg.org/sites/default/files/legacy/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf)). [Lire un résultat du diagnostic de domaine](https://emailmarketing.net/fr/apprendre/fondamentaux/lire-un-resultat-du-diagnostic-de-domaine) explique chaque verdict.

**La plateforme** fournit les valeurs à publier et signe les emails.

- **Première action :** vérifier qu'elle authentifie les emails de votre domaine avec SPF et DKIM, comme Google demande de le vérifier aux expéditeurs qui passent par un fournisseur ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)). La plateforme gère aussi l'infrastructure d'envoi que vérifient les fournisseurs, comme une résolution DNS directe et inverse valide pour les IP d'envoi et les connexions TLS (même source).

**Le marketing** sait quels outils envoient des emails au nom de votre domaine.

- **Première action :** dresser la liste de tous les services qui envoient au nom de votre domaine (newsletters, CRM, facturation, service d'assistance) et la transmettre au responsable du DNS. Google indique que votre enregistrement SPF doit inclure tous les expéditeurs d'emails de votre domaine, et que les emails des expéditeurs qui n'y figurent pas sont plus susceptibles d'être marqués comme spam (même source).

## Régularité des volumes

**Ce que mesurent les fournisseurs :** la régularité de vos envois. Google conseille d'envoyer à un rythme régulier, d'éviter les envois groupés et d'éviter les pics soudains sans historique de gros volumes : « le doublement soudain du volume d'envoi par rapport aux volumes précédents peut entraîner une limitation de la fréquence d'envoi ou une baisse de la réputation » ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)). Le M3AAWG indique que la régularité du volume « joue un rôle essentiel dans la détermination de la réputation d'une IP et des résultats de délivrabilité » ([Sender Best Common Practices du M3AAWG, version 4.0, août 2026](https://www.m3aawg.org/senderbcp)). Spamhaus note que les variations soudaines du volume d'emails sont typiques des machines infectées, et que les fournisseurs réagissent en conséquence ([Spamhaus, Email Deliverability 101](https://info.spamhaus.com/hubfs/Know%20How%20-%20Email%20Deliverability/Spamhaus%20eBook_Email%20Deliverability%20101.pdf)).

**Le marketing est responsable** du plan : un pic saisonnier, une campagne de réactivation, un segment nouvellement importé.

- **Première action :** prévenir votre plateforme avant tout envoi beaucoup plus gros que d'habitude, et y arriver progressivement sur plusieurs envois plutôt qu'en une journée.

**La plateforme est responsable** du débit d'envoi : la limitation du débit d'envoi, le ralentissement quand un fournisseur reporte les emails, et la chauffe des nouvelles IP. Google conseille de réduire le volume quand les messages commencent à produire des rebonds ou à être différés, puis de l'augmenter à nouveau lentement (même source). Outlook.com propose SNDS, qui fournit au propriétaire d'une plage d'adresses IP des données comme le volume d'emails et les taux de plaintes du trafic provenant de ces IP ([FAQ de Microsoft SNDS](https://substrate.office.com/ip-domain-management-snds/snds/faq)). Si vous envoyez depuis les adresses IP de votre plateforme, c'est la plateforme qui peut voir ces données.

- **Première action :** vérifier que la plateforme ralentit automatiquement quand un fournisseur reporte les emails.

## Voir aussi

- [Est-ce un problème de livraison ? Le savoir avant de dépenser](https://emailmarketing.net/fr/apprendre/fondamentaux/est-ce-un-probleme-de-livraison) : utiliser ces signaux pour décider de la suite
- [Le modèle de livraison en sept étapes](https://emailmarketing.net/fr/apprendre/fondamentaux/modele-de-livraison-en-sept-etapes) : la répartition entre l'expéditeur et la plateforme, et la boucle des campagnes
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email) : pourquoi les plaintes et l'engagement pèsent le plus
- [Exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs), [Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs) et [Exigences de Microsoft envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs) : les règles des fournisseurs en intégralité
- [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools) : le tableau de bord des signaux Gmail

# Est-ce un problème de livraison ? Le savoir avant de dépenser

> Pour un responsable marketing ou un chef d'entreprise : distinguer un vrai problème de livraison (rebonds, blocages, emails classés en spam) d'un problème de liste, de contenu ou de mesure, avec les seuls éléments accessibles sans journaux de serveur, et ce que chaque constat implique pour la décision.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fondamentaux/est-ce-un-probleme-de-livraison

Quand les résultats de vos emails baissent, la « délivrabilité » est généralement la première explication avancée. C'est parfois juste. Souvent, les emails arrivent toujours, et c'est autre chose qui a changé : la liste, l'offre ou la façon de compter les résultats. Ces problèmes se corrigent de manières très différentes et à des coûts très différents : une heure de vérification vaut donc la peine avant d'engager quelqu'un ou de changer de plateforme.

Cet article s'adresse à vous si vous gérez les emails d'une entreprise sans manipuler les protocoles au quotidien. Il n'utilise que des éléments que vous pouvez consulter vous-même : les rapports de votre plateforme d'envoi, Google Postmaster Tools, un test sur liste de test et un diagnostic de domaine gratuit. Le principe qui sous-tend tout cela, à savoir que les fournisseurs de messagerie livrent les emails que leurs utilisateurs désirent et attendent, est traité dans [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email).

Aucune vérification présentée ici, ni personne que vous engagerez, ne peut promettre où vos emails arriveront. Google indique ne pas accepter les demandes d'ajout à la liste blanche provenant de fournisseurs de messagerie et précise : « Nous ne pouvons pas garantir que les messages envoyés par des fournisseurs de messagerie ne seront pas bloqués par les filtres antispam de Gmail » ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)). Ce que vous pouvez faire, c'est déterminer quel type de problème vous avez.

## Quatre problèmes qui se ressemblent

| Type de problème | Ce qui se passe réellement | Où cela se voit |
|---|---|---|
| **Livraison** | Les fournisseurs de messagerie refusent les emails (rebonds, blocages) ou les acceptent et les classent en spam. | Des rebonds dont le texte mentionne une politique, l'authentification ou une liste de blocage ; des erreurs de distribution ou un taux de spam élevé dans Postmaster Tools ; un placement en dossier spam sur l'ensemble des boîtes de test. |
| **Liste** | Les emails partent vers des adresses qui n'existent plus, ou vers des personnes qui n'en veulent plus. | Des rebonds définitifs pour des adresses inexistantes, des plaintes en hausse, une inscription sur une liste de blocage. |
| **Contenu ou offre** | Les emails arrivent, mais les destinataires n'y donnent pas suite. | Rebonds et plaintes stables ; clics et ventes en baisse. |
| **Mesure** | L'endroit où arrivent vos emails n'a pas changé ; ce sont les chiffres que vous lisez qui ont changé. | Les taux d'ouverture bougent alors que les clics, les rebonds et les plaintes ne bougent pas. |

Ces catégories ne sont pas étanches. Un problème de liste laissé de côté devient un problème de livraison : Google indique que si les messages provenant de votre domaine sont souvent signalés comme spam, les futurs messages de votre part seront plus susceptibles d'être marqués comme spam, et qu'« à terme, le fait que votre domaine soit lié à des rapports de spam envoyés par des utilisateurs peut nuire à sa réputation » ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)). C'est pourquoi les vérifications de la liste, plus bas, passent avant toute dépense.

## Ne jugez pas la livraison sur les ouvertures

Apple Mail Privacy Protection « télécharge le contenu distant en arrière-plan par défaut, que vous interagissiez avec l'email ou non » ([Apple](https://www.apple.com/legal/privacy/data/en/mail-privacy-protection/)). Les expéditeurs savent qu'un message a été ouvert grâce à ce même contenu distant : pour les destinataires qui utilisent cette fonction, une ouverture enregistrée ne montre donc plus que quelqu'un a lu le message.

Un taux d'ouverture peut donc varier sans que l'endroit où arrivent vos emails ait changé. Jugez la livraison sur les rebonds, les plaintes et les éléments de placement ci-dessous, et jugez l'intérêt sur les clics et les ventes. [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure) traite des autres sources de biais.

## Les éléments que vous pouvez rassembler vous-même

### 1. Le rapport de rebonds de votre plateforme d'envoi

Un rebond est un serveur de réception qui dit non. Le code indique si c'est temporaire ou définitif : les réponses qui commencent par 4 sont des échecs transitoires et celles qui commencent par 5 sont définitives ([RFC 5321 §4.2.1](https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.1)), et les codes d'état étendus suivent la même répartition, 4.x.x et 5.x.x ([RFC 3463](https://datatracker.ietf.org/doc/html/rfc3463)).

Lisez le texte des rebonds, pas seulement leur nombre. Le M3AAWG note que les codes seuls « n'indiquent pas clairement si l'adresse doit être retirée ou non », et que le texte descriptif peut désigner un problème d'infrastructure d'envoi ou de contenu, ou montrer que l'IP d'envoi figure sur une liste de blocage ([Sender Best Common Practices du M3AAWG, version 4.0, août 2026](https://www.m3aawg.org/senderbcp)).

- **Surtout des « user unknown » ou « mailbox does not exist » :** un problème de liste. Selon le M3AAWG, de gros volumes de rebonds définitifs « sont trop souvent le signe d'un processus d'inscription mal géré ou d'une liste de diffusion ancienne ou mal utilisée ».
- **Un texte qui mentionne l'authentification, une politique, la réputation ou une liste de blocage, concentré chez un seul fournisseur :** un problème de livraison chez ce fournisseur. Par exemple, Gmail peut rejeter les messages non authentifiés avec une erreur 5.7.26, et répond généralement par 4.7.28 lorsque vous dépassez ses limites de débit d'envoi ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)).

Les [procédures de dépannage de la livraison](https://emailmarketing.net/fr/apprendre/operations/procedures-de-depannage-de-la-livraison) passent en revue le texte des rebonds par fournisseur.

### 2. Vos chiffres de plaintes

Les plaintes parviennent à votre plateforme par les feedback loops, que les fournisseurs de messagerie proposent pour renvoyer les signalements de spam à l'expéditeur ([RFC 6449](https://datatracker.ietf.org/doc/html/rfc6449)). Yahoo envoie une copie de la plainte lorsqu'un utilisateur clique sur « report spam » ([Yahoo](https://senders.yahooinc.com/best-practices/)). Gmail affiche plutôt un taux de spam dans Postmaster Tools.

Les fournisseurs publient leurs limites :

- **Gmail :** maintenir le taux de spam sous 0,1 % et ne jamais le laisser atteindre 0,3 %. Google indique qu'un taux supérieur à 0,1 % a déjà un impact négatif sur la distribution en boîte de réception pour les expéditeurs de gros volumes ([FAQ de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/14229414?hl=en)).
- **Yahoo :** maintenir le taux de spam sous 0,3 %, calculé sur les emails livrés en boîte de réception ([Yahoo](https://senders.yahooinc.com/best-practices/)).

Des plaintes en hausse signalent généralement un problème de liste ou de consentement qui commence à se transformer en problème de livraison. Les consignes de Gmail sont directes : les personnes qui ne se sont pas inscrites pour recevoir vos messages « peuvent marquer vos messages comme spam » ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)).

### 3. Google Postmaster Tools

Postmaster Tools est la console gratuite de Google pour les expéditeurs. Ses tableaux de bord couvrent le taux de spam, la réputation, l'authentification des messages et les erreurs de distribution, et ses données ne s'appliquent qu'aux messages envoyés à des comptes Gmail personnels, ceux qui se terminent par @gmail.com ou @googlemail.com ([Google](https://support.google.com/mail/answer/9981691?hl=en)).

- Vous ajoutez le domaine avec lequel vos emails sont authentifiés (le domaine DKIM `d=` ou le domaine SPF du Return-Path), puis vous le validez avec un enregistrement DNS. La personne qui gère votre DNS devra ajouter cet enregistrement.
- Des données peuvent manquer lorsque le nombre de messages d'une journée est trop faible. Google les retient pour protéger la confidentialité des utilisateurs. Un tableau de bord vide n'est pas le signe d'un problème.

[Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools) explique chaque tableau de bord.

### 4. Un test sur liste de test

Un test sur liste de test envoie votre campagne à un ensemble de boîtes de test réparties chez plusieurs fournisseurs et indique dans quel dossier chaque copie est arrivée. C'est le seul élément de cette liste qui montre directement le placement, mais uniquement pour ces boîtes.

Le placement se décide par destinataire autant que par expéditeur. Google indique que les messages envoyés à partir d'une adresse figurant dans la liste de contacts du destinataire risquent moins d'être marqués comme spam, et que lorsqu'un destinataire marque un message comme n'étant pas du spam, les futurs messages de cet expéditeur devraient arriver dans sa boîte de réception ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)). Les boîtes de test n'ont pas un tel historique avec vous. Lisez un résultat de test sur liste de test comme une tendance d'un fournisseur à l'autre, pas comme une mesure de vos abonnés. [Méthodologie de mesure du placement](https://emailmarketing.net/fr/apprendre/operations/methodologie-de-mesure-du-placement) indique où les résultats de ces tests induisent en erreur.

### 5. Le diagnostic de domaine gratuit

Le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) lit les enregistrements SPF, DKIM, DMARC et MX que votre domaine publie dans le DNS public, et recherche les adresses autorisées par votre enregistrement SPF sur les listes de blocage qu'il interroge. Il ne voit pas comment votre plateforme d'envoi utilise ces enregistrements, ni votre réputation auprès des fournisseurs de messagerie, ni l'endroit où arrivent vos emails. [Lire un résultat du diagnostic de domaine](https://emailmarketing.net/fr/apprendre/fondamentaux/lire-un-resultat-du-diagnostic-de-domaine) explique chaque verdict.

L'authentification n'est pas facultative chez les grands fournisseurs :

- **Gmail** exige SPF ou DKIM de tous les expéditeurs, et SPF, DKIM et DMARC de quiconque envoie plus de 5 000 messages par jour à des comptes Gmail ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)).
- **Yahoo** exige SPF ou DKIM de tous les expéditeurs, et SPF, DKIM et une politique DMARC d'au moins `p=none` des expéditeurs de gros volumes ([Yahoo](https://senders.yahooinc.com/best-practices/)).
- **Microsoft** exige que les domaines qui envoient plus de 5 000 emails par jour à Outlook.com se conforment à SPF, DKIM et DMARC. Les emails non conformes vont dans le courrier indésirable et peuvent être rejetés avec `550 5.7.515` ([politiques postmaster d'Outlook.com](https://substrate.office.com/ip-domain-management-snds/postmaster/policies)).

## Lire les éléments ensemble

| Ce que vous constatez | Ce dont il s'agit le plus probablement |
|---|---|
| Les ouvertures ont changé ; les clics, les rebonds et les plaintes non. | Mesure. |
| Rebonds et plaintes stables et faibles ; clics et ventes en baisse. | Contenu, offre ou ciblage. |
| Des rebonds définitifs pour des adresses inexistantes, surtout dans les segments anciens. | Liste. |
| Un taux de plaintes qui approche les limites des fournisseurs indiquées plus haut. | Un problème de liste ou de consentement qui devient un problème de livraison. |
| Le diagnostic de domaine affiche l'authentification en **Mauvais** ou **Risqué**, et le texte des rebonds mentionne l'authentification. | Configuration : des enregistrements que la personne qui gère votre DNS et votre plateforme peuvent corriger. |
| Des rejets ou un placement en dossier spam chez un seul fournisseur, alors que les signaux de liste sont propres et que l'authentification est en place. | Livraison chez ce fournisseur. |
| Une adresse depuis laquelle vous envoyez figure sur une liste de blocage. | Livraison, avec une cause à trouver d'abord. |

## Ce que chaque constat implique pour la décision

### Corriger d'abord la liste

**Quand :** des rebonds définitifs pour des adresses inexistantes, des plaintes en hausse, un segment auquel vous n'avez pas écrit depuis longtemps, ou des adresses achetées ou collectées sans opt-in clair.

**Pourquoi d'abord :** les fournisseurs tiennent compte de ce que font vos destinataires. Gmail demande aux expéditeurs de n'envoyer des emails « qu'aux personnes qui souhaitent recevoir [leurs] messages » et de ne pas acheter d'adresses ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)). Yahoo indique qu'écrire à des personnes qui ne lisent pas vos messages, ou qui les signalent comme spam, « nuira à vos indicateurs de livraison et à votre réputation » ([Yahoo](https://senders.yahooinc.com/best-practices/)). Spamhaus considère qu'une adresse piège touchée est « le signe d'une mauvaise hygiène des données ou de problèmes dans votre processus d'inscription marketing », et conseille de corriger la collecte des données plutôt que de chercher à localiser le piège ([Spamhaus, Email Deliverability 101](https://info.spamhaus.com/hubfs/Know%20How%20-%20Email%20Deliverability/Spamhaus%20eBook_Email%20Deliverability%20101.pdf)). Le M3AAWG recommande de retirer les adresses qui produisent des rebonds de façon répétée sur plusieurs campagnes consécutives ([Sender Best Common Practices du M3AAWG, version 4.0, août 2026](https://www.m3aawg.org/senderbcp)).

Personne en dehors de votre entreprise ne peut corriger la composition de votre liste. Commencez par [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil) et [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement).

### Se faire aider

**Quand :** les éléments désignent la livraison (des rejets qui mentionnent la réputation ou une politique, un taux de spam ou des erreurs de distribution persistants dans Postmaster Tools, une inscription sur une liste de blocage qui revient), et vos vérifications de liste et d'authentification sont propres. Également lorsque les éléments se contredisent et que vous ne pouvez pas trancher.

**Ce qu'il faut apporter :** des exemples de texte de rebonds, l'évolution de vos taux de plaintes, des captures d'écran de Postmaster Tools et le résultat de votre diagnostic de domaine. La première conversation devient ainsi un diagnostic plutôt qu'un travail de découverte.

**À quoi s'attendre :** les fournisseurs posent des conditions à leur propre aide. Google indique que les expéditeurs de gros volumes dont le taux de spam dépasse 0,3 % ne peuvent pas obtenir la levée des restrictions tant que ce taux ne reste pas sous 0,3 % pendant 7 jours consécutifs ([FAQ de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/14229414?hl=en)). Microsoft indique que son équipe d'assistance pourrait ne pas être en mesure d'aider les expéditeurs qui ne respectent pas ses politiques ([politiques postmaster d'Outlook.com](https://substrate.office.com/ip-domain-management-snds/postmaster/policies)). Faire baisser les plaintes passe avant l'escalade, quel que soit celui qui fait le travail. [Canaux d'escalade et de levée des restrictions des fournisseurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-et-de-levee-des-restrictions) indique à qui s'adresser.

### Changer d'ESP

C'est rarement la première réponse. Cela a du sens quand le problème se situe dans ce que contrôle la plateforme et ne peut pas y être résolu, par exemple :

- **Elle ne peut pas authentifier les emails avec votre propre domaine.** Google demande aux expéditeurs qui passent par un fournisseur de services de messagerie de vérifier que ce fournisseur authentifie les emails de leur domaine avec SPF et DKIM ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)).
- **La réputation de l'adresse IP partagée vous tire sans cesse vers le bas.** Sur une adresse IP partagée, « l'activité des expéditeurs utilisant une adresse IP partagée a une incidence sur la réputation de tous ceux qui ont recours à cette adresse » (même source). Si cela se répète et que la plateforme ne peut pas isoler vos emails, c'est un problème de plateforme.

Un changement ne corrige pas un problème de liste ou de contenu. Gmail suit le volume, les retours et les limites par domaine autant que par adresse IP, et les signalements de spam font baisser la réputation d'un domaine (même source). Comme cet historique est enregistré sur votre domaine et pas seulement sur les adresses de la plateforme, le même domaine l'emporte vers une nouvelle plateforme. Un changement est aussi une modification importante de votre infrastructure d'envoi : Google conseille d'augmenter séparément le volume du trafic modifié, et d'éviter les pics de volume soudains sans historique d'envoi de gros volumes (même source).

## Voir aussi

- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email) : le principe du courrier désiré et attendu qui sous-tend chaque vérification présentée ici
- [Ce que mesurent les fournisseurs de messagerie, et qui s'en charge dans votre équipe](https://emailmarketing.net/fr/apprendre/fondamentaux/ce-que-mesurent-les-fournisseurs-de-messagerie) : les signaux derrière ces constats, et qui agit sur chacun
- [Lire un résultat du diagnostic de domaine](https://emailmarketing.net/fr/apprendre/fondamentaux/lire-un-resultat-du-diagnostic-de-domaine) : ce que signifie chaque verdict du diagnostic de domaine
- [Le modèle de livraison en sept étapes](https://emailmarketing.net/fr/apprendre/fondamentaux/modele-de-livraison-en-sept-etapes) : la boucle des campagnes, y compris la taxonomie des problèmes côté destinataire
- [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite) : les chiffres plus en détail

# Fondamentaux de la délivrabilité des emails

> Le principe de base de la délivrabilité (envoyer des emails désirés et attendus) et la façon dont les fournisseurs de messagerie le mesurent.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email

Un email arrive en boîte de réception lorsque les personnes qui le reçoivent à la fois le désirent et l'attendent. Ces deux conditions sont distinctes, et chacune compte :

1. **Désiré** : le message apporte au destinataire quelque chose qui a de la valeur à ses yeux.
2. **Attendu** : le destinataire reconnaît l'email, parce qu'il s'est inscrit pour le recevoir ou qu'il est déjà en relation commerciale avec votre marque.

## Comment les fournisseurs de messagerie évaluent vos emails

Aucun fournisseur de messagerie ni fournisseur d'accès à Internet (ISP) ne peut demander à chaque destinataire si un message était le bienvenu. Un fournisseur peut en revanche observer comment ses utilisateurs traitent vos emails dans des dizaines de milliers de boîtes, et ce comportement répond de façon plus fiable qu'une question. Les plaintes et l'engagement pèsent le plus. Pour chaque campagne, un fournisseur peut voir :

- La part des destinataires qui l'ont signalée comme spam
- La part de ceux qui l'ont supprimée sans la lire
- La part de ceux qui l'ont ouverte et lue
- Le temps que les lecteurs y ont passé

Les algorithmes de filtrage combinent ces mesures pour juger si les destinataires désirent et attendent vos emails.

## Le contenu compte aussi

Le comportement des destinataires ne dit pas tout. Les fournisseurs analysent aussi ce que dit un message lorsqu'ils décident s'il s'agit de spam, et certains mots ou certaines tournures peuvent jouer contre lui.

## Les détails techniques comptent

La manière dont vous envoyez est jugée elle aussi. Les filtres anti-spam tiennent compte :

- Du nombre de connexions que vous ouvrez vers chaque domaine de réception
- De l'authentification des emails (SPF, DKIM et DMARC, voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc))
- De la façon dont vous chauffez les nouvelles adresses IP (voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip))

Vous réglez ces éléments dans votre MTA ou dans une autre infrastructure d'envoi, quel que soit le logiciel de serveur de messagerie que vous utilisez.

## Mises en garde importantes

- La décision finale revient au fournisseur de messagerie : la boîte de réception, le dossier spam ou le refus du message. De bonnes pratiques font de vos emails le genre de courrier qu'un fournisseur accepte de livrer en boîte de réception, mais aucune pratique ne peut promettre le placement en boîte de réception.
- Attendez-vous à procéder par ajustements successifs, car l'amélioration de la délivrabilité est un **processus itératif**. Chaque campagne enrichit votre historique d'envoi, et ces données montrent ce qu'il faut changer ensuite.

## Voir aussi

- [Les deux mondes de la délivrabilité email](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email), qui approfondit le principe des emails désirés et attendus
- [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)
- [Allocation de base des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip)

# Le modèle de livraison en sept étapes

> Un modèle mental du cycle de vie des campagnes (constituer la liste, créer le contenu, transmettre proprement, traiter les problèmes côté destinataire, suivre, gérer l'hygiène, affiner) qui associe chaque étape aux articles de la base de connaissances qui la traitent en détail.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fondamentaux/modele-de-livraison-en-sept-etapes

Si vous avez besoin d'une façon d'organiser le travail de délivrabilité, voyez chaque programme d'email comme un cycle de sept étapes, où chaque étape alimente la suivante. Les étapes 1–2 et 6–7 relèvent principalement de l'expéditeur (le marketeur). Les étapes 3–5 dépendent davantage de la plateforme d'envoi.

Tout le cycle repose sur une règle d'or : **envoyer un contenu intéressant et utile à des personnes qui ont accepté de le recevoir**. C'est le principe du courrier désiré et attendu décrit dans [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email).

```
        ┌─────────────────────────────────────────────┐
        ▼                                             │
1 Assemble → 2 Create → 3 Transmit → 4 Recipient → 5 Track
  the list     content     cleanly      issues       results
        ▲                                  │            │
        └────────── 6 Manage hygiene ◄─────┘   7 Fine-tune content ──► (2)
```

| Étape | Ce qu'elle recouvre | Traitée en détail dans |
|---|---|---|
| 1. Constituer la bonne liste | Une audience qui veut le courrier, y a consenti et s'y attend, avec des adresses exactes et à jour, segmentée et ciblée. | [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement), [Hygiène de base de données](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil), [Meilleures pratiques M3AAWG pour les expéditeurs](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs) |
| 2. Créer un excellent contenu | Un contenu bien écrit et utile, reconnaissable par sa marque, conforme à la loi, avec des lignes d'objet honnêtes. | [Contenu et design au service de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite), [articles sur la conformité](https://emailmarketing.net/fr/apprendre/conformite) |
| 3. Transmettre le message proprement | Un envoi authentifié et conforme aux RFC, à des débits que chaque serveur de réception accepte, depuis une infrastructure qui a mérité sa réputation. | [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi), [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf), [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc), [Chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip) |
| 4. Traiter les problèmes côté destinataire | Classer les plaintes, les rebonds, la limitation de débit, le filtrage et les désabonnements, et agir en conséquence (voir la liste des problèmes ci-dessous). | [Feedback loops de plaintes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes), [Codes d'état étendus](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp), [DSN](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison) |
| 5. Suivre les résultats | Mesurer la livraison, les ouvertures, les clics et les résultats commerciaux, et comparer les campagnes dans le temps. | [Indicateurs et valeurs de référence](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite) (y compris les limites de la mesure du taux d'ouverture), [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation) |
| 6. Gérer l'hygiène de base de données | Réinjecter dans la liste les signaux de l'étape 4 : retirer immédiatement les rebonds définitifs et les personnes qui se plaignent, retirer les adresses en rebond temporaire répété, et mettre en sommeil les contacts non engagés. | [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil) |
| 7. Affiner le contenu | Utiliser les données de l'étape 5 pour améliorer les prochains envois : lignes d'objet, offres, fréquence et segmentation. | [Contenu et design](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite), [Les deux mondes](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email) (l'économie du « moins, c'est plus ») |

La valeur du modèle tient à ses **boucles de rétroaction**. Les problèmes côté destinataire (4) doivent mettre à jour la liste (6, puis 1), et les résultats (5) doivent mettre à jour le contenu (7, puis 2). Un programme qui exécute les étapes 1–3 sans jamais boucler accumule des adresses périmées et un contenu avec lequel personne n'interagit, ce qui est exactement le profil que les fournisseurs de messagerie pénalisent.

### Répartition des responsabilités

La répartition des responsabilités proposée par le livre blanc reste un bon moyen de structurer les échanges entre un expéditeur et sa plateforme. Le **marketeur contrôle** ces facteurs de réputation : les plaintes, les rebonds définitifs, les adresses pièges touchées et le contenu. La **plateforme contrôle** ceux-ci : la conformité aux RFC et aux autres normes techniques, la mécanique de l'authentification, la gestion du débit d'envoi, et le traitement des rebonds et des rapports de feedback loop (FBL).

Aucune des deux parties ne peut compenser les défaillances de l'autre. Une plateforme n'est pas non plus un service de nettoyage de listes. Elle automatise l'entretien courant, mais partir d'une liste dûment consentie est la tâche de l'expéditeur.

## Taxonomie des problèmes côté destinataire (étape 4)

Une fois le message remis, sept types de problèmes peuvent survenir. Ils sont présentés à peu près du plus fort au plus faible effet sur la réputation :

| Problème | Ce qui se passe | Effet sur la réputation | Action de l'expéditeur |
|---|---|---|---|
| **Plaintes pour spam** | Le destinataire signale le message. Le fournisseur classe en courrier indésirable les futurs messages de cet utilisateur, et compte la plainte contre l'adresse IP et le domaine de l'expéditeur. La plainte parvient à l'expéditeur par les [feedback loops](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes) lorsqu'elles existent. Gmail n'affiche que des taux agrégés, par [Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools), et non des rapports pour chaque message. | Le signal négatif le plus fort. | Placez immédiatement en suppression la personne qui se plaint, et corrigez le problème d'acquisition ou de contenu qui cause les plaintes. **Rendez le désabonnement plus facile que la plainte** : un lien de désabonnement visible (en haut des messages longs, ou en haut et en bas) plus le [désabonnement en un clic par List-Unsubscribe](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic), que Gmail, Yahoo et Microsoft exigent désormais des expéditeurs de gros volumes. |
| **Rebonds définitifs** | Un échec définitif (5xx) : l'adresse ou le domaine est invalide ou injoignable. | Les fournisseurs surveillent de près les taux de rebonds définitifs, et peuvent bloquer une campagne en cours d'envoi si elle dépasse leur seuil. | Retirez l'adresse dès le premier rebond définitif, et ne la réactivez jamais, en raison du risque d'adresses pièges recyclées (voir [Adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges)). |
| **Rebonds temporaires** | Un échec temporaire (4xx) : une boîte pleine, une liste grise, des délais dépassés, une congestion, ou une limitation de débit par domaine ou par adresse IP. | Neutres s'ils sont bien traités. Des rebonds temporaires répétés vers la même adresse suggèrent qu'elle est périmée. | Réessayez selon la [sémantique de la RFC 5321](https://emailmarketing.net/learn/rfc/rfc5321-smtp). Placez en suppression les adresses en rebond temporaire sur plusieurs envois consécutifs. |
| **Erreurs de débit de transmission** | Envoyer trop, trop vite, surtout depuis des adresses IP qui ont peu d'historique, provoque des délais dépassés, une limitation de débit et des blocages. | Nuit directement à la réputation de l'adresse IP. | Respectez les débits attendus par chaque fournisseur, [chauffez](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip) les nouvelles adresses IP, et laissez la plateforme ajuster en temps réel les nouvelles tentatives et le débit pour chaque serveur de réception. |
| **Filtres antispam côté client** | Au-delà du filtrage du fournisseur à la passerelle, des filtres propres à chaque utilisateur (listes d'expéditeurs bloqués, modèles personnels appris) peuvent classer en courrier indésirable un message accepté pendant la session SMTP. | Invisible pour l'expéditeur, sauf sous la forme d'un engagement absent. | Gagnez la confiance de chaque utilisateur : une identité From reconnaissable, des réponses, et des ajouts au carnet d'adresses. |
| **Suppressions sans lecture** | Le message arrive, mais le destinataire le supprime sans l'ouvrir. | Les fournisseurs accordent de plus en plus de poids à l'engagement, si bien qu'un manque d'engagement persistant érode la réputation même sans aucune plainte. | Étape 7 : meilleur ciblage, meilleures lignes d'objet et fréquence adaptée. Mettez en sommeil les contacts qui n'interagissent jamais. |
| **Désabonnements** | Le destinataire se désabonne par le mécanisme prévu. | **Pas nuisible.** Un désabonnement par votre propre lien est la sortie saine, et bien préférable à une plainte. | Traitez-le immédiatement et sans friction (pas de connexion, pas de ressaisie, pas de délai). Continuer à envoyer après un désabonnement est illégal dans la plupart des juridictions. |

Quand la livraison se dégrade, le premier réflexe de diagnostic est d'établir lequel de ces problèmes survient : un problème de transmission, un problème de liste ou de contenu, ou des dégâts de réputation accumulés. Les remèdes sont complètement différents. Voir [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation) pour les outils de surveillance et la procédure de rétablissement.

## Le problème du noreply@

L'adresse From fait partie du contenu (étape 2), et c'est aussi l'un des endroits où surviennent les problèmes côté destinataire (étape 4). Envoyer depuis `noreply@`, une adresse que personne ne lit ou qui n'existe pas, dit aux abonnés « merci de ne pas nous écrire », et coûte concrètement à l'expéditeur :

1. Le courrier envoyé depuis noreply@ a plus de chances d'être ignoré, supprimé ou signalé comme spam, car les clients de messagerie modernes affichent l'adresse et pas seulement le nom d'affichage.
2. Les réponses sont des retours clients qui se perdent, y compris les tentatives de désabonnement par réponse. Une réponse « retirez-moi » que personne ne lit se transforme souvent en plainte pour spam.
3. Les réponses sont un signal positif. Quand un destinataire répond, l'expéditeur est souvent ajouté automatiquement à ses contacts ou à ses expéditeurs approuvés, ce qui améliore le placement de tous les futurs messages pour cet utilisateur.
4. Les effets observés sont des taux d'ouverture plus faibles et des taux de désabonnement et de plaintes plus élevés.

Deux autorités appuient ce point. CAN-SPAM exige que les adresses From et Reply-To et les informations de routage soient exactes et identifient l'entreprise à l'origine du message (voir [CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis)). Les [meilleures pratiques M3AAWG pour les expéditeurs](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs) indiquent que les expéditeurs devraient pouvoir traiter les demandes de désabonnement envoyées aux adresses From et Reply-To. Utilisez une vraie adresse que quelqu'un lit (`hello@`, `news@`, `info@`), et gardez des boîtes `abuse@` et `postmaster@` qui fonctionnent sur le domaine d'envoi. Le même BCP demande ces deux boîtes, ainsi qu'un enregistrement MX, sur le domaine que le serveur d'envoi utilise dans son HELO et son DNS inverse.

## Affirmations datées de la source, corrigées

Le livre blanc de 2018 précède plusieurs évolutions. Là où ses conseils ont vieilli, voici la situation actuelle :

- **Authentification** : le livre blanc citait « SPF/Sender ID, DomainKeys et DKIM », sans qu'aucun ne domine. Sender ID et DomainKeys sont dépassés depuis longtemps, et la version 4.0 des [Sender Best Common Practices du M3AAWG](https://www.m3aawg.org/senderbcp) (août 2026) les déclare formellement obsolètes tous les deux. La base actuelle est SPF et DKIM avec DMARC par-dessus, et les grands fournisseurs **exigent** l'authentification des expéditeurs de gros volumes. Voir [Gmail](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs), [Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs) et [Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs).
- **Accréditation et listes blanches tierces** (Goodmail, Habeas, certification Return Path) : ces programmes ont disparu ou sont marginaux, et les fournisseurs s'appuient désormais sur leurs propres systèmes de réputation. La confiance au niveau du destinataire (contacts et listes d'expéditeurs approuvés) compte toujours. Le secteur appelle désormais les listes d'expéditeurs approuvés des « allowlists » (listes blanches).
- **Scores de spam fondés sur des mots-clés** (« évitez des mots comme gratuit, casino ») : les filtres modernes examinent le message entier et sont pilotés par la réputation. Les listes de mots déclencheurs sont en grande partie un mythe. Voir [Contenu et design](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite) pour ce qui compte réellement dans le contenu.
- **Suivi des ouvertures** : depuis Apple Mail Privacy Protection (2021), les nombres d'ouvertures sont gonflés et peu fiables comme signal pour un destinataire individuel. Voir les limites de la mesure décrites dans [Indicateurs et valeurs de référence](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite).

## Voir aussi

- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)
- [Les deux mondes de la délivrabilité email](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email), le cadre stratégique des étapes 5–7
- [Méthodes de consentement et spectre de qualité des listes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement), sur l'étape 1
- [Indicateurs et valeurs de référence](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite), les chiffres derrière les étapes 4–6
- [Ce que mesurent les fournisseurs de messagerie, et qui s'en charge dans votre équipe](https://emailmarketing.net/fr/apprendre/fondamentaux/ce-que-mesurent-les-fournisseurs-de-messagerie), sur la façon dont la part de responsabilité de l'expéditeur se répartit entre le marketing, le responsable du DNS et la plateforme

# Lire un résultat du diagnostic de domaine

> Ce que signifient les résultats SPF, DKIM, DMARC, MX et listes de blocage quand le diagnostic de domaine indique Bon, Risqué, Mauvais ou Indéterminé, ce que le diagnostic ne voit pas (les sélecteurs qu'il n'a pas essayés, les adresses depuis lesquelles vous envoyez réellement, votre réputation), et la prochaine étape pour chacun.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fondamentaux/lire-un-resultat-du-diagnostic-de-domaine

Le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) gratuit lit les enregistrements que votre domaine publie dans le DNS public pour SPF, DKIM, DMARC et MX, et recherche les adresses autorisées par votre enregistrement SPF sur les listes de blocage qu'il interroge. Il attribue à chaque résultat l'un de quatre mots, et chaque mot a un sens précis :

| Verdict | Ce qu'il signifie |
|---|---|
| **Bon** | La vérification s'est exécutée et a trouvé ce qu'elle cherche. |
| **Risqué** | La vérification s'est exécutée et a trouvé une configuration qui fonctionne mais laisse une faille. |
| **Mauvais** | La vérification s'est exécutée et a trouvé un élément manquant ou défectueux. |
| **Indéterminé** | La vérification n'a pas obtenu de réponse. Ce n'est ni une réussite ni un échec, et le diagnostic n'indique jamais **Bon** pour une vérification qui ne s'est pas terminée. |

Les résultats décrivent ce que votre domaine indique aux fournisseurs de messagerie. Ils ne prédisent pas où arriveront vos emails. Les messages authentifiés « risquent moins d'être rejetés ou marqués comme spam », selon les termes de Google ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)). Moins de risque n'est pas une garantie, même avec tous les résultats en **Bon**.

Chaque résultat comporte aussi sa propre prochaine étape, en une ligne. Cet article explique le raisonnement derrière ces étapes, et qui s'en charge habituellement.

## SPF

SPF liste les serveurs autorisés à envoyer des emails pour votre domaine, dans un enregistrement TXT qui commence par `v=spf1` ([RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208)). Son dernier terme, le « mécanisme all », indique aux serveurs de réception comment traiter les emails provenant de n'importe où ailleurs.

| Verdict | Ce que le diagnostic a trouvé | Prochaine étape |
|---|---|---|
| **Bon** | L'enregistrement se termine par `-all` (échec strict) ou `~all` (échec souple). L'échec souple compte sur DMARC pour arrêter les emails usurpés : le résultat DMARC compte donc aussi. | Aucune action sur cet enregistrement. Tenez-le à jour quand vous ajoutez ou modifiez des services qui envoient au nom de votre domaine, et lisez le résultat DMARC. |
| **Risqué** | L'enregistrement se termine par `?all` ou `+all`, qui ne restreignent pas réellement qui peut envoyer au nom de votre domaine, ou il n'a aucun mécanisme all reconnu. | Une fois tous les expéditeurs légitimes listés, terminez l'enregistrement par `-all` (ou `~all` pendant les tests). |
| **Mauvais** | Aucun enregistrement SPF ; plusieurs ; une erreur de syntaxe ; plus de 10 requêtes DNS ; ou un `redirect=` qui pointe vers un domaine sans enregistrement SPF, ou avec plusieurs. | Publiez exactement un enregistrement commençant par `v=spf1` : fusionnez les doublons, corrigez la syntaxe, ou retirez les mécanismes inutilisés jusqu'à ce que l'évaluation demande 10 requêtes ou moins. |
| **Indéterminé** | Les requêtes DNS ont échoué ou ne se sont pas terminées à temps, ou l'enregistrement confie sa politique à un autre domaine avec `redirect=` et le diagnostic ne l'a pas suivi. | Réessayez dans un instant. Pour une redirection, consultez l'enregistrement SPF du domaine cible : son mécanisme all est la politique qu'appliquent les serveurs de réception. |

Pourquoi ces cas sont **Mauvais** : la RFC 7208 indique que plus d'un enregistrement SPF, une erreur de syntaxe n'importe où dans l'enregistrement, ou plus de 10 termes qui interrogent le DNS font tous aboutir l'évaluation SPF à une « permerror », une erreur permanente et non une réussite ([RFC 7208 §4.5, §4.6 et §4.6.4](https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4)).

**Qui agit :** le responsable du DNS modifie l'enregistrement. Votre plateforme d'envoi vous indique quoi inclure pour ses serveurs. Google indique que SPF doit inclure tous les expéditeurs d'emails de votre domaine, et que les emails des expéditeurs qui n'y figurent pas sont plus susceptibles d'être marqués comme spam ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)).

## DKIM

DKIM signe chaque message avec une clé. La moitié publique de cette clé est publiée dans le DNS sous un nom appelé sélecteur, que la signature elle-même indique dans sa balise `s=` ([RFC 6376 §3.1 et §3.5](https://datatracker.ietf.org/doc/html/rfc6376#section-3.1)). Le sélecteur est choisi par celui qui signe les emails : une requête DNS ne peut donc qu'essayer des noms et voir ce qui répond.

| Verdict | Ce que le diagnostic a trouvé | Prochaine étape |
|---|---|---|
| **Bon** | Une clé DKIM est publiée à un sélecteur. C'est ce que le DNS peut montrer, et non que vos messages sont signés. Le même verdict apparaît quand le domaine n'autorise aucun serveur à envoyer (`v=spf1 -all`), puisqu'un domaine qui n'envoie pas d'emails n'a pas besoin de clé DKIM. | Vérifiez un vrai message : envoyez-en un à une boîte que vous contrôlez et cherchez dans son en-tête `Authentication-Results` un `dkim=pass` avec un `d=` qui correspond à votre domaine From. Faites tourner la clé périodiquement. |
| **Mauvais** | Un enregistrement existe au sélecteur, mais sa clé publique est absente ou mal formée. | Régénérez la paire de clés et republiez la clé publique. Votre plateforme d'envoi fournit généralement l'enregistrement à publier. |
| **Indéterminé** | Aucune clé à aucun des sélecteurs courants essayés par le diagnostic, ni au sélecteur que vous avez saisi. Le résultat nomme les sélecteurs vérifiés. | Demandez à votre plateforme d'envoi avec quel sélecteur elle signe, puis relancez le diagnostic avec ce nom dans le champ « Sélecteur DKIM (facultatif) ». |

Il n'existe pas de résultat DKIM **Risqué**. Une clé est soit trouvée et utilisable, soit trouvée et défectueuse, soit introuvable là où le diagnostic a cherché.

**Qui agit :** la plateforme génère la clé et signe les emails ; le responsable du DNS publie la clé publique. [L'en-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results) explique comment lire `dkim=pass` ([RFC 8601](https://datatracker.ietf.org/doc/html/rfc8601)), et [Rotation des clés DKIM](https://emailmarketing.net/fr/apprendre/authentification/rotation-des-cles-dkim) traite de la rotation.

## DMARC

DMARC, publié à `_dmarc.<your domain>`, indique aux serveurs de réception que faire des emails qui échouent à l'authentification pour votre domaine, et où envoyer les rapports ([RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489)). Sa balise `p=` est la politique : `none` ne demande aucune action particulière, `quarantine` demande aux serveurs de réception de traiter les emails en échec comme suspects, et `reject` leur demande de les rejeter. La balise `rua=` nomme l'adresse qui reçoit les rapports agrégés (RFC 7489 §6.3).

| Verdict | Ce que le diagnostic a trouvé | Prochaine étape |
|---|---|---|
| **Bon** | Une politique contraignante est appliquée (`p=quarantine` ou `p=reject`) avec des rapports agrégés configurés. | Aucune action. Examinez périodiquement les rapports agrégés pour repérer des expéditeurs que vous ne reconnaissez pas. |
| **Risqué** | Mode surveillance seule (`p=none`) : les rapports sont collectés, mais les serveurs de réception ne sont pas invités à mettre en quarantaine ou à rejeter les emails non authentifiés. Ou une politique contraignante est appliquée sans adresse `rua=`, si bien que personne ne voit les rapports. | Ajoutez une adresse `rua=` s'il n'y en a pas. Une fois que les rapports montrent que tous les expéditeurs légitimes réussissent, passez à `p=quarantine`, puis à `p=reject`. |
| **Mauvais** | Aucun enregistrement DMARC ; plusieurs, auquel cas les serveurs de réception n'en appliquent aucun ; ou un enregistrement sans politique `p=` reconnue. | Publiez un seul enregistrement TXT à `_dmarc.<your domain>` commençant par `v=DMARC1; p=none;` pour commencer la surveillance, ou retirez les enregistrements en trop, ou ajoutez la balise `p=`. |
| **Indéterminé** | La requête DNS a échoué ou ne s'est pas terminée à temps. | Réessayez dans un instant. |

Sur les enregistrements multiples, la RFC 7489 est explicite : s'il reste plus d'un enregistrement DMARC, « la découverte de la politique s'arrête et le traitement DMARC n'est pas appliqué à ce message » ([RFC 7489 §6.6.3](https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.3)).

**Risqué ne veut pas dire non conforme.** Gmail, Yahoo et Microsoft acceptent `p=none` pour leur exigence DMARC envers les expéditeurs de gros volumes ([Gmail](https://support.google.com/mail/answer/81126?hl=en), [Yahoo](https://senders.yahooinc.com/best-practices/), [Outlook.com](https://substrate.office.com/ip-domain-management-snds/postmaster/policies)). Le verdict **Risqué** désigne la faille qui subsiste : les emails qui usurpent votre domaine ne sont pas arrêtés. Le M3AAWG recommande `p=reject` lorsque c'est possible, et indique que tout enregistrement DMARC, même avec `p=none`, devrait inclure au minimum une balise `rua` ([meilleures pratiques M3AAWG pour l'authentification des emails](https://www.m3aawg.org/sites/default/files/legacy/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf)).

**Qui agit :** le responsable du DNS publie et modifie l'enregistrement. Passer de `p=none` à une politique contraignante est une décision à prendre avec les rapports agrégés en main, parce qu'ils montrent quels services envoient au nom de votre domaine. [Déploiement de DMARC en détail](https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc) traite du déploiement.

## MX

Les enregistrements MX nomment les serveurs qui reçoivent les emails de votre domaine. Ils comptent pour un domaine d'envoi parce que les réponses et les rebonds y reviennent.

| Verdict | Ce que le diagnostic a trouvé | Prochaine étape |
|---|---|---|
| **Bon** | Un ou plusieurs enregistrements MX. Ou un MX nul accompagné de `v=spf1 -all` : un domaine correctement configuré pour n'envoyer ni recevoir aucun email. | Aucune action. |
| **Risqué** | Un MX nul, qui indique que le domaine n'accepte aucun email, sur un domaine qui envoie peut-être des emails. | Si le domaine envoie des emails, remplacez le MX nul par un enregistrement MX qui pointe vers un serveur capable de recevoir les réponses et les rebonds. |
| **Mauvais** | Aucun enregistrement MX. | Ajoutez un enregistrement MX qui pointe vers le serveur de messagerie du domaine. |
| **Indéterminé** | La requête DNS a échoué ou ne s'est pas terminée à temps. | Réessayez dans un instant. |

Le MX nul est défini dans la [RFC 7505](https://datatracker.ietf.org/doc/html/rfc7505). Son §4.2 indique que les systèmes de messagerie « NE DEVRAIENT PAS publier d'enregistrement MX nul pour des domaines qu'ils utilisent dans des adresses RFC5321.MailFrom ou RFC5322.From », et qu'un domaine qui le fait « risque de voir ses emails rejetés ». Sans aucun enregistrement MX, SMTP se rabat sur l'enregistrement d'adresse du domaine lui-même, un « MX implicite » ([RFC 5321 §5.1](https://datatracker.ietf.org/doc/html/rfc5321#section-5.1)) : le diagnostic l'indique donc comme **Mauvais** plutôt que comme un serveur de messagerie désigné.

**Qui agit :** le responsable du DNS, avec la personne qui gère les boîtes de messagerie de votre domaine.

## Listes de blocage

Une liste de blocage DNS publie des adresses IP dans le DNS pour que les serveurs de réception puissent les consulter au moment de décider s'ils acceptent un email ([RFC 5782](https://datatracker.ietf.org/doc/html/rfc5782)). Le diagnostic lit votre enregistrement SPF pour trouver les adresses que vous autorisez, puis recherche chacune d'elles sur les listes de blocage qu'il interroge.

| Verdict | Ce que le diagnostic a trouvé | Prochaine étape |
|---|---|---|
| **Bon** | Aucune inscription sur les listes de blocage vérifiées, pour les sources d'envoi vérifiées. Si certaines listes n'ont pas pu être interrogées, le résultat indique combien. Le même verdict apparaît quand le domaine n'autorise aucun serveur à envoyer. | Aucune action pour les listes vérifiées. Relancez le diagnostic périodiquement, surtout après un changement de vos adresses d'envoi. |
| **Mauvais** | Inscrit sur une ou plusieurs listes de blocage. Le résultat nomme chaque adresse et chaque liste. | Résolvez d'abord la cause, puis suivez la procédure de retrait de liste de chaque liste de blocage. Un retrait de liste sans correction de la cause aboutit souvent à une nouvelle inscription. |
| **Indéterminé** | Votre enregistrement SPF ne nomme aucune source d'envoi qui se résout en adresse, donc rien n'a pu être vérifié ; ou les requêtes ont échoué ou n'ont donné aucune réponse exploitable. | Vérifiez directement les adresses IP depuis lesquelles vous envoyez réellement, avec l'outil de recherche propre à chaque liste de blocage. |

**Qui agit :** si vous envoyez depuis les adresses IP partagées de votre plateforme, c'est à la plateforme de résoudre l'inscription. Google note que sur une adresse IP partagée, « l'activité des expéditeurs utilisant une adresse IP partagée a une incidence sur la réputation de tous ceux qui ont recours à cette adresse » ([consignes de Google pour les expéditeurs d'emails](https://support.google.com/mail/answer/81126?hl=en)). Si les adresses sont les vôtres, la cause se trouve généralement dans votre liste ou vos systèmes. [Listes de blocage DNS et zones Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus) traite des causes et du retrait de liste.

## Ce que ce diagnostic ne voit pas

Un résultat propre couvre ce que le diagnostic a pu lire. Voici ses limites, et où regarder à la place :

| Ce qu'il ne voit pas | Pourquoi | Où regarder à la place |
|---|---|---|
| **Les sélecteurs qu'il n'a pas essayés** | Les sélecteurs DKIM sont choisis par le signataire, pas listés dans le DNS. | Demandez le sélecteur à votre plateforme et saisissez-le dans le champ « Sélecteur DKIM (facultatif) », ou lisez `s=` dans l'en-tête `DKIM-Signature` d'un vrai message. |
| **Si vos emails sont signés, réussissent et sont alignés** | Le diagnostic ne lit que le DNS. Une clé publiée et un enregistrement SPF correct ne montrent pas ce qui arrive à un vrai message. | Envoyez un message à une boîte que vous contrôlez et lisez son en-tête `Authentication-Results`. |
| **Les adresses depuis lesquelles vous envoyez réellement** | Les recherches sur les listes de blocage utilisent les adresses autorisées par votre enregistrement SPF. Les expéditeurs nommés par `include:` ne sont pas développés, l'adresse d'un site web et les serveurs de réception d'un fournisseur de messagerie ne sont jamais vérifiés, et un diagnostic couvre un nombre limité d'adresses. Le résultat indique quand l'un de ces cas s'applique. | Demandez à votre plateforme depuis quelles adresses IP partent vos emails, et vérifiez-les directement avec l'outil de recherche propre à chaque liste de blocage. |
| **Toutes les listes de blocage** | Le diagnostic interroge un ensemble fixe de listes de blocage. Spamhaus n'est pas vérifié : son service gratuit est réservé à un usage non commercial, et l'outil n'a pas de licence commerciale. | L'outil de recherche propre à chaque liste de blocage. |
| **Votre réputation, vos plaintes et votre placement** | Ces données se trouvent chez les fournisseurs de messagerie, pas dans le DNS. | Les rapports de rebonds et de plaintes de votre plateforme, et Google Postmaster Tools pour Gmail. [Est-ce un problème de livraison ?](https://emailmarketing.net/fr/apprendre/fondamentaux/est-ce-un-probleme-de-livraison) montre comment les lire ensemble. |

## Voir aussi

- [Est-ce un problème de livraison ? Le savoir avant de dépenser](https://emailmarketing.net/fr/apprendre/fondamentaux/est-ce-un-probleme-de-livraison) : la place du diagnostic de domaine parmi les autres éléments
- [Ce que mesurent les fournisseurs de messagerie, et qui s'en charge dans votre équipe](https://emailmarketing.net/fr/apprendre/fondamentaux/ce-que-mesurent-les-fournisseurs-de-messagerie) : qui est responsable de l'authentification, et les signaux que le DNS ne montre pas
- [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf), [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) : chaque protocole en détail
- [Authentification du domaine des clients](https://emailmarketing.net/learn/esp-operations/customer-domain-authentication) : comment les plateformes d'envoi configurent l'authentification pour votre domaine

# Apple iCloud Mail : exigences postmaster

> Les exigences publiées par Apple pour l'envoi d'emails en masse vers iCloud Mail (mac.com, me.com, icloud.com), son modèle de filtrage et sa procédure d'escalade.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/apple-icloud-mail-exigences-postmaster

Si vous envoyez des emails en masse à des adresses **mac.com**, **me.com** ou **icloud.com**, vos messages doivent respecter chacune des exigences d'Apple, sinon ils seront rejetés. Contrairement à Gmail ou Yahoo, Apple ne publie aucun seuil chiffré, mais indique clairement que **toutes les exigences doivent être respectées, faute de quoi l'email sera rejeté**.

Apple expose ses règles dans un seul document postmaster, l'article d'assistance 102322, dont la dernière publication date du 2025-02-25.

## Exigences pour l'envoi d'emails en masse

Chaque point ci-dessous est obligatoire, et manquer à l'un d'eux justifie un rejet :

| N° | Exigence |
|---|-------------|
| 1 | N'envoyer qu'aux destinataires qui se sont **expressément abonnés** : pas de listes achetées, de listes louées ni d'enrichissement de fichiers |
| 2 | Proposer un **lien de désabonnement** pour que le destinataire puisse se désabonner immédiatement |
| 3 | Ajouter des **en-têtes ARC** aux emails transférés |
| 4 | Respecter la **RFC 5321** et la **RFC 5322** |
| 5 | Publier un **DNS inverse (PTR)** avec votre domaine pour aider à identifier vos IP |
| 6 | Utiliser **des IP et des domaines d'envoi constants**, mais **séparer les flux marketing et transactionnels** |
| 7 | Utiliser **un nom et une adresse `From:` constants** qui identifient clairement votre marque |
| 8 | S'authentifier avec **SPF** et **DKIM** |
| 9 | Le domaine d'envoi **doit publier une politique DMARC** |
| 10 | Suivre les **erreurs SMTP** temporaires et permanentes renvoyées par les serveurs d'Apple et agir en conséquence |
| 11 | Disposer d'une **politique de gestion des rebonds** standard |
| 12 | **Retirer périodiquement les abonnés inactifs** |
| 13 | **Ne jamais réactiver** des adresses déjà présentes dans votre liste de désabonnement ou de suppression |

Apple renvoie aussi les expéditeurs aux meilleures pratiques de communication du M3AAWG comme norme de référence.

Deux exigences se distinguent par rapport aux autres fournisseurs : l'obligation explicite d'**ajouter des en-têtes ARC lors d'un transfert**, et celle de **séparer le courrier marketing du courrier transactionnel** sur des flux distincts (voir [Segmentation avancée des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip)).

## Le filtrage d'iCloud Mail

- **Pas de liste blanche.** Apple indique explicitement ne pas en proposer. Les décisions de filtrage reposent sur la réputation d'expéditeur, suivie à travers **la réputation des IP, la réputation du domaine, des contrôles de contenu et les retours des utilisateurs**.
- **Pas de feedback loop (FBL).** Apple n'en propose pas non plus. Comme vous ne recevez aucun signal de plainte, l'hygiène de base de données est le seul substitut. Les conseils d'Apple eux-mêmes :
  - placer périodiquement en liste de suppression les abonnés inactifs ou désengagés ;
  - retirer les adresses qui rebondissent régulièrement ;
  - traiter les demandes de désabonnement le plus vite possible.
- Le courrier indésirable est détecté et bloqué **avant d'atteindre la boîte de réception**, et même un message légitime peut parfois être classé à tort comme indésirable.

Sans FBL ni liste blanche, l'hygiène fondée sur l'engagement est tout ce sur quoi vous pouvez compter chez iCloud. Le principe du message « souhaité et attendu » exposé dans [Fondamentaux](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email) s'applique sans filet de sécurité.

## La politique d'authentification d'Apple elle-même (entrante et sortante)

- iCloud Mail authentifie **tous les messages entrants** avec SPF et DKIM.
- iCloud Mail **applique la politique DMARC du domaine d'envoi** aux messages entrants.
- Tous les domaines iCloud publient des enregistrements SPF et signent tous les messages sortants avec DKIM.
- Tous les domaines iCloud publient une politique DMARC **`p=quarantine`** (en vigueur depuis le **2 juillet 2018**). Un message qui prétend venir d'une adresse iCloud mais échoue à SPF et à DKIM devrait aller dans le courrier indésirable.
- Pour connaître les plages d'IP sortantes d'Apple, interrogez les **enregistrements SPF** de mac.com, me.com et icloud.com. Ils sont la source de référence publiée pour les adresses IP sortantes d'Apple.

En pratique, ne mettez jamais une adresse `@icloud.com`, `@me.com` ou `@mac.com` usurpée dans votre en-tête `From:`. Les récepteurs qui appliquent la politique de quarantaine d'Apple la classeront en courrier indésirable. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Diagnostiquer les rejets et procédure de déblocage

Il n'existe pas de formulaire en libre-service pour demander un déblocage. La procédure est la suivante :

1. **Lisez l'erreur SMTP.** Les serveurs de messagerie d'Apple renvoient des erreurs SMTP qui expliquent pourquoi une connexion ou un message a été rejeté, et la plupart comportent une **URL donnant plus d'informations**. Consultez vos journaux de messagerie.
2. **Corrigez le problème en vous appuyant sur le tableau des exigences ci-dessus.** Le premier remède recommandé par Apple est de « suivre les meilleures pratiques » (*follow the best practices*).
3. **Escaladez auprès de l'équipe postmaster** seulement si les étapes 1 et 2 ne règlent pas le problème. Écrivez à **icloudadmin@apple.com** en fournissant **l'ensemble** des éléments suivants :
   - le nom de votre entreprise
   - votre domaine email
   - les adresses IP des serveurs de messagerie concernés
   - les erreurs SMTP reçues des serveurs de messagerie d'iCloud
   - une description détaillée du problème, y compris **la date à laquelle il a commencé**

Les personnes qui ne sont pas administrateurs (utilisateurs finaux) doivent plutôt contacter l'assistance Apple, car icloudadmin@ est réservé aux administrateurs système.

# Canaux d'escalade de Microsoft

> La carte des corrections pour les blocages Microsoft : portail de retrait d'IP antispam d'Office 365 (sender.office.com), delist@microsoft.com pour le 5.7.511, formulaire d'assistance aux expéditeurs d'Outlook.com, conditions préalables SNDS/JMRP, ce dont chaque canal a besoin et des délais réalistes.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-de-microsoft

Lorsque Microsoft bloque vos messages, le canal capable de lever le blocage dépend du système de Microsoft qui l'a appliqué. Microsoft exploite **deux systèmes de filtrage distincts, chacun avec ses propres voies de correction**, et escalader auprès du mauvais fait perdre des jours. Commencez par classer le blocage :

| Symptôme | Système | Canal |
|---|---|---|
| NDR `550 5.7.606–649 Access denied, banned sending IP` provenant d'un destinataire **professionnel ou client** (un domaine personnalisé sur Microsoft 365) | EOP (Office 365) | Portail de retrait `https://sender.office.com` |
| NDR `550 5.7.511 Access denied, banned sender` | EOP (Office 365), sur la liste qui nécessite une enquête approfondie | Email à `delist@microsoft.com` |
| `550 5.7.703 ... Tenant Allow Block List` | Un blocage posé par un seul client destinataire | Seul l'administrateur de ce client peut le corriger ; il n'existe aucun canal Microsoft |
| `421 RP-001/002/003`, `550 SC-001..004`, `DY-001/002`, `OU-001/002`, ou messages classés en courrier indésirable chez **@outlook.com, @hotmail.com, @live.com ou @msn.com** | Outlook.com grand public | Formulaire d'assistance aux expéditeurs (ci-dessous), après les conditions préalables SNDS et JMRP |

Pour la signification de chaque code, voir [Exigences de Microsoft envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs). Pour diagnostiquer à partir des en-têtes les messages envoyés à un client Microsoft, voir [Le fonctionnement interne du filtrage de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/fonctionnement-interne-du-filtrage-de-microsoft).

## Canal 1 : Office 365 Anti-Spam IP Delist Portal (sender.office.com)

Utilisez ce canal pour les adresses IP inscrites sur la **liste des expéditeurs bloqués** d'EOP (plage de NDR `5.7.606–649`, dont le message renvoie lui-même vers le portail). Il fonctionne en libre-service, une adresse IP à la fois.

Procédure :

1. Rendez-vous sur `https://sender.office.com`.
2. Saisissez **l'adresse email qui a reçu le NDR** et **l'adresse IP indiquée dans le message d'erreur** (une adresse email et une adresse IP par visite), puis passez le CAPTCHA.
3. Microsoft envoie un email de vérification à cette adresse. Cliquez sur le lien de confirmation pour revenir au portail.
4. Sélectionnez **Delist IP**.

Il vous faut le texte exact du NDR (l'adresse IP et le code) et une boîte fonctionnelle à l'adresse saisie. Sur le délai, Microsoft indique que les résultats varient et que le retrait complet **peut prendre jusqu'à 24 heures, voire plus**.

Le retrait ne lève que le blocage en bordure. Les messages doivent encore passer le filtrage d'EOP et de MDO, y compris l'authentification composite, et si le trafic reste abusif, l'adresse IP est de nouveau bloquée. Comme pour tout [retrait d'une liste de blocage](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus), corrigez la cause profonde (une compromission, la qualité de la liste, l'authentification) avant de demander le retrait.

## Canal 2 : delist@microsoft.com (erreur 5.7.511)

`550 5.7.511 Access denied, banned sender` signifie que l'adresse IP figure sur une liste qui exige **une enquête supplémentaire de Microsoft**, et le portail en libre-service ne peut explicitement pas régler le problème. Transférez le rebond à **`delist@microsoft.com`** en incluant **le texte intégral du NDR et l'adresse IP**. Microsoft indique qu'il répondra **sous 48 heures** avec la marche à suivre. Attendez-vous à des questions sur le trafic, et ayez sous la main des preuves sur le volume, le consentement et les corrections.

## Canal 3 : formulaire d'assistance aux expéditeurs d'Outlook.com (boîtes grand public)

Ce canal sert uniquement aux problèmes de délivrabilité vers Outlook.com grand public, c'est-à-dire « any address @msn.com, @Outlook.com, @hotmail.com, or @live.com ». Utilisez-le pour les messages classés en courrier indésirable, pour les blocages pour plaintes `SC-004` une fois la correction faite, pour une limitation de débit (`RP-00x`) qui ne se résorbe pas et pour demander une levée des restrictions pendant la chauffe.

**Conditions préalables que Microsoft attend avant toute demande** (les demandes qui ne les remplissent pas reçoivent généralement des refus types) :

1. Vérifiez que vous respectez la page des politiques d'Outlook.com (authentification, enregistrements PTR, limites de connexions ; voir [Exigences de Microsoft envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs)).
2. Inscrivez les adresses IP à **SNDS et JMRP**, ou mettez leur inscription à jour. Les nouvelles adresses IP doivent être ajoutées à votre compte JMRP. Voir [Microsoft SNDS et JMRP](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp). Les données SNDS (couleur du filtre, taux de plaintes, proportion d'échecs RCPT) sont aussi les preuves que vous citerez dans le ticket.
3. Consultez d'abord la FAQ de dépannage pour votre code d'erreur exact.

**Où se trouve le formulaire** : l'article d'assistance de Microsoft « Sender Support in Outlook.com » (`https://support.microsoft.com/en-us/outlook/sender-support-in-outlook-com`) et la page de dépannage postmaster renvoient tous deux vers le formulaire. Il se trouvait historiquement à `https://sendersupport.olc.protection.outlook.com/pm/Troubleshooting`, et il est aussi accessible par le redirecteur `https://go.microsoft.com/fwlink/?LinkID=614866`.

Les pages postmaster et SNDS ont migré vers `https://substrate.office.com/ip-domain-management-snds/`, et l'ancien domaine `sendersupport.olc.protection.outlook.com` est obsolète à partir du **22 juin 2026**. Attendez-vous à ce que le lien du redirecteur vous mène à l'emplacement actuel du formulaire. Pour le lien en vigueur, suivez la page Troubleshooting postmaster (`https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting`).

**Ce qu'il faut inclure** : les adresses IP d'envoi concernées, le texte ou le code exact de l'erreur SMTP, les domaines d'envoi, une description du flux de messages (volume, méthode d'opt-in) et les corrections déjà effectuées (suppression des plaignants JMRP, nettoyage de la liste, corrections de l'authentification).

**Déroulement et délais réalistes** (largement rapportés par les praticiens ; ce n'est pas un niveau de service officiel) :

- Le formulaire produit une **réponse automatique**, qui indique souvent « no problem detected » ou propose une levée des restrictions générique sous conditions.
- **Répondez à cet email automatique** pour faire remonter la demande à un agent humain. Les réponses arrivent depuis des adresses `olcsupport.office.com`, et une réponse humaine prend généralement d'un à plusieurs jours ouvrés.
- Lorsqu'elle est accordée, la levée des restrictions est généralement temporaire ou conditionnelle. La réputation doit être reconstruite par le comportement d'envoi, d'abord à faible volume.
- Les nouvelles adresses IP ont besoin d'**environ 2 semaines ou plus** de construction de la réputation chez Outlook.com. SPF sur un domaine qui a déjà une bonne réputation accélère la montée en charge.

Il existe aussi un **formulaire distinct de retrait de liste pour Outlook.com grand public** à l'adresse `https://support.microsoft.com/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75`, cité dans l'article de Microsoft sur le retrait EOP pour les blocages côté grand public. Lisez la FAQ de dépannage avant de le soumettre.

## Canal 4 : problèmes que seul le client destinataire peut corriger (aucun canal Microsoft)

Dans certains cas, **il n'existe aucun canal Microsoft destiné aux expéditeurs** : lorsque les en-têtes montrent `SFV:SKB` ou `SFV:BLK` (les listes de blocage du destinataire), lorsqu'une entrée de la Tenant Allow/Block List vous bloque (`5.7.703`), ou lorsque le message est mis en quarantaine comme phishing à haut niveau de confiance à cause d'une URL ou d'un domaine que le client a bloqué. L'administrateur de l'organisation destinataire doit retirer l'entrée, ou soumettre le message à Microsoft comme faux positif par la page Submissions de Defender (`https://security.microsoft.com/reportsubmission`). Une soumission est aussi la seule voie pour obtenir une autorisation face à un verdict de logiciel malveillant ou de phishing à haut niveau de confiance. Fournissez à l'administrateur du destinataire les en-têtes complets et le guide de terrain [Le fonctionnement interne du filtrage de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/fonctionnement-interne-du-filtrage-de-microsoft).

## Liste de contrôle de l'escalade (procédure de consultant)

1. **Classez** le blocage à partir du code SMTP exact ou du verdict dans les en-têtes (voir le tableau en haut de page).
2. **Corrigez d'abord la cause profonde** : alignement de l'authentification, hôtes compromis, causes des plaintes, hygiène de base de données. Microsoft bloque de nouveau les expéditeurs dont les corrections n'existent que sur le papier.
3. **Inscrivez-vous à SNDS et JMRP** avant tout contact au sujet des boîtes grand public, et récupérez la vue SNDS des jours de l'incident.
4. **Utilisez le canal le plus ciblé** : le portail pour les 606–649 ; `delist@microsoft.com` pour le 5.7.511 ; le formulaire d'assistance aux expéditeurs pour les problèmes d'Outlook.com grand public ; l'administrateur du destinataire pour les blocages posés par un client.
5. **Gardez une trace écrite** : les identifiants de tickets et les réponses automatiques. Ce sont les réponses à l'email automatique qui atteignent des humains.
6. **Vérifiez après la levée des restrictions** : surveillez les résultats du filtre dans SNDS et faites des tests sur liste de test vers des boîtes grand public. Augmentez le volume progressivement, comme après une [chauffe](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip).

## Voir aussi

- [Exigences de Microsoft envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs), avec le catalogue des codes d'erreur et des politiques
- [Le fonctionnement interne du filtrage de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/fonctionnement-interne-du-filtrage-de-microsoft), pour lire les en-têtes de verdict
- [Microsoft SNDS et JMRP](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp), les conditions préalables obligatoires
- [Listes de blocage DNS et zones Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus), car les blocages OU-001 sont liés à Spamhaus

# Canaux d'escalade et de levée des restrictions des fournisseurs

> La carte, tous fournisseurs confondus, des canaux d'assistance aux expéditeurs, de levée des restrictions et de déblocage (Google, Yahoo, Apple, Microsoft), avec les formulaires exacts, les champs obligatoires, les conditions d'éligibilité et les preuves à rassembler avant toute escalade.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-et-de-levee-des-restrictions

Quand un fournisseur de messagerie bloque vos messages ou les classe mal alors que vous en avez corrigé la cause, vous lui demandez une levée des restrictions. Chaque grand fournisseur propose un canal différent, avec des conditions préalables différentes, et tous ont un point commun : **l'escalade n'aide que les expéditeurs déjà conformes**.

Les fournisseurs utilisent ces canaux pour lever les blocages qui subsistent sur un trafic corrigé. Ils ne s'en servent pas pour passer outre leurs filtres au profit d'expéditeurs qui n'ont pas corrigé la cause profonde. Corrigez d'abord, escaladez ensuite.

## Préparation commune : les preuves à rassembler avant toute escalade

Chaque formulaire ou boîte postmaster d'un fournisseur demande une partie du même ensemble de preuves. Réunissez-le avant d'ouvrir le moindre ticket :

| Preuve | Détails |
|---|---|
| Textes d'erreur exacts | Le texte intégral de la réponse SMTP tiré de vos journaux, mot pour mot, y compris les codes d'état étendus, les identifiants propres au fournisseur (par exemple le suffixe `gsmtp` ou `gcdp` de Gmail) et les URL qui figurent dans le texte |
| Chronologie | La date de début du problème, son caractère intermittent ou constant, et ce qui a changé autour de cette date (nouvelles adresses IP, nouveau client, hausse brutale du volume, changement de modèle) |
| Infrastructure concernée | Les adresses IP d'envoi (une par ligne, car plusieurs formulaires les lisent ainsi), les enregistrements PTR, les domaines d'envoi, et les flux et clients qui les utilisent |
| État de l'authentification | La preuve que SPF, DKIM et DMARC réussissent actuellement avec alignement pour le domaine concerné (l'idéal est un en-tête `Authentication-Results` tiré d'un message livré) |
| Historique de volume | Le volume quotidien vers le fournisseur concerné au cours des semaines précédentes. Les fournisseurs recherchent les pics avant d'accorder une levée des restrictions |
| Données de réputation | Les chiffres actuels de taux de spam et de plaintes tirés du tableau de bord du fournisseur lui-même ([Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools), [Microsoft SNDS](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp), [flux de données de délivrabilité de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/flux-de-donnees-de-delivrabilite-de-yahoo)) |
| En-têtes complets d'un message concerné | Des messages récents. Google exige les en-têtes de messages **de moins de 12 jours** |
| Corrections déjà effectuées | Ce que vous avez corrigé et quand. Les escalades qui obtiennent une levée des restrictions sont celles qui énumèrent des mesures correctives concrètes |

## Google (Gmail)

Google exploite deux canaux d'escalade, tous deux soumis à une condition d'éligibilité stricte. La page marketing `gmail.com/postmaster` ne fait que renvoyer vers la console Postmaster Tools, à l'adresse `postmaster.google.com`.

### Condition d'éligibilité (valable pour les deux canaux)

Depuis juin 2024, les expéditeurs de gros volumes dont le taux de spam signalé par les utilisateurs est **supérieur à 0,3 %** sont **inéligibles à la levée des restrictions**. Ils ne redeviennent éligibles qu'une fois que le taux de spam dans Postmaster Tools reste **sous 0,3 % pendant 7 jours consécutifs**. Une authentification SPF, DKIM et DMARC complète et un désabonnement en un clic fonctionnel sont des conditions préalables. Voir l'éligibilité à la levée des restrictions dans [Exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs#éligibilité-à-la-levée-des-restrictions).

### Canal 1 : « Report delivery issue » dans Postmaster Tools (à privilégier)

Le canal d'escalade le plus récent de Google, dont vous pouvez suivre l'avancement, se trouve dans la console Postmaster Tools (documenté à l'adresse support.google.com/mail/answer/16740603). Utilisez-le pour les messages **classés à tort comme spam ou phishing, rejetés ou en échec temporaire**.

Conditions préalables :

1. Le domaine est **validé** dans Postmaster Tools.
2. Le domaine **respecte les consignes de Google pour les expéditeurs d'emails** (authentification SPF et DKIM), et le domaine de l'en-tête `From:` correspond au domaine sous lequel vous faites le signalement.

Procédure :

1. Connectez-vous à Postmaster Tools.
2. Ouvrez **Report delivery issue** (dans le menu en bas à gauche).
3. Sélectionnez le domaine dans la liste déroulante, puis **Create new report**.
4. Renseignez les détails du message. L'assistant **« Get message info for me »** remplit le formulaire à votre place : ouvrez le message concerné, choisissez **Show original**, copiez le message brut, collez-le dans le champ du formulaire et cliquez sur **Get info**.
5. Soumettez le signalement. Suivez son avancement dans **Reported issues** sur le tableau de bord du domaine, où chaque escalade a un statut.

Google ne publie aucun engagement de délai de réponse pour ce canal.

### Canal 2 : le Sender Contact Form (ancien formulaire d'escalade pour les expéditeurs de gros volumes)

Le formulaire autonome à l'adresse `support.google.com/mail/contact/bulk_send_new` (« Sender Contact Form ») reste ouvert. Toutefois, le texte de Google sur ce formulaire recommande désormais de passer plutôt par le parcours **Report delivery issues** de Postmaster Tools, dont l'avancement est plus facile à suivre.

| Champ | Obligatoire |
|---|---|
| Name | non |
| Email address | oui |
| Issue type (liste déroulante) | oui |
| Short summary of issue | oui |
| Detailed description | oui |
| Email headers (selon le type de problème) | conditionnel |

La liste déroulante du type de problème propose :

1. "Your messages are incorrectly classified as Spam or Phishing"
2. "You get SMTP temp-fails or rejects"
3. "Other"

Le formulaire énonce ces règles :

- Respectez les consignes pour les expéditeurs **avant** de demander une levée des restrictions.
- Les en-têtes soumis doivent provenir de messages **de moins de 12 jours**.
- Laissez **au moins 2 semaines entre deux soumissions** pour que les changements prennent effet.
- Suivez les résultats dans Postmaster Tools plutôt que d'attendre une réponse.

### Ce que la levée des restrictions de Google peut et ne peut pas corriger

Ce canal traite les erreurs de classement et les blocages qui subsistent sur un trafic **conforme** (par exemple des blocages 5.7.x qui persistent après correction, ou des erreurs de livraison « Suspected spam » dans le tableau de bord). Il ne peut pas lever la barrière des 0,3 %, remplacer les corrections d'authentification ni garantir le placement en boîte de réception. Pour les corrections que vous pouvez faire vous-même, erreur par erreur, voir [Erreurs SMTP de Gmail et dépannage](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/depannage-gmail).

## Yahoo (y compris AOL)

Le point d'entrée des escalades chez Yahoo est `senders.yahooinc.com/contact/`, qui mène à quatre parcours :

| Parcours | Canal |
|---|---|
| Problèmes de livraison vers des boîtes AOL ou Yahoo | **Sender Support Request**, le formulaire Salesforce « Email a Specialist » (iframe intégrée : `https://vzmmemberservices.my.salesforce-sites.com/?fc=SSR`) |
| Signaler un abus provenant de domaines AOL ou Yahoo | Le formulaire Report Abuse (sur le même site Salesforce, `?fc=ReportAbuse`). Joignez le texte intégral du message et ses en-têtes |
| Mise en place et gestion de la Complaint Feedback Loop | Renvoie vers la [page de la CFL](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/feedback-loop-de-plaintes-de-yahoo). Au moment de la capture, la page de contact indiquait que son nouveau formulaire d'inscription à la CFL était temporairement indisponible, et elle renvoyait au même parcours « Email a specialist » de l'aide Yahoo |
| Questions générales et de développeurs | `mail-questions@yahooinc.com` (questions générales) et `mail-api@yahooinc.com` (développeurs et API) |

### Sender Support Request : liste complète des champs

Le formulaire propose **New request** et **Status update** (choisissez l'un des deux ; obligatoire). Ces champs ont été relevés sur le formulaire en ligne (\* signale un champ obligatoire) :

| Champ | Remarques |
|---|---|
| Adresse email\* (saisie deux fois) | Là où Yahoo répond |
| Nom\*, fonction dans l'entreprise\* | |
| Nom de l'entreprise\*, adresse postale\*, numéro de téléphone\* | |
| URL de l'application ou du service\* | Son domaine **doit correspondre au domaine de l'URL de votre politique de confidentialité** |
| Informations d'envoi pour chaque serveur de messagerie actif\* | Adresse IP, enregistrement DNS inverse et domaine associé, avec **une entrée de serveur par ligne**. Pour les problèmes qui touchent plusieurs adresses IP, listez chaque adresse IP concernée, une par ligne |
| Utilisez-vous un ESP ?\* (oui ou non), et lequel\* | Les clients d'un ESP nomment leur fournisseur |
| Signez-vous avec DKIM ?\* (oui ou non) | |
| Type d'emails envoyés\* | Par exemple marketing, transactionnel, publications de forum, newsletters, personnel, autre |
| Processus d'abonnement\* | Par exemple opt-in confirmé ou double opt-in, simple opt-in, opt-out, co-inscription, marketing d'affiliation, autre |
| Nombre d'abonnés\* et emails envoyés par mois\* | |
| Case ISP | À cocher si vous êtes un fournisseur d'accès à Internet |
| URL de la politique de confidentialité\* et URL du formulaire d'abonnement\* | |
| Retirez-vous les adresses qui rebondissent ?\* (oui ou non) | |
| Délai de traitement des désabonnements\* | Le temps nécessaire pour retirer une adresse |
| Message d'erreur (facultatif) | Le texte exact de l'erreur que vous constatez |
| Informations complémentaires (facultatif) | À utiliser pour la chronologie et le compte rendu de vos corrections |

Le formulaire est protégé par hCaptcha. Une grande partie des questions porte sur les **pratiques de gestion de la liste** (méthode d'opt-in, traitement des rebonds, rapidité de traitement des désabonnements) : Yahoo évalue l'ensemble du programme de l'expéditeur, pas seulement le blocage.

### Attentes réalistes

- Yahoo ne publie **aucun engagement de niveau de service (SLA)** sur les réponses de l'assistance aux expéditeurs.
- Il n'existe **aucun programme formel de liste blanche**. Pour les lancements importants ou les notifications légales, c'est la même Sender Support Request qui sert de canal. Yahoo peut ajuster la réputation, mais ne garantit jamais la livraison en boîte de réception (voir [Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs)).
- Pour des adresses IP ou des domaines qui viennent d'être bloqués, soumettez la demande **en joignant l'erreur et les codes de diagnostic** (reports préfixés par TS ou PH, et codes 5xx ; voir [Codes d'erreur SMTP de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/codes-d-erreur-smtp-de-yahoo)).
- Le Sender Hub propose aussi un tableau de bord **Sender Hub Insights**, accessible après connexion, qui présente des statistiques de livraison agrégées pour votre domaine. Consultez-le, ainsi que les [flux de données de délivrabilité](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/flux-de-donnees-de-delivrabilite-de-yahoo), avant et après l'escalade.

## Apple (iCloud Mail)

Apple n'a **ni formulaire de déblocage en libre-service, ni liste blanche, ni FBL**. Le canal d'escalade est la boîte postmaster **icloudadmin@apple.com**, réservée aux administrateurs système. Ne la contactez qu'après avoir lu l'erreur SMTP (les rejets d'Apple comportent une URL qui les explique) et corrigé le problème au regard des exigences publiées.

Le message doit indiquer le nom de l'entreprise, le domaine email, les adresses IP concernées, les erreurs SMTP mot pour mot et une description qui précise quand le problème a commencé. La procédure complète et le tableau des exigences figurent dans [Apple iCloud Mail : exigences postmaster](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/apple-icloud-mail-exigences-postmaster). (Les pages en-US et en-CA d'Apple pour le document 102322 ont un contenu identique.)

## Microsoft (Outlook.com et Office 365)

Les canaux de Microsoft sont documentés séparément dans [Canaux d'escalade de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-de-microsoft) : l'examen SNDS, le parcours d'assistance aux expéditeurs et de levée des restrictions d'Outlook.com pour les blocages des séries RP et SC, et le portail d'Office 365 pour le retrait de liste des adresses IP. Voir aussi [Exigences de Microsoft envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs) et [Microsoft SNDS et JMRP](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp).

## Autres fournisseurs (repères rapides)

- **Comcast Xfinity** : un formulaire de retrait de blocage (limité à 5 demandes par jour) et une ligne téléphonique CSA. Voir [Comcast / Xfinity : postmaster](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/postmaster-comcast-xfinity).
- **GMX, WEB.DE et mail.com** : un formulaire pour signaler une inscription sur liste de blocage. Les retours de plaintes passent par la certification CSA, pas par une FBL directe. Voir [GMX / WEB.DE : exigences postmaster](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/gmx-web-de-exigences-postmaster).
- **Les opérateurs de listes de blocage** (Spamhaus et d'autres) ont des processus d'escalade entièrement distincts. Voir [Listes de blocage DNS et zones Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus).

## Discipline de fonctionnement

1. **Diagnostiquez et corrigez avant d'escalader.** Tout fournisseur répond à un expéditeur non conforme en le renvoyant à sa page d'exigences.
2. **Une seule soumission propre et complète** fonctionne mieux que des soumissions partielles répétées. Google demande explicitement 2 semaines entre deux soumissions.
3. **Escaladez à partir des données du fournisseur lui-même** (Postmaster Tools, SNDS, flux de Yahoo), pour que votre affirmation corresponde à ce que voit le fournisseur.
4. **Consignez chaque escalade** (canal, date, preuves soumises, résultat). Des blocages qui reviennent sans cesse chez un même fournisseur sont un problème de programme d'envoi, pas un problème de ticket. Pour rétablir le volume après une levée des restrictions, voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation).

# Codes d'erreur SMTP de Yahoo

> Les catégories d'erreurs et de reports de remise SMTP de Yahoo Mail (4XX temporaires, 5XX permanentes, reports TS*, blocages de contenu PH*) avec leurs causes et les actions recommandées.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/codes-d-erreur-smtp-de-yahoo

Quand Yahoo Mail reporte ou rejette vos messages, sa réponse SMTP vous indique s'il faut réessayer et ce qu'il faut corriger. Yahoo documente ces erreurs (Delivery Status Notifications, DSN) **par catégorie plutôt que sous la forme d'un tableau exhaustif code par code**.

Des jetons étendus comme `TS*` (reports temporaires) et `PH*` (blocages pour contenu ou phishing) apparaissent dans le texte de la DSN à côté du code numérique. Quand vous contactez Yahoo au sujet d'erreurs persistantes, joignez à votre Sender Support Request **l'erreur exacte et les codes de diagnostic relevés dans vos journaux**.

## Classes principales

| Classe | Codes | Signification | Réessayer ? |
|---|---|---|---|
| 4XX temporaires | 421, 451 | Un problème temporaire bloque la livraison | Oui, réessayer plus tard |
| 5XX permanentes | 550, 553, 554 | Un problème permanent, et le message est refusé | **Non.** Ne jamais réessayer, et retirer les adresses qui génèrent des rebonds 5xx |

### Causes des erreurs temporaires 4XX (421 et 451)

- Yahoo a observé des schémas de trafic inhabituels depuis l'adresse IP de votre serveur d'envoi.
- Le message présentait des caractéristiques de spam.
- Les messages de votre serveur génèrent des plaintes d'utilisateurs de Yahoo.
- Les serveurs de messagerie de Yahoo étaient occupés au moment de la connexion.
- Un autre comportement suspect a déclenché une **dépriorisation dynamique** de votre serveur.
- Votre serveur de noms était temporairement indisponible.
- Une erreur temporaire a empêché Yahoo de déterminer les résultats d'authentification de votre domaine.

Action : consultez les exigences et recommandations de Yahoo envers les expéditeurs (voir [Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs)) et réessayez plus tard. Si vous n'administrez pas le serveur de messagerie, contactez son administrateur.

### Causes des erreurs permanentes 5XX (553 et 554)

- L'adresse du destinataire est invalide.
- Le message a échoué à l'authentification au regard de la politique DMARC ou DKIM du domaine d'envoi.
- Yahoo n'accepte pas le contenu, pour des raisons de politique.
- Un autre comportement suspect a entraîné le rejet permanent de la connexion SMTP.
- **L'adresse IP est inscrite chez Spamhaus.** Vérifiez sur https://www.spamhaus.org.

Action : **ne réessayez pas**. Des erreurs 5xx récurrentes signalent un problème étendu, et les gestionnaires de listes devraient avoir une politique de retrait des adresses qui génèrent des rebonds 5xx.

## Catégories d'erreurs

| Catégorie | Codes typiques | Cause | Action recommandée |
|---|---|---|---|
| Non-conformité aux RFC | 4xx ou 5xx | En-têtes en double, en-têtes mal formatés, types MIME incorrects et autres violations des RFC 5321 et 5322 | Corriger la construction des messages pour qu'elle respecte les RFC |
| Domaine From impossible à résoudre (RFC 5321 ou 5322) | 451 (délai dépassé ou SERVFAIL) ou 554 (échec permanent) | Le domaine à droite du @ dans MAIL FROM ou dans l'en-tête From ne semble pas valide. Yahoo vérifie son existence par une **requête SOA** : les sous-domaines utilisés dans MAIL FROM ou dans l'en-tête From ont donc besoin d'**enregistrements SOA**, pas seulement d'enregistrements A ou MX (même génériques) | Vérifier que chaque sous-domaine utilisé dans From ou MAIL FROM se résout et est couvert par un enregistrement SOA |
| Plaintes excessives des utilisateurs | Report ou rejet | Messages qui génèrent trop de votes spam de la part des utilisateurs de Yahoo | Surveiller votre réputation (même les expéditeurs à bonne réputation reçoivent des votes spam). Si l'erreur persiste plus de 48 h, ou suit des changements de contenu ou de politique, examiner les messages sortants à la recherche de contenus ou de pratiques contestables. Sur des adresses IP partagées, le trafic d'autres domaines peut vous nuire : envisager des adresses IP dédiées. Vérifier que les destinataires ont donné un opt-in correct |
| Messages non sollicités excessifs | Report ou rejet | Volume très élevé depuis une seule adresse IP, typique du courrier de masse non sollicité. Souvent, **une nouvelle adresse IP dont le volume a augmenté trop vite** | Ne pas renvoyer avant d'avoir revu vos pratiques. Chauffer les adresses IP lentement (voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)). Confirmer que tous les destinataires ont demandé les messages. Si l'erreur persiste plus de 48 h, revoir le contenu et les pratiques |
| Destinataires inconnus excessifs | Rejet | Un serveur qui envoie à de nombreux destinataires invalides. Il peut s'agir d'un **relais ouvert ou d'un proxy ouvert**, et Yahoo n'accepte pas les messages qui en proviennent | Sécuriser vos serveurs, retirer des listes les adresses qui rebondissent et examiner les files d'attente sortantes à la recherche d'abus par des spammeurs |
| Échecs d'authentification | Rejet | Échec de la vérification SPF, DKIM ou DMARC. Yahoo rejette un message pour échec DKIM lorsque le domaine signataire publie une politique exigeant que tous ses messages soient signés avec DKIM, que le domaine figure dans la balise DKIM `d=` et que le message n'a pas pu être authentifié (signature absente ou invalide) | Tous les expéditeurs : SPF ou DKIM. Expéditeurs de gros volumes : SPF, DKIM et DMARC. Expéditeurs sur Microsoft 365 ou Google Workspace : configurer DKIM selon leurs guides. Listes de diffusion (listservs) : mettre l'adresse de la liste dans From: et l'expéditeur réel dans Reply-To:. Messages transférés : envisager ARC |
| Blocages de contenu | Erreurs **PH\*** | Contenu que Yahoo n'accepte pas : virus, phishing, rançongiciels, autres logiciels malveillants, ou liens vers l'un d'eux | Examiner les files d'attente sortantes à la recherche de contenus contestables, et sécuriser les serveurs contre les abus |
| Le destinataire n'existe pas | 554 (par exemple `554 delivery error: dd This user doesn't have a yahoo.com account (user@yahoo.com) [-5]`) | Le compte Yahoo n'existe pas | Ne jamais réessayer. Retirer l'adresse de votre liste, et confirmer l'adresse directement auprès du destinataire |
| Message temporairement reporté | Erreurs **TS\*** (421) | Plaintes nombreuses d'utilisateurs de Yahoo, contenu contestable ou ressemblant à du spam, **mauvaise réputation IP (de l'adresse IP ou de son sous-réseau /24)**, ou schémas de trafic inhabituels | Réessayer plus tard est acceptable. Revoir le contenu sortant. Les serveurs qui n'envoient pas en masse (serveurs personnels, d'entreprise, d'établissements d'enseignement ou de fournisseurs d'accès) devraient vérifier leurs files d'attente à la recherche d'abus par des spammeurs. Si l'erreur se prolonge, soumettre une Sender Support Request avec l'erreur et les codes de diagnostic |
| Ressources temporairement indisponibles | 4xx | Les serveurs de messagerie de Yahoo étaient occupés au moment de la connexion | En général passager. Réessayer après un court délai |
| Autres erreurs de politique | 550, 554 | Un **enregistrement Null MX (RFC 7505)**. Un en-tête trop long (From, Subject, To). Une Date hors plage. Une valeur d'en-tête impossible à décoder (From, Subject). Une adresse contenant des caractères inhabituels ou interdits (par exemple `,$%?{}<>`) | Corriger l'enregistrement, l'en-tête ou l'adresse en cause |

## Lire un rebond de Yahoo

Un avis d'échec de Yahoo (envoyé par « MAILER-DAEMON » ou « Mail Delivery Subsystem », avec un objet du type « Failed Delivery ») comporte deux parties : le motif du rebond, puis une copie du message d'origine. Voici un exemple de la ligne qui rapporte la réponse de l'hôte distant :

```
Remote host said: 554 delivery error: dd This user doesn't have a yahoo.com account (testing123@yahoo.com) [-5] - mta123.mail.mud.yahoo.com
```

La cause d'échec la plus courante est une adresse de destinataire invalide. Si le compte « n'existe pas », vérifiez l'orthographe. Si les rebonds continuent, le compte a peut-être été fermé ou déplacé.

## Voir aussi

- [Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs), les exigences dont la violation produit la plupart de ces erreurs
- [La feedback loop de plaintes de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/feedback-loop-de-plaintes-de-yahoo), pour prévenir les reports de remise dus aux plaintes
- [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip), pour éviter les erreurs « messages non sollicités excessifs » sur les nouvelles adresses IP

# Comcast / Xfinity : postmaster, codes d'erreur, limites de débit et déblocage

> La politique de Comcast (comcast.net / Xfinity) envers les expéditeurs : le tableau complet des codes d'erreur BL/RL/ES/DM, les limites de débit fondées sur SenderScore, les limites de connexions et de destinataires, le retrait des listes de blocage et la FBL.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/postmaster-comcast-xfinity

Si vos messages vers des adresses comcast.net ou Xfinity sont reportés ou rejetés, le code du rebond vous indique pourquoi et quoi faire ensuite. La documentation postmaster de Comcast est d'une précision inhabituelle. Elle nomme les listes de blocage que Comcast consulte, publie un tableau de limites de débit fondé sur SenderScore et propose un formulaire de déblocage en libre-service disponible 24/7.

Cette documentation se trouvait autrefois à l'adresse `postmaster.comcast.net`. Elle est désormais servie par le portail Xfinity Service Policy Assurance (SPA), à l'adresse `spa.xfinity.com/help/postmaster`. Comcast précise que toutes ses politiques et tous ses seuils peuvent changer.

> D'où viennent ces informations : le portail SPA est une application JavaScript. Les codes et les seuils ci-dessous ont donc été relevés sur les pages archivées de `postmaster.comcast.net` (instantanés de 2021 à 2022) que le portail a remplacées. Considérez les seuils chiffrés comme indicatifs, et vérifiez les valeurs actuelles sur le portail en ligne avant toute décision critique.

## Exigences d'acceptation de base (« éviter les blocages »)

| Règle | Détail |
|---|---|
| Conformité aux RFC | Tous les emails doivent respecter les RFC applicables |
| DNS inverse | Comcast vérifie le DNS inverse (rDNS) de l'adresse IP d'envoi. Il refuse les connexions sans enregistrement **PTR** valide, plus un enregistrement **MX ou A** |
| Adresses IP statiques uniquement | Les messages provenant d'un espace d'adresses IP dynamique ou résidentiel ne sont pas acceptés. Une adresse IP est classée dynamique si son rDNS « ne respecte pas les conventions de nommage statique standard » (*does not comply with standard static naming conventions*) |
| DNSBL | Comcast consulte des listes de blocage externes (historiquement Spamhaus Zen, Cloudmark CSI, Return Path (SenderScore) et Vade (documentée auparavant comme TrendMicro MAPS)). Une inscription sur l'une d'elles vous bloque |
| Hygiène de base de données | Un volume élevé de messages non livrables fait bloquer l'adresse IP. **Chaque 550 « Not our customer » doit être traité comme un désabonnement** par les expéditeurs d'envois en masse |
| Gestion des abus | Faites respecter les politiques d'utilisation acceptable (AUP) et traitez les comptes compromis. Les attaques par dictionnaire et par collecte d'annuaire entraînent rapidement le blocage des adresses IP |
| DMARC | Comcast valide DMARC sur les messages entrants et applique la politique du domaine d'envoi (voir DM000001 ci-dessous). Il envoie des rapports agrégés quotidiens depuis `dmarc-support@alerts.comcast.net` |

## Limites strictes

| Limite | Valeur |
|---|---|
| Connexions simultanées pour chaque adresse IP d'envoi | **25** |
| Emails dans chaque session SMTP | **1 000** |
| Destinataires pour chaque message | **100** |
| Taille maximale d'un message | **15 Mo** |
| Demandes de retrait de liste | Au maximum **5** pour chaque adresse IP par jour, et au maximum **20** adresses IP différentes par jour (formulaire de retrait) |

## Limitation de débit (codes RL)

Le trafic soumis à une limitation de débit reçoit un **échec temporaire 4xx**. La bonne réponse est de réessayer plus tard, et quand les limites de débit s'appliquent, Comcast conseille lui-même de **raccourcir votre intervalle entre les tentatives**. Les nouvelles adresses IP doivent être chauffées : les limites augmentent chaque jour à mesure que s'accumule un historique de volume propre (voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)).

| Code | Fondement |
|---|---|
| RL000001 | Réputation d'expéditeur selon **SenderScore**, plus l'authentification du serveur d'envoi, quel que soit le nombre de domaines qui envoient depuis ce serveur |
| RL000002 | Indicateurs de réputation d'expéditeur et de volume fournis par **Cloudmark** |
| RL000003 | L'historique du volume et de la qualité de ce volume ; indépendant du nombre de domaines ; s'applique à IPv4 et à IPv6 |

Débit horaire selon SenderScore (RL000001), tel que publié. Deux versions du tableau ont existé, et les deux sont indiquées :

| SenderScore | Destinataires par heure (tableau le plus récent) | Destinataires par heure (tableau antérieur) |
|---|---|---|
| N/A (pas de score) | 120 | 300 |
| 0 à 15 | 1 200 | 1 200 |
| 16 à 25 | 3 600 | 3 600 |
| 26 à 30 | 6 000 | 7 200 |
| 31 à 50 | 12 000 | 14 400 |
| 51 à 70 | 24 000 | 50 400 |
| 71 à 85 | 42 000 | 72 000 |
| 86 à 100 | 60 000 | 86 400 |

Ces débits supposent une authentification réussie.

## Codes d'erreur de listes de blocage (série BL)

Le code BL est un **masque de bits des listes externes sur lesquelles figure l'adresse IP**. Chaque position de bit correspond à une liste. En lisant BLxxxxxx de droite à gauche, les listes sont Spamhaus Zen, Cloudmark CSI, la liste de blocage SenderScore de Return Path et la Vade Threat List (documentée auparavant comme TrendMicro MAPS).

La correction est toujours la même : réglez le problème de spam sortant, puis demandez le retrait **auprès du service de liste lui-même**. Comcast reprend l'inscription ; il n'en est pas propriétaire.

| Code | Inscrit sur |
|---|---|
| BL000000 | Les propres filtres de Comcast : des schémas d'envoi « caractéristiques du spam » (*characteristic of spam*). Utilisez le formulaire de retrait de Comcast |
| BL000001 | Spamhaus Zen |
| BL000010 | Cloudmark Sender Intelligence (CSI) |
| BL000011 | CSI + Spamhaus Zen |
| BL000100 | Return Path Reputation Network Blocklist (SenderScore) |
| BL000101 | Return Path + Spamhaus Zen |
| BL000110 | Return Path + CSI |
| BL000111 | Return Path + CSI + Spamhaus Zen |
| BL001000 | Vade Threat List (VTL) |
| BL001001 | VTL + Spamhaus Zen |
| BL001010 | VTL + CSI |
| BL001011 | VTL + CSI + Spamhaus Zen |
| BL001100 | VTL + Return Path |
| BL001101 | VTL + Return Path + Spamhaus Zen |
| BL001110 | VTL + Return Path + CSI |
| BL001111 | VTL + Return Path + CSI + Spamhaus Zen |

## Codes d'erreur de politique (ES, DM)

| Code | Signification | Correction |
|---|---|---|
| ES000001 | Envoi depuis une adresse IP dynamique ou résidentielle **à l'intérieur du réseau de Comcast**. Les abonnés ne peuvent envoyer que via smtp.comcast.net | Ce blocage ne peut pas être levé. Utilisez le webmail de Comcast ou son service de soumission, ou contactez Commercial Services (`support_biz@cable.comcast.com`) pour exploiter un serveur |
| ES000010 | Envoi depuis un espace d'adresses IP que Comcast classe comme dynamique ou résidentiel (généralement parce que le rDNS n'a pas l'air statique) | Modifiez le rDNS selon une convention de nommage statique. Si votre fournisseur ne peut pas le faire, escaladez auprès de Customer Security Assurance |
| DM000001 | Le message a été rejeté parce que le **domaine d'envoi publie DMARC `p=reject`** et que le message a échoué à la fois à DKIM et à SPF pour ce domaine | Corrigez l'authentification et l'alignement (voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)) |

## Erreurs SMTP génériques

| Code ou texte | Signification |
|---|---|
| 421 Too many sessions opened | Plus de 25 connexions simultanées depuis l'adresse IP |
| 421 Reverse DNS failure : Try again later | La résolution rDNS a renvoyé SERVFAIL (le DNS faisant autorité est mal configuré ou hors service). Échec temporaire ; réessayez |
| 421 Try again later | Échec temporaire générique ; réessayez |
| 452 Too many emails sent on this session | Plus de 1 000 messages dans la session |
| 452 Too many recipients for message | Plus de 100 destinataires pour le message |
| 550 Not our customer | Le destinataire n'existe pas. Les expéditeurs d'envois en masse doivent le traiter comme un désabonnement |
| 550 …too many invalid recipients | Le message entier est refusé pour tous les destinataires. Nettoyez la liste et renvoyez-le |
| 550 Invalid sender domain | Le domaine d'envoi n'a pas d'enregistrement A ou MX valide |
| 550 Account not available | Le compte du destinataire est actuellement indisponible |
| 552 Message size exceeded | Plus de 15 Mo |
| 554 PTR lookup failure | La résolution du PTR a renvoyé NXDOMAIN : l'adresse IP qui se connecte n'a pas de DNS inverse |

## Procédure de retrait des listes de blocage

1. Trouvez le code dans le rebond. Chaque avis de non-livraison (NDN) renvoie vers la FAQ qui explique le blocage.
2. Pour les codes de listes externes (BL000001 et suivants), corrigez le problème, puis demandez le retrait auprès de l'opérateur de la liste (Spamhaus, CSI, SenderScore ou Vade). Comcast applique le retrait.
3. Pour les blocages internes à Comcast (BL000000), soumettez le **Blocked Provider Request Form** sur le portail postmaster. Les champs obligatoires sont votre nom, votre adresse email, vos numéros de téléphone de jour et de soir, le domaine de l'adresse IP bloquée, votre rôle (administrateur email, dirigeant, abonné ou abonné Comcast), les adresses IP bloquées et une description du problème. Vous pouvez aussi indiquer ce que vous avez fait pour le corriger (filtrage antispam mis en place, rDNS rendu statique et cohérent). Les limites sont de **5 soumissions par jour** et, selon une documentation tierce, de **20 adresses IP par jour** au maximum. Le formulaire est surveillé **24/7**, et les blocages simples sont généralement levés en bien moins d'une heure.
4. Escalade : **Customer Security Assurance, 888-565-4329**, cité sur les pages des codes ES, RL et DM lorsque le libre-service ne permet pas de résoudre le problème.

## Feedback loop (FBL)

- Inscrivez-vous sur **feedback.comcast.net**. L'inscription peut se fonder **sur les adresses IP ou sur DKIM** (l'option DKIM a été lancée en version bêta).
- Les rapports utilisent l'**Abuse Reporting Format (ARF)** et sont générés quand un utilisateur clique sur « This is Spam ». Ils incluent les en-têtes complets du message, mais l'adresse du plaignant est retirée et n'est jamais rétablie.
- Vous devez être la partie responsable du serveur d'envoi. Sur des serveurs partagés, c'est le propriétaire du serveur qui doit s'inscrire.
- Les critères d'acceptation historiques étaient les suivants : un SenderScore **≥ 60** est accepté ; **30 à 60** est accepté uniquement si l'adresse IP ne figure sur aucune DNSBL ; **< 30** est refusé. Un refus est accompagné d'une explication et des étapes pour corriger le problème, et vous pouvez refaire une demande à tout moment.
- Comcast se réserve le droit de cesser à tout moment d'envoyer des retours à toute partie.

## L'infrastructure sortante de Comcast (pour les serveurs de réception)

Les emails grand public partent des hôtes `resqmta-*.sys.comcast.net` et `resdmta-*.sys.comcast.net` (plages publiées 96.103.146.x, 96.102.19.x et 96.102.200.x) et des plages IPv6 2001:558:fd00::/…. Les envois en masse passent par une plateforme distincte (MDP) en 96.114.127.0/27 et 68.87.28.32/27, plus deux /120 IPv6. Consultez le portail en ligne pour la liste actuelle.

# Délivrabilité B2B et passerelles de messagerie d'entreprise

> Livrer vers des messageries d'entreprise protégées par des passerelles de messagerie sécurisées : en quoi le filtrage de Proofpoint, Mimecast et Barracuda diffère de celui des fournisseurs de messagerie grand public, leurs procédures de retrait de liste, leurs systèmes de réécriture des liens, et comment chauffer, diagnostiquer et mesurer les envois B2B.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/delivrabilite-vers-les-passerelles-b2b

Quand vous écrivez à des adresses professionnelles (`@company.com`), vos messages ne sont généralement pas filtrés par un fournisseur de messagerie grand public comme Gmail ou Yahoo. Ils passent d'abord par une **passerelle de messagerie sécurisée (SEG, *secure email gateway*)** que l'administrateur informatique de l'organisation destinataire choisit et configure : Proofpoint, Mimecast, Barracuda, Cisco IronPort ou Exchange Online Protection de Microsoft 365. Les passerelles obéissent à l'administrateur, pas au destinataire, et se comportent très différemment des fournisseurs grand public.

Vous trouverez ci-dessous le modèle des passerelles et les trois grandes passerelles tierces. Pour le filtrage dans les environnements M365, voir [Exigences de Microsoft envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs).

> Note sur les sources : les pages de Proofpoint Essentials sur le flux de messagerie et sur URL Defense exigent une connexion sur help.proofpoint.com. Leur contenu provient donc d'instantanés de la Wayback Machine (mai 2025 et mars 2025 respectivement). L'article d'assistance de Mimecast sur les définitions URL Protect est derrière une vérification Cloudflare, et son contenu provient d'un instantané Wayback de juillet 2025.

## En quoi le filtrage des passerelles diffère de celui des fournisseurs grand public

| Dimension | Fournisseurs grand public (Gmail, Yahoo, Outlook.com) | Passerelles d'entreprise (Proofpoint, Mimecast, Barracuda) |
|---|---|---|
| Qui fixe la politique | Le filtre global du fournisseur, complété par des modèles d'engagement propres à chaque utilisateur | L'administrateur informatique de l'organisation destinataire, pour chaque client |
| Signaux principaux | Engagement (ouvertures, réponses, suppressions), taux de plaintes, réputation du domaine et de l'adresse IP | Flux statiques de réputation des adresses IP et des domaines, règles de contenu, listes d'autorisation et de blocage définies par l'administrateur |
| Retour de l'engagement | Les ouvertures, les déplacements et les plaintes alimentent le filtre | Pratiquement aucun : le comportement des utilisateurs influence rarement le filtrage |
| Boucle de plaintes | Feedback loops (FBL, au format ARF) accessibles aux expéditeurs | Pas de FBL : les « plaintes » se traduisent par des blocages décidés par l'administrateur |
| Visibilité pour l'expéditeur | Outils postmaster (Google Postmaster Tools, SNDS) | Aucune : vous l'apprenez par les rebonds, par le silence ou par le destinataire |
| Mode d'échec | Dossier spam | Rejet SMTP, quarantaine silencieuse (listée dans un récapitulatif destiné à l'administrateur) ou mise en attente décidée par l'administrateur |
| Voie de rétablissement | Corriger le comportement, attendre que la réputation se rétablisse | Portails de retrait de liste, et demande d'ajout à la liste blanche auprès de l'administrateur du destinataire |
| Cohérence | Une politique par fournisseur | Chaque client est différent. La même passerelle peut accepter vos messages dans une entreprise et les rejeter dans la suivante |

Ce que cela implique pour un expéditeur :

- **La réputation fonctionne presque en tout ou rien.** Soit vous êtes sur une liste de blocage ou dans une catégorie de faible réputation, soit vous ne l'êtes pas. Aucune personnalisation propre à chaque utilisateur ne peut vous sauver en partie.
- **La quarantaine est invisible.** De nombreuses passerelles acceptent le message (250 OK), puis le retiennent dans une quarantaine que le destinataire ne voit que dans un récapitulatif quotidien. Vos journaux indiquent « livré », et le destinataire affirme ne l'avoir jamais reçu.
- **La décision d'un seul administrateur couvre des milliers de boîtes aux lettres.** Un blocage sur le domaine d'une grande entreprise retire tout le domaine d'un coup. De la même manière, une seule entrée en liste blanche règle le problème d'un coup.
- **Identifiez la passerelle à partir de l'enregistrement MX** avant de diagnostiquer : `*.pphosted.com` ou `*.ppe-hosted.com` désigne Proofpoint, `*.mimecast.com` désigne Mimecast, `*.barracudanetworks.com` ou une appliance Barracuda sur site désigne Barracuda, et `*.mail.protection.outlook.com` désigne Microsoft 365 (EOP).

## Proofpoint

### Ordre du flux de messagerie et du filtrage (Essentials)

Proofpoint Essentials traite les messages entrants dans cet ordre :

1. **Vérifications de réputation DNS et de l'adresse IP** : **PDR** (Proofpoint Dynamic Reputation) et **CSI** (Cloudmark Sender Intelligence).
2. **Vérifications de validité DNS** (contrôle DNS de l'expéditeur entrant).
3. **Attachment Defense** (si la licence le prévoit).
4. **Analyse antivirus**. Ni le client ni Proofpoint ne peuvent jamais libérer un message bloqué comme virus.
5. **Analyse anti-usurpation** : DMARC, DKIM et SPF.
6. **Filtres** : filtres personnalisés définis par l'administrateur, et listes d'expéditeurs autorisés et bloqués. Les exécutables (`.exe`, `.dll`, `.bat`, `.js` et autres) sont bloqués avant l'exécution des filtres personnalisés. Tout filtre qui déclenche **Quarantine** ou **Allow** saute l'étape antispam.
7. Moteur de contenu **antispam**.
8. **Analyse et réécriture URL Defense** (si la licence le prévoit). Les filtres personnalisés **ne contournent pas** cette étape : même un message exempté par un filtre d'autorisation voit ses liens réécrits.

En pratique, les rejets PDR et CSI au moment de la connexion ont lieu avant tout examen du contenu, et la correction porte donc sur la réputation de l'adresse IP. Les mises en quarantaine relèvent de la politique ou du contenu, et la correction porte donc sur le contenu ou sur une entrée en liste blanche ajoutée par l'administrateur. Une entrée « Allow » de l'administrateur contourne le score de spam, mais pas la réécriture des URL ni les contrôles antivirus.

### PDR et ipcheck.proofpoint.com

**PDR (Proofpoint Dynamic Reputation)** est un système de réputation des adresses IP fondé sur la classification du contenu par apprentissage automatique. Il cherche à identifier les adresses IP compromises et celles qui appartiennent à des botnets. Une fois identifiée, une adresse IP est **retardée (reportée) ou bloquée** d'un coup chez tous les destinataires que protège Proofpoint. Une vague soudaine de reports ou de rejets simultanés sur de nombreux domaines professionnels sans rapport entre eux est le symptôme classique d'une inscription PDR.

- **Vérifier et demander le retrait :** `https://ipcheck.proofpoint.com/` (qui redirige vers `proofpoint.com/us/ipcheck`). Saisissez l'adresse IP pour savoir si elle est sur liste de blocage ou retardée, et soumettez des informations ou une demande de retrait depuis le même outil.
- **Relance :** écrivez à `delist-request@proofpoint.com` si l'outil ne règle pas le problème. Le traitement des demandes peut prendre **72 heures**. Il n'existe **aucune assistance téléphonique** pour les retraits de liste.
- Les clients de Proofpoint bénéficient d'un traitement plus rapide via le portail d'assistance. Les autres ne peuvent utiliser que l'outil et l'adresse email.
- Si une organisation précise que protège Proofpoint vous bloque (une décision de politique, et non la réputation globale), Proofpoint ne donnera pas suite à votre demande. **C'est l'organisation destinataire qui doit ouvrir le ticket**, car seuls ses contacts d'assistance autorisés peuvent joindre le support de Proofpoint.

### URL Defense (réécriture des liens)

URL Defense réécrit chaque URL des messages livrés pour la faire passer par `urldefense.proofpoint.com` (ou `urldefense.com`), et analyse la destination au moment du clic. Le format réécrit (v2) ressemble à ceci :

```
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.google.com&d=DwMBaQ&c=...&r=...&m=...&s=...&e=
```

| Paramètre | Signification |
|---|---|
| `u` | l'URL d'origine, encodée (`:` devient `-3A`, `/` devient `_`) |
| `d` | indicateurs de débogage |
| `c` | identifiant du cluster PPS |
| `r` | le destinataire du message |
| `m` | un identifiant de message |
| `s` | signature numérique qui empêche la falsification |
| `e` | marqueur vide de fin d'URL |

Les comportements qui comptent pour les expéditeurs :

- **Interaction avec DKIM :** par défaut, URL Defense réécrit les URL des messages signés avec DKIM, ce qui **casse la signature DKIM** après la livraison. Cela compte lorsque le message est ensuite transféré (voir [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc)). Les administrateurs peuvent désactiver la réécriture des messages signés avec DKIM.
- **Des exemptions définies par l'administrateur** existent pour un domaine ou une adresse IP, pour une adresse d'expéditeur, pour les URL en texte brut et pour les adresses IP nues. C'est ce que vous demandez à l'administrateur d'un destinataire de configurer si la réécriture abîme vos liens.
- Si le texte d'un lien affiche une URL différente du véritable `href`, l'URL du texte visible est réécrite et devient le lien. C'est pourquoi une « jolie » URL affichée par-dessus un lien de suivi peut finir par pointer vers un endroit inattendu dans les messages protégés.
- Lorsqu'un lien est jugé malveillant, l'utilisateur voit une page de blocage et l'URL du navigateur change. Pour signaler un faux positif à Proofpoint, il vous faut le lien réécrit **d'origine** tiré de l'email, et non l'URL de la page de blocage.
- Proofpoint ne propose aucun décodeur public officiel des liens URL Defense pour Essentials. Des décodeurs tiers existent, car le paramètre `u=` se décode mécaniquement.
- Comme les liens sont analysés au moment du clic, l'infrastructure de Proofpoint visite vos liens. Voir [Pourquoi les indicateurs de clics mentent](#pourquoi-les-indicateurs-de-clics-mentent-scanners-de-sécurité) plus bas.

### Canaux d'assistance de Proofpoint (synthèse)

| Situation | Démarche |
|---|---|
| Adresse IP retardée ou bloquée globalement (PDR ou CSI) | ipcheck.proofpoint.com, puis relance à `delist-request@proofpoint.com` ; environ 72 h ; pas de téléphone |
| Bloqué par une organisation protégée précise | S'adresser à l'administrateur de cette organisation ; seuls ses contacts autorisés peuvent ouvrir des tickets chez Proofpoint |
| Inscriptions SORBS (liste historiquement exploitée par Proofpoint) | Uniquement via le site web de SORBS |

## Mimecast

### URL Protect (réécriture des liens)

Mimecast réécrit tous les liens des emails entrants et analyse la destination en temps réel au moment du clic (il vérifie le domaine et valide l'URL avant de laisser passer l'utilisateur). Les liens réécrits pointent vers un **domaine Mimecast régional** (par exemple `protect-eu.mimecast.com/s/...` ; l'hôte exact dépend de la grille ou de la région qui héberge le compte). Chaque **définition URL Protect** fixe la configuration, et une stratégie l'applique. Voici les principaux réglages auxquels un expéditeur peut se heurter :

- **Mode de réécriture :** *Relaxed* ne réécrit que les URL valides dotées d'un domaine de premier niveau. *Moderate* ajoute les adresses IP. *Aggressive* réécrit tout ce qui ressemble à une URL, et c'est le seul mode qui réécrit les URL contenant des caractères interdits.
- **L'analyse par catégorie d'URL** bloque les liens selon leur catégorie. Compromised, Phishing & Fraud, Malware et Botnets sont bloqués à tous les niveaux. **Spam Sites** et **Suspicious** sont bloqués en Moderate et en Aggressive. Private IPs, ainsi que le **modèle d'apprentissage automatique zero-day** supplémentaire, ne s'appliquent qu'en Aggressive. Un domaine de suivi ou de destination classé « Spam Sites » ou « Suspicious » est donc bloqué chez la plupart des clients.
- **Action sur une URL dangereuse :** Allow (journalisé), **Warn** (une page intermédiaire ; l'utilisateur peut continuer) ou **Block** (une page de blocage). Pour une URL contenue dans une pièce jointe, c'est la pièce jointe qui est supprimée. Browser Isolation (une session de navigation sécurisée à distance) peut remplacer l'accès direct pour les sites suspects.
- **Tous les clics sont journalisés**, et chaque clic est analysé à nouveau. C'est une autre source de trafic de robots dans les statistiques de l'expéditeur.
- Les liens sont réécrits **en HTTPS par défaut**. Les URL de la ligne d'objet peuvent être supprimées ou réécrites (un lien réécrit peut atteindre 200 caractères, ce qui modifie visiblement l'objet). Un message en texte brut peut être converti en HTML précisément pour que ses liens puissent être réécrits (« Create Missing HTML Body »).
- L'option **Ignore Signed Messages** évite la réécriture des messages signés numériquement, pour préserver les signatures.
- **Display URL Destination Domain** ajoute le vrai domaine de destination au lien réécrit, par exemple `protect-eu.mimecast.com/s/1dBvZWHZ?url.uk.m.mimecastprotect.com`.
- **Les contrôles de similarité avancés** signalent les liens qui ressemblent aux domaines internes ou surveillés du client. Des domaines d'envoi sosies peuvent déclencher ce contrôle même lorsqu'ils sont légitimes.
- L'analyse des URL dans les pièces jointes couvre les fichiers HTML, TXT et PDF, les archives, et les formats Office et OpenOffice jusqu'à **50 Mo** (les fichiers chiffrés de plus de **40 Mo** sont traités comme malveillants). Les codes QR contenus dans les images sont analysés, et un verdict malveillant sur un code QR peut entraîner le rejet (**Reject**) ou la mise en attente (**Hold**) du message entier (une défense contre le « quishing »).
- Les pages **User Awareness** peuvent soumettre un pourcentage des clics à une page intermédiaire avant de laisser passer l'utilisateur. Un clic peut donc être journalisé alors que la personne n'atteint jamais votre page.
- Mimecast ne réécrit jamais ses propres domaines `login*.mimecast.com`.

Retrait de liste : Mimecast bloque les expéditeurs à la fois par ses propres contrôles de réputation globale et par les stratégies de chaque client. Son texte de rejet SMTP indique la catégorie de motif (la réputation, ou une stratégie nommée). Vous savez ainsi s'il faut passer par les canaux de Mimecast destinés aux expéditeurs ou contacter l'administrateur du destinataire. Un rejet qui cite la stratégie d'un client précis nécessite l'administrateur de ce client, exactement comme chez Proofpoint. (L'article de Mimecast sur le dépannage des messages rejetés et reportés ne faisait pas partie des sources utilisées ici. Les indications code par code de cette page ne sont donc pas encore couvertes.)

## Barracuda

### Barracuda Reputation Block List (BRBL) et retrait

Barracuda exploite sa propre DNSBL publique (zone de requête `b.barracudacentral.org`). Les appliances Barracuda comme des tiers la consultent (voir [Listes de blocage DNS et zones Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus)). Pour demander un retrait, utilisez `https://www.barracudacentral.org/rbl/removal-request` :

- **Champs obligatoires :** l'adresse IP du serveur de messagerie, une adresse email de contact et un numéro de téléphone. **Facultatifs :** le nom ou l'adresse email du client Barracuda, et le motif du retrait.
- Les demandes accompagnées d'une justification valable sont généralement examinées et traitées **en moins de 12 heures**.
- Les demandes sans informations valables sont **ignorées**, et les soumissions en double ne sont pas prises en compte. Soumettez une seule fois, avec une vraie explication de la cause et de la correction.
- Le formulaire ne fait que recueillir les demandes. Barracuda ne publie ni ses critères d'inscription ni de procédure de recours.

### Fonctionnement des listes d'autorisation et de blocage (Email Security Gateway)

Les listes de l'administrateur se trouvent dans les pages BLOCK et ACCEPT de l'appliance. Elles couvrent **les adresses IP, les domaines et sous-domaines, et les adresses email d'expéditeurs ou de destinataires** :

- **Les messages en liste blanche échappent au score de spam, mais sont toujours analysés par l'antivirus.** Les contrôles d'adresse IP et de pièces jointes interdites s'appliquent toujours. L'ajout à la liste blanche n'est pas un contournement complet.
- Dans le journal des messages, **« Allowed »** signifie que le message a passé tous les filtres, et **« Allow Listed »** qu'il correspond à une entrée d'autorisation explicite. La distinction est utile quand l'administrateur d'un destinataire vous lit ses journaux.
- **La protection contre l'usurpation de l'expéditeur** rejette les messages externes qui utilisent le propre domaine du client dans l'en-tête From. Elle se règle globalement ou pour chaque domaine, et le réglage global **l'emporte sur les entrées de liste blanche propres à chaque utilisateur**. C'est une raison fréquente pour laquelle les messages rebondissent encore alors qu'« ils nous ont mis en liste blanche » : vous avez mis le propre domaine du destinataire dans l'en-tête From.
- **Les filtres d'expéditeur personnalisés** portent sur **Envelope From, Header From et Reply-To**. Les trois identités comptent, pas seulement l'adresse From visible.
- **La vérification SPF est désactivée par défaut** en raison de la charge DNS. Une fois activée, elle peut marquer ou bloquer les échecs, et la quarantaine est recommandée pour les résultats `none`. **Les adresses IP des services de transfert connus échappent aux contrôles SPF, de débit et de réputation IP.** **La vérification DKIM** consomme beaucoup de processeur et est désactivée par défaut. Barracuda prévient que les lignes HTML de plus de **990 caractères** peuvent casser la validation DKIM. L'application de **DMARC** est disponible via la Cloud Protection Layer.
- **La suppression des rebonds invalides** marque les messages sortants avec un jeton chiffré et rejette les rebonds qui ne le portent pas. C'est une des raisons pour lesquelles les notifications d'état de livraison (DSN) envoyées à des expéditeurs protégés par Barracuda rebondissent parfois.
- Les appliances Barracuda évaluent le contenu, et l'administrateur de chaque client fixe les seuils de score de spam. Un même message peut donc être marqué sur un site Barracuda et passer sans problème sur un autre.

Les rejets de Barracuda comportent généralement une URL sur `barracudanetworks.com/reputation` avec l'adresse IP inscrite. Cette URL mène directement au formulaire de retrait de la BRBL décrit plus haut.

## Recommandations pratiques pour les expéditeurs

### Chauffer vers des listes B2B

- La logique habituelle de la [chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip) s'applique, mais le retour d'information est différent. Les passerelles ne vous donnent ni tableau de bord postmaster ni FBL : **surveillez donc le texte des rebonds et les taux de reports de remise pour chaque domaine de réception**, et non l'engagement.
- Les passerelles s'appuient fortement sur **la réputation statique au moment de la connexion** (PDR, CSI, BRBL, Spamhaus). Une adresse IP toute neuve et sans historique déclenche des reports et des limitations de débit semblables à la liste grise ; une adresse IP au passé chargé déclenche un rejet pur et simple. Vérifiez l'adresse IP sur ipcheck.proofpoint.com, sur `b.barracudacentral.org` et sur les grandes listes de blocage publiques **avant** le premier envoi.
- Les listes B2B concentrent le risque : un seul domaine d'entreprise peut représenter 5 à 10 % de la liste. **Chauffez séparément pour chaque domaine de réception** et, quand un domaine renvoie une avalanche de reports 4xx, ralentissez pour ce seul domaine plutôt que de tout mettre en pause.
- Les listes d'entreprise se dégradent plus vite que les listes grand public (l'attrition due aux changements d'emploi est couramment estimée à 20 à 30 % par an). Les listes B2B périmées atteignent des taux élevés de destinataires inconnus, que les passerelles et leurs flux de réputation considèrent comme un fort signal de spam. Vérifiez soigneusement les adresses avant de chauffer.
- Chauffer en fonction de l'engagement (« envoyer d'abord aux ouvreurs récents ») n'aide guère ici, car les passerelles ne surveillent pas les ouvertures. Ce qui aide, c'est **une authentification propre, avec SPF, DKIM et DMARC tous réussis et alignés**, puisque les passerelles exécutent tôt dans leur chaîne des étapes explicites d'anti-usurpation. Un rDNS et un HELO valides aident aussi.

### Interpréter les rebonds des passerelles

| Symptôme | Signification probable | Action |
|---|---|---|
| 5xx à la connexion ou tôt dans la session SMTP, citant la réputation, une DNSBL ou une URL de réputation | Blocage pour réputation globale (PDR, CSI, BRBL ou Spamhaus) | Demander le retrait via le portail de l'éditeur ; corriger d'abord la cause profonde |
| Reports 4xx simultanés sur de nombreux domaines professionnels sans rapport entre eux | Retard dynamique dans le style de PDR, ou limitation de débit d'une nouvelle adresse IP | Ralentir, vérifier la santé de l'adresse IP, réessayer ; demander le retrait si cela persiste |
| 5xx citant « policy », « local policy », « prohibited by administrator » ou un nom de règle | Politique de l'administrateur du client | Seule l'organisation destinataire peut corriger ; demander à votre contact de réclamer un ajout à la liste blanche |
| 250 accepté, le destinataire ne le voit jamais | Quarantaine ou mise en attente, listée dans un récapitulatif | Le destinataire cherche dans la quarantaine ; l'administrateur libère le message et vous ajoute à la liste blanche |
| Rebond d'un message dont le From contient le propre domaine du destinataire | Protection contre l'usurpation de l'expéditeur | Ne jamais utiliser le domaine du destinataire dans le From ; utiliser votre propre domaine authentifié |
| Les DSN envoyées à votre adresse de rebond rebondissent elles-mêmes | Suppression des rebonds invalides (validation du jeton) | Normal ; vérifiez que votre traitement du Return-Path ne crée pas de boucle |

Recueillez toujours **le texte intégral de la réponse SMTP**. Les rejets des passerelles nomment généralement l'éditeur et la catégorie de motif, et donnent souvent l'URL exacte de correction.

### Pourquoi les indicateurs de clics mentent (scanners de sécurité)

Toutes les grandes passerelles réécrivent les liens et **les visitent depuis l'infrastructure de l'éditeur**. Elles le font au moment de la livraison (sandboxing ou pré-analyse), au moment du clic (URL Defense, URL Protect, Microsoft Safe Links), et parfois à plusieurs reprises. Chaque visite atteint votre redirection de suivi des clics et est enregistrée comme un « clic ». Les effets, et comment les détecter :

- **Les taux de clics B2B sont gonflés et ne sont pas fiables** comme signaux d'engagement. Un schéma du type « tous les liens cliqués moins de 1 seconde après la livraison » est le fait d'un scanner, pas d'une personne.
- Heuristiques pour filtrer les clics de robots dans les données d'événements : clics quelques secondes après la livraison ; **tous** les liens d'un message cliqués (y compris le lien de désabonnement et les liens du pied de page) ; clics depuis des plages d'adresses IP de centres de données ou depuis le numéro de système autonome (ASN) de l'éditeur de la passerelle ; requêtes HEAD ou user-agents qui ne sont pas des navigateurs ; plusieurs destinataires d'un même domaine qui « cliquent » de façon identique.
- **Ne considérez jamais un clic sur un lien de désabonnement ou de confirmation comme une intention** d'un destinataire B2B, car les scanners suivent aussi ces liens. Utilisez le comportement POST du [désabonnement en un clic via List-Unsubscribe](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic), et exigez une action de confirmation explicite avant toute modification destructrice qu'une requête GET déclencherait.
- Avec les pages intermédiaires Warn et User Awareness de Mimecast, la passerelle peut journaliser un vrai clic qui n'atteint jamais votre page. À l'inverse, l'infrastructure de Browser Isolation peut télécharger votre page à la place de l'appareil de l'utilisateur.
- C'est le pendant, côté entreprise, des ouvertures par proxy dues à Apple MPP. Pour le fonctionnement des pixels de suivi, le comportement des ouvertures par proxy de MPP et la conception de politiques de mise en sommeil sur des données faussées, voir [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure) dans `operations/`.
- La réécriture affecte aussi la délivrabilité des messages transférés. URL Defense casse DKIM sur les messages signés qu'il réécrit, si bien que tout filtre qui vérifie plus loin des messages d'entreprise transférés voit des signatures cassées.

### Demander aux destinataires un ajout à la liste blanche

Si une part significative de votre liste est B2B, publiez une demande d'ajout à la liste blanche sur laquelle l'équipe informatique du destinataire peut agir. Demandez-lui d'autoriser les éléments suivants, par ordre de préférence :

1. **Vos plages d'adresses IP d'envoi.** Une autorisation au niveau de la connexion l'emporte sur le filtrage du contenu et, chez Barracuda, une autorisation pour un service de transfert connu ou une adresse IP contourne aussi SPF et le contrôle du débit.
2. **Votre domaine d'enveloppe (Return-Path) et votre domaine DKIM**, pas seulement l'adresse From affichée. Les filtres d'expéditeur des passerelles vérifient séparément Envelope From, Header From et Reply-To.
3. **Une exemption de réécriture des liens** pour votre domaine de suivi (chez Proofpoint, « Exclude URLs that contain specified domains » ; chez Mimecast, des exceptions dans la définition), si la réécriture casse vos liens ou si vos statistiques comptent.

Cadrez les attentes de vos clients. Sur la plupart des passerelles, l'ajout à la liste blanche laisse actifs l'analyse antivirus, le blocage des pièces jointes et les contrôles d'adresse IP. Il ne vaut que pour un client, et doit donc être demandé auprès de chaque organisation destinataire importante. Enfin, il ne survit pas à un changement d'éditeur de passerelle chez le destinataire.

### Ce qui ne fonctionne PAS

- Agir sur l'engagement (« campagnes de reconquête pour améliorer la réputation »), car les passerelles ne mesurent pas l'engagement.
- Attendre la fin d'une inscription. Les inscriptions BRBL et PDR persistent jusqu'à ce que vous demandiez le retrait, ou jusqu'à ce que le comportement en cause ne soit plus observé. Utilisez les portails.
- Contacter l'éditeur de la passerelle au sujet d'un blocage imposé par la politique d'un client. Les éditeurs n'agissent que sur leurs propres inscriptions de réputation globale ; le client est maître de ses blocages.
- Changer d'adresse IP pour échapper à une inscription. Les inscriptions fondées sur le contenu (PDR classe selon le contenu ; Barracuda évalue le contenu) suivent le flux d'emails vers la nouvelle adresse IP, et les adresses IP neuves ramènent le problème de limitation de débit. Voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation) pour la procédure générale de retrait de liste.

# Erreurs SMTP de Gmail et dépannage

> Catalogue complet des codes de réponse SMTP de Gmail, avec leurs codes d'état étendus, leur signification et les corrections à apporter.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/depannage-gmail

Lorsque Gmail rejette vos messages, les reporte ou en limite le débit, la réponse SMTP vous dit pourquoi et ce qu'il faut corriger. Google publie la liste complète des codes de réponse que ses serveurs renvoient pour les messages entrants. Ils sont rassemblés ci-dessous avec leur signification et la correction à apporter.

Toute erreur générée par Gmail se termine par l'identifiant **`gsmtp`**. Les erreurs qui contiennent aussi **`gcdp`** ont été déclenchées par une règle personnalisée qu'un administrateur Google Workspace a configurée sur le domaine de réception, et non par le filtrage propre à Gmail.

Les messages d'erreur sont cités tels que les serveurs de Google les renvoient, en anglais.

Règles générales :

- Les codes **4xx** sont temporaires : réessayez plus tard. De nombreux codes 4.7.x sont une **limitation de débit** délibérée, qui devient un blocage permanent 5.7.x si vous ne corrigez pas le problème de fond.
- Les codes **5xx** sont définitifs pour ce message. Corrigez la cause avant de renvoyer.
- Les paires de codes 4.7.x et 5.7.x liées à la conformité (SPF, DKIM, DMARC, TLS, PTR, alignement) correspondent directement aux [exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs#codes-derreur-de-non-conformité).

## Échecs temporaires (4xx)

| Code | Message (abrégé) | Signification et correction |
|---|---|---|
| 450-4.2.1 | L'utilisateur "is receiving email too quickly" / "at a rate that prevents delivery" | Limitation de débit côté destinataire ; renvoyez plus tard |
| 450-4.2.1 | "Peak SMTP relay limit exceeded for this customer" | Limite du relais SMTP de Workspace ; contactez l'administrateur du compte |
| 452-4.2.2 | "The recipient's inbox is out of storage space" | Le destinataire doit libérer de l'espace de stockage Google |
| 421-4.3.0 | "Temporary System Problem. Try again later" | Problème côté Google ; réessayez |
| 451-4.3.0 | "Email server has temporarily rejected this message" | Réessayez plus tard |
| 451-4.3.0 | "Multiple destination domains per transaction is unsupported" | Envoyez à un seul domaine de destination par transaction SMTP (RFC 5321) |
| 451-4.4.2 | "Timeout - closing connection" | Délai réseau ou de session dépassé ; réessayez |
| 421-4.4.5 | "Server busy, try again later" | Réessayez avec un délai croissant (backoff) |
| 451-4.5.0 | "SMTP protocol violation" | Corrigez la façon dont le client gère le protocole, selon la RFC 5321 |
| 452-4.5.3 | "Domain policy size per transaction exceeded" | Réessayez ce destinataire dans une transaction distincte |
| 452-4.5.3 | "Your message has too many recipients" | Réduisez le nombre de destinataires par message |
| 421-4.7.0 | "Connection expired, try reconnecting" / "Try again later, closing connection" | Reconnectez-vous et réessayez |
| 421-4.7.0 | "IP not in whitelist for RCPT domain" | Le domaine de réception (Workspace) n'accepte que les adresses IP inscrites sur sa liste blanche |
| 421-4.7.0 | "The IP address sending this message does not have a PTR record" | Ajoutez un enregistrement PTR et un enregistrement DNS direct concordants |
| 421-4.7.0 | "TLS required for RCPT domain, closing connection" | Livrez par TLS |
| 421-4.7.0 | "This message is suspicious due to the very low reputation of the sending IP / sending domain" | Blocage pour réputation ; voir le rétablissement de la réputation ci-dessous |
| 421-4.7.0 | "This message is suspicious due to the nature of the content" | Contenu signalé ; revoyez le contenu du message |
| 454-4.7.0 | "Too many login attempts" / "Cannot authenticate due to a temporary system problem" | Limitation de débit de l'authentification client ; réessayez plus tard |
| 451-4.7.23 | "The sending IP address for this message doesn't have a PTR record" | Ajoutez un enregistrement PTR |
| 451-4.7.24 | "The SPF record of the sending domain has one or more suspicious entries" | Nettoyez l'enregistrement SPF (retirez les include compromis ou suspects) |
| 421-4.7.26 | "Rate limited because it is unauthenticated" | Mettez en place SPF ou DKIM |
| 451-4.7.26 | "Unauthenticated email from *domain* is not accepted due to domain's DMARC policy" | La politique DMARC du domaine From: lui-même rejette l'usage non authentifié ; authentifiez avec SPF ou DKIM alignés |
| 421-4.7.27 | "Rate limited because SPF authentication didn't pass" | Corrigez SPF |
| 421-4.7.28 | "Unusual rate of email" depuis votre adresse IP, votre bloc d'adresses IP, votre domaine DKIM, votre domaine SPF ou le domaine d'une URL du corps ; ou "sender exceeded the quota" | Limitation de débit liée à un profil de spam, appliquée à cet identifiant. Pour vous rétablir, attendez au moins 10 minutes, reprenez avec une seule connexion, puis ajoutez les connexions une par une |
| 421-4.7.29 | "Rate limited because you're not using a TLS connection" | Activez TLS |
| 421-4.7.30 | "Rate limited because DKIM authentication didn't pass" | Corrigez DKIM |
| 421-4.7.32 | "Rate limited because the From: header isn't aligned" avec le domaine SPF ou DKIM | Obtenez l'alignement DMARC ; voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) |
| 421-4.7.40 | "Rate limited because the sending domain doesn't have a DMARC record" | Publiez un enregistrement DMARC (au minimum `p=none`) |

## Échecs définitifs (5xx)

### Destinataire et adressage

| Code | Message (abrégé) | Signification et correction |
|---|---|---|
| 550-5.1.1 | "The email account that you tried to reach does not exist" | Rebond définitif : retirez l'adresse et vérifiez les fautes de frappe |
| 553-5.1.2 | "We weren't able to find the recipient domain" | Domaine erroné ; vérifiez l'orthographe et l'enregistrement MX |
| 553-5.1.3 | "The recipient address is not a valid RFC 5321 address" | Corrigez la syntaxe de l'adresse |
| 553-5.1.7 | "The sender address is not a valid RFC 5321 address" | Corrigez la syntaxe de l'expéditeur d'enveloppe |
| 550-5.2.1 | "The email account that you tried to reach is inactive" | Compte désactivé ; placez l'adresse en liste de suppression |
| 550-5.2.1 | L'utilisateur "is receiving email at a rate that prevents delivery" | Limitation de débit côté destinataire |
| 552-5.2.2 | "The recipient's inbox is out of storage space and inactive" | Placez l'adresse en liste de suppression, ou attendez |
| 550-5.4.5 | "Daily user sending limit exceeded" / "Daily SMTP relay limit exceeded for user" | Limites d'envoi de Gmail ou de Workspace atteintes |
| 554-5.4.6 | "Message exceeded 50 hops" | Probablement une boucle de messagerie ; examinez les chaînes de transfert |
| 550-5.5.3 | "Too many recipients for this sender" | Réduisez le nombre de destinataires |

### Limites de taille

| Code | Message (abrégé) | Signification et correction |
|---|---|---|
| 552-5.3.4 | Limites de taille du message dépassées | Le message entier est trop volumineux |
| 552-5.3.4 | "The number of attachments exceeds Google's limit" | Envoyez moins de pièces jointes |
| 552-5.3.4 | Limites de taille des en-têtes dépassées : ensemble des en-têtes, valeur d'un en-tête, nom d'un en-tête ou en-tête `Subject:` | Réduisez les en-têtes |

### Protocole et session

| Code | Message (abrégé) | Signification et correction |
|---|---|---|
| 502-5.5.1 | "Unimplemented command" / "Unrecognized command" / "Too many unrecognized commands, goodbye" | Corrigez le comportement du client SMTP |
| 503-5.5.1 | "Bad sequence of commands" / "EHLO/HELO first" / "RCPT first" / "No DATA after BDAT" (RFC 3030) | Un bogue dans l'ordre des commandes du client |
| 501-5.5.2 / 555-5.5.2 | "Syntax error" | Commande SMTP mal formée |
| 501-5.5.4 | "HELO/EHLO argument invalid" / "Empty HELO/EHLO argument not allowed" | Envoyez un nom de domaine pleinement qualifié (FQDN) valide dans HELO ou EHLO |
| 530-5.7.0 | "Must issue a STARTTLS command first" (RFC 3207) / "Authentication required" | Démarrez TLS, ou authentifiez-vous, avant d'envoyer |
| 523-5.7.10 | "No commands allowed to pipeline after STARTTLS" | Non-respect de la RFC 3207 |
| 501-5.7.11 | "Syntax error (no parameters allowed)" | Non-respect de la RFC 3207 |
| 554-5.7.0 | "Too many unauthenticated commands" | Session interrompue |
| 503-5.7.0 | "No identity changes permitted" | Ne changez pas d'identité authentifiée en cours de session |

### Contenu, format et politique

| Code | Message (abrégé) | Signification et correction |
|---|---|---|
| 554-5.6.0 | "Email message is malformed. Not accepted" | Mettez le message en conformité avec la RFC 5322 |
| 552-5.7.0 | "Content presents a potential security issue" | Pièce jointe ou type de fichier bloqué (voir la liste des types de fichiers bloqués par Gmail) |
| 550-5.7.1 | "The user or domain that you are sending to has a policy" interdisant ce message | Politique du domaine Workspace de réception (erreurs `gcdp`) ; contactez l'administrateur du destinataire |
| 550-5.7.1 | "This message is likely unsolicited email" / "likely suspicious due to the very low reputation" de l'adresse IP ou du domaine d'envoi | Blocage pour spam ou pour réputation ; voir le rétablissement ci-dessous |
| 550-5.7.1 | Non-respect de la RFC 5322 : en-tête `From:` absent ou invalide, plusieurs en-têtes `From:`, plusieurs adresses dans `From:`, aucun `Message-ID:` valide, en-têtes en double, en-tête mal formé, valeur `From:` non conforme, syntaxe encoded-word dans un en-tête, caractère Unicode dans un en-tête qui ne l'autorise pas | Corrigez la génération des messages selon la RFC 5322 |
| 550-5.7.1 | "This message does not meet IPv6 sending guidelines" | En IPv6, les enregistrements PTR et l'authentification sont obligatoires ; corrigez-les ou envoyez en IPv4 |
| 550-5.7.1 | "This email has been rate limited" | Limites d'envoi ou de réception |
| 550-5.7.1 | "The IP you're using to send email is not authorized" | Messages envoyés directement depuis une adresse IP dynamique ou résidentielle ; passez plutôt par le serveur SMTP de votre fournisseur |
| 550-5.7.1 | "Invalid credentials for relay" / "Daily SMTP relay sending limit exceeded for this customer" | Configuration ou limites du relais SMTP de Workspace |
| 550-5.7.0 | "Email relay denied" (identifiants invalides ou compte suspendu) | Enregistrez l'adresse IP d'envoi dans les paramètres du relais SMTP de Workspace, ou le compte de relais est suspendu pour spam |

### Blocages liés à l'authentification et aux exigences envers les expéditeurs

| Code | Message (abrégé) | Signification et correction |
|---|---|---|
| 550-5.7.24 | "SPF record of the sending domain has one or more suspicious entries" | Nettoyez l'enregistrement SPF |
| 550-5.7.25 | "The sending IP address doesn't have a PTR record" | Ajoutez un enregistrement PTR |
| 550-5.7.26 | "Blocked because the sender is unauthenticated" | Mettez en place SPF ou DKIM |
| 550-5.7.26 | "The (E)MAIL FROM domain has an SPF record with a hard fail policy" (`-all`), mais le message a échoué à SPF | Corrigez l'enregistrement SPF, ou envoyez depuis une adresse IP autorisée |
| 550-5.7.26 | "Unauthenticated email from *domain* is not accepted due to domain's DMARC policy" | La politique DMARC du domaine From: exige une authentification alignée |
| 550-5.7.27 | "Didn't pass SPF authentication" | Corrigez SPF |
| 550-5.7.28 | "Unusual rate of unsolicited email originating from your IP address" | Blocage pour volume de spam ; arrêtez, corrigez l'hygiène de base de données, puis procédez à une nouvelle chauffe |
| 550-5.7.29 | "Wasn't sent over a TLS connection" | Activez TLS |
| 550-5.7.30 | "Didn't pass DKIM authentication" | Corrigez DKIM |
| 5.7.32 | "Blocked because the From: header isn't aligned" avec SPF ou DKIM | Corrigez l'alignement DMARC |
| 550-5.7.40 | "The sending domain doesn't have a DMARC record" | Publiez DMARC |

### Erreurs d'authentification client (soumission, hors délivrabilité)

| Code | Message (abrégé) | Signification et correction |
|---|---|---|
| 535-5.7.80 | "Username and Password not accepted" | Identifiants erronés, ou connexion bloquée |
| 534-5.7.90 | "Application-specific password required" / "Please log in with your web browser" | Utilisez des mots de passe d'application ou OAuth |
| 534-5.7.14 | "Please log in through your web browser and then try again" | Vérification de sécurité du compte |
| 504-5.7.40 | "Unrecognized authentication type" / "XOAUTH is no longer supported" | Utilisez OAuth 2.0 (XOAUTH2) |

## Se rétablir après un blocage ou une limitation de débit

- **Les échecs temporaires 4.7.x sont une limitation de débit**, pas un verdict final. Google conseille d'« arrêter complètement l'envoi pendant une courte période, puis de reprendre à un rythme plus lent » (« completely stop sending for a short period of time, then resume sending at a slower rate »), ce qui revient en pratique à procéder à une nouvelle [chauffe](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip).
- **Erreurs de quota de débit (4.7.28)** : attendez au moins 10 minutes, reprenez avec une seule connexion, puis ajoutez les connexions une par une. Si une seule connexion échoue encore, attendez encore 10 minutes.
- **Blocages pour réputation** (« very low reputation of the sending IP/domain ») : consultez les tableaux de bord de réputation des adresses IP (IP Reputation) et de réputation des domaines (Domain Reputation) dans [Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools), supprimez la source du spam et laissez passer du temps. La réputation ne se rétablit que par un envoi soutenu qui respecte les règles.
- **Inscriptions sur des listes de blocage publiques (RBL)** : Gmail consulte aussi les listes de blocage publiques. Demandez le retrait directement à l'opérateur de la liste.
- **Blocages persistants sur un trafic conforme** : utilisez le formulaire d'escalade de Google pour les expéditeurs de gros volumes (*Bulk Sender Escalation Form*). Aucune levée des restrictions n'est possible tant que votre taux de spam dans Postmaster Tools dépasse 0,3 % (voir [exigences envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs#éligibilité-à-la-levée-des-restrictions)).

# Exigences de Gmail envers les expéditeurs

> Les exigences de Gmail envers les expéditeurs pour livrer des messages aux comptes Gmail personnels : authentification, seuils de taux de spam, désabonnement en un clic, règles pour les expéditeurs de gros volumes et calendrier d'application.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs

Si vous envoyez des messages à des **comptes Gmail personnels**, c'est-à-dire à des adresses se terminant par `@gmail.com` ou `@googlemail.com`, les consignes de Google pour les expéditeurs d'emails (*Email Sender Guidelines*) définissent ce que vous devez faire pour que ces messages soient acceptés et livrés. Ces exigences sont appliquées depuis le **1er février 2024** et se sont durcies au fil du temps (voir [Calendrier d'application](#calendrier-dapplication)).

Périmètre :

- Les consignes et leur application par Google concernent **uniquement les messages envoyés à des comptes Gmail personnels**. Les messages envoyés à des comptes Google Workspace ne sont pas couverts. En revanche, tous les expéditeurs, y compris les utilisateurs de Google Workspace, doivent respecter les consignes lorsqu'ils envoient des messages à des comptes Gmail personnels.
- Les expéditeurs Google Workspace qui envoient de gros volumes sont en outre soumis au règlement de Gmail sur le spam et les abus (Gmail Spam and abuse policy).

## Qui est considéré comme expéditeur de gros volumes

> « Un expéditeur de gros volumes est un expéditeur qui envoie près de 5 000 messages ou plus à des comptes Gmail personnels en 24 heures. »

Fonctionnement :

- **Le volume est décompté par domaine principal (organisationnel), sous-domaines compris.** Exemple donné par Google : 2 500 messages par jour depuis `solarmora.com` et 2 500 par jour depuis `promotions.solarmora.com` font un expéditeur de gros volumes, car les 5 000 messages proviennent tous du domaine principal `solarmora.com`.
- **Le statut d'expéditeur de gros volumes est permanent** : « Le statut d'expéditeur de gros volumes n'a pas de date d'expiration. » Descendre ensuite sous les 5 000 messages par jour ne retire pas ce statut.
- Notez la formulation « près de 5 000 ». Ne considérez pas 4 999 comme un chiffre sûr.

## Exigences pour tous les expéditeurs (quel que soit le volume)

| Domaine | Exigence |
|---|---|
| Authentification | Configurer **SPF ou DKIM** pour vos domaines d'envoi |
| DNS | Des enregistrements **DNS direct et inverse** (PTR) valides pour les adresses IP d'envoi. L'adresse IP d'envoi doit correspondre à l'adresse IP du nom d'hôte indiqué dans son enregistrement PTR, et la résolution directe (A ou AAAA) de ce nom d'hôte doit renvoyer la même adresse IP |
| Transport | Utiliser une **connexion TLS** pour transmettre les emails (aucune version de TLS n'est précisée) |
| Taux de spam | Maintenir le taux de spam signalé par les utilisateurs dans Postmaster Tools **sous 0,10 %**, et **ne jamais le laisser atteindre 0,30 % ou plus** |
| Format des messages | Respecter la **RFC 5322** (Internet Message Format) |
| En-tête From | Ne pas usurper l'identité de Gmail dans les en-têtes `From:`. Gmail applique une politique DMARC contraignante **quarantine** sur `gmail.com`, donc l'usurper nuira à la livraison. Utiliser une seule adresse email dans le champ `From:` |
| Message-ID | Chaque message doit comporter un en-tête `Message-ID:` valide |
| En-têtes | Les en-têtes qui ne peuvent figurer qu'une fois (`From`, `To`, `Subject`, `Date`) doivent apparaître exactement une fois. Aucun en-tête en double ou mal formé |
| Contenu | Aucun contenu masqué au moyen de HTML ou de CSS. Les liens web doivent être visibles et compréhensibles. Le HTML doit respecter les normes. Ne pas mélanger différents types de contenu (par exemple un reçu et des promotions) dans un même message |
| Transfert | Si vous transférez régulièrement des messages ou exploitez un service de transfert (listes de diffusion, passerelles), suivez les *Best practices for forwarding email to Gmail* de Google. Ajoutez des **en-têtes ARC** pour que Gmail puisse voir les résultats d'authentification d'origine, et préservez l'authentification d'origine autant que possible |

## Exigences supplémentaires pour les expéditeurs de gros volumes (environ 5 000 par jour ou plus)

Tout ce qui précède, **plus** :

| Domaine | Exigence |
|---|---|
| Authentification | **SPF et DKIM à la fois**, et non l'un ou l'autre |
| DMARC | Publier un **enregistrement DMARC** pour le domaine `From:`. Une politique minimale `p=none` est acceptable |
| Alignement | Pour les messages envoyés directement, le domaine de l'en-tête `From:` doit être **aligné** avec le domaine SPF ou le domaine DKIM (l'alignement souple sur le domaine organisationnel suffit) |
| Clé DKIM | Une clé de **1 024 bits** au minimum. **2 048 bits** sont recommandés |
| Désabonnement en un clic | Les messages marketing et ceux auxquels le destinataire s'est abonné (promotionnels ou commerciaux) doivent prendre en charge le **désabonnement en un clic selon la RFC 8058**, avec les deux en-têtes :<br>`List-Unsubscribe: <https://example.com/unsubscribe/…>`<br>`List-Unsubscribe-Post: List-Unsubscribe=One-Click` |
| Désabonnement visible | Un lien de désabonnement clairement visible dans le corps du message également |
| Respect des désabonnements | Traiter les demandes de désabonnement sous **48 heures** |

Précisions sur le désabonnement en un clic, d'après la FAQ de Google :

- Il n'est obligatoire que pour les messages **marketing et promotionnels**. Les messages transactionnels en sont exclus.
- Un en-tête `List-Unsubscribe` en `mailto:` seul ne satisfait **pas** l'exigence, car la RFC 8058 impose le mécanisme HTTPS POST.
- Les autres liens de désabonnement dans le corps du message n'ont pas besoin d'être en un clic.
- Le désabonnement en un clic peut ne retirer le destinataire que de cette liste de diffusion précise, et pas nécessairement de tous les messages de l'expéditeur.

## Calendrier d'application

| Date | Changement |
|---|---|
| **1er février 2024** | Les exigences entrent en vigueur pour les expéditeurs qui écrivent à des comptes Gmail personnels. Les expéditeurs de gros volumes (5 000 par jour ou plus) doivent s'authentifier avec SPF, DKIM et DMARC, éviter les messages non désirés et faciliter le désabonnement. L'application a débuté de façon « graduelle et progressive » : d'abord des erreurs temporaires sur une partie du trafic non conforme, puis des taux de rejet croissants |
| **1er juin 2024** | Date limite pour les expéditeurs qui incluent déjà un lien de désabonnement : ils doivent ajouter le **désabonnement en un clic** à tous leurs messages commerciaux et promotionnels |
| **Juin 2024** | Les expéditeurs de gros volumes dont le taux de spam signalé par les utilisateurs dépasse **0,3 %** deviennent **inéligibles à la levée des restrictions** (escalades auprès du support de livraison) |
| **Novembre 2025** | Gmail « intensifie l'application des règles au trafic non conforme ». Les messages non conformes subissent des perturbations, notamment des **rejets temporaires et permanents** |

### Éligibilité à la levée des restrictions

Le formulaire d'escalade de Google pour les expéditeurs de gros volumes n'aide que les expéditeurs déjà conformes :

- Un expéditeur est inéligible tant que son taux de spam signalé par les utilisateurs dépasse **0,3 %**.
- L'éligibilité revient lorsque le taux de spam reste **sous 0,3 % pendant 7 jours consécutifs**.
- Une authentification complète (SPF, DKIM, DMARC) et un désabonnement en un clic fonctionnel sont des conditions préalables.
- Le taux de spam et les autres données de Postmaster Tools sont calculés et mis à jour **chaque jour**.

## Codes d'erreur de non-conformité

Gmail signale le non-respect des consignes par des erreurs temporaires 4.7.x (limitation de débit), qui deviennent des rejets permanents 5.7.x. Toutes les erreurs SMTP de Gmail portent l'identifiant `gsmtp` (et `gcdp` lorsqu'une règle personnalisée d'un administrateur Workspace les a provoquées).

| Exigence non respectée | Temporaire (débit limité) | Permanente (bloquée) |
|---|---|---|
| PTR ou DNS inverse | 451-4.7.23 (ainsi que 421-4.7.0 « no PTR record ») | 550-5.7.25 |
| SPF ou DKIM (non authentifié) | 421-4.7.26 | 550-5.7.26 |
| Échec SPF | 421-4.7.27 | 550-5.7.27 |
| Échec DKIM | 421-4.7.30 | 550-5.7.30 |
| Absence d'enregistrement DMARC | 421-4.7.40 | 550-5.7.40 |
| From: non aligné avec SPF ou DKIM | 421-4.7.32 | 5.7.32 |
| Absence de TLS | 421-4.7.29 | 550-5.7.29 |
| Volume inhabituel ou non sollicité | 421-4.7.28 | 550-5.7.28 |
| Entrées suspectes dans l'enregistrement SPF | 451-4.7.24 | 550-5.7.24 |
| Consignes d'envoi IPv6 (PTR ou authentification) | Aucun | 550-5.7.1 « does not meet IPv6 sending guidelines » |

La liste complète des erreurs, y compris les erreurs de format et de réputation, figure dans [Erreurs SMTP de Gmail et dépannage](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/depannage-gmail).

Pour vous rétablir après une limitation de débit (erreurs de quota SMTP 4.7.28) : attendez au moins **10 minutes**, puis reprenez avec une **seule connexion**. Si elle réussit, ajoutez les connexions **une par une**. Si la connexion unique échoue encore, attendez encore 10 minutes.

## Recommandations sur les pratiques d'envoi (non obligatoires, mais prises en compte)

- Envoyez depuis des **adresses IP stables**. Utilisez des adresses IP différentes pour différents types de messages (par exemple les notifications et les promotions), et des adresses `From:` stables pour chaque catégorie. Voir [Segmentation avancée des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip).
- Augmentez le volume **progressivement**, à un rythme régulier, et évitez les pics. Voir [Chauffe d'IP (warm-up)](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip).
- Sur des **adresses IP partagées**, l'activité de chaque expéditeur influe sur la réputation commune. Surveillez la présence de l'adresse IP dans les listes de blocage et dans Postmaster Tools.
- N'achetez pas de listes d'adresses email, n'envoyez pas de messages non sollicités et n'utilisez pas de formulaires d'opt-in avec des cases précochées (la législation locale peut les interdire).
- Surveillez vos **affiliés** et écartez ceux qui envoient du spam : « Si votre marque est associée à du spam marketing, d'autres messages que vous envoyez risquent d'être marqués comme spam. »

### Règles relatives au nom d'affichage

Le nom d'affichage d'un expéditeur doit identifier uniquement cet expéditeur, et refléter une identité cohérente, claire et exacte. Il ne doit contenir ni texte de ligne d'objet ni contenu du message (« DEMANDE URGENTE », « LE TEMPS PRESSE »), ni emoji trompeur, ni le nom du destinataire lui-même, ni rien qui imite une conversation suivie (une tromperie du type « Re: »).

## Vérification de la conformité

Utilisez [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools), en particulier le **tableau de bord de l'état de conformité** (Compliance status), pour vérifier chaque exigence, et le tableau de bord du taux de spam pour suivre les seuils de 0,10 % et 0,30 %. Après une correction, les changements d'état de conformité peuvent mettre jusqu'à 7 jours à apparaître.

## Voir aussi

- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc), sur SPF, DKIM, DMARC et l'alignement
- [Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs)
- [Exigences de Microsoft envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs)
- [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools)

# Exigences de Microsoft envers les expéditeurs

> Les politiques postmaster d'Outlook.com, l'obligation SPF+DKIM+DMARC imposée en mai 2025 aux expéditeurs de gros volumes (plus de 5 000 messages par jour ; courrier indésirable ou rejet 550 5.7.515, selon la source Microsoft), les limites de connexion et la référence des codes d'erreur SMTP.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs

Les consignes postmaster de Microsoft pour les expéditeurs qui écrivent aux boîtes aux lettres grand public Outlook.com (outlook.com, hotmail.com, live.com, msn.com). Elles comprennent l'obligation d'authentification imposée aux expéditeurs de gros volumes, annoncée en avril 2025 et appliquée depuis le **5 mai 2025**, ainsi que les exigences techniques et de politique permanentes qui s'appliquent à tous les expéditeurs.

Des obligations comparables existent chez Yahoo (voir [Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs)) et chez Gmail ; les sources de Microsoft elles-mêmes se contredisent sur le sort des messages non conformes des expéditeurs de gros volumes : classement en courrier indésirable, ou **rejet dès la transaction SMTP** avec `550 5.7.515`. Voir [Application et calendrier](#application-et-calendrier).

## Exigences pour les expéditeurs de gros volumes (en vigueur depuis le 5 mai 2025)

S'appliquent aux **domaines qui envoient plus de 5 000 emails par jour** vers Outlook.com. L'application se fait au niveau du **domaine d'envoi**.

| Mécanisme | Exigence |
|---|---|
| SPF | **Doit réussir** pour le domaine d'envoi. L'enregistrement DNS du domaine doit indiquer exactement les adresses IP et les hôtes autorisés à envoyer. |
| DKIM | **Doit réussir**, pour valider l'intégrité et l'authenticité des emails. |
| DMARC | Publier **au minimum `p=none`**, et le message doit être **aligné avec SPF ou avec DKIM (de préférence les deux)**. |

### Application et calendrier

- **Avril 2025 (annonce)** : les expéditeurs sont invités à vérifier et mettre à jour leurs enregistrements SPF, DKIM et DMARC avant l'entrée en application.
- **Annonce sur Tech Community (publiée le 2 avril 2025, mise à jour le 30 avril 2025)** : le texte initial indiquait qu'après le 5 mai 2025, les messages non conformes des expéditeurs de gros volumes seraient **acheminés vers le courrier indésirable**, le rejet devant intervenir « à l'avenir (date à annoncer) » (*in the future (date to be announced)*). La mise à jour du 29 avril a barré ce paragraphe et l'a remplacé par : « nous avons décidé de **rejeter** les messages qui ne satisfont pas aux exigences d'authentification requises […] Ce changement prendra effet le 5 mai, comme annoncé initialement » (*we have made a decision to **reject** messages that don't pass the required authentication requirements … This change will state taking effect on May 5th as originally stated*). La section « What's Changing? » du même billet, elle, n'a pas été barrée et indique toujours : « Les messages non conformes seront d'abord acheminés vers le courrier indésirable. Si les problèmes ne sont pas résolus, ils pourront finir par être rejetés » (*Non‐compliant messages will first be routed to Junk. If issues remain unresolved, they may eventually be rejected*). Le billet se contredit donc lui-même.
- **Page Policies du postmaster d'Outlook.com (aucune date de publication ni de mise à jour indiquée ; consultée le 11 septembre 2026)** : « Les messages des expéditeurs de gros volumes qui ne satisfont pas à ces exigences seront envoyés dans le courrier indésirable. Si les problèmes ne sont pas résolus, les messages pourront être rejetés » (*Messages from high-volume senders that do not meet these requirements will be sent to the junk folder. If issues remain unresolved, messages may be rejected*), avec l'erreur `550; 5.7.515` ci-dessous, « en vigueur depuis le 5 mai 2025 » (*Effective May 5th, 2025*).
- **Les deux sources se contredisent.** La mise à jour de Tech Community annonce un rejet à partir du 5 mai 2025 ; la page postmaster annonce d'abord le courrier indésirable, puis un rejet éventuel plus tard. Comme la page postmaster n'est pas datée, les pages seules ne permettent pas d'établir laquelle est la plus récente. Prévoyez les deux issues : un message non conforme peut arriver dans le courrier indésirable ou être rejeté.
- Texte du rejet (donné par les deux sources, pour les messages rejetés) : `550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.`
- Outlook « se réserve en outre le droit de prendre des **mesures défavorables**, notamment de filtrer ou de bloquer, à l'encontre des expéditeurs non conformes, en particulier en cas de manquement grave en matière d'authentification ou d'hygiène » (*reserves the right to take negative action, including filtering or blocking — against non-compliant senders, especially for critical breaches of authentication or hygiene*).
- Dans un premier temps, l'application ne vise pas les expéditeurs de moins de 5 000 messages par jour. Microsoft souligne toutefois que tous les expéditeurs ont intérêt à adopter les mêmes pratiques, et n'exclut pas d'étendre l'application aux petits expéditeurs.

### Recommandations d'hygiène pour les expéditeurs de gros volumes

Publiées en même temps que l'obligation, au titre de meilleures pratiques (non appliquées au niveau SMTP, mais susceptibles de justifier des mesures défavorables) :

| Pratique | Détail |
|---|---|
| Adresses d'expéditeur P2 (principales) conformes | **L'adresse From ou Reply-To doit être valide, refléter le véritable domaine d'envoi et pouvoir recevoir des réponses** |
| Liens de désabonnement fonctionnels | Un opt-out simple et bien visible, en particulier pour le courrier marketing ou de masse ; il doit être « facile à trouver et fiable quand on clique dessus » (*easy to find and reliable when clicked*) |
| Hygiène de base de données et gestion des rebonds | Retirer régulièrement les adresses invalides pour réduire les plaintes pour spam, les rebonds et les messages envoyés en pure perte |
| Pratiques d'envoi transparentes | Des lignes d'objet exactes, aucun en-tête trompeur, et des destinataires qui ont donné leur consentement |

Pour vérifier la conformité, examinez l'en-tête `Authentication-Results` d'un message reçu dans une boîte Outlook.com (Microsoft documente la lecture des en-têtes sur learn.microsoft.com, page « message-headers-eop-mdo »).

## Politiques permanentes pour tous les expéditeurs

D'après la page des politiques du postmaster d'Outlook.com :

- Respecter le Contrat de services Microsoft (Microsoft Services Agreement) et sa politique antispam (Anti-Spam Policy), ainsi que la loi **CAN-SPAM** et la législation du pays de l'expéditeur ; les demandes de désabonnement doivent être honorées conformément aux recommandations de la FTC.
- Le mécanisme de désabonnement doit être « clairement documenté, et facile à trouver et à utiliser pour les destinataires » (*clearly documented and easy for recipients to find and use*).
- Le respect des **RFC 2821 / RFC 2822** (SMTP / format des messages) est obligatoire.
- Des enregistrements **DNS inverse (PTR) valides** sont exigés pour les adresses IP d'envoi.
- Les messages provenant d'**espaces d'adresses IP dynamiques** ne sont pas acceptés.
- Aucun relais non sécurisé ni proxy ouvert.
- **Aucune exploration de l'espace d'adresses** (*namespace mining*, c'est-à-dire sonder des adresses pour en trouver de valides sans envoyer de message).

### Limites de connexion et de nouvelles tentatives

| Règle | Valeur |
|---|---|
| Connexions simultanées | **500** au maximum sans accord préalable |
| Échecs de livraison répétés | Cesser d'envoyer à une adresse après plusieurs réponses de non-livraison |
| Erreurs permanentes | **Ne pas retransmettre** un message après une réponse SMTP **500–599**, quelle qu'elle soit |

## Codes d'erreur SMTP

Les codes de report de remise et de rejet documentés par Outlook.com. Les codes `421` sont temporaires (limitation de débit fondée sur la réputation) ; les codes `550` sont permanents.

| Code | Signification | Correction |
|---|---|---|
| `421 RP-001` | L'IP d'envoi a dépassé la limite de débit autorisée (réputation de l'IP ou du domaine) | Améliorer la réputation ; ralentir ; escalader auprès du support aux expéditeurs |
| `421 RP-002` | Limite de débit dépassée sur cette connexion (réputation) | Comme pour RP-001 |
| `421 RP-003` | Limite de connexions dépassée (réputation) | Réduire le nombre de connexions simultanées (≤ 500) ; améliorer la réputation |
| `550 5.7.515` | Le domaine d'envoi (plus de 5 000 messages par jour) n'atteint pas le niveau d'authentification requis | Réussir SPF et DKIM ; publier DMARC (`p=none` au minimum) avec alignement |
| `550 SC-001` | Rejet pour raisons de politique : contenu d'aspect spam ou mauvaise réputation | Revoir le contenu et la réputation ; demander la levée des restrictions |
| `550 SC-002` | Comportement d'exploration de l'espace d'adresses détecté | Vérifier que les machines ne sont pas compromises ; cesser la collecte d'adresses |
| `550 SC-003` | L'IP semble être un proxy ou un relais ouvert | Fermer le relais ; corriger avant de demander un retrait de liste |
| `550 SC-004` | IP bloquée à cause de plaintes d'utilisateurs | S'inscrire à JMRP ; retirer les plaignants ; demander la levée des restrictions |
| `550 DY-001` | Les messages provenant d'IP dynamiques ne sont pas acceptés | Envoyer depuis un espace d'adresses IP statiques (la PBL de Spamhaus recense les plages dynamiques) |
| `550 DY-002` | Le schéma d'envoi évoque un hôte compromis ou infecté par un virus | Nettoyer l'hôte ; contacter le fournisseur d'accès |
| `550 OU-001` | Rejet générique par la politique du serveur de réception (inscription sur une liste tierce) | Vérifier l'inscription et demander le retrait auprès de Spamhaus |
| `550 OU-002` | Rejet pour caractéristiques de spam ou pour réputation | Revoir le contenu, l'authentification et la réputation |

Microsoft documente aussi les corrections suivantes : vérifiez le DNS inverse ; lorsque l'usage d'un domaine change, comptez **48 heures** de propagation après la mise à jour de ses enregistrements DNS d'authentification ; inscrivez-vous à JMRP pour voir ce que les destinataires marquent comme courrier indésirable.

## Outils de réputation et de surveillance

Microsoft propose deux programmes gratuits : **SNDS** (données de réputation par IP : taux de plaintes, verdicts du filtre anti-spam) et **JMRP** (une feedback loop qui renvoie le message complet lorsqu'un destinataire le marque comme courrier indésirable ou comme phishing). Les deux sont présentés dans [Microsoft SNDS et JMRP](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp). Les abus peuvent être signalés à Microsoft à l'adresse `report_spam@outlook.com`, au format RFC 2822 ou ARF.

## Voir aussi

- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) : alignement, syntaxe de l'enregistrement, passage à une politique contraignante
- [Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs) : l'obligation équivalente imposée par Yahoo en 2024
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email) : pourquoi les signaux de plaintes et d'engagement pilotent le filtrage

# Exigences de Yahoo envers les expéditeurs

> Les exigences de Yahoo Mail envers tous les expéditeurs et envers les expéditeurs de gros volumes (authentification, désabonnement en un clic, seuil de 0,3 % de taux de plaintes), ainsi que ses recommandations sur l'hygiène de base de données, l'infrastructure et la réputation.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs

Si vous envoyez à des adresses Yahoo Mail, vos messages doivent respecter les exigences que Yahoo a publiées envers les expéditeurs pour atteindre la boîte de réception. Yahoo a commencé à les appliquer en **février 2024**, avec un déploiement progressif, et a commencé à appliquer la politique relative à List-Unsubscribe en **juin 2024**.

Ces exigences s'appliquent à **tous les domaines et à toutes les marques grand public hébergés par Yahoo Mail**, y compris AOL et les autres domaines que Yahoo héberge. **Yahoo Japan est exploité de façon indépendante** et n'est pas concerné.

Les messages qui ne respectent pas ces exigences peuvent être livrés dans le dossier spam, ou purement et simplement rejetés avec un code d'erreur (voir [Codes d'erreur SMTP de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/codes-d-erreur-smtp-de-yahoo)).

## Exigences pour tous les expéditeurs

| Exigence | Détail |
|---|---|
| Authentification | Mettre en place **au minimum SPF ou DKIM** |
| Taux de plaintes | Maintenir le taux de plaintes pour spam **sous 0,3 %** |
| DNS | Des enregistrements **DNS direct et inverse (PTR)** valides pour les adresses IP d'envoi |
| Normes | Respecter la **RFC 5321** et la **RFC 5322** |

## Exigences supplémentaires pour les expéditeurs de gros volumes

Yahoo ne publie aucun seuil de volume qui définirait un « expéditeur de gros volumes » : il s'agit d'un expéditeur qui envoie un volume de messages important. Pour l'application des règles, un « expéditeur » est évalué au niveau du **domaine authentifié ou du domaine de l'en-tête From**, et Yahoo se sert de toutes les informations disponibles (contenu, IP, etc.) pour vérifier la conformité.

| Exigence | Détail |
|---|---|
| SPF **et** DKIM | Les deux doivent être en place, pas seulement l'un des deux |
| DMARC | Publier une politique DMARC valide d'**au minimum `p=none`**, et **DMARC doit réussir**. Une balise `rua` pour les rapports agrégés est recommandée. **L'alignement souple est accepté** : le domaine de l'en-tête From doit être aligné avec le domaine SPF ou avec le domaine DKIM. |
| En-tête List-Unsubscribe | Un **en-tête List-Unsubscribe fonctionnel, qui prend en charge le désabonnement en un clic**, sur les messages marketing et sur ceux auxquels le destinataire s'est abonné. **La méthode POST de la RFC 8058 est vivement recommandée** ; la méthode `mailto:` est acceptée. |
| Désabonnement visible | Un lien de désabonnement évident et visible dans le corps du message, qui **n'exige pas de se connecter**. Les liens du corps peuvent mener à des pages de préférences, mais ils ne remplacent pas l'en-tête |
| Respect des désabonnements | Traiter les demandes de désabonnement **sous 2 jours**, sans délai de grâce au-delà |
| Taux de plaintes | Taux de spam **sous 0,3 %**, calculé sur les messages livrés en boîte de réception |
| DNS et RFC | Les mêmes exigences de DNS direct et inverse, et de conformité à la RFC 5321 et à la RFC 5322, que pour tous les expéditeurs |

### Périmètre du désabonnement en un clic

- Il s'applique **uniquement aux messages promotionnels ou marketing**, pas aux messages transactionnels (confirmations de commande, réinitialisations de mot de passe).
- Si une catégorie de messages qui n'y est pas soumise génère beaucoup de plaintes, Yahoo conseille d'y ajouter malgré tout des options de désabonnement.
- Lorsque l'en-tête List-Unsubscribe est correctement configuré selon la RFC 8058 **et** que l'expéditeur a une réputation et un engagement suffisants, le webmail de Yahoo affiche une option bleue « Se désabonner » (*Unsubscribe*) à côté de l'adresse From. Testez-la sur https://mail.yahoo.com/.

### L'usurpation d'identité compte contre vous

Les messages qui usurpent votre domaine **comptent dans les seuils d'application de Yahoo**. Si votre domaine est usurpé, passez DMARC à une politique contraignante (`p=quarantine` ou `p=reject`). Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) pour atteindre l'application sans risque.

## Détails de l'authentification

- **Longueur de clé DKIM** : **1 024 bits** au minimum, et **2 048 bits** recommandés.
- **Signatures DKIM multiples** : Yahoo prend en compte toutes les signatures pour l'alignement DMARC, pour le calcul de la réputation et pour sa feedback loop de plaintes (Complaint Feedback Loop). Plusieurs signatures en échec ne font pas, cumulées, une réussite DMARC.
- **SPF** : publiez l'ensemble précis des adresses IP autorisées à envoyer.
- **ARC** (Authenticated Received Chain) : recommandé pour les messages transférés.
- Yahoo publie `p=reject` pour ses propres domaines : les messages qui usurpent des adresses From comme @yahoo.com sont donc rejetés.

## Recommandations au-delà des exigences

### Acquisition des adresses et hygiène de base de données

- N'envoyez qu'aux utilisateurs qui ont **expressément demandé** vos messages : pas de listes achetées, et pas de cases d'opt-in précochées.
- Utilisez le **double opt-in** (un clic de confirmation) pour améliorer la qualité de la liste.
- Annoncez dès l'inscription quels messages l'abonné recevra, à quelle fréquence et à quoi ils ressembleront, et **respectez la fréquence prévue pour la liste**, sans l'augmenter sans prévenir.
- Surveillez les rebonds définitifs et temporaires ainsi que les destinataires inactifs, et **retirez rapidement les destinataires invalides**.
- Envoyez de temps en temps un **email de reconfirmation aux abonnés inactifs**.

### Infrastructure

- Publiez des **enregistrements DNS inverse (PTR) valides, parlants et non génériques**, qui reflètent votre nom de domaine, et évitez les noms qui ressemblent à des adresses IP attribuées dynamiquement.
- **Séparez les flux de messages** : n'envoyez pas de courrier de masse ou marketing depuis les adresses IP (ou les domaines DKIM) que vous utilisez pour le courrier transactionnel, les alertes ou le courrier des utilisateurs. Voir [Segmentation avancée des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip).
- Maintenez vos serveurs à jour, et assurez-vous qu'ils ne sont ni des **relais ouverts ni des proxys ouverts** (Yahoo rejette les messages qui en proviennent).
- Annoncez des routes BGP (Border Gateway Protocol) pour l'espace d'adresses IP qui vous appartient.
- **Gestion des connexions** : limitez le nombre de messages par connexion SMTP, reconnectez-vous si la connexion se termine sans code d'erreur, et ouvrez des connexions simultanées avec mesure. Yahoo ne publie aucune limite précise par connexion ni sur le nombre de connexions simultanées.

### Surveillance et réputation

- Inscrivez tous vos domaines DKIM à la [feedback loop de plaintes de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/feedback-loop-de-plaintes-de-yahoo), et placez les plaignants en liste de suppression.
- Les éléments qui entrent dans la réputation chez Yahoo comprennent **la réputation de l'IP, de l'URL, du domaine et de l'expéditeur, la réputation du numéro de système autonome (ASN), les signatures DKIM, l'authentification DMARC**, et les votes spam des utilisateurs.
- Une bonne réputation de domaine ne garantit pas à elle seule la boîte de réception. Une combinaison de facteurs (plaintes élevées, URL masquées, absence de DNS inverse, non-conformité aux RFC) peut encore envoyer les messages en spam. Les règles définies par chaque utilisateur l'emportent sur les décisions du système.
- Maîtrisez les pics de trafic, et chauffez progressivement les nouvelles adresses IP. Voir [Chauffe d'IP (warm-up)](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip).
- Yahoo évalue le taux de plaintes pour l'application des règles **en continu**, et les messages des domaines dont le taux de plaintes est élevé peuvent être reportés.

### Conformité

- Respectez la loi **CAN-SPAM** : pas d'en-têtes faux ou trompeurs, et pas de lignes d'objet mensongères.

## Questions opérationnelles fréquentes

| Sujet | Réponse de Yahoo |
|---|---|
| Liste blanche | Il n'existe aucun programme formel de liste blanche. Pour un lancement important ou des notifications légales, soumettez une demande au support aux expéditeurs (Sender Support Request). La réputation peut être ajustée, mais la livraison en boîte de réception n'est jamais garantie. |
| Nouvelles adresses IP ou nouveaux domaines bloqués | Soumettez une demande au support aux expéditeurs qui comprend l'erreur et les codes de diagnostic relevés dans vos journaux. |
| Taille maximale des messages | Environ **25 Mo** de pièces jointes. Elle varie selon plusieurs facteurs, et ni les utilisateurs ni l'équipe Postmaster ne peuvent la modifier. |
| Signaler un abus commis par un utilisateur Yahoo | Marquer le message comme spam dans le produit, ou utiliser le formulaire Report Abuse de Yahoo, avec le texte intégral du message et ses en-têtes. |
| Logo BIMI qui ne s'affiche pas | Conditions : un enregistrement SVG valide pour Brand Indicators for Message Identification (BIMI), une politique DMARC de quarantaine ou de rejet, des envois en volume, ainsi qu'une réputation et un engagement suffisants. Laissez le temps à la propagation DNS, et vérifiez sur https://mail.yahoo.com/ après avoir vidé le cache. |

## Voir aussi

- [Feedback loop de plaintes de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/feedback-loop-de-plaintes-de-yahoo), pour surveiller les plaintes qui comptent dans le seuil de 0,3 %
- [Codes d'erreur SMTP de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/codes-d-erreur-smtp-de-yahoo)
- [Flux de données de délivrabilité de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/flux-de-donnees-de-delivrabilite-de-yahoo)
- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)

# GMX / WEB.DE (United Internet) : exigences postmaster

> Les exigences envers les expéditeurs de GMX, WEB.DE et mail.com (United Internet) : DKIM aligné obligatoire, règles strictes sur les en-têtes et le DNS, désabonnement selon la RFC 8058, format des messages d'erreur et parcours CSA.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/gmx-web-de-exigences-postmaster

Si votre liste compte des destinataires européens, certains utilisent GMX, WEB.DE ou mail.com, qui dominent le marché allemand de la messagerie grand public. Ces fournisseurs sont plus stricts que la plupart sur deux points : **DKIM est obligatoire (SPF seul ne suffit pas)** et **un DNS inverse générique est rejeté d'emblée**.

Tous trois sont exploités par United Internet (1&1) et partagent une même politique postmaster, publiée en parallèle sur `postmaster.gmx.net`, `postmaster.web.de` et `postmaster.mail.com`.

## Exigences d'infrastructure et de DNS

| Exigence | Détail |
|---|---|
| IP statique | Le serveur qui livre doit avoir une adresse IP statique. Les adresses IP provenant de plages d'accès commuté ou attribuées dynamiquement **ne sont pas acceptées** |
| DNS inverse (PTR) | Doit résoudre vers un FQDN **qui appartient au propre domaine de l'expéditeur**. Les noms génériques par défaut des fournisseurs (par exemple `123-123-123-123-static.ihrprovider.tld`) « entraînent généralement un rejet » (*usually result in rejection*) |
| DNS direct | Le domaine d'envoi doit avoir des **enregistrements MX ou A** valides |
| HELO ou EHLO | Doit être un **FQDN** valide |
| Listes de blocage | Ni l'adresse IP ni le domaine ne doivent figurer sur des listes de blocage connues (ils suggèrent de vérifier sur dnsbl.info) |

## Exigences de format des messages (RFC 5321 et 5322)

- Les en-têtes doivent respecter la **RFC 5321** et la **RFC 5322**.
- Champs d'en-tête obligatoires : **`Date`, `From`, `Message-ID`** (et `Sender` le cas échéant).
- Chacun des champs **`BCC`, `CC`, `Date`, `From`, `Sender`, `Subject`, `To`** ne peut apparaître **qu'une seule fois**.
- Le champ `Date` (date, heure et fuseau horaire) doit être exact, et ne doit pas s'écarter sensiblement de l'heure réelle d'envoi.

## Authentification : DKIM obligatoire et aligné

- **DKIM est obligatoire** : « l'utilisation d'une signature DKIM valide est obligatoire » (*the use of a valid DKIM signature is mandatory*).
- **SPF est seulement recommandé.** Selon leurs termes : « Nous exigeons DKIM comme condition minimale ; SPF seul ne suffit pas » (*We require DKIM as a minimum requirement; SPF alone is not sufficient*).
- **DMARC est recommandé** pour prévenir l'usurpation d'identité et le phishing.
- Le domaine DKIM `d=` doit être **aligné sur le domaine `RFC5322.From`**, au moins en mode souple :

| Domaine DKIM (`d=`) | Domaine From | Mode |
|---|---|---|
| example.com | child.example.com | souple (accepté) |
| child.example.com | example.com | souple (accepté) |
| example.com | example.com | strict |
| child.example.com | child.example.com | strict |

C'est la même notion d'alignement que celle de DMARC (voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)), mais United Internet impose l'alignement DKIM comme condition d'acceptation même quand le domaine n'a pas de politique DMARC.

## Exigences envers les expéditeurs de gros volumes

- **Consentement explicite uniquement**, idéalement par **double opt-in**.
- Suivre les recommandations du **M3AAWG** et de la **CSA**. La participation à la CSA est recommandée (voir plus bas).
- **Désabonnement :** chaque email doit contenir une option de désabonnement facile à trouver et à comprendre. La méthode à privilégier est le désabonnement en un clic List-Unsubscribe de la **RFC 8058**. Si un message est conforme, GMX et WEB.DE affichent un **bouton de désabonnement** dans leur interface. Si la RFC 8058 n'est pas respectée, une **adresse de réponse valide** doit être fournie à la place.
- **Hygiène de base de données :** évitez les adresses invalides, inactives ou périmées, et retirez régulièrement les adresses qui ne peuvent pas être livrées. « Si de nombreux messages sont envoyés à des adresses inconnues ou désactivées, cela peut entraîner une suspension temporaire » (*If many messages are sent to unknown or deactivated addresses, this can lead to temporary suspension*) de l'acceptation.
- **Identité de l'expéditeur :** l'expéditeur doit être identifiable clairement et sans ambiguïté, le contenu doit être pertinent et la fréquence appropriée.
- **Réserve sur la chauffe :** pour les envois en masse, « notre système peut limiter la livraison malgré la chauffe de l'IP » (*our system may throttle delivery despite IP warm-up*). Attendez-vous à des échecs temporaires sur les nouvelles adresses IP, même avec une montée en charge correcte (voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)).

## Messages d'erreur

United Internet documente la **structure** de ses erreurs SMTP plutôt qu'un tableau complet des codes :

- Les codes **5xx** sont des erreurs permanentes, et les codes **4xx** des erreurs temporaires.
- Chaque rejet contient un code d'état SMTP, une description du problème et une **URL avec des paramètres de diagnostic**. Cette URL pointe vers la page postmaster correspondante (`https://postmaster.gmx.net/...`, `postmaster.web.de` ou `postmaster.mail.com`), qui donne des explications et des solutions. Suivez toujours cette URL, car elle identifie le motif exact du blocage.
- Exemple : `554 gmx.net (mxgmx104) Nemesis ESMTP Service not available / No SMTP service / IP address is block listed.` L'adresse IP qui se connecte figure sur une liste de blocage, et l'URL du message explique comment corriger le problème.

## Comportement du filtrage, liste blanche et feedback loop

- **Pas de liste blanche :** « GMX ne propose pas ce service » (*GMX does not offer this service*). Selon GMX, respecter les exigences rend la liste blanche inutile.
- **Comportement proche de la liste grise :** ils retardent ou rejettent les messages des serveurs qui présentent « des caractéristiques évidentes d'un serveur de spam » (*unmistakable characteristics that indicate a spamming server*).
- Le filtrage repose **à la fois sur les adresses IP et sur le contenu**. Si un message est classé à tort, soumettez ses en-têtes étendus par leur formulaire de contact (`https://postmaster.gmx.net/en/contact`).
- **Pas de FBL publique qui leur soit propre.** En pratique, les retours de plaintes pour GMX et WEB.DE sont accessibles par la **CSA** (les expéditeurs certifiés reçoivent des données de plaintes dans le cadre de la certification). Le site postmaster lui-même oriente les expéditeurs de gros volumes vers la CSA au lieu de proposer une inscription directe à une FBL.

## Certified Senders Alliance (CSA) et trustedDialog

- **CSA** : un projet de liste positive d'eco (Verband der deutschen Internetwirtschaft) mené avec la DDV. GMX, WEB.DE et plusieurs autres fournisseurs européens vérifient la certification, et United Internet recommande aux expéditeurs de newsletters et de publicités d'y participer. Informations : certified-senders.org.
- **trustedDialog** : une norme payante de protection de marque d'United Internet Media. Elle associe l'authentification de l'expéditeur à la vérification de l'intégrité du contenu et, en retour, affiche un **sceau et le logo de la marque dans la boîte de réception**, donne aux destinataires plus de confiance dans l'authenticité de l'expéditeur et (selon United Internet Media) améliore les taux d'ouverture et de clics. Elle concerne surtout les grandes marques grand public qui écrivent à des utilisateurs allemands.

## Serveurs sortants de GMX (pour les serveurs de réception et les vérifications)

Les messages qui proviennent réellement de GMX arrivent depuis ces hôtes publiés :

| Rôle | Nom d'hôte | Adresses IP |
|---|---|---|
| Sortant | mout.gmx.net | 212.227.15.15, 212.227.15.18, 212.227.15.19, 212.227.17.20, 212.227.17.21, 212.227.17.22 |
| Traitement des rebonds | mout-bounce.gmx.net | 212.227.15.44–46, 212.227.17.26, 212.227.17.28, 212.227.17.29 |
| Réputation plus faible (messages transférés par les clients) | mout-xforward.gmx.net | 82.165.159.12–14, 82.165.159.40–42 |

## Si GMX vous bloque

1. Lisez le rebond. Il contient le motif exact et une URL postmaster.
2. Corrigez la cause profonde au regard des exigences ci-dessus (le formulaire de retrait de liste ne servira à rien tant que des problèmes de PTR, de DKIM ou de consentement persistent).
3. Contactez l'équipe abuse par le formulaire de contact postmaster, en indiquant votre adresse email, votre adresse de contact, votre nom, **la date de la tentative d'envoi, le domaine du destinataire et le message d'erreur exact ou le texte du mailer-daemon**. Les rebonds dus à des boîtes pleines ou à une mauvaise configuration chez le destinataire ne relèvent pas d'une inscription sur liste de blocage, et n'ont pas leur place dans ce formulaire.

# La feedback loop de plaintes de Yahoo (CFL)

> Le fonctionnement de la Complaint Feedback Loop de Yahoo, fondée sur le domaine DKIM : inscription via Sender Hub, format des rapports ARF et règles opérationnelles.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/feedback-loop-de-plaintes-de-yahoo

Si vous envoyez des emails à des utilisateurs de Yahoo, vous pouvez recevoir un rapport chaque fois que l'un d'eux marque votre message comme spam. La Complaint Feedback Loop (CFL) de Yahoo envoie ces rapports au format **ARF (Abuse Reporting Format)**.

Les rapports vous permettent de **placer les plaignants en liste de suppression pour les campagnes suivantes**, et d'ajuster votre ciblage et votre fréquence. C'est important, car les votes spam nuisent directement à la réputation d'expéditeur et comptent dans le seuil de 0,3 % de plaintes de Yahoo (voir [Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs)).

## Caractéristiques principales

| Caractéristique | Valeur |
|---|---|
| Fondement | **Fondée sur le domaine, DKIM uniquement.** Seuls les messages signés avec DKIM sont pris en charge, car c'est par DKIM que Yahoo identifie l'expéditeur réellement responsable |
| FBL fondée sur l'adresse IP | **Non proposée.** Yahoo ne prend plus en charge les rapports CFL fondés sur des adresses IP ou des plages CIDR |
| Format des rapports | ARF |
| Couverture | Tous les domaines grand public hébergés par Yahoo, y compris AOL (des milliers de domaines hébergés) |
| Qui doit s'inscrire | Les expéditeurs d'emails en masse. Les ESP inscrivent généralement les domaines DKIM pour le compte de leurs clients |

## Inscription (via Sender Hub)

1. **Créez votre profil d'expéditeur** sur Yahoo Sender Hub (senders.yahooinc.com).
2. **Ajoutez et vérifiez vos domaines** : les domaines DKIM `d=` avec lesquels vous signez.
3. **Inscrivez chaque domaine** à la CFL.

Remarques :

- Les inscriptions faites avec l'**ancien formulaire de Yahoo, antérieur à Sender Hub, n'ont pas été reprises**. Il fallait se réinscrire via Sender Hub. Les rapports ARF des anciennes inscriptions ont cessé le **1er août 2024**, sans délai de grâce.
- L'**adresse de réception des rapports peut être n'importe quelle adresse email que vous contrôlez**. Sa propriété est vérifiée lors de l'inscription, et vous pouvez réutiliser la même adresse vérifiée pour inscrire d'autres domaines.
- Inscrire le domaine organisationnel n'inscrit pas tous ses sous-domaines. **Les rapports ARF sont envoyés pour les domaines DKIM inscrits qui correspondent à la signature** du message ayant fait l'objet d'une plainte. Inscrivez chaque domaine de signature.
- Pour vérifier l'état des inscriptions, les modifier ou les supprimer, allez dans **Manage Services**, puis **Complaint Feedback Loop**, dans votre profil Sender Hub.

## Fonctionnement des rapports

- Tous les rapports utilisent l'**Abuse Reporting Format (ARF)** et contiennent **au moins trois parties MIME** : une partie en texte brut, des métadonnées lisibles par une machine au format MIME, et les en-têtes du message d'origine.
- Les messages de rapport arrivent avec :
  - le nom d'affichage de l'en-tête From : **"Yahoo! Mail AntiSpam Feedback"**
  - l'expéditeur SMTP : **feedback@arf.mail.yahoo.com**
  - une signature DKIM avec le domaine **arf.mail.yahoo.com** (vérifiez la signature avant de vous fier aux rapports ou d'automatiser des actions à partir d'eux)
- Lorsqu'un message porte plusieurs signatures DKIM, Yahoo les évalue toutes pour la CFL (ainsi que pour l'alignement DMARC et la réputation).

## Usage opérationnel

- **Automatisez la suppression.** Analysez les rapports ARF entrants, et désabonnez ou placez immédiatement en liste de suppression le destinataire qui s'est plaint. Continuer à écrire aux personnes qui se sont plaintes aggrave les dégâts de réputation.
- **Surveillez le taux de plaintes.** Comparer le volume de la CFL au volume livré chez Yahoo est le moyen pratique de suivre votre position par rapport au seuil de 0,3 %. L'indicateur `complaints` des [flux de données de délivrabilité](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/flux-de-donnees-de-delivrabilite-de-yahoo) en donne une vue agrégée.
- **Diagnostiquez les segments.** Un pic de rapports ARF après un changement de contenu, de fréquence ou d'audience permet d'identifier la campagne ou le segment en cause.

## Voir aussi

- [Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs), y compris le seuil de 0,3 % de plaintes
- [Flux de données de délivrabilité de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/flux-de-donnees-de-delivrabilite-de-yahoo), pour les indicateurs agrégés de plaintes et de placement
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email), sur la façon dont les plaintes influent sur la réputation

# Le fonctionnement interne du filtrage de Gmail

> Comment Gmail décide réellement du placement : réputation de l'expéditeur authentifié par domaine, classification du spam et du phishing par apprentissage automatique et par LLM, catégorisation de la boîte de réception en onglets, et signaux de personnalisation par utilisateur qui rendent impossible un diagnostic unique.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/fonctionnement-interne-du-filtrage-de-gmail

Si vos messages arrivent en boîte de réception chez certains utilisateurs de Gmail et dans le dossier spam chez d'autres, la raison tient à la façon dont Gmail décide du placement. Les [exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs) disent ce que Gmail vérifie. Ce qui suit décrit ce que Gmail fait du résultat. Deux faits dominent, et ils expliquent pourquoi la délivrabilité chez Gmail résiste à un diagnostic unique :

1. **La réputation est calculée sur le domaine d'envoi authentifié, pas sur l'adresse IP.** C'est l'inverse de la plupart des serveurs de réception, qui centrent la réputation sur les adresses IP. L'authentification est la condition préalable qui permet tout simplement d'évaluer un message.
2. **Le placement est appris pour chaque utilisateur.** Le même message du même expéditeur peut arriver en boîte de réception chez un destinataire et dans le dossier spam chez un autre, car Gmail laisse l'historique de signalements et de marquages d'un utilisateur l'emporter sur la réputation générale de l'expéditeur. Il n'y a pas de réponse unique à « est-ce que j'arrive en boîte de réception chez Gmail ? », seulement une répartition entre destinataires.

Tout cela est documenté, et non déduit, principalement à partir des propres travaux de recherche de Google (Taylor, CEAS 2006 ; Taylor, Fingal et Aberdeen, NIPS 2007) et de ses pages d'aide et de blog. L'article de 2006 décrit un système de l'époque de la version bêta, et les mécanismes ont depuis été reconstruits sur l'apprentissage automatique (voir [classification par apprentissage automatique](#classification-du-spam-et-du-phishing-par-apprentissage-automatique)). Mais cet article est le seul endroit où Google a exposé concrètement la logique de la réputation, et ses principes décrivent toujours le comportement du système : évaluation sur le domaine authentifié, autocorrection par les votes des utilisateurs, et zone intermédiaire confiée à un filtre statistique. Considérez les formules comme des illustrations du modèle, pas comme le code qui tourne aujourd'hui.

## Le modèle de réputation du domaine authentifié

Source : **« Sender Reputation in a Large Webmail Service »**, de Bradley Taylor (Google), CEAS 2006 (Third Conference on Email and Anti-Spam). Gmail a été lancé en version bêta en avril 2004, et l'article décrit le système de réputation construit pendant cette bêta.

### Pourquoi le domaine, et pas l'IP

Google a écarté la réputation d'IP comme clé principale, car l'IP « est une forme d'authentification rudimentaire » (*is a crude form of authentication*). Un même expéditeur n'utilise pas toujours la même IP. À cause du transfert, l'IP qui se connecte n'est pas toujours le véritable expéditeur. Les adresses IP des en-têtes `Received` ne peuvent pas être authentifiées de façon fiable. Et quand plusieurs domaines partagent un ensemble d'adresses IP, un seul domaine qui envoie du spam « peut ruiner la réputation de tous les autres domaines » (*can ruin the reputation for all the other domains*). Gmail classe donc les messages selon **qui envoie (le domaine authentifié)** plutôt que selon **ce que contient le message**. L'article présentait Gmail comme « le seul » (*the only one*) des grands systèmes de réputation à fonctionner sur le domaine authentifié plutôt que sur l'IP.

Voici les méthodes d'authentification utilisées pour établir le domaine, et leur répartition dans les messages qui arrivaient chez Gmail :

| Méthode d'authentification SPF | Part des messages authentifiés par SPF | Mécanisme |
|---|---|---|
| SPF simple | 52 % | Un enregistrement SPF publié |
| SPF « best-guess » | 38 % | Pas d'enregistrement SPF, ou un enregistrement en échec : considérer le message comme authentifié si l'IP d'envoi se trouve dans la même plage que les enregistrements A ou MX du domaine, **ou** si le nom DNS inverse de l'IP d'envoi correspond au domaine annoncé dans l'email |
| Zone PTR | 10 % | Si SPF simple et SPF best-guess échouent tous deux, et que l'expéditeur est un sous-domaine de la zone DNS du PTR, traiter le message comme s'il venait de la zone elle-même (par exemple `subdomain.example.com` depuis une IP dont le PTR est `host.example.com`) |

DomainKeys, le prédécesseur de DKIM, était l'autre signal. Gmail l'a adopté tôt, en partie parce que SPF casse lors d'un transfert alors qu'une signature y survit. La recommandation de Google, hier comme aujourd'hui, est de **mettre en place les deux**, pour que si un transfert ou une modification du message casse l'un, l'autre authentifie encore : « si les deux sont présents, le signal d'authentification est d'autant plus fort » (*if both are present, it is that much stronger of an authentication signal*).

Les taux d'authentification étaient très différents entre les messages souhaités et les messages indésirables, si bien que l'authentification est en soi un signal de réputation :

| Méthode | Non-spam (souhaité) | Spam (indésirable) |
|---|---|---|
| SPF et DomainKeys | 20 % | 1,5 % |
| SPF seul | 53 % | 39 % |
| DomainKeys seul | 1 % | 0,5 % |
| Non authentifié | 26 % | 59 % |
| **Authentifié (toute méthode)** | **environ 75 %** | **environ 40 %** |

### Le calcul de la réputation

Chaque message livré enregistre un événement avec son classement et son authentification. Quatre compteurs s'accumulent pour chaque domaine authentifié :

| Variable | Signification |
|---|---|
| `autononspam` | nombre de fois où un message de cet expéditeur est allé automatiquement en boîte de réception |
| `autospam` | nombre de fois où un message de cet expéditeur est allé automatiquement dans le dossier spam |
| `manualnonspam` | nombre de fois où un utilisateur a cliqué sur **Not Spam** pour cet expéditeur |
| `manualspam` | nombre de fois où un utilisateur a cliqué sur **Report Spam** pour cet expéditeur |

La réputation est un nombre **de 0 à 100** : « on peut voir la réputation comme la probabilité que les messages d'un expéditeur donné ne soient pas du spam » (*you can think of the reputation as the probability that a given sender's mail is not spam*). 0 correspond au plus spammeur, et 100 au moins spammeur.

```
good       = autononspam + manualnonspam − manualspam
total      = autospam + autononspam
reputation = 100 × good / total
```

La version affinée plafonne les termes manuels, pour qu'un petit nombre de votes ne puisse pas dominer, et évite la division par zéro (si `total = 0`, il n'y a pas de réputation) :

```
manualnonspam2 = min(autospam,    manualnonspam)
manualspam2    = min(autononspam, manualspam)
good2          = autononspam + manualnonspam2 − manualspam2
reputation     = 100 × good2 / total
```

Exemples chiffrés tirés de l'article :

- `weliketospam.com` envoie 100 spams. 60 atterrissent automatiquement dans le dossier spam et 40 arrivent en boîte de réception comme faux négatifs, ce qui donne une réputation de **40**. Quand 30 utilisateurs signalent ensuite les spams qui ont échappé au filtre, la réputation tombe à **10**.
- `weneverspam.com` envoie 100 messages. 5 arrivent à tort dans le dossier spam comme faux positifs, ce qui donne une réputation de **95**. Quand 3 utilisateurs annulent ce classement, la réputation monte à **98**.

La réputation sert aussi de taux de faux positifs attendu. Pour un expéditeur dont la réputation est de 2, avec un seuil de dossier spam fixé sous une réputation de 5, « vous aurez des faux positifs sur les messages de cet expéditeur environ 2 % du temps ».

### Autocorrection, pondération des votes et dynamique de rétablissement

- Les réputations sont calculées **sur de nombreux jours**, si bien qu'un domaine solide « peut se bâtir une réputation très solide » (*can build up a very solid reputation*) et qu'« un petit accès de spam [...] est absorbé comme du bruit » (*a little blip of spam ... is absorbed as noise*). En contrepartie, un domaine qui envoie du spam pendant longtemps puis se corrige **met quelques jours à se rétablir**.
- **Les boutons Report Spam et Not Spam sont tous deux essentiels.** Si seuls les signalements de spam sont pris en compte, la réputation ne peut pas remonter après une erreur du filtre, et ne peut donc pas se corriger d'elle-même. Google qualifie la présence des deux boutons d'« essentielle au succès » (*critical for the success*) du système.
- **Tous les utilisateurs ne votent pas, et les votes sont limités.** Seule une partie des utilisateurs, « ceux qui fourniront les meilleures informations » (*the ones that will provide the best information*), est prise en compte, et les utilisateurs qui ne signalent jamais ni spam ni non-spam sont exclus. Pour éviter que les utilisateurs qui reçoivent beaucoup de messages dominent, chaque utilisateur est limité à **un signalement de spam par domaine et par heure**, soit **24 votes par domaine et par jour** au maximum.

### L'usage de la réputation (le partage en trois)

Après avoir authentifié l'expéditeur et calculé la réputation du domaine, Gmail procède ainsi :

1. Une réputation **au-dessus d'un seuil** envoie tous les messages de l'expéditeur en **boîte de réception**.
2. Une réputation **sous un seuil** les envoie tous dans le **dossier spam**.
3. **Entre les deux (ou si elle est inconnue)**, le message est transmis, avec la valeur de réputation, à un **filtre antispam statistique qui prend la décision finale** sur le contenu.

Point essentiel : **un utilisateur peut passer outre la politique générale pour des adresses d'expéditeur précises**. C'est la raison documentée pour laquelle le placement diffère d'un utilisateur à l'autre.

### À quoi ressemblait la répartition des réputations

- Les domaines de spam se regroupent étroitement autour de **0**, et les domaines de messages souhaités dans la fourchette **90–100**. Pour les expéditeurs légitimes de gros volumes, un score **inférieur à 90** est « le reflet de pratiques d'envoi loin d'être idéales » (*a reflection of less-than-ideal sending practices*). Une hygiène imparfaite se traduit par un score moyen, pas par un zéro.
- Réputations de quelques domaines (2006, à titre d'illustration du modèle) : `aol.com` 98,5 ; `yahoo.com` 95,6 avec SPF et 95,0 avec DomainKeys (DK) ; `hotmail.com` 95,4 ; `ebay.com` 95,2 avec SPF contre 98,2 avec DomainKeys ; `earthlink.net` 93,3 avec SPF contre 98,0 avec DK. Les domaines signalés comme spam obtenaient de 1,5 à 3,3.
- L'écart entre SPF et DomainKeys pour `ebay.com` est instructif. eBay ne signait avec DomainKeys que ses messages transactionnels, et ces messages « étaient probablement plus souhaités par les utilisateurs que les autres » (*would likely be more wanted by users than other mail*), si bien que le flux signé obtenait un meilleur score. C'est une première illustration de l'intérêt de la **séparation des flux** (voir [Segmentation avancée des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip) et [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi)).

### Défaillances documentées et règles qui en découlent pour l'expéditeur

L'article relève ces problèmes, et tous sont encore d'actualité :

- **Le transfert :** les utilisateurs transfèrent des messages (spam compris) avec des outils comme `procmail`, qui réécrivent l'expéditeur d'enveloppe. Le spam transféré s'authentifie alors comme venant du service de transfert, et « nuit injustement à la réputation du domaine qui transfère » (*hurts the reputation of the forwarding domain unfairly*). La règle qui en découle est de ne pas authentifier les messages que vous ne faites que transférer, sauf si vous en avez d'abord filtré le spam, car les signer revient à assumer la responsabilité du flux qui en résulte. [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc) a plus tard traité le même problème.
- **Les listes de diffusion :** le domaine d'une liste (l'exemple de l'article est Yahoo Groups, signé `yahoogroups.com`) peut avoir une bonne réputation globale alors que certains groupes qu'il héberge envoient du spam, si bien qu'une confiance généralisée « laissera passer du spam » (*will allow some spam through*). En outre, les utilisateurs trouvent souvent **plus facile de signaler une liste comme spam que de se désabonner**, ce qui nuit à la réputation de l'expéditeur de la liste « plus que nécessaire » (*worse than it needs to be*). C'est un argument pour une option de désabonnement bien visible et sans friction (voir [List-Unsubscribe et désabonnement en un clic](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic)).

Politiques que l'article recommande aux expéditeurs :

1. Authentifiez-vous avec **à la fois** SPF et DomainKeys ou DKIM (vous disposez peut-être déjà implicitement de SPF best-guess).
2. **N'authentifiez pas les messages que vous ne faites que transférer**, sauf si vous en avez d'abord filtré le spam.
3. Tenez les spammeurs et les machines zombies à l'écart de votre réseau, et respectez les bonnes pratiques d'envoi en masse : « si un expéditeur fait quelque chose de mal, comme utiliser le simple opt-in au lieu du double opt-in, cela se traduit simplement par une mauvaise réputation et une plus grande probabilité de finir dans le dossier spam » (*if a sender is doing something bad such as using single opt-in instead of double opt-in, it simply translates into a poor reputation and a greater likelihood of ending up in the spam folder*). **Ce sont les utilisateurs qui font respecter les consignes de Gmail sur les envois en masse**, à travers la réputation, pas un règlement.

## Classification du spam et du phishing par apprentissage automatique

Le modèle de réputation ci-dessus répond à la question « cet expéditeur est-il digne de confiance ? ». Pour tout ce qui se trouve dans la zone intermédiaire ambiguë, le verdict sur le contenu vient de classificateurs à apprentissage automatique, reconstruits et agrandis à plusieurs reprises.

- **« The War Against Spam: A Report from the Front Line »** (Taylor, Fingal et Aberdeen, NIPS 2007 Workshop on Machine Learning in Adversarial Environments) présente le filtrage antispam de Gmail comme un succès concret de l'apprentissage automatique en environnement adverse : l'immense majorité du spam est identifiée avec certitude, avec une grande précision (peu de faux positifs). Ce cadre adverse compte. Les spammeurs s'adaptent, donc les filtres doivent être réentraînés en continu au lieu d'appliquer un ensemble de règles figé.
- **2014 : une reconstruction à l'échelle de TensorFlow.** Les filtres à règles de Google avaient atteint environ 99 % de précision. À partir de 2014, Google a ajouté des **algorithmes d'apprentissage automatique fondés sur TensorFlow** qui « régénèrent en continu » (*continuously regenerate*) les filtres antispam, trouvent de nouveaux schémas et s'adaptent « bien plus vite que les anciens systèmes manuels » (*far quicker than previous manual systems*). Résultat annoncé : **plus d'un milliard d'utilisateurs de Gmail évitent le spam**, avec une efficacité d'environ **99,9 %**.
- **Annonces de 2017 sur le modèle de sécurité** (Google, 31 mai 2017) : **plus de 99,9 % de précision** dans le blocage du spam et du phishing, et **50–70 % de tous les messages que reçoit Gmail sont du spam**. Les classificateurs combinent **des milliers de signaux de spam, de logiciels malveillants et de rançongiciels** avec des **heuristiques sur les pièces jointes** et des **signatures d'expéditeurs**. Les défenses contre le phishing combinent **Google Safe Browsing** avec une **analyse de la réputation et de la similarité des URL**. Un modèle de détection précoce du phishing peut **retarder de façon sélective** les messages à risque pour une analyse plus poussée, ce qui concerne **moins de 0,05 % des messages en moyenne**. Des avertissements au moment du clic, des avertissements sur les réponses à des destinataires externes et des défenses contre les rançongiciels et les logiciels malveillants polymorphes complètent le dispositif.
- **2024 : des classificateurs à grand modèle de langage.** Google a déployé **un grand modèle de langage (LLM) entraîné sur le phishing, les logiciels malveillants et le spam** qui bloque **20 % de spam en plus** et examine **1 000 fois plus de spam signalé par les utilisateurs chaque jour**, avec un second modèle « superviseur » qui évalue **des centaines de signaux de menace** lorsqu'un message à risque est repéré. Voir [le durcissement pendant les fêtes](#durcissement-pendant-les-fêtes-de-fin-dannée) plus bas.

Conséquence pour les expéditeurs : le classificateur est une cible mouvante, entraînée sur tout ce que signalent les utilisateurs. Il n'existe aucune liste blanche de contenu à satisfaire, car le filtre optimise ce que les utilisateurs traitent comme souhaité. C'est le mécanisme qui sous-tend les recommandations de [Contenu et design au service de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite) : éviter les schémas de spam et optimiser l'engagement, plutôt que suivre une liste de mots-clés.

## La catégorisation de la boîte de réception (les onglets)

La catégorisation est une **décision distincte, prise après l'acceptation**, du verdict entre boîte de réception et spam. Un message qui a déjà gagné la boîte de réception est ensuite rangé dans l'une des cinq catégories par défaut (dans le type de boîte de réception « Default » de Gmail). **Arriver dans un onglet de catégorie autre que Primary n'est pas un échec de délivrabilité.** Promotions, c'est la boîte de réception, pas le spam.

| Catégorie | Définition de Google |
|---|---|
| **Primary** | « Les emails de personnes que vous connaissez et les messages qui n'apparaissent pas dans les autres onglets » (*Emails from people you know and messages that don't appear in other tabs.*) |
| **Social** | « Les messages des réseaux sociaux et des sites de partage de médias » (*Messages from social networks and media-sharing sites.*) |
| **Promotions** | « Les bons plans, les offres et les autres emails promotionnels » (*Deals, offers, and other promotional emails.*) |
| **Updates** | « Les confirmations, notifications, relevés et rappels automatiques qui ne demandent pas forcément une attention immédiate » (*Automated confirmations, notifications, statements, and reminders that may not need immediate attention.*) |
| **Forums** | « Les messages des groupes en ligne, des forums de discussion et des listes de diffusion » (*Messages from online groups, discussion boards, and mailing lists.*) |

Fonctionnement :

- Les utilisateurs activent ou désactivent les catégories dans **Quick Settings**, puis **Default inbox type**, puis **Customize**. Désactiver entièrement les catégories impose de passer à une autre disposition de boîte de réception. Comme c'est le destinataire qui choisit les onglets présents, un expéditeur ne peut même pas supposer qu'un destinataire donné possède un onglet Promotions.
- **Les expéditeurs ne peuvent pas choisir l'onglet à l'avance.** Les destinataires déplacent les messages d'un onglet à l'autre par **glisser-déposer** (avec une option d'annulation), ce qui apprend leur préférence à Gmail pour qu'il « trie vos emails plus précisément » (*sort your email more accurately*) au fil du temps. C'est une autre préférence de l'utilisateur qui l'emporte.
- Demander aux lecteurs engagés de faire glisser vos messages vers Primary est légitime et efficace. Voir [Contenu et design au service de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite) pour les facteurs de contenu (personnalisation, style conversationnel, nombre limité d'images et de liens) qui orientent les messages vers Primary plutôt que Promotions.

### La prédiction de catégorie comme problème d'apprentissage automatique

Source : **« Email Category Prediction »**, de Zhang, Garcia Pueyo, Wendt, Najork et Broder (Google, WWW 2017 Companion). Les points clés pour les expéditeurs :

- **Environ 90 % des emails grand public sont générés par des machines.** La catégorisation vise les messages issus de modèles (reçus d'achat, campagnes promotionnelles, confirmations de réservation, rappels de factures), pas les échanges entre personnes.
- L'approche exploite la **découverte des modèles** et les **« fils causaux »** (*causal threads*) des séquences d'emails, car les messages automatiques légitimes suivent des schémas prévisibles (une commande, puis une confirmation d'expédition, puis une alerte de livraison). Les séquences prévisibles qui correspondent à leurs modèles se classent proprement ; une structure erratique, non.
- Comparaison des modèles : **les réseaux de neurones (perceptrons multicouches, ou MLP, et réseaux de mémoire à long et court terme, ou LSTM) surpassent largement** une référence à chaîne de Markov, **les LSTM devançant légèrement les MLP**. Les applications citées comprennent le remplissage de l'agenda, les alertes d'expédition, la publicité ciblée et la détection du spam : la catégorisation alimente donc à son tour le filtrage.

## Les signaux de personnalisation par utilisateur

Au-delà du vote spam ou non-spam, Gmail exploite un modèle d'**importance** propre à chaque utilisateur et des contrôles antispam propres à chaque utilisateur. Ce sont ces mécanismes qui rendent le placement individuel.

**Marqueurs d'importance** (rubrique d'aide « Importance markers in Gmail »). Gmail prédit quels messages comptent pour chaque utilisateur à partir :

- de la fréquence à laquelle l'utilisateur échange avec l'expéditeur ;
- des messages que l'utilisateur ouvre et auxquels il répond ;
- **des mots-clés présents dans les emails que l'utilisateur lit habituellement** ;
- des interactions : ajout d'une étoile, archivage, suppression.

Les utilisateurs voient un marqueur d'importance jaune, peuvent le corriger (ce qui entraîne le modèle) et peuvent retrouver les messages marqués avec `is:important`. Un utilisateur peut désactiver le marquage prédictif (« Don't use my past actions to predict which messages are important ») ou masquer complètement les marqueurs. Ces réglages se modifient dans le navigateur, mais s'appliquent à toutes les applications.

**Contrôles antispam qui alimentent la personnalisation** (rubrique d'aide sur le tri du spam dans Gmail) :

| Action de l'utilisateur | Effet sur le placement futur |
|---|---|
| **Report spam** | Le message est ajouté au dossier Spam ; « plus vous signalez de spam, plus Gmail identifie efficacement les emails similaires comme du spam » (*as you report more spam, Gmail identifies similar emails as spam more efficiently*). Google reçoit une copie et peut l'analyser pour protéger tous les utilisateurs. |
| **Not spam** | Récupère le message et apprend à Gmail que cet expéditeur est souhaité (le vote `manualnonspam`). |
| **Block sender** | « Même lorsque vous retirez ses emails du dossier Spam, Gmail continue d'identifier automatiquement ses emails comme du spam » (*Even when you remove their emails from Spam, Gmail still automatically identifies their emails as spam.*). Une préférence stricte pour cet utilisateur. |
| **Ajouter l'expéditeur à Google Contacts** | « Gmail cesse d'envoyer ses messages dans le dossier Spam » (*Gmail stops sending their messages to Spam.*). Une autorisation stricte pour cet utilisateur. |
| **Unsubscribe** | Proposé directement dans le message pour les expéditeurs auxquels l'utilisateur s'est abonné. Une sortie moins dommageable que Report Spam. |
| **Filtres** | Des règles créées par l'utilisateur peuvent étiqueter ou prioriser les messages d'un expéditeur. |

Le fil conducteur : **l'historique du destinataire lui-même peut l'emporter sur la réputation globale de l'expéditeur, dans les deux sens.** Un expéditeur dont le domaine a une solide réputation arrive tout de même en spam chez tout destinataire qui l'a bloqué ou signalé à plusieurs reprises. Un expéditeur à la réputation faible arrive en boîte de réception chez les destinataires qui l'ont ajouté à leurs contacts ou ont cliqué sur Not Spam.

## Durcissement pendant les fêtes de fin d'année

Google durcit publiquement ses filtres pendant les périodes de forte fraude. Pour la **saison des fêtes 2024** (billet de blog, décembre 2024) :

- Gmail bloque **plus de 99,9 % du spam, du phishing et des logiciels malveillants**.
- Le **classificateur à LLM** nouvellement déployé et le **modèle superviseur** (voir [classification par apprentissage automatique](#classification-du-spam-et-du-phishing-par-apprentissage-automatique)) ont été mis en service **avant le Black Friday**.
- Résultat : les utilisateurs ont signalé **35 % d'arnaques en moins** arrivées en boîte de réception pendant le premier mois de la saison des fêtes, par rapport à l'année précédente.
- Les schémas d'arnaques de fin d'année contre lesquels Gmail a renforcé ses défenses : les **arnaques à la facture** (de fausses factures qui invitent le destinataire à appeler un numéro pour les contester), les **arnaques aux célébrités** (usurpation d'identité ou fausse recommandation) et les **arnaques à l'extorsion** (des menaces qui citent une adresse personnelle ou un détail privé).

Conséquence pour les expéditeurs : les seuils des filtres **ne sont pas constants tout au long de l'année**. Un flux à la réputation limite qui arrive en boîte de réception pendant un mois calme peut basculer en spam pendant une période de durcissement. Constituez une marge de réputation avant le quatrième trimestre (Q4), et ne lancez pas de nouveaux flux ni de nouvelle chauffe à l'approche du pic des fêtes.

## À retenir pour l'expéditeur : ce qui fait réellement bouger le placement chez Gmail

1. **Authentifiez-vous pour que vos messages puissent être évalués, puis bâtissez la réputation du domaine.** Utilisez SPF et DKIM alignés sur le [domaine From](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs). La réputation s'attache à ce domaine authentifié, pas à votre IP. Les messages non authentifiés ne peuvent pour la plupart pas être évalués, et ils sont corrélés au spam (environ 60 % du spam n'est pas authentifié, contre environ 26 % des messages souhaités).
2. **Le seul indicateur qui pilote directement le modèle est le vote spam de l'utilisateur.** Report Spam fait baisser la réputation ; Not Spam et l'ajout de l'expéditeur aux contacts la font monter. Maintenez le taux de spam dans [Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools) sous **0,10 %**, et ne le laissez jamais atteindre **0,30 %**. Ce sont les seuils des [exigences envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs) qui correspondent à ce vote.
3. **La réputation évolue lentement dans les deux sens.** Des jours de comportement régulier la construisent, un accès isolé est absorbé comme du bruit, et le rétablissement après un abus prolongé « prend quelques jours » (*takes a few days*). Il n'y a pas de solution du jour au lendemain ; voir [Rétablissement après un incident de réputation](https://emailmarketing.net/fr/apprendre/operations/retablissement-apres-un-incident-de-reputation).
4. **Séparez vos flux.** Dès 2006, les messages transactionnels signés séparément des messages marketing obtenaient un meilleur score, car les destinataires ne souhaitent pas les deux flux au même degré. Segmentez par [domaine ou sous-domaine d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi) et par type de contenu.
5. **La catégorisation n'est pas la délivrabilité.** Promotions, c'est la boîte de réception. Améliorez le placement par onglet grâce au contenu (personnalisation, ton conversationnel, moins d'images et de liens), pas en essayant de déjouer le classificateur : vous ne pouvez pas choisir l'onglet à l'avance.
6. **La personnalisation pour chaque utilisateur met en échec le diagnostic unique.** Les marqueurs d'importance, les blocages, les contacts et les préférences par adresse s'appliquent tous destinataire par destinataire, si bien que « où arrivent mes messages chez Gmail ? » n'a pas de réponse unique, seulement une répartition. Les tests sur liste de test portent sur une poignée de comptes neufs sans historique propre, et **ne peuvent donc pas représenter** ce que voit un vrai destinataire engagé (ou désengagé). Fiez-vous davantage aux tendances de la réputation agrégée et du taux de spam dans Postmaster Tools qu'à une capture d'écran d'une seule boîte de réception (voir [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure)).

> Note sur les sources : la réponse d'aide de Gmail **6596** (« Gmail inbox tabs and categories ») recoupe les recommandations sur les onglets Gmail de [Contenu et design au service de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite) et la présentation de la catégorisation ci-dessus. Elle n'a pas été utilisée séparément, car elle n'apporte rien de plus que la réponse 3094499, déjà citée.

## Voir aussi

- [Exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs), les règles vérifiables et les seuils de taux de spam qui alimentent ce modèle
- [Erreurs SMTP de Gmail et dépannage](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/depannage-gmail), y compris les messages de blocage pour réputation
- [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools)
- [Contenu et design au service de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite)
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)
- [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc), la correction ultérieure du problème de transfert décrit dans l'article de 2006

# Le fonctionnement interne du filtrage de Microsoft (EOP / Defender for Office 365)

> Lire les en-têtes X-Forefront-Antispam-Report et X-Microsoft-Antispam, les échelles SCL et BCL avec les actions à chaque niveau, les codes de motif compauth, l'empilement des couches de filtrage EOP/MDO et le fonctionnement de la Tenant Allow/Block List du point de vue de l'expéditeur.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/fonctionnement-interne-du-filtrage-de-microsoft

Quand vos messages destinés à une entreprise qui utilise Microsoft 365 arrivent dans le dossier Courrier indésirable ou en quarantaine, les en-têtes du message vous disent pourquoi. Voici comment Exchange Online Protection (EOP) filtre les messages entrants destinés aux **clients professionnels** (tenants), et comment un expéditeur ou un consultant lit son verdict.

C'est un système différent du filtrage des boîtes Outlook.com grand public (héritier de SmartScreen et visible dans SNDS), que traite [Exigences de Microsoft envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs). Les deux systèmes partagent toutefois des données de réputation, et les expéditeurs B2B dépendent des verdicts d'EOP.

Pour diagnostiquer un message, obtenez-en une copie telle qu'elle a été livrée (ou classée en courrier indésirable ou mise en quarantaine) auprès d'un destinataire Microsoft 365, et extrayez les en-têtes complets. Lisez trois en-têtes dans l'ordre : `Authentication-Results` (l'authentification a-t-elle réussi ?), `X-Forefront-Antispam-Report` (quel est le verdict, et pourquoi ?) et `X-Microsoft-Antispam` (BCL). L'analyseur de Microsoft lui-même est le Message Header Analyzer, à l'adresse `https://mha.azurewebsites.net/`.

## L'empilement des couches

1. **Le filtrage des connexions en bordure du service**, fondé sur l'adresse IP. C'est là que la plupart du spam est intercepté. Les données d'entrée sont la liste des expéditeurs bloqués de Microsoft (voir [Canaux d'escalade de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-de-microsoft)), les listes d'autorisation et de blocage d'adresses IP du client, et la réputation des adresses IP. Les entrées de la liste de blocage d'IP d'un client rejettent les messages en bordure.
2. **Les stratégies antispam (filtrage du contenu)** classent chaque message comme bulk, spam, spam à haut niveau de confiance, phishing ou phishing à haut niveau de confiance, et apposent les valeurs SCL et BCL. Il existe trois niveaux de stratégies : la stratégie **par défaut**, les stratégies **personnalisées** créées par les administrateurs, et les **stratégies de sécurité prédéfinies Standard et Strict**. Les stratégies prédéfinies ont des valeurs par défaut de plus en plus agressives et, pour les destinataires qu'elles incluent, leurs réglages l'emportent sur ceux des stratégies personnalisées.
3. **L'anti-phishing, la spoof intelligence et l'authentification composite** : la couche d'authentification implicite de Microsoft (`compauth`), qui juge le domaine From même en l'absence d'enregistrement DMARC.
4. **Les modules complémentaires de Defender for Office 365 (MDO)** : la protection contre l'usurpation d'identité (des utilisateurs, des domaines, et par la mailbox intelligence), Safe Links et Safe Attachments. Ils n'existent que chez les clients disposant de licences MDO, et produisent les valeurs `CAT` marquées MDO uniquement ci-dessous.

Les modifications de stratégie mettent jusqu'à 1 heure à s'appliquer. Lorsque plusieurs détections se déclenchent, les stratégies s'appliquent par ordre de priorité et le verdict le plus prioritaire l'emporte.

## L'en-tête X-Forefront-Antispam-Report

L'en-tête est une liste de paires champ:valeur séparées par des points-virgules, par exemple `...CTRY:;LANG:hr;SCL:1;SRV:;IPV:NLI;SFV:NSPM;PTR:;SFTY:;...`. Les champs que Microsoft ne documente pas servent au diagnostic interne. Les champs documentés sont les suivants :

| Champ | Signification |
|---|---|
| `ARC` | Évaluation ARC : `AAR` (Authentication-Results enregistrés), `AMS` (signature du message), `AS` (signature des en-têtes avec validation de la chaîne `cv=` : none, pass ou fail) |
| `CAT` | Catégorie de menace appliquée (voir le tableau ci-dessous) |
| `CIP:[IP]` | Adresse IP de connexion, utilisable dans les listes d'autorisation et de blocage d'IP du client |
| `CTRY` | Pays ou région source, d'après l'adresse IP de connexion (peut différer de l'adresse IP d'origine) |
| `DIR` | Direction : `INB` entrant, `OUT` sortant, `INT` interne |
| `H:[helostring]` | Chaîne HELO ou EHLO du serveur qui se connecte |
| `IPV:CAL` | Filtrage antispam ignoré, car l'adresse IP source figurait dans la liste d'autorisation d'IP du client |
| `IPV:NLI` | Adresse IP absente de toute liste de réputation d'IP |
| `LANG` | Code pays de la langue du message (par exemple `ru_RU`) |
| `PTR:[ReverseDNS]` | Enregistrement PTR (DNS inverse) de l'adresse IP source |
| `SCL` | Spam confidence level (échelle ci-dessous) |
| `SFTY` | Marqueur de conseil de sécurité anti-phishing : `9.19` usurpation de domaine, `9.20` usurpation d'utilisateur, `9.25` conseil de sécurité de premier contact |
| `SFV` | Verdict du filtrage antispam (tableau ci-dessous) |
| `SRV:BULK` | Identifié comme bulk par le seuil BCL. Avec `MarkAsSpamBulkMail` activé (par défaut), le courrier en nombre est marqué comme spam au SCL 6 |
| `X-CustomSpam:[ASFOption]` | Correspond à un réglage Advanced Spam Filter (ASF) (heuristiques de contenu comme les balises embed, JavaScript dans le HTML ou un message vide). Le champ est ajouté après l'exécution des règles de flux de messagerie, qui ne peuvent donc pas s'en servir |

### Valeurs de CAT (catégorie)

| Valeur | Signification | Valeur | Signification |
|---|---|---|---|
| `AMP` | Anti-malware | `INTOS` | Phishing interne à l'organisation |
| `BIMP` | Usurpation de marque (MDO) | `MALW` | Logiciel malveillant |
| `BULK` | Bulk | `OSPM` | Spam sortant |
| `DIMP` | Usurpation de domaine (MDO) | `PHSH` | Phishing |
| `FTBP` | Filtre anti-malware des pièces jointes courantes | `SAP` | Safe Attachments (MDO) |
| `GIMP` | Usurpation détectée par la mailbox intelligence (MDO) | `SPM` | Spam |
| `HPHSH` ou `HPHISH` | Phishing à haut niveau de confiance | `SPOOF` | Usurpation d'identité |
| `HSPM` | Spam à haut niveau de confiance | `UIMP` | Usurpation d'utilisateur (MDO) |

### Valeurs de SFV (verdict du filtrage antispam)

| Valeur | Signification |
|---|---|
| `SFV:NSPM` | Marqué comme non-spam ; livré normalement |
| `SFV:SPM` | Marqué comme spam par le filtrage du contenu |
| `SFV:BLK` | Bloqué : l'expéditeur figure dans la liste Blocked Senders de l'utilisateur destinataire (filtrage ignoré) |
| `SFV:SFE` | Autorisé : l'expéditeur figure dans la liste Safe Senders de l'utilisateur destinataire (filtrage ignoré) |
| `SFV:SKA` | Filtrage ignoré : l'expéditeur ou le domaine figure dans la liste d'autorisation de la stratégie antispam ; livré en boîte de réception |
| `SFV:SKB` | Marqué comme spam : l'expéditeur ou le domaine figure dans la liste de blocage de la stratégie antispam |
| `SFV:SKN` | Marqué comme non-spam avant le filtrage (par exemple, une règle de flux de messagerie a fixé SCL -1 ou un contournement) |
| `SFV:SKS` | Marqué comme spam avant le filtrage (par exemple, une règle de flux de messagerie a fixé SCL 5–9) |
| `SFV:SKQ` | Libéré de la quarantaine vers les destinataires prévus |

Comment un consultant les lit : `SKA`, `SFE` et `SKN` signifient que le côté destinataire vous a mis en liste blanche. C'est fragile, car le placement dépend d'une exception et non de la réputation. `SKB` et `BLK` signifient que le côté destinataire vous a bloqué explicitement. Aucun travail de réputation côté expéditeur ne corrige cela ; l'organisation destinataire doit retirer l'entrée.

## SCL : Spam Confidence Level

Le SCL est apposé sous forme d'en-tête X sur chaque message entrant. Le filtrage n'appose jamais les valeurs 2, 3 ou 4. Le SCL 7 est généralement fixé non par le filtrage antispam lui-même, mais par l'évaluation d'analystes, les échecs DMARC ou les règles de flux de messagerie.

| SCL | Définition | Action par défaut |
|---|---|---|
| -1 | Filtrage ignoré (expéditeur ou destinataire sûr, ou liste d'autorisation d'IP) | Boîte de réception |
| 0, 1 | Pas du spam | Boîte de réception |
| 5, 6 | **Spam** | Stratégies par défaut et personnalisées, et stratégie prédéfinie Standard : dossier Courrier indésirable. Stratégie prédéfinie Strict : quarantaine |
| 7, 8, 9 | **Spam à haut niveau de confiance** | Stratégies par défaut et personnalisées : dossier Courrier indésirable. Stratégies prédéfinies Standard et Strict : quarantaine |

## BCL : Bulk Complaint Level

Le BCL est apposé dans l'en-tête `X-Microsoft-Antispam` (par exemple `X-Microsoft-Antispam: BCL:5;`). Microsoft l'attribue, en fonction du comportement de plaintes, aux messages des **expéditeurs en nombre** reconnus (« gray mail »), que leurs sources soient internes ou externes à Microsoft. C'est l'en-tête qui compte le plus pour les ESP, car c'est en pratique le score de réputation de plaintes par expéditeur que publie Microsoft.

| BCL | Signification |
|---|---|
| 0 | Ne provient pas d'un expéditeur en nombre |
| 1–3 | Expéditeur en nombre qui génère **peu** de plaintes |
| 4–7 | Expéditeur en nombre qui génère un nombre **mitigé** de plaintes |
| 8–9 | Expéditeur en nombre qui génère un nombre **élevé** de plaintes |

Seuils et actions (un message est traité comme Bulk lorsque son BCL **atteint ou dépasse** le seuil) :

| Stratégie | Seuil BCL | Action au seuil ou au-delà |
|---|---|---|
| Stratégies antispam par défaut et nouvelles stratégies personnalisées | **7** | Dossier Courrier indésirable |
| Stratégie de sécurité prédéfinie Standard | **6** | Dossier Courrier indésirable |
| Stratégie de sécurité prédéfinie Strict | **5** | Quarantaine |

Ce que cela signifie pour un expéditeur : **un message au BCL ≤ 3 arrive en boîte de réception partout. Un BCL 4 est classé en courrier indésirable par les clients qui utilisent la stratégie prédéfinie Strict (le minimum recommandé pour adhérer à la fonction de dossier Promotions est 5). Un BCL 5–6 est classé en courrier indésirable ou mis en quarantaine par les clients qui utilisent des stratégies prédéfinies. Un BCL ≥ 7 est classé en courrier indésirable par défaut chez tous les clients.** Les administrateurs des destinataires peuvent ajuster le seuil, et voir le volume en nombre de chaque expéditeur dans le « bulk senders insight » du portail Defender.

**Dossier Promotions (préversion, 2026)** : les clients peuvent choisir de livrer le courrier en nombre **sous** le seuil BCL (même le courrier en nombre au BCL 0) dans un dossier Promotions plutôt qu'en boîte de réception. Ils le font avec une règle de flux de messagerie qui appose `X-MS-Exchange-Organization-BulkStamping: 1`, et le réglage « Bulk moves enabled » de la stratégie antispam. Microsoft 365 apprend des utilisateurs qui déplacent des messages vers ce dossier ou hors de celui-ci. Le message arrive tout de même en boîte de réception si l'expéditeur figure dans la liste Safe Senders de l'utilisateur. Pour les expéditeurs, cela signifie que même un courrier en nombre sans plaintes peut cesser d'arriver dans les boîtes de réception Microsoft 365 à cause de son classement, un peu comme avec les onglets de Gmail.

## Authentication-Results et authentification composite

Microsoft appose les résultats standard `spf=`, `dkim=` et `dmarc=` (voir [L'en-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results)), ainsi que des champs propres à Microsoft :

- Les valeurs de `dmarc=` comprennent la valeur non standard **`bestguesspass`** : aucun enregistrement DMARC n'existe, mais le message aurait réussi s'il en existait un.
- `action=` pour DMARC : `oreject` (rejeté selon la politique) ; `pct.quarantine` ou `pct.reject` (échec DMARC, mais livré parce que `pct` < 100 l'a exempté au hasard) ; `permerror` ; `temperror`.
- **`compauth`** est l'authentification composite : le verdict combiné de Microsoft à partir de SPF, DKIM, DMARC et de signaux du message, évalué par rapport au **domaine From (5322.From)**. Un résultat `compauth=fail` ne garantit pas le classement en courrier indésirable si les autres signaux sont bons.
- **`reason`** est un code à trois chiffres qui explique le résultat de compauth :

| Code | Signification |
|---|---|
| 000 | Échec de l'authentification explicite : échec DMARC avec `p=quarantine` ou `p=reject` |
| 001 | Échec de l'authentification implicite : aucun enregistrement d'authentification, ou des enregistrements faibles (SPF `~all` ou `?all`, DMARC `p=none`) |
| 002 | La politique de l'organisation interdit explicitement l'usurpation pour ce couple d'expéditeur et de domaine |
| 010 | Échec DMARC avec reject ou quarantine, et le domaine d'envoi est l'un des domaines acceptés de l'organisation (usurpation interne à l'organisation) |
| 1xx (100–130) | Réussite : 100 SPF ou DKIM réussi avec alignement. 101 DKIM par le domaine From. 102 MAIL FROM et From alignés, et SPF réussi. 103 ou 104 le PTR est aligné sur le domaine From. 108 échec DKIM attribué à un saut antérieur légitime. 109 pas d'enregistrement DMARC, mais le message réussirait. 111 temperror ou permerror DMARC, mais SPF ou DKIM aligné. 112 délai DNS dépassé lors de la résolution DMARC. 115 envoyé depuis une organisation M365 dont le From est un domaine accepté. 116 le MX du domaine From est aligné sur le PTR de l'adresse IP de connexion. 130 un scelleur ARC de confiance a annulé l'échec DMARC |
| 2xx (201, 202) | Réussite partielle sur l'alignement du PTR ou du sous-réseau (`compauth=softpass`) |
| 3xx, 4xx, 9xx | Non vérifié, ou contourné (`compauth=none`) |
| 501, 502 | DMARC non appliqué : un NDR valide avec un contact établi, ou un NDR valide pour les messages de l'organisation elle-même |
| 6xx (601) | Échec de l'authentification implicite ; 601 signifie l'usurpation d'un domaine accepté à l'intérieur de l'organisation |
| 7xx (701–704) | DMARC non appliqué, car l'organisation a un historique de messages légitimes provenant de cette infrastructure |
| 905 | DMARC non appliqué, en raison d'un routage complexe (un saut sur site ou chez un tiers avant M365) |

Le motif 001 est le code que les consultants d'ESP voient le plus souvent. Il signifie que l'expéditeur n'avait **aucune authentification, ou une authentification faible**, et que Microsoft a classé le message en courrier indésirable sur un soupçon issu de l'authentification implicite. La correction consiste à aligner SPF et DKIM, et à publier un enregistrement DMARC. C'est la même correction que pour l'[obligation de mai 2025](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs) d'Outlook.com.

## Tenant Allow/Block List (TABL) : ce que contrôlent les clients destinataires

La TABL est une liste d'exceptions propre à chaque client, à l'adresse `https://security.microsoft.com/tenantAllowBlockList`. Elle s'applique pendant le flux de messagerie et au moment du clic. Les types d'entrées sont : les **domaines et adresses email** (comparés à l'**adresse From (5322.From)**, pas au MAIL FROM), les **expéditeurs usurpés**, les **URL**, les **fichiers**, les **adresses IP** et les domaines Teams. **Les entrées de blocage l'emportent sur les entrées d'autorisation.** Les entrées prennent effet en environ 5 minutes.

Ce que fait un blocage :

| Entité bloquée | Effet |
|---|---|
| Domaine ou adresse email | Le message est traité comme **phishing à haut niveau de confiance** et mis en quarantaine (et pas seulement traité comme spam). Les utilisateurs du client ne peuvent pas non plus lui écrire (`550 5.7.703 ... blocked by your organization using Tenant Allow Block List`) |
| URL ou fichier | Le message est mis en quarantaine comme phishing à haut niveau de confiance ou comme logiciel malveillant, respectivement |
| Adresse IP | Rejeté en bordure du service |
| Expéditeur usurpé | Annulation manuelle d'une autorisation de la spoof intelligence |

Expiration des entrées de blocage : pour les domaines et adresses, les fichiers et les URL, les entrées expirent après **30 jours** par défaut (réglable à 90 jours ou à jamais). Les entrées des expéditeurs usurpés, des adresses IP et de Teams **n'expirent jamais**.

Comment fonctionnent les entrées d'autorisation, et pourquoi « il suffit qu'ils nous mettent en liste blanche » a ses limites :

- Les administrateurs **ne peuvent pas créer directement d'entrées d'autorisation pour des verdicts de logiciel malveillant ou de phishing à haut niveau de confiance**. Pour ceux-ci, le message, l'URL ou le fichier doit être soumis à Microsoft via la page Submissions (`https://security.microsoft.com/reportsubmission`) et confirmé sain ; ce n'est qu'ensuite qu'une entrée d'autorisation peut être créée. Les messages identifiés comme logiciels malveillants ou phishing à haut niveau de confiance sont **toujours filtrés, quelles que soient les entrées d'autorisation**.
- Les entrées d'autorisation directes pour les domaines et adresses, et pour les URL, ne peuvent l'emporter que sur ces verdicts : bulk, spam, spam à haut niveau de confiance, et phishing qui n'est pas à haut niveau de confiance.
- Les entrées d'autorisation pour les domaines et adresses, les fichiers et les URL sont conservées **45 jours après que le système de filtrage a jugé l'entité saine pour la dernière fois**, puis retirées automatiquement (ou l'administrateur les règle pour expirer au plus 30 jours après leur création). Les entrées d'autorisation des expéditeurs usurpés n'expirent jamais. Microsoft peut retirer automatiquement les entrées d'autorisation qu'il juge inutiles, et envoie alors une alerte.
- Un expéditeur autorisé reste soumis au reste de la pile. Le message doit aussi réussir les contrôles d'authentification, d'URL et de fichiers, car une entrée d'autorisation ne dispense que des filtres liés à l'entité autorisée.
- Les autorisations d'URL créées par une soumission couvrent automatiquement les variantes et les sous-chemins de l'URL signalée.

Ce que cela signifie pour un expéditeur : si vos messages reçoivent un verdict de phishing à haut niveau de confiance chez le client d'un de vos clients, l'administrateur du destinataire ne peut pas simplement vous mettre en liste blanche. Les causes habituelles sont une URL ou un domaine **bloqué** dans sa TABL, ou une détection d'usurpation. La voie passe par une soumission de l'administrateur à Microsoft. Demandez à l'administrateur du destinataire de soumettre le message comme faux positif ; l'examen de Microsoft peut créer l'entrée d'autorisation.

## Éléments de la FAQ utiles aux expéditeurs externes

La FAQ antispam de Microsoft documente ces causes lorsque des messages légitimes sont classés en courrier indésirable chez Microsoft 365, ainsi que leurs corrections :

| Cause | Correction |
|---|---|
| Échec d'authentification (SPF, DKIM ou DMARC, qui entraîne un échec compauth) | Corriger SPF, DKIM et DMARC pour le domaine d'envoi |
| Réputation de l'expéditeur (historique de l'adresse IP ou du domaine, listes de blocage, faible volume) | Vérifier les listes de blocage tierces et la présence d'un enregistrement PTR valide, et examiner [SNDS](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp) |
| Déclencheurs de contenu (liens trop nombreux, raccourcisseurs d'URL, balises de formulaire, scripts intégrés, messages composés uniquement d'images) | Revoir le contenu ; le destinataire a peut-être activé des options ASF |
| Le BCL a atteint le seuil du client | Pas du spam, mais un classement en bulk ; réduire les plaintes, ou le destinataire ajuste son seuil ou ses expéditeurs sûrs |
| Exceptions du destinataire (règle de flux de messagerie, liste de blocage d'une stratégie, Blocked Senders de l'utilisateur) | Seul le destinataire peut les retirer |
| Un service de filtrage intermédiaire masque la véritable adresse IP source | Le destinataire active Enhanced Filtering for Connectors (« skip listing ») |

La liste de Microsoft elle-même des meilleures pratiques d'envoi pour atteindre Microsoft 365 :

- Le domaine d'envoi se résout dans le DNS. (**Sans enregistrement A ou MX, les messages passent par le pool à haut risque de Microsoft, quel que soit leur contenu.**)
- L'adresse IP source a un enregistrement PTR.
- HELO ou EHLO et MAIL FROM sont cohérents et fondés sur un domaine, et le HELO correspond à l'enregistrement PTR.
- SPF est correct.
- Les messages sont **signés avec DKIM avec une canonicalisation souple (relaxed)**, car une canonicalisation stricte des en-têtes peut casser lors du transit par le service.
- Les enregistrements WHOIS sont exacts.
- Les rebonds utilisent le format de la RFC 3464.
- Les adresses qui renvoient un NDR pour inexistence sont retirées.
- SNDS est surveillé.

La limitation des envois sortants à l'intérieur du service compte lorsqu'un client compromis envoie par Microsoft. Un utilisateur qui envoie plus de 50 % de spam sur une période donnée se voit interdire l'envoi, et le spam sortant passe par le **pool de livraison à haut risque** (des adresses IP distinctes) pour protéger le pool normal.

## Voir aussi

- [Exigences de Microsoft envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs), sur les politiques d'Outlook.com grand public, les codes d'erreur et l'obligation d'authentification de 2025
- [Canaux d'escalade de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-de-microsoft)
- [Microsoft SNDS et JMRP](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp)
- [L'en-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results), la base RFC 8601 que Microsoft étend

# Les flux de données de délivrabilité de Yahoo

> Les flux de données côté serveur que Yahoo propose aux expéditeurs : le Placement Feed (boîte de réception, spam, dossiers, erreurs, plaintes) et le Campaign Performance Feed (indicateurs d'engagement), avec leurs schémas et leurs délais de mise à disposition.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/flux-de-donnees-de-delivrabilite-de-yahoo

Si vous voulez savoir si vos messages arrivent en boîte de réception ou dans le dossier spam chez Yahoo, sans dépendre de listes de test, les flux de données de Yahoo vous donnent cette réponse. Ils sont le seul moyen direct de voir des données de placement de première main chez ce grand fournisseur de messagerie.

Ces flux rendent compte du placement et de l'engagement des emails **directement à partir des serveurs de messagerie de Yahoo**, et non à partir de pixels de suivi ou de données de listes de test ou de panels. Yahoo présente cette approche comme plus respectueuse de la vie privée que le suivi par pixel, et plus représentative que les sources de panel aux petits échantillons, puisque Yahoo compte des centaines de millions d'utilisateurs actifs.

## Les deux flux

### Placement Feed

Le Placement Feed suit l'endroit où les messages arrivent (boîte de réception, spam, dossiers), ainsi que les erreurs et les plaintes. Les données sont filtrées par une **liste d'autorisation de domaines d'expéditeur ou d'adresses IP d'envoi que fournit l'utilisateur du flux**.

| Dimensions | Indicateurs |
|---|---|
| `dkim_domain`, `sender_domain`, `ip_address`, `xheader`, `xheader_value` | `inbox_delivers`, `spam_delivers`, `folder_delivers`, `error_delivers`, `complaints` |

Les dimensions `xheader` et `xheader_value` permettent à un expéditeur de ventiler les résultats selon un en-tête X personnalisé (par exemple, un identifiant de campagne ajouté aux messages sortants).

### Campaign Performance Feed

Le Campaign Performance Feed mesure l'engagement après la livraison, ventilé par domaine d'expéditeur et par campagne. Il est filtré par une **liste d'autorisation de domaines d'expéditeur**.

| Dimensions | Indicateurs |
|---|---|
| `declared_template_namespace`, `declared_template_id`, `declared_template_goal`, `delivery_type`, `client`, `sender_domain`, `sender_email`, `engagement_date`, `user_local_hour`, `is_scrubbed` | `delivered`, `opened`, `link_clicked`, `deleted`, `marked_read`, `forwarded`, `starred`, `archived`, `moved`, `push_notif_opened`, `replied`, `marked_spam`, `dwell_time_read`, `dwell_time_glance`, `dwell_time_skim` |

Les signaux d'engagement vont loin. Ils comprennent les suppressions, les réponses, les votes spam, les ouvertures de notifications push et des catégories de temps de lecture (lecture, coup d'œil et survol, *read*, *glance* et *skim*). Ce sont les mêmes types de signaux que les fournisseurs de messagerie utilisent en interne pour la réputation (voir [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)).

## Spécifications des flux

| Spécification | Placement Feed | Campaign Performance Feed |
|---|---|---|
| Granularité des rapports | Horaire | Horaire |
| Granularité de la livraison des données | Horaire | Quotidienne |
| Engagement de délai (latence des données) | 12 heures | 48 heures |
| Conservation | 30 jours | 30 jours |
| Format de fichier | Avro | Avro |
| Fuseau horaire | UTC | UTC |
| Filtrage | Liste d'autorisation de domaines d'expéditeur ou d'IP d'envoi | Liste d'autorisation de domaines d'expéditeur |

## Accès

Yahoo ne publie ni tarif, ni critère d'éligibilité formel, ni moyen de s'inscrire soi-même. Écrivez à **mail-questions@yahooinc.com** pour en savoir plus sur le programme et ses conditions d'accès.

## Place dans une démarche de délivrabilité

- **Surveillance du placement** : remplacez ou vérifiez les tests sur liste de test chez Yahoo par de vrais décomptes de placement en boîte de réception et en spam pour chaque domaine et chaque adresse IP. Surveillez `error_delivers` en parallèle de vos journaux SMTP (voir [Codes d'erreur SMTP de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/codes-d-erreur-smtp-de-yahoo)).
- **Suivi du taux de plaintes** : `complaints` divisé par `inbox_delivers` donne une approximation du taux que Yahoo compare à son **seuil de 0,3 %** ([Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs)). Combinez-le avec la suppression des destinataires un par un grâce à la [feedback loop de plaintes](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/feedback-loop-de-plaintes-de-yahoo).
- **Optimisation de l'engagement** : les indicateurs de temps de lecture et d'action (suppressions comparées aux lectures, `user_local_hour`) aident à décider du contenu, de la segmentation et de l'heure d'envoi pour chaque campagne ou chaque modèle.
- **Comparaison des flux** : les dimensions `dkim_domain` et `ip_address` montrent les performances de flux de messages séparés les uns par rapport aux autres (voir [Segmentation avancée des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip)).

## Voir aussi

- [Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs)
- [La feedback loop de plaintes de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/feedback-loop-de-plaintes-de-yahoo)
- [Codes d'erreur SMTP de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/codes-d-erreur-smtp-de-yahoo)

# Allocation de base des adresses IP

> Combien d'adresses IP d'envoi utiliser, selon le volume quotidien, pour un flux d'emails unique et homogène.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip

Lorsque vous mettez en place un nouveau serveur de messagerie, vous devez vite décider depuis combien d'adresses IP envoyer. La réponse dépend de la quantité d'emails que vous envoyez chaque jour, et utiliser plus d'adresses que votre volume ne le permet peut nuire à votre réputation.

## À qui s'adressent ces recommandations

Les chiffres ci-dessous supposent que tous vos emails sont **d'un seul type** : vous n'avez donc aucune raison de maintenir des réputations séparées sur des adresses IP séparées. Si vous avez besoin de cette séparation, commencez par [Segmentation et allocation avancées des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip).

Ils supposent aussi que votre objectif est de livrer des emails que les destinataires **désirent** et **attendent**. Pour des emails que les destinataires ne désirent pas ou n'attendent pas, suivre ces recommandations peut faire baisser la livraison au lieu de l'améliorer, selon les circonstances.

## Nombre d'adresses IP selon le volume quotidien

GreenArrow, un éditeur de logiciels de serveur de messagerie, dimensionne ainsi le nombre d'adresses IP d'envoi :

| Volume quotidien de messages | Adresses IP |
|---|---|
| Moins de 40 000 | Une |
| De 40 000 à 200 000 | Deux |
| Plus de 200 000 | Assez pour que chaque adresse envoie de 100 000 à 1 000 000 messages par jour |

## Trop d'adresses ressemblent à du snowshoeing

Les spammeurs emploient une technique appelée **snowshoeing**. Ils étalent leur volume en couches minces sur un grand nombre d'adresses IP, pour qu'aucune adresse n'envoie assez d'emails pour attirer l'attention. Les fournisseurs de messagerie connaissent ce schéma. Quand un expéditeur utilise beaucoup d'adresses pour la quantité d'emails qu'il envoie, ils le pénalisent.

Si vous avez réparti vos envois sur de nombreuses adresses, et que votre taux de plaintes est très élevé ou votre engagement faible, lisez [Les deux mondes de la délivrabilité email](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email) avant de regrouper vos envois sur moins d'adresses.

## Trop peu d'emails sur chaque adresse

Maintenez chaque adresse IP au-dessus de **40 000 messages par semaine**. Les fournisseurs de messagerie jugent une adresse d'après l'engagement et les plaintes que suscitent ses emails. En dessous de ce volume, ils en voient trop peu pour que ces chiffres soient statistiquement significatifs.

Ce chiffre est le plancher général, valable pour n'importe quelle adresse. Une adresse IP dédiée à l'email transactionnel peut se justifier à un volume plus faible, et chaque fournisseur de services de messagerie (ESP) fixe son propre minimum. Le [tableau des seuils de volume pour adresse IP dédiée](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi#dedicated-ip-volume-floors-canonical) compare ces chiffres.

## Voir aussi

- [Segmentation et allocation avancées des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip)
- [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)

# Recommandations pour la chauffe d'IP

> Pourquoi les nouvelles adresses IP d'envoi doivent être chauffées, à quoi s'attendre, et un calendrier de montée en charge concret (volume, rythme, choix de l'audience).

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip

## Ce que supposent ces recommandations

Le calendrier ci-dessous est conçu pour les expéditeurs dont les destinataires **désirent** et **attendent** les emails. Pour des emails que les destinataires n'ont pas demandés ou ne reconnaissent pas, l'appliquer peut laisser votre délivrabilité en moins bon état qu'une autre approche. [Les deux mondes de la délivrabilité email](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email) en donne la raison.

## Pourquoi une chauffe est nécessaire

Un fournisseur de messagerie n'a aucun historique pour une adresse IP qui n'a jamais envoyé d'emails, donc aucune raison de lui faire confiance. Chauffer une adresse, c'est augmenter le volume pas à pas jusqu'à ce que les fournisseurs aient vu assez de bons emails venant d'elle pour lui accorder une réputation : la crédibilité qui laisse passer les campagnes suivantes.

Le point de départ est pire qu'une page blanche. D'après GreenArrow, 99 fois sur 100, une adresse IP qui devient active appartient à un spammeur bloqué ailleurs qui a changé d'adresse. Les fournisseurs regardent donc une nouvelle adresse avec une grande méfiance, et votre réputation démarre un peu en dessous de la neutralité.

Les fournisseurs plafonnent aussi la quantité d'emails qu'ils acceptent d'une même adresse IP. Pour franchir ce plafond, commencez par de petits volumes, montrez un bon comportement à ce niveau, et n'envoyez davantage qu'ensuite.

## À quoi s'attendre

Les premières campagnes ne donneront pas vos meilleurs résultats. GreenArrow constate que dans environ 75 % des cas, la première campagne envoyée depuis une nouvelle adresse IP est classée dans le dossier spam de Gmail.

Un classement en spam pendant les premiers jours est normal et n'a rien d'inquiétant. Les fournisseurs apprennent de la réaction des destinataires : de bons emails obtiennent un meilleur placement à mesure que la chauffe avance.

## Que faire

### 1. Décider du nombre d'adresses IP et de leur segmentation

[Allocation de base des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip) et [Segmentation et allocation avancées des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip) expliquent combien d'adresses IP utiliser et comment répartir vos emails entre elles.

Donnez à l'email transactionnel une adresse IP dédiée au lieu de la partager avec l'email marketing.

Lorsque la chauffe porte sur plusieurs adresses IP, mettez-les en service par étapes : commencez avec **trois**, puis ajoutez-en une tous les **trois jours**. Un grand groupe d'adresses qui se mettent toutes à envoyer le même jour est un schéma que les fournisseurs jugent très suspect.

### 2. Augmenter le volume, mais commencer par vos meilleures données

- Au départ, visez à peu près **5 000 messages quotidiens par adresse IP et par fournisseur de messagerie**. Le plus gros fournisseur pesant d'ordinaire près de 25 % d'une liste, on arrive à environ **20 000 messages quotidiens par adresse IP**, tous fournisseurs confondus.
- Faites progresser le volume de **50 % par semaine**, sous deux conditions :
  - les fournisseurs prennent vos emails sans taux élevés de reports de remise ou d'échecs, et
  - vous avez envoyé régulièrement. Une semaine sans le moindre envoi n'entre pas dans le calcul de la chauffe.
- Adressez-vous en priorité aux destinataires les plus enclins à réagir, c'est-à-dire ceux qui **ont dernièrement ouvert l'un de vos emails ou cliqué dedans**. Face à la méfiance que les fournisseurs ont par principe envers une adresse IP neuve, rien ne vaut votre meilleur contenu envoyé à vos destinataires les plus engagés.
- Si ces ouvertures et clics récents ne vous permettent pas d'atteindre 20 000 messages quotidiens (ou 5 000 quotidiens par fournisseur) sur chacune des nouvelles adresses IP, **réduisez le nombre d'adresses IP** : chacune conservera ainsi un volume sain.

> **Ces chiffres face aux autres sources.** Tous les chiffres précis donnés plus haut proviennent d'un seul éditeur, GreenArrow : un départ à ≈5 000 quotidiens par fournisseur, une progression de +50 % par semaine, trois adresses IP pour commencer puis une supplémentaire tous les trois jours, et ≈75 % de premières campagnes classées en spam chez Gmail. Ils précèdent aussi l'entrée en vigueur, en février 2024, des exigences de [Gmail](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs) et de [Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs) envers les expéditeurs de gros volumes. Or 5 000 messages quotidiens par fournisseur, c'est pile le seuil (5 000 messages par jour) à partir duquel Gmail range un expéditeur parmi les « expéditeurs de gros volumes ». Une chauffe menée à ce niveau doit donc, dès son premier jour, remplir les exigences d'authentification (SPF, DKIM, DMARC), proposer le désabonnement en un clic (list-unsubscribe) et maintenir le taux de spam sous le plafond de <0,3 %. Les autres sources partagent le principe général de la chauffe, avec des chiffres différents :
> - **AWS SES** recommande de se construire une réputation positive en **deux à six semaines environ, fournisseur par fournisseur**, en commençant par vos utilisateurs les plus engagés, avant de se maintenir vers **~1 000 messages quotidiens par fournisseur** pour préserver cette réputation. Quel que soit le volume, sa chauffe automatique s'étend sur **45 jours**. ([documentation](https://docs.aws.amazon.com/ses/latest/dg/dedicated-ip-warming.html))
> - **Twilio SendGrid** conseille un départ nettement plus modeste, de **~50 messages le premier jour**, puis de **multiplier le volume par deux environ à chaque journée d'envoi** jusqu'au volume visé, ce qui demande en général **4 à 6 semaines**. ([documentation](https://www.twilio.com/docs/sendgrid/concepts/reputation/warm-up-ip-addresses))
>
> Voyez dans le calendrier de GreenArrow une option raisonnable, située du côté offensif, et non une règle universelle. Confrontez le volume initial et la progression hebdomadaire aux consignes en vigueur de votre ESP ainsi qu'à un [suivi en direct du placement en boîte de réception](#4-surveiller-le-placement-en-boîte-de-réception), et levez le pied au premier signe de reports de remise ou de classement en spam.

### 3. Limiter le débit d'envoi

Maîtrisez le rythme auquel les emails entrent dans votre MTA. Durant la chauffe, étalez l'envoi de chaque journée sur **quatre heures au minimum**, voire sur **huit heures** quand c'est possible, sachant que certaines entreprises ne peuvent pas se permettre d'attendre autant.

Plateformes d'envoi et MTA offrent presque tous, à cet effet, un paramètre de vitesse de campagne, aussi appelé débit d'injection. À 5 000 messages par heure, par exemple, un envoi de 20 000 messages s'étale sur quatre heures. Accélérez progressivement au cours de la chauffe.

### 4. Surveiller le placement en boîte de réception

Pendant toute la chauffe, suivez chaque campagne avec un outil de mesure du placement en boîte de réception ou de liste de test (seed list). Vous voyez ainsi, fournisseur par fournisseur, si les emails parviennent en boîte de réception ou dans le dossier spam, et donc à quel moment augmenter le volume.

## Voir aussi

- [Allocation de base des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip)
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)
- [Segmentation et allocation avancées des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip)

# Segmentation et allocation avancées des adresses IP

> Segmenter les flux d'emails en zones de réputation : isoler l'email transactionnel du marketing, regrouper par qualité et dimensionner le nombre d'adresses IP selon le volume.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip

Si vous envoyez plusieurs types d'emails, la façon dont vous les répartissez entre vos adresses IP détermine si un problème sur un type peut nuire aux autres. Deux questions guident le plan :

1. Quels emails ont besoin d'une **réputation propre**, et donc de leurs propres adresses IP ?
2. Quel **volume** chaque groupe envoie-t-il ?

Lorsque tous vos emails sont d'un seul type et que rien ne doit être tenu à part, [Allocation de base des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip) suffit.

## Hypothèses

Les conseils qui suivent visent à livrer des emails que les destinataires **désirent** et **attendent**. Appliqués à des emails que les destinataires ne désirent pas ou n'attendent pas, ils peuvent au contraire faire baisser la livraison, selon les circonstances.

## Les quatre étapes

1. Donner à l'**email transactionnel une adresse IP qui lui est propre**, à l'écart de l'email marketing.
2. Recenser les **flux d'emails** (*Mail Streams*) que vous envoyez.
3. Regrouper ou scinder ces flux en **zones de réputation** (*Reputation Realms*).
4. Fixer le **nombre d'adresses IP** de chaque zone d'après son volume.

## Deux termes

- **Flux d'emails** (*Mail Stream*) : une catégorie d'emails qui se distingue de vos autres emails à la fois par son contenu et par sa liste de destinataires. Un fournisseur de services de messagerie (ESP) a un flux par client. Une entreprise dont les unités commerciales envoient des emails sans lien entre eux à des listes sans lien entre elles a un flux par unité. La plupart des expéditeurs n'ont qu'un flux, par exemple leur newsletter.
- **Zone de réputation** (*Reputation Realm*) : un ensemble d'adresses IP, de noms de domaine ou des deux, dont la réputation est tenue à l'écart de celle de toutes les autres zones. Les zones existent pour que les emails d'une zone ne puissent pas faire bloquer ceux d'une autre zone.

## Étape 1 : isoler l'email transactionnel

L'email transactionnel désigne tout message que le destinataire déclenche par sa propre action, comme une confirmation de commande ou une réinitialisation de mot de passe.

Les destinataires guettent ces messages : ce sont donc les emails les mieux délivrés que vous envoyez. Sur une adresse IP qui lui est propre, l'email transactionnel est à l'abri des problèmes que causent vos autres emails.

Une adresse dédiée a besoin d'un volume suffisant pour tenir. GreenArrow, un éditeur de logiciels de serveur de messagerie, fixe le minimum à **1 000 messages par jour**. En dessous, beaucoup d'expéditeurs font plutôt passer l'email transactionnel par un pool d'adresses IP partagées bien géré. Le [tableau des seuils de volume pour adresse IP dédiée](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi#dedicated-ip-volume-floors-canonical) compare ce seuil au plancher général valable pour toute adresse et aux minimums que fixent les ESP.

## Étape 2 : recenser vos flux d'emails

Le plus souvent, il n'y en a qu'un. Un ESP devrait traiter chaque client comme un flux distinct.

Pour décider si deux types d'emails forment vraiment des flux distincts, imaginez le regard d'une personne extérieure. Un filtre anti-spam, ou un chercheur qui étudie vos emails, devrait y voir une différence nette. S'il conclut qu'il s'agit du même courrier sous un autre emballage, c'est un seul flux.

## Étape 3 : former les zones de réputation

Aucune règle ne tranche cette étape. Elle demande du jugement.

### Ce qu'une zone isole

Une zone fonctionne comme un pare-feu. Quand un groupe d'emails rencontre des difficultés, les autres groupes gardent leur propre réputation et leurs emails continuent d'arriver.

Des adresses IP séparées sont le moyen habituel de bâtir ce pare-feu. Les serveurs de réception rattachent toutefois la réputation à d'autres éléments que l'adresse d'envoi. Pour une séparation plus solide, donnez aussi à chaque zone sa propre valeur pour les éléments ci-dessous, classés du plus important au moins important :

1. Le domaine de vos liens de suivi des ouvertures et des clics
2. L'adresse IP vers laquelle pointe le domaine de suivi
3. Le domaine Return-Path
4. Le domaine présent dans les noms DNS inverse de vos adresses IP d'envoi. Ne changez celui-ci que si vous avez besoin de la séparation la plus forte possible. Beaucoup de domaines différents dans le DNS inverse ressemblent à du « domain snowshoeing », une technique de spammeur, et des emails qui ne font que ressembler à du spam peuvent être bloqués.

Changer les seuls éléments 1 et 2 rend déjà le pare-feu bien plus solide.

### Séparer les emails par qualité

Beaucoup d'expéditeurs créent une zone « haute qualité » et une zone « basse qualité », ou plusieurs zones échelonnées par niveau de qualité. La qualité combine ici :

- **Permission** : des pratiques plus strictes, comme l'opt-in confirmé, classent plus haut.
- **Engagement** : plus d'ouvertures en boîte de réception, et plus d'abonnés engagés récemment, classent plus haut.
- **Plaintes** : un taux de plaintes plus bas classe plus haut.
- **Contenu** : les sujets fréquents dans le spam, comme la perte de poids, les conseils boursiers et les pharmacies en ligne, classent plus bas.

Garder ensemble les emails de qualité voisine empêche les emails les plus faibles de faire bloquer les plus solides. Selon les circonstances, une plus grande part de vos emails peut alors atteindre la boîte de réception que s'ils partageaient tous une seule zone. Pour un ESP, cela signifie que les clients aux mauvaises pratiques ne peuvent pas faire bloquer les clients aux bonnes pratiques. Les Sender Best Common Practices du M3AAWG (version 4.0, août 2026) font la même remarque pour les adresses IP partagées : les expéditeurs qui partagent un pool devraient avoir un contenu, des taux de plaintes et des taux de rebonds semblables.

### Mélanger des emails de qualité différente dans une même zone

L'approche inverse place un gros volume d'emails solides et un volume plus faible d'emails moins bons dans la même zone.

Quand les proportions et la qualité sont justes, les emails plus faibles sont mieux livrés grâce aux plus solides, et ceux-ci n'y perdent rien. Quand les emails plus faibles sont trop mauvais, ou représentent une part trop grande, la livraison des emails solides baisse. Cette approche ne marche qu'avec une surveillance étroite et une planification soigneuse.

### Scinder un flux d'emails par qualité

Vous pouvez aussi scinder un flux unique, avec ses meilleurs segments dans une zone et ses segments plus faibles dans une autre. Façons courantes de le scinder :

- Selon l'endroit où l'adresse de chaque abonné a été recueillie
- Selon l'activité récente, avec dans le groupe de haute qualité les personnes qui ont récemment ouvert, cliqué ou se sont inscrites

### Utiliser plusieurs zones pour la seule séparation

Il arrive que vous ne puissiez pas dire quels flux sont solides et lesquels sont faibles. Vous pouvez tout de même les répartir entre plusieurs zones, pour que toute votre réputation ne dépende pas d'une seule. Si un flux tourne ensuite très mal, les dégâts restent enfermés dans sa zone.

## Étape 4 : dimensionner chaque zone selon le volume

GreenArrow dimensionne le nombre d'adresses IP d'une zone d'après son volume quotidien :

| Volume quotidien de messages | Adresses IP |
|---|---|
| Moins de 40 000 | Une |
| De 40 000 à 200 000 | Deux |
| Plus de 200 000 | Assez pour que chaque adresse envoie de 100 000 à 1 000 000 messages par jour |

Si vous scindez un flux d'emails entre plusieurs zones, ces zones réunies ne doivent pas utiliser plus d'adresses IP que le tableau n'en donne pour le flux pris dans son ensemble.

### Éviter d'utiliser trop d'adresses

Le snowshoeing est une technique de spam qui étale le volume sur de nombreuses adresses IP, pour que chaque adresse reste trop petite pour être remarquée. Les fournisseurs de messagerie le traquent, et ils pénalisent les expéditeurs qui utilisent beaucoup d'adresses pour le volume qu'ils envoient.

Si vous avez réparti vos envois de cette manière, et que votre taux de plaintes est très élevé ou votre engagement faible, lisez [Les deux mondes de la délivrabilité email](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email) avant de regrouper vos envois sur moins d'adresses.

### Garder assez de volume dans chaque zone

Chaque zone de réputation devrait envoyer au moins **40 000 messages par semaine**. En dessous, les fournisseurs de messagerie voient trop peu de ses emails pour tirer des conclusions statistiquement significatives sur l'engagement et les plaintes.

## Voir aussi

- [Allocation de base des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip)
- [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)
- [Les deux mondes de la délivrabilité email](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email)

# Feedback loops de plaintes (RFC 6449)

> Comment fonctionnent les feedback loops (FBL) des fournisseurs de messagerie : structure des rapports ARF, inscription et contrôle, et recommandations opérationnelles pour les fournisseurs de feedback et les expéditeurs.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes

Quand un destinataire clique sur « Signaler comme spam » dans votre message, une feedback loop (FBL) peut vous envoyer un rapport de cette plainte, pour que vous cessiez d'écrire à cette personne et que vous compreniez ce qui n'a pas fonctionné. Les plaintes sont l'un des principaux signaux de réputation que mesurent les fournisseurs de messagerie (voir [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)), et une FBL vous donne un accès direct à ce signal.

La RFC 6449, « Complaint Feedback Loop Operational Recommendations », décrit comment les fournisseurs de messagerie transmettent ces plaintes aux expéditeurs. Son objectif déclaré est de « fournir aux consommateurs de feedback les informations nécessaires pour réduire le spam ou la perception de spam ».

## Terminologie

| Terme | Signification |
|---|---|
| **Spam** (dans le contexte des FBL) | Tout message dont le destinataire choisit de se plaindre, quelle que soit l'intention de son auteur |
| **Fournisseur de feedback** (Feedback Provider) | L'organisation qui envoie les rapports de plaintes, en général un fournisseur de messagerie |
| **Consommateur de feedback** (Feedback Consumer) | L'organisation qui reçoit les rapports : l'expéditeur du message, ou un ESP ou un FAI qui agit pour son compte |
| **ARF** | Abuse Reporting Format, le format de rapport normalisé (RFC 5965) |

## Comment une plainte devient un rapport

1. L'utilisateur clique sur « Signaler comme spam » (Report Spam) dans l'interface webmail ou dans le client de messagerie du fournisseur. Si le fournisseur ne propose pas un tel bouton, une FBL efficace est pratiquement impossible.
2. Le fournisseur rattache le message à un consommateur de feedback inscrit. Il utilise traditionnellement l'**adresse IP du dernier saut** qui lui a remis le message, et de plus en plus souvent le **domaine DKIM `d=`**.
3. Un rapport ARF est généré et envoyé **immédiatement, sans examen**, si bien que le consommateur le reçoit presque en temps réel.

### Routage des FBL par domaine DKIM ou par adresse IP

Une même valeur DKIM `d=` peut couvrir de nombreux serveurs et adresses IP, et vous pouvez ajouter ou retirer des serveurs sans modifier l'inscription à la FBL (« lorsqu'une feedback loop utilise DKIM, aucune reconfiguration n'est nécessaire, car le domaine signataire ne change pas »). Les FBL fondées sur les adresses IP doivent être mises à jour à chaque modification de l'infrastructure d'envoi. Privilégiez l'inscription par domaine DKIM lorsque le fournisseur la propose. Elle se combine aussi naturellement avec l'[alignement DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) et avec des domaines de signature distincts pour chaque flux (voir [Segmentation et allocation avancées des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip)).

Le fonctionnement de l'inscription, selon la page de ressources FBL du M3AAWG : l'inscription par domaine exige que le courrier soit signé avec DKIM, et demande à la fois le domaine signataire (la valeur `d=`) **et le sélecteur (la valeur `s=`)** de la signature DKIM. Le sélecteur utilisé sur le courrier de production doit donc être connu et stable au moment de l'inscription.

Les FBL agrégées fonctionnent différemment. Elles totalisent les nombres de plaintes par adresse IP, par domaine **ou par un identifiant choisi par l'expéditeur**, qui est le modèle que Gmail met en œuvre avec l'en-tête `Feedback-ID` (voir [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools)). L'annuaire des pages d'inscription de chaque fournisseur est tenu à jour dans [Index des documents M3AAWG et écosystème des FBL](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/index-des-documents-m3aawg). La plupart des FBL traditionnelles passent par la Universal Feedback Loop de Validity, sur fbl.validity.com.

## Structure d'un rapport ARF (RFC 5965)

Un message ARF est un message MIME `multipart/report` en trois parties :

| Partie | Contenu |
|---|---|
| 1. Texte destiné aux personnes | Un texte type qui explique le rapport, et les coordonnées du fournisseur |
| 2. Métadonnées destinées aux machines (`message/feedback-report`) | La version du protocole, le type de rapport (`abuse`, `fraud`, …), l'expéditeur d'enveloppe (facultatif) et l'heure de réception du message |
| 3. Message d'origine (`message/rfc822`) | Une copie de l'email signalé. Elle est souvent **caviardée**, en particulier l'adresse du destinataire, pour des raisons de vie privée ou juridiques |

Comme l'adresse du destinataire est souvent caviardée, les expéditeurs **ne peuvent pas se fier à l'adresse To:** du message renvoyé pour identifier qui s'est plaint (voir Automatisation ci-dessous).

## Recommandations pour les fournisseurs de feedback (fournisseurs de messagerie)

- **Candidature et contrôle :** gardez la procédure de candidature simple, et vérifiez que le candidat est habilité pour les adresses IP ou les domaines qu'il revendique. Vérifiez la propriété des adresses IP par l'ASN d'origine, les enregistrements WHOIS ou RWHOIS et le DNS inverse. Vérifiez les contacts par un message de confirmation envoyé à `abuse@` ou à `postmaster@`.
- **Refus :** vous pouvez refuser une candidature lorsque le candidat semble s'inscrire sous un faux prétexte pour contourner les politiques de livraison, ou qu'il est déjà bloqué pour mauvaise réputation. Maintenez une procédure de recours documentée et transparente.
- **Contenu des rapports :** incluez une adresse de contact pour les questions (idéalement une adresse reliée à un système de tickets). Vous pouvez aussi inclure des statistiques de livraison résumées (volume, taux de placement en boîte de réception, adresses pièges touchées).
- **Maintenance continue :** revérifiez régulièrement les consommateurs inscrits au regard des critères en vigueur, et vérifiez que les adresses qui reçoivent les rapports fonctionnent toujours.
- **Vie privée :** les données des rapports ne doivent pas être transmises au-delà du destinataire approuvé, et tout usage abusif justifie une résiliation immédiate. Les FBL franchissent les frontières, si bien que c'est le droit local de la protection des données qui détermine ce qui peut être caviardé ou partagé. L'adresse email et l'adresse IP du destinataire qui a signalé le message sont les éléments habituellement caviardés.
- **Les conditions d'utilisation** devraient préciser les obligations de confidentialité, l'obligation de tenir les contacts à jour, le fait que l'accès à une FBL n'accorde **aucun privilège d'envoi particulier**, et le fait que l'inscription est un privilège qui peut être retiré à tout moment et pour tout motif.
- **Les FBL non sollicitées** (l'envoi de rapports à des expéditeurs qui ne se sont pas inscrits) restent débattues. Si vous en envoyez, ne les envoyez qu'à des fournisseurs de messagerie ou d'accès, seulement après avoir tenté un contact normal, et uniquement aux adresses abuse publiées dans le WHOIS. Des consommateurs qui ne sont pas préparés peuvent être incapables de gérer le volume ou le format.

## Recommandations pour les expéditeurs (consommateurs de feedback)

### Avant l'inscription

- Des adresses de rôle qui fonctionnent : `abuse@`, `postmaster@`.
- Une adresse dédiée à la réception des rapports de FBL.
- La preuve que vous êtes propriétaire de vos adresses IP : un DNS inverse et des enregistrements WHOIS corrects.
- Des contacts nommés et des points d'escalade.

### Traiter chaque plainte

- **Traitez une plainte comme un désabonnement.** Assurez-vous qu'aucun autre message de cette liste n'atteint ce destinataire : retirez l'adresse, ou ajoutez-la à la liste de suppression.
- **L'étendue de la suppression** relève du discernement, et l'objectif est de réduire les plaintes futures. Placer l'adresse en suppression pour tout un ESP est probablement trop large. La placer en suppression sur toutes les listes segmentées d'un même client est probablement le bon niveau.
- **L'exception transactionnelle :** la bonne décision est parfois d'ignorer le rapport. Par exemple, un client qui signale ses propres billets d'avion comme spam a toujours besoin des billets restants. Placez en suppression le courrier marketing, pas le flux transactionnel (c'est une raison de garder le courrier transactionnel séparé ; voir [Segmentation et allocation avancées des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip)).

### Mesurer correctement le taux de plaintes

La RFC 6449 signale plusieurs pièges de calcul :

- **Le jour de lecture, pas le jour d'envoi :** les plaintes sont comptées le jour où l'utilisateur a lu le message. Un expéditeur qui envoie du lundi au vendredi voit un « taux » gonflé le samedi, car les plaintes sont divisées par un nombre d'envois minuscule, voire nul.
- **La boîte de réception comme dénominateur :** les fournisseurs divisent généralement les plaintes par le nombre de messages **livrés en boîte de réception**, et non par le nombre de messages envoyés. Pour un expéditeur dont 500 messages sur 10 000 arrivent en boîte de réception (9 500 dans le dossier spam), les plaintes sont divisées par 500. Une mauvaise réputation dégrade donc encore davantage le taux mesuré.
- La RFC donne un ordre de grandeur : 10 rapports par jour peuvent signaler de graves problèmes chez un petit expéditeur, mais être un bruit de fond normal chez un expéditeur qui envoie 300 000 messages par mois. Elle cite un **taux de plaintes de 2 %** comme pouvant justifier un blocage immédiat. Les seuils actuels des fournisseurs sont bien plus stricts : Gmail demande moins de 0,1 %.
- **Suivez les tendances, pas seulement les nombres.** Les FAI devraient suivre chaque jour les plaintes par client ou par adresse IP, car un pic soudain suggère l'inscription d'un spammeur ou un système compromis. Les ESP devraient ventiler les plaintes par client, par liste et par campagne, et utiliser le taux (les plaintes divisées par les messages envoyés) plutôt que des nombres absolus.

### Automatisation

- **Les petits consommateurs** (listes de quelques milliers d'adresses) n'ont besoin que de peu ou pas d'automatisation, car les rapports ARF se lisent dans un client de messagerie. Un filtre simple qui ajoute l'adresse IP signalée à la ligne d'objet rend les tendances visibles quand vous triez.
- **Les grands consommateurs** doivent extraire de chaque rapport le destinataire qui s'est plaint, le fournisseur de messagerie qui a envoyé le rapport, le client responsable (pour les ESP), les identifiants de campagne et de liste, et éventuellement l'adresse IP source et le DKIM `d=`.
- **Comme l'adresse du destinataire est souvent caviardée**, placez les identifiants du destinataire et de la campagne dans le message lui-même, à un endroit que le traitement des FBL ne supprimera pas. Les options sont des clés primaires de base de données (opaques, mais il faut un accès à la base), des valeurs chiffrées (il faut un déchiffrement automatisé), ou un encodage dans le Message-ID. Par exemple, `esp-423-27-42460@example.com` est opaque pour les tiers, mais l'expéditeur peut l'analyser.
- **Réutilisez la chaîne de traitement des rebonds.** Si l'identifiant se convertit au même format que la chaîne VERP utilisée pour le traitement des rebonds, le processeur de FBL peut créer un « faux » rebond définitif et le transmettre au processeur de rebonds existant, qui place l'adresse en suppression (voir [Delivery Status Notifications](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison)).
- Les FAI qui consomment des rapports ont surtout besoin de l'adresse IP source et du client responsable. L'adresse IP figure généralement dans les métadonnées ARF, et sinon dans les en-têtes Received.

## Sécurité

Le fournisseur doit s'assurer que les rapports ne sont envoyés qu'aux consommateurs autorisés, et doit établir l'identité de l'expéditeur à partir de l'adresse IP qui se connecte ou du domaine de signature DKIM, « deux éléments difficiles à falsifier ». Cela empêche les spammeurs de s'inscrire pour des réseaux qui ne leur appartiennent pas afin de récolter des adresses et des données privées dans les rapports.

## Voir aussi

- [List-Unsubscribe et désabonnement en un clic](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic), qui permet aux utilisateurs de quitter une liste plutôt que de se plaindre
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)

# Intégrité de l'acquisition des adresses : collecte légitime ou collecte sauvage

> L'intégrité de l'acquisition dans la constitution des listes : le socle de l'opt-in confirmé selon Spamhaus, les métadonnées d'acquisition que chaque adresse devrait porter, et pourquoi les logiciels de collecte d'adresses (illégaux en Australie, en Nouvelle-Zélande, au Canada et ailleurs) et les listes achetées, enrichies ou issues de co-inscription sont la cause première d'une mauvaise qualité de liste.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/gestion-des-listes/integrite-de-l-acquisition-des-adresses

La façon dont une adresse est entrée dans votre liste détermine, plus que tout autre facteur, si son titulaire s'engagera avec vos messages ou s'en plaindra. La question est ici de savoir si chaque adresse a été obtenue par une méthode que vous pouvez assumer, et si vous pouvez le prouver.

Cela suppose de traiter l'acquisition comme un processus que vous documentez et auditez, de connaître les techniques de collecte illégitimes, et de savoir pourquoi plusieurs d'entre elles sont aussi illégales en elles-mêmes, à commencer par les logiciels de collecte d'adresses. [Méthodes de consentement et spectre de qualité des listes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement) examine les mêmes adresses sous un autre angle : le type de permission que porte chacune. Il classe les huit méthodes de consentement par qualité et décrit leurs profils de plaintes.

## Le socle : opt-in confirmé et preuve

Le guide de Spamhaus « Address Acquisition for Mailing Lists: The Basics » fixe le minimum d'une collecte légitime à l'**opt-in confirmé (COI, aussi appelé double opt-in)**. Le contact prend la décision volontaire et active de recevoir du courrier, et la confirme en cliquant sur un lien dans un email avant que l'adresse ne reçoive la moindre campagne. Spamhaus associe ces exigences à une inscription défendable :

- **Choix volontaire et actif** : pas de cases précochées. C'est le contact qui accomplit l'action.
- **Inscription transparente** : le contact sait à qui il s'abonne et ce qu'il recevra.
- **Protection des formulaires web** : un CAPTCHA ou un reCAPTCHA sur le formulaire, pour contenir les soumissions automatisées et malveillantes (la même défense que celle décrite dans [Bombardement d'inscriptions](https://emailmarketing.net/learn/esp-operations/subscription-bombing)).
- **Confirmation active par email** : le clic COI, qui bloque aussi les fautes de frappe et les [adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges), car une adresse piège ne peut jamais confirmer.

<a id="acquisition-metadata-to-capture-at-signup"></a>

### Métadonnées d'acquisition à enregistrer lors de l'inscription

La légitimité n'est utile que si vous pouvez la **prouver** plus tard. Spamhaus recommande de stocker au minimum les informations suivantes pour chaque adresse :

| Champ | Pourquoi c'est important |
|---|---|
| **Date et heure d'inscription en UTC** | Montre quand le consentement a été donné, et fixe le calendrier de la mise en sommeil et de la nouvelle demande de permission |
| **Canal ou source d'acquisition** | Permet d'isoler et de mettre en quarantaine une source défaillante lorsque les plaintes ou les adresses pièges touchées augmentent brusquement |
| **Adresse IP de soumission** | Preuve d'une soumission réelle. Distingue les inscriptions naturelles des injections en masse |

Cet enregistrement est ce que vous présentez à un **opérateur de liste de blocage lors d'un litige de retrait de liste**, et ce sur quoi vous vous appuyez pour répondre à une **demande d'effacement ou d'opposition au titre du RGPD** (voir [Droit d'opposition et effacement](https://emailmarketing.net/fr/apprendre/conformite/droit-d-opposition-et-droit-a-l-effacement)). Sans enregistrement d'acquisition, vous n'avez en pratique aucun consentement défendable. Les [meilleures pratiques M3AAWG pour les expéditeurs](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs) décrivent la même conservation des preuves de consentement.

Le consentement suit l'adresse, pas la personne. La version 4.0 de ces meilleures pratiques (août 2026) indique que, lorsque des abonnés changent l'adresse enregistrée, la nouvelle adresse devrait être confirmée de la même façon qu'une nouvelle inscription.

<a id="the-core-principle-consent-is-not-transferable"></a>

## Le principe central : le consentement n'est pas transférable

Toutes les méthodes illégitimes ci-dessous échouent au même test : **une permission donnée à une partie ne se transfère pas à une autre.** Un contact qui a accepté d'avoir des nouvelles de l'entreprise A n'a pas pour autant accepté d'en avoir de l'entreprise B, de ses « partenaires » ou de quiconque a acheté le fichier. Spamhaus le répète (« le consentement n'est pas transférable ») pour expliquer pourquoi la co-inscription, la location ou l'achat de listes et l'enrichissement de fichiers sont tous dangereux, quelle que soit la façon dont la transaction est documentée.

## Techniques d'acquisition illégitimes

| Technique | De quoi il s'agit | Pourquoi elle échoue |
|---|---|---|
| **Collecte d'adresses ou scraping** | Un logiciel parcourt le web et récupère tout ce qui ressemble à une adresse, ou génère des adresses en combinant des noms avec un domaine (une attaque par dictionnaire ou par annuaire) | Aucun consentement n'est possible. Spamhaus met en garde contre de « graves problèmes de blocage et de livraison », une atteinte durable à la réputation et un placement en boîte de réception réduit. C'est l'exposition la plus forte aux [pièges vierges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges). **Également illégale en elle-même** (voir plus bas). |
| **Listes achetées** | Des adresses achetées directement | Le consentement ne se transfère pas. Le résultat est l'inscription sur des listes de blocage, une dégradation durable de la délivrabilité, une atteinte à la marque et un risque juridique au titre du RGPD et des lois similaires. L'acheteur fait aussi baisser la réputation partagée de son courrier opt-in existant. |
| **Listes louées** | Vous payez le propriétaire d'une liste pour qu'il envoie votre contenu à son fichier, et vous ne voyez jamais les adresses | Aucune relation avec les destinataires. Le propriétaire et l'expéditeur partagent les dégâts de réputation. |
| **Enrichissement de fichiers (email append, « epending »)** | Vous rapprochez des noms ou des données démographiques dont vous disposez d'adresses email fournies par un prestataire, ce qui crée des adresses qu'on ne vous a jamais données | C'est contraire aux valeurs fondamentales du secteur (Spamhaus soutient l'interdiction de l'enrichissement de fichiers posée par le M3AAWG). Le contact ne vous a jamais donné l'adresse. |
| **Co-inscription ou listes de partenaires** | Une adresse est recueillie sur le formulaire de l'entreprise A avec une mention comme « …et nos partenaires », puis transmise à l'entreprise B | Techniquement possible, mais Spamhaus la déconseille : « la permission n'est pas transférable », si bien qu'elle « crée un risque inacceptable de dégâts sur les campagnes ». |

Pratiquement toutes les politiques d'utilisation acceptable des ESP interdisent les listes collectées, achetées, louées et enrichies, ainsi que les listes issues de co-inscription ou de partenaires. Les utiliser justifie la fermeture du compte, en plus des dégâts de réputation et du risque juridique. C'est pourquoi les audits d'acquisition sont au cœur de la [réponse aux incidents d'adresses pièges](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response) et du [contrôle des clients](https://emailmarketing.net/learn/esp-operations/customer-vetting).

## Les logiciels de collecte d'adresses sont illégaux en eux-mêmes

Au-delà de l'atteinte à la réputation, utiliser un logiciel de collecte d'adresses, ou des listes qu'il a produites, constitue une infraction distincte dans le droit de plusieurs juridictions. La collecte d'adresses est ainsi la seule méthode d'acquisition qui n'est pas seulement une mauvaise pratique mais une violation juridique distincte, pour l'expéditeur, pour le fournisseur du logiciel et souvent pour l'ESP.

- **Nouvelle-Zélande, Unsolicited Electronic Messages Act 2007** (appliquée par le Department of Internal Affairs, DIA) : les entreprises ne doivent pas utiliser « de logiciel de collecte d'adresses électroniques, ni de listes produites à l'aide d'un tel logiciel, dans le but d'envoyer des messages électroniques commerciaux non sollicités » (*electronic address harvesting software, or lists that have been generated using such software, for the purpose of sending unsolicited commercial electronic messages*). Le DIA souligne qu'**acheter une base de données ne vous rend pas conforme**. Même lorsqu'un vendeur affirme qu'un « consentement présumé » existe, l'expéditeur doit prouver le consentement au moment de chaque envoi, et une infraction est constituée « qu'il ait cru ou non que le consentement existait du fait de l'achat d'une base de données » (*regardless of whether they believe consent existed due to the purchase of a database*). Le consentement présumé est étroit. L'adresse doit avoir été **publiée de façon visible** à titre professionnel ou officiel, **sans** mention refusant les messages non sollicités, et le message doit **concerner le rôle ou les fonctions du destinataire**. Les sanctions vont de l'avertissement formel à une **action devant la High Court pour des sanctions pécuniaires, une indemnisation et des dommages-intérêts**. Voir [Lois APAC sur l'email](https://emailmarketing.net/fr/apprendre/conformite/lois-sur-le-marketing-par-email-en-asie-pacifique) pour les niveaux de consentement et les sanctions maximales de la loi néo-zélandaise.
- **Australie, Spam Act 2003**, articles 20 à 22 : les logiciels de collecte d'adresses et les listes d'adresses collectées ne doivent être ni **fournis, ni acquis, ni utilisés** en lien avec des envois qui enfreignent la règle du consentement. Ce sont trois infractions distinctes. Voir [Spam Act australien](https://emailmarketing.net/fr/apprendre/conformite/australie-spam-act-2003-et-application-par-l-acma).
- **Canada, LCAP et LPRPDE**, et **États-Unis, CAN-SPAM** : la collecte d'adresses et la génération d'adresses par attaque par dictionnaire sont explicitement visées. Au titre de CAN-SPAM, elles constituent une « violation aggravée » (*aggravated violation*, 15 U.S.C. 7704). Au Canada, le Commissariat à la protection de la vie privée (CPVP) les traite au titre de la LPRPDE. Fournir ou sélectionner des adresses collectées est un fondement de responsabilité distinct qui peut atteindre l'ESP lui-même. Voir [Affaires de sanctions](https://emailmarketing.net/fr/apprendre/conformite/application-des-lois-sur-l-email-lcap-et-can-spam).

En pratique, un fichier acheté, ou un fichier « à consentement présumé » proposé par un courtier, doit être présumé dangereux et potentiellement issu d'une collecte d'adresses. La charge de prouver le contraire pèse sur l'expéditeur, et il ne peut généralement pas s'en acquitter.

## Pourquoi la méthode d'acquisition est la cause première

Les problèmes de qualité de liste qui apparaissent plus tard, comme les adresses pièges touchées, les taux de plaintes élevés, les pics de rebonds définitifs et les inscriptions sur des listes de blocage, sont presque toujours des **défaillances d'acquisition qui se manifestent tardivement**. Un piège vierge n'apparaît que dans un fichier collecté, généré ou acheté. Un piège recyclé n'apparaît que dans un fichier qui a remis en service d'anciennes adresses. Un pic de plaintes après un échange de listes remonte presque toujours à des adresses enrichies ou transférées dont les titulaires n'ont jamais consenti à recevoir le courrier de cet expéditeur. Corriger l'acquisition passe avant toute procédure de remédiation, et coûte moins cher que chacune d'elles :

- La conséquence pour les adresses pièges touchées, tirée d'[Adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges) : « si vos processus de gestion de liste laissent entrer des adresses pièges, il est probable que vous envoyez aussi du courrier à de vraies personnes qui n'en veulent pas ». Les adresses pièges sont un signal du défaut d'acquisition, pas le défaut lui-même.
- Le rétablissement après un incident ([Rétablissement après un incident de réputation](https://emailmarketing.net/fr/apprendre/operations/retablissement-apres-un-incident-de-reputation)) comprend toujours un audit et une purge des sources d'acquisition, car refaire la chauffe d'une adresse IP sur la même liste contaminée ne fait que mériter à nouveau le blocage.

## Voir aussi

- [Méthodes de consentement et spectre de qualité des listes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement)
- [Adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges), y compris les pièges vierges, les pièges recyclés et les pièges à fautes de frappe
- [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil), y compris la validation à l'inscription
- [Réponse aux incidents d'adresses pièges](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response)
- [Contrôle des clients](https://emailmarketing.net/learn/esp-operations/customer-vetting), sur la façon dont les ESP examinent les pratiques d'acquisition d'un prospect avant de l'accueillir
- [Affaires de sanctions](https://emailmarketing.net/fr/apprendre/conformite/application-des-lois-sur-l-email-lcap-et-can-spam)
- [Spam Act australien](https://emailmarketing.net/fr/apprendre/conformite/australie-spam-act-2003-et-application-par-l-acma)
- [Lois APAC sur l'email](https://emailmarketing.net/fr/apprendre/conformite/lois-sur-le-marketing-par-email-en-asie-pacifique)
- [Évolution des lignes directrices sur le consentement](https://emailmarketing.net/fr/apprendre/conformite/evolutions-des-positions-des-autorites-sur-le-consentement), sur les positions récentes des autorités de contrôle quant à ce qu'exige désormais le consentement

# List-Unsubscribe et désabonnement en un clic (RFC 2369 et RFC 8058)

> Syntaxe et sémantique exactes des champs d'en-tête List-* et du mécanisme de désabonnement en un clic List-Unsubscribe-Post, y compris les exigences DKIM et les raisons pour lesquelles les grands fournisseurs de messagerie les imposent.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic

Si vous envoyez des messages en nombre ou des emails marketing, le lien « Se désabonner » (*Unsubscribe*) que Gmail, Yahoo, Apple Mail et Outlook.com affichent à côté du nom de l'expéditeur provient d'en-têtes que vous ajoutez à chaque message. Deux RFC définissent ce mécanisme standard de désabonnement lisible par une machine :

- La **RFC 2369** (1998) définit les champs d'en-tête `List-*`, dont `List-Unsubscribe`.
- La **RFC 8058** (2017) ajoute `List-Unsubscribe-Post`, qui transforme la variante HTTPS en une action **en un clic** que les clients de messagerie peuvent effectuer pour l'utilisateur, sans charger de page web.

## RFC 2369 : les champs d'en-tête List-*

La RFC 2369 définit six champs d'en-tête pour les messages distribués par une liste de diffusion :

| En-tête | Rôle | Remarques |
|---|---|---|
| `List-Help` | Instructions complètes pour la liste | Considéré comme le champ le plus important ; peut être le seul implémenté |
| `List-Unsubscribe` | Commande ou URL pour quitter la liste | Le champ sur lequel agissent les fournisseurs de messagerie |
| `List-Subscribe` | Commande ou URL pour rejoindre la liste | |
| `List-Post` | Comment publier sur la liste | Valeur spéciale `NO` pour les listes qui n'acceptent pas de publications (listes d'annonces) |
| `List-Owner` | Contact de l'administrateur de la liste | |
| `List-Archive` | Comment accéder aux archives de la liste | |

### Règles de syntaxe

- Le contenu de chaque champ est **une ou plusieurs URL entre chevrons** : `<mailto:...>` ou `<http://...>`. Les espaces à l'intérieur des chevrons sont ignorés. Les systèmes qui génèrent les champs ne doivent pas mettre d'espaces entre les chevrons, mais les clients devraient tolérer les entrées mal formatées.
- **Plusieurs URL alternatives** PEUVENT être fournies, sous la forme d'une liste d'URL entre chevrons séparées par des virgules. **L'ordre indique la préférence, de gauche à droite** : un client utilise le protocole le plus à gauche qu'il prend en charge (par exemple HTTPS d'abord, avec `mailto:` en solution de repli).
- Des commentaires entre parenthèses peuvent suivre une URL : `List-Post: NO (posting not allowed on this list)`.
- Un message peut contenir **au plus une occurrence de chaque champ**.
- Les champs **DOIVENT être générés uniquement par le système de la liste ou d'envoi, jamais par les utilisateurs finaux**.
- Les champs implémentés pour une liste DEVRAIENT figurer dans **tous** les messages que cette liste distribue.
- Règles pour les clients qui analysent les champs : si le contenu du champ commence par autre chose que `<`, le champ DEVRAIT être ignoré. Les caractères qui suivent un `>` fermant sont ignorés, sauf si le caractère suivant qui n'est ni un espace ni une partie d'un commentaire est une virgule. Un élément séparé par des virgules qui n'est pas une URL entre chevrons fait ignorer le reste du champ.
- Une sous-liste qui redistribue les messages d'une liste parente devrait remplacer les champs `List-Help`, `List-Subscribe`, `List-Unsubscribe` et `List-Owner` de la liste parente par les siens, et conserver `List-Archive`, sauf si elle fournit le sien.

### Exemples (tirés de la RFC)

```
List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,
    <mailto:list-request@host.com?subject=unsubscribe>
List-Help: <http://www.host.com/list/>, <mailto:list-info@host.com>
List-Subscribe: <http://www.host.com/list.cgi?cmd=sub&lst=list>,
    <mailto:list-manager@host.com?body=subscribe%20list>
List-Post: <mailto:list@host.com>
List-Owner: <mailto:listmom@host.com>
List-Archive: <http://www.host.com/list/archive/> (Web Archive)
```

Pour les URL `mailto:`, les clients sont censés afficher une boîte de dialogue de confirmation (avec le destinataire et la commande) avant l'envoi.

## RFC 8058 : désabonnement en un clic (List-Unsubscribe-Post)

Une simple URL HTTPS dans `List-Unsubscribe` ne peut pas être ouverte automatiquement sans risque. Les scanners antispam, les outils de préchargement de liens et les proxys de sécurité suivent les liens GET, ce qui désabonnerait des utilisateurs qui n'ont jamais demandé à partir. La RFC 8058 résout ce problème. Le signal que définit la RFC 8058 est **fondé sur POST**, et seule une action délibérée dans le client de messagerie le produit.

### Syntaxe de l'en-tête

```
list-unsubscribe-post = "List-Unsubscribe-Post:" 0*1WSP postarg CRLF
postarg               = "List-Unsubscribe=One-Click"
```

La valeur de l'en-tête est **exactement** `List-Unsubscribe=One-Click`, et rien d'autre n'est valide.

### Exigences envers l'expéditeur

| Exigence | Niveau |
|---|---|
| Le message porte un en-tête `List-Unsubscribe` qui contient **une URI HTTPS** (d'autres URI, comme `mailto:`, PEUVENT aussi être présentes) | DOIT |
| L'URI HTTPS contient assez d'informations pour identifier le destinataire **et** la liste, de sorte que le désabonnement aboutisse sans autre saisie | DOIT |
| L'URI comprend une partie opaque et difficile à falsifier (par exemple un HMAC du destinataire et de la liste), vérifiée côté serveur | DEVRAIT |
| Le point de terminaison de désabonnement effectue l'action **sans aucune autre interaction** avec l'utilisateur (ni connexion, ni formulaire de confirmation) | DOIT |
| Le point de terminaison POST ne renvoie pas de redirections HTTPS (les requêtes POST redirigées sont historiquement peu fiables) | NE DOIT PAS |
| Le message porte au moins une **signature DKIM valide** dont la balise `h=` couvre **à la fois** `List-Unsubscribe` et `List-Unsubscribe-Post` | DOIT |

Si la signature DKIM exigée est absente ou invalide, le serveur de réception NE DEVRAIT PAS proposer le désabonnement en un clic. C'est ce qui empêche un attaquant d'injecter de faux en-têtes de désabonnement.

### Sémantique du POST (ce qu'envoie le fournisseur de messagerie)

Lorsque l'utilisateur clique sur la commande de désabonnement dans le client, le serveur de réception envoie une requête HTTPS **POST** à l'URI indiquée dans `List-Unsubscribe`, avec pour corps la clé et la valeur de `List-Unsubscribe-Post` :

- `Content-Type` : `multipart/form-data` (DEVRAIT) ou `application/x-www-form-urlencoded` (PEUT).
- Corps : l'unique paire `List-Unsubscribe=One-Click`.
- La requête **NE DOIT PAS** inclure de cookies, d'autorisation HTTP ni aucune autre information de contexte. Le point de terminaison ne peut donc pas s'appuyer sur une session, seulement sur l'URI elle-même.
- Le serveur de réception NE DOIT PAS envoyer le POST sans le consentement de l'utilisateur. Il ne l'envoie qu'après une action explicite de l'utilisateur, jamais par anticipation.

### Exemples (tirés de la RFC)

```
List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

POST /unsubscribe/opaquepart HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26

List-Unsubscribe=One-Click
```

Avec une alternative `mailto:` et `multipart/form-data` :

```
List-Unsubscribe:
    <mailto:listrequest@example.com?subject=unsubscribe>,
    <https://example.com/unsubscribe.html/opaque123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

POST /unsubscribe.html/opaque=123456789 HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=---FormBoundaryjWmhtjORrn
Content-Length: 124

---FormBoundaryjWmhtjORrn
Content-Disposition: form-data; name="List-Unsubscribe"

One-Click
---FormBoundaryjWmhtjORrn--
```

### Modèle de sécurité

- Limiter le corps du POST à une seule paire fixe empêche d'utiliser l'en-tête pour déclencher des soumissions de formulaire arbitraires.
- Exclure les cookies et l'autorisation empêche de relier le désabonnement aux autres activités web de l'utilisateur.
- Comme avec le `List-Unsubscribe` classique, toute personne qui dispose d'une copie du message peut désabonner le destinataire. La partie opaque de l'URI réduit ce risque, mais ne l'élimine pas.

## Pourquoi Gmail et Yahoo l'imposent

Depuis février 2024, Gmail et Yahoo exigent des **expéditeurs de gros volumes** (le seuil de Gmail est d'environ 5 000 messages ou plus par jour vers ses utilisateurs) qu'ils intègrent le désabonnement en un clic de la RFC 8058 à leurs messages commerciaux et promotionnels, et qu'ils traitent les désabonnements **dans un délai de deux jours**. Les raisons découlent directement des bases de la délivrabilité (voir [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)) :

- Un désabonnement sans friction est l'alternative au bouton **« Signaler comme spam »** (*Report spam*). Chaque utilisateur qui se désabonne au lieu de se plaindre protège votre taux de plaintes (Gmail demande de maintenir le taux de spam sous 0,10 % et de ne jamais le laisser dépasser 0,30 %).
- L'exigence que DKIM couvre les en-têtes rattache le désabonnement à un domaine authentifié, en complément de l'[alignement DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).
- Comme le POST ne transporte ni cookies ni contexte, l'honorer exige, côté expéditeur, une infrastructure qui associe réellement le jeton opaque à une vraie inscription en liste de suppression. C'est donc un bon indicateur de la compétence d'un expéditeur dans la gestion de ses listes.

### Liste de contrôle de mise en œuvre pour l'expéditeur

1. Ajoutez les deux en-têtes à chaque message commercial ou de liste, et conservez `mailto:` comme URI de repli à côté de l'URI HTTPS.
2. Signez avec DKIM, et incluez les deux en-têtes dans la liste `h=` de la signature.
3. Rendez le point de terminaison idempotent, sans redirection et instantané : placez l'adresse en liste de suppression dès le POST, sans connexion et sans étape « êtes-vous sûr ? ».
4. Versez les désabonnements en un clic dans la même liste de suppression que les plaintes issues des [feedback loops](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes), et traitez-les dans un délai de 48 heures au plus tard (l'exigence de Gmail et Yahoo décrite plus haut).
5. Conservez aussi le lien de désabonnement dans le corps du message. Les en-têtes le complètent, ils ne le remplacent pas.

## Ce qu'ajoutent les Sender Best Common Practices du M3AAWG

Le Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) décrit les pratiques du secteur en matière de désabonnement dans ses *Sender Best Common Practices* (version 4.0, août 2026, section 4.6). La version 4.0 fait du désabonnement en un clic une exigence des recommandations du M3AAWG lui-même, en s'appuyant sur les règles des grands fournisseurs de messagerie :

- **Le désabonnement en un clic est une exigence.** Pour répondre aux exigences mises à jour des grands fournisseurs de messagerie, les expéditeurs « doivent mettre en œuvre le désabonnement en un clic (List-Unsubscribe-Post) dans les en-têtes, comme le décrit la RFC 8058 » (section 4.6, point 6c). Le même point indique toujours que les expéditeurs **devraient** adopter l'en-tête `List-Unsubscribe` de la RFC 2369 lui-même.
- **Gardez l'adresse hors du lien.** Le lien de désabonnement **ne devrait pas** afficher l'adresse email de l'abonné, et devrait utiliser une référence encodée plutôt que du texte en clair (point 14). La section 2.8 étend cette règle à toutes les URL d'action d'un message, y compris les liens de suivi et de préférences. L'adresse ne devrait apparaître ni en clair ni sous un encodage facile à inverser, comme le base64. Une valeur chiffrée, ou un identifiant sans rapport avec le destinataire que seul l'expéditeur peut faire correspondre, est bien préférable. La partie opaque d'une URI RFC 8058 fonctionne déjà ainsi.
- **Sans délai, mais sans échéance chiffrée.** Les expéditeurs **doivent** traiter chaque demande de désabonnement sans délai (point 2), et **devraient** indiquer aux destinataires, pendant la démarche, le délai de retrait et les listes concernées (point 3). Le M3AAWG ne fixe aucun nombre de jours. Les délais de 48 heures et de deux jours cités sur cette page viennent de Gmail et Yahoo, pas du M3AAWG.
- **Aucune connexion.** Les abonnés **doivent** pouvoir se désabonner sans se connecter à un centre de préférences ni passer aucun autre contrôle de sécurité (point 12). Cela correspond à la règle de la RFC 8058 selon laquelle le point de terminaison effectue l'action sans autre interaction.

# Méthodes de consentement et échelle de qualité des listes

> Les huit façons dont des adresses se retrouvent sur une liste de diffusion, de l'opt-in confirmé à la collecte d'adresses, classées selon à qui appartient la relation et selon le risque de plaintes, avec les règles d'acquisition qui limitent les plaintes.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement

La manière dont une adresse est arrivée sur votre liste de diffusion est, à elle seule, le meilleur indicateur de ce qu'elle fera : interagir, ignorer vos messages, rebondir ou se plaindre. Les méthodes d'acquisition employées dans le secteur, y compris celles qu'aucun expéditeur légitime ne devrait utiliser, peuvent être classées sur une seule échelle.

Le Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) formalise les trois meilleures méthodes sous forme de « niveaux » d'opt-in, assortis d'exigences détaillées, dans ses [Sender Best Common Practices](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs) (version 4.0, août 2026). L'échelle ci-dessous se prolonge au-delà de ces niveaux, jusqu'aux méthodes d'acquisition que le M3AAWG condamne, pour que vous puissiez comparer toute la gamme.

## L'échelle : une relation qui vous appartient, une relation empruntée ou aucune relation

Des meilleures pratiques aux pires :

```
MEILLEURE ◄───────────────────────────────────────────────────────────────────────► PIRE
Double   Opt-in    Simple   Opt-out   Liste de      Liste       Liste     Liste
opt-in   notifié   opt-in             partenaires   louée       achetée   collectée
└─ la relation vous appartient ─────┘ └─ relation empruntée ──┘ └─ aucune relation ────┘
                                         à un tiers
└─ le destinataire vous ──┘ └─ tromperie ou aucun consentement ────────────────────────┘
   a demandé de le contacter
```

Deux questions permettent de situer n'importe quelle méthode sur l'échelle :

1. **À qui appartient la relation ?** Avec les méthodes d'opt-in, le destinataire est en relation avec vous. Avec les listes de partenaires, louées ou achetées, vous empruntez ou achetez la relation de quelqu'un d'autre. Avec les listes collectées, il n'existe aucune relation. **Le consentement ne se transfère pas.** L'autorisation qu'un abonné a donnée à l'entreprise A ne s'étend jamais à l'entreprise B.
2. **Le destinataire a-t-il demandé à être contacté ?** Seules les méthodes d'opt-in permettent de répondre oui. Toutes les méthodes à partir de l'opt-out reposent sur l'inertie, sur la tromperie ou sur rien du tout.

Les taux de plaintes augmentent à chaque étape de l'échelle, et les plaintes comptent parmi les signaux de réputation négatifs les plus forts qu'utilisent les fournisseurs de messagerie (voir [Indicateurs et valeurs de référence](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite) pour les seuils).

## Les huit méthodes

| Méthode | Fonctionnement | Profil de plaintes et de risque |
|---|---|---|
| **Opt-in confirmé (« en boucle fermée ») ou double opt-in** | L'inscription déclenche un email de confirmation. L'adresse ne reçoit rien tant que le destinataire n'a pas cliqué sur un lien ou répondu. | Le taux de plaintes le plus bas. Bloque les fautes de frappe, les inscriptions frauduleuses et les [adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges), car une adresse piège ne peut jamais aller au bout de la confirmation. Niveau 3 du M3AAWG (« le meilleur »). Le M3AAWG précise aussi que, lorsqu'un abonné change d'adresse, la nouvelle adresse devrait passer par la même confirmation. |
| **Opt-in notifié** | L'inscription déclenche un email de bienvenue, mais l'adresse rejoint la liste sans confirmation. | Répandu. Génère plus de plaintes que le double opt-in, car les fautes de frappe et les adresses saisies par malveillance entrent dans la liste. Niveau 2 du M3AAWG. Si l'email de bienvenue rebondit, le M3AAWG demande de le traiter comme un rebond et de retirer l'adresse de la liste. |
| **Simple opt-in** | Le destinataire coche en connaissance de cause une case « inscrivez-moi » vide sur un formulaire (lors du paiement ou de la création de compte). Aucune confirmation ni aucun message de bienvenue ne suit. | Exposé aux abus et à la pollution par les fautes de frappe. Les taux de plaintes et de rebonds sont plus élevés, et peuvent dégénérer en problèmes de livraison. Niveau 1 du M3AAWG : « à utiliser avec une extrême prudence ». |
| **Opt-out (case précochée ou ajout automatique)** | L'adresse est ajoutée automatiquement, par une case précochée ou lors d'un achat, et le destinataire doit se désabonner ou décocher la case pour ne pas recevoir de messages. | Les destinataires se sentent piégés, et les volumes de plaintes sont importants. Le M3AAWG traite différemment les deux mécanismes. Ajouter quelqu'un qui a donné son adresse lors du paiement, sans l'avoir prévenu que des messages marketing suivraient, correspond à ce qu'il appelle le consentement implicite : ce n'est pas une meilleure pratique, et il faut l'éviter autant que possible. Une case précochée est jugée plus sévèrement : pour une finalité supplémentaire, l'opt-in « ne doit pas être activé par défaut », et la case de consentement que recommande le M3AAWG est une case distincte et non cochée. Au regard de la [Loi canadienne anti-pourriel (LCAP)](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel), le consentement implicite n'est légal que dans des cas précis et pour une durée limitée. Si vous utilisez l'un ou l'autre lors du paiement, passez à une case non cochée ou à une confirmation. |
| **Listes de partenaires (affiliation)** | L'entreprise A partage des adresses avec des « partenaires », souvent au moyen d'une mention du type « …et partenaires concernés » au moment de l'inscription. | Les destinataires qui se sont inscrits auprès de l'entreprise A ne reconnaissent pas l'entreprise B, et ils se plaignent. Le taux de plaintes est élevé, et les problèmes de livraison tendent à persister. |
| **Listes louées** | L'expéditeur paie le propriétaire d'une liste pour qu'il envoie le contenu de l'expéditeur à sa liste, généralement une seule fois. L'expéditeur ne voit jamais les adresses. | Aucune relation avec les destinataires, et des taux de rebonds et de plaintes élevés. Le propriétaire de la liste **et** l'expéditeur partagent les dégâts de réputation. Au regard de CAN-SPAM, « même si vous confiez votre marketing par email à une autre entreprise, vous ne pouvez pas vous décharger par contrat de votre responsabilité légale de respecter la loi » (FTC ; voir [CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis)). |
| **Listes achetées** | Adresses achetées purement et simplement. | Les destinataires n'ont jamais accepté de recevoir des messages de l'acheteur. Attendez-vous à des signalements de spam, à des relations dégradées avec la marque, à des adresses invalides et à des pièges vierges. Acheter une liste dégrade aussi la livraison vers l'audience existante de l'expéditeur, qui a donné son consentement, parce que cela tire vers le bas la réputation commune. La plupart des fournisseurs de services email (ESP) sérieux refusent tout simplement ce type de clients. |
| **Listes collectées (« scrapées »)** | Adresses collectées en parcourant le web à la recherche de tout ce qui ressemble à `something@domain.com`, ou par des attaques de collecte par dictionnaire ou par annuaire, qui devinent des adresses d'entreprise construites sur un modèle (`jdoe@`, `john.doe@`). | Une technique de spammeur. Il n'y a ni consentement ni relation, les plaintes, les rebonds et les pièges vierges touchés sont à leur maximum, et collecter des adresses de cette façon est illégal dans plusieurs juridictions. |

La politique antispam de pratiquement tous les ESP interdit les listes collectées, achetées, louées et de partenaires. Les utiliser justifie la résiliation du compte, en plus des dégâts de réputation.

### Le piège de la relation commerciale existante

**Avoir une relation commerciale existante avec quelqu'un ne vous autorise pas pour autant à l'ajouter à une liste de diffusion.** Les clients ajoutés automatiquement, ou par un parcours d'inscription peu clair, signalent les messages comme spam simplement parce qu'ils ne reconnaissent pas l'expéditeur ou n'ont jamais voulu ces messages. Au moment de l'achat, proposez l'option de s'abonner au lieu d'abonner les gens automatiquement.

La loi est ici plus permissive que les bonnes pratiques. CAN-SPAM permet d'envoyer sans consentement préalable, et le consentement implicite que la LCAP accorde en cas de « relation d'affaires en cours » est limité dans le temps (voir la [vue d'ensemble de la conformité](https://emailmarketing.net/fr/apprendre/conformite)). Mais ce qui est légal n'est pas ce qui maintient les taux de plaintes à un niveau supportable. Le principe du M3AAWG est que les attentes des destinataires l'emportent sur ce qu'une politique de confidentialité autorise techniquement.

## Les règles d'acquisition qui limitent les plaintes

Les plaintes comptent parmi les facteurs qui pèsent le plus, à eux seuls, sur la réputation d'expéditeur, donc concevez vos pratiques d'acquisition pour les prévenir :

- N'utilisez jamais de liste achetée, collectée ou « scrapée », quelle qu'elle soit
- Ayez une relation directe avec chaque adresse de la liste
- Confirmez les nouvelles inscriptions (double opt-in)
- Demandez aux gens s'ils veulent s'abonner, et ne les inscrivez jamais automatiquement
- Rendez le parcours d'inscription explicite : ce à quoi les gens s'inscrivent, quand les envois commencent et à quelle fréquence ils arriveront
- Utilisez un nom et une adresse d'expéditeur (From) constants
- Utilisez des lignes d'objet qui décrivent fidèlement le contenu
- Traitez rapidement les désabonnements (voir [List-Unsubscribe et désabonnement en un clic](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic) ; Gmail et Yahoo imposent désormais le désabonnement en un clic aux expéditeurs de gros volumes)
- Respectez la loi antispam de chaque région où vous envoyez des emails ([CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis), [LCAP](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel), [PECR](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email) et RGPD, entre autres). Une seule adresse dans une juridiction suffit à y rendre la loi applicable, donc suivez les règles les plus strictes qui s'appliquent
- Tenez la liste à jour, et **ne réactivez jamais d'anciennes adresses ni des adresses auparavant invalides**. Une adresse en rebond définitif a pu être transformée depuis en [adresse piège](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges) recyclée, et écrire à une adresse désabonnée est illégal dans la plupart des juridictions. C'est particulièrement important lors d'un changement d'ESP : ne reprenez jamais les rebonds définitifs ni les désabonnés comme contacts actifs dans la nouvelle plateforme
- Envoyez régulièrement, pour que la liste ne vieillisse jamais

La méthode de consentement détermine la qualité de la liste au point d'entrée. [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil) traite du maintien de cette qualité dans le temps, et ajoute à la méthode de consentement une validation à l'inscription (vérification de la syntaxe et des enregistrements MX, CAPTCHA, détection des fautes de frappe).

## Voir aussi

- [M3AAWG Senders BCP](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs), notamment les niveaux d'opt-in formels 1–3
- [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil)
- [Adresses pièges : types et ce qu'elles révèlent](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges)
- [Feedback loops de plaintes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes)
- [Le modèle de livraison en sept étapes](https://emailmarketing.net/fr/apprendre/fondamentaux/modele-de-livraison-en-sept-etapes)
- [Vue d'ensemble de la conformité](https://emailmarketing.net/fr/apprendre/conformite)

# Backscatter et BATV

> Les rebonds mal dirigés vers des adresses de retour usurpées : pourquoi l'acceptation suivie d'un rebond en est la cause, comment fonctionnent les inscriptions sur Backscatterer.org, la mécanique du marquage BATV prvs= (draft-levine-smtp-batv-01) avec ses avantages et inconvénients opérationnels, et les alternatives modernes.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/backscatter-et-batv

Si votre domaine reçoit des rebonds pour des messages qu'il n'a jamais envoyés, ou si vos propres serveurs ont été inscrits sur une liste pour avoir envoyé de tels rebonds, vous avez affaire au backscatter. Un ESP y est confronté des deux côtés : ses MTA ne doivent pas en générer, et ses domaines de retour en reçoivent des flots.

Le **backscatter** désigne le trafic de rebonds livré à des personnes qui n'ont jamais envoyé le message d'origine. Il comprend les notifications d'état de livraison (DSN) et, par extension, les réponses automatiques et les messages de défi. Les spammeurs et les virus inscrivent de vraies adresses usurpées dans le `MAIL FROM`. Quand le spam ne peut pas être livré, le rebond part vers la personne dont l'adresse a été usurpée. À l'échelle d'une campagne de spam, un domaine innocent peut recevoir un flot de rapports de non-livraison (NDR) mal dirigés, et les systèmes qui envoient ces rebonds se retrouvent sur des listes de blocage en tant que sources de backscatter.

## La cause : accepter puis renvoyer un rebond

Un rebond n'est mal dirigé que s'il est généré après la fin de la transaction SMTP. La pratique admise en découle :

- **Rejetez pendant la transaction SMTP (avec un 5xx) chaque fois que c'est possible.** Un rejet est renvoyé dans la connexion en cours, à l'hôte qui a réellement soumis le message. Aucun nouveau message n'est créé, donc une adresse `MAIL FROM` usurpée ne reçoit rien. Tout verdict que vous pouvez établir avant la fin de `DATA`, qu'il porte sur un destinataire inconnu, la politique, la taille ou le contenu, devrait être un rejet pendant la session.
- **Accepter puis renvoyer un rebond** consiste à répondre 250, puis à générer plus tard une DSN vers l'adresse `MAIL FROM`. Cela crée un nouveau message destiné à une adresse que personne n'a vérifiée, et pour du courrier usurpé, cette DSN est du backscatter. Les causes habituelles sont les passerelles et les relais de stockage et retransmission qui acceptent le courrier pour des serveurs en aval sans connaître la liste des destinataires valides (« tout accepter, renvoyer les rebonds plus tard »), les filtres antispam et antivirus appliqués après acceptation et configurés pour « avertir l'expéditeur », et les systèmes de défi-réponse.
- Plusieurs règles en découlent. Validez les destinataires en bordure (par une vérification en temps réel auprès du serveur en aval, ou par une liste de destinataires synchronisée). Si vous devez traiter du spam après acceptation, **supprimez-le ou mettez-le en quarantaine, et ne renvoyez jamais de rebond**. Ne répondez jamais automatiquement à un courrier qui échoue à l'authentification. Toute DSN que vous générez légitimement utilise toujours `MAIL FROM:<>` (voir [DSN](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison)).

### Inscription sur une liste de blocage pour backscatter (Backscatterer.org et UCEPROTECT)

- La zone est `ips.backscatterer.org`. Elle liste les adresses IP observées en train d'envoyer des **rebonds mal dirigés, des réponses automatiques mal dirigées et des vérifications d'expéditeur par rappel**. Les sondes de vérification de l'adresse de l'expéditeur (SAV) sont elles aussi considérées comme un abus.
- Ce n'est explicitement **pas une liste de spam** (« C'est une liste de Backscatterer !!! »). L'usage recommandé est le **SAFE MODE** : ne l'interroger que lorsque `MAIL FROM` vaut `<>` ou `postmaster`, c'est-à-dire uniquement pour filtrer du trafic qui ressemble à des rebonds, car les adresses IP listées envoient aussi beaucoup de courrier légitime. Les sites qui l'interrogent pour tout le courrier causent les dommages collatéraux contre lesquels ses opérateurs mettent en garde.
- Historiquement, les inscriptions expirent d'elles-mêmes après une période sans nouvelle détection (environ quatre semaines), et il existe une option payante de « retrait de liste express », une pratique controversée. Les détails sur l'expiration et le tarif ne figuraient pas sur la page d'utilisation consultée comme source. Ils sont indiqués ici d'après la politique largement documentée de l'opérateur, donc vérifiez les conditions en vigueur avant de conseiller à quiconque de payer un retrait de liste. La correction est toujours la même : trouver et arrêter le comportement d'acceptation suivie d'un rebond ou de vérification par rappel, puis laisser l'inscription expirer.
- Une inscription a un impact pratique limité, puisque peu de grands fournisseurs utilisent la zone, et seulement en safe mode. C'est tout de même un signe fiable que votre infrastructure est mal configurée.

## BATV : Bounce Address Tag Validation

BATV permet à un domaine de distinguer les rebonds du courrier qu'il a réellement envoyé des rebonds d'usurpations, en signant les parties locales de ses propres adresses `MAIL FROM`. Il est spécifié dans **draft-levine-smtp-batv-01** (Levine, Crocker, Silberman, Finch ; 2008-05-13, expiré le 2008-11-14). Le draft n'a **jamais été publié en RFC**, mais de nombreux MTA et appliances l'ont implémenté depuis.

### Méta-syntaxe et schéma prvs=

La forme d'une partie locale marquée :

```
local-part = tag-type "=" tag-val "=" loc-core
```

Le seul schéma défini est **prvs** (« private signature », avec une clé privée simple) :

```
prvs=KDDDSSSSSS=jsmith@example.com
        │ │  └── SSSSSS : 3 premiers octets (6 chiffres hexadécimaux) d'un HMAC-SHA1
        │ └───── DDD : 3 derniers chiffres du nombre de jours depuis 1970 (ancre d'expiration)
        └─────── K : un chiffre de numéro de clé (rotation)
```

- L'entrée du HMAC est `K DDD <original MAIL FROM address>`, avec pour clé un secret que partagent les signataires sortants et les validateurs entrants du domaine.
- Les MTA sortants réécrivent `MAIL FROM:<jsmith@example.com>` sous la forme marquée à la frontière du domaine de gestion administrative (ADMD). Ils ne marquent jamais les adresses d'autres domaines. L'en-tête `From:` du message n'est pas modifié : BATV n'agit que sur l'enveloppe.
- Les MTA entrants, pour le courrier adressé à une partie locale `prvs=` (en pratique, du trafic qui ressemble à des rebonds), vérifient le HMAC et contrôlent que le compteur de jours est dans la fenêtre. Le draft impose une **durée de vie de 7 jours**, pour tenir compte des rebonds retardés. Si la marque est valide, le MTA la retire (tout jusqu'au second `=` inclus) et livre à `loc-core`. Si un rebond porte une marque invalide ou n'en porte pas, le MTA le rejette pendant la session SMTP.
- La méta-syntaxe autorise d'autres schémas, notamment un « marquage public » à clés publiques que des tiers pourraient vérifier. Seul prvs a jamais été défini et déployé.

### Ce que BATV apporte à un ESP

- **Il arrête les flots de faux rebonds.** Une DSN adressée à votre domaine de retour sans marque, ou avec une mauvaise marque, n'est de façon prouvée pas une réponse à votre courrier, donc vous pouvez la rejeter. Cela protège le traitement des rebonds contre l'empoisonnement (de faux rebonds qui suppriment de bonnes adresses) et contre les flots de volume.
- Il n'offre qu'une protection faible contre le rejeu, et c'est voulu, comme le dit le draft lui-même. Le HMAC est tronqué à 6 chiffres hexadécimaux et la fenêtre est de 7 jours, ce qui empêche de deviner, mais pas le rejeu déterminé d'une adresse marquée récemment collectée. Il ne protège pas contre une modification du contenu, et la protection n'existe qu'au domaine de livraison (car la clé est privée), pas le long du chemin.

### Problèmes opérationnels (d'après les considérations de déploiement du draft)

| Problème | Détail |
|---|---|
| Liste grise | Les nouvelles tentatives de livraison doivent présenter le **même** `MAIL FROM` marqué. La marque doit être calculée une fois par message, et non à chaque tentative, sinon la liste grise reporte le message indéfiniment. |
| Listes de diffusion | Les listes qui identifient les abonnés ou les auteurs par l'expéditeur d'enveloppe voient une adresse différente chaque fois que le compteur de jours change, si bien que les contrôles d'abonnement et de publication échouent. |
| Défi-réponse et listes blanches | Les listes blanches d'adresses d'expéditeur et les systèmes de défi-réponse traitent chaque variante de la marque comme un nouvel expéditeur. Il en résulte des défis répétés et des listes d'autorisation qui ne fonctionnent plus. |
| Détection des doublons et tri | Les systèmes qui s'appuient sur l'expéditeur d'enveloppe traitent les variantes comme des adresses distinctes. |
| Administration séparée | Si des parties différentes gèrent les serveurs de messagerie entrants et sortants (courant chez les hébergeurs), le partage de la clé HMAC est malcommode. La solution de repli du draft, signer au niveau du client de messagerie (MUA), est irréaliste. |
| Longueur de l'adresse | La marque ajoute 16 caractères à la partie locale, ce qui peut dépasser la limite de 64 octets des parties locales pour des adresses déjà longues. |
| Expéditeurs tiers | Toute personne qui envoie légitimement « depuis » votre domaine sans votre clé (un ESP, un partenaire) produit du courrier non marqué, dont vous rejetez désormais les rebonds. BATV doit couvrir tous les points d'émission légitimes, ou ces flux doivent être exclus. |

### BATV et VERP : complémentaires, et largement convergents

Un ESP qui utilise déjà **VERP** (une adresse de retour encodée pour chaque destinataire, par exemple `bounce-c123-user=example.com@bounces.esp.com`) obtient l'essentiel du bénéfice de BATV si le jeton VERP contient un HMAC. Tout « rebond » entrant dont la partie locale ne se décode pas en un envoi sortant réel est rejeté ou supprimé.

Cette approche, le **VERP signé et validé**, est ce qu'utilisent en réalité la plupart des grands ESP au lieu du marquage `prvs=` littéral. Elle valide les rebonds par rapport aux envois sortants et identifie le destinataire et la campagne exacts. Elle évite aussi les problèmes que BATV pose aux listes de diffusion et aux listes blanches, car le domaine de retour est un domaine de rebond dédié avec lequel aucune personne ne correspond.

## Pratique actuelle

1. **N'envoyez jamais de backscatter.** Rejetez pendant la session SMTP, supprimez le spam détecté après acceptation, ne faites pas de vérification SAV par rappel, et n'envoyez de DSN que depuis `<>`.
2. **Validez les rebonds entrants** par rapport à vos propres envois, avec du VERP signé (ou BATV lorsque tout le courrier du domaine passe par un seul ADMD). Supprimez tout ce qui ne peut pas être vérifié à une adresse de rebond avant que cela n'atteigne votre logique de suppression d'adresses.
3. **L'authentification réduit l'offre d'usurpations.** À mesure que davantage de domaines appliquent [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc), moins de courrier usurpé est accepté au départ, donc moins de backscatter est généré vers ces domaines.
4. **La correction structurelle est en cours d'élaboration.** [DKIM2](https://emailmarketing.net/fr/apprendre/authentification/dkim2) renvoie les DSN saut par saut le long d'une chaîne de responsabilité authentifiée, ce qui rend les rebonds mal dirigés impossibles pour le courrier participant. C'est l'un de ses objectifs de conception explicites. Il en est encore au stade de draft, donc ne comptez pas encore dessus.
5. Si vous êtes inscrit sur `ips.backscatterer.org`, auditez les chemins d'acceptation suivie d'un rebond et les vérifications par rappel, corrigez la source, puis attendez l'expiration de l'inscription. Traitez l'inscription comme un avertissement sur votre configuration plutôt que comme une urgence de délivrabilité.

## Voir aussi

- [Delivery Status Notifications](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison), notamment la règle de l'expéditeur nul et l'analyse de VERP
- [Listes de blocage et Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus)
- [DKIM2](https://emailmarketing.net/fr/apprendre/authentification/dkim2), sur le routage authentifié des rebonds

# Codes d'état étendus SMTP (RFC 3463)

> La taxonomie des codes d'état étendus du système de messagerie X.Y.Z : classes, sujets et table complète des codes de détail, et comment s'en servir pour classer les rebonds.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp

Quand un message est refusé ou rebondit, la réponse comporte généralement un code comme `5.1.1` ou `4.2.2`. Ces codes vous indiquent si l'échec est définitif et quelle partie du système de messagerie a échoué, ce qui en fait la donnée la plus utile pour classer automatiquement les rebonds.

La RFC 3463 définit ces **codes d'état étendus du système de messagerie**. Les codes `X.Y.Z` apparaissent dans les réponses SMTP et dans le champ `Status:` des [notifications d'état de livraison](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison). Ils existent parce que les codes de réponse SMTP de base à 3 chiffres (250, 450, 550…) mélangent les résultats du transport et le sens du résultat de la livraison. Les codes étendus donnent un motif qu'une machine peut analyser et qui ne dépend pas du transport.

## Structure

```
status-code = class "." subject "." detail
```

Chaque composant est numérique, sans zéro non significatif.

### Classe (premier nombre) : l'échec est-il définitif ?

| Classe | Signification | Conséquence pour la gestion des rebonds |
|---|---|---|
| `2.X.X` | Succès : une action de livraison positive | Pas un rebond |
| `4.X.X` | Échec transitoire persistant : le message est valide, mais une condition temporaire a causé un retard ou a fait abandonner le serveur | **Rebond temporaire** : réessayer, et ne supprimer l'adresse qu'après des échecs répétés |
| `5.X.X` | Échec définitif : renvoyer le message sous sa forme actuelle a peu de chances de le résoudre | **Rebond définitif** : ne pas réessayer sans modification, et supprimer l'adresse lorsque la cause concerne l'adresse |

### Sujet (deuxième nombre) : quelle partie du système a échoué ?

| Sujet | Catégorie |
|---|---|
| `X.0.X` | Autre ou non défini |
| `X.1.X` | État de l'adressage |
| `X.2.X` | État de la boîte aux lettres |
| `X.3.X` | État du système de messagerie (hôte de destination) |
| `X.4.X` | État du réseau et du routage |
| `X.5.X` | État du protocole de livraison du courrier |
| `X.6.X` | État du contenu ou du média du message |
| `X.7.X` | État de la sécurité ou de la politique |

## Table complète des codes de détail

### X.1.X : adressage

| Code | Signification |
|---|---|
| X.1.0 | Autre état d'adresse |
| X.1.1 | Adresse de boîte aux lettres de destination invalide |
| X.1.2 | Adresse du système de destination invalide |
| X.1.3 | Syntaxe de l'adresse de boîte aux lettres de destination invalide |
| X.1.4 | Adresse de boîte aux lettres de destination ambiguë |
| X.1.5 | Adresse de destination valide |
| X.1.6 | La boîte aux lettres de destination a été déplacée, sans adresse de réexpédition |
| X.1.7 | Syntaxe de l'adresse de boîte aux lettres de l'expéditeur invalide |
| X.1.8 | Adresse du système de l'expéditeur invalide |

### X.2.X : boîte aux lettres

| Code | Signification |
|---|---|
| X.2.0 | Autre état de boîte aux lettres, ou non défini |
| X.2.1 | Boîte aux lettres désactivée, n'accepte pas de messages |
| X.2.2 | Boîte pleine |
| X.2.3 | La longueur du message dépasse la limite administrative |
| X.2.4 | Problème d'expansion de liste de diffusion |

### X.3.X : système de messagerie

| Code | Signification |
|---|---|
| X.3.0 | Autre état du système de messagerie, ou non défini |
| X.3.1 | Système de messagerie plein |
| X.3.2 | Le système n'accepte pas les messages du réseau |
| X.3.3 | Le système ne prend pas en charge les fonctionnalités choisies |
| X.3.4 | Message trop volumineux pour le système |
| X.3.5 | Système mal configuré |

### X.4.X : réseau et routage

| Code | Signification |
|---|---|
| X.4.0 | Autre état du réseau ou du routage, ou non défini |
| X.4.1 | Pas de réponse de l'hôte |
| X.4.2 | Mauvaise connexion |
| X.4.3 | Défaillance du serveur d'annuaire |
| X.4.4 | Routage impossible |
| X.4.5 | Congestion du système de messagerie |
| X.4.6 | Boucle de routage détectée |
| X.4.7 | Délai de livraison expiré |

### X.5.X : protocole de livraison du courrier

| Code | Signification |
|---|---|
| X.5.0 | Autre état du protocole, ou non défini |
| X.5.1 | Commande invalide |
| X.5.2 | Erreur de syntaxe |
| X.5.3 | Trop de destinataires |
| X.5.4 | Arguments de commande invalides |
| X.5.5 | Mauvaise version du protocole |

### X.6.X : contenu ou média du message

| Code | Signification |
|---|---|
| X.6.0 | Autre erreur de média, ou non définie |
| X.6.1 | Média non pris en charge |
| X.6.2 | Conversion nécessaire mais interdite |
| X.6.3 | Conversion nécessaire mais non prise en charge |
| X.6.4 | Conversion effectuée avec perte |
| X.6.5 | Échec de la conversion |

### X.7.X : sécurité ou politique

| Code | Signification |
|---|---|
| X.7.0 | Autre état de sécurité, ou non défini |
| X.7.1 | Livraison non autorisée, message refusé |
| X.7.2 | Expansion de liste de diffusion interdite |
| X.7.3 | Conversion de sécurité nécessaire mais impossible |
| X.7.4 | Fonctions de sécurité non prises en charge |
| X.7.5 | Échec cryptographique |
| X.7.6 | Algorithme cryptographique non pris en charge |
| X.7.7 | Échec de l'intégrité du message |

## Utiliser les codes pour classer les rebonds

Voici les combinaisons qui apportent le plus d'information à un moteur de suppression :

| État observé | Interprétation | Action typique |
|---|---|---|
| `5.1.1`, `5.1.2`, `5.1.3`, `5.1.6` | L'adresse n'existe pas, ne peut pas être routée ou a disparu | Rebond définitif : supprimer immédiatement. Les 5.1.1 répétés sont aussi le moyen par lequel les fournisseurs détectent les listes périmées |
| `5.2.1` | Boîte aux lettres désactivée | Supprimer. Le compte a été délaissé ou fermé |
| `4.2.2` | Boîte pleine | Rebond temporaire : réessayer, et supprimer si la situation se répète (souvent un compte délaissé) |
| `5.2.2` | Boîte pleine, signalée comme définitive | Traiter comme un 4.2.2 qui se répète |
| `4.3.x`, `4.4.x` | Problème du système ou du réseau de destination | Réessayer. Ce n'est pas un signal de qualité de la liste |
| `4.4.7` | Délai de livraison expiré (nouvelles tentatives épuisées) | Le côté expéditeur a renoncé. Chercher quelle condition sous-jacente a persisté |
| `5.3.4` / `X.2.3` | Message trop volumineux, ou dépassant une limite administrative | Corriger le message, pas la liste |
| `5.7.1` et autres `5.7.x` | Refus pour des raisons de politique ou de sécurité | **Un problème de réputation ou d'authentification, pas une adresse invalide.** Ne pas supprimer le destinataire en cas de refus pour raison de politique ; pour l'exception d'une seule adresse, voir [Les codes d'état et la règle de retrait du M3AAWG](#les-codes-détat-et-la-règle-de-retrait-du-m3aawg). Vérifier les listes de blocage, [DMARC, SPF et DKIM](https://emailmarketing.net/fr/apprendre/authentification/dmarc), ainsi que le volume et la chauffe (voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)) |
| `4.7.x` | Report temporaire pour des raisons de politique (liste grise, limitation de débit, « unusual volume ») | Ralentir. C'est le signal classique de limitation de débit pendant la chauffe |

Mises en garde :

- Le chiffre de classe décide de la manière de réessayer, même lorsque le sujet et le détail semblent le contredire. Dans le modèle de la RFC 3463, c'est le jugement du premier nombre sur le caractère définitif de l'échec qui l'emporte.
- Beaucoup de serveurs de réception ne renvoient qu'un code générique (`5.0.0`) ou un texte non standard. Les classificateurs fiables combinent le code étendu avec le texte libre du `Diagnostic-Code` (voir [Delivery Status Notifications](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison)).
- Des RFC ultérieures et des enregistrements IANA étendent cette liste. Par exemple, la RFC 7372 enregistre des codes 5.7.x supplémentaires pour les échecs SPF et DMARC. Les codes ci-dessus sont l'ensemble de base de la RFC 3463, commun à toutes les implémentations.

## Les codes d'état et la règle de retrait du M3AAWG

Le Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) fixe la référence du secteur pour le retrait des adresses qui produisent des rebonds, dans ses *Sender Best Common Practices* (version 4.0, août 2026, section 2.2). Ses recommandations comportent trois volets :

- Lorsque le serveur de réception indique qu'il n'y a personne à cette adresse (« user unknown »), ne réessayez pas, et supprimez l'adresse des envois futurs.
- Les codes numériques n'ont pas été conçus pour dire si une adresse devrait être retirée : les expéditeurs **doivent** donc lire le texte descriptif pour décider du traitement de l'adresse. Le texte peut désigner un problème d'infrastructure ou de contenu chez l'expéditeur, ou montrer que l'adresse IP de l'expéditeur figure sur une liste de blocage. Les expéditeurs **devraient** chercher à diagnostiquer et à corriger les problèmes de livraison des adresses qui semblent valides.
- Comme meilleure pratique générale, retirez une adresse qui produit un rebond au moins deux fois de suite, sur une période de deux semaines ou plus, quels que soient le code ou le texte. Chaque expéditeur choisit le nombre exact de campagnes et la durée, et la durée tient compte des problèmes de serveur côté réception qui peuvent provoquer un rebond par erreur.

Le tableau ci-dessus indique de ne pas supprimer le destinataire en cas de refus pour raison de politique `5.7.x`, avec une exception pour une seule adresse (cas 4 ci-dessous). La raison tient à ce que ces codes signalent d'ordinaire. Un `5.7.x` est un refus pour des raisons de sécurité ou de politique : une inscription sur une liste de blocage, un échec d'authentification, un blocage lié à la réputation. Ces causes relèvent de l'expéditeur, et elles touchent généralement de nombreux destinataires chez le même fournisseur au même moment. Supprimer toutes les adresses qui en ont reçu un retire de vrais abonnés à cause d'un problème de votre côté, et laisse le problème en place.

Appliquez les deux règles ensemble :

1. **Échecs liés à l'adresse** (`5.1.1`, `5.1.2`, `5.1.3`, `5.1.6` et `5.2.1`) : supprimez, comme l'indique le tableau. Ils correspondent au cas « user unknown » des recommandations du M3AAWG.
2. **Autres échecs qui se répètent pour une même adresse** (une boîte pleine de façon récurrente, ou un `5.0.0` générique dont le texte ne mentionne aucune politique) : comptez un rebond par campagne, et non un par nouvelle tentative. Retirez l'adresse lorsque le compteur atteint votre seuil et que les rebonds s'étendent sur au moins deux semaines. Deux campagnes constituent le minimum du M3AAWG ; un nombre plus élevé respecte toujours sa règle.
3. **Refus pour raison de politique ou de réputation** (`5.7.x`) : examinez au lieu de supprimer. Lisez le texte, vérifiez les listes de blocage et l'authentification, et corrigez la cause. Les rebonds reçus pendant que vous étiez bloqué ne disent rien des adresses : ne les comptez donc pas dans le compteur de retrait d'une adresse.
4. **Un `5.7.x` qui se répète pour une seule adresse**, sur au moins deux campagnes et deux semaines, alors que d'autres adresses du même domaine acceptent vos emails : cela désigne le destinataire, et non votre réputation (par exemple, une boîte qui refuse vos emails par choix de son titulaire). Traitez-le comme le cas 2, selon la règle de retrait du M3AAWG.

Pour la mécanique de suppression qu'applique une plateforme, voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation#suppression-lists-as-a-reputation-defense).

# Delivery Status Notifications : le format des DSN (RFC 3464)

> Comment sont structurés les messages de rebond : le format DSN multipart/report, les champs par message et par destinataire (Action, Status, Diagnostic-Code), et comment les expéditeurs devraient les analyser.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison

Pour traiter les rebonds automatiquement, vous devez lire le message de rebond lisible par une machine que renvoient les serveurs de messagerie. Lorsqu'un message ne peut pas être livré (ou que sa livraison est retardée, ou qu'une notification positive que vous avez demandée se déclenche), le MTA qui fait le rapport renvoie une **Delivery Status Notification (DSN)**, ou notification d'état de livraison, à l'expéditeur d'enveloppe.

La RFC 3464 définit le format normalisé de ce message. Tout processeur automatique de rebonds est, au fond, un analyseur de ce format, complété d'heuristiques pour les rebonds qui ne le respectent pas.

## Règles d'enveloppe

- Une DSN envoyée par SMTP **DOIT utiliser une adresse de retour nulle** : `MAIL FROM:<>`. Cela empêche les boucles de messagerie, car aucune DSN n'est jamais générée pour une DSN.
- Il s'ensuit que les rebonds arrivent à l'adresse que vous avez indiquée dans le `MAIL FROM` du message d'origine. Une adresse de retour qui encode chaque destinataire (**VERP**, par exemple `bounces+user=example.com@sender.com`) vous permet d'identifier le destinataire en échec même lorsque le corps de la DSN est mal formé. Elle permet aussi à un [processeur de feedback loop](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes) de réutiliser la même chaîne de suppression.
- Chaque destinataire indiqué par l'expéditeur DEVRAIT donner lieu à **au plus une** DSN « delivered » ou « failed ». Lorsqu'un message atteint un alias de liste de diffusion, le MTA de transfert DEVRAIT émettre une DSN « expanded » pour le destinataire d'origine, et ne devrait pas transmettre la demande de DSN aux adresses issues de l'expansion.

## Structure générale : multipart/report

Une DSN est un message MIME avec `Content-Type: multipart/report; report-type=delivery-status`. Elle contient :

| Partie | Content-Type | Rôle |
|---|---|---|
| 1 | `text/plain` (en général) | Une explication de ce qui s'est passé, à lire par un humain |
| 2 | `message/delivery-status` | L'état sous une forme qu'une machine peut analyser. C'est la partie que lisent les processeurs de rebonds |
| 3 | `message/rfc822` ou `text/rfc822-headers` | Le message d'origine renvoyé (ou ses en-têtes). Facultatif |

La partie `message/delivery-status` est un ensemble de groupes de champs écrits comme des en-têtes : un groupe **par message**, puis un groupe **par destinataire** pour chaque destinataire rapporté. Une ligne vide sépare les groupes.

## Champs par message

| Champ | Obligatoire ? | Syntaxe et signification |
|---|---|---|
| `Reporting-MTA` | **Obligatoire** | `mta-name-type; mta-name` : le MTA qui rapporte le résultat, par exemple `dns; mail.example.net` |
| `Original-Envelope-Id` | Facultatif | Identifiant de transaction fourni à la soumission, pour rapprocher la DSN de l'envoi d'origine |
| `DSN-Gateway` | Conditionnel | Présent uniquement quand la DSN a été traduite depuis un système de rapport étranger (non Internet) |
| `Received-From-MTA` | Facultatif | Nom du MTA dont le message a été reçu |
| `Arrival-Date` | Facultatif | Date et heure RFC 822 d'arrivée du message au MTA qui fait le rapport |

Les noms de MTA sont sensibles à la casse, et leur orthographe doit être conservée exactement.

## Champs par destinataire

| Champ | Obligatoire ? | Syntaxe et signification |
|---|---|---|
| `Final-Recipient` | **Obligatoire** | `address-type; generic-address` : l'adresse du destinataire telle que l'a vue le MTA qui fait le rapport |
| `Action` | **Obligatoire** | L'une des cinq valeurs ci-dessous |
| `Status` | **Obligatoire** | Code d'état étendu, `DIGIT.1*3DIGIT.1*3DIGIT` (par exemple `5.1.1`) |
| `Original-Recipient` | Facultatif | L'adresse telle que l'expéditeur l'a indiquée à l'origine (avant transfert ou réécriture) |
| `Remote-MTA` | Facultatif | Le MTA du saut suivant impliqué dans la tentative de livraison rapportée |
| `Diagnostic-Code` | Facultatif | `diagnostic-type; text` : l'erreur réelle au niveau du transport, par exemple la réponse SMTP complète du serveur distant |
| `Last-Attempt-Date` | Facultatif | Date et heure RFC 822 de la dernière tentative de livraison |
| `Final-Log-ID` | Facultatif | Référence dans le journal de livraison du MTA qui fait le rapport |
| `Will-Retry-Until` | Facultatif | Pour `delayed` uniquement : le moment où le MTA abandonnera |

### Valeurs d'Action (exactement cinq, insensibles à la casse)

| Action | Signification | Traitement par un processeur de rebonds |
|---|---|---|
| `failed` | N'a pas pu être livré, et la livraison est abandonnée définitivement | C'est le rebond. Classez-le à l'aide de `Status` et de `Diagnostic-Code` |
| `delayed` | Pas encore livré ; les tentatives continuent (voir `Will-Retry-Until`) | Informatif. Ne supprimez pas l'adresse, car une DSN `failed` peut suivre ou non |
| `delivered` | Livré avec succès à l'adresse du destinataire | Une DSN positive (envoyée uniquement si elle est demandée) ; ce n'est pas un rebond |
| `relayed` | Transmis vers un environnement qui ne prend pas la responsabilité des DSN | Terminal du point de vue des DSN, mais ce n'est pas une preuve de livraison |
| `expanded` | Livré à l'adresse indiquée par l'expéditeur, qui était un alias ou une liste à plusieurs destinataires qui a renvoyé le message | Non terminal ; utilisé uniquement pour les alias à plusieurs destinataires |

### Status et Diagnostic-Code

- `Status` porte le [code d'état étendu](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp), qui ne dépend pas du transport. C'est la clé de classement principale (`4.x.x` temporaire, `5.x.x` définitif).
- `Diagnostic-Code` conserve l'erreur de transport brute. Lorsque son type est `smtp`, le texte est la réponse SMTP du serveur distant. La RFC note qu'il est « quelque peu redondant » avec `Status`, mais qu'il est fourni pour conserver l'information d'origine. Lorsque `Remote-MTA` est présent, le diagnostic vient de ce MTA ; sinon, il vient du MTA qui fait le rapport. En pratique, le texte du diagnostic contient souvent des détails propres au fournisseur (noms de listes de blocage, URL de politique, « user unknown ») que le `Status` numérique ne donne pas, donc analysez les deux.

### Conventions de type

- Les valeurs `address-type`, `mta-name-type` et `diagnostic-type` sont des atomes insensibles à la casse. Les valeurs standard sont `rfc822` (adresses), `dns` (noms de MTA) et `smtp` (diagnostics). `unknown` sert quand le type ne peut pas être déterminé, le préfixe `X-` marque les types expérimentaux, et les nouveaux types sont enregistrés auprès de l'IANA.
- Le contenu qui suit le type peut être sensible à la casse (les parties locales des boîtes aux lettres, par exemple) et doit être conservé exactement.

## Exemple (tiré de la RFC)

```
Reporting-MTA: dns; cs.utk.edu

Original-Recipient: rfc822;louisl@larry.slip.umd.edu
Final-Recipient: rfc822;louisl@larry.slip.umd.edu
Action: failed
Status: 4.0.0
Diagnostic-Code: smtp; 426 connection timed out
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
```

## Conseils d'analyse pour les expéditeurs

1. **Identifiez le destinataire.** Privilégiez `Original-Recipient`, et à défaut `Final-Recipient`. Retirez le préfixe de type `rfc822;`. Si le corps ne peut pas être analysé, rabattez-vous sur l'adresse de retour encodée par VERP.
2. **Filtrez sur `Action`.** Seul `failed` doit entraîner une suppression. Ignorez `delayed` pour l'hygiène de base de données, mais journalisez-le pour la surveillance de la livraison. Traitez `delivered`, `relayed` et `expanded` comme des messages qui ne sont pas des rebonds.
3. **Classez sur `Status`.** Envoyez `5.x.x` vers votre logique de rebond définitif et `4.x.x` vers vos compteurs de rebonds temporaires. Utilisez la [table des codes de détail](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp) pour séparer les codes d'adresse invalide (à supprimer) des codes de politique ou de réputation (à investiguer). Une vague de `5.7.1` est un problème d'expéditeur, pas un problème de liste.
4. **Affinez sur `Diagnostic-Code`.** Des règles par expression régulière ou par mot-clé, appliquées au texte SMTP brut, détectent les situations propres à un fournisseur que le code numérique masque (listes de blocage nommées, « spam content », avis de limitation de débit).
5. **Attendez-vous à plusieurs groupes de destinataires dans une même DSN.** Un seul message de rebond peut rapporter plusieurs destinataires, donc traitez chaque groupe séparément.
6. **Attendez-vous à des rebonds qui ne respectent pas le format.** Beaucoup de rebonds réels sont du texte libre sans aucune partie `message/delivery-status`. L'analyse selon la RFC 3464 est la voie rapide ; gardez une solution de repli heuristique, avec VERP comme filet de sécurité.
7. **Ne répondez jamais automatiquement à une DSN**, et n'envoyez jamais vos propres rebonds avec une adresse de retour non nulle. C'est la règle `MAIL FROM:<>` qui préserve l'écosystème de l'email des boucles.

# ActiveCampaign : configuration de DKIM et DMARC

> Comment configurer votre domaine d'envoi dans ActiveCampaign : ajouter le domaine dans Advanced Settings, le vérifier, ajouter les enregistrements DKIM, Mailserver Domain et DMARC, puis confirmer l'état Authenticated, chaque étape renvoyant au centre d'aide actuel d'ActiveCampaign.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/guides-par-esp/activecampaign

Ce guide suit le centre d'aide d'ActiveCampaign, consulté le 2026-09-11. Chaque étape renvoie à la page dont elle provient. Les noms de menus et les valeurs des enregistrements peuvent changer : si l'application affiche autre chose, l'application et la page d'aide actuelle d'ActiveCampaign font foi.

Pour les protocoles eux-mêmes, voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Avant de commencer

- Vous devez avoir accès aux paramètres DNS de votre domaine, généralement chez votre bureau d'enregistrement ou votre hébergeur.
- Envoyez depuis un domaine qui vous appartient. L'aide d'ActiveCampaign indique : « veillez à utiliser un domaine d'envoi établi qui vous appartient. En outre, votre domaine doit avoir plus de 30 jours et pointer vers un site web valide, pas vers une page vide. » ([SPF, DKIM, and DMARC Authentication](https://help.activecampaign.com/hc/en-us/articles/206903370-SPF-DKIM-and-DMARC-Authentication))

## Ce qu'ActiveCampaign vous demande de publier

| Rôle | Type d'enregistrement | Nombre | Origine des valeurs |
|---|---|---|---|
| DKIM | `CNAME` | Selon la liste | Nom du type `acdkim1._domainkey` ; valeur affichée dans ActiveCampaign |
| Mailserver Domain (chemin de retour) | `CNAME` | 1 | Affiché dans ActiveCampaign |
| DMARC | `TXT` | 1 | Enregistrement de base affiché dans ActiveCampaign |

ActiveCampaign : l'authentification « consiste à publier des enregistrements DNS (DKIM, Mailserver Domain/SPF et DMARC) », chacun de type « CNAME ou TXT » ([Set up your sending domain](https://help.activecampaign.com/hc/en-us/articles/360015584680-Set-up-your-sending-domain)). Le centre d'aide présente la liste complète des enregistrements sous forme d'image : copiez donc les lignes depuis le tableau de votre compte.

## Étape 1 : ajouter le domaine d'envoi

1. Cliquez sur **Settings** (icône en forme d'engrenage).
2. Dans le menu Settings, cliquez sur **Advanced**.
3. Dans la section **Sending Domain**, choisissez **Configure Domain** ou **Set up manually**. **Configure Domain** se connecte aux fournisseurs DNS pris en charge et crée les enregistrements pour vous, une fois que vous vous êtes connecté à votre fournisseur DNS. La suite de ce guide suit **Set up manually**.
4. Saisissez le domaine de l'adresse depuis laquelle vous enverrez (pour `sales@mycompany.com`, saisissez `mycompany.com`, sans `https://`).

Source : [Set up your sending domain](https://help.activecampaign.com/hc/en-us/articles/360015584680-Set-up-your-sending-domain).

## Étape 2 : vérifier le domaine

La vérification est obligatoire : « Vous devez vérifier votre domaine et vos sous-domaines avant d'envoyer le moindre email ».

1. Dans la fenêtre **Verify your domain**, saisissez une adresse email du domaine, puis cliquez sur **Continue**.
2. Ouvrez l'email de vérification (il expire au bout de sept jours) et cliquez sur le lien. S'il n'est pas arrivé, cliquez sur **Resend verification email** dans le tableau Sending Domains.
3. De retour dans ActiveCampaign, cliquez sur **Set up DNS records**.

Source : [Set up your sending domain](https://help.activecampaign.com/hc/en-us/articles/360015584680-Set-up-your-sending-domain).

## Étape 3 : ajouter les enregistrements DKIM et Mailserver Domain

Une fenêtre affiche un tableau des noms et valeurs des enregistrements. Chez votre fournisseur DNS, créez chaque enregistrement `CNAME` du tableau :

- **Type** : le type indiqué pour la ligne.
- **Nom ou hôte** : le **Name** donné par ActiveCampaign, par exemple `acdkim1._domainkey`, ou le nom complet `acdkim1._domainkey.mydomain.com` si votre fournisseur DNS n'ajoute pas le domaine automatiquement.
- **Valeur ou contenu** : la **Value** donnée par ActiveCampaign.
- **TTL** : la valeur par défaut de votre hébergeur DNS ; s'il n'y en a pas, ActiveCampaign recommande `300`.

DKIM utilise des enregistrements `CNAME` : « Depuis le 23 février 2023, ActiveCampaign est passé d'un enregistrement TXT à un enregistrement CNAME pour DKIM » ([Troubleshooting issues with domain authentication](https://help.activecampaign.com/hc/en-us/articles/12372243669404-Troubleshooting-issues-with-domain-authentication)). Le `CNAME` Mailserver Domain fait pointer votre domaine vers ActiveCampaign, afin qu'il puisse utiliser votre domaine comme domaine de chemin de retour (return path) ([Domains and domain alignment](https://help.activecampaign.com/hc/en-us/articles/360014290939-Domains-and-domain-alignment)).

Source : [Set up your sending domain](https://help.activecampaign.com/hc/en-us/articles/360015584680-Set-up-your-sending-domain).

## Étape 4 : ajouter l'enregistrement DMARC

Créez l'enregistrement `TXT` DMARC à partir du même tableau. ActiveCampaign le présente comme « un enregistrement DMARC de base, au strict minimum » ([SPF, DKIM, and DMARC Authentication](https://help.activecampaign.com/hc/en-us/articles/206903370-SPF-DKIM-and-DMARC-Authentication)).

Si votre domaine a déjà un enregistrement DMARC, n'en ajoutez pas un second : quand un serveur de réception trouve plus d'un enregistrement DMARC, il n'applique aucun traitement DMARC ([RFC 7489 §6.6.3](https://www.rfc-editor.org/rfc/rfc7489#section-6.6.3)). Consultez [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) avant de modifier une politique existante.

Source : [Set up your sending domain](https://help.activecampaign.com/hc/en-us/articles/360015584680-Set-up-your-sending-domain).

## Étape 5 : attendre la propagation et vérifier l'état

« En général, l'enregistrement DNS se propage en 5 à 10 minutes, mais dans de rares cas, cela peut prendre jusqu'à 24 heures ». Pour vérifier, revenez à la page Advanced Settings, cliquez sur la flèche vers le bas tout à droite du domaine, puis sur **Recheck Authentication** ou **View DNS Records**. Une fois les enregistrements propagés, le domaine affiche l'état **Authenticated** avec un indicateur vert. Sinon, un bouton **Resolve Issues** apparaît ; il lance le parcours **Configure Domain**.

Source : [Set up your sending domain](https://help.activecampaign.com/hc/en-us/articles/360015584680-Set-up-your-sending-domain).

## SPF

La configuration du domaine d'envoi d'ActiveCampaign ne comporte pas d'étape d'enregistrement SPF. Son aide indique que le `CNAME` Mailserver Domain « permet à ActiveCampaign de publier pour vous l'enregistrement SPF nécessaire » et que « vous n'avez pas besoin de créer un enregistrement SPF ni de modifier un enregistrement existant pour utiliser ActiveCampaign » ([SPF, DKIM, and DMARC Authentication](https://help.activecampaign.com/hc/en-us/articles/206903370-SPF-DKIM-and-DMARC-Authentication)). Par ailleurs, ActiveCampaign documente une étape SPF facultative pour votre domaine From, qui consiste à ajouter `include:emsd1.com` à votre enregistrement SPF, et qui selon lui « n'est pas nécessaire pour que SPF réussisse » ([How to merge or update existing SPF records](https://help.activecampaign.com/hc/en-us/articles/13063110494364-How-to-merge-or-update-existing-SPF-records)). Vérifié le 2026-09-11 : les pages d'aide d'ActiveCampaign listées dans les sources de ce guide.

## Comment fonctionne l'alignement ici

DMARC réussit quand un message passe DKIM ou SPF **et** que le domaine validé est aligné sur le domaine de l'adresse From visible ; un seul passage aligné suffit. Envoyez depuis une adresse du domaine que vous avez configuré. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) pour la façon dont l'alignement est évalué.

## Vérifier votre configuration

Une fois qu'ActiveCampaign affiche **Authenticated**, lancez le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) gratuit sur votre domaine pour voir ce que les serveurs de réception trouvent dans le DNS pour SPF, DKIM et DMARC.

Le diagnostic cherche DKIM sous une liste fixe de sélecteurs courants : il peut donc ne pas trouver seul votre enregistrement DKIM ActiveCampaign. Indiquez-lui votre sélecteur via l'API du diagnostic : `https://emailmarketing.net/api/domain-check?domain=yourdomain.com&selector=<selector>`. Le sélecteur est la partie du nom de l'enregistrement DKIM qui précède `._domainkey`. Pour ActiveCampaign, c'est le début du **Name** de l'enregistrement DKIM affiché dans votre compte ; l'aide d'ActiveCampaign prend `acdkim1` comme exemple (`acdkim1._domainkey`).

# Brevo : configuration de DKIM et DMARC

> Comment authentifier votre domaine d'envoi dans Brevo : ajouter le domaine, ajouter les enregistrements Brevo code, DKIM et DMARC, puis confirmer l'état Authenticated, chaque étape renvoyant au centre d'aide actuel de Brevo.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/guides-par-esp/brevo

Ce guide suit le centre d'aide de Brevo, consulté le 2026-09-11. Chaque étape renvoie à la page dont elle provient. Les noms de menus et les valeurs des enregistrements peuvent changer : si l'application affiche autre chose, l'application et la page d'aide actuelle de Brevo font foi.

Pour les protocoles eux-mêmes, voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Avant de commencer

- Vous devez avoir accès aux paramètres DNS de votre domaine, généralement chez votre bureau d'enregistrement ou votre hébergeur.
- Envoyez depuis une adresse d'un domaine qui vous appartient. L'aide de Brevo indique : « Vous ne pouvez authentifier qu'un domaine que vous ou votre entreprise possédez et contrôlez. Les domaines des services de messagerie gratuits, comme Gmail ou Yahoo (par exemple @gmail.com ou @yahoo.com), ne peuvent pas être authentifiés. » ([Authenticate your domain with Brevo](https://help.brevo.com/hc/en-us/articles/12163873383186))
- Brevo déploie progressivement un nouveau parcours de configuration des domaines. Si votre compte en dispose, suivez plutôt [Set up your domain in Brevo](https://help.brevo.com/hc/en-us/articles/35337929909778) ; ce guide couvre le parcours actuel.

## Ce que Brevo vous demande de publier

| Rôle | Type d'enregistrement | Nombre | Origine des valeurs |
|---|---|---|---|
| Propriété du domaine (Brevo code) | `TXT` | 1 | Nom et valeur affichés dans Brevo |
| DKIM | `TXT` ou `CNAME` | 1 `TXT` ou 2 `CNAME` | Affichés dans Brevo comme DKIM record, ou DKIM 1 et DKIM 2 |
| DMARC | `TXT` | 1 | Nom et valeur affichés dans Brevo |

Brevo : « Selon votre compte Brevo, vous devrez peut-être ajouter trois ou quatre enregistrements. » ([Authenticate your domain with Brevo](https://help.brevo.com/hc/en-us/articles/12163873383186))

## Étape 1 : ajouter le domaine

1. Cliquez sur le menu déroulant du compte et sélectionnez **Settings > Senders, Domains, IPs > Domains**.
2. Cliquez sur **Add a domain**. Si le domaine figure déjà dans la liste, cliquez plutôt sur **Authenticate** à côté de lui.
3. Saisissez le domaine, c'est-à-dire la partie de votre adresse email qui suit le `@`, puis cliquez sur **Add domain**.

Source : [Authenticate your domain with Brevo](https://help.brevo.com/hc/en-us/articles/12163873383186).

## Étape 2 : choisir l'authentification automatique ou manuelle

**Authenticate the domain automatically** est l'option par défaut et recommandée par Brevo : vous vous connectez à votre fournisseur de domaine depuis Brevo, et « Brevo détecte votre fournisseur, ajoute les enregistrements DNS nécessaires (Brevo code, DKIM, DMARC) et vérifie la configuration ». Si votre domaine a déjà un enregistrement DMARC, ce parcours vous demande s'il faut le remplacer par celui de Brevo ; pour garder le vôtre, authentifiez plutôt le domaine manuellement.

Pour le parcours manuel, sélectionnez **Authenticate the domain yourself**. Brevo affiche les enregistrements à copier dans le compte de votre fournisseur de domaine. **Ask someone else to authenticate the domain** envoie les instructions à une autre personne.

Source : [Authenticate your domain with Brevo](https://help.brevo.com/hc/en-us/articles/12163873383186).

## Étape 3 : ajouter les enregistrements Brevo code et DKIM

Chez votre fournisseur DNS, créez l'enregistrement `TXT` du **Brevo code** avec le nom et la valeur affichés par Brevo, en utilisant ses boutons de copie. Ajoutez ensuite le type d'enregistrement DKIM que votre compte affiche : soit **DKIM 1 record** et **DKIM 2 record** (`CNAME`), soit un seul **DKIM record** (`TXT`).

Si vous utilisez Cloudflare avec des enregistrements DKIM `CNAME`, désactivez le CNAME flattening et le bouton de proxy. Brevo : « Si le CNAME flattening est activé, Cloudflare convertit l'enregistrement en enregistrement TXT, et l'authentification DKIM échoue. »

Source : [Authenticate your domain with Brevo](https://help.brevo.com/hc/en-us/articles/12163873383186).

## Étape 4 : ajouter l'enregistrement DMARC

Créez un enregistrement `TXT` avec le nom et la valeur DMARC affichés par Brevo.

Si votre domaine a déjà un enregistrement DMARC, n'en ajoutez pas un second : quand un serveur de réception trouve plus d'un enregistrement DMARC, il n'applique aucun traitement DMARC ([RFC 7489 §6.6.3](https://www.rfc-editor.org/rfc/rfc7489#section-6.6.3)). Brevo précise aussi : « Votre domaine ne doit avoir qu'un seul enregistrement DMARC. » Consultez [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) avant de modifier une politique existante.

Source : [Authenticate your domain with Brevo](https://help.brevo.com/hc/en-us/articles/12163873383186).

## Étape 5 : vérifier et contrôler l'état

Dans Brevo, cliquez sur **Authenticate this email domain** en bas de la page qui présente les enregistrements DNS. « La propagation des modifications DNS et l'affichage de votre domaine comme authentifié dans Brevo peuvent parfois prendre jusqu'à 48 heures. » L'état affiche **Authenticated**, ou une fenêtre indique « The domain is not authenticated yet » ; vous pouvez relancer la vérification au cours des 48 heures suivantes. Au-delà, consultez l'[article de dépannage](https://help.brevo.com/hc/en-us/articles/16045394674066) de Brevo ou contactez son support.

Source : [Authenticate your domain with Brevo](https://help.brevo.com/hc/en-us/articles/12163873383186).

## Étape 6 : conserver les enregistrements

« Conservez les enregistrements DNS tels quels chez votre fournisseur de domaine tant que vous utilisez Brevo pour envoyer des emails. Modifier ou supprimer ces enregistrements DNS peut entraîner des problèmes de livraison, ou le classement de vos emails en spam. »

Source : [Authenticate your domain with Brevo](https://help.brevo.com/hc/en-us/articles/12163873383186).

## SPF

L'aide de Brevo ne donne pas d'étape d'enregistrement SPF pour l'authentification du domaine. Elle indique : « Les enregistrements SPF et MX ne sont pas nécessaires pour authentifier un domaine. Nous ne fournissons ces enregistrements que lors de la configuration d'une adresse IP dédiée. » ([Authenticate your domain with Brevo](https://help.brevo.com/hc/en-us/articles/12163873383186)) Ce guide n'en donne pas non plus.

## Comment fonctionne l'alignement ici

DMARC réussit quand un message passe DKIM ou SPF **et** que le domaine validé est aligné sur le domaine de l'adresse From visible ; un seul passage aligné suffit. Envoyez depuis une adresse du domaine que vous avez authentifié. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) pour la façon dont l'alignement est évalué.

## Vérifier votre configuration

Une fois que Brevo affiche **Authenticated**, lancez le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) gratuit sur votre domaine pour voir ce que les serveurs de réception trouvent dans le DNS pour SPF, DKIM et DMARC.

Le diagnostic cherche DKIM sous une liste fixe de sélecteurs courants : il peut donc ne pas trouver seul votre enregistrement DKIM Brevo. Indiquez-lui votre sélecteur via l'API du diagnostic : `https://emailmarketing.net/api/domain-check?domain=yourdomain.com&selector=<selector>`. Le sélecteur est la partie du nom de l'enregistrement DKIM qui précède `._domainkey`. Pour Brevo, prenez-le dans le nom de l'enregistrement DKIM (ou DKIM 1) affiché dans votre compte ; l'aide de Brevo ne donne pas de valeur fixe.

# Cakemail : configuration de DKIM et DMARC

> Comment authentifier votre domaine d'envoi dans Cakemail : vérifier l'expéditeur, ajouter les enregistrements TXT DKIM et DMARC ainsi que les enregistrements CNAME de suivi et de rebond, puis confirmer l'état Authenticated, chaque étape renvoyant au centre d'aide actuel de Cakemail.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/guides-par-esp/cakemail

Ce guide suit le centre d'aide de Cakemail, consulté le 2026-09-11. Chaque étape renvoie à la page dont elle provient. Les noms de menus et les valeurs des enregistrements peuvent changer : si l'application affiche autre chose, l'application et la page d'aide actuelle de Cakemail font foi.

Pour les protocoles eux-mêmes, voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Avant de commencer

- Vous devez avoir accès aux paramètres DNS de votre domaine, généralement chez votre bureau d'enregistrement ou votre hébergeur.
- Envoyez depuis une adresse d'un domaine qui vous appartient. L'aide de Cakemail indique : « L'authentification ne fonctionne que pour un domaine privé que vous contrôlez », et un domaine de messagerie web public comme `gmail.com` ne peut pas être authentifié ([Authenticating Your Domain](https://docs.cakemail.com/en/docs/senders/authenticating-domains)).

## Ce que Cakemail vous demande de publier

| Rôle | Type d'enregistrement | Nombre | Origine des valeurs |
|---|---|---|---|
| DKIM | `TXT` | 1 | Nom `c[CID]._domainkey.[DOMAIN].` ; valeur affichée dans **Settings ▸ Domains** |
| DMARC | `TXT` | 1 | Nom `_dmarc.[DOMAIN]` ; valeur `v=DMARC1; p=none;` |
| Suivi et rebond | `CNAME` | 2 | `link.[DOMAIN]` et `em.[DOMAIN]`, affichés dans **Settings ▸ Domains** |

`[DOMAIN]` est votre domaine d'envoi et `[CID]` votre Client ID ([Adding DNS Records](https://docs.cakemail.com/en/docs/senders/adding-dns-records)).

## Étape 1 : vérifier l'expéditeur

Un expéditeur doit être vérifié avant de pouvoir envoyer : « Vous ne pouvez envoyer des campagnes que depuis un expéditeur vérifié ».

1. Dans le menu de gauche, allez dans **Settings ▸ Senders**.
2. Cliquez sur **+**, renseignez **Sender Name (Public)** et **Email**, puis cliquez sur **Confirm**.
3. Ouvrez l'email de vérification envoyé à cette adresse et cliquez sur le lien. L'expéditeur apparaît alors comme **VERIFIED**.

Source : [Adding a Sender](https://docs.cakemail.com/en/docs/senders/managing-senders).

## Étape 2 : lancer l'authentification

1. Dans le menu de gauche, allez dans **Settings ▸ Domains**.
2. Dans **Sender Domains**, repérez votre domaine d'envoi. S'il affiche **Unauthenticated**, cliquez sur **Authenticate Domain**. (Si le domaine n'apparaît pas encore, cliquez d'abord sur **Create Sender and Domain**.)
3. À la première étape de l'assistant, ouvrez votre fournisseur DNS dans un nouvel onglet, ou cliquez sur **Copy instructions** pour transmettre la configuration à la personne qui gère votre DNS.

Source : [Authenticating Your Domain](https://docs.cakemail.com/en/docs/senders/authenticating-domains).

## Étape 3 : ajouter l'enregistrement DKIM

Chez votre fournisseur DNS, créez l'enregistrement `TXT` affiché par Cakemail. Copiez le **Name** et la **Value** avec les boutons **Copy to clipboard** plutôt que de les saisir à la main. La valeur est proposée en quatre variantes : copiez **Variant 1**, qui selon Cakemail « couvre la majorité des cas ».

Si votre fournisseur DNS n'accepte qu'un préfixe (par exemple `..._domainkey` au lieu de `..._domainkey.yourdomain.com`), cela convient.

Source : [Authenticating Your Domain](https://docs.cakemail.com/en/docs/senders/authenticating-domains).

## Étape 4 : ajouter l'enregistrement DMARC

Cakemail vérifie la présence d'un enregistrement DMARC. Si votre domaine n'en a pas, créez un enregistrement `TXT` avec pour **Name** `_dmarc.yourdomain.com` et pour **Value** `v=DMARC1; p=none;`.

Si votre domaine a déjà un enregistrement DMARC, n'en ajoutez pas un second : quand un serveur de réception trouve plus d'un enregistrement DMARC, il n'applique aucun traitement DMARC ([RFC 7489 §6.6.3](https://www.rfc-editor.org/rfc/rfc7489#section-6.6.3)). Consultez [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) avant de modifier une politique existante.

Source : [Authenticating Your Domain](https://docs.cakemail.com/en/docs/senders/authenticating-domains).

## Étape 5 : attendre la vérification et contrôler l'état

Cliquez sur **Continue**. « Les modifications DNS prennent généralement quelques heures à s'appliquer, et parfois jusqu'à 24–48 heures. » Cakemail vérifie alors les enregistrements DKIM et DMARC, et le domaine apparaît comme **Authenticated**. S'il affiche encore **Unverified** après 48 heures, copiez à nouveau les enregistrements et cherchez d'éventuels espaces en trop, ou contactez le support de Cakemail.

Source : [Authenticating Your Domain](https://docs.cakemail.com/en/docs/senders/authenticating-domains).

## Étape 6 : aligner les domaines de suivi et de rebond

Cakemail présente cette étape comme « non obligatoire, mais fortement recommandée ».

1. Dans **Settings ▸ Domains**, faites défiler jusqu'à **Tracking and Bounce domain alignment** et sélectionnez votre domaine.
2. Ajoutez les deux enregistrements `CNAME` affichés, un enregistrement **Tracking** (`link.yourdomain.com`) et un enregistrement **Bounce** (`em.yourdomain.com`), exactement tels qu'ils apparaissent.
3. Après la propagation, le **Status** de chaque enregistrement passe de **Not valid** à valide.

Le domaine de suivi porte les liens de vos campagnes ; le domaine de rebond « reçoit les notifications d'état de livraison des emails qui rebondissent ».

Source : [Tracking and Bounce Domains](https://docs.cakemail.com/en/docs/senders/tracking-and-bounce-domains).

## SPF

Les pages d'aide actuelles de Cakemail sur l'authentification des domaines listent les enregistrements DKIM, DMARC, de suivi et de rebond. Elles ne documentent pas d'étape d'enregistrement SPF ; ce guide n'en donne donc pas. Vérifié le 2026-09-11 : toutes les pages en anglais du [centre d'aide de Cakemail](https://docs.cakemail.com/en/llms.txt) ; l'ancien article de support.cakemail.com sur le branding du domaine d'expéditeur n'a pas pu être récupéré.

## Comment fonctionne l'alignement ici

DMARC réussit quand un message passe DKIM ou SPF **et** que le domaine validé est aligné sur le domaine de l'adresse From visible ; un seul passage aligné suffit. Envoyez depuis une adresse du domaine que vous avez authentifié. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) pour la façon dont l'alignement est évalué.

## Vérifier votre configuration

Une fois que Cakemail affiche **Authenticated**, lancez le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) gratuit sur votre domaine pour voir ce que les serveurs de réception trouvent dans le DNS pour SPF, DKIM et DMARC.

Le diagnostic cherche DKIM sous une liste fixe de sélecteurs courants : il peut donc ne pas trouver seul votre enregistrement DKIM Cakemail. Indiquez-lui votre sélecteur via l'API du diagnostic : `https://emailmarketing.net/api/domain-check?domain=yourdomain.com&selector=<selector>`. Le sélecteur est la partie du nom de l'enregistrement DKIM qui précède `._domainkey`. Pour Cakemail, c'est `c` suivi de votre Client ID, tiré du Name de l'enregistrement DKIM `c[CID]._domainkey.[DOMAIN].`.

# Constant Contact : configuration de DKIM et DMARC

> Comment auto-authentifier votre domaine d'envoi dans Constant Contact : choisir des enregistrements DKIM CNAME ou TXT, ajouter les enregistrements DKIM et DMARC, puis activer l'auto-authentification, chaque étape renvoyant à la base de connaissances actuelle de Constant Contact.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/guides-par-esp/constantcontact

Ce guide suit la base de connaissances de Constant Contact, consultée le 2026-09-11. Chaque étape renvoie à la page dont elle provient. Les noms de menus et les valeurs des enregistrements peuvent changer : si l'application affiche autre chose, l'application et la page d'aide actuelle de Constant Contact font foi.

Pour les protocoles eux-mêmes, voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Avant de commencer

- Vous devez avoir accès aux paramètres DNS de votre domaine. L'aide de Constant Contact indique : « Pour auto-authentifier vos emails, vous devez pouvoir accéder aux enregistrements DNS de votre domaine, généralement via votre hébergeur. » ([Self-authenticate your emails using your own domain](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain))
- Envoyez depuis une adresse d'un domaine qui vous appartient. Depuis une adresse de messagerie web gratuite, Constant Contact réécrit votre adresse From « avec notre domaine partagé ccsend.com » ([Understanding email authentication](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5865-Understanding-email-authentication)).
- « Vous ne pouvez authentifier qu'un seul domaine dans votre compte » (même page que le premier point).

## Ce que Constant Contact vous demande de publier

| Rôle | Type d'enregistrement | Nombre | Origine des valeurs |
|---|---|---|---|
| DKIM, option CNAME | `CNAME` | 2 | Générés dans Constant Contact ; noms `ctct1._domainkey` et `ctct2._domainkey`, valeurs pointant vers `ccsend.com` |
| DKIM, option TXT | `TXT` | 1 | Nom d'hôte et valeur générés dans Constant Contact ; la valeur commence par `k=rsa;` |
| DMARC | `TXT` | 1 | Nom et valeur générés dans Constant Contact |

Constant Contact : « Constant Contact génère les informations de l'enregistrement CNAME ou TXT, ainsi que celles de la politique DMARC, que vous devrez publier dans les paramètres DNS de votre domaine » ([Self-authenticate your emails using your own domain](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain)). Ses exemples de noms CNAME sont `ctct1._domainkey.halfmoonyogastudio.com` et `ctct2._domainkey.halfmoonyogastudio.com` ([Update your DNS records through your hosting provider](https://knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/39520-Update-your-DNS-records-through-your-hosting-provider-to-finish-setting-up-self-authentication)), et sa page de dépannage donne pour valeurs CNAME `100._domainkey.dkim1.ccsend.com` ou `200._domainkey.dkim2.ccsend.com` ([Troubleshooting DKIM self-authentication](https://knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/49735-Troubleshooting-DKIM-self-authentication-using-CNAME-TXT-and-DMARC)).

## Étape 1 : lancer l'auto-authentification

1. Cliquez sur le nom du profil en haut à droite et sélectionnez **Settings** dans le menu déroulant.
2. Cliquez sur l'onglet **Advanced settings**, puis sur **Add self-authentication**.
3. Sélectionnez **Self-authenticate using DKIM CNAME records** ou **Self-authenticate using DKIM TXT record**, puis cliquez sur **Continue**. Constant Contact présente les enregistrements CNAME comme « la façon la plus simple et la plus sûre d'authentifier l'adresse email de votre domaine » ; l'enregistrement TXT « est la meilleure option si plusieurs comptes Constant Contact utilisent le même domaine ».

Source : [Self-authenticate your emails using your own domain](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain).

## Étape 2 : choisir le domaine

1. Dans le menu déroulant, sélectionnez le domaine à auto-authentifier. S'il n'y figure pas, choisissez **Select another domain** pour ajouter et vérifier une nouvelle adresse email.
2. Cliquez sur **Continue**. Si le message « This domain is already authenticated in another Constant Contact account » s'affiche, utilisez plutôt l'option TXT.
3. Avec l'option TXT, cliquez sur **Generate key**. Constant Contact prévient : « Vous ne pourrez pas envoyer d'emails tant que vos enregistrements DNS ne se seront pas entièrement propagés, ce qui peut prendre jusqu'à 48 heures. »

Source : [Self-authenticate your emails using your own domain](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain).

## Étape 3 : ajouter les enregistrements DKIM

Utilisez les symboles de copie pour copier chaque nom et chaque valeur d'enregistrement chez votre fournisseur DNS, ou cliquez sur **Copy information** pour les transmettre à la personne qui gère votre DNS. Pour l'option TXT, créez un enregistrement `TXT` « en utilisant le Host name comme nom de l'enregistrement TXT et la Value comme contenu de l'enregistrement TXT ». Cliquez sur **OK** une fois terminé (avec l'option CNAME, puis sur **Got it**).

« Certains fournisseurs DNS ajoutent automatiquement votre domaine à l'enregistrement CNAME, TXT ou DMARC par défaut. » Chez ces fournisseurs, saisissez seulement la première partie du nom : « Pour le CNAME, le nom de l'enregistrement doit être saisi sous la forme "ctct1._domainkey" et "ctct2_domainkey" au lieu de "ctct1._domainkey.halfmoonyogastudio.com" et "ctct2._domainkey.halfmoonyogastudio.com". » (Le second nom court est privé d'un point dans la source ; le nom complet `ctct2._domainkey` montre la forme correcte.) ([Update your DNS records through your hosting provider](https://knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/39520-Update-your-DNS-records-through-your-hosting-provider-to-finish-setting-up-self-authentication))

Source : [Self-authenticate your emails using your own domain](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain).

## Étape 4 : ajouter l'enregistrement DMARC

Créez un enregistrement `TXT` avec le nom et la valeur DMARC affichés par Constant Contact. Pour l'option CNAME, Constant Contact demande de publier l'enregistrement de politique DMARC en même temps que les enregistrements CNAME pour pouvoir activer l'auto-authentification ; pour l'option TXT, de le publier « pour être en conformité avec les dernières exigences d'authentification ». Quelle que soit l'option, l'activation peut échouer avec l'erreur DMARC « Host name was not found or has incorrect value » ([Troubleshooting DKIM self-authentication](https://knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/49735-Troubleshooting-DKIM-self-authentication-using-CNAME-TXT-and-DMARC)). L'enregistrement minimal recommandé par Constant Contact a pour hôte `_dmarc.yourdomain.com` et pour valeur `v=DMARC1; p=none;` ([What is a DMARC policy and why do I need one?](https://knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/7644-What-is-a-DMARC-policy-and-why-do-I-need-one)).

Si votre domaine a déjà un enregistrement DMARC, n'en ajoutez pas un second : quand un serveur de réception trouve plus d'un enregistrement DMARC, il n'applique aucun traitement DMARC ([RFC 7489 §6.6.3](https://www.rfc-editor.org/rfc/rfc7489#section-6.6.3)). Consultez [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) avant de modifier une politique existante.

Source : [Self-authenticate your emails using your own domain](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain).

## Étape 5 : activer et tester

« Environ 24 à 48 heures après avoir collé les enregistrements CNAME et DMARC dans vos paramètres DNS, cliquez sur **Check status** ou **Activate** pour terminer l'activation de votre auto-authentification. » Si tout est prêt, cliquez sur **Activate**. Si une erreur apparaît (**Host name was not found**, **Please enter expected host name**, **Please enter correct value for host name**), consultez l'[article de dépannage](https://knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/49735-Troubleshooting-DKIM-self-authentication-using-CNAME-TXT-and-DMARC) de Constant Contact.

Avant votre prochain envoi, vérifiez une adresse email du domaine authentifié : « Une fois l'auto-authentification en place, vous ne pouvez utiliser qu'une "From Address" de votre domaine authentifié, sinon vos emails risquent de rebondir. » Constant Contact conseille d'abord un envoi de test à une petite liste de vos propres adresses.

Source : [Self-authenticate your emails using your own domain](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain).

## Étape 6 : conserver les enregistrements

Constant Contact réécrit votre adresse From avec son domaine partagé ccsend.com si « les enregistrements d'authentification de votre DNS ont été modifiés ou supprimés », ou si vous avez « auto-authentifié vos emails sans avoir encore publié de politique DMARC » ([How the industry email sender requirements impact your "From" address](https://knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/51400-How-your-From-email-address-may-be-impacted-by-the-latest-email-authentication-requirements)). Pour authentifier un autre domaine, cliquez d'abord sur **Remove self-authentication** dans **Advanced settings** ([Self-authenticate your emails using your own domain](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain)).

## SPF

L'auto-authentification de Constant Contact ne comporte pas d'étape d'enregistrement SPF. Son aide indique : « Les serveurs de messagerie destinataires vérifient l'enregistrement SPF de notre domaine, pas du vôtre ; vous n'avez donc pas besoin d'ajouter les adresses IP de Constant Contact à votre enregistrement SPF si vous en avez un. » ([Understanding email authentication](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5865-Understanding-email-authentication)) Ce guide n'en donne pas non plus. Vérifié le 2026-09-11 : une recherche de « SPF » dans la base de connaissances de Constant Contact n'a renvoyé que cet article et [What is a DMARC policy and why do I need one?](https://knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/7644-What-is-a-DMARC-policy-and-why-do-I-need-one), dont aucun ne donne d'étape SPF.

## Comment fonctionne l'alignement ici

DMARC réussit quand un message passe DKIM ou SPF **et** que le domaine validé est aligné sur le domaine de l'adresse From visible ; un seul passage aligné suffit. Envoyez depuis une adresse du domaine que vous avez authentifié. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) pour la façon dont l'alignement est évalué.

## Vérifier votre configuration

Une fois que Constant Contact affiche l'auto-authentification comme active, lancez le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) gratuit sur votre domaine pour voir ce que les serveurs de réception trouvent dans le DNS pour SPF, DKIM et DMARC.

Le diagnostic cherche DKIM sous une liste fixe de sélecteurs courants : il peut donc ne pas trouver seul votre enregistrement DKIM Constant Contact. Indiquez-lui votre sélecteur via l'API du diagnostic : `https://emailmarketing.net/api/domain-check?domain=yourdomain.com&selector=<selector>`. Le sélecteur est la partie du nom de l'enregistrement DKIM qui précède `._domainkey`. Pour l'option CNAME de Constant Contact, les sélecteurs sont `ctct1` et `ctct2`, tirés des noms d'enregistrement `ctct1._domainkey` et `ctct2._domainkey` ([Update your DNS records through your hosting provider](https://knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/39520-Update-your-DNS-records-through-your-hosting-provider-to-finish-setting-up-self-authentication)). Pour l'option TXT, le sélecteur est un nombre : prenez-le dans le nom d'hôte affiché dans votre compte ; l'exemple de Constant Contact est `10008432` ([Self-authenticate your emails using your own domain](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain)).

# HubSpot : configuration de SPF, DKIM et DMARC

> Comment connecter votre domaine d'envoi d'emails dans HubSpot : lancer la connexion, ajouter les deux enregistrements CNAME DKIM et les enregistrements TXT SPF et DMARC, puis confirmer l'état Authenticated, chaque étape renvoyant à la base de connaissances actuelle de HubSpot.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/guides-par-esp/hubspot

Ce guide suit la base de connaissances de HubSpot, consultée le 2026-09-11. Chaque étape renvoie à la page dont elle provient. Les noms de menus et les valeurs des enregistrements peuvent changer : si l'application affiche autre chose, l'application et la page actuelle de la base de connaissances de HubSpot font foi.

Ce guide couvre uniquement la connexion du domaine depuis lequel vous envoyez vos emails marketing. Pour les protocoles eux-mêmes, voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Avant de commencer

- Vous devez avoir accès aux paramètres DNS de votre domaine, généralement chez votre bureau d'enregistrement ou votre hébergeur.
- Envoyez depuis un domaine qui vous appartient. La base de connaissances de HubSpot indique : « Vous devez posséder chaque domaine et y avoir accès. » Elle précise aussi que vous « ne pouvez authentifier qu'un domaine d'envoi d'emails qui n'est pas déjà utilisé à une autre fin, comme l'hébergement de votre site web » ; un sous-domaine comme `info.domain.com` peut être utilisé à la place ([Manage your email authentication](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot)).
- Si vous utilisez Cloudflare pour le DNS, HubSpot demande que « le CNAME flattening à l'échelle du domaine et les paramètres de proxy soient désactivés ».

## Ce que HubSpot vous demande de publier

| Rôle | Type d'enregistrement | Nombre | Origine des valeurs |
|---|---|---|---|
| DKIM | `CNAME` | 2 | **Host** et **Required data** affichés dans HubSpot |
| SPF | `TXT` | 1 | **Host** et **Required data** affichés dans HubSpot |
| DMARC | `TXT` | 1 | **Host** et **Required data** affichés dans HubSpot |

HubSpot : « DKIM nécessite deux enregistrements CNAME, tandis que SPF et DMARC nécessitent chacun un enregistrement TXT. » ([Manage your email authentication](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot))

L'introduction de HubSpot cite MX parmi les types d'enregistrements (« quatre types d'enregistrements DNS distincts : MX, DKIM, SPF et DMARC »), mais ses étapes de configuration ne mentionnent aucun enregistrement MX.

## Étape 1 : lancer la connexion du domaine d'envoi

1. Dans votre compte HubSpot, cliquez sur l'icône **settings** dans la barre de navigation supérieure.
2. Dans le menu de la barre latérale gauche, allez dans **Content > Domains & URLs**.
3. Cliquez sur l'onglet **Email Sending**.
4. En haut à droite, cliquez sur **Connect sending domain**.

Source : [Manage your email authentication](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot).

## Étape 2 : confirmer le domaine et choisir une méthode

1. Sur l'écran de connexion du domaine, saisissez une adresse email que vous utilisez pour envoyer des emails marketing, puis cliquez sur **Next**.
2. Vérifiez que le domaine d'envoi d'emails est correct, puis cliquez sur **Next**.
3. Si l'option existe pour votre fournisseur DNS, cliquez sur **Sign in with [provider]**, ou cliquez sur **No, I'll set it up manually** pour ajouter vous-même les enregistrements DNS.

Source : [Manage your email authentication](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot).

## Étape 3 : ajouter les enregistrements DKIM

Chez votre fournisseur DNS, créez les deux enregistrements `CNAME` affichés par HubSpot. Pour chaque enregistrement, cliquez sur **Copy** à côté de la valeur dans les colonnes **Host** et **Required data**, puis collez les valeurs chez votre fournisseur DNS.

Source : [Manage your email authentication](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot).

## Étape 4 : ajouter l'enregistrement SPF

Créez l'enregistrement `TXT` affiché par HubSpot, en copiant **Host** et **Required data** de la même façon. Si vous avez déjà un enregistrement SPF, HubSpot demande d'y ajouter HubSpot « plutôt que d'en créer un nouveau » :

1. Ajoutez la chaîne de la colonne **Required data** qui suit `include:` à la fin de l'enregistrement SPF existant.
2. Vérifiez que la version SPF et le qualificateur `-all` n'apparaissent qu'une seule fois. L'exemple de HubSpot : `v=spf1 include:anotherprovider.com include:123456.spf03.hubspotemail.net -all`.

Source : [Manage your email authentication](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot).

## Étape 5 : ajouter l'enregistrement DMARC

Créez l'enregistrement `TXT` affiché par HubSpot pour DMARC, en copiant **Host** et **Required data** de la même façon.

Si votre domaine a déjà un enregistrement DMARC, n'en ajoutez pas un second : quand un serveur de réception trouve plus d'un enregistrement DMARC, il n'applique aucun traitement DMARC ([RFC 7489 §6.6.3](https://www.rfc-editor.org/rfc/rfc7489#section-6.6.3)). Consultez [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) avant de modifier une politique existante.

HubSpot précise qu'« un sous-domaine sera considéré comme authentifié si un enregistrement DMARC est configuré au niveau du domaine racine, en raison de l'héritage de la politique DMARC ».

Source : [Manage your email authentication](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot).

## Étape 6 : attendre la vérification et contrôler l'état

« La mise à jour des enregistrements DNS prend généralement entre 10 et 70 minutes, mais peut prendre jusqu'à 48 heures dans certains cas. » HubSpot recommande d'attendre au moins 20 minutes avant de vérifier. Dans **Content > Domains & URLs**, onglet **Email Sending**, chaque domaine affiche l'un de ces trois états :

- **Not authenticated** : aucune des trois méthodes n'est encore entièrement configurée ou vérifiée.
- **Partially authenticated** : DKIM est configuré et vérifié, mais SPF ou DMARC doit encore être vérifié.
- **Authenticated** : DKIM, SPF et DMARC sont tous configurés et vérifiés.

Si un enregistrement pose problème, cliquez sur **Continue setup** pour revoir les valeurs à ajouter chez votre fournisseur DNS.

Source : [Manage your email authentication](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot).

## SPF

L'aide de HubSpot donne une étape SPF (étape 4) pour le domaine de votre adresse From. Elle explique aussi que SPF « est traditionnellement requis pour le domaine du chemin de retour de l'enveloppe » et que « HubSpot l'a déjà configuré pour les emails marketing envoyés par ses serveurs partagés » ; les clients disposant d'adresses IP dédiées doivent configurer SPF sur leur domaine de chemin de retour dans le cadre de la mise en place de leurs IP ([Overview of email authentication](https://knowledge.hubspot.com/marketing-email/overview-of-email-authentication)). Si un domaine publie plus d'un enregistrement SPF, l'évaluation SPF renvoie un permerror ; voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf).

## Comment fonctionne l'alignement ici

DMARC réussit quand un message passe DKIM ou SPF **et** que le domaine validé est aligné sur le domaine de l'adresse From visible ; un seul passage aligné suffit. Envoyez depuis une adresse du domaine que vous avez connecté. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) pour la façon dont l'alignement est évalué.

## Vérifier votre configuration

Une fois que HubSpot affiche **Authenticated**, lancez le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) gratuit sur votre domaine pour voir ce que les serveurs de réception trouvent dans le DNS pour SPF, DKIM et DMARC.

Le diagnostic cherche DKIM sous une liste fixe de sélecteurs courants : il peut donc ne pas trouver seul votre enregistrement DKIM HubSpot. Indiquez-lui votre sélecteur via l'API du diagnostic : `https://emailmarketing.net/api/domain-check?domain=yourdomain.com&selector=<selector>`. Le sélecteur est la partie du nom de l'enregistrement DKIM qui précède `._domainkey`. Pour HubSpot, c'est le début du **Host** de chaque enregistrement CNAME DKIM affiché par HubSpot ; vérifiez les deux.

# Kit : configuration de DKIM et DMARC

> Comment configurer un domaine d'envoi vérifié dans Kit (anciennement ConvertKit) : ajouter le domaine, ajouter les enregistrements CNAME et l'enregistrement TXT DMARC, puis valider, chaque étape renvoyant au centre d'aide actuel de Kit.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/guides-par-esp/kit

Ce guide suit le centre d'aide de Kit (anciennement ConvertKit), consulté le 2026-09-11. Chaque étape renvoie à la page dont elle provient. Les noms de menus et les valeurs des enregistrements peuvent changer : si l'application affiche autre chose, l'application et la page d'aide actuelle de Kit font foi.

Pour les protocoles eux-mêmes, voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Avant de commencer

- Vous devez avoir accès aux paramètres DNS de votre domaine. L'aide de Kit indique : « Si vous avez besoin d'aide pour modifier vos paramètres DNS, demandez de l'aide à votre fournisseur DNS. » ([Verify your domain to optimize your deliverability](https://help.kit.com/en/articles/2502558-verify-your-domain-to-optimize-your-deliverability))
- Envoyez depuis une adresse d'un domaine qui vous appartient. L'aide de Kit indique : « Tous les emails marketing doivent être envoyés depuis un domaine qui vous appartient, et non depuis un compte personnel sur le domaine d'un fournisseur » ([Why do I need my own domain to send email?](https://help.kit.com/en/articles/2502505-why-do-i-need-my-own-domain-to-send-email)).
- Avec un domaine d'envoi vérifié, « vous vous appuyez davantage sur la réputation de votre propre domaine d'expéditeur » ; Kit recommande de commencer par vos abonnés les plus engagés et de ne pas faire d'autres changements importants en même temps ([What you should know before setting up a verified sending domain](https://help.kit.com/en/articles/9176509-what-you-should-know-before-setting-up-a-verified-sending-domain)).

## Ce que Kit vous demande de publier

| Rôle | Type d'enregistrement | Nombre | Origine des valeurs |
|---|---|---|---|
| Domaine d'envoi vérifié (DKIM compris) | `CNAME` | Selon l'affichage | Affichés sur l'écran **Verify your sending domain** ; les exemples de Kit sont `ckespa` et `cka._domainkey` |
| DMARC | `TXT` | 1 | Affiché dans la section **Verified Sending Domain** ; s'il n'y en a pas, Kit indique que votre domaine en a déjà un |

Kit : « La configuration manuelle suppose une compréhension de base des enregistrements CNAME. » ([Verify your domain to optimize your deliverability](https://help.kit.com/en/articles/2502558-verify-your-domain-to-optimize-your-deliverability)) Ajouter l'enregistrement DMARC consiste à créer un nouvel enregistrement `TXT` pour votre domaine d'envoi vérifié avec les valeurs fournies par Kit ([How to add a DMARC record to your verified sending domain](https://help.kit.com/en/articles/8540237-how-to-add-a-dmarc-record-to-your-verified-sending-domain)).

## Étape 1 : ajouter le domaine

1. Cliquez sur le nom de votre compte en haut à droite du tableau de bord de Kit, puis sur **Settings**, puis sur **Email** dans la barre latérale gauche.
2. Sous **Verified Sending Domains**, cliquez sur **Set up your Verified Sending Domain** (ou sur **Add a Verified Sending Domain** si vous en avez déjà ajouté un).
3. Saisissez le domaine ou le sous-domaine que vous voulez vérifier pour l'envoi, puis cliquez sur **Next**. Kit accepte les domaines de premier niveau comme les sous-domaines ; vous n'êtes pas obligé de configurer un sous-domaine.

Source : [Verify your domain to optimize your deliverability](https://help.kit.com/en/articles/2502558-verify-your-domain-to-optimize-your-deliverability).

## Étape 2 : choisir la configuration automatique ou manuelle

Kit recommande d'« essayer d'abord la configuration automatique ». **Set this up for me** ouvre Entri : après **Continue**, Entri analyse votre domaine pour détecter votre fournisseur DNS, vous invite à vous y connecter, puis configure le domaine ; il faudra peut-être cliquer ensuite sur **Validate**. Si cela ne fonctionne pas, utilisez la configuration manuelle, qui affiche les enregistrements à ajouter vous-même.

Source : [Verify your domain to optimize your deliverability](https://help.kit.com/en/articles/2502558-verify-your-domain-to-optimize-your-deliverability).

## Étape 3 : ajouter les enregistrements CNAME

Sur l'écran **Verify your sending domain**, copiez les enregistrements DNS et ajoutez-les dans le gestionnaire d'enregistrements de votre fournisseur DNS, puis cliquez sur **Validate**. Si les enregistrements sont corrects, Kit affiche un message indiquant que votre domaine d'envoi est vérifié.

« Certains fournisseurs DNS exigent une version tronquée des valeurs d'hôte (par exemple, simplement ckespa au lieu de ckespa.yourdomain.com, et simplement cka._domainkey au lieu de cka._domainkey.yourdomain.com). » Si ni la version complète ni la version tronquée ne fonctionne, Kit conseille de contacter votre fournisseur DNS.

Source : [Verify your domain to optimize your deliverability](https://help.kit.com/en/articles/2502558-verify-your-domain-to-optimize-your-deliverability).

## Étape 4 : ajouter l'enregistrement DMARC

1. Dans **Settings ▸ Email**, repérez la section **Verified Sending Domain** et copiez l'enregistrement DMARC. Si les enregistrements DNS sont masqués, cliquez sur **Show DNS records**. Si aucun enregistrement DMARC n'apparaît, « cela signifie qu'un enregistrement DMARC est déjà ajouté à votre domaine ».
2. Chez votre fournisseur DNS, créez un enregistrement `TXT` pour votre domaine d'envoi vérifié avec les valeurs copiées.

L'enregistrement par défaut de Kit utilise `p=none`, « le plus permissif ». Si votre domaine a déjà un enregistrement DMARC, n'en ajoutez pas un second : quand un serveur de réception trouve plus d'un enregistrement DMARC, il n'applique aucun traitement DMARC ([RFC 7489 §6.6.3](https://www.rfc-editor.org/rfc/rfc7489#section-6.6.3)). Consultez [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) avant de modifier une politique existante.

Source : [How to add a DMARC record to your verified sending domain](https://help.kit.com/en/articles/8540237-how-to-add-a-dmarc-record-to-your-verified-sending-domain).

## Étape 5 : valider

« La prise d'effet de votre enregistrement DMARC peut prendre de 24 à 48 heures. » Sur la page **Email** de vos paramètres Kit, cliquez sur **Validate** pour votre domaine d'envoi vérifié. Une icône de réussite apparaît à côté du domaine une fois que Kit a validé l'enregistrement DMARC.

Source : [How to add a DMARC record to your verified sending domain](https://help.kit.com/en/articles/8540237-how-to-add-a-dmarc-record-to-your-verified-sending-domain).

## Étape 6 : conserver les enregistrements

« Une fois votre enregistrement DMARC ajouté, ne le supprimez pas, ni de Kit ni de votre domaine. Cela pourrait causer des problèmes de délivrabilité. » ([How to add a DMARC record to your verified sending domain](https://help.kit.com/en/articles/8540237-how-to-add-a-dmarc-record-to-your-verified-sending-domain)) La présentation de DMARC par Kit ajoute : « ne supprimez pas votre domaine d'envoi vérifié, ni votre enregistrement DMARC, ni de Kit ni de vos enregistrements DNS » ([DMARC: what is it and should you use it?](https://help.kit.com/en/articles/4534360-dmarc-what-is-it-and-should-you-use-it)). Avec un domaine d'envoi vérifié, « DKIM et SPF peuvent parfois échouer si les enregistrements CNAME ont été modifiés ou supprimés chez votre hébergeur » ([Inbox placement tests: how to analyze the results](https://help.kit.com/en/articles/4478092-inbox-placement-tests-how-to-analyze-the-results)).

## SPF

La configuration du domaine d'envoi vérifié de Kit ne comporte pas d'étape d'enregistrement SPF distincte. Son aide indique qu'un domaine d'envoi vérifié va « mettre votre adresse d'expédition dans le return-path » et « authentifier avec SPF en utilisant votre domaine » ([Verify your domain to optimize your deliverability](https://help.kit.com/en/articles/2502558-verify-your-domain-to-optimize-your-deliverability)). Ce guide n'en donne pas non plus. Vérifié le 2026-09-11 : tous les articles d'aide de Kit sur les domaines, la délivrabilité et l'authentification, dans le plan du site du centre d'aide de Kit et dans sa collection Deliverability, ont été parcourus à la recherche de « SPF », et aucun ne donne d'étape d'enregistrement SPF.

## Comment fonctionne l'alignement ici

DMARC réussit quand un message passe DKIM ou SPF **et** que le domaine validé est aligné sur le domaine de l'adresse From visible ; un seul passage aligné suffit. Envoyez depuis une adresse du domaine que vous avez authentifié. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) pour la façon dont l'alignement est évalué.

## Vérifier votre configuration

Une fois que Kit affiche le domaine comme vérifié, lancez le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) gratuit sur votre domaine pour voir ce que les serveurs de réception trouvent dans le DNS pour SPF, DKIM et DMARC.

Le diagnostic cherche DKIM sous une liste fixe de sélecteurs courants : il peut donc ne pas trouver seul votre enregistrement DKIM Kit. Indiquez-lui votre sélecteur via l'API du diagnostic : `https://emailmarketing.net/api/domain-check?domain=yourdomain.com&selector=<selector>`. Le sélecteur est la partie du nom de l'enregistrement DKIM qui précède `._domainkey`. Pour Kit, prenez-le dans l'hôte de l'enregistrement CNAME `_domainkey` affiché par Kit ; l'aide de Kit prend `cka` comme exemple (`cka._domainkey`).

# Klaviyo : configuration de DKIM et DMARC

> Comment configurer un domaine d'envoi personnalisé dans Klaviyo : générer les enregistrements, ajouter les enregistrements NS ou CNAME, l'enregistrement TXT de vérification et l'enregistrement TXT DMARC, puis vérifier et activer le domaine, chaque étape renvoyant au centre d'aide actuel de Klaviyo.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/guides-par-esp/klaviyo

Ce guide suit le centre d'aide de Klaviyo, consulté le 2026-09-11. Chaque étape renvoie à la page dont elle provient. Les noms de menus et les valeurs des enregistrements peuvent changer : si l'application affiche autre chose, l'application et la page d'aide actuelle de Klaviyo font foi.

Pour les protocoles eux-mêmes, voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Avant de commencer

- Vous devez avoir accès aux paramètres DNS de votre domaine. L'aide de Klaviyo indique : « Vous devez aussi être propriétaire du domaine que vous utilisez pour envoyer des emails. » Seuls les rôles Owner, Admin, Manager et Campaign Coordinator peuvent configurer un domaine d'envoi personnalisé (branded sending domain) ([How to set up a branded sending domain](https://help.klaviyo.com/hc/en-us/articles/115000357752)).
- Pour un premier domaine d'envoi personnalisé marketing, ou pour un domaine qui remplace le domaine actif, Klaviyo vous demande de « suspendre tous les envois avant d'appliquer les modifications » (même page).

## Ce que Klaviyo vous demande de publier

| Rôle | Type d'enregistrement | Nombre | Origine des valeurs |
|---|---|---|---|
| Sous-domaine d'envoi et DKIM, routage Dynamic | `NS` | 4 | Générés dans Klaviyo ; l'hôte est votre sous-domaine d'envoi |
| Sous-domaine d'envoi et DKIM, routage Static | `CNAME` | 3 | Générés dans Klaviyo ; le sous-domaine d'envoi plus deux enregistrements `_domainkey` |
| Propriété du domaine | `TXT` | 1 | L'hôte est votre domaine racine ; valeur `klaviyo-site-verification=…` |
| DMARC (facultatif) | `TXT` | 1 | Proposé seulement si votre domaine n'a pas d'enregistrement DMARC ; valeur `v=DMARC1; p=none;` |

Klaviyo : « Klaviyo exige jusqu'à 3 enregistrements CNAME ou 4 enregistrements NS pour l'authentification des emails, et un enregistrement TXT pour la vérification de la propriété du domaine. » Les domaines de service en routage Static nécessitent aussi un enregistrement `MX`, que Klaviyo génère ([How to set up a branded sending domain](https://help.klaviyo.com/hc/en-us/articles/115000357752)).

## Étape 1 : ajouter le domaine

1. Cliquez sur le nom de votre entreprise en bas à gauche, sélectionnez **Settings**, puis choisissez **Domains**.
2. Sélectionnez **Add Domain** et choisissez le type d'envoi : **Marketing**, **Transactional** ou **Service**.
3. Vérifiez le domaine racine que Klaviyo a repris de votre compte et sélectionnez **Next**.
4. Sous **Sending domain**, saisissez un sous-domaine inutilisé (par exemple `send`).

Source : [How to set up a branded sending domain](https://help.klaviyo.com/hc/en-us/articles/115000357752).

## Étape 2 : choisir le routage, DMARC et la méthode de configuration

1. Sélectionnez le type de **Routing**. **Dynamic** génère des enregistrements `NS` ; **Static** génère des enregistrements `CNAME`. Klaviyo recommande Dynamic, et indique que Static « est le bon choix si votre fournisseur DNS ne prend pas en charge les enregistrements NS ».
2. Choisissez d'ajouter ou non un enregistrement DMARC. Seuls les domaines qui n'ont pas encore d'enregistrement DMARC voient cette option.
3. Choisissez de vous connecter avec Entri ou de tout configurer manuellement. Avec Entri, Klaviyo détecte votre fournisseur DNS et vous demande de vous y connecter pour publier les enregistrements. Seuls les domaines éligibles à Entri voient cette option. Le parcours manuel affiche les enregistrements générés pour que vous les ajoutiez vous-même.

Source : [How to set up a branded sending domain](https://help.klaviyo.com/hc/en-us/articles/115000357752).

## Étape 3 : ajouter les enregistrements du domaine d'envoi

Sur le parcours manuel, choisissez votre fournisseur DNS sur la page **Find your DNS zone file** et sélectionnez **Next**. Copiez chaque enregistrement généré dans votre fichier de zone : les quatre enregistrements `NS` (Dynamic) ou les trois enregistrements `CNAME` (Static), plus l'enregistrement `TXT` de vérification. « Vous n'avez pas besoin de créer votre sous-domaine dans vos paramètres DNS. »

Si votre fournisseur DNS fait passer les enregistrements par un proxy (Cloudflare, par exemple), désactivez-le pour vos enregistrements Klaviyo : « Le proxy empêche Klaviyo de vérifier l'enregistrement » ([DNS and SPF setup troubleshooting](https://help.klaviyo.com/hc/en-us/articles/50941715515675)).

Source : [How to set up a branded sending domain](https://help.klaviyo.com/hc/en-us/articles/115000357752).

## Étape 4 : ajouter l'enregistrement DMARC

Si vous avez activé **Add DMARC record**, ajoutez l'enregistrement généré par Klaviyo : `v=DMARC1; p=none;`. Les étapes DMARC générales de Klaviyo utilisent un enregistrement `TXT` avec pour **Host** `_dmarc` ([Understanding email authentication](https://help.klaviyo.com/hc/en-us/articles/4402601857307)).

Si votre domaine a déjà un enregistrement DMARC, n'en ajoutez pas un second : quand un serveur de réception trouve plus d'un enregistrement DMARC, il n'applique aucun traitement DMARC ([RFC 7489 §6.6.3](https://www.rfc-editor.org/rfc/rfc7489#section-6.6.3)). Consultez [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) avant de modifier une politique existante.

Source : [How to set up a branded sending domain](https://help.klaviyo.com/hc/en-us/articles/115000357752).

## Étape 5 : vérifier et activer le domaine

Sélectionnez **Verify** une fois les enregistrements présents dans le DNS ; au début, il est normal qu'ils ne soient pas encore vérifiés. « La mise à jour des enregistrements DNS peut prendre jusqu'à 48 heures après leur publication dans vos paramètres DNS. » Vous voyez ensuite une confirmation de vérification, une erreur de vérification, ou un avertissement de conflit si des campagnes sont « en cours d'envoi ou programmées pour partir bientôt ». Une fois les enregistrements vérifiés, sélectionnez **Activate** sur la ligne du domaine.

Utilisez votre domaine racine dans votre adresse d'expédition (par exemple `@yourbusiness.com`), et non le sous-domaine d'envoi, sinon vous ne recevrez pas les réponses.

Source : [How to set up a branded sending domain](https://help.klaviyo.com/hc/en-us/articles/115000357752).

## Étape 6 : conserver les enregistrements

« Les domaines d'envoi personnalisés sont déconnectés quand les enregistrements DNS requis sont supprimés. » Klaviyo envoie une alerte dans votre boîte de notifications pour que vous puissiez corriger les enregistrements.

Source : [How to set up a branded sending domain](https://help.klaviyo.com/hc/en-us/articles/115000357752).

## SPF

L'aide de Klaviyo ne donne pas d'étape d'enregistrement SPF pour un domaine d'envoi personnalisé. Elle indique : « Quand vous envoyez des emails avec Klaviyo, vous n'avez pas besoin d'ajouter vos propres enregistrements SPF et DKIM » ([Understanding email authentication](https://help.klaviyo.com/hc/en-us/articles/4402601857307)). Ce guide n'en donne pas non plus.

## Comment fonctionne l'alignement ici

DMARC réussit quand un message passe DKIM ou SPF **et** que le domaine validé est aligné sur le domaine de l'adresse From visible ; un seul passage aligné suffit. Envoyez depuis une adresse du domaine que vous avez authentifié. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) pour la façon dont l'alignement est évalué.

## Vérifier votre configuration

Une fois que Klaviyo affiche le domaine comme actif, lancez le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) gratuit sur votre domaine pour voir ce que les serveurs de réception trouvent dans le DNS pour SPF, DKIM et DMARC.

Le diagnostic cherche DKIM sous une liste fixe de sélecteurs courants : il peut donc ne pas trouver seul votre enregistrement DKIM Klaviyo. Indiquez-lui votre sélecteur via l'API du diagnostic : `https://emailmarketing.net/api/domain-check?domain=yourdomain.com&selector=<selector>`. Le sélecteur est la partie du nom de l'enregistrement DKIM qui précède `._domainkey`. En routage Static, l'exemple d'enregistrement de Klaviyo est `km1._domainkey.helloworld.com` : les domaines marketing utilisent `km1`/`km2`, les domaines transactionnels `kt1`/`kt2`, les domaines de service `ks1`/`ks2`, et les anciens domaines statiques `kl1`/`kl2`. Un deuxième domaine du même type d'envoi utilise la paire de sélecteurs suivante, par exemple `km3`/`km4` pour un deuxième domaine marketing ([How to set up a branded sending domain](https://help.klaviyo.com/hc/en-us/articles/115000357752)). En routage Dynamic, « Klaviyo publie les enregistrements DKIM pour vous » et son aide ne nomme aucun sélecteur ; lisez-le dans la balise `s=` de la signature DKIM d'un message que vous avez envoyé (voir [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim)).

# Mailchimp : configuration de DKIM et DMARC

> Comment authentifier votre domaine d'envoi dans Mailchimp : vérifier le domaine, ajouter les deux enregistrements CNAME DKIM et l'enregistrement TXT DMARC, puis confirmer l'état Authenticated, chaque étape renvoyant au centre d'aide actuel de Mailchimp.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/guides-par-esp/mailchimp

Ce guide suit le centre d'aide de Mailchimp, consulté le 2026-09-11. Chaque étape renvoie à la page dont elle provient. Les noms de menus et les valeurs des enregistrements peuvent changer : si l'application affiche autre chose, l'application et la page d'aide actuelle de Mailchimp font foi.

Pour les protocoles eux-mêmes, voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Avant de commencer

- Vous devez avoir accès aux paramètres DNS de votre domaine, généralement chez votre bureau d'enregistrement ou votre hébergeur.
- Envoyez depuis une adresse d'un domaine qui vous appartient. L'aide de Mailchimp indique : « si vous utilisez un service de messagerie gratuit comme Gmail ou Yahoo pour votre adresse From, nous vous recommandons vivement de passer à une adresse email d'un domaine privé » ([About Email Domain Authentication](https://mailchimp.com/help/about-email-authentication/)).

## Ce que Mailchimp vous demande de publier

| Rôle | Type d'enregistrement | Nombre | Origine des valeurs |
|---|---|---|---|
| DKIM | `CNAME` | 2 | Affichés dans Mailchimp comme CNAME 1 et CNAME 2 |
| DMARC | `TXT` | 1 | Hôte `_dmarc` ; valeur affichée dans Mailchimp |

Mailchimp : « les enregistrements DNS de votre domaine doivent être mis à jour avec 2 enregistrements CNAME (pour DKIM) et 1 enregistrement TXT (pour DMARC) » ([About Email Domain Authentication](https://mailchimp.com/help/about-email-authentication/)).

## Étape 1 : vérifier le domaine

La vérification confirme que vous avez accès au domaine. Elle précède l'authentification : « Avant d'authentifier votre domaine d'email, vous devez le vérifier. » ([Set Up Email Domain Authentication](https://mailchimp.com/help/set-up-email-domain-authentication/))

1. Cliquez sur l'icône de votre profil et choisissez **Account & billing**, puis **Domains**.
2. Dans la section **Email Domains**, cliquez sur **Add & Verify Domain**.
3. Saisissez une adresse email du domaine et cliquez sur **Send Verification Email**.
4. Dans cet email, cliquez sur **Verify Domain Access**, ou saisissez le code de vérification dans votre compte et cliquez sur **Verify**.

Source : [Verify an Email Domain](https://mailchimp.com/help/verify-a-domain/).

## Étape 2 : lancer l'authentification

1. Cliquez sur l'icône de votre profil et choisissez **Account & billing**, puis l'onglet **Domains**.
2. Cliquez sur **Start authentication** à côté du domaine vérifié.
3. Choisissez une méthode : **Continue** lance l'authentification automatique avec Entri, qui analyse votre domaine, peut détecter votre fournisseur DNS et vous invite à vous connecter à votre fournisseur DNS. **Or manually authenticate your domain** affiche les enregistrements à ajouter vous-même. Pour le parcours manuel, sélectionnez votre fournisseur DNS (ou **Other**) et cliquez sur **Next**.

Source : [Set Up Email Domain Authentication](https://mailchimp.com/help/set-up-email-domain-authentication/).

## Étape 3 : ajouter les enregistrements DKIM

Chez votre fournisseur DNS, créez les deux enregistrements `CNAME` affichés par Mailchimp. Copiez le **Name (Host)** et la **Value** de **CNAME 1** et de **CNAME 2** exactement tels qu'ils apparaissent, puis revenez dans Mailchimp et cliquez sur **Next**.

Si votre fournisseur DNS ajoute automatiquement le domaine, saisissez seulement la partie hôte (par exemple `k2._domainkey`, et non `k2._domainkey.example.com`), sinon l'enregistrement se retrouve sous la forme `k2._domainkey.example.com.example.com`.

Source : [Set Up Email Domain Authentication](https://mailchimp.com/help/set-up-email-domain-authentication/).

## Étape 4 : ajouter l'enregistrement DMARC

Créez un enregistrement `TXT` avec pour **Host** `_dmarc` et pour **Value** la valeur affichée par Mailchimp, puis revenez dans Mailchimp et cliquez sur **Next**.

Si votre domaine a déjà un enregistrement DMARC, n'en ajoutez pas un second : quand un serveur de réception trouve plus d'un enregistrement DMARC, il n'applique aucun traitement DMARC ([RFC 7489 §6.6.3](https://www.rfc-editor.org/rfc/rfc7489#section-6.6.3)). Consultez [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) avant de modifier une politique existante.

Source : [Set Up Email Domain Authentication](https://mailchimp.com/help/set-up-email-domain-authentication/).

## Étape 5 : attendre la validation et contrôler l'état

Mailchimp valide les enregistrements. « La plupart des enregistrements se mettent à jour en quelques minutes, mais cela peut prendre jusqu'à 48 heures. » Vous recevez un email une fois la validation terminée. Pendant la validation, la page Domains affiche **Authentication in progress** ; en cas de réussite, l'étiquette **Authenticated** apparaît à côté du domaine. En cas d'échec, la page Domains propose **Resolve** ou **Restart authentication**.

Source : [Set Up Email Domain Authentication](https://mailchimp.com/help/set-up-email-domain-authentication/).

## Étape 6 : conserver les enregistrements

Ne modifiez pas les enregistrements CNAME DKIM après l'authentification. Mailchimp conserve l'authentification en mémoire ; pour changer les enregistrements, désactivez d'abord l'authentification sur la page Domains, puis authentifiez de nouveau le domaine une fois la modification DNS faite.

Source : [Set Up Email Domain Authentication](https://mailchimp.com/help/set-up-email-domain-authentication/).

## SPF

Les pages d'aide actuelles de Mailchimp sur l'authentification des domaines ne listent que les enregistrements DKIM et DMARC. Elles ne documentent pas d'étape d'enregistrement SPF ; ce guide n'en donne donc pas.

## Comment fonctionne l'alignement ici

DMARC réussit quand un message passe DKIM ou SPF **et** que le domaine validé est aligné sur le domaine de l'adresse From visible ; un seul passage aligné suffit. Envoyez depuis une adresse du domaine que vous avez authentifié. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) pour la façon dont l'alignement est évalué.

## Vérifier votre configuration

Une fois que Mailchimp affiche **Authenticated**, lancez le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) gratuit sur votre domaine pour voir ce que les serveurs de réception trouvent dans le DNS pour SPF, DKIM et DMARC.

Le diagnostic cherche DKIM sous une liste fixe de sélecteurs courants : il peut donc ne pas trouver seul votre enregistrement DKIM Mailchimp. Indiquez-lui votre sélecteur via l'API du diagnostic : `https://emailmarketing.net/api/domain-check?domain=yourdomain.com&selector=<selector>`. Le sélecteur est la partie du nom de l'enregistrement DKIM qui précède `._domainkey`. Pour Mailchimp, c'est l'hôte des enregistrements CNAME DKIM affichés par Mailchimp ; l'aide de Mailchimp prend `k2` comme exemple (`k2._domainkey`).

# MailerLite : configuration de SPF, DKIM et DMARC

> Comment authentifier votre domaine d'envoi dans MailerLite : ajouter le domaine, ajouter l'enregistrement CNAME DKIM et les enregistrements TXT SPF et de vérification du domaine, ajouter un enregistrement DMARC, puis confirmer que le domaine est authentifié, chaque étape renvoyant au centre d'aide actuel de MailerLite.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/guides-par-esp/mailerlite

Ce guide suit le centre d'aide de MailerLite, consulté le 2026-09-11. Chaque étape renvoie à la page dont elle provient. Les noms de menus et les valeurs des enregistrements peuvent changer : si l'application affiche autre chose, l'application et la page d'aide actuelle de MailerLite font foi.

Pour les protocoles eux-mêmes, voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Avant de commencer

- Vous devez avoir accès aux paramètres DNS de votre domaine. L'aide de MailerLite indique : « Accédez aux paramètres DNS de votre domaine, dans le compte de votre hébergeur » ([Domain authentication](https://www.mailerlite.com/help/how-to-verify-and-authenticate-your-domain)).
- Envoyez depuis une adresse de votre propre domaine payant : la configuration de MailerLite demande « une adresse email qui comporte votre domaine payant » ([How to use automatic domain authentication](https://www.mailerlite.com/help/automatic-domain-authentication)). MailerLite : « Compte tenu des nouvelles exigences de Google et Yahoo envers les expéditeurs d'emails, l'authentification de votre domaine est obligatoire si vous envoyez depuis un domaine personnalisé. » ([Domain authentication](https://www.mailerlite.com/help/how-to-verify-and-authenticate-your-domain))

## Ce que MailerLite vous demande de publier

| Rôle | Type d'enregistrement | Nombre | Origine des valeurs |
|---|---|---|---|
| DKIM | `CNAME` | 1 | Nom et valeur affichés dans MailerLite ; le nom est `litesrv._domainkey` |
| SPF | `TXT` | 1 | Valeur affichée dans MailerLite ; comprend `include:_spf.mlsend.com` |
| Vérification du domaine | `TXT` | 1 | Nom et valeur affichés dans MailerLite ; le nom est votre domaine racine |
| DMARC | `TXT` | 1 | Non généré par MailerLite ; voir l'étape 4 |

MailerLite : « Ajoutez le DKIM en enregistrement CNAME, le SPF en enregistrement TXT et la vérification du domaine en enregistrement TXT. » ([Domain authentication](https://www.mailerlite.com/help/how-to-verify-and-authenticate-your-domain))

## Étape 1 : ajouter le domaine

1. Allez sur la page **Account settings** et sélectionnez l'onglet **Domains**.
2. Cliquez sur **Add domain**.
3. Saisissez l'adresse email depuis laquelle vous voulez envoyer et cliquez sur **Save**.

Source : [Domain authentication](https://www.mailerlite.com/help/how-to-verify-and-authenticate-your-domain).

## Étape 2 : choisir l'authentification automatique ou manuelle

Quand une fenêtre propose de lancer l'authentification, cliquez sur **Continue** pour utiliser la configuration automatique : elle analyse votre domaine, détecte votre fournisseur DNS, puis vous demande de vous connecter à ce fournisseur et d'autoriser MailerLite à ajouter les enregistrements. Si vous n'avez pas les identifiants, **Forward login to someone else** partage un lien avec une personne qui les a.

Pour le parcours manuel, choisissez **Or manually authenticate your domain**, sélectionnez votre fournisseur DNS dans la liste déroulante (ou **Other**) et cliquez sur **Continue**. MailerLite affiche les champs **Name** et **Value** des enregistrements DKIM, SPF et de vérification du domaine. Si vous vous connectez à votre fournisseur DNS avec une connexion sociale, par exemple via Gmail, utilisez le parcours manuel : « ce type de connexion n'est pas pris en charge ».

Sources : [Domain authentication](https://www.mailerlite.com/help/how-to-verify-and-authenticate-your-domain), [How to use automatic domain authentication](https://www.mailerlite.com/help/automatic-domain-authentication).

## Étape 3 : ajouter les enregistrements DKIM, SPF et de vérification

Chez votre fournisseur DNS, ajoutez l'enregistrement DKIM en `CNAME`, et les enregistrements SPF et de vérification du domaine en enregistrements `TXT`, avec le **Name** et la **Value** affichés par MailerLite. « Ces enregistrements ne peuvent pas être modifiés dans MailerLite ; ils doivent donc correspondre exactement. »

- **DKIM** : le nom est `litesrv._domainkey` ; la plupart des fournisseurs DNS y ajoutent votre domaine. Si le vôtre ajoute aussi le domaine à la valeur, saisissez la valeur avec un point final : `litesrv._domainkey.mlsend.com.`
- **SPF et vérification du domaine** : le nom est votre domaine racine. Selon votre fournisseur, laissez-le vide ou saisissez `@`.
- **Un enregistrement SPF existant** : un domaine ne peut en avoir qu'un. MailerLite : « Il n'est possible d'avoir qu'un seul enregistrement SPF dans la zone DNS de votre domaine. » Fusionnez le `include:_spf.mlsend.com` de MailerLite dans votre enregistrement existant au lieu d'en ajouter un second ([How to merge SPF records](https://www.mailerlite.com/help/how-to-merge-spf-records)).

Sources : [Domain authentication](https://www.mailerlite.com/help/how-to-verify-and-authenticate-your-domain), [Troubleshooting domain authentication](https://www.mailerlite.com/help/troubleshooting-domain-authentication).

## Étape 4 : ajouter l'enregistrement DMARC

Le parcours d'authentification de MailerLite ne génère pas d'enregistrement DMARC. Son aide présente DMARC comme un enregistrement « configuré dans les paramètres DNS d'un domaine sous forme d'enregistrement TXT », donne `v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com` comme exemple d'enregistrement de base, et recommande DMARC « si vous envoyez fréquemment de gros volumes d'emails (environ 5k+) » ([The basics of DMARC](https://www.mailerlite.com/help/the-basics-of-dmarc)). L'enregistrement se place à `_dmarc.yourdomain.com` ([RFC 7489 §6.1](https://www.rfc-editor.org/rfc/rfc7489#section-6.1)).

Si votre domaine a déjà un enregistrement DMARC, n'en ajoutez pas un second : quand un serveur de réception trouve plus d'un enregistrement DMARC, il n'applique aucun traitement DMARC ([RFC 7489 §6.6.3](https://www.rfc-editor.org/rfc/rfc7489#section-6.6.3)). Consultez [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) avant de modifier une politique existante.

Source : [The basics of DMARC](https://www.mailerlite.com/help/the-basics-of-dmarc).

## Étape 5 : vérifier les enregistrements et l'état

1. Revenez à l'onglet **Domains** et cliquez sur **Authenticate** à côté du domaine.
2. Cliquez sur **Check DNS Records**. Si les enregistrements correspondent, ils sont approuvés et le domaine est authentifié.

« La mise à jour complète de ces informations sur les serveurs peut prendre jusqu'à 24 heures. La plupart du temps, cependant, l'approbation et la mise à jour se font en quelques minutes. » Avec la configuration automatique, le domaine affiche **Pending** d'ici là. Si un enregistrement n'est pas approuvé, suivez l'[article de dépannage](https://www.mailerlite.com/help/troubleshooting-domain-authentication) de MailerLite : quand il trouve plus d'un enregistrement SPF, **Check DNS records** affiche une valeur SPF fusionnée à publier à la place des enregistrements existants.

Sources : [Domain authentication](https://www.mailerlite.com/help/how-to-verify-and-authenticate-your-domain), [How to use automatic domain authentication](https://www.mailerlite.com/help/automatic-domain-authentication).

## Étape 6 : configurer l'alignement du domaine (facultatif)

L'**alignement du domaine** (domain alignment) de MailerLite place l'un de vos sous-domaines dans les en-têtes des emails et dans les liens suivis. Il est « non obligatoire, mais fortement recommandé ». Votre domaine doit d'abord être authentifié.

1. Dans l'onglet **Domains**, sous **Sending domains**, cliquez sur **Add custom domain** à côté du domaine authentifié.
2. Sous **Subdomain prefix**, saisissez un préfixe inutilisé (par exemple `newsletter`) et cliquez sur **Add**.
3. Utilisez la configuration automatique, ou cliquez sur **Check DNS records** et ajoutez les enregistrements `A`, `MX` et `TXT` de l'onglet **Manual**.
4. Une fois les enregistrements acceptés (jusqu'à 24 heures), passez l'alignement du domaine sur **ON** dans la page Domains.

Gardez votre adresse From sur votre domaine principal, et non sur le sous-domaine d'alignement. Si vous désactivez l'alignement, les liens des campagnes déjà envoyées avec celui-ci ne fonctionnent plus.

Source : [How to align your domain](https://www.mailerlite.com/help/how-to-align-a-domain).

## SPF

La configuration de MailerLite comprend un enregistrement `TXT` SPF, traité à l'étape 3. C'est l'un des enregistrements que **Check DNS Records** approuve. Comme un domaine ne peut avoir qu'un seul enregistrement SPF (en publier plusieurs produit un **permerror**, voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf)), fusionnez-le avec tout enregistrement SPF existant en suivant [How to merge SPF records](https://www.mailerlite.com/help/how-to-merge-spf-records).

## Comment fonctionne l'alignement ici

DMARC réussit quand un message passe DKIM ou SPF **et** que le domaine validé est aligné sur le domaine de l'adresse From visible ; un seul passage aligné suffit. Envoyez depuis une adresse du domaine que vous avez authentifié. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) pour la façon dont l'alignement est évalué.

## Vérifier votre configuration

Une fois que MailerLite affiche le domaine comme authentifié, lancez le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) gratuit sur votre domaine pour voir ce que les serveurs de réception trouvent dans le DNS pour SPF, DKIM et DMARC.

Le diagnostic cherche DKIM sous une liste fixe de sélecteurs courants : il peut donc ne pas trouver seul votre enregistrement DKIM MailerLite. Indiquez-lui votre sélecteur via l'API du diagnostic : `https://emailmarketing.net/api/domain-check?domain=yourdomain.com&selector=<selector>`. Le sélecteur est la partie du nom de l'enregistrement DKIM qui précède `._domainkey`. Pour MailerLite, c'est `litesrv`, tiré du nom CNAME DKIM `litesrv._domainkey` ([Troubleshooting domain authentication](https://www.mailerlite.com/help/troubleshooting-domain-authentication)).

# Salesforce Marketing Cloud : configuration de SPF, DKIM et DMARC

> Comment authentifier un domaine d'envoi dans Salesforce Marketing Cloud Engagement avec un Sender Authentication Package (SAP) ou un Private Domain : créer le domaine, choisir un DNS délégué ou auto-hébergé, publier les enregistrements de serveurs de noms ou du fichier de zone, puis attendre l'état Active, chaque étape renvoyant à Salesforce Help, et les étapes réalisées par Salesforce étant signalées comme telles.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/guides-par-esp/salesforce-marketing-cloud

Ce guide suit l'aide de Salesforce pour Marketing Cloud Engagement, consultée le 2026-09-11. Chaque étape renvoie à la page dont elle provient. Les noms de menus et les valeurs des enregistrements peuvent changer : si l'application affiche autre chose, l'application et la page d'aide actuelle de Salesforce font foi.

Pour les protocoles eux-mêmes, voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## Avant de commencer

- L'authentification du domaine passe par un produit payant : un **Sender Authentication Package (SAP)**, qui personnalise aussi vos liens et vos images à votre marque, ou un **Private Domain**, limité à l'authentification. « Private Domain est un produit payant. Pour l'acheter, contactez votre Account Executive (AE) Salesforce. » ([Private Domain FAQ](https://help.salesforce.com/s/articleView?id=000240073&language=en_US&type=1)) « Les clients qui envoient plus de 250 000 emails par mois doivent utiliser SAP. » ([Working with the Email Sender Authentication Package](https://help.salesforce.com/s/articleView?id=sf.mc_es_sender_authentication_package.htm&language=en_US&type=5))
- Salesforce recommande un sous-domaine de votre domaine connu, par exemple `email.mycompany.com` ([SAP Custom Domain Best Practices](https://help.salesforce.com/s/articleView?id=000382421&language=en_US&type=1)).
- Après l'achat d'une licence Marketing Cloud Engagement ou d'un SAP supplémentaire, Salesforce peut vous envoyer par email un formulaire SAP. Une fois ce formulaire soumis, « un dossier de délivrabilité est créé automatiquement », et l'équipe délivrabilité de Salesforce « peut vous poser quelques questions pour terminer la configuration du SAP » ([How to Fill Out the SAP Form](https://help.salesforce.com/s/articleView?id=000396049&language=en_US&type=1)).

## Ce que Marketing Cloud vous demande de publier

Cela dépend de la façon dont vous gérez le DNS du domaine.

| Rôle | Type d'enregistrement | Nombre | Origine des valeurs |
|---|---|---|---|
| DNS délégué : serveurs de noms | `NS` | 4 | `ns1`–`ns4.exacttarget.com` ; Salesforce héberge ensuite tous les enregistrements ci-dessous |
| DNS auto-hébergé : DKIM | `TXT` | 1 | Liste d'enregistrements de Salesforce ; nom `<selector>._domainkey.<your domain>` |
| DNS auto-hébergé : SPF | `TXT` | 3 | Liste d'enregistrements de Salesforce ; sur votre domaine, `bounce.<your domain>` et `reply.<your domain>` |
| DNS auto-hébergé : DMARC | `TXT` | 1 | Liste d'enregistrements de Salesforce ; nom `_dmarc.<your domain>` |

Un fichier de zone auto-hébergé contient aussi les enregistrements `MX`, `CNAME` et `A` que Marketing Cloud utilise pour les rebonds, les réponses, les liens suivis et les images ([DNS Record Maintenance](https://help.salesforce.com/s/articleView?id=sf.mc_es_dns_record_maintenance.htm&language=en_US&type=5)).

## Étape 1 : créer le domaine

1. Depuis **Setup**, dans la zone **Quick Find**, saisissez `ssl`, puis sélectionnez **Domain SSL Certificates**.
2. Cliquez sur **New Domain**. « Si ce bouton est désactivé, aucune licence SAP ou Private Domain n'est disponible. »
3. Saisissez un nom de domaine et une adresse email valides.

Source : [Configure a Sender Authentication Package or Private Domain](https://help.salesforce.com/s/articleView?id=sf.configure_sap_and_private_domain.htm&language=en_US&type=5).

## Étape 2 : choisir la configuration

1. Indiquez si le domaine sert à l'**authentification des emails et à la personnalisation des URL** (email authentication and URL branding) ou **uniquement à l'authentification des emails** (only email authentication), puis cliquez sur **Next**.
2. Sélectionnez la configuration d'adresse IP : **Salesforce shared IP**, **New dedicated IP** ou **Current dedicated IP**.
3. Pour utiliser Reply Mail Management (RMM), sélectionnez **Yes** et saisissez une adresse email de transfert.

Source : [Configure a Sender Authentication Package or Private Domain](https://help.salesforce.com/s/articleView?id=sf.configure_sap_and_private_domain.htm&language=en_US&type=5).

## Étape 3 : choisir la gestion du DNS, puis soumettre

Choisissez la façon de gérer le DNS et cliquez sur **Next**, puis relisez la configuration et cliquez sur **Submit**. Les deux possibilités :

- **Déléguer le DNS à Salesforce.** Salesforce héberge et met à jour les enregistrements. Salesforce le recommande : « La délégation à Salesforce est recommandée, mais si vous devez gérer le DNS vous-même, coordonnez-vous avec le personnel chargé de la gestion des domaines de votre entreprise. » ([How to Fill Out the SAP Form](https://help.salesforce.com/s/articleView?id=000396049&language=en_US&type=1))
- **Héberger soi-même le DNS.** Vous publiez vous-même tous les enregistrements. « Le support de Marketing Cloud Engagement ne dépanne pas les problèmes DNS quand un client a choisi l'auto-hébergement. » ([Private Domain FAQ](https://help.salesforce.com/s/articleView?id=000240073&language=en_US&type=1))

Source : [Configure a Sender Authentication Package or Private Domain](https://help.salesforce.com/s/articleView?id=sf.configure_sap_and_private_domain.htm&language=en_US&type=5).

## Étape 4 : publier les enregistrements DNS

- **Délégué** : configurez votre DNS pour faire pointer le domaine vers les serveurs de Marketing Cloud Engagement. « Les deux approches ne nécessitent que quatre entrées NS dans votre DNS » : de `ns1.exacttarget.com` à `ns4.exacttarget.com`.
- **Auto-hébergé** : dans la liste **Sending Domain** de la page principale, sélectionnez **Download Zone File**, puis ajoutez ses enregistrements chez votre fournisseur DNS.

Sources : [Configure a Sender Authentication Package or Private Domain](https://help.salesforce.com/s/articleView?id=sf.configure_sap_and_private_domain.htm&language=en_US&type=5), [DNS Record Maintenance](https://help.salesforce.com/s/articleView?id=sf.mc_es_dns_record_maintenance.htm&language=en_US&type=5).

## Étape 5 : vérifier l'enregistrement DMARC

- **Délégué** : Salesforce le publie. « Un enregistrement de politique DMARC de base est appliqué automatiquement à votre SAP ou Private Domain délégué lors de la configuration initiale, en l'absence de besoins supplémentaires. » Pour le modifier, ouvrez un dossier de support (SAP DNS Request) ([Request simple DMARC policy](https://help.salesforce.com/s/articleView?id=000384283&language=en_US&type=1), [SAP DNS Requests](https://help.salesforce.com/s/articleView?id=000392198&language=en_US&type=1)).
- **Auto-hébergé** : la liste d'enregistrements de Salesforce comprend un enregistrement `TXT` `_dmarc` ([DNS Record Maintenance](https://help.salesforce.com/s/articleView?id=sf.mc_es_dns_record_maintenance.htm&language=en_US&type=5)). « Contactez l'administrateur de votre domaine pour toute modification des enregistrements DMARC de votre domaine. »

Si votre domaine a déjà un enregistrement DMARC, n'en ajoutez pas un second : quand un serveur de réception trouve plus d'un enregistrement DMARC, il n'applique aucun traitement DMARC ([RFC 7489 §6.6.3](https://www.rfc-editor.org/rfc/rfc7489#section-6.6.3)). L'enregistrement proposé par Salesforce utilise `p=reject` et « peut ne pas convenir si vous utilisez exactement ce domaine ou ce sous-domaine sur plus d'une plateforme d'emailing ». Consultez [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) avant de modifier une politique existante.

Source : [Request simple DMARC policy](https://help.salesforce.com/s/articleView?id=000384283&language=en_US&type=1).

## Étape 6 : attendre l'état Active

Le domaine passe de **Pending DNS validation** à **In progress**, puis à **Active**, quand il est prêt à l'emploi. « La configuration peut prendre jusqu'à cinq jours ouvrés. » Pour arrêter avant l'activation, sélectionnez **Stop Configuration** dans le menu d'actions du domaine.

Source : [Configure a Sender Authentication Package or Private Domain](https://help.salesforce.com/s/articleView?id=sf.configure_sap_and_private_domain.htm&language=en_US&type=5).

## Étape 7 : tenir les enregistrements à jour

Avec un DNS auto-hébergé, « Engagement ajoute parfois un serveur de noms ou change d'adresses IP d'envoi, ce qui impose de mettre à jour vos enregistrements DNS ». Avec un DNS délégué, Salesforce se charge de ces mises à jour. Les modifications que vous souhaitez apporter vous-même aux enregistrements délégués, comme les enregistrements SPF, DMARC, BIMI ou de vérification, passent par un dossier de support dont l'objet commence par « SAP DNS Request » : « Commencez par SAP DNS Request, le domaine et un bref résumé de la modification. »

Sources : [DNS Record Maintenance](https://help.salesforce.com/s/articleView?id=sf.mc_es_dns_record_maintenance.htm&language=en_US&type=5), [SAP DNS Requests](https://help.salesforce.com/s/articleView?id=000392198&language=en_US&type=1).

## SPF

SPF fait partie de la configuration : Private Domain « ajoute des signatures DKIM et SPF à vos emails sortants » ([Private Domain FAQ](https://help.salesforce.com/s/articleView?id=000240073&language=en_US&type=1)). Avec un DNS délégué, Salesforce héberge les enregistrements SPF. Avec un DNS auto-hébergé, la liste d'enregistrements de Salesforce comprend trois enregistrements `TXT` SPF : sur votre domaine, et sur ses sous-domaines `bounce` et `reply` ([DNS Record Maintenance](https://help.salesforce.com/s/articleView?id=sf.mc_es_dns_record_maintenance.htm&language=en_US&type=5)). Un domaine ne peut avoir qu'un seul enregistrement SPF (en publier plusieurs produit un **permerror**, voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf)).

## Comment fonctionne l'alignement ici

DMARC réussit quand un message passe DKIM ou SPF **et** que le domaine validé est aligné sur le domaine de l'adresse From visible ; un seul passage aligné suffit. Envoyez depuis une adresse du domaine que vous avez authentifié. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) pour la façon dont l'alignement est évalué.

## Vérifier votre configuration

Une fois que Marketing Cloud affiche le domaine comme **Active**, lancez le [diagnostic de domaine](https://emailmarketing.net/tools/domain-check) gratuit sur votre domaine pour voir ce que les serveurs de réception trouvent dans le DNS pour SPF, DKIM et DMARC.

Le diagnostic cherche DKIM sous une liste fixe de sélecteurs courants : il peut donc ne pas trouver seul votre enregistrement DKIM Marketing Cloud. Indiquez-lui votre sélecteur via l'API du diagnostic : `https://emailmarketing.net/api/domain-check?domain=yourdomain.com&selector=<selector>`. Le sélecteur est la partie du nom de l'enregistrement DKIM qui précède `._domainkey`. L'aide de Salesforce ne montre qu'un exemple générique (`example._domainkey`), pas de valeur fixe. Avec un DNS auto-hébergé, prenez-le dans le nom de l'enregistrement `TXT` DKIM que vous avez publié. Avec un DNS délégué, lisez-le dans la balise `s=` de la signature DKIM d'un message que vous avez envoyé (voir [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim)).

# Documents M3AAWG pour les expéditeurs et les ESP : index commenté

> Ce que le M3AAWG publie d'autre pour les expéditeurs et les ESP, ainsi que l'écosystème des feedback loops : types de formats FBL et liste des points d'inscription aux FBL par fournisseur.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/index-des-documents-m3aawg

Si vous envoyez des emails ou exploitez un fournisseur de services de messagerie (ESP), une grande partie des recommandations opérationnelles du secteur vient d'un seul groupe de travail, et vous devez savoir quels documents il publie et où les trouver. Le Messaging, Malware and Mobile Anti-Abuse Working Group (M³AAWG) tient une page « Documents for Senders and ESPs » et une page de ressources sur les feedback loops. Deux de ces documents ont leur propre synthèse détaillée :

- [M3AAWG Sender Best Common Practices, Version 4.0 (août 2026)](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs)
- [M3AAWG Email Authentication Recommended Best Practices (2020)](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-l-authentification-des-emails)

Les tableaux ci-dessous recensent les autres, avec le contenu de chaque document et l'endroit où il est publié.

## Documents listés sur la page destinée aux expéditeurs et aux ESP

| Document | Date | Contenu | URL |
|---|---|---|---|
| Trust in Email Begins with Authentication | févr. 2015 | Livre blanc qui explique pourquoi et comment l'authentification des emails (SPF, DKIM, DMARC) établit la confiance. C'est une lecture de fond sur laquelle s'appuie le BCP Authentication de 2020. | https://www.m3aawg.org/sites/default/files/doc_files/M3AAWG_Email_Authentication_Update-2015.pdf |
| M3AAWG Sender Best Common Practices, Version 4.0 | août 2026 | Le BCP destiné aux expéditeurs (M3AAWG-158), résumé dans [Meilleures pratiques M3AAWG pour les expéditeurs](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs). Il remplace les versions 2.0 (2011) et 3.0 (2015). | https://www.m3aawg.org/senderbcp |
| M3AAWG Position on Email Appending | sept. 2019 | Prise de position : l'enrichissement de fichiers (rapprocher des fiches clients d'adresses email que le titulaire n'a jamais fournies ni consenties) est une violation directe des valeurs fondamentales du M³AAWG. C'est une pratique abusive, qui génère des plaintes et comporte un risque juridique au regard des lois sur la vie privée et des lois anti-spam. | https://www.m3aawg.org/sites/default/files/legacy/m3aawg_apending_position_update-2019-01.pdf |
| M3AAWG Vetting Best Common Practices | nov. 2011 | Guide approfondi du contrôle des clients pour les ESP : le contrôle avant envoi, pour repérer les expéditeurs malveillants avant qu'ils n'envoient, et la surveillance après envoi (le BCP destiné aux expéditeurs rend les deux obligatoires). | https://www.m3aawg.org/sites/default/files/doc_files/MAAWG_Vetting_BCP_2011-11.pdf |
| M3AAWG Complaint Feedback Loop BCP | août 2010, remplacé en nov. 2011 | Remplacé par la **RFC 6449, Complaint Feedback Loop Operational Recommendations**, la norme opérationnelle pour exploiter et consommer des FBL. | https://tools.ietf.org/html/rfc6449 |
| Best Current Practices for Building and Operating a Spam Trap | août 2016 | Comment les réseaux d'adresses pièges sont construits et exploités. Ce document aide les expéditeurs à comprendre comment les opérateurs se procurent les adresses (pièges recyclés ou pièges vierges) et pourquoi toucher des pièges nuit à la réputation. | https://www.m3aawg.org/sites/default/files/legacy/m3aawg-spamtrap-operations-bcp-2016-08.pdf |

Les deux BCP résumés plus haut citent aussi ces documents du M³AAWG, qui appartiennent au même catalogue mais ne figurent pas sur la page destinée aux expéditeurs :

| Document | Contenu | URL |
|---|---|---|
| Best Practices for Managing SPF Records (2017-08) | Gestion complète des enregistrements SPF, y compris le respect des limites de requêtes DNS de la RFC 7208. | https://www.m3aawg.org/sites/default/files/m3aawg_managing_spf_records-2017-08.pdf |
| DKIM Key Rotation BCP (2019-03) | Comment et à quelle fréquence faire tourner les clés DKIM. | https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf |
| Best Practices for Implementing DKIM To Avoid Key Length Vulnerability (2017-07) | Longueurs de clé minimales et conseils de mise en œuvre. | https://www.m3aawg.org/sites/default/files/m3aawg-key-implementation-bp-revised-2017-07.pdf |
| Protecting Parked Domains BCP (2015-12) | Publier `v=spf1 -all` (et les enregistrements associés) sur les domaines qui n'envoient jamais de courrier. | https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bp-2015-12.pdf |
| Email Forwarding Best Common Practices, version 2 (2015-03) | Exploiter un service de transfert de courrier (par exemple, un ESP qui transfère les réponses à ses clients qui utilisent des adresses sur le domaine de l'ESP). | https://www.m3aawg.org/documents/en/m3aawg-email-forwarding-best-common-practices-version-2 |
| Recommendations for Senders Handling of Complaints | Le document auquel renvoie le BCP destiné aux expéditeurs (version 4.0) pour le traitement des rapports de FBL et des plaintes directes. Le BCP ne donne aucun lien, et le document ne figurait pas sur les pages de documents du M³AAWG lors de la vérification en septembre 2026. | Introuvable |
| Feedback Reporting Recommendation (2014-02) | Recommandations sur les retours et le signalement des plaintes entre serveurs de réception et expéditeurs. La version 3.0 du BCP destiné aux expéditeurs le citait ; la version 4.0 cite à la place le document sur les plaintes ci-dessus. | https://www.m3aawg.org/sites/default/files/legacy/document/M3AAWG_Feedback_Reporting_Recommendation_BP-2014-02.pdf |
| DMARC Training Series (vidéos) | Formation approfondie sur DMARC présentée par des experts de DMARC.org. | http://www.maawg.org/activities/training/dmarc-training-series |

## Ressources sur les feedback loops (FBL)

Une **feedback loop de plaintes** (*Complaint Feedback Loop*) est un mécanisme par lequel un fournisseur de messagerie renvoie les plaintes pour spam de ses utilisateurs à l'expéditeur vérifié du message, pour que celui-ci puisse nettoyer sa base de données et corriger les causes des plaintes. La **RFC 6449** donne les recommandations opérationnelles, et les rapports utilisent l'**Abuse Reporting Format (ARF)** (RFC 5965 ; la RFC 6650 en est la déclaration d'applicabilité).

### Trois types de formats FBL

| Type | Fonctionnement | Remarques |
|---|---|---|
| Traditionnel (par adresse IP) | Conforme à la RFC 6449. Les rapports utilisent ARF, contiennent le message complet, identifient l'utilisateur plaignant et sont rattachés à l'adresse IP d'envoi. | Le modèle classique. L'expéditeur doit contrôler ou déclarer les adresses IP d'envoi. |
| Agrégé | Consolide des **nombres** de plaintes, sans données personnelles ni messages complets. | Conçu pour la vie privée, il fournit tout de même des données de performance pour chaque flux. Exemples : Gmail (données de taux de spam dans Postmaster Tools), Microsoft SNDS, Signal Spam. |
| Par domaine | Exige des **signatures DKIM**. Les rapports utilisent ARF et sont rattachés au domaine signataire. | Permet aux expéditeurs sur **adresses IP partagées** d'obtenir un retour sur leur propre programme. Il va de pair avec le conseil du BCP destiné aux expéditeurs de signer avec DKIM chaque entité d'un pool partagé avec son propre domaine ou sous-domaine. |

### Points d'inscription aux FBL par fournisseur de messagerie (selon la liste du M3AAWG)

La plupart des FBL traditionnelles sont exploitées par l'intermédiaire de la **Universal Feedback Loop de Validity** (https://fbl.validity.com) : Bluetie (Excite), Comcast, Cox, Fastmail, Gandi, Italiaonline (Libero et Virgilio), La Poste, Locaweb, Mail.Ru, OpenSRS (Tucows), Rackspace, Seznam, SFR, SilverSky (USA.NET), Swisscom, Synacor, Telecom Italia, Telenet, Telenor, Terra, UOL, Virgin Media, Ziggo.

Exceptions et programmes hors Validity :

| Fournisseur | Type | Inscription |
|---|---|---|
| Earthlink | Traditionnel | fblrequest@abuse.earthlink.net |
| Microsoft JMRP (Junk Mail Reporting Program) | Traditionnel | https://postmaster.live.com/snds/JMRP.aspx |
| QQ.com | Traditionnel | http://open.mail.qq.com (en chinois) |
| United Online (Juno et NetZero) | Traditionnel | http://www.unitedonline.net/postmaster/whitelisted.html |
| Gmail | Agrégé | https://support.google.com/mail/answer/6254652 (Postmaster Tools) |
| Microsoft SNDS | Agrégé | https://sendersupport.olc.protection.outlook.com/snds/index.aspx |
| Signal Spam (France) | Agrégé | https://www.signal-spam.fr (adhésion payante) |
| Yahoo! | Par domaine (DKIM) | https://senders.yahooinc.com/contact#complaint-feedback-loop |
| Comcast, Gandi, La Poste, SFR | Par domaine (proposent aussi le traditionnel) | https://fbl.validity.com |

**Gmail ne propose aucune FBL traditionnelle par message.** Son programme agrégé (taux de spam par identifiant, dans Postmaster Tools) est le seul signal de plaintes qu'il fournit. Vous ne pouvez pas supprimer les plaignants un par un chez Gmail, et la prévention des plaintes y compte donc davantage. **La FBL de Yahoo fonctionne par domaine**, rattachée au domaine DKIM `d=`.

Le M³AAWG fournit cette liste à titre de service au secteur et ne cautionne aucun fournisseur en particulier. Ces informations proviennent de tiers et sont proposées « en l'état ».

### La place des FBL dans le travail d'un expéditeur

Le [BCP destiné aux expéditeurs](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs) exige des ESP un système qui reçoit à la fois les rapports de FBL et les plaintes envoyées directement à la boîte abuse, ainsi qu'une procédure pour y donner suite. La version 4.0 ajoute que les ESP devraient s'inscrire à toutes les FBL auxquelles ils ont accès et vérifier que chacune continue de fournir des rapports. Le BCP considère les plaintes comme un moyen essentiel de repérer les clients qui enfreignent les conditions de l'expéditeur, mais il laisse la procédure elle-même à l'appréciation de l'ESP. Dans la pratique courante, cette procédure supprime immédiatement le destinataire plaignant (lorsque la FBL l'identifie) et suit le taux de plaintes de chaque client et de chaque flux pour détecter les violations des conditions d'utilisation ou les problèmes d'hygiène de base de données.

## Voir aussi

- [Meilleures pratiques M3AAWG pour les expéditeurs](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs)
- [Meilleures pratiques M3AAWG pour l'authentification des emails](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-l-authentification-des-emails)
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email), sur les plaintes comme facteur central de la réputation

# Meilleures pratiques M3AAWG pour l'authentification des emails (2020)

> La liste de contrôle du secteur pour déployer SPF, DKIM, DMARC et ARC : exigences concrètes sur les enregistrements pour les expéditeurs, et ce que l'on attend des intermédiaires et des serveurs de réception.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-l-authentification-des-emails

Que vous envoyiez, transfériez ou receviez des emails, le secteur attend de vous un ensemble précis de mesures d'authentification. Le Messaging, Malware and Mobile Anti-Abuse Working Group (M³AAWG) les expose dans ses *Email Authentication Recommended Best Practices*, une **liste de contrôle d'exigences techniques binaires** (« elles sont mises en œuvre ou elles ne le sont pas ») pour authentifier les emails avec SPF, DKIM, DMARC et ARC.

La liste de contrôle couvre trois catégories d'acteurs : les expéditeurs (émetteurs), les intermédiaires (services de transfert, listes de diffusion) et les serveurs de réception (fournisseurs de messagerie). [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) explique les notions de base.

SMTP AUTH (les identifiants présentés lors de la soumission d'un message, du MUA ou du MSA vers le MTA) est explicitement hors du périmètre, car il sert un autre objectif.

**Pourquoi c'est important :** les fournisseurs de messagerie évoquent régulièrement un avenir possible du type « **No auth, no entry** » (pas d'authentification, pas d'entrée), dans lequel un message devrait réussir une ou plusieurs vérifications d'authentification pour être seulement envisagé pour la livraison. Ces recommandations visent à établir la confiance dès aujourd'hui, et à satisfaire toute future obligation de ce type. L'objectif est partout de protéger le **domaine organisationnel** de l'en-tête RFC5322.From (le domaine que voit le destinataire). Cela implique de s'appuyer sur **DMARC**, qui protège ce domaine d'une façon que SPF et DKIM seuls ne permettent pas.

## Protocoles couverts

| Protocole | RFC | Rôle en une ligne |
|---|---|---|
| SPF | RFC 7208 | Les propriétaires de domaines publient, dans un enregistrement DNS TXT, les systèmes autorisés à envoyer des emails en leur nom. |
| DKIM | RFC 6376 | Une organisation revendique la responsabilité de la transmission d'un message, d'une façon que le destinataire peut valider. |
| DMARC | RFC 7489 | Une organisation qui émet des messages exprime, au niveau du domaine, ses politiques et ses préférences de validation, de traitement et de rapport. |
| ARC | RFC 8617 | Une chaîne de responsabilité authentifiée qui enregistre chaque intermédiaire et son évaluation d'authentification à chaque saut. Ce n'est pas encore une norme Internet, mais son adoption progresse. |

## Liste de contrôle pour les décideurs

| Acteur | Pratiques recommandées |
|---|---|
| **Expéditeur** | SPF : publier des enregistrements pour les domaines MAIL FROM **et** EHLO, terminer les enregistrements par `~all`, n'autoriser que les adresses IP strictement nécessaires, aligner MAIL FROM avec RFC5322.From lorsque c'est possible, et publier `v=spf1 -all` sur les domaines qui n'envoient pas d'emails. DKIM : signer tous les messages sortants avec un domaine aligné avec RFC5322.From, et suivre les meilleures pratiques de gestion des clés. DMARC : utiliser `p=reject` lorsque c'est possible, et `p=quarantine` sinon. `p=none`, `sp=none` et `pct<100` sont des états transitoires à quitter le plus vite possible. Toujours inclure une balise `rua`. |
| **Intermédiaire** | Mettre en œuvre ARC. Générer des rapports DMARC. |
| **Serveur de réception** | Effectuer les vérifications SPF, DKIM et DMARC. Respecter les politiques DMARC. Un pass DMARC l'emporte sur un verdict SPF fail, sauf lorsque l'enregistrement SPF est `v=spf1 -all`. Envoyer des rapports DMARC. Exploiter les en-têtes ARC des messages reçus. |

## Recommandations pour les expéditeurs

Un expéditeur est le point d'émission des messages : les propriétaires de marques, les fournisseurs de messagerie et les ESP, mais pas les utilisateurs finaux qui s'écrivent de personne à personne.

### SPF

Publiez des enregistrements SPF pour **tout domaine utilisé dans la commande RFC5321.MailFrom (MAIL FROM)** et pour **tout domaine utilisé comme identité SMTP HELO ou EHLO** de n'importe quel serveur d'envoi.

- Assurez-vous que l'enregistrement est valide et respecte les **limites de requêtes DNS de la RFC 7208** (la limite de 10 requêtes DNS).
- Les enregistrements **devraient se terminer par `~all`** (softfail). La section sur les serveurs de réception ci-dessous explique pourquoi `-all` interagit mal avec le transfert avant l'évaluation DMARC.
- N'autorisez **que les adresses IP strictement nécessaires**. Utilisez les plus petits blocs réseau possibles pour les adresses IP qui envoient au nom du domaine.
- Les domaines qui n'envoient pas d'emails devraient publier **`v=spf1 -all`** (comme le recommande le BCP du M³AAWG *Protecting Parked Domains*).
- Les domaines MAIL FROM devraient être **alignés** avec le domaine RFC5322.From lorsque c'est possible.
- Pour plus de détails, voir *M³AAWG Best Practices for Managing SPF Records* (https://www.m3aawg.org/sites/default/files/m3aawg_managing_spf_records-2017-08.pdf).

### DKIM

Tout système de réputation fondé sur les domaines a besoin d'une méthode fiable pour confirmer l'identité du domaine qui prend la responsabilité d'un message, et **DKIM est la meilleure méthode disponible aujourd'hui**.

- Signez **tous** les messages sortants avec une clé DKIM dont le domaine `d=` **est aligné avec le domaine RFC5322.From**.
- **Les ESP devraient sérieusement envisager de signer aussi avec leur propre domaine**, afin que les serveurs de réception puissent établir une réputation distincte pour chaque domaine.
- **Les ESP devraient utiliser une clé DKIM différente pour chaque client.**
- Signez un ensemble raisonnable de champs d'en-tête, en prenant pour guide la **section 5.4.1 de la RFC 6376**.
- Pour la gestion des clés, le M³AAWG renvoie à :
  - *DKIM Key Rotation Best Common Practices* (révisé en mars 2019 : https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf)
  - *Best Practices for Implementing DKIM To Avoid Key Length Vulnerability* (révisé en juillet 2017 : https://www.m3aawg.org/sites/default/files/m3aawg-key-implementation-bp-revised-2017-07.pdf)

### DMARC

- **Le M³AAWG recommande `p=reject`** pour les domaines qui publient un enregistrement DMARC. Lorsque cela pose des difficultés opérationnelles, utilisez `p=quarantine`.
- **`p=none`, `sp=none` et `pct<100` ne sont que des états transitoires**, et l'objectif est de les quitter le plus vite possible. (Comparez avec le conseil plus progressif de « commencer par `p=none` » dans [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc). Les deux s'accordent sur la destination, une politique contraignante, guidée par les données des rapports.)
- Fixez la politique en mettant en balance le **profil de risque** du domaine face à l'usurpation d'identité et au phishing, actifs ou potentiels, et la perte possible de messages légitimes due à une signature absente ou cassée.
- **Chaque** enregistrement DMARC publié, même avec `p=none`, doit comporter au minimum une **balise `rua`** qui pointe vers une boîte aux lettres pour les rapports agrégés. Sans la possibilité de recevoir et de traiter les rapports, les propriétaires de domaines ne peuvent pas savoir s'ils peuvent passer sans risque à une politique plus stricte, car ils ne peuvent pas vérifier que tous leurs messages légitimes s'authentifient correctement.
- **`ruf` (rapports d'échec) est facultatif.** En raison des préoccupations de vie privée et du caviardage des données personnelles, la plupart des serveurs de réception n'envoient pas de rapports d'échec, et ceux-ci sont peu utiles à la plupart des propriétaires de domaines.
- Ni la boîte `rua` ni la boîte `ruf` ne devraient envoyer de réponses (réponses automatiques) lorsqu'elles reçoivent un rapport.

## Recommandations pour les intermédiaires

Les intermédiaires sont les *Mediators*, *Relays* et *Gateways* de la RFC 5598 : les services de transfert, les listes de diffusion, les serveurs de groupes de discussion, et toute boîte aux lettres configurée pour transférer tous ses messages vers un autre domaine. SPF, DKIM et DMARC sont conçus d'une façon qui fait que les vérifications d'authentification finales **peuvent échouer pour des messages passés par un intermédiaire**, alors que les mêmes messages auraient réussi s'ils avaient été envoyés directement. Le M³AAWG demande aux intermédiaires de réduire ce risque :

- **Modifier le message le moins possible en transit.** L'authentification dépend du contenu des en-têtes et/ou du corps, donc toute modification (parfois inévitable pour les listes de diffusion) doit rester minimale.
- **Réduire le risque d'échec d'authentification.** L'exemple type est une liste de diffusion qui ajoute un en-tête ou un pied de page à chaque message. Elle devrait réécrire l'en-tête From lorsque le domaine de l'auteur publie DMARC :
  1. un membre publie depuis `john.jones@dmarc.domain.tld` ;
  2. le logiciel de liste constate que `dmarc.domain.tld` publie une politique DMARC ;
  3. la liste réécrit le From en, par exemple, `john.jones=40dmarc.domain.tld@list.domain`, ce qui élimine le risque d'échec DMARC.
- **Mettre en œuvre ARC.** ARC enregistre les résultats d'authentification à chaque saut sans modifier le contenu du message, ce qui protège contre les échecs plus loin sur le parcours causés par le passage par l'intermédiaire. Cela suppose que l'intermédiaire effectue lui-même les vérifications SPF, DKIM et DMARC dont les résultats vont dans l'en-tête `ARC-Authentication-Results`.
- **Générer et envoyer des rapports agrégés DMARC.**

## Recommandations pour les serveurs de réception

Les serveurs de réception sont les domaines qui acceptent et stockent les messages de leurs destinataires. Le terme est plus large que « fournisseur de messagerie », car beaucoup d'emails aboutissent à des domaines qui ne sont pas des fournisseurs de messagerie. Ces mécanismes deviendront vraisemblablement de plus en plus nécessaires. Lorsqu'ils dépassent les compétences informatiques d'un petit domaine, le M³AAWG demande aux services d'hébergement cloud vers lesquels ces domaines migrent de les mettre en œuvre.

- **Effectuer les vérifications d'authentification** (SPF, DKIM, DMARC) sur les messages entrants, et utiliser les résultats pour décider de l'acceptation et du filtrage. C'est une meilleure pratique pour protéger les titulaires de boîtes aux lettres contre les emails frauduleux, que le serveur de réception adopte ou non le principe « no auth, no entry ».
- **Respecter les politiques DMARC.** Lorsqu'un domaine publie DMARC (surtout `p=reject`), les destinataires s'attendent à ce que les messages qui réussissent proviennent réellement du domaine de la ligne From. Les dérogations par politique locale devraient être (a) relativement rares et (b) clairement justifiées et documentées dans les champs de dérogation à la politique et de commentaire du rapport agrégé.
- **Un pass DMARC l'emporte sur un verdict SPF fail.** DMARC n'exige qu'un pass aligné de DKIM **ou** de SPF, et les domaines Return-Path ne sont souvent pas alignés avec le domaine From. Un échec SPF (l'enregistrement se termine par `-all` et la vérification échoue) **ne devrait donc pas entraîner de rejet tant que DMARC n'a pas été évalué et n'a pas réussi**.
  - **La seule exception** est `v=spf1 -all`, un enregistrement qui n'autorise aucun usage. Dans ce cas, le serveur de réception (ou l'intermédiaire) peut agir immédiatement sur l'échec SPF.
- **Envoyer des rapports agrégés DMARC.** Les rapports permettent aux propriétaires de domaines de renforcer leur authentification, qu'ils passent ou non à `p=reject`. Sans rapports, ils ne peuvent ni identifier les flux légitimes qui échouent à l'authentification, ni voir les tentatives d'usurpation et les prestataires mal configurés. Plusieurs grands fournisseurs de messagerie ont conclu que l'envoi de rapports agrégés n'entre pas en conflit avec les lois sur la vie privée. Le M³AAWG recommande aux émetteurs de rapports de tenir compte des avis juridiques actuels (par exemple, le rapport de certified-senders.org sur DMARC et le RGPD).
- **Exploiter les en-têtes ARC** : prendre en compte les ensembles d'en-têtes ARC des messages reçus dans le verdict d'authentification final et dans le traitement du message.

## Références citées par le document

RFC : 5598 (architecture de la messagerie Internet), 6376 (DKIM), 7208 (SPF), 7489 (DMARC), 8617 (ARC).

Documents du M³AAWG associés (voir aussi l'[index des documents](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/index-des-documents-m3aawg)) :

| Document | URL |
|---|---|
| Best Practices for Managing SPF Records (2017-08) | https://www.m3aawg.org/sites/default/files/m3aawg_managing_spf_records-2017-08.pdf |
| DKIM Key Rotation BCP (2019-03) | https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf |
| Best Practices for Implementing DKIM To Avoid Key Length Vulnerability (2017-07) | https://www.m3aawg.org/sites/default/files/m3aawg-key-implementation-bp-revised-2017-07.pdf |
| Protecting Parked Domains BCP (2015-12) | https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bp-2015-12.pdf |
| Trust in Email Begins with Authentication (2015) | https://www.m3aawg.org/sites/default/files/document/M3AAWG_Email_Authentication_Update-2015.pdf |
| Report on the Compliance of DMARC with the EU GDPR | https://certified-senders.org/wp-content/uploads/2018/08/Report_DMARC_and_GDPR.pdf |

## Voir aussi

- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc), sur l'alignement, la syntaxe de l'enregistrement et le passage d'une politique à l'autre
- [Meilleures pratiques M3AAWG pour les expéditeurs](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs), sur les exigences de DNS direct, de DNS inverse et de HELO dont dépend SPF, et sur DKIM par client dans les pools d'adresses IP partagées
- [Index des documents M3AAWG](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/index-des-documents-m3aawg)

# Meilleures pratiques M3AAWG pour les domaines d'envoi

> Les règles consensuelles du secteur pour choisir, segmenter, authentifier, déléguer et migrer les domaines utilisés pour envoyer des emails en masse et transactionnels.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/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](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip). Pour les recommandations tirées des guides de prestataires, voir [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/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 :

| Option | Position du M3AAWG |
|---|---|
| Domaine principal de la marque, ou sous-domaines de cette zone | **Recommandé**. C'est la recommandation principale du document |
| Un domaine nouvellement acquis et apparenté à la marque (un « domaine sosie ») | **Fortement déconseillé** |

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](https://emailmarketing.net/fr/apprendre/operations/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](https://www.m3aawg.org/senderbcp) (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](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-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 » :

| Type de trafic | Exemple de sous-domaine |
|---|---|
| Marketing | `offers.mybrand.com` |
| Transactionnel | `info.mybrand.com` |

- 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](https://emailmarketing.net/fr/apprendre/operations/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 :

| Champ d'en-tête | Schéma « même sous-domaine » | Schéma « aligné sur le domaine organisationnel » |
|---|---|---|
| Return-Path | `bounce@news.mybrand.com` | `bounce@bounce.mybrand.com` |
| From: visible | `great@news.mybrand.com` | `service@mybrand.com` |
| DKIM `d=` | `news.mybrand.com` | `mybrand.com` |

### Alignement

Le document utilise partout l'**alignement souple** ([RFC 7489 §3.1](https://emailmarketing.net/fr/apprendre/authentification/dmarc)). Deux domaines sont en alignement souple lorsque leurs domaines organisationnels correspondent.

| From: visible | Return-Path | DKIM `d=` | Alignement |
|---|---|---|---|
| `great@news.mybrand.com` | `bounce@bounce.news.mybrand.com` | `news.mybrand.com` | Souple |
| `service@info.mybrand.com` | `bounce@bounce.mybrand.com` | `news.mybrand.com` | Souple |
| `great@news.mybrand.com` | `bounce@news.mybrand.com` | `news.mybrand.com` | Strict |
| `great@mybrand.com` | `bounce@brandofmine.com` | `brandofmine.com` | Aucun |

## 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](https://emailmarketing.net/fr/apprendre/outils-postmaster/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](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi) et [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/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 :

| Protocole | Emplacement de l'enregistrement | Points clés |
|---|---|---|
| [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) | Zone DNS du **domaine Return-Path** | Par exemple, TXT sur `news.mybrand.com` : `v=spf1 include:_spf.example-esp.com ~all` |
| [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim) | Zone du domaine signataire, à `<selector>._domainkey.<domain>` | Clés de **1024 bits** au minimum. **Chaque sous-domaine d'envoi devrait utiliser un sélecteur différent** : des sélecteurs distincts limitent les dégâts d'une clé faible, volée ou ancienne, et permettent à différents expéditeurs de détenir leurs propres clés privées. Faites tourner les clés comme le décrit le BCP M3AAWG sur la rotation des clés DKIM |
| [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) | TXT à `_dmarc.` du **domaine du From: visible** | L'objectif est une politique sur le **domaine organisationnel**. Un enregistrement sur le sous-domaine est acceptable comme étape intermédiaire. Le domaine From: doit être aligné avec un `d=` DKIM valide **ou** avec un domaine Return-Path dont le SPF réussit |

### 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**.

| Hôte | Type | Valeur |
|---|---|---|
| `news.mybrand.com.` | TXT | `v=spf1 include:spf.example-esp.com ~all` |
| `news.mybrand.com.` | MX | `0 bounce.example-esp.com` |
| `t.news.mybrand.com.` | A | `192.0.2.124` (hôte de suivi) |
| `myselec._domainkey.news.mybrand.com.` | TXT | `k=rsa; p=MIGfMA0GCSq…` |
| `_dmarc.mybrand.com` | TXT | `v=DMARC1; p=reject; rua=mailto:dmarc-rua@mybrand.com` |

### 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.

| Hôte | Type | Valeur |
|---|---|---|
| `news.mybrand.com.` | TXT | `v=spf1 include:_spf.example-esp.com ~all` |
| `news.mybrand.com.` | MX | `0 bounce.example-esp.com` |
| `t.news.mybrand.com.` | CNAME | `tracking.example-esp.com` (hôte de suivi) |
| `myselec._domainkey.news.mybrand.com.` | CNAME | `myselec.news-mybrand.com.dkim.example-esp.com` |
| `_dmarc.news.mybrand.com` | CNAME | `dmarc.news-mybrand.com.example-esp.com` |

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](https://emailmarketing.net/fr/apprendre/authentification/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 :

| Hôte | Type | Valeur |
|---|---|---|
| `news.mybrand.com.` | NS | `ns.example-esp.com` |

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](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs) (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](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/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](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/index-des-documents-m3aawg).

## Voir aussi

- [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/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](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip)
- [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf), [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)

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

> La base consensuelle du secteur pour les expéditeurs commerciaux et les ESP, version 4.0 (août 2026) : authentification des emails, traitement des rebonds et des feedback loops, chauffe et surveillance des domaines, identité IP et DNS, surveillance des services, sécurité des données, WHOIS, niveaux d'opt-in, bombardement d'inscriptions, règles de désabonnement et contrôle des clients.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs

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](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-l-authentification-des-emails) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/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**.

| Classe de code | Signification | Action de l'expéditeur |
|---|---|---|
| 2xx | Succès : le message a été accepté | Aucune |
| 4xx | Échec temporaire : le message n'a pas été accepté | Le remettre en file d'attente et réessayer plus tard |
| 5xx | Échec définitif : le message n'a pas été accepté | **Ne pas** le remettre en file d'attente |

**É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](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/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](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/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](https://emailmarketing.net/fr/apprendre/operations/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](https://emailmarketing.net/learn/esp-operations/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](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-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](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip) et [Segmentation et allocation avancées des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-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](https://emailmarketing.net/learn/esp-operations/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](https://emailmarketing.net/learn/transport-security/tls-baseline) et [MTA-STS](https://emailmarketing.net/learn/transport-security/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 | Nom | Fonctionnement |
|---|---|---|
| 1 | Simple opt-in | L'utilisateur fournit une adresse, et les envois programmés commencent. Pas de notification, et pas de confirmation du consentement. |
| 2 | Simple opt-in avec notification (mieux) | Un message de notification ou de bienvenue informe les destinataires qu'ils recevront des messages. Pas de confirmation du consentement. |
| 3 | Opt-in confirmé (le mieux) | Un message de confirmation exige une action du destinataire (cliquer sur un lien ou répondre) **avant l'envoi de tout message lié à l'abonnement**. Également appelé « double opt-in » ou « abonnement en boucle fermée » (closed-loop subscription). |

### 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](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-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](https://emailmarketing.net/learn/esp-operations/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](https://emailmarketing.net/fr/apprendre/reference/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](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-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](https://emailmarketing.net/learn/esp-operations/customer-vetting).

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

| Terme | Définition (abrégée) |
|---|---|
| Adresse IP dédiée | Une adresse IP statique qui n'envoie que pour un seul expéditeur, une seule entreprise ou une seule marque, responsable de tout son contenu ; son rDNS identifie généralement la marque. |
| Adresse IP partagée | Une adresse IP utilisée par de nombreux expéditeurs, marques ou clients d'ESP, généralement en même temps ; identifiée à l'ESP qui la possède. |
| Liste de diffusion sale | Une liste qui contient des adresses issues de mauvaises pratiques d'acquisition ou d'opt-in, ou qui n'est pas tenue à jour (mauvais traitement des rebonds définitifs ou des désabonnements, ou aucun envoi depuis un an ou plus), ou les deux. |
| FBL | Le système d'un fournisseur de messagerie qui donne aux expéditeurs qualifiés des copies des messages que ses utilisateurs ont signalés comme spam, pour que les expéditeurs puissent en corriger les causes. |
| Rebond définitif | Un échec définitif : l'adresse ou le domaine n'existe plus, ou n'a jamais existé. |
| Rebond temporaire | Un échec temporaire, dû par exemple à une boîte pleine, à un échec de connexion, à une panne technique chez le fournisseur, ou au fournisseur qui **limite le débit de l'adresse IP qui se connecte pour ralentir la livraison**. |
| Messages transactionnels | Confirment une transaction ou donnent une information d'état individuelle (une alerte bancaire, un changement de mot de passe), par opposition aux messages en masse ou marketing. |
| Message de confirmation | Élément de l'opt-in confirmé : le nouvel abonné doit cliquer sur un lien ou répondre, et il n'est pas ajouté à la liste sans cette action. |
| Opt-in confirmé | Également appelé double opt-in : l'expéditeur vérifie que le titulaire de l'adresse soumise a demandé à s'inscrire, pour que personne ne soit abonné sans son consentement. |
| Message d'abonnement ou email de bienvenue | Envoyé après l'inscription, il décrit généralement le contenu et la fréquence des envois ; il devrait inclure un lien de désabonnement. |

## Voir aussi

- [Meilleures pratiques M3AAWG pour l'authentification des emails](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-l-authentification-des-emails)
- [Meilleures pratiques M3AAWG pour les domaines d'envoi](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-domaines-d-envoi)
- [Index des documents M3AAWG](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/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](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)
- [Les deux mondes de la délivrabilité email](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email)
- [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)
- [Segmentation et allocation avancées des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip)
- [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi)

# Word to the Wise : meilleures pratiques de l'email

> Synthèse du livre blanc « Email Best Practices » de Word to the Wise (Laura Atkins, 2012) : les meilleures et les pires pratiques des expéditeurs de gros volumes du point de vue de la livraison.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/word-to-the-wise-meilleures-pratiques-email

Si vous envoyez des emails en masse, les pratiques ci-dessous sont celles qui déterminent si votre courrier atteint régulièrement la boîte de réception, et les pires pratiques sont celles qui l'en empêchent le plus souvent. Elles viennent du livre blanc de Word to the Wise (WttW) *Email Best Practices* (Laura Atkins, 2012), qui porte sur les meilleures pratiques de **livraison**, par opposition aux meilleures pratiques de stratégie de communication.

WttW précise que le document a été publié à l'origine en 2012 et que le filtrage a évolué depuis. Beaucoup de ses recommandations restent valables, et les informations à jour se trouvent sur le [blog de Word to the Wise](https://wordtothewise.com/blog) (voir [Ressources de la communauté de la délivrabilité](https://emailmarketing.net/fr/apprendre/reference/ressources-communautaires-et-experts-de-la-delivrabilite)).

## La règle d'or

> Envoyez un courrier que les destinataires **désirent et attendent**.

En pratique, cela signifie que **tout email envoyé en masse doit être opt-in**. Vous pouvez toujours acquérir des clients par email, mais c'est plus compliqué que d'acheter une liste d'adresses et de lui écrire. [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email) et [Les deux mondes de la délivrabilité email](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email) développent le même principe.

Un point essentiel : les spammeurs ont beaucoup investi pour faire livrer leur courrier malgré une mauvaise réputation, et les FAI et les sociétés de filtrage ont donc construit des filtres qui **examinent l'ensemble des pratiques d'un expéditeur**. De mauvaises pratiques dans un flux peuvent affecter tout le courrier d'un expéditeur, même lorsque celui-ci essaie de séparer le bon courrier du mauvais.

## Meilleures pratiques générales

### N'envoyer que du courrier opt-in

L'opt-in signifie que le destinataire donne une adresse email à l'expéditeur **afin de recevoir du courrier marketing de cet expéditeur**. Zones grises courantes, qui ne sont pas de l'opt-in lorsque l'expéditeur décide à la place du destinataire :

- Fournir une adresse email lors d'un achat (est-ce un consentement au marketing ?)
- Fournir une adresse à une division d'une entreprise (est-ce un consentement pour les autres divisions ?)

Cela n'interdit pas d'envoyer des informations aux clients ni de faire du marketing croisé, mais l'expéditeur doit réfléchir à la façon de s'assurer que le client **s'attend** à ce courrier.

### Respecter toutes les lois locales

Aux États-Unis, CAN-SPAM impose que tout email réponde à ces critères :

| # | Exigence de CAN-SPAM |
|---|---|
| 1 | L'expéditeur doit fournir des informations de routage exactes sur les emails. |
| 2 | Les emails publicitaires doivent être clairement identifiés comme tels. |
| 3 | Les destinataires doivent pouvoir se désinscrire (opt-out). Les mécanismes d'opt-out doivent être électroniques et n'exiger que l'adresse email du destinataire et son choix de se désinscrire. Aucun mot de passe ni aucune autre information ne peut être exigé pour traiter la désinscription. |
| 4 | Tous les emails doivent contenir l'adresse postale de l'expéditeur. |

Points importants :

- **CAN-SPAM n'exige pas de permission.** Le droit américain ne fait pas de la permission une obligation.
- D'autres juridictions exigent une permission pour envoyer des emails marketing ou commerciaux, notamment l'**UE (RGPD)** et le **Canada (LCAP)**. Y envoyer sans permission peut engager la responsabilité juridique de l'expéditeur.
- Dans certaines juridictions, **la permission ne peut être ni partagée ni vendue**, si bien que même l'achat de listes « opt-in » est illégal.
- Segmenter des listes achetées par pays pour contourner les lois sur l'opt-in suppose que le vendeur a correctement compilé les données, ce qui est une mauvaise hypothèse. Ce qui protège réellement l'expéditeur contre une violation involontaire des lois sur l'opt-in, c'est d'obtenir la permission du destinataire avant l'envoi.

### Pratiquer une bonne hygiène des données

- Des études indiquent qu'environ **30 % des adresses email sont délaissées par leurs utilisateurs chaque année**.
- Les adresses délaissées sont un poids mort : elles tirent les statistiques vers le bas et compliquent la mesure de l'efficacité du programme.
- Les expéditeurs devraient **retirer régulièrement de leurs listes les adresses qui ne réagissent pas**. Les règles précises de retrait dépendent de l'expéditeur, des produits et du cycle de vente.

## Pires pratiques

### Envoyer du courrier sans permission explicite

C'est la mauvaise pratique la plus répandue. Un cas courant : des entreprises ajoutent automatiquement l'adresse des acheteurs à leurs listes marketing, sans leur demander. C'est une source très fréquente de problèmes de livraison, surtout pour les achats ponctuels. Par exemple, un acheteur qui a acheté un **cadeau** pour quelqu'un d'autre n'a aucun intérêt pour de futurs envois. Il peut signaler l'expéditeur comme spammeur auprès d'un grand FAI et ne jamais racheter chez ce commerçant.

<a id="buying-lists"></a>

### Acheter des listes

- Des milliers de vendeurs proposent des « listes opt-in 100 % fondées sur la permission », et beaucoup de ces listes n'en sont rien : elles sont collectées, compilées ou volées.
- Comme les listes achetées ont un historique de problèmes de livraison et d'inscriptions sur des listes de blocage, **de nombreux ESP interdisent purement et simplement les listes achetées**.
- Les listes achetées contiennent souvent des **[adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges)** et un grand nombre d'adresses qui ne peuvent pas recevoir de courrier, ce qui fait baisser la réputation de l'expéditeur.
- Ce sont aussi de mauvais outils d'acquisition de clients. Les listes sont revendues encore et encore, les destinataires sont submergés de courrier qu'ils n'ont pas demandé et ignorent les offres, et les problèmes de livraison peuvent s'étendre à **l'ensemble du programme d'email**, et pas seulement au flux d'acquisition.

### Changer de domaines et d'adresses From

La reconnaissance de l'expéditeur favorise l'engagement et la livraison, à deux niveaux :

- **Les FAI** reconnaissent les expéditeurs à la combinaison de l'**adresse IP et des domaines d'envoi**.
- **Les utilisateurs** reconnaissent un email à ce qui s'affiche dans leur boîte de réception (l'adresse From).

**Planifiez** tout changement de domaines, d'adresses IP et d'adresses From, pour réduire le risque sur la livraison. (Voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip) pour les changements d'adresse IP.)

### Programmes d'affiliation

- Des affiliés négligents peuvent causer de graves problèmes de livraison, même pour le courrier opt-in d'un expéditeur. Certains affiliés font appel à des **sous-affiliés** qui envoient du spam au nom de la marque à son insu.
- Les incitations financières attirent des expéditeurs sans scrupules. Trop de spam faisant la promotion d'un produit ou d'un service donné peut **nuire à la réputation de tout le courrier lié à ce produit ou service**, y compris le courrier opt-in légitime, les reçus et le courrier transactionnel.

## Conclusion : la réputation suit d'un flux à l'autre

- Le meilleur moyen d'atteindre la boîte de réception est d'envoyer un courrier que les destinataires désirent et attendent, et de demander d'abord la permission.
- Indiquez clairement ce à quoi les destinataires s'abonnent, et **tenez ces promesses**. N'envoyez pas un email quotidien à quelqu'un qui s'est inscrit à une newsletter mensuelle, et ne partagez pas vos listes avec d'autres entreprises sans permission explicite.
- **La réputation peut suivre un expéditeur d'un flux de messagerie à l'autre.** De mauvaises pratiques dans le marketing d'acquisition peuvent affecter les emails de fidélisation et les emails transactionnels. Même lorsque les expéditeurs pensent que leur réputation ne peut pas être suivie et appliquée d'un flux à l'autre, elle l'est souvent. (C'est l'argument en faveur de la séparation des flux, décrite dans [Segmentation et allocation avancées des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip), mais n'oubliez pas que la séparation ne rend pas acceptable une mauvaise pratique.)

# Contenu et design au service de la délivrabilité

> Les facteurs de filtrage liés au contenu : mythes et réalité des mots déclencheurs de spam, équilibre texte/images, pratiques en matière de liens, en-têtes, lignes d'objet, onglets de Gmail et design qui favorise l'engagement.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite

La réputation et la qualité de la liste pèsent le plus dans les décisions de filtrage (voir [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)), mais le contenu est le seul critère de filtrage que vous maîtrisez directement, pour chaque message que vous envoyez. Selon Litmus, **70 % des emails présentent au moins un problème lié au spam** susceptible de les tenir à l'écart de la boîte de réception.

Les filtres anti-spam modernes sont des systèmes d'apprentissage automatique, entraînés sur des schémas de spam et de phishing et qui s'ajustent en temps réel. Les règles de contenu consistent donc à éviter les schémas de spam et à optimiser l'engagement, et non à suivre une liste fixe de mots-clés.

## Mots déclencheurs de spam : mythe et réalité

**Mythe** : certains mots (« gratuit », « achetez maintenant », « soldes ») envoient automatiquement les messages dans le dossier spam, et éviter une liste magique de mots garantit le placement en boîte de réception.

**Réalité** : les mots déclencheurs ne posent pas de problème en eux-mêmes ; c'est la manière de les employer qui compte. Une offre réellement gratuite présentée comme gratuite ne pose aucun problème. Une promesse « gratuite » trompeuse, ou une « vente flash » qui revient chaque semaine, provoque des plaintes pour spam et de l'attrition de la liste, et ce sont ces signaux de plaintes et d'engagement qui font chuter le placement. Les filtres entraînés sur les retours réels des utilisateurs sanctionnent les schémas trompeurs, pas le vocabulaire.

Certains schémas de contenu correspondent encore réellement à du spam :

| Schéma | Pourquoi c'est pénalisant |
|---|---|
| Lignes d'objet trompeuses ou fausses promesses | Elles provoquent des plaintes, et la tromperie est le signal central que visent les filtres |
| TOUT EN MAJUSCULES et suites de points d'exclamation | Une forte corrélation classique avec le spam |
| Symboles en excès ($$$, avalanches d'emojis) dans l'objet | Idem |
| Fautes d'orthographe (surtout les graphies délibérées pour contourner les filtres) | Une technique historique des spammeurs |
| Messages uniquement en HTML, sans partie texte | Mal accueillis par les fournisseurs, et ils s'affichent mal quand les images sont bloquées |

## Équilibre entre texte, images et liens

- **Des rapports texte sur images et texte sur liens plus élevés sont préférables.** Trop d'images ou de liens par rapport au texte déclenche les filtres anti-spam. Les filtres se méfient des emails dominés par les images, car l'email tout en images est une technique classique de contournement des filtres.
- Les fournisseurs **bloquent souvent les images par défaut**, donc un email composé uniquement d'images n'affiche rien au destinataire, ce qui nuit aux signaux d'engagement qui déterminent le placement. Envoyez toujours en **multipart (texte et HTML)** ou en texte seul.
- Ajoutez un **texte alternatif** (*alt text*) aux images. Il préserve le sens quand les images sont bloquées, aide les lecteurs d'écran et réduit les plaintes dues à l'agacement.
- Une mise en page lisible et un contraste suffisant influent sur l'engagement, et l'engagement influe sur le placement. Les liens cassés et les images manquantes agacent les abonnés et font baisser les clics.
- Testez le rendu dans les principaux clients de messagerie avant l'envoi. Un message qui s'affiche mal dans un client perd sans bruit le signal d'engagement de ce fournisseur.

## Pratiques en matière de liens

- **Les domaines des liens doivent correspondre au domaine d'envoi**, ou au moins partager la même racine organisationnelle. Des liens vers des domaines sans rapport sont un schéma de phishing.
- **Évitez les raccourcisseurs d'URL publics.** Les spammeurs les utilisent beaucoup, et certains filtres les pénalisent d'office.
- Évitez **les liens trop nombreux**, et n'envoyez jamais de **liens cassés**.
- Utilisez un **domaine de suivi des clics à votre marque (avec SSL)** plutôt que le domaine de suivi partagé d'un fournisseur de services de messagerie (ESP). Il aligne les liens de suivi sur votre marque ou votre domaine racine, vous met à l'abri du comportement des autres expéditeurs sur un domaine de suivi partagé, et augmente de façon mesurable la probabilité de clic.

## En-têtes et détails de structure

- **Le domaine From doit correspondre au domaine d'envoi réel.** C'est une question d'alignement DMARC, pas seulement de présentation, et Hotmail de Microsoft est particulièrement strict. Même `mail.example.com` face à `example.com` peut suffire à faire classer des messages en spam chez certains serveurs de réception. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).
- Gmail examine de près les **en-têtes Message-ID et Received**. Un Message-ID mal formé (sans les chevrons `< >`, ou avec le mauvais domaine après le `@`) évoque un logiciel de spam. Si votre infrastructure génère correctement les Message-ID, ne les remplacez pas dans le code applicatif.
- **Personnalisez le champ To:** avec l'adresse réelle du destinataire, et utilisez son nom dans la formule d'appel.
- Incluez un **lien de désabonnement fonctionnel et des en-têtes List-Unsubscribe**. Plusieurs fournisseurs (notamment Hotmail et Outlook) filtrent les messages qui en sont dépourvus, et le désabonnement en un clic est une exigence de Gmail et de Yahoo envers les expéditeurs de gros volumes. Une option de désabonnement difficile à trouver se transforme en plaintes pour spam, un signal bien plus dommageable.
- Incluez une **adresse postale** et, idéalement, un lien vers votre politique de confidentialité (CAN-SPAM exige le mécanisme de désabonnement et l'adresse postale).

## Lignes d'objet

- La ligne d'objet est la première chose que voit le destinataire. Elle décide de l'ouverture, et les ouvertures influent sur le placement.
- Ne trompez jamais. Un décalage entre l'objet et le corps est l'une des premières causes de plaintes et un signal de filtrage direct.
- Limitez les symboles au minimum et évitez les majuscules intégrales.
- **Testez systématiquement vos lignes d'objet en A/B.** Tester pour trouver une variante gagnante (avec un rapport sur le niveau de confiance dans le résultat) est l'expérience de contenu qui a le plus d'effet sur le taux d'ouverture. Comparez vos résultats à la valeur de référence d'un taux d'ouverture d'au moins 33 % (voir [Surveillance et remédiation de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation) pour le tableau complet des seuils).

## Onglets de Gmail : Principale (*Primary*), Promotions, Notifications (*Updates*), Réseaux sociaux (*Social*), Forums

- Les algorithmes de Gmail décident du classement dans un onglet après la livraison. Les expéditeurs ne peuvent pas choisir l'onglet à l'avance, mais le contenu influe sur le résultat.
- **Promotions n'est pas le dossier spam.** Des études montrent que les emails de l'onglet Promotions n'ont pas subi la baisse redoutée du taux d'ouverture, et y atterrir est normal pour des emails marketing.
- Les facteurs qui poussent vers Principale sont la personnalisation (par exemple l'insertion du prénom, avec des valeurs de repli), un style conversationnel d'individu à individu, et un nombre limité d'images et de liens. Les messages très formatés, dominés par les images et chargés de liens sont classés dans Promotions.
- Les utilisateurs peuvent faire glisser un message vers un autre onglet et demander à Gmail de continuer ainsi, donc demander aux lecteurs engagés de vous déplacer dans Principale est légitime et efficace.
- Les outils de test sur liste de test peuvent prévoir, avant l'envoi, l'onglet dans lequel un message donné sera classé (voir [Surveillance et remédiation de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation)).

## Pratiques qui favorisent l'engagement

Le contenu gagne le placement en boîte de réception indirectement, en produisant les signaux d'engagement que récompensent les fournisseurs :

- **La pertinence et le ciblage comptent plus que tout le reste.** Segmentez et personnalisez. Un contenu inadapté au segment se traduit par des désabonnements et des plaintes.
- **Facilitez les réponses.** Envoyez depuis une adresse qui accepte les réponses, et invitez-les. Les réponses et les transferts comptent parmi les signaux positifs les plus forts, et une vraie conversation « fait des merveilles » pour la réputation.
- **Fixez des attentes à l'inscription et respectez-les**, par exemple avec une série de bienvenue qui annonce le contenu et la fréquence. Ajustez ensuite la fréquence à l'engagement : réduisez-la à mesure que l'engagement d'un destinataire baisse. Écrire souvent à des profils inactifs nuit à la réputation, tandis qu'écrire trop peu aux profils engagés fait seulement perdre du chiffre d'affaires.
- **Apportez une valeur autre que des offres** (contenu pédagogique, informations utiles). Les flux purement promotionnels épuisent l'engagement.
- **Testez le contenu avant l'envoi.** Faites passer les messages par un test de filtre anti-spam ou un test sur liste de test (par exemple Mail-Tester ou des outils commerciaux) pour repérer les éléments de contenu signalés avant un envoi réel, et ne faites varier qu'un paramètre par test.
- Suivez, pour chaque campagne, les ouvertures, les clics, le temps de lecture, les suppressions sans lecture, les réponses et les transferts, les plaintes et les pics de désabonnement. C'est là que les problèmes de contenu apparaissent en premier.

La vitesse de production est aussi un risque proche du contenu. Les équipes produisent désormais des campagnes en 1 à 3 jours (contre 2 semaines ou plus en 2024), et une cadence d'envoi fortement accrue peut elle-même paraître suspecte aux fournisseurs si le volume augmente en même temps.

## Voir aussi

- [Surveillance et remédiation de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation), sur les seuils des indicateurs et les outils de test et de surveillance
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email), sur la façon dont les signaux d'engagement alimentent le filtrage
- [Les deux mondes de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email), sur les raisons pour lesquelles un contenu désiré et attendu vaut mieux que de chercher à tromper les filtres

# Distorsions du suivi et de la mesure

> Le fonctionnement mécanique du suivi des ouvertures et des clics, et la façon dont Apple MPP, Microsoft Safe Links, les scanners des passerelles et les proxys d'images faussent les indicateurs qui en résultent, avec des repères sur les signaux qui restent fiables.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure

Si votre politique de mise en sommeil, vos segments de chauffe d'« ouvreurs récents » ou vos valeurs de référence de taux d'ouverture dépendent des données d'engagement, ils dépendent de deux mécanismes de suivi que les fonctions de confidentialité et les scanners de sécurité faussent désormais systématiquement. Voici comment fonctionnent le suivi des ouvertures et celui des clics, ce qui fausse chacun d'eux, et les indicateurs auxquels vous pouvez encore vous fier.

> Note sur les sources : les trois articles du centre d'aide de Litmus cités ont été déplacés vers une base de connaissances Validity (knowledge.validity.com) qui ne se charge qu'avec JavaScript et ne peut pas être récupérée sous forme de pages statiques. Le contenu ci-dessous provient d'instantanés de la Wayback Machine des pages d'origine de help.litmus.com (captures du 2024-09-16, du 2024-12-11 et du 2025-02-13 ; les pages indiquent des dates de « dernière mise à jour » d'août 2023 à novembre 2024).

## Le fonctionnement du suivi

### Le suivi des ouvertures : le pixel 1×1

Le suivi des ouvertures insère une **image transparente de 1×1** (le « pixel de suivi ») dans le corps HTML. Son URL est propre à chaque destinataire et pointe vers le domaine de suivi de l'expéditeur ou de l'ESP. Quand le client de messagerie affiche le message et télécharge les images distantes, la requête du pixel atteint le serveur de suivi, qui enregistre une « ouverture » avec l'adresse IP à l'origine de la requête, l'user-agent et un horodatage. Litmus décrit ses propres statistiques de la même façon : « Email Analytics utilise un pixel de suivi 1x1, comme la plupart des ESP pour fournir les indicateurs de taux d'ouverture. Chaque fois que ce pixel est chargé, nous détectons une ouverture. »

Certaines conséquences découlent de la conception elle-même, avant même qu'une fonction de confidentialité n'entre en jeu :

- **Si aucune image ne se charge, aucune ouverture n'est enregistrée.** Les clients dont les images sont désactivées, l'affichage en texte brut ou les clients texte seul produisent des faux négatifs. Un « taux d'ouverture » est en réalité un *taux de chargement du pixel*.
- **Chaque chargement d'image enregistre une ouverture.** Cela inclut l'expéditeur qui prévisualise la campagne dans l'ESP ou dans un navigateur, le message publié sur un site web ou sur les réseaux sociaux, et un code de suivi réutilisé d'un modèle à l'autre (autant de défaillances documentées par Litmus).
- **Ouvertures totales et uniques :** les requêtes brutes sur le pixel sont les ouvertures *totales*. Les ESP dédoublonnent pour compter les ouvertures *uniques* de chaque destinataire, car ils savent à quel abonné appartient chaque requête.
- Les ESP filtrent déjà les chargements manifestement faits par des machines. Litmus note que certains fournisseurs « écartent tous les [chargements de pixel] qui semblent être des doublons, par exemple si plus de 4 requêtes sont enregistrées en moins d'une seconde… pour contrer les ouvertures par proxy qu'utilisent certains fournisseurs de messagerie pour accélérer le chargement des emails ».

### Le suivi des clics : les liens de redirection réécrits

Le suivi des clics réécrit chaque `href` du message pour qu'il pointe vers le domaine de redirection (de suivi) de l'expéditeur ou de l'ESP, avec un identifiant encodé. Le serveur de redirection enregistre la requête et renvoie une redirection HTTP vers la destination d'origine. Selon les termes de Litmus, les destinataires « sont redirigés vers un serveur web spécial hébergé par votre ESP, qui prend note de la "requête" puis les envoie à destination » (*are redirected to a special web server hosted by your ESP that makes a note of the 'hit' and then sends them on their way*). Seule la plateforme d'envoi peut le faire, car les liens doivent être réécrits au moment de l'envoi. C'est pourquoi les outils qui ne fournissent que des statistiques, comme Litmus, ne proposent pas de suivi des clics.

Le domaine de suivi a sa propre réputation. Les listes de blocage d'URL et les filtres de contenu évaluent le domaine de redirection présent dans le corps du message, si bien qu'un domaine de suivi partagé répartit la réputation entre tous les expéditeurs qui l'utilisent (voir [Contenu et design au service de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite)).

## Source de distorsion 1 : Apple Mail Privacy Protection (MPP)

MPP a été introduite avec iOS 15 et macOS Monterey (2021). Elle est disponible dans Apple Mail sur iOS, iPadOS, visionOS et macOS, et sur iCloud.com. Elle s'applique à **toute boîte de réception lue dans Apple Mail**, pas seulement aux adresses @icloud.com.

### Ce qu'en dit la documentation d'Apple elle-même

D'après la page juridique et de confidentialité d'Apple :

- Le contenu distant est téléchargé « **en arrière-plan par défaut, que vous interagissiez ou non avec l'email** ». Le pixel est téléchargé à l'avance, à l'arrivée du message, et non quand une personne le consulte.
- Les téléchargements passent par **deux relais distincts** : « Le premier connaît votre adresse IP, mais pas le contenu de Mail provenant de tiers que vous recevez. Le second connaît le contenu distant de Mail que vous recevez, mais pas votre adresse IP » (*The first knows your IP address, but not any third-party Mail content you receive. The second knows the remote Mail content you receive, but not your IP address*). L'expéditeur voit donc l'adresse IP d'un proxy d'Apple, et non celle du destinataire.
- Son objectif déclaré est d'empêcher les expéditeurs de savoir « quand et combien de fois vous avez ouvert leur email, si vous avez transféré l'email, votre adresse IP (Internet Protocol) et d'autres données » (*when and how many times you opened their email, whether you forwarded the email, your Internet Protocol (IP) address, and other data*).

D'après le guide d'assistance de Mail sur macOS (Mail > Settings > Privacy) :

- Avec **Protect Mail Activity** activé, « votre adresse IP est masquée aux expéditeurs et le contenu distant est téléchargé de façon privée en arrière-plan **lorsque vous recevez un message (et non lorsque vous le consultez)** » (*your IP address is hidden from senders and remote content is privately downloaded in the background when you receive a message (instead of when you view it)*).
- Quand il est désactivé, deux options indépendantes apparaissent : **Hide IP Address** (l'adresse IP est masquée, mais le contenu n'est pas téléchargé à l'avance) et **Block All Remote Content** (rien de distant ne se charge ; l'utilisateur voit un bandeau et peut charger le contenu manuellement).
- Selon la page juridique, Hide IP Address « masquera toujours votre adresse IP » (*will still mask your IP address*) même quand MPP elle-même est désactivée.

La fonction est proposée à la première ouverture de Mail et reste activée sauf si l'utilisateur la désactive. En pratique, presque tous les utilisateurs d'Apple Mail l'ont activée. Les réglages se trouvent dans Settings > Apps > Mail > Privacy Protection sur iOS, iPadOS et visionOS, dans Mail > Settings > Privacy sur le Mac, et dans Settings > Privacy & Security sur iCloud.com.

### Ce que cela fait aux données de l'expéditeur

| Signal | Effet sous MPP |
|---|---|
| Événement d'ouverture | Enregistré pour ~chaque message livré à un utilisateur d'Apple Mail, engagé ou non : **des faux positifs à grande échelle** |
| Horodatage de l'ouverture | Reflète le calendrier de téléchargement anticipé d'Apple, et non l'heure de lecture. Inutilisable pour optimiser l'heure d'envoi pour ces destinataires |
| Nombre d'ouvertures et réouvertures | Supprimés. Plusieurs consultations par une personne ne peuvent pas être distinguées |
| Adresse IP du destinataire | Remplacée par l'adresse IP de sortie d'un relais d'Apple. La géolocalisation pointe vers l'infrastructure d'Apple, au mieux à peu près vers une région |
| Empreinte de l'appareil et du client | Masquée. La requête du proxy ne révèle pas le vrai client |
| Contenu dynamique (comptes à rebours, images ciblées selon la localisation) | Rendu au moment et à l'endroit du téléchargement anticipé, et non au moment de la consultation |

Les opérateurs doivent connaître une réserve : le téléchargement anticipé n'est pas garanti pour chaque message, car les appareils doivent être branchés ou connectés à un réseau pour l'activité en arrière-plan. Les ouvertures MPP représentent donc près de 100 % du volume livré à ces destinataires, sans l'atteindre exactement. Vous pouvez repérer les ouvertures MPP dans les données d'événements grâce à **l'user-agent du proxy d'Apple et aux plages d'adresses IP d'Apple** sur les requêtes du pixel.

MPP ne touche **pas** aux clics. Un clic provient toujours d'une vraie action de l'utilisateur. L'adresse IP de la visite de la page de destination qui suit peut être masquée par iCloud Private Relay pour les utilisateurs de Safari, mais l'événement de clic lui-même est authentique.

## Source de distorsion 2 : Microsoft Safe Links (côté clics)

Safe Links est la protection des URL de Microsoft Defender for Office 365. Elle compte pour les expéditeurs parce qu'elle **réécrit leurs liens** et **les visite sans qu'aucune personne ne clique**.

Son fonctionnement, d'après la documentation de Microsoft sur les stratégies Safe Links :

- **La couverture est activée par défaut.** Il n'existe pas d'objet de stratégie Safe Links par défaut, mais la stratégie de sécurité prédéfinie **Built-in protection** « fournit la protection Safe Links à tous les destinataires par défaut » (*provides Safe Links protection to all recipients by default*) dans toute organisation disposant d'une licence Defender for Office 365 (Plan 1/2, inclus dans Microsoft 365 E5 et diverses offres pour entreprises). Les stratégies prédéfinies Standard et Strict et les stratégies personnalisées s'y ajoutent. Les modifications de stratégie mettent jusqu'à 6 heures à s'appliquer.
- **Réécriture des URL :** le réglage par défaut pour les emails est « Safe Links checks a list of known, malicious links when users click links in email. **URLs are rewritten by default** » (Safe Links vérifie une liste de liens malveillants connus quand les utilisateurs cliquent sur des liens dans un email ; les URL sont réécrites par défaut). Les liens du message livré pointent vers `*.safelinks.protection.outlook.com`, avec l'URL d'origine encodée en paramètre, ce qui permet une **vérification au moment du clic**. Chaque clic passe par Microsoft avant d'atteindre la redirection de suivi de l'expéditeur.
- **Analyse en temps réel et détonation :** l'option « Apply real-time URL scanning for suspicious links and links that point to files » (`ScanUrls`) analyse le contenu lié, et « Wait for URL scanning to complete before delivering the message » (`DeliverMessageAfterScan`, activation recommandée) retient la livraison jusqu'à la fin des analyses. Ces analyses **visitent les URL de l'expéditeur depuis l'infrastructure de Microsoft**. Chaque visite d'un lien de suivi réécrit est enregistrée par l'ESP comme un « clic » qu'aucune personne n'a fait, généralement quelques secondes après la livraison.
- **Mode API uniquement :** « Do not rewrite URLs, do checks via SafeLinks API only » laisse les URL du corps inchangées, et les clients Outlook pris en charge appellent Safe Links quand l'utilisateur clique. Dans ce mode, les liens de l'expéditeur ne semblent pas réécrits, mais les vérifications au moment du clic ont toujours lieu.
- **Listes d'URL à ne pas réécrire :** les administrateurs peuvent exempter des URL (`DoNotRewriteUrls`) de la réécriture pendant le flux de messagerie. Microsoft précise que les URL exemptées « peuvent encore être bloquées au moment du clic » (*might still be blocked at time of click*), sauf si elles sont aussi autorisées dans la Tenant Allow/Block List.
- **Télémétrie des clics :** « Track user clicks » (`TrackUserClicks`) est activé par défaut. Les pages d'avertissement sur les URL bloquées peuvent empêcher complètement l'utilisateur d'accéder au lien (`AllowClickThrough $false`). Un vrai clic sur un domaine de suivi signalé à tort n'atteint alors jamais l'expéditeur. Ce chemin produit des **faux négatifs** de clics, en plus des faux positifs de la détonation.

C'est sur les listes B2B (clients Microsoft 365) que les expéditeurs voient le plus ces effets. Les destinataires d'entreprise soumis à la stratégie prédéfinie Strict produisent les visites de liens avant livraison les plus agressives.

## Source de distorsion 3 : les autres passerelles et scanners de sécurité

D'autres produits suivent le modèle de Safe Links. Les passerelles de messagerie sécurisées (Proofpoint, Mimecast, Barracuda, Cisco IronPort, la protection avancée de Google Workspace, et de nombreux antivirus) ont couramment pour habitude de :

- **Visiter chaque lien** d'un message au moment de la livraison ou peu après, pour vérifier les destinations (« détonation des liens » ou sandboxing). Cela inclut le lien de désabonnement. C'est pourquoi le désabonnement en un clic de la RFC 8058 utilise POST plutôt que GET (voir [List-Unsubscribe et désabonnement en un clic](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic)) : les scanners envoient des requêtes GET, donc un désabonnement qui agit sur un GET est déclenché par des robots.
- **Réécrire les liens** par leurs propres redirecteurs (par exemple `urldefense.com`, la protection des liens de Mimecast), ce qui ajoute une seconde redirection devant la redirection de suivi de l'ESP.
- **Télécharger le pixel de suivi** pendant l'analyse du contenu, ce qui produit des « ouvertures » par des scanners depuis des adresses IP de centres de données.

Les comportements qui distinguent les clics de scanners des clics humains :

| Heuristique | Schéma d'un scanner ou d'un robot | Schéma d'une personne |
|---|---|---|
| Délai après la livraison | De quelques secondes à ~2 minutes après l'acceptation du message par le serveur SMTP, souvent avant toute ouverture | De quelques minutes à plusieurs jours plus tard, généralement après une ouverture |
| Couverture | Tous les liens du message, ou presque, sont cliqués, y compris le désabonnement et les liens du pied de page | Un lien de contenu, ou quelques-uns |
| Ordre | Les liens sont visités dans l'ordre où ils apparaissent dans le HTML, presque au même moment | Irrégulier, et généralement un seul clic |
| Adresse IP source | Un centre de données ou le réseau (ASN) d'un éditeur de sécurité (plages de Microsoft, de Proofpoint ou de Barracuda), souvent une seule adresse IP qui clique pour de nombreux destinataires | Le fournisseur d'accès résidentiel ou mobile du destinataire, ou l'adresse de sortie de son entreprise |
| User-agent | Des agents sans interface ou génériques, ou des agents qui ne correspondent pas au client qui a ouvert le message | Des agents de navigateur et d'appareil cohérents |
| Comportement après le clic | Aucune session sur la page de destination, et aucune autre page vue | Une session web normale |

Pour filtrer les clics de robots en pratique, évaluez chaque événement selon plusieurs de ces heuristiques plutôt qu'une seule. Certains scanners ne cliquent que sur une sélection aléatoire de liens, et certaines adresses IP de sortie d'entreprise servent à la fois aux scanners et aux personnes. Ne déclenchez jamais une action irréversible, comme un désabonnement, une modification des préférences ou un achat en un clic, sur une simple requête GET.

## Source de distorsion 4 : les proxys d'images de Gmail (et de Yahoo et AOL)

Gmail réécrit toutes les URL d'images par son **proxy d'images** (`googleusercontent.com`). Le client du destinataire télécharge les images depuis le cache de Google, et le proxy de Google les télécharge depuis le serveur de l'expéditeur. Les effets, confirmés par la page de Litmus sur les limites de ses statistiques :

- **L'adresse IP et la géolocalisation sont masquées.** Les requêtes du pixel proviennent des adresses IP du proxy de Google, et les détails de l'appareil se réduisent à la chaîne user-agent du proxy.
- **La mise en cache supprime les ouvertures répétées.** Une fois l'image en cache, les consultations suivantes peuvent être servies sans nouveau téléchargement depuis l'expéditeur, si bien que les réouvertures sont sous-comptées. Litmus les appelle « image cache opens » et **les exclut de ses rapports d'engagement (temps de lecture)**, car « l'engagement est aussi masqué par les processus des fournisseurs » (*engagement is also masked by the providers' processes*).
- Yahoo et AOL exploitent un proxy et un cache équivalents. Litmus note que depuis **août 2018** « Yahoo! Mail et AOL sont traités par les mêmes serveurs dorsaux » (*both Yahoo! Mail and AOL are processed by the same backend servers*), et que les deux ne peuvent pas être distingués (« Yahoo/AOL Mail via Yahoo/AOL's Image Cache »).
- Contrairement à Apple MPP, le proxy de Gmail a historiquement téléchargé les images **au moment de la consultation**, si bien qu'une ouverture par le proxy de Gmail indique toujours qu'une personne a ouvert le message. Il fausse qui l'a ouvert, où et sur quel appareil, mais pas le fait qu'il ait été ouvert. (Gmail a parfois téléchargé à l'avance les images de certains messages, donc considérez les ouvertures Gmail comme majoritairement humaines, mais sans garantie.)

## Ce que les éditeurs de statistiques reconnaissent eux-mêmes (Litmus)

Litmus documente les limites de son propre Email Analytics. Cette documentation est une base utile et honnête de ce que les statistiques fondées sur un pixel peuvent et ne peuvent pas affirmer :

- Il ne peut pas suivre les destinataires dont **les images sont désactivées** ni les clients texte seul. Ses statistiques sont « un moyen de ventiler votre taux d'ouverture » (*a way to break down your open rate*), autrement dit un éclairage sur les destinataires qui ont ouvert, et sur eux seuls.
- **Plus aucune donnée fiable sur le transfert ou l'impression** ne subsiste pour aucun fournisseur de messagerie (Litmus les a abandonnées pour des raisons de confidentialité et d'exactitude).
- **Apple MPP** et les caches d'images des fournisseurs font l'objet de réserves spécifiques. Les ouvertures concernées sont isolées ou exclues des rapports d'engagement.
- Les webmails (Gmail, Outlook.com, Yahoo, AOL) chargent le contenu de façon asynchrone et continuent de télécharger après que le lecteur est passé à autre chose, si bien que **le suivi du temps de lecture et de l'engagement est exclu** pour tous les webmails. Les clients qui ne peuvent pas être suivis exportent un temps de lecture de **-1**.
- L'identification des clients est grossière. Toutes les versions modernes d'Outlook pour Windows (2016+) « renvoient les mêmes identifiants » (*return the same identifiers*). Outlook pour Mac affiche avec WebKit et apparaît comme Apple Mail. Lotus Notes ne peut pas être suivi.
- Les requêtes sur le pixel issues des aperçus dans l'ESP, des pages de campagne partagées ou publiées, et des codes de suivi réutilisés comptent toutes comme des ouvertures, sauf si elles sont retirées avant l'envoi.

Si un éditeur spécialisé dans les statistiques documente autant de bruit, l'indicateur d'ouverture brut d'un ESP en comporte au moins autant, plus l'inflation liée au téléchargement anticipé de MPP.

## Conséquences opérationnelles

### Les indicateurs auxquels vous pouvez encore vous fier

| Indicateur | Niveau de confiance | Remarques |
|---|---|---|
| Taux de livraison et de rebonds | Élevé | Mesurés au niveau SMTP, et non touchés par les distorsions du suivi |
| Taux de plaintes pour spam | Élevé | Fondé sur les feedback loops (FBL), et un vrai signal négatif venant de personnes |
| Désabonnement (en un clic, par POST) | Élevé | Un POST au titre de la RFC 8058 résiste aux requêtes GET des scanners |
| Conversions et activité sur votre site | Élevé | Elles exigent une vraie session. C'est le signal positif le plus fort |
| Clics (robots filtrés) | Moyen à élevé | Authentiques une fois les schémas de scanners (ci-dessus) filtrés |
| Clics (bruts) | Moyen | Gonflés par la détonation de Safe Links et des passerelles, surtout sur les listes B2B |
| Ouvertures, tendance globale | Moyen à faible | Encore utilisables pour comparer des campagnes au sein d'une audience de composition stable (l'inflation liée à MPP est à peu près constante d'une campagne à l'autre) |
| Ouvertures, pour un destinataire individuel | Faible | Une « ouverture » d'un utilisateur d'Apple Mail prouve la livraison, pas l'attention |
| Horodatage, localisation et appareil des ouvertures | Faible | Passent par un proxy ou sont téléchargés à l'avance pour les destinataires chez Apple, Gmail, Yahoo et AOL |

Le taux d'ouverture global garde un usage légitime : une baisse soudaine signale toujours un problème de livraison. Même les ouvertures par téléchargement anticipé exigent que le message atteigne la boîte de réception, si bien que, pour les destinataires chez Apple, les ouvertures MPP servent en pratique de mesure du placement en boîte de réception.

### Adapter les politiques de mise en sommeil aux ouvertures gonflées par MPP

La règle classique, « placer en suppression après N mois sans ouverture », échoue désormais dans les deux sens. Les utilisateurs de MPP semblent engagés en permanence, si bien qu'ils ne sont jamais mis en sommeil et que la liste se dégrade. Les utilisateurs dont les images sont désactivées semblent inactifs en permanence, si bien que des lecteurs engagés sont retirés. Revoyez la politique ainsi (cela prolonge [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil)) :

1. **Regroupez les destinataires selon la fiabilité de leurs ouvertures**, grâce à l'user-agent et à l'adresse IP des requêtes du pixel : ouvertures par le proxy de MPP, ouvertures depuis les caches des fournisseurs, et ouvertures directes.
2. Pour les destinataires concernés par MPP, définissez l'inactivité par **les clics, les conversions, les connexions au site et les achats**, jamais par les ouvertures. Allongez la période d'observation en conséquence, car les clics sont plus rares que les ouvertures. Une règle de 90 jours fondée sur les ouvertures peut devenir une règle de 180–365 jours fondée sur les clics et les conversions.
3. Pour les destinataires dont les ouvertures directes sont fiables, les ouvertures peuvent encore compter, avec un poids inférieur à celui des clics.
4. Conservez la vérification par l'activité hors email (visites du site web, achats). C'est désormais le signal principal, et non un recours.
5. Ne laissez pas les clics de robots déclencher un réengagement, pour qu'une détonation par Safe Links ne « sauve » pas une adresse morte. De la même façon, ne comptez jamais le GET d'un scanner sur le lien de confirmation d'une campagne de reconquête comme un consentement.

La même correction s'applique aux segments de chauffe. Les segments « les plus engagés » constitués pour la [chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip) devraient être classés selon la date des derniers clics ou conversions des destinataires, et non selon les ouvertures, sans quoi ils se rempliront d'utilisateurs Apple non engagés.

### Optimiser l'heure d'envoi et le contenu

- Les modèles qui optimisent l'heure d'envoi et sont entraînés sur les horodatages des ouvertures sont pollués par les calendriers de téléchargement anticipé. Entraînez-les uniquement sur les horodatages des clics.
- Le contenu dynamique (comptes à rebours, images personnalisées selon la localisation) est rendu quand Apple le télécharge à l'avance ou quand le proxy de Google le télécharge. Concevez le contenu pour que la version rendue au moment du téléchargement anticipé reste acceptable.
- Les tests A/B jugés sur les ouvertures mesurent surtout du bruit pour les destinataires chez Apple. Jugez les tests de ligne d'objet sur les clics et les conversions, ou limitez la lecture des ouvertures aux ouvertures qui ne sont pas passées par un proxy.

## Voir aussi

- [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite), avec les seuils que ces réserves nuancent
- [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil)
- [List-Unsubscribe et désabonnement en un clic](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic), y compris la raison pour laquelle le désabonnement en un clic utilise POST
- [Contenu et design au service de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite), y compris la réputation des domaines de suivi
- [Le modèle de livraison en sept étapes](https://emailmarketing.net/fr/apprendre/fondamentaux/modele-de-livraison-en-sept-etapes)

# Emails obligatoires et réglementaires

> Comment envoyer des avis de masse imposés par la loi (notifications de violation de données, rappels de produits, changements de politique) à des bases entières, y compris les adresses en liste de suppression et inactives, sans détruire la réputation d'expéditeur.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/emails-obligatoires-et-reglementaires

Certains messages doivent atteindre leurs destinataires indépendamment de l'engagement, du statut du consentement ou des indicateurs de délivrabilité : un expéditeur peut être légalement tenu ou contraint d'écrire à toute sa base, y compris aux adresses inactives depuis longtemps, désabonnées ou déjà placées en liste de suppression. C'est exactement ce que la pratique normale de la délivrabilité interdit (voir [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil)), et c'est pourquoi ces envois exigent un processus dédié. La recommandation du M3AAWG est explicite : ce processus est réservé **uniquement** aux messages obligatoires qui font exception aux pratiques d'envoi normales et qui présentent vraisemblablement un intérêt particulier pour le destinataire, jamais aux communications marketing ou transactionnelles habituelles.

## Définition et exemples

Les emails obligatoires (à haut risque) informent des personnes d'un changement de politique important, les aident à limiter un préjudice, leur proposent une assistance ou leur fournissent des informations non commerciales sur leur compte. Exemples typiques :

| Type | Exemple |
|---|---|
| Notification de violation de données | Annonce de la compromission d'un compte, avec réinitialisation du mot de passe ou offre gratuite de surveillance du crédit |
| Rappel de produit | Avis de santé et de sécurité |
| Changement de politique | Mises à jour de la politique de confidentialité ou des conditions d'utilisation |
| Statut du compte | Avis non commerciaux sur le compte du destinataire |

## Pourquoi ces envois sont dangereux pour la délivrabilité

- Ce sont des envois de masse **très susceptibles d'afficher de mauvais indicateurs de livraison** : rebonds élevés (adresses mortes revenues dans la liste) et plaintes (destinataires qui se sont désabonnés ou ont oublié la marque).
- Ils peuvent devoir être adressés à des personnes **déjà placées en liste de suppression ou désabonnées**, ce qui réintroduit exactement les signaux négatifs que la suppression sert à éviter (voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite) pour les seuils en jeu).
- Les pics de volume vers une base entière rompent les habitudes d'envoi et peuvent déclencher les mécanismes antispam des récepteurs (voir [Fondamentaux](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email) sur la façon dont les fournisseurs évaluent les expéditeurs).

Il appartient à chaque organisation de déterminer si un envoi à haut risque est nécessaire, en le mettant en balance avec la nature potentiellement abusive de ces messages et leur fréquence. Veillez à ce qu'ils restent peu intrusifs et perturbent le moins possible les utilisateurs et les fournisseurs de messagerie.

## Préparation avant l'envoi (organisation expéditrice)

**Prévenez les fournisseurs de messagerie à l'avance.** Utilisez le point de contact privilégié de chaque fournisseur (`postmaster@mailboxprovider.com` ou sa page de contact postmaster ; voir les articles [providers/](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie) pour les canaux connus). Adressez des notifications personnalisées aux fournisseurs de messagerie les plus pertinents pour l'audience ; lorsque c'est approprié, passez par un contact personnel ou par des groupes du secteur, à la discrétion de la plateforme d'envoi et de l'organisation.

**Coordonnez-vous en interne et en externe :**

- Consultez votre ESP pour les exigences techniques et les solutions qui maximisent l'efficacité tout en limitant l'impact sur la réputation des IP et du domaine.
- Transmettez les consignes, instructions et calendriers des autorités de régulation concernées ou de l'équipe juridique.
- Les équipes internes (réseaux sociaux, centre d'appels, personnel en contact avec la clientèle) doivent coordonner un message cohérent sur tous les canaux de service client.
- Déterminez si des informations sont nécessaires à des fins d'audit, et ce que cela implique.

## Choix d'infrastructure et d'authentification

| Pratique | Détail |
|---|---|
| Alias dédié | Utiliser un nouvel alias email pour ces notifications au lieu de l'alias marketing habituel (par exemple `notice@sub.example.com`) |
| Domaine de marque vérifié | Envoyer depuis un domaine de marque de l'organisation, vérifié sans ambiguïté par l'authentification de domaine (selon la [BCP du M3AAWG sur l'authentification des emails](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-l-authentification-des-emails)) |
| **Pas de domaines sosies** | **Ne pas** utiliser un domaine sosie nouvellement enregistré (une variante du domaine d'envoi habituel), ni enregistrer un nouveau domaine pour ces avis : ce procédé est impossible à distinguer du phishing |
| SPF + DKIM + DMARC | Les trois configurés sur le domaine d'envoi ; voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf), [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim), [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) |
| TLS | Pris en charge par le serveur d'envoi pour les récepteurs qui l'implémentent |
| Plage d'IP dédiée | Certains fournisseurs de messagerie encouragent à réserver une plage d'IP exclusivement aux adresses de notification des emails obligatoires (voir [Segmentation avancée des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip)) |

## Contenu et identification du message

- Nom d'expéditeur du type « [Nom de l'organisation] : Notification » ; « Notification importante » dans la ligne d'objet.
- **Un minimum d'éléments suivis** : limitez les liens à ceux qui sont indispensables, voire aucun.
- Un contenu qui porte exclusivement sur le sujet, **sans aucun marketing**.
- Un modèle sobre ou minimal, adapté au type de notification (voir [Contenu et design au service de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite)).
- **Suspendez les communications marketing pendant la période de notification** : le message obligatoire ne doit pas entrer en concurrence avec les emails promotionnels.

## Segmentation de l'audience et traitement de la liste

Décidez qui doit recevoir le message en fonction des exigences réelles de la notification, et échelonnez l'envoi **du groupe le moins risqué au plus risqué** :

1. Utilisateurs concernés
2. Utilisateurs actifs
3. Utilisateurs abonnés
4. Utilisateurs désabonnés
5. Utilisateurs ayant généré un rebond : **excluez totalement les adresses mortes connues** ; elles n'atteindront jamais le destinataire visé et ne font qu'abîmer la réputation

Pour les adresses connues pour rebondir et les utilisateurs qui ont déjà signalé la marque comme spam, utilisez des **canaux de contact alternatifs** plutôt que l'email : courrier postal, SMS, notification sur le site web, réseaux sociaux ou médias traditionnels (presse, radio, télévision). Certains groupes de destinataires sont par nature difficiles à joindre par email ; d'autres méthodes peuvent satisfaire l'obligation sans aucun coût en délivrabilité.

## Tâches de l'ESP : la coordination avec les fournisseurs de messagerie

Les ESP ont souvent peu de prise sur le contenu du message, généralement rédigé par les conseillers juridiques pour remplir les obligations de l'organisation liées à l'avis. Le rôle de l'ESP est la coordination et le rythme d'envoi. Les notifications préalables aux fournisseurs de messagerie devraient comprendre :

- Les coordonnées de l'organisation ou de l'administration auprès de laquelle les destinataires peuvent obtenir davantage d'informations, ainsi qu'une copie du message lui-même si possible
- Les volumes d'envoi et les jours nécessaires
- L'infrastructure d'envoi utilisée : domaines et noms d'hôtes d'envoi, adresses IP (idéalement une plage réservée), dates et heures, volumes attendus

Pendant l'envoi :

- **Limitez la vitesse d'envoi dans le temps** pour éviter les pics de volume qui surchargent les réseaux de réception et déclenchent les mécanismes antispam.
- Vérifiez que SPF, DKIM, DMARC et TLS sont en place avant le départ du premier message.

**Préparation contractuelle :** envisagez de définir à l'avance, dans le contrat client ou dans l'accord de protection des données (*Data Protection Agreement*), un processus privilégié pour les violations de données et les emails obligatoires, afin que la procédure existe avant l'urgence.

## Après l'envoi

Surveillez l'envoi comme tout événement à haut risque : taux de rebonds et de plaintes par rapport aux seuils de [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite), inscriptions sur des listes de blocage et tableaux de bord des fournisseurs selon [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation). Les adresses qui génèrent un rebond définitif ou une plainte pendant l'envoi obligatoire retournent dans la suppression normale : l'exception liée à l'obligation prend fin avec la période de notification, et la [politique de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil) habituelle reprend.

## Voir aussi

- [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil) : les règles normales auxquelles cet envoi déroge temporairement
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email) : pourquoi les envois à des bases inactives sont pénalisés
- [BCP du M3AAWG pour les expéditeurs](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs) : le socle dont ces pratiques s'écartent, délibérément et de façon ciblée
- [Articles sur les fournisseurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie) : les points de contact postmaster pour la notification préalable

# Envoyer des emails en IPv6

> Pourquoi les serveurs de réception imposent des règles plus strictes aux emails en IPv6 : le document du M3AAWG de 2014 sur la politique de réception (agrégation au /64, rejet sans PTR, rejet sans authentification) et ce que cela implique aujourd'hui pour les expéditeurs et les ESP.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/envoyer-des-emails-en-ipv6

Si vous prévoyez d'envoyer des emails en IPv6, attendez-vous à ce que les serveurs de réception appliquent des règles plus strictes qu'en IPv4 : un enregistrement PTR et une authentification réussie sont de fait obligatoires. Ces règles s'appuient sur un document du Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), *M3AAWG Policy Issues for Receiving Email in a World with IPv6 Hosts* (M3AAWG084, **septembre 2014**).

**Tenez compte de son âge.** C'est un document de position et d'exigences de 2014, rédigé comme « une première liste d'exigences pour de futurs services », et non un guide opérationnel. Ses principales prédictions se sont vérifiées : les grands serveurs de réception, Gmail en tête, exigent bien un PTR valide et une authentification réussie sur les connexions IPv6. Considérez comme historiques ses références précises à des institutions, par exemple le groupe de travail WEIRDS de l'IETF, dont les travaux ont depuis abouti à RDAP.

## Le problème de fond : la réputation par IP ne passe pas à l'échelle d'IPv6

- La lutte contre les abus en IPv4 repose sur la réputation de chaque adresse (/32) : limitation de débit, listes de blocage et évaluation de la réputation. C'est moins stable et moins fiable qu'on ne le souhaiterait, mais cela fonctionne, et « la plupart des systèmes antispam ne pourront pas fonctionner si l'efficacité de ces mécanismes est dégradée ».
- Les adresses /128 d'IPv6 cassent ce modèle. Suivre chaque /128 est irréaliste à grande échelle, et **un expéditeur capable d'envoyer chaque email depuis un /128 unique rend inefficaces les mécanismes fondés sur une seule adresse**.
- IPv6 rend donc indispensable la **réputation fondée sur le domaine** (associée ou non à une IP), ainsi que de meilleurs mécanismes d'agrégation des adresses.

Le M3AAWG a fixé trois objectifs pour l'email en IPv6 : agréger l'espace d'adresses en attributions qu'il est possible de suivre ; exiger des opérateurs qu'ils identifient les hôtes destinés à servir d'agents de transfert de messages (MTA) sortants ; et exiger un **identifiant valide fondé sur l'authentification du domaine** pour évaluer la réputation.

## Recommandation 1 : suivre les attributions agrégées et agir sur elles, pas sur les /128

- Les mécanismes fondés sur l'IP (limitation du débit des connexions, listes de blocage) doivent traiter une plage IPv6 suffisamment large comme une seule entité pour rester efficaces. Une plage trop large provoque des faux positifs, car elle mélange les MTA d'acteurs sans rapport entre eux.
- Idéalement, les fournisseurs d'accès à Internet publieraient la taille de leurs agrégats via un service ouvert et standard que les mécanismes antispam pourraient interroger. À défaut, des conventions sur des frontières d'agrégation communes suffisent.
- **Heuristique initiale : prenez le /64 comme taille d'attribution minimale par défaut.** Selon la RFC 4291, les 64 premiers bits identifient le préfixe de routage et le sous-réseau, et les 64 suivants identifient l'interface, et il est peu probable qu'une seule interface héberge les MTA de plusieurs acteurs au volume significatif. Les opérateurs peuvent agir sur des plages plus larges ou plus étroites lorsque c'est pertinent, et les éditeurs antispam sont censés collecter des données sur la taille des attributions dans le cadre de leurs services.

**Ce que cela implique pour les expéditeurs :** tout le /64 (ou le bloc plus large) partage le même sort. Les dégâts de réputation causés par un hôte, ou par un client d'un fournisseur de services email (ESP), peuvent faire inscrire l'agrégat entier sur une liste de blocage. Segmentez l'envoi en IPv6 en attribuant un /64 distinct à chaque flux ou à chaque catégorie de clients, comme dans la [pratique d'allocation des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip).

## Recommandation 2 : rejeter les emails des hôtes non identifiés comme MTA sortants

- Les botnets envoient des abus depuis des hôtes compromis dont les propriétaires n'ont jamais voulu en faire des MTA, donc n'accepter les emails que de sources explicitement autorisées réduit fortement la valeur des hôtes compromis. La gestion du port 25 sortant (la recommandation Port 25 du MAAWG) aide, mais elle n'est pas appliquée partout, et l'Internet des objets (IoT) va considérablement augmenter le nombre d'appareils vulnérables.
- Il n'existait aucune norme permettant aux opérateurs de déclarer quels hôtes sont destinés à servir de MTA sortants. SPF identifie les MTA sortants autorisés d'un domaine, mais « permet aussi à des propriétaires de domaines malveillants de désigner de grandes plages d'adresses IP qui ne leur appartiennent pas ». Le M3AAWG demandait une méthode standardisée, indexée par adresse IP, qui puisse être interrogée automatiquement. Rien de tel n'a été largement adopté depuis.
- Le mécanisme provisoire est le **DNS inverse**. De nombreux opérateurs rejettent déjà les connexions IPv4 sans enregistrement PTR, ou les jugent très suspectes. En IPv6, c'est un filtre passe-haut encore plus efficace, car les opérateurs ne publieront pas d'enregistrements PTR pour l'immense majorité de leur espace IPv6 (le bénéfice est faible, et c'est fastidieux à cette échelle), alors qu'il est tout à fait possible de maintenir des enregistrements PTR pour le petit nombre d'hôtes relais dédiés.
- **« En l'absence d'un mécanisme plus approprié […], le M3AAWG recommande de rejeter les emails provenant d'adresses IPv6 d'hôtes dépourvues d'enregistrements DNS inverse »**, jusqu'à ce qu'une meilleure norme existe (aucune ne l'a remplacée).

**Ce que cela implique pour les expéditeurs :** chaque adresse IPv6 d'envoi doit avoir un enregistrement PTR et, comme les serveurs de réception l'attendent en général, une confirmation directe concordante. Un PTR absent en IPv6 justifie un rejet pur et simple, et pas seulement de la méfiance.

## Recommandation 3 : rejeter les emails sans authentification de domaine valide

- Le besoin d'identifiants de réputation stables et exacts est encore plus grand en IPv6 qu'en IPv4, et les noms de domaine sont nettement plus stables que les adresses IP, même en IPv4.
- DKIM et SPF fournissent le domaine authentifié qui permet d'imputer la responsabilité : la valeur **`d=`** de DKIM, et le domaine **MAIL FROM** de l'enveloppe pour SPF (ou le domaine **EHLO ou HELO** pour les rebonds). Les grands fournisseurs avaient déjà déployé la réputation de domaine en complément de la réputation d'IP.
- **« Le M3AAWG recommande donc d'évoluer vers le rejet des emails qui ne contiennent pas de signature DKIM valide ou qui ne réussissent pas les vérifications SPF »**, ce qui permet une réputation cohérente et fiable, fondée sur le domaine authentifié, pour les décisions de livraison.

**Ce que cela implique pour les expéditeurs :** en IPv6, un email non authentifié n'est pas seulement pénalisé ; la position du secteur est qu'il doit être rejeté. C'est exactement ce que Gmail et les autres grands fournisseurs ont adopté pour les connexions IPv6 (voir [Exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs) : la livraison en IPv6 exige un enregistrement PTR et la réussite de SPF ou de DKIM). N'envoyez jamais en IPv6 depuis un flux dont SPF et DKIM ne sont pas parfaitement en ordre. Lorsque vous activez IPv6 sur un MTA, vérifiez d'abord l'authentification, sinon attendez-vous à des rebonds définitifs que le même flux ne subirait pas en IPv4.

## Domaines responsables

Des informations WHOIS exactes sont « un élément essentiel de la réputation d'un domaine ». Des enregistrements WHOIS complets devraient être obligatoires pour les domaines qui agissent comme clients SMTP, avec des contacts abuse fonctionnels. (Le document renvoie au remplaçant du WHOIS étudié par le groupe de travail WEIRDS de l'IETF, qui a abouti à RDAP.)

## Synthèse pratique pour un ESP (le document de 2014 et la pratique actuelle)

| Recommandation de 2014 | Réalité opérationnelle actuelle |
|---|---|
| Agréger la réputation au minimum au /64 | Les serveurs de réception et les listes de blocage DNS (DNSBL) inscrivent IPv6 avec une granularité de /64 ; planifiez les allocations en conséquence |
| Rejeter les emails IPv6 sans PTR | Appliqué par les grands serveurs de réception ; un enregistrement PTR avec confirmation directe est obligatoire |
| Rejeter les emails IPv6 qui échouent à SPF et n'ont pas de DKIM valide | Appliqué par Gmail en IPv6 depuis le milieu des années 2010 ; considérez que cela s'applique partout |
| Réputation de domaine plutôt que réputation d'IP | L'orientation générale de tout le filtrage moderne |

IPv6 ne laisse presque aucune tolérance aux erreurs d'authentification, et la livraison en double pile rend les échecs intermittents (les messages passent tantôt par IPv6, tantôt par IPv4). Pour ces raisons, de nombreux ESP préfèrent encore délibérément IPv4 pour les emails marketing sortants, ou n'activent IPv6 que sur des flux dont l'authentification est éprouvée.

## Voir aussi

- [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi)
- [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf)
- [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim)

# Événements de livraison et diagnostic

> La taxonomie des événements de livraison qu'émet un ESP ou un MTA (processed, deferred, delivered, bounce, blocked, dropped, spamreport, open, click), ainsi que les rapports de délivrabilité, le diagnostic des retards et le score de qualité de l'engagement : la couche d'instrumentation sous les procédures de dépannage.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/evenements-de-livraison-et-diagnostic

Lorsque vous devez savoir ce qui est arrivé à un message, ou pourquoi une campagne donne de mauvais résultats, la réponse commence dans le flux d'événements. Chaque message que traite un fournisseur de services de messagerie (ESP) passe par une suite d'états. Chaque changement d'état est un **événement** que la plateforme enregistre et peut vous transmettre en continu.

Les taux de rebonds et de plaintes, les estimations du placement en boîte de réception par fournisseur, l'analyse des retards et les scores d'engagement sont tous construits à partir de ces événements. L'Event Webhook de SendGrid sert ci-dessous d'exemple de référence, car il est entièrement spécifié. Après les événements viennent les rapports, le diagnostic des retards et le score d'engagement construits sur eux.

Pour les seuils qu'alimentent ces événements et les mesures correctives qu'ils déclenchent, voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite). Pour un diagnostic pas à pas, voir [Procédures de dépannage de la livraison](https://emailmarketing.net/fr/apprendre/operations/procedures-de-depannage-de-la-livraison). Les deux s'appuient sur les données décrites ici.

## La taxonomie des événements

Les événements se répartissent en trois familles. Les **événements de livraison** enregistrent ce que le système d'envoi et les serveurs de réception ont fait du message. Les **événements d'engagement** enregistrent ce qu'a fait le destinataire. Les **événements de compte** enregistrent les changements de statut au niveau de la plateforme. L'Event Webhook de SendGrid les publie en JSON. Les noms sont les libellés de SendGrid, mais toute infrastructure d'envoi produit des états équivalents.

### Événements de livraison

| Événement | Signification | Déclencheur |
|---|---|---|
| **processed** | La plateforme a accepté le message et peut le livrer | Le message a été injecté, validé et placé en file d'attente pour l'agent de transfert de courrier (MTA) sortant |
| **deferred** | Le serveur de réception a refusé le message **temporairement** | Une réponse 4.x.x du MTA distant (liste grise, limitation de débit, « try again later ») ; la plateforme réessaie |
| **delivered** | Le serveur de réception a accepté le message (`250 OK`) | Le MTA distant a renvoyé une réponse de succès 2.x.x à `DATA` |
| **bounce** | Le serveur de réception a rejeté le message | Un rejet permanent 5.x.x (ou un échec temporaire après épuisement des nouvelles tentatives), renvoyé pendant la session SMTP ou plus tard dans une notification d'état de livraison (DSN) asynchrone |
| **blocked** | Un sous-type de rebond *temporaire* : un rejet temporaire pour des raisons de réputation, de contenu ou un problème technique | Le MTA distant a rejeté le message, mais pas parce que l'adresse est invalide ; enregistré comme un rebond avec `type: "blocked"` |
| **dropped** | La **plateforme elle-même** a refusé d'envoyer, donc le message n'est jamais parti | Le destinataire figure dans une liste de suppression (après un rebond antérieur, un désabonnement, un signalement de spam ou une adresse invalide), le contenu a été signalé comme spam, un en-tête ou un modèle était invalide, ou un quota a été dépassé |

Les distinctions qu'un opérateur doit bien connaître :

- **Un report de remise n'est pas un rebond.** Un report est un refus temporaire que la plateforme continue de retenter. Il ne devient un rebond que si les nouvelles tentatives sont épuisées. Des reports persistants sont le signe classique d'une limitation de débit (voir [Diagnostic des retards et de la latence](#diagnostic-des-retards-et-de-la-latence)).
- **bounce et blocked sont différents.** SendGrid enregistre les deux comme un événement `bounce` et les distingue par le champ `type`. `type: "bounce"` est un rebond définitif, qui est permanent (par exemple, l'adresse n'existe pas). `type: "blocked"` est un rebond temporaire : un rejet temporaire à cause de la réputation, du contenu ou d'un problème technique. Dans les rapports Bounces & Blocks de l'interface, un **Bounce** désigne une adresse email invalide (qui n'a jamais existé ou a été désactivée), tandis qu'un **Block** signifie que le message a été rejeté pour des « content and reputation issues or technical failures » (problèmes de contenu et de réputation ou défaillances techniques). Un blocage est le jugement du serveur de réception sur vous, et non sur l'adresse, et il peut disparaître une fois corrigé le problème de réputation ou de contenu qui en est la cause. Voir [Listes de blocage DNS et zones Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus).
- **Un abandon, c'est la plateforme qui vous protège, ou votre propre erreur.** La plateforme a supprimé l'envoi avant la transmission. La plupart des abandons sont sains, car supprimer une adresse connue comme mauvaise protège la réputation. Un pic d'abandons pour des raisons inattendues (un modèle invalide, un quota dépassé) signale un défaut côté expéditeur, et non un problème chez le serveur de réception. [Architecture des listes de suppression](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture) explique la portée des suppressions.
- **Livré ne veut pas dire en boîte de réception.** `delivered` est publié quand le serveur de réception répond `250 OK`. Ensuite, le serveur de réception peut encore placer le message en boîte de réception, le mettre en file d'attente, le classer dans le dossier spam ou le courrier indésirable, le supprimer sans rien dire ou (chez Gmail) le ranger dans un onglet, et la plateforme d'envoi ne reçoit **aucun autre signal** sur tout cela. La seule preuve ultérieure est l'engagement du destinataire (ouvertures et clics). Un taux de livraison élevé avec un engagement quasi nul est le signe typique de messages classés en spam. C'est pourquoi le placement en boîte de réception ne peut être qu'*estimé*, par des tests sur liste de test et les tableaux de bord postmaster des fournisseurs, et jamais lu directement dans les événements de livraison. Voir [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure) et [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation).

### Classification des rebonds

Pour les événements `bounce`, SendGrid ajoute un champ `bounce_classification` qui range l'échec SMTP dans une catégorie de cause sur laquelle un opérateur peut agir :

| Classification | Signification et action de l'opérateur |
|---|---|
| **Invalid Address** | L'adresse n'existe pas ou n'a jamais existé. Retirez-la définitivement (hygiène de base de données) |
| **Mailbox Unavailable** | La boîte est pleine ou temporairement injoignable. Souvent temporaire ; peut se rétablir |
| **Technical** | Un échec DNS, de connexion, de protocole ou TLS, côté infrastructure |
| **Content** | Le contenu du message a déclenché un rejet ou un filtrage. Corrigez le contenu ou les liens |
| **Reputation** | La réputation de l'adresse IP ou du domaine d'envoi a causé le rejet. Travaillez sur la réputation |
| **Frequency/Volume** | Le débit ou le volume d'envoi est trop élevé pour le serveur de réception. Limitez le débit (voir [Réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta)) |
| **Unclassified** | L'échec n'a pas pu être rangé dans une catégorie |

Les catégories Content et Reputation alimentent le score de qualité de l'engagement (voir plus bas) comme alerte précoce, car elles montrent que le serveur de réception vous juge, et non que l'adresse est mauvaise.

### Événements d'engagement

| Événement | Signification | Déclencheur |
|---|---|---|
| **open** | Le destinataire a affiché le message HTML | Le pixel de suivi des ouvertures s'est chargé (Open Tracking doit être activé) |
| **click** | Le destinataire a cliqué sur un lien de suivi | Un lien réécrit a été suivi (Click Tracking doit être activé) |
| **spamreport** | Le destinataire a marqué le message comme spam (une *plainte*) | L'action « marquer comme spam » du destinataire, transmise par la feedback loop du fournisseur |
| **unsubscribe** | Le destinataire a cliqué sur le lien global de désinscription de tous les envois | Subscription Tracking est activé |
| **group_unsubscribe** | Le destinataire s'est désabonné d'un groupe de suppression | Un lien de désabonnement du groupe ou la page de préférences |
| **group_resubscribe** | Le destinataire s'est de nouveau abonné à un groupe | La page de préférences (Subscription Tracking activé) |

Deux précautions évitent que les événements d'engagement vous induisent en erreur :

- **Ouvertures par des machines.** SendGrid renseigne `sg_machine_open: true` lorsque l'ouverture a été générée par Apple Mail Privacy Protection (MPP), et non par une personne. Excluez ces ouvertures de toute mesure réelle de l'engagement. Le préchargement des images de Gmail déclenche aussi des ouvertures sans personne. Voir [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure) et [Interactions non humaines](https://emailmarketing.net/fr/apprendre/operations/interactions-non-humaines).
- **spamreport est votre signal de plainte.** C'est la partie de la feedback loop du fournisseur que voit l'expéditeur. Un taux de spamreport soutenu est la donnée d'entrée la plus dommageable pour la réputation. Voir [Feedback loops de plaintes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes).

### Événements de compte

SendGrid émet `account_status_change` lorsque la plateforme modifie la situation d'un compte pour des raisons de conformité (phishing, taux de spam élevés, « other bad behavior »). Le champ `type` donne l'action, par ordre de gravité croissante :

| `type` | Effet |
|---|---|
| `compliance_suspend` | Bloque la livraison ; met les messages en file d'attente et les fait rebondir au moment de la livraison |
| `compliance_deactivate` | Bloque la livraison ; rejette les files d'attente ; supprime les messages en file d'attente ; bannit l'utilisateur au bout de 48 heures |
| `compliance_ban` | Bloque la livraison ; rejette et supprime les files d'attente ; retire l'accès à la console ; annule la facturation ; retire les adresses IP |
| `reactivate` | Rétablit le compte en statut actif |

Pour la façon dont un opérateur d'ESP détecte et contient ces problèmes et applique l'échelle des sanctions, voir [Comptes compromis](https://emailmarketing.net/learn/esp-operations/compromised-accounts), [Surveillance des envois sortants](https://emailmarketing.net/learn/esp-operations/outbound-monitoring) et [Architecture multi-tenant](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture).

## Champs de la charge utile des événements

Le JSON du webhook comporte un ensemble de champs communs et des champs propres à chaque événement. Ce sont les champs que vous mettez en correspondance pour répondre à la question « qu'est-il arrivé à ce message ? ».

| Champ | Type | Événements | Signification |
|---|---|---|---|
| `email` | chaîne | tous | Adresse du destinataire |
| `timestamp` | entier (UNIX) | tous | Moment où l'événement s'est produit |
| `event` | chaîne | tous | Identifiant du type d'événement |
| `sg_event_id` | chaîne | tous | Identifiant unique de l'événement (compatible URL, ≤100 caractères), la clé pour supprimer les doublons |
| `sg_message_id` | chaîne | tous | Identifiant unique du message, la clé qui relie tous les événements d'un même message |
| `smtp-id` | chaîne | événements de livraison, ainsi que les événements bounce, spam et group | Message-ID attribué par le système d'origine |
| `category` | chaîne ou tableau | livraison et engagement | Étiquettes personnalisées que l'expéditeur définit pour organiser ses messages |
| `asm_group_id` | entier | la plupart | Identifiant du groupe de désabonnement (suppression) |
| `marketing_campaign_id` et `_name` | entier et chaîne | livraison et engagement | Identifiants de la campagne |
| `pool` | objet `{name, id}` | processed | Pool d'adresses IP depuis lequel le message a été envoyé |
| `ip` | chaîne | delivered, open, click, désabonnement et réabonnement à un groupe | Adresse IP d'envoi (delivered) ou adresse IP du destinataire (engagement) |
| `response` | chaîne | delivered, deferred | Texte intégral de la réponse du serveur de réception |
| `reason` | chaîne | bounce, deferred, dropped | Raison lisible de l'erreur ou de l'abandon |
| `status` | chaîne `X.Y.Z` | bounce, dropped | Code d'état étendu (voir [Codes d'état étendus](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp)) |
| `attempt` | entier | deferred | Nombre de tentatives de livraison jusqu'ici |
| `type` | chaîne | bounce, account | `bounce` ou `blocked`, ou l'action sur le statut du compte |
| `bounce_classification` | chaîne | bounce | Catégorie de cause (tableau ci-dessus) |
| `tls` | booléen | bounce, delivered | Indique si la connexion a utilisé TLS |
| `url` | chaîne | click, désabonnement et réabonnement à un groupe | L'URL concernée |
| `url_offset` | entier | click | Position du lien dans le HTML, à partir de zéro (les URL répétées reçoivent des positions différentes) |
| `useragent` | chaîne | open, click, désabonnement et réabonnement à un groupe | Programme client qui a généré l'événement |
| `sg_machine_open` | booléen | open | Vrai si l'ouverture a été générée par Apple MPP |
| `unique_args` | objet | livraison et engagement | Paramètres personnalisés fournis par l'expéditeur |

> SendGrid recommande de ne jamais placer de données personnelles dans `category` ou `unique_args`. La plateforme peut utiliser ces champs pour ses opérations internes, ils ne peuvent pas être masqués, et ils peuvent être conservés longtemps.

Une requête de diagnostic typique joint tous les événements qui partagent un même `sg_message_id` et les trie par `timestamp` pour reconstituer l'historique complet d'un message : processed, puis deferred une ou plusieurs fois, puis delivered, puis open. Une autre agrège par `event`, `bounce_classification` et domaine de réception pour trouver quel fournisseur rejette quelle catégorie de messages.

## Rapports de délivrabilité

Un tableau de bord de diagnostic construit à partir du flux d'événements suit le modèle « Deliverability Insights » (dans SendGrid, sous **Stats**, puis **Deliverability Insights**). Ses données ont environ **48 heures** de retard sur le temps réel. Il comporte quatre vues :

| Vue | Contenu |
|---|---|
| **Overview** | Processed (« la quantité de messages que vous avez tenté d'envoyer »), Delivered (% acceptés par les fournisseurs de messagerie), Bounce & Blocked (% non livrés) et Unique Opens (% des messages *livrés* qui ont été ouverts), en tendance dans le temps |
| **Mailbox Providers** | Les mêmes indicateurs pour chaque fournisseur (Gmail, Yahoo, Microsoft, AOL, …) : taux de livraison, taux d'ouverture, et répartition entre rebonds et blocages |
| **Bounces & Blocks** | Les deux types d'échec séparément : un **Bounce** est une adresse invalide ; un **Block** est un rejet pour des raisons de contenu, de réputation ou un problème technique |
| **Spam & Unsubscribes** | Les plaintes et les désinscriptions, par fournisseur |

Le choix de conception le plus important est la **segmentation par fournisseur de messagerie**. Un taux de livraison global de 95 % peut masquer un blocage total chez un fournisseur. La réputation est tenue séparément chez chaque fournisseur, donc le diagnostic et la correction doivent aussi se faire fournisseur par fournisseur (voir [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation) et [Réglages de référence par fournisseur](https://emailmarketing.net/fr/apprendre/operations/reglages-de-reference-par-fournisseur)). SendGrid publie ces seuils pour lire cette vue :

| Signal | Seuil |
|---|---|
| Taux de blocage | Objectif **≤ 3 %** chez chaque grand fournisseur de messagerie |
| Taux de signalement de spam | **≥ 0,1 %** chez un seul fournisseur, c'est excessif |
| Taux de rebonds | **Constamment au-dessus de 5 %**, c'est préoccupant |
| Déclencheur de mise en sommeil | Aucune ouverture ni aucun clic pendant **3 mois** : cessez d'écrire à cette adresse |

Ces seuils concordent avec les seuils rassemblés à partir de plusieurs sources dans [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite) : le consensus de ≤0,1 % de plaintes et de <5 % de rebonds, et la limite de 0,3 % que Gmail et Yahoo traitent comme une violation.

## Diagnostic des retards et de la latence

« Retard » peut désigner deux choses très différentes, et les confondre oriente le diagnostic dans la mauvaise direction.

**1. Retard chez le serveur de réception (reports de remise et limitation de débit).** Le message a quitté la plateforme, mais le serveur de réception le retient par une liste grise, une limitation de débit ou un « try again later ». Cela se traduit par des événements **deferred** avec un compteur `attempt` croissant et une `response` 4.x.x. La plateforme réessaie selon un calendrier. SendGrid retente les messages reportés pendant **72 heures** au maximum, puis transforme le message en rebond.

Des reports persistants concentrés chez un seul fournisseur signifient que vous dépassez ce que ce fournisseur accepte en débit ou en volume. Le remède est d'adapter le trafic à ce serveur de réception (réduire la concurrence ou le débit, étaler l'envoi sur davantage d'heures), et non de multiplier les tentatives. Voir [Réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta) et [Liste grise (RFC 6647)](https://emailmarketing.net/learn/rfc/rfc6647-greylisting).

**2. Retard sur la plateforme ou à l'injection (bloqué en Processing).** Le message n'atteint jamais un serveur de réception ; il reste à l'état **processed**. SendGrid documente plusieurs causes :

- **Une limite de volume sur une nouvelle adresse IP dédiée.** Un plafond de volume s'applique pendant les **3 premiers jours** sur une nouvelle adresse IP dédiée, pour prévenir les abus. Augmentez le volume progressivement avec le processus de [chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip).
- **Une mise en attente pour conformité.** Pour un compte en cours d'examen, ou sur lequel une activité inhabituelle a été détectée, l'envoi est suspendu jusqu'à confirmation par l'équipe Compliance.
- **Un engorgement de la file d'attente du MTA.** Un volume d'envoi très élevé peut accumuler les messages dans la file d'attente du MTA sortant. Mettez l'envoi en pause ou mettez une autre adresse IP en service.
- **La suspension d'un compte dormant.** Les comptes sans aucune connexion sont suspendus automatiquement.

Les messages restent en attente pendant **72 heures** au maximum. Si le problème sous-jacent n'est pas résolu d'ici là, ils deviennent des **rebonds définitifs**.

**3. Latence de transport (intégration et réseau).** Le message arrive lentement dans la plateforme. Les recommandations de SendGrid portent sur le débit et le chemin réseau :

- Utilisez les bibliothèques clientes officielles (C#, PHP, Ruby, Node.js, Python, Go, Java) plutôt que du code écrit de zéro.
- Débit SMTP : jusqu'à **5000 messages par connexion**, et jusqu'à **1000 destinataires `To:` par message** (par l'en-tête `x-smtpapi`).
- Ouvrez davantage de connexions simultanées, jusqu'à un **maximum recommandé d'environ 10 connexions simultanées**.
- Diagnostic réseau : `hping` et `Test-NetConnection` mesurent le temps de réponse et le TTL, et **tout ce qui dépasse environ 150 ms** de temps de réponse est un premier signal d'alerte. Le mode traceroute montre la latence de chaque saut ; surveillez les hausses brusques d'un saut à l'autre. Les analyseurs d'en-têtes (comme celui de Google) montrent le trajet du message à travers chaque MTA et le temps passé à chaque saut. Wireshark capture la conversation SMTP pour une inspection approfondie.

Diagnostiquez dans cet ordre. Vérifiez d'abord l'état `event`. **processed** indique un problème de plateforme ou de conformité ; **deferred** indique une limitation de débit par le serveur de réception ; **delivered sans engagement** indique le dossier spam, qui est un problème de placement et non de retard. N'utilisez les outils de latence de transport qu'une fois confirmé que le message quitte normalement la plateforme.

## Score de qualité de l'engagement

Le niveau d'agrégation le plus élevé transforme tout le flux d'événements en un seul score de santé. L'**API Engagement Quality (SEQ)** de SendGrid en est l'exemple de référence. Elle renvoie un score de **1 à 5**, où un score plus élevé signifie un meilleur engagement et une meilleure délivrabilité. Le score permet à un opérateur de classer les expéditeurs et les sous-utilisateurs à grande échelle, et de repérer une dégradation avant qu'elle ne devienne un incident de réputation.

Un score n'est généré qu'avec le **suivi des ouvertures activé** et **≥ 1 000 messages envoyés au cours des 30 derniers jours**. Les scores sont conservés **90 jours** au maximum. Les points de terminaison renvoient les scores du compte et de chaque sous-utilisateur.

Le score combine cinq composantes pondérées, qui sont les signaux d'événements décrits plus haut, condensés :

| Composante | Ce qu'elle mesure |
|---|---|
| **Engagement Recency** | Le % d'adresses uniques destinataires au cours des **30 derniers jours** qui ont aussi interagi (ouverture ou clic) au cours des **90 derniers jours** |
| **Unique Open Rate** | Le taux le plus bas sur les **7 et 30 derniers jours** chez les **5 principaux fournisseurs de messagerie**, hors ouvertures par les machines d'Apple et messages non livrés |
| **Bounce Rate** | Le % de rebonds permanents sur les 7 et 30 derniers jours, en retenant le **plus élevé** (le pire) des deux |
| **Bounce Classification** | Donne du poids aux rebonds classés **Reputation** ou **Content**, les catégories où le serveur de réception vous juge |
| **Spam Rate** | Les plaintes pour spam récentes sur une fenêtre de **7 jours** |

Cette conception montre ce qu'une plateforme considère réellement comme de la qualité : un engagement récent (écrivez-vous à des personnes qui veulent encore vos messages ?), de vraies ouvertures plutôt que des ouvertures par des machines chez les fournisseurs qui comptent, des rebonds permanents qui évoluent dans le mauvais sens, les rebonds de réputation et de contenu en particulier, et les plaintes. Un ESP peut utiliser ces scores pour répartir les sous-utilisateurs en [pools d'adresses IP](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture), signaler les expéditeurs peu performants à la [surveillance des envois sortants](https://emailmarketing.net/learn/esp-operations/outbound-monitoring), et décider quand faire passer des expéditeurs d'une infrastructure partagée à une infrastructure dédiée, ou l'inverse.

## Voir aussi

- [Procédures de dépannage de la livraison](https://emailmarketing.net/fr/apprendre/operations/procedures-de-depannage-de-la-livraison)
- [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite)
- [Codes d'état étendus (RFC 3463)](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp), pour lire le champ `status`
- [Notifications d'état de livraison (RFC 3464)](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison), le format des rebonds asynchrones
- [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure), sur les raisons pour lesquelles les ouvertures et les clics induisent en erreur
- [Réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta)
- [Feedback loops de plaintes (RFC 6449)](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes)
- [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation)

# Hygiène de base de données et politiques de mise en sommeil

> Comment acquérir des adresses sans risque, les valider à l'inscription, gérer au quotidien les rebonds et les plaintes, et mettre en sommeil les destinataires inactifs avant qu'ils ne nuisent à la réputation.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil

Les adresses de votre liste déterminent les indicateurs sur lesquels les fournisseurs de messagerie vous notent (voir [Indicateurs et valeurs de référence](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite)). Garder ces indicateurs sains suppose de gérer chaque adresse tout au long de sa vie : comment vous l'acquérez, comment vous la validez à l'inscription, comment vous traitez ses rebonds et ses plaintes, et quand vous cessez de lui écrire parce qu'elle n'interagit plus (mise en sommeil).

## Acquisition : à faire et à éviter

**Ne louez, n'achetez et ne collectez jamais de listes d'adresses email.** Les guides des trois ESP s'accordent sur ce point, pour des raisons concrètes :

- Les listes achetées contiennent un grand nombre d'adresses invalides, qui font grimper en flèche les taux de rebonds définitifs (AWS SES).
- Elles contiennent des **adresses pièges** : des adresses placées précisément pour attraper les expéditeurs illégitimes. Tomber sur l'une d'elles peut nuire aux taux de livraison et à la réputation de façon « irrévocable » (AWS SES).
- La collecte d'adresses (des robots qui parcourent des sites web à la recherche d'adresses) est particulièrement risquée, car aucun des destinataires n'a donné son accord (SendGrid).

Développez plutôt votre liste de façon légitime. Donnez aux gens des occasions de fournir leur adresse volontairement : des pages d'atterrissage qui expliquent ce qu'apporte le programme d'emails, des publicités display qui mènent à un opt-in, et un consentement explicite et documenté avant tout envoi (SendGrid).

## Validation à l'inscription

| Pratique | Détail | Source |
|---|---|---|
| Double opt-in | Envoyez un lien de confirmation à l'inscription, et n'envoyez **rien** à l'adresse tant qu'il n'a pas été cliqué. Cela élimine les rebonds définitifs dus aux fautes de frappe et prouve l'intention. | AWS SES, SendGrid |
| Validation syntaxique et MX | À l'envoi du formulaire, vérifiez que l'adresse est bien formée (`recipient@example.com`) et que le domaine a des enregistrements MX valides. | AWS SES |
| CAPTCHA sur les formulaires d'inscription | Empêche les robots de s'inscrire et d'empoisonner la liste. | SendGrid |
| Détection des fautes de frappe et des adresses jetables | Validez les adresses à l'inscription pour repérer les domaines jetables et suggérer une correction des fautes de frappe courantes (par exemple, via une API de validation). | SendGrid |
| Refus des adresses de rôle et des alias de surveillance | Les adresses comme `postmaster@`, `abuse@` et `noc@` ne s'inscrivent presque jamais volontairement. Elles peuvent être ajoutées par malveillance, pour saboter l'expéditeur, et sont traditionnellement réservées aux personnes qui surveillent les abus. | AWS SES |
| Contrôle du contenu généré par les utilisateurs | Les inscriptions sur les forums et les envois de formulaires peuvent être remplis de contenu de spammeurs. Ne mettez jamais de saisies utilisateur dans les emails sortants sans les vérifier. | AWS SES |
| Validation par l'email de bienvenue | Envoyez un email de bienvenue à chaque nouvelle adresse, et retirez automatiquement les adresses dont l'email de bienvenue rebondit. | SendGrid |

Un message de bienvenue permet aussi de fixer les attentes. Les destinataires qui comprennent pourquoi ils reçoivent des messages se plaignent moins (voir [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)).

## Adresses pièges

Il en existe deux catégories (SendGrid) :

- **Pièges vierges (pots de miel)** : des adresses qui ne se sont jamais inscrites à quoi que ce soit, placées par les fournisseurs de messagerie et les organisations antispam. On ne peut les obtenir que par des listes achetées ou collectées.
- **Pièges recyclés** : de vraies adresses abandonnées par leurs propriétaires, puis transformées en pièges. Après environ **12 mois** d'inactivité, une adresse abandonnée est soit complètement désactivée (elle produit alors des rebonds définitifs), soit transformée en adresse piège.

Les pièges recyclés expliquent pourquoi une politique de mise en sommeil fondée sur l'engagement est nécessaire, même pour les listes entièrement fondées sur le consentement. Une adresse qui a cessé d'interagir il y a un an est peut-être devenue un piège.

## Gestion des rebonds

Ces règles proviennent d'AWS SES et de Postmark :

- **Retirez immédiatement les rebonds définitifs.** Ne renvoyez jamais de message à une adresse en rebond définitif. Les rebonds définitifs répétés s'accumulent et nuisent à votre réputation auprès du fournisseur de messagerie concerné. Pour les systèmes transactionnels, la pratique de Postmark consiste à suspendre automatiquement la livraison vers l'adresse, et à exiger que quelqu'un la réactive une fois le problème de fond corrigé.
- **Retentez les rebonds temporaires, puis traitez-les comme définitifs.** Les systèmes d'envoi retentent les rebonds temporaires à intervalles pendant les jours qui suivent. Si une adresse produit des rebonds temporaires à répétition d'un envoi à l'autre, traitez-la comme un rebond définitif et placez-la en liste de suppression.
- **Une boîte pleine est généralement permanente en pratique.** Selon SendGrid, seulement **8,5 %** environ des adresses dont la boîte est pleine redeviennent actives dans les 30 jours. Suivez les réponses « boîte pleine » répétées, et placez en liste de suppression les adresses qui présentent ce profil de façon constante.
- **Assurez-vous de recevoir vos notifications de rebond.** L'adresse qui collecte les notifications de rebonds et de plaintes doit elle-même accepter les messages. Évitez d'utiliser pour cela une boîte hébergée chez un fournisseur de messagerie, car un afflux de notifications de rebond peut être classé en spam ou supprimé. Si vous ne pouvez pas l'éviter, surveillez le dossier spam, et ne marquez jamais les messages de rebond comme spam (AWS SES).
- **Rendez les rebonds traçables.** Un rebond identifie la boîte qui a refusé le message. Pour le rattacher à une campagne, ajoutez un en-tête X- dont la valeur peut être retrouvée par votre système de suivi interne (AWS SES).

### Tactiques opérationnelles pour les rebonds transactionnels (Postmark)

Pour les emails de produit ou transactionnels, un rebond signifie souvent un utilisateur que vous ne pouvez pas joindre. C'est un problème de produit, pas seulement un problème de liste :

1. Arrêtez la livraison vers l'adresse immédiatement après un rebond définitif ou une plainte pour spam (pour protéger la réputation)
2. Alertez automatiquement l'équipe support pour qu'elle enquête
3. Affichez une notification dans l'application à l'utilisateur concerné lors de sa connexion (« nous n'arrivons pas à joindre votre adresse email »)
4. Consignez l'événement de rebond dans le compte
5. Laissez l'utilisateur réactiver lui-même la livraison après avoir corrigé son adresse
6. Utilisez d'autres canaux (SMS, adresse email secondaire) lorsqu'ils sont disponibles
7. Prévenez les administrateurs et les collaborateurs du compte lorsque l'email d'un utilisateur important rebondit
8. Si vous le souhaitez, affichez les réponses automatiques (messages d'absence) là où des personnes travaillent ensemble
9. Traitez les webhooks de rebond dans le code de l'application plutôt que par interrogation périodique
10. Utilisez un environnement de test isolé (sandbox), pour que les envois de test n'atteignent jamais de vrais destinataires

## Gestion des plaintes

- Maintenez le taux de plaintes sous **0,1 %** (voir [Indicateurs et valeurs de référence](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite) pour le tableau complet des seuils).
- Lorsqu'un destinataire se plaint d'un email **marketing**, cessez immédiatement de lui envoyer des emails marketing. Si le programme envoie aussi des messages **transactionnels ou de notification**, il peut être acceptable de continuer à lui envoyer ces types de messages (AWS SES).
- Les notifications de plaintes issues des feedback loops masquent généralement l'adresse de la personne qui s'est plainte. Ajoutez des en-têtes X- personnalisés ou des identifiants dans le corps du message, pour pouvoir identifier l'adresse et la placer en liste de suppression (AWS SES).
- Vérifiez que vos propres systèmes ne filtrent pas les notifications de plaintes comme spam.

## Désabonnement et gestion des préférences

- Le désabonnement en un clic (`List-Unsubscribe` selon la RFC 8058) est exigé par les règles de Google et de Yahoo pour les expéditeurs de gros volumes, et c'est une exigence de base de CAN-SPAM (SendGrid).
- Placez un lien de désabonnement clair dans le pied de page. Lorsque se désabonner est difficile, les gens se plaignent à la place.
- Proposez un **centre de préférences** avec un réglage de la fréquence et une option pour « réduire l'abonnement » (moins d'emails plutôt qu'aucun). Il conserve l'abonné tout en réduisant les signaux négatifs (SendGrid).

## Politiques de mise en sommeil

Une **politique de mise en sommeil** (*sunset policy*) « réduit la fréquence à laquelle une adresse email reçoit des campagnes, ou la place entièrement en liste de suppression, en fonction de son engagement ou de son absence d'engagement » (SendGrid). Les adresses qui n'interagissent pas font baisser les taux d'engagement, et après environ 12 mois sans activité, elles peuvent devenir des rebonds définitifs ou des pièges recyclés.

Un processus de mise en sommeil complet, qui combine les sources :

1. **Définissez l'inactivité** selon la date de la dernière ouverture ou du dernier clic. Gardez à l'esprit que le suivi des ouvertures est gonflé, donc donnez plus de poids aux clics (voir [Indicateurs et valeurs de référence](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite)).
2. **Réduisez d'abord la fréquence** pour les segments qui se refroidissent, plutôt que de cesser de leur écrire.
3. **Vérifiez le statut de l'adresse par d'autres canaux** lorsque c'est possible, comme les connexions au site web ou l'historique d'achats, avant d'écrire à une adresse inactive depuis longtemps (AWS SES).
4. **Lancez une campagne de réengagement** en dernière étape : un message qui indique que vous n'avez pas eu de nouvelles du destinataire et lui demande de confirmer qu'il souhaite toujours recevoir vos messages. AWS parle d'une campagne de *win-back*, et SendGrid d'une *re-engagement campaign*, « une dernière chance ».
5. **Retirez les personnes qui ne répondent pas.** Après la campagne de reconquête, retirez tous les destinataires qui n'ont pas répondu (AWS SES).
6. Si vous écrivez à une liste restée longtemps sans contact, envoyez d'abord un message de type bienvenue, qui rappelle aux destinataires qui vous êtes et pourquoi ils reçoivent vos messages. Cela réduit les plaintes (AWS SES).

Envoyer moins souvent, à des destinataires moins nombreux et de meilleure qualité, améliore généralement la livraison en boîte de réception (voir [Deux mondes de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email)).

## Voir aussi

- [Indicateurs et valeurs de référence](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite), les seuils que l'hygiène de base de données protège
- [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi), notamment les feedback loops qui alimentent la liste de suppression

# Indicateurs et valeurs de référence de la délivrabilité

> Définitions concrètes des indicateurs de rebonds, de plaintes et d'engagement, avec les seuils chiffrés que les grands guides d'ESP jugent sains, et les mesures correctives quand un indicateur sort de la plage.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite

Pour savoir si vos envois sont en bonne santé, vous devez suivre les mêmes signaux que ceux dont les fournisseurs de messagerie se servent pour décider si vos messages sont désirés et attendus (voir [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)). Voici les définitions de ces indicateurs et les objectifs chiffrés publiés par les grands guides d'ESP : AWS SES, Postmark, Twilio SendGrid et Klaviyo, avec les fourchettes de taux d'ouverture de Braze et de Bird. Quand les sources diffèrent, chaque chiffre est donné avec son origine.

Le [tableau de référence des seuils](#canonical-threshold-table) ci-dessous rassemble les seuils en un seul endroit. Pour des chiffres d'enquêtes sectorielles datés auxquels comparer ces objectifs, voir [Valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/reference/valeurs-de-reference-chiffrees-de-la-delivrabilite). Cet article couvre les taux de boîte de réception, de spam et de messages manquants mesurés par Validity sur liste de test, par fournisseur et par secteur, ainsi que des valeurs de référence d'engagement pour chaque secteur, toutes attribuées à leurs éditeurs.

## Événements du cycle de vie d'un message

Twilio SendGrid recense neuf événements principaux dans le cycle de vie d'un message. Ces noms sont des libellés de son interface, mais toute infrastructure d'envoi produit des états équivalents :

| Événement | Définition |
|---|---|
| Traité (*Processed*) | Message reçu par le système d'envoi et mis en file d'attente pour livraison |
| Écarté (*Dropped*) | Pas envoyé du tout (par exemple, l'adresse est sur une liste de suppression ou a déjà fait l'objet d'un rebond, ou le contenu a été signalé comme spam) |
| Différé (*Deferred*) | Refus temporaire du serveur de réception ; la livraison est retentée (SendGrid retente pendant 72 heures au plus) |
| Rebond (*Bounce*) | Le serveur de réception a rejeté le message ; indique souvent des adresses invalides ou obsolètes |
| Livré (*Delivered*) | Accepté par le serveur de réception. Cela ne signifie **pas** une arrivée en boîte de réception : le message peut encore être classé en spam |
| Ouverture (*Open*) | Le destinataire (ou un proxy, voir ci-dessous) a affiché le message |
| Clic (*Click*) | Le destinataire a cliqué sur un lien de suivi |
| Signalement de spam (*Spam report*) | Le destinataire a marqué le message comme spam (une plainte) |
| Désabonnement (*Unsubscribe*) | Le destinataire a cliqué sur un lien de désabonnement |

## Rebonds

Un **rebond** se produit quand un email ne peut pas être livré au destinataire prévu.

- **Rebond définitif** : un échec permanent. L'adresse ou le domaine n'existe pas, l'authentification échoue (défaut d'alignement SPF, DKIM ou DMARC), ou il existe de graves problèmes de réputation ou de liste de blocage. Les codes de réponse SMTP sont dans la plage **5.X.X** (par exemple 550).
- **Rebond temporaire** : un échec temporaire. La boîte est pleine, le serveur de réception est surchargé ou momentanément indisponible, ou un blocage temporaire lié au contenu ou à la réputation s'applique. Les codes de réponse SMTP sont dans la plage **4.X.X** (par exemple 421, 451, 452). Les systèmes d'envoi retentent généralement les rebonds temporaires à intervalles réguliers pendant plusieurs jours avant d'abandonner.

(Le code 250 signifie que le message a été accepté et que la livraison est terminée.)

Un taux de rebonds définitifs élevé indique aux serveurs de réception que vous ne connaissez pas vos destinataires, ce qui est un signal de réputation très négatif. Retirez immédiatement les adresses en rebond définitif et ne leur envoyez plus jamais rien ; voir [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil).

### Répartition des rebonds (emails transactionnels)

Les données de rebonds transactionnels de Postmark se répartissent ainsi : **80 %** de rebonds définitifs, **10 %** de rebonds temporaires, **3,5 %** de plaintes pour spam et de blocages par les fournisseurs de messagerie, **2,5 %** de retards, **2,5 %** de réponses automatiques, et **1,5 %** d'autres cas (erreurs DNS, rejets DMARC, vérifications par défi, désabonnements). Automatisez d'abord le traitement des rebonds définitifs.

## Plaintes

Une **plainte** se produit quand un destinataire clique sur « Signaler comme spam » (*Mark as Spam*, ou l'équivalent) dans son client de messagerie. Certains fournisseurs de messagerie, mais pas tous, transmettent les plaintes aux expéditeurs par une **feedback loop** (voir [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi)). Les plaintes accumulées indiquent au fournisseur que vous envoyez du spam, ce qui nuit directement à la délivrabilité et à la réputation d'expéditeur.

## Ouvertures et clics : précautions de mesure

Les taux d'ouverture sont gonflés par **Apple Mail Privacy Protection (MPP)** et par le préchargement des images de Gmail, qui chargent le pixel d'ouverture sans qu'une personne lise le message. La recommandation de SendGrid est de repérer les ouvertures par proxy (par exemple, grâce aux agents utilisateurs de préchargement dans les données d'événements) et de **privilégier les indicateurs de clics et de conversions plutôt que le taux d'ouverture** pour juger de l'engagement.

<a id="canonical-threshold-table"></a>

## Tableau de référence des seuils

Les seuils ci-dessous sont rassemblés à partir de plusieurs sources, afin que les autres recommandations puissent renvoyer à un seul ensemble de chiffres. Quand les sources divergent réellement, la fourchette est donnée avec son origine, et un chiffre « maison » plus strict d'un éditeur est présenté comme tel, et non comme un consensus.

<a id="reading-thresholds-by-scope-read-this-first"></a>

### Lire les seuils selon leur portée

Lisez cette partie en premier. Les chiffres ci-dessous se contredisent en partie parce qu'**ils ne mesurent pas la même chose.** Un taux dépend de trois éléments, et deux seuils ne sont comparables que si les trois concordent :

- **Qui le mesure** : le fournisseur de messagerie (Gmail ou Yahoo, qui mesurent ce que font leurs utilisateurs), ou le côté expéditeur (votre ESP ou votre MTA, qui mesurent ce que voient vos journaux et vos feedback loops). Un fournisseur ne voit que les plaintes déposées par ses propres utilisateurs. Un expéditeur ne voit que les rebonds et les plaintes que renvoient les feedback loops (FBL).
- **L'entité de réputation (réseau, adresse IP ou domaine)** : la réputation est suivie aux trois niveaux à la fois. Les listes de blocage répertorient séparément les **adresses IP** (Spamhaus SBL et CSS) et les **domaines** (DBL). Gmail Postmaster Tools présente la **réputation des adresses IP** et la **réputation des domaines** dans des tableaux de bord distincts. AWS SES applique ses sanctions au niveau du **compte** pour protéger le **réseau** de ses IP partagées.
- **Le dénominateur** : les plaintes ou les rebonds divisés par les messages **envoyés**, par les messages **livrés** ou par les messages **livrés en boîte de réception**. Le taux de spam de Gmail correspond aux signalements des utilisateurs divisés par les messages livrés en boîte de réception, en ne comptant que les messages authentifiés par DKIM, si bien qu'un chiffre Gmail bas peut masquer des messages que Gmail a déjà envoyés dans le dossier spam. SES et Klaviyo divisent par les messages livrés. Les événements bruts sont les mêmes, mais le pourcentage diffère.

| Portée | Ce que c'est | Qui la mesure | Exemple de seuil |
|---|---|---|---|
| **Réseau ou pool partagé** | réputation globale de l'espace d'IP partagées d'un ESP | infrastructure d'envoi (AWS SES, par **compte**) | pause SES à 0,5 % de taux de plaintes ou à 10 % de taux de rebonds |
| **Adresse IP** | réputation d'une seule IP d'envoi | listes de blocage ; tableaux de bord de réputation des adresses IP des fournisseurs | inscription Spamhaus ; tableau de bord de réputation des adresses IP de Gmail |
| **Domaine d'expéditeur** | réputation du domaine From ou DKIM que voit le destinataire | fournisseur de messagerie (Gmail ou Yahoo, par **domaine**) | Gmail : objectif de 0,1 % et plafond de 0,3 % (divisés par les messages livrés en boîte de réception) |

**La ligne sur laquelle vous agissez dépend de votre rôle :**

- **Expéditeur (vous possédez le domaine) :** le plafond du fournisseur de messagerie pour chaque **domaine** détermine votre placement en boîte de réception. Maintenez le taux de plaintes chez Gmail et Yahoo sous **0,1 %**, et ne le laissez jamais approcher **0,3 %**. Les chiffres du tableau de bord de votre ESP sont une alerte précoce, pas l'objectif.
- **Opérateur d'ESP (plateforme partagée) :** un seul chiffre ne peut pas protéger toutes les portées, il vous faut donc **trois** garde-fous : (1) un garde-fou pour le **réseau ou le pool**, qui protège la réputation des adresses IP partagées (la ligne par compte à la manière de SES) ; (2) un garde-fou pour chaque **domaine**, afin que chaque client reste sous le plafond de Gmail et de Yahoo ; et (3) un garde-fou plus serré pour chaque **client ou adresse IP**, qui repère un mauvais expéditeur avant que l'un des deux autres ne se déclenche (bien en dessous de 0,3 %, près de 0,1 % ou de votre propre ligne maison). Voir [Sanctions appliquées aux comptes](https://emailmarketing.net/learn/esp-operations/account-enforcement), [Surveillance des envois sortants](https://emailmarketing.net/learn/esp-operations/outbound-monitoring) et [Architecture multiclient](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture).
- **Conformité :** un taux de plaintes en hausse signale un problème de **qualité du consentement** avant de signaler un problème de délivrabilité. Des plaintes durablement au-dessus d'environ 0,1 % révèlent un problème de permission ou d'attentes, et non un problème technique (voir [Méthodes de consentement et échelle de qualité des listes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement)).

### Taux de plaintes (spam)

| Ligne | Valeur | Portée et mesure | Dénominateur |
|---|---|---|---|
| Objectif sain faisant consensus | **< 0,1 %** (≤ 1 pour 1 000) | côté expéditeur, par compte ou par liste : AWS SES, Postmark, SendGrid | messages livrés |
| Chiffre maison de Klaviyo (plus strict) | **< 0,01 %** (≤ 1 pour 10 000) | côté expéditeur, par compte ou par liste : Klaviyo (volontairement prudent, pas un consensus) | messages livrés |
| « Élevé » en pratique | même **0,08 %** peut être élevé | côté expéditeur : SendGrid | messages livrés |
| **Plafond d'infraction de Gmail et Yahoo** | **0,3 %**, qui ne doit jamais être atteint | **fournisseur de messagerie, par domaine d'expéditeur** : les règles de Google et de Yahoo de février 2024 pour les expéditeurs de gros volumes | **messages livrés en boîte de réception** (Gmail : messages authentifiés par DKIM livrés en boîte de réception) |
| Sanctions SES (réseau ou pool) | examen à **0,1 %**, pause à **0,5 %** | **infrastructure, par compte AWS**. Protège le réseau des IP partagées et n'est pas un objectif qui garantit la délivrabilité ; voir [Sanctions appliquées aux comptes](https://emailmarketing.net/learn/esp-operations/account-enforcement) | messages livrés |

**Ces lignes ne sont pas directement comparables.** Le fournisseur mesure le plafond de **0,3 %** de Gmail et de Yahoo par rapport aux messages livrés en boîte de réception pour chaque domaine, tandis que les chiffres côté expéditeur et ceux de SES sont mesurés par rapport aux messages livrés, à l'échelle d'un compte ou d'un pool. Comme le dénominateur de Gmail exclut les messages déjà envoyés dans le dossier spam, **le tableau de bord de votre ESP peut afficher 0,1 % des messages livrés alors que votre taux de spam chez Gmail est déjà proche de la limite de 0,3 %**. En pratique, les expéditeurs devraient viser l'objectif du fournisseur de **< 0,1 %** pour chaque domaine. Les opérateurs d'ESP devraient placer leurs propres seuils de pause automatique, pour les pools et les clients, sous le plafond de 0,3 % (près de 0,1 %), et jamais au niveau de la ligne réseau plus lâche de SES à 0,5 %.

### Taux de rebonds

| Ligne | Valeur | Source et signification |
|---|---|---|
| Chiffre maison de Klaviyo (idéal visé) | total des rebonds **< 1,0 %** | Klaviyo, plus strict que le consensus |
| Sain pendant la chauffe | **< 2 %** | Postmark (guide de chauffe de domaine) |
| Plafond de fonctionnement | maintenir le taux de rebonds définitifs **sous 5 %** | AWS SES (« objectif raisonnable et atteignable, mais pas une règle universelle chez tous les fournisseurs de messagerie ») ; Postmark (pour l'ensemble du domaine) |
| Plafond absolu | **ne jamais dépasser 10 %** | Postmark : enquêter immédiatement à ce taux ou au-delà |
| Sanctions SES | rebonds définitifs en examen à **5 %**, pause possible du compte à **10 %** | AWS SES (par **compte**, à la portée du réseau ou du pool) ; voir [Sanctions appliquées aux comptes](https://emailmarketing.net/learn/esp-operations/account-enforcement) |

**Note sur la portée :** le taux de rebonds est par nature un indicateur **côté expéditeur**. Aucun fournisseur de messagerie ne publie de plafond de rebonds, parce que les rebonds sont ce qu'observe votre MTA, et non ce que font les destinataires. Toutes les lignes ci-dessus sont donc mesurées par l'expéditeur. Elles diffèrent par l'entité à laquelle elles s'appliquent : Klaviyo et Postmark donnent des lignes de qualité pour chaque **liste** ou domaine, tandis que SES sanctionne pour chaque **compte** afin de protéger le **réseau** de ses IP partagées. Elles diffèrent aussi par le dénominateur : les rebonds définitifs divisés par les messages envoyés, ou le total des rebonds divisé par les messages livrés. Le taux de plaintes ci-dessus est différent, car son plafond contraignant est fixé par le fournisseur de messagerie pour chaque domaine.

### Taux d'ouverture (depuis MPP)

Depuis Apple Mail Privacy Protection, un taux d'ouverture brut est en réalité un taux de chargement du pixel, gonflé par les ouvertures automatiques (voir [Mécanique du suivi des ouvertures et des clics](https://emailmarketing.net/fr/apprendre/operations/fonctionnement-du-suivi-des-ouvertures-et-des-clics) et [Suivi et distorsion des mesures](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure)). Lisez chaque valeur de référence d'ouverture en vérifiant si elle **inclut les ouvertures automatiques** (chargements bruts du pixel, gonflés par MPP) ou **les exclut** (ouvertures « humaines », sans les préchargements ni les robots) :

| Base | Sain | Alerte dossier spam | Source |
|---|---|---|---|
| Ouvertures automatiques incluses (brut) | **≥ 33 %** | Non indiqué | Klaviyo |
| Ouvertures automatiques exclues (humaines, sans préchargement) | **> 25 %** (Braze) ou **> 35 %** (Bird) indique un placement en boîte de réception généralisé | **< 20 %** laisse supposer un placement dans le dossier spam | Braze, Bird ; voir [Mécanique du suivi des ouvertures et des clics](https://emailmarketing.net/fr/apprendre/operations/fonctionnement-du-suivi-des-ouvertures-et-des-clics#opens-as-a-deliverability-signal--the-honest-reading) |

L'ancienne fourchette de GreenArrow, « 5 % à 20 % et plus pour les bons expéditeurs », est antérieure à MPP et dépassée comme valeur de référence pour les ouvertures brutes (voir [Les deux mondes](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email)). Ne l'utilisez pas pour juger une liste moderne comptant de nombreux utilisateurs Apple. Quel que soit le chiffre, jugez l'engagement de l'**audience** sur les clics et les conversions, pas sur les ouvertures, et n'utilisez la tendance du taux d'ouverture que comme un signal de placement approximatif.

## Déclencheurs de mesures correctives

Le guide de chauffe de domaine de Postmark associe chaque dépassement d'indicateur à un changement concret de volume. Ces associations sont utiles pendant toute montée en charge (voir aussi [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)) :

| Déclencheur | Action |
|---|---|
| Taux de rebonds supérieur à 3 % | Réduire le volume de 40 à 50 % |
| Taux d'ouverture inférieur à 10 % | Réduire le volume de 25 à 30 % et se recentrer sur les abonnés engagés |
| Plaintes pour spam supérieures à 0,1 % | Identifier immédiatement les segments concernés et les mettre en pause |
| Limitation de débit ou reports de remise d'un fournisseur | Réduire le volume quotidien de 20 à 30 % ou étaler les envois sur davantage d'heures |
| Inscription sur une liste de blocage majeure | Arrêter immédiatement les envois ; obtenir le retrait de liste ; reprendre à un volume nettement réduit |

Le même guide fixe une règle générale : n'augmentez **jamais** le volume avant d'avoir examiné les performances **pour chaque fournisseur de réception**. Si l'engagement et les taux de rebonds semblent normaux, l'augmentation du lendemain est probablement sans risque.

## La qualité du contenu comme donnée d'entrée

Au-delà des taux comportementaux, les serveurs de réception font passer chaque message par des **filtres de contenu**. AWS SES donne ces recommandations pour rester du bon côté :

- Les filtres de contenu modernes s'adaptent en continu et n'appliquent pas un jeu de règles figé. Des services tiers de test sur liste de test et de test de contenu peuvent repérer le contenu qui déclenche les filtres avant l'envoi.
- Vérifiez chaque URL du message dans des listes de blocage fondées sur le DNS (DNSBL) comme URIBL.com et SURBL.org.
- **Évitez les raccourcisseurs de liens.** Quand des spammeurs détournent un service de raccourcissement et qu'il est placé sur liste de blocage, tous les messages qui l'utilisent pour leurs liens sont filtrés.
- Vérifiez que chaque lien pointe vers la destination voulue.
- Dans chaque email, mettez des liens vers des pages de politique de confidentialité et de conditions d'utilisation à jour.
- Pour le contenu que vous envoyez souvent (par exemple des offres quotidiennes), variez le contenu de chaque envoi. Un contenu identique et répétitif passe pour du spam.

Postmark ajoute trois recommandations : évitez les URL raccourcies (surtout bit.ly), limitez les mises en page chargées d'images, et incluez toujours une version texte brut en plus de la partie HTML. D'infimes changements peuvent déclencher le filtrage du contenu. Dans un cas rapporté par Postmark, l'ajout d'un numéro de téléphone dans un modèle a déclenché le filtrage anti-spam de Gmail. Quand le placement chute après une modification de modèle, annulez les changements un par un pour isoler la cause.

## Voir aussi

- [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil), sur ce qu'il faut faire des adresses qui se cachent derrière de mauvais indicateurs
- [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi), sur les feedback loops et les outils de surveillance de la réputation
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)

# Le DNS inverse en IPv6 (RFC 8501) et l'email

> Pourquoi le provisionnement d'un PTR par adresse s'effondre à l'échelle d'IPv6, les cinq approches recensées par la RFC 8501 (avec leurs compromis) et ce que les serveurs de réception attendent du DNS inverse en IPv6.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/dns-inverse-en-ipv6

Si vous envoyez des emails en IPv6, chaque adresse d'envoi a besoin d'un DNS inverse qui concorde avec son DNS direct, alors que l'habitude héritée d'IPv4, créer à l'avance un enregistrement PTR pour chaque adresse, devient mathématiquement impossible. La RFC 8501, *Reverse DNS in IPv6 for Internet Service Providers* (novembre 2018, informative), analyse comment les opérateurs peuvent alimenter `ip6.arpa` autrement. L'email est son cas d'usage phare, car c'est dans SMTP qu'un DNS inverse absent ou incohérent bloque réellement le trafic.

## Pourquoi un PTR par adresse ne tient pas à l'échelle d'IPv6

- En IPv4, un fournisseur d'accès à Internet (FAI) qui dispose d'un /24 écrit 256 enregistrements PTR, souvent générés automatiquement, et passe à autre chose. Le DNS direct et le DNS inverse concordent, ce qui répond à l'attente de la RFC 1912 selon laquelle « chaque hôte joignable depuis Internet devrait avoir un nom » dont les entrées directe et inverse concordent.
- Un seul **/64** IPv6 (un réseau local) contient 2^64 adresses, et un **/48** de client en contient 2^80. La RFC 8501 fait le calcul : à raison de 1 000 entrées de fichier de zone écrites par seconde, remplir un seul /48 « ne serait toujours pas terminé au bout de 38 000 milliards d'années ».
- Les hôtes s'attribuent aussi eux-mêmes leurs adresses, par l'autoconfiguration d'adresse sans état (SLAAC) et par des adresses de confidentialité qui changent régulièrement. L'opérateur ne sait souvent pas quelles adresses sont utilisées, si bien que même un pré-remplissage sélectif ne peut pas suivre la réalité.

Un opérateur IPv6 doit donc choisir une autre stratégie que des enregistrements PTR statiques pour chaque adresse. Pour un fournisseur de services email (ESP), c'est aussi une question d'infrastructure d'envoi. Chaque adresse IPv6 depuis laquelle vous envoyez des emails a besoin d'un DNS inverse correct et concordant (voir plus bas ce qu'attendent les serveurs de réception), et le reste de votre espace d'adresses a besoin d'une politique délibérée.

## Le catalogue d'options de la RFC 8501

| N° | Approche | Fonctionnement | Compromis |
|---|---|---|---|
| 1 | **Réponse négative (NXDOMAIN)** | Répondre avec autorité qu'aucun PTR n'existe | Honnête quand aucun nom n'est connu, mais contraire à l'attente de concordance de la RFC 1912. Les services SSH et web peuvent rester bloqués en attendant les résolutions. **Les serveurs de messagerie peuvent refuser la connexion purement et simplement**, et la RFC note que ce refus « peut aider à lutter contre le spam » |
| 2 | **Correspondance générique (wildcard)** | Un PTR générique pour chaque préfixe client (/48, /56, /64) | Passe à l'échelle, mais la résolution directe du nom générique renvoyé ne peut pas redonner le même nom, donc le DNS inverse confirmé par le direct (FCrDNS) échoue. Inadapté aux sources d'emails |
| 3 | **DNS dynamique (DDNS)** | Les hôtes (ou la passerelle du client, ou le FAI à partir des données DHCPv6 ou RADIUS) mettent à jour les enregistrements PTR et AAAA à mesure que les adresses sont configurées | Produit de vrais enregistrements concordants. Mais ce n'est pas le réglage par défaut sur la plupart des hôtes, il n'existe aucun moyen standard de découvrir le serveur de mise à jour, il faut une authentification et une limitation de débit (exposition aux attaques par déni de service), et le rétablissement après une panne provoque des avalanches de mises à jour |
| 4 | **Génération à la volée (synthétique)** | Générer le PTR par algorithme au moment de la requête (et synthétiser le AAAA correspondant pour le nom généré) | Garantit la concordance entre direct et inverse, sans provisionnement. L'algorithme doit être identique sur tous les serveurs de la zone. Laisse moins de place aux noms d'hôtes choisis par les utilisateurs. Signer en direct les réponses synthétiques avec DNSSEC a un coût en performances |
| 5 | **Délégation au client** | Déléguer la zone inverse (par exemple, par /48) à des serveurs faisant autorité que gère le client | Adapté aux entreprises compétentes en DNS. Irréaliste pour les particuliers. En conflit avec les réglages de sécurité par défaut des équipements installés chez le client (CPE) de la RFC 6092 |

La conclusion de la RFC 8501 : « Lorsque l'attribution des adresses et le nom relèvent de la même autorité, ou lorsqu'un hôte a une adresse et un nom statiques, les enregistrements AAAA et PTR devraient exister et concorder. » Pour tout le reste, comme les pools résidentiels, les choix réalistes sont les wildcards, les réponses négatives (là où rien n'a besoin d'un PTR) ou la génération à la volée.

## Ce que les serveurs de réception attendent (FCrDNS)

- La RFC le dit sans détour : « la plupart des fournisseurs de messagerie n'acceptent pas de connexions entrantes sur le port 25 si les entrées DNS directe et inverse ne concordent pas ». C'est le **DNS inverse confirmé par le direct (FCrDNS)** : le PTR de l'adresse qui se connecte renvoie un nom, et l'enregistrement AAAA (ou A) de ce nom contient l'adresse qui se connecte.
- Seules les options 3 (DDNS), 4 (à la volée) et 5 (délégation) peuvent produire des paires concordantes. Les wildcards et NXDOMAIN ne le peuvent pas. Une source d'emails située derrière un wildcard ou une zone inverse vide sera rejetée ou lourdement pénalisée.
- Gmail est le modèle de l'application de ces règles en IPv6. Les hôtes d'envoi doivent avoir un PTR dont la résolution directe confirme l'IP, et doivent aussi réussir l'authentification, sinon les messages sont rejetés avec des erreurs `550 5.7.1` propres à IPv6 (répertoriées dans [Erreurs SMTP de Gmail et dépannage](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/depannage-gmail), avec les exigences dans [Exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs)). Les serveurs de réception appliquent en général des règles plus strictes en IPv6 qu'en IPv4, car la réputation par IP se dilue dans l'immense espace d'adresses. Voir [Envoyer des emails en IPv6](https://emailmarketing.net/fr/apprendre/operations/envoyer-des-emails-en-ipv6) pour l'ensemble de la politique d'envoi.
- Les noms PTR d'apparence générique ou synthétique (par exemple, `2-2-2-2.pool6.example.net`) signalent « pas un serveur de messagerie délibéré », si bien que les serveurs de réception utilisent aussi le nommage des enregistrements PTR comme heuristique antispam. Les recommandations du Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), citées par le NIST SP 800-177 ([synthèse](https://emailmarketing.net/learn/transport-security/nist-sp-800-177)), indiquent que les arbres inverses devraient identifier les serveurs de messagerie qui font autorité pour un domaine.

## Sécurité et confidentialité (RFC 8501 §5)

- **Des enregistrements concordants ne signifient pas la confiance.** Un attaquant qui contrôle sa propre zone inverse peut facilement faire concorder le DNS direct et le DNS inverse, et sans DNSSEC, les réponses peuvent être usurpées en transit. Considérez FCrDNS comme un minimum d'hygiène, pas comme une authentification. [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf), [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) assurent l'authentification.
- **Interactions avec DNSSEC** : les enregistrements ajoutés dynamiquement ou synthétisés compliquent la signature (le coût de la signature en direct, et l'exposition des clés sur les signataires en ligne). Les zones inverses non signées sont de plus en plus lues comme un signal de confiance réduite.
- **Confidentialité** : les noms d'hôtes qui encodent une localisation ou l'identité d'un abonné divulguent des informations (RFC 8117). Les noms d'hôtes fournis par les utilisateurs risquent de contenir des contenus offensants ou abusifs.
- **Surface d'attaque par déni de service** : les canaux de mise à jour DDNS ont besoin d'authentification et de limites de débit, et les générateurs à la volée doivent borner leur état et la taille de leur cache.

## Liste de contrôle opérationnelle pour un ESP qui exploite une infrastructure email en IPv6

1. **Chaque adresse IPv6 qui envoie du SMTP reçoit un PTR statique et descriptif qui réussit FCrDNS** (`mtaN.esp.example`, avec un enregistrement AAAA correspondant), provisionné comme un actif de production. Utilisez l'option « enregistrements statiques », jamais les wildcards.
2. Décidez de la politique pour le reste de vos allocations, la partie qui n'envoie pas d'emails. NXDOMAIN est propre et honnête. Ne laissez jamais un wildcard couvrir un espace d'adresses d'où du SMTP pourrait partir.
3. Avant le premier envoi, vérifiez que votre fournisseur amont ou votre registre Internet local (LIR) délègue `ip6.arpa` pour votre préfixe à vos serveurs de noms (généralement sur des frontières de quartet : /32, /36, ... /48, /56, /64).
4. Signez la zone inverse avec DNSSEC si vous le pouvez. C'est cohérent avec la posture d'authentification du [NIST SP 800-177](https://emailmarketing.net/learn/transport-security/nist-sp-800-177), et les serveurs de réception attentifs à la sécurité l'attendent.
5. Gardez des noms PTR cohérents avec l'identité directe que vous utilisez dans HELO et EHLO. Les serveurs de réception comparent les noms de HELO, du PTR et du certificat lorsqu'ils évaluent une connexion (voir [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi)).
6. Lorsque vous analysez un rejet soudain du type `550 5.7.1` qui cite une adresse IPv6, vérifiez d'abord FCrDNS pour cette adresse précise. La cause classique est un serveur d'application qui s'est mis à envoyer des emails en IPv6 depuis des adresses de confidentialité changeantes. Vérifiez ensuite l'alignement de l'authentification. La stratégie double pile d'ensemble est traitée dans [Envoyer des emails en IPv6](https://emailmarketing.net/fr/apprendre/operations/envoyer-des-emails-en-ipv6).

# Le fonctionnement du suivi des ouvertures et des clics

> Comment les ESP comptent réellement les ouvertures et les clics : le fonctionnement du pixel et de la réécriture des liens chez Pardot, Eloqua, Bird, Customer.io et Braze, les définitions des valeurs uniques et totales, la notion de « taux de lecture » et ce que chaque indicateur prouve ou ne prouve pas.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/fonctionnement-du-suivi-des-ouvertures-et-des-clics

Avant de vous fier à un taux d'ouverture ou à un taux de clics, il est utile de savoir comment le chiffre a été produit. Tous les indicateurs d'engagement que publie un fournisseur de services de messagerie (ESP), qu'il s'agisse du taux d'ouverture, du taux de clics, du taux de clics sur ouvertures ou du taux de lecture, découlent de deux modifications apportées au message au moment de l'envoi : un pixel de suivi et des liens réécrits.

Vous trouverez ci-dessous comment les plateformes mettent en œuvre et comptent ces événements, comment elles définissent les valeurs uniques et totales, et ce que chaque chiffre peut et ne peut pas prouver exactement. Les fonctions de confidentialité et les scanners qui faussent ces décomptes (Apple Mail Privacy Protection (MPP), Microsoft Safe Links, la détonation des liens par les passerelles de sécurité, les proxys d'images) sont traités en détail dans [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure). Les seuils qu'alimentent ces indicateurs figurent dans [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite).

## Le suivi des ouvertures : le pixel

Une ouverture est déduite, jamais observée. L'ESP place dans le corps HTML une **image transparente de 1×1** (un « pixel de suivi », une « balise » ou un « web bug »). Son URL, sur un domaine de suivi, encode l'identifiant unique du destinataire. Lorsque le client de messagerie affiche le message et charge les images distantes, la requête atteint le serveur de suivi, qui enregistre une ouverture avec l'adresse IP à l'origine de la requête, l'user-agent et l'heure.

Comme l'événement est une requête d'image, certains faits valent sur toutes les plateformes :

- **Sans chargement d'image, pas d'ouverture.** Les clients dont les images sont désactivées, les volets de lecture en texte brut et les clients texte seul produisent des faux négatifs. Un « taux d'ouverture » est en réalité un taux de chargement du pixel.
- **Tout chargement d'image compte comme une ouverture**, y compris les aperçus de l'expéditeur lui-même, une campagne transférée ou publiée sur le web, et un modèle qui réutilise un code de suivi.
- **Les parties en texte brut ne peuvent pas être suivies.** Un pixel n'existe qu'en HTML : un message affiché en texte ne produit donc aucune ouverture. C'est pourquoi Pardot appelle une ouverture détectée par le pixel une **« HTML open »** : l'ouverture en texte n'existe pas.
- **Les valeurs totales et uniques diffèrent.** Les requêtes brutes sur le pixel sont les ouvertures *totales* : un destinataire qui recharge le message compte à chaque fois. Les ESP dédoublonnent pour obtenir les ouvertures *uniques* de chaque destinataire, car ils savent quel identifiant appartient à quel abonné. Les valeurs de référence et les comparaisons entre plateformes devraient toujours utiliser le taux **unique**.

### Le repli du clic vers l'ouverture

Plusieurs plateformes enregistrent une ouverture lorsqu'un clic arrive d'un destinataire sans ouverture préalable. Le raisonnement est qu'un clic prouve que le message a été vu, même si le pixel ne s'est jamais chargé parce que les images étaient désactivées.

- **Eloqua** le dit explicitement : « si un clic se produit sans ouverture d'email enregistrée pour ce RecipientID, Oracle Eloqua enregistre automatiquement une ouverture d'email en même temps que le clic » (*If a clickthrough occurs without a recorded email open for that RecipientID, Oracle Eloqua automatically records an email open along with the clickthrough.*). Eloqua détecte donc les ouvertures de deux manières : quand le pixel se charge, et quand un clic implique une ouverture.
- **Customer.io** l'intègre à sa définition : une ouverture est comptée « lorsque le client de messagerie du destinataire charge une image invisible (pixel de suivi) **ou** lorsque le destinataire clique sur l'un des liens de l'email » (*when the recipient's email client loads an invisible image (tracking pixel) or when the recipient clicks one of the links in the email.*).

Ce repli explique pourquoi les audiences qui cliquent beaucoup mais gardent les images désactivées (une grande partie du B2B) affichent tout de même des ouvertures. Il explique aussi pourquoi, depuis MPP, un clic est le seul signal qui révèle une véritable ouverture humaine par un destinataire Apple Mail dont le pixel s'est chargé automatiquement (voir [distorsions](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure)).

## Le suivi des clics : la réécriture des liens

Le suivi des clics réécrit, au moment de l'envoi, chaque `href` du message pour le faire pointer vers le domaine de redirection de l'ESP (souvent appelé domaine de « tracking », de « click » ou de « links »), avec la destination et le destinataire encodés. Lors d'un clic, le serveur de redirection enregistre la requête et renvoie une redirection HTTP vers la véritable URL. Seule la plateforme d'envoi peut le faire, car les liens doivent être réécrits avant que le message ne parte. C'est pourquoi les outils purement analytiques ne peuvent pas proposer de suivi des clics, et pourquoi la réécriture des liens relève de l'ESP.

Pour ces raisons, les clics sont un signal plus solide que les ouvertures, mais pas un signal propre :

- **Le domaine de redirection porte une réputation.** Les listes de blocage d'URL et les filtres de contenu évaluent les domaines des liens dans le corps du message : un domaine de redirection partagé répartit donc la réputation, bonne ou mauvaise, entre tous les expéditeurs qui l'utilisent. Des noms d'hôte de suivi personnalisés pour chaque client gardent les réputations séparées. Bird sert le suivi des clics et des ouvertures depuis **un nom d'hôte de suivi personnalisé sur votre propre domaine** : un CNAME sous le domaine d'envoi (par défaut `links.yourdomain.com`), en HTTPS, par lequel il réécrit les liens visibles.
- **Les scanners gonflent les clics.** Les passerelles de sécurité (Safe Links, Proofpoint, Mimecast) font « détoner » les liens réécrits en les demandant quelques secondes après la livraison, et chaque requête est enregistrée comme un clic qu'aucune personne n'a fait. Pour les détails et les moyens de distinguer les robots des personnes, voir [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure).
- **Les valeurs uniques et totales** fonctionnent comme pour les ouvertures. Les clics totaux comptent chaque requête ; les clics uniques en comptent un par destinataire (certaines plateformes affichent aussi les clics uniques pour chaque lien).

### Le suivi doit être activé avant de fonctionner

Un message n'est pas suivi automatiquement du simple fait qu'il contient des liens. Bird ne suit un envoi que lorsque ces trois conditions sont toutes remplies :

1. l'indicateur de l'envoi (`track_opens` ou `track_clicks`, vrai par défaut) est vrai. Un `false` sur un envoi désactive toujours le suivi, quels que soient les réglages du domaine ;
2. le suivi est activé pour le domaine ;
3. le **CNAME de suivi a été vérifié** : « le suivi des clics et des ouvertures ne fonctionne qu'une fois ce CNAME vérifié ; d'ici là, rien n'est réécrit ni doté d'un pixel » (*Click and open tracking only run once that CNAME has verified; until then nothing is rewritten or pixelled.*).

Bird indique si le CNAME de suivi est prêt séparément de la capacité du domaine à envoyer (`capabilities.tracking` et `capabilities.sending`). Un domaine peut donc envoyer des messages sans enregistrer aucun engagement, et sans aucun avertissement. En pratique, quand les données d'ouverture et de clic d'un client tombent soudain à zéro, la cause est souvent un CNAME de suivi cassé ou non vérifié, et non un changement d'audience.

## Le filtrage des robots et des interactions non humaines intégré au décompte

Les scanners demandent les pixels et les liens réécrits aussi bien que les personnes. Les plateformes matures filtrent donc l'activité des machines avant qu'elle n'atteigne l'indicateur principal, au lieu de simplement publier les requêtes brutes.

- **Customer.io** montre explicitement les deux côtés. Depuis le **2025-03-20**, un indicateur **Human Opened** exclut Apple MPP, le préchargement de Gmail, les robots et les scanners. Depuis le **2025-04-20**, un indicateur **Human Clicked** exclut les scanners de sécurité, les robots, les proxys et les autres schémas non humains. Les indicateurs correspondants **Machine Opened** et **Machine Clicked** recueillent les événements automatisés exclus. Rien n'est compté deux fois : « si un même email a été ouvert à la fois par une machine et par un humain, cela compte pour un dans l'indicateur agrégé » (*if a single email was opened by both a machine and a human, that counts as one in the aggregate metric.*). Toutes les ouvertures dans Apple Mail sont comptées comme non humaines, et une ouverture n'est de nouveau comptée comme humaine que si le destinataire clique aussi : les ouvertures humaines sont donc sous-estimées.
- **Pardot (Account Engagement)** inclut **Metrics Guard** dans tous les comptes. Il détecte, à l'aide de seuils, les rafales d'ouvertures ou de clics provenant d'une même adresse IP. Les seuils sont des « moyennes prudentes des pics d'activité email sur une période donnée dans l'ensemble de l'écosystème Account Engagement » (*conservative averages of peak email activity within a certain time frame across the Account Engagement ecosystem*), et lorsqu'une adresse IP en dépasse un, « le suivi de l'activité à cet emplacement est suspendu jusqu'à ce que le niveau d'activité repasse sous le seuil » (*activity tracking on that location is paused until the activity level falls back below the threshold.*). Il filtre l'essentiel de l'activité des scanners sans bloquer les visiteurs légitimes, mais ne peut pas intercepter tous les robots : l'activité sous les seuils reste enregistrée.
- **Eloqua** stocke les ouvertures et clics automatiques des outils d'analyse des emails, et les ouvertures automatiques dues aux fonctions de confidentialité d'Apple, **séparément** de l'engagement réel des contacts, au lieu de les compter comme de l'engagement.
- **Bird** marque les ouvertures demandées par un proxy avec `is_prefetched: true`, et définit son taux d'ouverture comme les **« ouvertures uniques non préchargées rapportées aux messages livrés »** (*unique non-prefetched opens over delivered*). Les ouvertures préchargées sont retirées du taux principal, et pas seulement étiquetées.
- **Braze** propose des rapports qui « excluent ou incluent les ouvertures par des machines (comme MPP d'Apple) » (*either exclude or include machine opens (like Apple's MPP).*).

Si vous exploitez un ESP, ne comparez jamais un taux d'ouverture non filtré à un taux filtré des robots, et sachez lequel des deux affiche le tableau de bord par défaut de votre plateforme. Sur les listes qui comptent beaucoup d'utilisateurs Apple, l'écart entre « ouvertures » et « ouvertures humaines » atteint souvent 30 à 70 %.

## Ce que les plateformes nomment et exposent réellement

| Plateforme | Une ouverture est comptée quand… | Clic compté comme ouverture | Traitement des robots | Définition d'indicateur notable |
|---|---|---|---|---|
| **Pardot (Account Engagement)** | Le pixel HTML se charge (« HTML open ») ; l'ouverture en texte n'existe pas | Non documenté | Metrics Guard : des seuils de rafale pour chaque adresse IP suspendent le suivi | Publie aussi un **taux de lecture** (niveaux de temps passé sur le message, voir plus bas) |
| **Eloqua** | Le pixel se charge, *ou* un clic arrive sans ouverture préalable pour ce RecipientID | Oui, explicitement | Ouvertures automatiques des scanners et d'Apple stockées séparément de l'engagement | Par défaut, le pixel est `<img …?elq=…>` en bas du message |
| **Bird** | Un chargement de pixel qui n'a pas été préchargé | (une ouverture sur tout événement suivi) | `is_prefetched:true` exclu du taux d'ouverture | Taux d'ouverture = ouvertures uniques non préchargées ÷ messages livrés ; **les taux sont calculés sur l'heure de l'événement, pas sur l'heure de l'envoi** |
| **Customer.io** | Le pixel se charge **ou** un lien est cliqué | Oui, dans la définition | Human et Machine Opened et Clicked (2025) ; rien n'est compté deux fois | Les indicateurs prennent par défaut les messages **livrés** comme base (configurable) ; les événements sur des messages de plus de 6 mois sont ignorés |
| **Braze** | Un pixel 1×1 se charge (un indicateur indirect d'ouverture) | Non documenté | Les rapports peuvent inclure ou exclure les ouvertures par des machines | Présente le taux d'ouverture unique comme indicateur indirect du placement en boîte de réception (voir plus bas) |

Surveillez la base de chaque taux. Customer.io et Bird calculent les taux d'engagement par rapport aux messages **livrés**, et Bird attribue l'engagement à l'**heure de l'événement** : un clic aujourd'hui sur l'envoi de la semaine dernière apparaît dans les chiffres d'aujourd'hui. Deux plateformes peuvent publier des « taux d'ouverture » différents pour un comportement identique, uniquement parce qu'elles choisissent des dénominateurs et une attribution temporelle différents. Avant de comparer, vérifiez toujours le numérateur (unique ? filtré des robots ?) et le dénominateur (livrés ? envoyés ?).

## Le taux de lecture : une mesure complètement différente

Le « taux de lecture » n'est pas un indicateur fondé sur le pixel. Il mesure **pendant combien de temps un message est resté ouvert au premier plan, ou actif,** avant que le lecteur ne passe à autre chose, réparti en niveaux. Pardot distingue **supprimé (deleted, < ~2 s), parcouru (skimmed, ~2 à 8 s) et lu (read, > ~8 s)**. Les données proviennent d'une autre source que les ouvertures :

- Selon oimetrics, les taux de lecture viennent **d'un panel de boîtes de réception surveillées**. Ce sont des taux estimés, pas des mesures directes : attendez-vous donc à des écarts avec vos propres ouvertures.
- Ce sont **des taux uniques, pas des taux totaux**. Ils sont calculés en observant le moment où un abonné marque ou garde un message comme lu, et non par le chargement d'un pixel : ils **échappent donc en grande partie à l'effet d'Apple MPP**. MPP gonfle les ouvertures par pixel, mais il n'invente pas de temps de lecture.
- Leur intérêt pour la délivrabilité : « les taux de lecture utilisent la même méthodologie que les fournisseurs d'accès, comme Gmail et Outlook » (*read rates use the same methodology as ISPs, like Gmail and Outlook*), et « estiment donc plus précisément ce que calculent les fournisseurs d'accès » (*more accurately estimate what ISPs are calculating*) pour le score d'engagement. Le taux de lecture est donc plus proche que n'importe quelle ouverture par pixel du signal d'engagement que calcule le fournisseur de messagerie lui-même.
- Ne comparez le taux de lecture qu'au **taux d'ouverture unique, pas au taux d'ouverture total** ; « plus il est élevé, mieux c'est » (*higher is better*).

Le taux de lecture d'un panel estime la performance d'une liste dans son ensemble ; il ne dit rien de fiable sur un destinataire en particulier. Il sert à vérifier les ouvertures par pixel et d'indicateur indirect des calculs d'engagement du fournisseur. Un taux de lecture sain face à un taux d'ouverture qui s'effondre désigne une distorsion du pixel due à MPP, et non une vraie baisse d'engagement.

<a id="opens-as-a-deliverability-signal--the-honest-reading"></a>

## Les ouvertures comme signal de délivrabilité : la lecture honnête

Braze énonce clairement la position actuelle : un chargement de pixel est « plus susceptible d'indiquer un **placement en boîte de réception** qu'un être humain qui sélectionne réellement votre message et choisit de le lire » (*more likely to indicate inbox placement as opposed to a human being actually selecting your message and choosing to read it*). C'est la manière utile de considérer les ouvertures lorsque vous exploitez un ESP :

- **Un taux d'ouverture unique qui exclut les ouvertures par des machines et dépasse ~25 % indique un placement en boîte de réception généralisé.** En dessous de ~20 %, il suggère un placement dans le dossier spam, et une **tendance régulière à la baisse précède souvent des problèmes de délivrabilité** (Braze). Le tableau de bord de Bird qualifie de « Healthy » un taux d'ouverture supérieur à **35 %**, et de sain un taux de livraison supérieur à **95 %**. Considérez ces chiffres précis comme calibrés par chaque éditeur, et non comme universels. Ce sont des fourchettes qui **excluent les ouvertures par des machines**. Une valeur de référence sur les ouvertures brutes, qui incluent les ouvertures par des machines, comme le ≥ 33 % de Klaviyo, ne peut pas leur être comparée. Le [tableau de référence des seuils](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite#canonical-threshold-table) classe les chiffres de taux d'ouverture selon qu'ils incluent ou excluent les ouvertures par des machines.
- Les fournisseurs de messagerie jugent l'engagement sur des données que les expéditeurs **ne peuvent pas voir** : « délai avant ouverture, délai avant clic, transferts, réponses, suppressions, etc. » (*time-to-open, time-to-click, forwards, replies, deleted, etc.*) (Braze). Votre indicateur d'ouverture est une ombre grossière du vrai modèle du fournisseur, et le taux de lecture en est une ombre un peu moins grossière.
- Pour juger l'engagement d'une audience, et pour décider de la mise en sommeil et du réengagement, appuyez-vous donc sur **les clics et les conversions plutôt que sur les ouvertures**. Pour juger le placement, la tendance du taux d'ouverture agrégé reste un signal d'alerte précoce légitime : une baisse signifie que les messages n'atteignent plus la boîte de réception. En pratique, la règle est d'utiliser les ouvertures pour la direction du placement, et les clics et les conversions pour les décisions d'engagement.

### Ce que chaque indicateur dit et ne dit pas

| Indicateur | Prouve | Ne prouve **pas** |
|---|---|---|
| Livré | Le serveur MX de réception a accepté le message | Qu'il est allé en boîte de réception ou dans le dossier spam |
| Ouverture (pixel brut) | Une image a été demandée (par un client, un proxy ou un scanner) | Qu'une personne l'a vue, quand ou où, ni sur quel appareil |
| Ouverture humaine unique | Le client d'une personne a affiché les images au moins une fois | L'attention, ni que les personnes qui n'ont pas ouvert n'ont pas lu (images désactivées) |
| **Tendance** des ouvertures agrégées | Le sens de l'évolution du placement en boîte de réception | Le placement réel, ni l'intérêt d'un destinataire en particulier |
| Clic (brut) | Un lien réécrit a été demandé | Qu'une personne a cliqué (les scanners font détoner les liens) |
| Clic humain unique | Une personne a agi à partir du message | Que la destination a été atteinte (des pages d'avertissement peuvent la bloquer) |
| Taux de lecture (panel) | Une répartition estimée du temps de lecture, résistante à MPP | Ce qui s'est passé pour un destinataire en particulier ; c'est une estimation par échantillon |
| Conversion ou activité sur le site | Une vraie session et un objectif atteint | (le signal positif le plus fort, et le plus difficile à falsifier) |

## Voir aussi

- [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure), sur la façon dont MPP, Safe Links, la détonation des liens et les proxys d'images faussent ces décomptes
- [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite)
- [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil), sur les définitions de l'engagement qui dépendent des événements auxquels vous vous fiez
- [Contenu et design au service de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite), y compris la réputation du domaine de suivi et le traitement des liens
- [Authentification des domaines des clients](https://emailmarketing.net/learn/esp-operations/customer-domain-authentication), y compris la configuration d'un CNAME de suivi personnalisé pour les clients

# Les interactions non humaines (NHI) et les indicateurs email

> L'étude du M3AAWG de novembre 2020 sur les « clics de robots » des scanners de sécurité : une inflation des clics et des ouvertures < 10 % en B2C contre 20 à 80 % en B2B, pourquoi il est peu fiable d'exclure les NHI, et les pratiques qui les réduisent.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/interactions-non-humaines

Si vos taux de clics ou d'ouverture semblent plus élevés que ce que l'engagement réel peut expliquer, un logiciel clique peut-être sur vos liens et ouvre vos messages avant vos destinataires. Ces interactions non humaines (NHI) peuvent gonfler fortement les indicateurs en business-to-business (B2B), et elles ne peuvent pas être exclues de façon fiable.

Les chiffres ci-dessous proviennent d'une étude du Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) : *M3AAWG Exploring the Impact of Nonhuman Interactions on Email Send Metrics*, novembre 2020 (M3AAWG-136). Le document indique lui-même l'adresse m3aawg.org/sites/default/files/nhi.pdf. L'URL d'origine sur m3aawg.org renvoie désormais une erreur 404, donc le document a été récupéré via la Wayback Machine (instantané du 2025-12-11).

Les NHI, aussi appelées « clics automatisés », désignent le traitement automatisé des emails reçus par un logiciel plutôt que par le destinataire. Elles se produisent généralement lors des **analyses de sécurité effectuées par les logiciels antivirus et de sécurité d'un fournisseur de messagerie**. Le système suit les liens d'un email et visite le site cible pour en analyser le contenu (à la recherche de logiciels malveillants et de pages de phishing). Au passage, il enregistre un « clic » ou une « ouverture » pour la campagne et pollue les statistiques du site web.

Les schémas d'analyse sont volontairement difficiles à reconnaître, pour que les acteurs malveillants ne puissent pas contourner l'analyse. Les symptômes vont de clics sur une partie des liens à **des clics en rafale sur tous les liens de tous les emails envoyés à un domaine**.

Ce qui n'était qu'une anomalie statistique est devenu « un problème majeur qui affecte massivement les indicateurs des campagnes email ». Les expéditeurs qui s'appuyaient sur les taux d'ouverture et de clics pour mesurer leurs performances peuvent avoir besoin d'indicateurs de succès supplémentaires. Les NHI sur les clics sont étroitement liées à la façon dont Apple Mail Privacy Protection (MPP) et le préchargement des images de Gmail gonflent les ouvertures (voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite)).

## Impact mesuré (étude comparative du M3AAWG)

Méthode : l'étude a utilisé des données comparatives provenant de grands et de petits ESP, et d'expéditeurs B2B et business-to-consumer (B2C) de tout le secteur, couvrant dans certains cas plusieurs années de données d'envois, de clics et d'ouvertures. Elle visait à vérifier si les **chaînes user-agent des navigateurs permettaient d'identifier les NHI de façon fiable**, et si les NHI pouvaient être exclues de façon fiable pour retrouver un vrai taux de clics.

| Segment | Impact des NHI sur les indicateurs | Remarques |
|---|---|---|
| **B2C** | En général **< 10 %** | De gros volumes vont vers un nombre restreint de grands fournisseurs de messagerie grand public. Le chiffre est resté constant tout au long de l'étude. **L'impact est plus faible pour les marques plus réputées** |
| **B2B** | **20–80 %** | Les logiciels antispam d'entreprise sont plus stricts sur les messages entrants. La fourchette était corrélée à l'engagement des destinataires : **plus l'engagement est faible chez un fournisseur de messagerie, plus la probabilité d'analyses NHI est élevée** |

L'étude n'a pas pu ventiler les niveaux de NHI par secteur d'activité de façon significative. Un effet global à l'échelle du secteur est difficile à chiffrer, car **les éditeurs de filtres et les fournisseurs d'accès à Internet masquent activement leurs analyses pour qu'elles ne soient pas détectées**, ce qu'ils doivent faire pour que les filtres ne soient pas contournés. Tout effort d'exclusion laisse donc une marge d'erreur dans les taux « corrigés des NHI ».

L'étude a en revanche constaté une forte **corrélation entre la réputation et les NHI**. Le M3AAWG recommande de bâtir et d'entretenir une bonne réputation pour réduire l'impact des NHI sur les taux d'ouverture et de clics.

## Impact sur l'activité

- **E-commerce** : les clics et ouvertures automatisés peuvent **déclencher des automatisations marketing et des emails de relance**. Des indicateurs peu fiables rendent moins précise la planification du retour sur investissement (ROI) et du retour sur les dépenses publicitaires. Le coût tient davantage aux occasions perdues qu'aux revenus perdus.
- **Médias et marketing de contenu** : les clics et les visites du site sont souvent l'indicateur de conversion lui-même. Les stratégies fondées sur des clics, des ouvertures ou des lectures d'articles garantis ne peuvent plus s'appuyer sur ces chiffres. Cela réduit directement les revenus publicitaires et d'abonnement, et menace les revenus marketing qui dépendent de la génération de prospects. Le M3AAWG conseille de renforcer **la vérification des formulaires et des adresses email** pour préserver la qualité des listes.
- **Réputation de la marque et de l'ESP** : à mesure que les indicateurs d'engagement deviennent moins fiables, il devient plus difficile de segmenter selon l'engagement et de mettre en sommeil les destinataires. La qualité des listes diminue alors, et l'engagement réel baisse, ce qui fait baisser la réputation du domaine. Les ESP qui hébergent **les liens de suivi des clics sur leurs propres domaines** sont également exposés.
- **Hygiène de base de données** : les NHI produisent un faux « engagement ». Un nettoyage de liste fondé sur la dernière activité **peut conserver des adresses qui n'ont jamais été « actives » qu'à cause des NHI**, ce qui met en échec les séries de réengagement et les politiques de retrait des adresses inactives ([Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil)).
- **Préjudice pour les destinataires** : les NHI peuvent déclencher des actions auxquelles le destinataire n'a jamais consenti, comme valider un double opt-in ou un opt-in confirmé, confirmer des informations, rejoindre une nouvelle liste, quitter une liste existante ou enregistrer un intérêt pour des articles qui ne l'intéressent pas. Il en résulte davantage d'emails indésirables, de plaintes pour abus et d'atteintes à la marque.

## Meilleures pratiques qui réduisent les NHI (issues de l'étude)

- **Utilisez HTTPS pour tous les liens.** Les liens de suivi qui mêlent adresses sécurisées et non sécurisées semblent ciblés de façon disproportionnée. Un lien annonceur en HTTP derrière un lien de suivi en HTTPS « semble déclencher le plus de comportements indésirables ».
- **Envoyez des campagnes distinctes aux destinataires à l'engagement confirmé et aux destinataires inactifs**, en particulier lorsque le placement en boîte de réception pose problème chez certains domaines.
- **Surveillez la qualité du contenu** au niveau des liens et au-delà (par exemple, le rapport entre images et texte). Un marketing « agressif », comme des émoticônes dans les lignes d'objet ou de gros mots d'accroche, tend à attirer davantage de NHI.
- **La réputation d'expéditeur compte** : les NHI sont nettement moins nombreuses chez les expéditeurs dont les destinataires sont très engagés.

Les recommandations permanentes s'appliquent aussi. Suivez la [BCP pour les expéditeurs](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs) pour la délivrabilité et l'engagement, et la [BCP sur l'authentification des emails](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-l-authentification-des-emails), qui permet aux fournisseurs de rattacher la réputation à la marque de l'expéditeur. De bonnes pratiques de contenu réduisent l'impact des NHI.

La version 4.0 des [Sender Best Common Practices du M3AAWG](https://www.m3aawg.org/senderbcp) (août 2026) lit l'engagement de la même façon pendant la chauffe d'un domaine. Une forte hausse des ouvertures ou des clics peut signifier que des filtres de sécurité examinent les emails de plus près, tandis qu'une baisse peut signifier qu'ils arrivent dans le courrier indésirable.

## Conclusions et limites

- Il n'existe **aucun guide d'atténuation définitif**. Les données de l'étude ne couvrent que les interactions qui ont pu être identifiées comme NHI, pas 100 % d'entre elles.
- Les scanners utilisent **des comportements simulés conçus pour être indiscernables d'interactions humaines naturelles**. Les identifier est déjà très difficile et « deviendra quasiment impossible à l'avenir ».
- Retirer les NHI change les chiffres, mais un expéditeur ne peut jamais être sûr de les avoir toutes détectées, et l'effort n'en vaut pas forcément la peine. Si chaque ESP exclut les NHI à sa manière, les indicateurs deviennent encore plus difficiles à comparer.
- En résumé, les NHI ont des conséquences mesurables et importantes. Réévaluez la façon dont vous utilisez les données d'engagement pour décider de la fréquence d'envoi ou de la segmentation, et tenez compte de cette inflation lorsque vous lisez les tableaux de bord de clics et d'ouvertures.

# Lire les en-têtes Received : sauts, délais et ce qu'ils prouvent

> Comment lire les champs de trace Received d'un message livré : la syntaxe du champ, l'ordre de lecture de bas en haut, les sauts auxquels se fier, le calcul du délai de chaque saut malgré les fuseaux horaires, et le lien entre Received et Authentication-Results.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/lire-les-en-tetes-received

Chaque serveur SMTP qui accepte un message ajoute une ligne `Received:` en tête de celui-ci. Lues ensemble, ces lignes retracent le chemin suivi par le message et le moment où chaque hôte l'a reçu. C'est la première chose à vérifier lorsqu'un message est arrivé en retard ou par un chemin inattendu. Certaines de ces lignes sont des preuves fiables, d'autres ne sont que des affirmations, et cet article explique comment les distinguer.

Les règles viennent de la [RFC 5321](https://emailmarketing.net/learn/rfc/rfc5321-smtp) §4.4 (informations de trace) et de la [RFC 5322](https://emailmarketing.net/learn/rfc/rfc5322-message-format) §3.6.7 (champs de trace). Le lien avec `Authentication-Results` vient de la RFC 8601 (voir [l'en-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results)).

## D'où viennent les lignes Received

RFC 5321 §4.4 : « Lorsqu'un serveur SMTP reçoit un message à livrer ou à traiter, il DOIT insérer des informations de trace ("time stamp" ou "Received") au début du contenu du message » (*When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content*). Trois conséquences découlent directement de la même section :

- **Chaque ligne est écrite par l'hôte qui reçoit, pas par l'expéditeur.** Une ligne `Received:` enregistre l'acceptation du message par un hôte.
- **Les lignes ne sont ajoutées qu'en tête.** « Les serveurs SMTP DOIVENT ajouter les lignes Received en tête des messages ; ils NE DOIVENT PAS modifier l'ordre des lignes existantes ni insérer de lignes Received à un autre endroit » (*SMTP servers MUST prepend Received lines to messages ; they MUST NOT change the order of existing lines or insert Received lines in any other location*).
- **Les lignes existantes ne sont ni modifiées ni supprimées.** « Un programme de messagerie Internet NE DOIT PAS modifier ou supprimer une ligne Received : ajoutée précédemment à la section d'en-tête du message » (*An Internet mail program MUST NOT change or delete a Received : line that was previously added to the message header section*).

Ce sont des exigences imposées aux logiciels conformes, pas des garanties valables pour chaque message. La RFC 3848 §3 note que « certaines personnes, dans une tentative malavisée de cacher des informations sur leurs serveurs internes, retirent des informations utiles des en-têtes Received » (*some people in a misguided attempt to hide information about their internal servers will strip Received headers of useful information*) : une chaîne peut donc présenter des trous.

Lorsque le message quitte SMTP au moment de la livraison finale, le serveur qui livre ajoute aussi `Return-Path:`, qui contient l'adresse `MAIL FROM` de l'enveloppe. La RFC 5321 §4.4 indique que le message livré « commence par une ligne de chemin de retour, suivie d'une ou plusieurs lignes d'horodatage » (*begin with a return path line, followed by one or more time stamp lines*).

La RFC 5322 §3.6.7 considère ces champs comme « strictement informatifs, toute interprétation formelle sortant du cadre de ce document » (*strictly informational, and any formal interpretation of them is outside of the scope of this document*). Il n'y a rien à valider : une ligne `Received:` n'est digne de confiance que dans la mesure où l'est l'hôte qui l'a écrite.

## Syntaxe du champ

La RFC 5321 §4.4 définit la ligne (version abrégée ; `FWS`/`CFWS` désignent les espaces de pliage et les commentaires de la RFC 5322) :

```
Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp           = From-domain By-domain Opt-info [CFWS] ";" FWS date-time
Opt-info        = [Via] [With] [ID] [For] [Additional-Registered-Clauses]
```

Une ligne peut être pliée sur plusieurs lignes physiques : dépliez-la avant de la lire. Les clauses, dans l'ordre :

| Clause | Ce qu'elle enregistre | Qui fournit la valeur |
|---|---|---|
| `from` | L'hôte qui a remis le message. RFC 5321 : elle « DEVRAIT contenir à la fois (1) le nom de l'hôte source tel que présenté dans la commande EHLO et (2) un littéral d'adresse contenant l'adresse IP de la source, déterminée à partir de la connexion TCP » (*SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection*). La partie entre parenthèses (`TCP-info`) correspond aux « informations dérivées par le serveur de la connexion TCP, et non de l'EHLO du client » (*Information derived by server from TCP connection not client EHLO*). | Le **nom avant les parenthèses** est ce que le client a annoncé dans `EHLO`. **L'adresse entre parenthèses** est ce que le serveur de réception a observé sur la connexion. |
| `by` | L'hôte qui a reçu le message et écrit cette ligne. | Le serveur de réception. |
| `via` | Le type de liaison (`TCP`). RFC 5321 : « "Via" est surtout utile avec des transports autres qu'Internet » (*'Via' is primarily of value with non-Internet transports*). | Le serveur de réception. |
| `with` | Le protocole : `SMTP` ou `ESMTP` dans la RFC 5321, plus les noms enregistrés auprès de l'IANA. La RFC 3848 a enregistré `ESMTPS` (STARTTLS négocié), `ESMTPA` (SMTP AUTH réussi), `ESMTPSA` (les deux), et `LMTP` avec ses variantes `A`/`S`/`SA`. | Le serveur de réception, qui décrit **ce saut uniquement**. |
| `id` | Un identifiant choisi par le serveur de réception, un atome ou un `msg-id`. RFC 5321 : il « PEUT contenir un "@"… mais ce n'est pas obligatoire » (*MAY contain an '@'… but this is not required*). La RFC 5321 ne définit pas ce qu'il identifie. | Le serveur de réception. Si vous exploitez cet hôte, cherchez la valeur dans ses journaux. |
| `for` | Le destinataire. RFC 5321 : « Si la clause FOR apparaît, elle DOIT contenir exactement une entrée `<path>`, même lorsque plusieurs commandes RCPT ont été données » (*If the FOR clause appears, it MUST contain exactly one `<path>` entry, even when multiple RCPT commands have been given*). | Le serveur de réception. Elle est facultative. |
| `; date-time` | Le moment où cet hôte a reçu le message, au format `date-time` de la RFC 5322. La RFC 5321 interdit les formes obsolètes, « en particulier les années à deux chiffres » (*especially two-digit years*). | L'horloge du serveur de réception lui-même. |

Ne lisez pas le mot-clé `with` comme une preuve de chiffrement ou d'authentification. La RFC 3848 §3 indique que ces mots-clés « peuvent être modifiés par un attaquant actif » (*can be modified by an active attacker*) et « n'apportent aucune garantie de sécurité réelle » (*do not provide any real-world security assurance*).

La grammaire autorise des commentaires (`CFWS`) entre les clauses, si bien que les implémentations ajoutent du texte libre entre parenthèses. Le contenu de ces commentaires n'est pas normalisé : ne l'analysez pas comme s'il l'était.

## Ordre de lecture : de bas en haut

Chaque serveur ajoute sa propre ligne en tête, donc les lignes se lisent de la plus récente à la plus ancienne :

- La ligne `Received:` du **bas** est le premier saut enregistré : le premier serveur qui a accepté le message et écrit une ligne.
- La ligne `Received:` du **haut** est le saut le plus récent.
- Comparez l'hôte `by` de chaque ligne avec l'hôte `from` de la ligne située au-dessus. Ils ne seront souvent pas écrits de la même façon, car le nom `from` est ce qu'annonce le client dans `EHLO`, et le nom `EHLO` d'un hôte peut légitimement différer du nom qu'il écrit dans `by`. Une discordance est une raison d'y regarder de plus près, pas la preuve qu'un saut manque ou qu'une ligne est fausse. Les adresses IP entre les parenthèses de `from` sont un meilleur fil conducteur.

Pour retracer le chemin, partez du bas et remontez.

## Les sauts auxquels se fier

Savoir d'où viennent les lignes indique jusqu'où leur faire confiance.

1. **Une ligne n'est fiable que dans la mesure où l'est l'hôte qui l'a écrite.** N'importe quel client SMTP peut ouvrir une connexion et écrire ce qu'il veut dans le contenu du message avant la fin de `DATA`, y compris du texte qui ressemble à des lignes `Received:` antérieures. RFC 5321 §7.1 : « il est possible, même pour des utilisateurs assez occasionnels, de dialoguer directement avec des serveurs SMTP de réception et de relais et de créer des messages qui feront croire à un destinataire naïf qu'ils viennent d'ailleurs » (*it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else*).
2. **Vos serveurs conservent tout ce qu'on leur a remis.** Les lignes existantes « NE DOIVENT PAS » être modifiées ou supprimées : un serveur de réception garde donc les lignes fabriquées avec les vraies.
3. **Vous ne pouvez donc vous fier qu'aux lignes ajoutées par votre propre infrastructure de réception.** « Votre propre » désigne ici l'ADMD côté réception, le domaine administratif que la RFC 8601 §1.2 décrit comme situé à l'intérieur de sa « frontière de confiance » (*trust boundary*). Trouvez la ligne la plus basse dont l'hôte `by` est l'un de vos serveurs. C'est le **premier saut de confiance**, le moment où le message est entré dans votre infrastructure.
4. **Dans le premier saut de confiance, ne vous fiez qu'à ce que votre serveur a observé.** C'est-à-dire son horodatage, son `id`, son protocole `with` et **l'adresse IP entre les parenthèses de `from`**, qui provient de la connexion TCP. Le nom `from` avant les parenthèses vient de l'`EHLO` du client et n'est qu'une affirmation.
5. **Tout ce qui se trouve sous le premier saut de confiance peut être falsifié.** Les lignes situées en dessous étaient déjà dans le message quand votre serveur l'a accepté. Elles peuvent être exactes : les relais d'un expéditeur légitime écrivent des lignes exactes, et elles vous aident à déboguer le côté de cet expéditeur. Mais l'IP qui se connecte dans le premier saut de confiance est la seule adresse de la chaîne que votre infrastructure a vérifiée.

La même logique s'applique quand c'est vous l'expéditeur et que vous lisez une copie arrivée dans une boîte que vous n'exploitez pas. Seules les lignes ajoutées par l'infrastructure du fournisseur **de réception** sont des observations du récepteur. Les lignes situées en dessous sont les enregistrements de vos propres systèmes, que vous pouvez confronter à vos propres journaux.

## Délai de chaque saut

Chaque horodatage marque le moment où *cet* hôte a reçu le message. La différence entre deux horodatages adjacents est le temps passé par le message entre une réception et la suivante : en file d'attente sur l'hôte inférieur, ou en transit depuis celui-ci.

### Normalisez d'abord les fuseaux horaires

La RFC 5321 §4.4 demande aux serveurs d'utiliser des décalages numériques : « Les serveurs SMTP qui créent des champs d'en-tête Received DEVRAIENT utiliser des décalages explicites dans les dates (par exemple -0800) plutôt que des noms de fuseaux horaires, quels qu'ils soient. L'heure locale (avec un décalage) DEVRAIT être utilisée de préférence à l'UT lorsque c'est possible » (*SMTP servers that create Received header fields SHOULD use explicit offsets in the dates (e.g., -0800), rather than time zone names of any type. Local time (with an offset) SHOULD be used rather than UT when feasible*). La RFC 5322 §3.3 définit le décalage : « +hhmm signifie +(hh * 60 + mm) minutes, et -hhmm signifie -(hh * 60 + mm) minutes » (*+hhmm means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) minutes*). Un horodatage en `-0000` signifie que « l'heure a été générée sur un système qui peut se trouver dans un fuseau horaire local autre que le temps universel, et que la date-heure ne contient aucune information sur le fuseau horaire local » (*the time was generated on a system that may be in a local time zone other than Universal Time and that the date-time contains no information about the local time zone*).

Pour calculer un délai, convertissez chaque horodatage en UTC en soustrayant son décalage (`09:00:02 -0400` correspond à `13:00:02 UTC`), puis soustrayez les valeurs adjacentes. Si vous comparez les heures affichées sans conversion, un saut peut sembler durer des heures, voire se produire avant le saut situé en dessous.

### Décalage des horloges

Chaque horodatage vient de l'horloge de l'hôte qui l'a écrit, et rien dans la RFC 5321 n'exige que ces horloges concordent. La RFC 5321 indique bien que « la comparabilité des champs d'en-tête Received est importante pour détecter les problèmes, en particulier les relais lents » (*comparability of Received header fields is important for detecting problems, especially slow relays*), et c'est pourquoi les décalages comptent. Ce qui suit est un raisonnement pratique fondé sur la façon dont les horodatages sont produits, pas une exigence de la RFC :

- Un délai **négatif**, où l'horodatage d'un saut ultérieur est antérieur à celui du saut situé en dessous, signifie que les deux horloges ne concordent pas. Il ne peut pas signifier que le message a remonté le temps. Signalez ce saut comme un « désaccord d'horloges » plutôt que comme un délai.
- Un **petit** délai entre des hôtes gérés par des opérateurs différents peut rester dans la marge d'erreur des horloges. Accordez plus de poids à un petit délai entre deux hôtes de la même infrastructure.

### Ce qu'un long délai peut indiquer

Un long écart entre deux sauts signifie que le message a attendu quelque part entre ces deux réceptions. Causes connues compatibles avec un tel écart :

- **Un échec temporaire suivi d'une nouvelle tentative.** Après une réponse `4xx`, l'hôte d'envoi conserve le message et réessaie plus tard. RFC 5321 §4.5.4.1 : « En général, l'intervalle entre les tentatives DEVRAIT être d'au moins 30 minutes ; toutefois, des stratégies plus élaborées et variables seront bénéfiques lorsque le client SMTP peut déterminer la raison de la non-livraison » (*In general, the retry interval SHOULD be at least 30 minutes ; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery*). C'est une recommandation, pas un plancher. Un report de remise retenté conformément à cette recommandation laisse un écart d'environ 30 minutes ou plus, mais un expéditeur qui suit une autre stratégie peut réessayer plus tôt. Voir [Réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta).
- **La liste grise.** La RFC 6647 la décrit comme une « dégradation du service pour une source inconnue ou suspecte, pendant une période (généralement de l'ordre de quelques minutes ou de quelques heures) » (*degradation of service for an unknown or suspect source, over a period of time (typically measured in minutes or a small number of hours)*), et note que « certains MTA répandus ne retentent pas les livraisons échouées avant une heure ou plus » (*Some popular MTAs do not retry failed delivery attempts for an hour or more*). Voir [liste grise](https://emailmarketing.net/learn/rfc/rfc6647-greylisting).
- **L'hôte inférieur qui garde le message** dans sa file d'attente avant sa première tentative. L'en-tête n'en enregistre pas la raison. Voir [Réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta) pour la façon dont les files d'attente d'envoi ordonnancent le travail.

### Ce qu'un long délai ne prouve pas

- **Il ne vous donne pas la cause.** La RFC 6647 §3 le dit clairement : « Un client ne sait pas, et n'a pas à savoir, pourquoi le code d'état d'échec temporaire est renvoyé ; une liste grise peut être en place, ou il peut s'agir d'un problème de ressources locales sur le serveur » (*A client does not know, nor is it entitled to know, the reason for the temporary failure status code being returned ; greylisting could be in effect, or it could be caused by a local resource issue at the server*). L'en-tête montre *où* le temps s'est écoulé. Le *pourquoi* se trouve dans les codes et textes de réponse journalisés par l'hôte qui a gardé le message : consultez ses journaux à l'aide de l'`id` de la ligne qu'il a écrite. Voir [Procédures de dépannage de la livraison](https://emailmarketing.net/fr/apprendre/operations/procedures-de-depannage-de-la-livraison).
- **Il ne prouve rien sous le premier saut de confiance.** Un délai entre deux lignes auxquelles vous ne pouvez pas vous fier peut être inventé.
- **Il ne dit rien de ce qui s'est passé après la ligne du haut.** Le temps écoulé entre le dernier horodatage `Received:` et le moment où une personne a vu le message n'est pas enregistré ici.
- **Il ne dit rien du dossier de placement ni du filtrage.** Les lignes `Received:` n'enregistrent que l'acceptation et la chronologie.

## Le lien entre Received et Authentication-Results

Le récepteur qui a vérifié SPF, DKIM et DMARC consigne son verdict dans un champ `Authentication-Results:` (RFC 8601). Les deux types de champ font face au même problème de falsification, et partagent la même solution : ne se fier qu'aux champs ajoutés à l'intérieur de votre propre frontière de confiance. La RFC 8601 §5 admet une exception : un MTA de bordure « PEUT choisir de ne pas supprimer » (*MAY elect not to delete*) les résultats d'un hôte amont auquel il fait explicitement confiance, « même s'ils se trouvent dans des frontières administratives totalement disjointes » (*even though they exist in completely disjoint administrative boundaries*).

- **Authentication-Results se comporte comme un champ de trace.** RFC 8601 §4.1 : il « DOIT être traité comme s'il s'agissait d'un champ d'en-tête de trace tel que défini à la section 3.6.7 de [MAIL], et par conséquent NE DOIT PAS être réordonné et DOIT être ajouté en tête du message, afin qu'il y ait généralement, à la livraison, une indication de l'endroit de la chaîne de MTA où l'authentification du message a été effectuée » (*MUST be treated as though it were a trace header field as defined in Section 3.6.7 of [MAIL] and hence MUST NOT be reordered and MUST be prepended to the message, so that there is generally some indication upon delivery of where in the chain of handling MTAs the message authentication was done*).
- **Les copies falsifiées sont retirées à la frontière.** RFC 8601 §5 : un MTA « DOIT supprimer toute occurrence découverte de ce champ d'en-tête qui prétend, par son identifiant de service d'authentification, avoir été ajoutée à l'intérieur de sa frontière de confiance mais qui ne provient pas directement d'un autre MTA de confiance » (*MUST delete any discovered instance of this header field that claims, by virtue of its authentication service identifier, to have been added within its trust boundary but that did not come directly from another trusted MTA*). La section 1.6 en donne la raison : « un usage valide du champ d'en-tête exige de retirer toutes ses occurrences qui prétendent être associées à l'ADMD lorsque le message entre dans l'ADMD » (*valid use of the header field requires removing any occurrences of it that claim to be associated with the ADMD when the message enters the ADMD*).
- **La position peut servir de test de validité.** La RFC 8601 §7.1 la cite parmi plusieurs approches proposées, dont aucune n'est normalisée. Le test suppose que « les MTA internes sont entièrement conformes » (*internal MTAs are fully compliant*) et utilisent leurs propres noms d'hôte ou le domaine de l'ADMD comme `authserv-id`. Dans cette hypothèse, « ce champ d'en-tête devrait toujours apparaître au-dessus d'un en-tête Received ajouté par un MTA de confiance. Cela peut servir de test de validité du champ d'en-tête » (*this header field should always appear above a Received header added by a trusted MTA. This can be used as a test for header field validity*).
- **La confiance est une liste explicite, pas un comportement par défaut.** RFC 8601 §7.1 : « Il est acceptable qu'un MUA qui connaît cette spécification dispose d'une liste explicite de noms d'hôte dont les champs d'en-tête Authentication-Results sont dignes de confiance ; cette liste devrait toutefois être vide au départ » (*It is acceptable to have an MUA aware of this specification but have an explicit list of hostnames whose Authentication-Results header fields are trustworthy ; however, this list should initially be empty*).

Le **point d'ancrage de la confiance** est donc le récepteur qui a ajouté à la fois votre première ligne `Received:` de confiance et un champ `Authentication-Results:` dont il possède l'`authserv-id`. Lisez cette paire ensemble :

- La ligne `Received:` donne l'IP de connexion qu'il a observée.
- La ligne `Authentication-Results:` donne les verdicts qu'il a calculés pour cette connexion.

Un champ `Authentication-Results:` situé sous le premier saut de confiance, ou portant l'`authserv-id` de quelqu'un d'autre, est l'affirmation d'un tiers. Pour savoir comment les résultats d'authentification peuvent survivre à un service de transfert, voir [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc).

Même un `pass` de confiance a une portée limitée. RFC 8601 §7.2 : « l'existence de ce champ d'en-tête indiquant un "pass" ne rend pas le message digne de confiance » (*the existence of this header field indicating a "pass" does not render the message trustworthy*).

## Exemple commenté

Le message ci-dessous a été envoyé par un client de la plateforme d'envoi d'`example.net` à un destinataire chez `example.com`. Les noms, identifiants et adresses sont fictifs ; les IP proviennent des plages réservées à la documentation. La section d'en-tête est présentée de haut en bas telle qu'elle apparaît dans le message livré, sans les champs autres que de trace :

```
Return-Path: <bounce-7731@bounce.example.net>
Received: from mx1.example.com (mx1.example.com [192.0.2.25])
        by store.example.com with LMTP id 9KcQ2
        for <reader@example.com>; Thu, 10 Sep 2026 13:31:11 +0000
Authentication-Results: mx1.example.com;
        spf=pass smtp.mailfrom=bounce.example.net;
        dkim=pass header.d=example.net;
        dmarc=pass header.from=example.net
Received: from out1.example.net (out1.example.net [198.51.100.20])
        by mx1.example.com with ESMTPS id 4Q8kx2
        for <reader@example.com>; Thu, 10 Sep 2026 15:31:10 +0200
Received: from submit.example.net (submit.example.net [198.51.100.5])
        by out1.example.net with ESMTP id A71F3;
        Thu, 10 Sep 2026 13:00:03 +0000
Received: from workstation.example.net (workstation.example.net [203.0.113.10])
        by submit.example.net with ESMTPSA id 0e2c9;
        Thu, 10 Sep 2026 09:00:02 -0400
```

**Étape 1 : lire de bas en haut et vérifier la continuité.** Le chemin est `workstation` → `submit.example.net` → `out1.example.net` → `mx1.example.com` → `store.example.com`. L'hôte `by` de chaque ligne est l'hôte `from` de la ligne suivante : la chaîne est continue.

**Étape 2 : trouver le premier saut de confiance.** L'infrastructure de réception est `example.com`. La ligne la plus basse écrite `by` un hôte `example.com` est la ligne de `mx1.example.com`. C'est le premier saut de confiance, et l'IP de connexion qu'il a observée est `198.51.100.20`. Les deux lignes situées en dessous ont été écrites par des hôtes `example.net`. Ce sont les propres enregistrements de la plateforme d'envoi : utiles à ses opérateurs et vérifiables dans leurs journaux, mais des affirmations non vérifiées du point de vue du récepteur.

**Étape 3 : rattacher Authentication-Results.** Le champ `Authentication-Results:` porte l'`authserv-id` `mx1.example.com` et se trouve directement au-dessus de la ligne `Received:` écrite par `mx1`. Cela correspond au test de position de la RFC 8601 §7.1. Ses verdicts SPF, DKIM et DMARC sont le jugement de `mx1` sur le message arrivé depuis `198.51.100.20`.

**Étape 4 : normaliser les horodatages et calculer les délais.**

| Saut (écrit par) | Horodatage tel qu'écrit | UTC | Délai depuis le saut précédent |
|---|---|---|---|
| `submit.example.net` | 09:00:02 -0400 | 13:00:02 | (premier saut) |
| `out1.example.net` | 13:00:03 +0000 | 13:00:03 | 1 s |
| `mx1.example.com` (premier de confiance) | 15:31:10 +0200 | 13:31:10 | **31 min 7 s** |
| `store.example.com` | 13:31:11 +0000 | 13:31:11 | 1 s |

Lu en heures locales, le saut `mx1` semble arriver 2,5 heures après `out1`. L'écart réel est de 31 minutes, et le message les a passées entre sa réception par `out1.example.net` et son acceptation par `mx1.example.com`.

**Étape 5 : interpréter avec prudence.** Un écart de 31 minutes correspond à un seul échec temporaire suivi d'une nouvelle tentative conforme à l'intervalle d'au moins 30 minutes recommandé par la RFC 5321. Il correspond aussi à une liste grise, ou à une attente en file sur `out1`. L'en-tête seul ne permet pas de les distinguer. Le journal de livraison de la plateforme d'envoi pour l'identifiant de file `A71F3` sur `out1` indique si une tentative a été reportée et quel était le texte de la réponse. Et comme l'horodatage d'`out1` vient du côté expéditeur, un désaccord d'horloges entre les deux opérateurs fait partie de la marge.

## Liste de contrôle

- Dépliez chaque ligne `Received:`, puis lisez de bas en haut.
- Comparez chaque hôte `by` avec l'hôte `from` de la ligne située au-dessus. Une discordance est une raison d'y regarder de plus près, pas la preuve d'un saut manquant ou faux.
- Trouvez la ligne la plus basse écrite `by` votre infrastructure de réception. Fiez-vous à cette ligne et à celles du dessus ; traitez tout ce qui est en dessous comme une affirmation.
- Dans le premier saut de confiance, fiez-vous à l'IP entre les parenthèses de `from`, pas au nom `EHLO`.
- Convertissez chaque horodatage en UTC avant de soustraire. Traitez les délais négatifs comme un désaccord d'horloges.
- Servez-vous d'un long délai pour localiser l'hôte qui a gardé le message, puis cherchez la cause dans les journaux de cet hôte à l'aide de l'`id` de la ligne.
- Lisez le champ `Authentication-Results:` dont l'`authserv-id` appartient au récepteur et qui se trouve au-dessus de la propre ligne `Received:` de ce récepteur.

## Voir aussi

- [RFC 5321 : SMTP](https://emailmarketing.net/learn/rfc/rfc5321-smtp) · [RFC 5322 : format des messages](https://emailmarketing.net/learn/rfc/rfc5322-message-format) · [RFC 5598 : architecture de l'email](https://emailmarketing.net/learn/rfc/rfc5598-email-architecture)
- [L'en-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results) · [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc) · [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) · [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim)
- [Liste grise (RFC 6647)](https://emailmarketing.net/learn/rfc/rfc6647-greylisting) · [Réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta) · [TLS pour SMTP en pratique](https://emailmarketing.net/learn/transport-security/smtp-tls-practice)
- [Procédures de dépannage de la livraison](https://emailmarketing.net/fr/apprendre/operations/procedures-de-depannage-de-la-livraison)

# Méthodologie de mesure du placement

> Comment le placement en boîte de réception est réellement mesuré (listes de test, panels d'abonnés, télémétrie par pixel et taux de lecture, tableaux de bord des fournisseurs de messagerie) et le biais systématique de chaque méthode, y compris les angles morts « sans données » de Google Postmaster Tools.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/methodologie-de-mesure-du-placement

Quand vous citez un taux de placement en boîte de réception, vous citez une estimation, car personne en dehors d'un fournisseur de messagerie ne peut voir directement où un message livré a atterri. SMTP vous indique qu'un message a été accepté (250 OK), mais ne dit rien de sa destination : boîte de réception, spam, onglet Promotions, ou suppression silencieuse.

Tout chiffre de placement que cite un opérateur vient donc de l'une de quatre méthodes indirectes, et **chaque méthode se trompe dans une direction connue et systématique**. Choisissez la méthode adaptée à votre question, et corrigez le biais inscrit dans sa réponse.

Pour le programme de surveillance qu'alimentent ces méthodes, voir [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation). Pour comprendre pourquoi les signaux d'engagement sur lesquels reposent certaines méthodes sont eux-mêmes faussés, voir [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure). Pour le tableau de bord le plus détaillé d'un fournisseur de messagerie, voir [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools).

## Les quatre méthodes de mesure en un coup d'œil

| Méthode | Ce qu'elle observe | Vrais destinataires ? | Engagement pris en compte ? | Voit les messages manquants ou bloqués ? | Couverture des fournisseurs | Biais systématique |
|---|---|---|---|---|---|---|
| **Liste de test (seed list)** | Placement d'un message de test dans des boîtes de test dédiées | Non | Non | Oui | Large (des centaines de fournisseurs) | Prudente et bruitée : aucun historique d'engagement, échantillon minuscule |
| **Panel d'abonnés** | Placement et comportement dans de vraies boîtes surveillées de personnes consentantes | Oui | Oui | Non | Étroite (quelques grands webmails) | Optimiste : exclut les messages manquants ou bloqués à la passerelle |
| **Télémétrie par pixel ou taux de lecture** | Événements d'ouverture sur vos propres envois réels | Oui (implicitement) | Ouvertures uniquement | Indirectement (une baisse suggère un filtrage) | Tout fournisseur auquel vous envoyez | Faussée par le préchargement d'Apple Mail Privacy Protection (MPP), les proxys et les scanners |
| **Tableau de bord du fournisseur** | La vue du serveur de réception lui-même sur votre réputation et votre taux de spam | Oui (tous) | Plaintes, agrégées | Partiellement (erreurs de livraison) | Un fournisseur chacun ; seuls les grands fournisseurs en publient un | Aveugle sous un plancher de volume ; en retard ; couvre uniquement les boîtes grand public |

Aucune méthode ne suffit à elle seule, et les programmes honnêtes recoupent les sources. Les sections ci-dessous expliquent comment chaque méthode est construite et où elle induit en erreur.

## Méthode 1 : les listes de test (et les comptes de test personnels)

Un **test sur liste de test** (*seed test*) envoie une copie de la campagne à une liste soignée d'adresses de test. Ce sont des boîtes de test dédiées que le fournisseur du service entretient chez de nombreux fournisseurs de messagerie, filtres antispam et régions. Le test indique où chaque copie a atterri : boîte de réception, spam, onglet précis (Primary, Promotions, Updates, Social ou Forums de Gmail), dossier d'un filtre d'entreprise, ou **manquant** (accepté puis supprimé, ou bloqué à la passerelle).

Bien fait, le test injecte les adresses de test dans l'envoi de production lui-même (le même message, la même infrastructure et la même IP, la même fenêtre d'envoi), afin que leur traitement se rapproche de celui de la vraie campagne plutôt que de celui d'une copie de test fabriquée à la main.

Ce à quoi les tests sur liste de test servent vraiment :

- **Les contrôles qualité avant lancement** : détecter les échecs d'authentification (SPF, DKIM, DMARC), les défauts d'affichage et les liens morts avant que la vraie liste ne les voie.
- **La comparaison entre fournisseurs** : isoler un problème du type « nous arrivons en boîte de réception partout sauf chez Microsoft ».
- **Le test de changements** : une variable à la fois, comme un nouveau modèle, un nouveau domaine de suivi ou une nouvelle IP d'envoi.
- **Le tri des incidents** : une lecture rapide pour savoir si un problème en cours vient du contenu, de l'authentification ou de la réputation.
- **Les nouveaux programmes sans historique** : un panel a besoin que vos messages atteignent de vrais utilisateurs engagés avant de pouvoir dire quoi que ce soit, alors que les listes de test indiquent le placement « indépendamment du filtrage déclenché par l'utilisateur ou fondé sur l'engagement » (*irrespective of user-initiated or engagement-based filtering*). Pour un programme qui démarre à froid, une liste de test peut être le seul signal disponible.

### Où les listes de test se trompent

Les critiques de Mailgun, de la Certified Senders Alliance (CSA) et de Suped convergent vers les mêmes défauts structurels :

1. **Pas d'engagement, alors que les filtres modernes fonctionnent à l'engagement.** Les adresses de test ne font rien. Selon la CSA, elles « n'ouvrent ni ne lisent les emails, ne cliquent pas sur les liens, ne se désabonnent pas et ne se plaignent pas » (*don't open or read emails, click on links, unsubscribe or complain*). Le placement chez Gmail, Microsoft et Yahoo est désormais dominé par le comportement des abonnés (ouvertures, clics, transferts, plaintes, suppressions, enregistrements), si bien qu'un indicateur sans aucune donnée d'engagement peut s'écarter fortement de ce que vivent les vrais abonnés. Un résultat sur liste de test est un instantané de la façon dont les filtres évaluent le contenu, l'authentification et la réputation sans humain dans la boucle.
2. **Les fournisseurs ne traitent pas les adresses de test comme de vrais destinataires.** Mailgun l'affirme sans détour : « les fournisseurs de messagerie ne traitent pas les boîtes de test comme les vrais destinataires » (*mailbox providers don't treat seed inboxes the same as actual recipients*). Les boîtes de test n'ont aucun historique de réception de vos messages, si bien que leur placement penche vers la prudence (aucun capital de confiance accumulé), et elles passent à côté du filtrage personnalisé dont bénéficierait un vrai abonné engagé.
3. **Un échantillon minuscule et non représentatif.** Une poignée d'adresses de test ne peut pas remplacer des milliers de vrais destinataires dont le volume, les horaires et la qualité de liste varient. Les résultats montrent **un seul instant**, pas une tendance durable.
4. **Des faux positifs comme des faux négatifs.** Les adresses de test peuvent afficher la boîte de réception alors que les vrais abonnés sont filtrés, ou l'inverse. **Un seul mauvais résultat sur liste de test n'est généralement que du bruit** : n'agissez que sur une tendance répétée sur plusieurs envois.
5. **Le coût.** Les services professionnels de listes de test sont une dépense récurrente. Tester avec vos propres comptes personnels supprime le coût mais conserve toutes les autres limites (petit échantillon, conditions non représentatives, aucune vraie dynamique de réputation).

Règle pratique : utilisez les listes de test comme **signal de direction et contrôle qualité**, examinez-les séparément pour chaque fournisseur de messagerie, et recoupez-les avec des données réelles (rapports agrégés DMARC, taux de plaintes, journaux de rebonds, statut sur les listes de blocage) avant de changer quoi que ce soit.

## Méthode 2 : les panels d'abonnés

Un **panel** est un ensemble de vraies boîtes aux lettres, appartenant à de vraies personnes qui acceptent d'être suivies par le fournisseur de la mesure. Validity (anciennement Return Path) appelle son panel « Consumer Network », et d'autres construisent des équivalents. Quand vos messages atteignent un panéliste, le fournisseur observe non seulement le placement mais aussi le **comportement** : boîte de réception ou spam, lecture ou non du message, signalement comme spam, et d'autres actions de l'utilisateur.

Les données de panel peuvent donc révéler **les facteurs et les seuils de filtrage fondés sur l'engagement que les listes de test, non interactives, ne peuvent pas voir**, c'est-à-dire précisément les signaux qui déterminent le placement chez les grands fournisseurs.

### Où les panels se trompent

Leurs faiblesses sont le miroir de celles des listes de test :

1. **Une couverture étroite des fournisseurs.** Un panel ne mesure que les fournisseurs chez lesquels il a assez de panélistes, historiquement les grands webmails grand public (Google, Outlook.com de Microsoft, Yahoo et, dans les données de 2018, AOL). Il dit peu de chose des passerelles d'entreprise ou entre entreprises (B2B), des fournisseurs régionaux et de la longue traîne que les listes de test atteignent.
2. **Aucune visibilité sur les messages manquants ou bloqués, d'où un chiffre optimiste.** La mesure par panel ne voit que les messages acceptés par la passerelle et livrés dans la boîte d'un panéliste. Les messages bloqués ou supprimés en amont n'entrent jamais dans le dénominateur, si bien que **les taux de placement en boîte de réception issus des panels sont structurellement plus élevés que ceux des listes de test.** L'illustration de Validity elle-même en 2018 (ci-dessous) montre l'ampleur de cet écart.
3. **Le biais de composition du panel.** Les résultats reflètent la démographie, la répartition des fournisseurs et le comportement du panel, qui peuvent ne pas correspondre à votre audience.

### L'écart entre liste de test et panel, chiffré (daté : 2018)

> Note sur les sources : les chiffres ci-dessous viennent du **Return Path (aujourd'hui Validity) 2018 Deliverability Benchmark**, qui a échantillonné plus de 2 milliards de messages promotionnels envoyés de juillet 2017 à juin 2018 chez plus de 140 fournisseurs de messagerie. Les ventilations des données de panel et du secteur portent sur environ 17 000 expéditeurs, 2 millions de panélistes et 2 milliards de messages envoyés à Microsoft, Google, Yahoo et AOL. **Les taux absolus sont anciens et ont été dépassés** par des études plus récentes (voir [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation) pour les chiffres actuels de Litmus, et [Valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/reference/valeurs-de-reference-chiffrees-de-la-delivrabilite) pour les taux actuels de boîte de réception, de spam et de messages manquants mesurés par Validity sur liste de test, par fournisseur, région et secteur). Ils ne sont cités ici que parce que le rapport met les deux méthodes côte à côte sur les mêmes messages. La relation entre les méthodes est la leçon qui dure.

La même période de 2018, la même population d'expéditeurs, deux méthodes :

| Indicateur | Données de panel | Données de liste de test |
|---|---|---|
| Placement global en boîte de réception | **91 %** | **85 %** |
| Taux de placement en dossier spam | 9 % | 6 % |
| Taux de messages manquants ou bloqués | **N/A** (non mesurable) | **10 %** |

Les 91 % du panel et les 85 % de la liste de test décrivent les mêmes messages. L'écart de 6 points correspond presque entièrement aux quelque 10 % de messages que les listes de test ont comptés comme manquants ou bloqués et que le panel n'a jamais vus. Selon Validity elle-même : « les taux de placement en boîte de réception calculés à partir des données de panel ne tiennent pas compte des emails manquants ou bloqués, si bien que le taux obtenu sera toujours plus élevé » (*inbox placement rates calculated with panel data do not factor in missing/blocked emails, so the resulting inbox placement rate will always be higher*). **Chaque fois que vous comparez deux chiffres de placement, demandez-vous d'abord quelle méthode a produit chacun.** Un « 91 % » et un « 85 % » peuvent être la même réalité mesurée de deux façons, et non une vraie différence.

Une seconde ventilation de panel, datée mais parlante, mérite d'être conservée. En 2018, le placement chez les quatre principaux fournisseurs atteignait en moyenne 96 % chez AOL, 92 % chez Gmail, 92 % chez Yahoo et **75 % chez Outlook**. Microsoft était déjà en 2018 le grand fournisseur de messagerie le plus difficile à atteindre, ce qui concorde avec le constat, toujours présent dans les études actuelles, que Microsoft est le plus strict.

## Méthode 3 : la télémétrie par pixel ou taux de lecture comme indicateur indirect du placement

Votre propre suivi des ouvertures ne mesure pas le placement, mais son effondrement est un signal de placement, car un message doit atteindre la boîte avant qu'un pixel puisse se déclencher. C'est la méthode la moins chère, la plus large et la plus réactive (elle couvre en temps réel tous les fournisseurs auxquels vous envoyez réellement), et aussi la plus contaminée.

[Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure) explique le fonctionnement complet. Voici les points qui comptent quand vous utilisez les ouvertures comme indicateur indirect du placement :

- **Apple MPP déclenche le pixel lors du préchargement côté réception**, pour presque chaque message livré à un utilisateur d'Apple Mail, engagé ou non. Cela rend les ouvertures individuelles presque sans valeur comme signe d'attention, mais fait du taux d'ouverture MPP agrégé un **indicateur indirect de fait de la livraison en boîte de réception pour le segment Apple**, car une ouverture MPP exige tout de même que le message ait atteint la boîte.
- **Une baisse soudaine du taux d'ouverture agrégé chez un fournisseur, alors que les autres restent stables**, est le signe classique d'un classement en spam chez ce fournisseur. C'est l'alerte précoce la plus sensible dont disposent la plupart des expéditeurs, justement parce qu'elle porte sur toute votre audience réelle et non sur un échantillon.
- Elle ne distingue pas la boîte de réception de l'onglet Promotions, ne voit pas directement les messages manquants, et est polluée par les ouvertures des scanners et des proxys. Elle vous dit si le placement a bougé, pas vers où. Confirmez la direction et le lieu avec un test sur liste de test ou un tableau de bord.

## Méthode 4 : les tableaux de bord des fournisseurs de messagerie et leurs angles morts

Les tableaux de bord des fournisseurs ([Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools), [Microsoft SNDS et JMRP](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp), les flux de Yahoo) sont les seules « données réelles » qui viennent directement du serveur de réception : le verdict du fournisseur lui-même sur votre réputation, votre taux de plaintes pour spam et vos taux de réussite de l'authentification. Ils font autorité là où ils publient quelque chose. Leur faiblesse n'est pas le biais mais **l'absence** : le tableau de bord reste vide précisément quand un expéditeur petit ou nouveau a le plus besoin d'une réponse.

### Les situations sans données de Google Postmaster Tools

Google Postmaster Tools (GPT) n'affiche rien, ou affiche des trous dans un graphique par ailleurs rempli, pour plusieurs raisons distinctes. Il est important de les distinguer, car « aucune donnée » est régulièrement pris à tort pour « un problème » :

| Cause des données manquantes ou vides | Ce qui se passe réellement |
|---|---|
| **Sous le plancher de volume lié à la confidentialité** | Gmail masque les données de réputation et de tableau de bord lorsqu'un domaine ou une IP a trop peu de trafic qualifié, pour protéger la vie privée des destinataires. C'est la cause la plus courante, et ce n'est pas une anomalie. |
| **Seul @gmail.com compte** | Le volume est mesuré **uniquement sur les destinataires Gmail personnels**. Les boîtes Google Workspace et professionnelles, et les autres domaines, ne comptent pas pour le seuil. Un expéditeur B2B « à gros volume » peut être sous le seuil chez Gmail. |
| **Jours à faible volume omis** | Les journées à faible volume sont écartées une à une par souci de confidentialité, ce qui crée des trous dans une série par ailleurs remplie. Un trou signifie « trop peu ce jour-là », pas zéro. |
| **Décalage de périmètre entre domaine et sous-domaine** | Les données sont rattachées au domaine d'authentification vérifié exact, et le domaine vérifié doit correspondre au **domaine de signature DKIM `d=`**. Le trafic du domaine racine et celui des sous-domaines sont publiés séparément, si bien que vérifier le mauvais domaine affiche un tableau vide. |
| **Interruptions de publication sans rattrapage** | Il est arrivé que les données de réputation de Google s'interrompent puis reviennent **sans que les dates manquantes soient rattrapées**. C'est une panne côté Google, pas un problème lié à vos envois. |
| **Retrait des graphiques de réputation** | Google a retiré les anciens graphiques de réputation High, Medium, Low et Bad vers le **30 septembre 2025**, et les vues historiques de réputation sont devenues peu fiables, quel que soit votre volume. |

### Le volume nécessaire, et la vitesse d'apparition des données

Google ne publie **aucun minimum fixe**. Ces seuils ont été observés par des praticiens (Suped), et tous comptent des **destinataires Gmail personnels par jour** :

| Volume quotidien vers Gmail | Comportement du tableau de bord |
|---|---|
| **Moins d'environ 100 par jour** | Clairsemé : souvent aucune donnée, beaucoup de jours manquants |
| **Environ 100 à 300 par jour** | Intermittent : certains tableaux de bord se remplissent, mais les variations quotidiennes sont peu marquées |
| **Plusieurs centaines par jour** | Données de tendance généralement utiles et régulières |
| **5 000 et plus par jour** | C'est la limite des expéditeurs de gros volumes dans les [exigences de Gmail](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs), un seuil de conformité et **non** le seuil d'affichage. Vous obtenez des données utiles bien en dessous |

Prévoyez **plusieurs centaines de messages par jour vers des adresses Gmail personnelles** pour des tableaux de bord fiables. Une fois le volume suffisant, les délais sont les suivants :

| Signal | Délai avant apparition ou mise à jour |
|---|---|
| Premières données après la vérification d'un nouveau domaine | Environ 24 à 48 heures |
| Indicateur de taux de spam | Environ 1 à 2 jours |
| Tendance de la réputation du domaine | Environ 1 à 2 jours ou plus |
| Statut de conformité | Jusqu'à **7 jours** (calcul glissant) |

Selon Google, les données du tableau de bord sont « généralement mises à jour dans les 24 heures, mais cela peut prendre plus de temps » (*usually updated within 24 hours, but can take longer*). Il n'y a **aucune donnée rétroactive**. Un domaine inscrit après un incident n'a aucun historique pour la période de l'incident, c'est pourquoi chaque domaine d'authentification devrait être inscrit avant que des problèmes surviennent.

L'angle mort général : **tout tableau de bord de fournisseur est un instrument limité au courrier grand public, au-dessus d'un plancher, et en retard.** Sous le plancher, et pour les destinations B2B ou d'entreprise qui ne publient aucun tableau de bord, vous revenez aux listes de test et aux panels.

## Quand se fier à quelle méthode

| La question à laquelle vous répondez | Méthode à utiliser | Pourquoi |
|---|---|---|
| « Cette campagne s'affichera-t-elle et s'authentifiera-t-elle correctement avant que je l'envoie ? » | Liste de test | Les contrôles qualité avant envoi sont exactement ce que font les listes de test, et l'engagement n'a aucune importance pour une vérification d'affichage ou d'authentification |
| « Chez quels fournisseurs mes messages sont-ils classés en spam en ce moment ? » | Panel et liste de test | La liste de test pour une large couverture, messages manquants compris ; le panel pour les grands fournisseurs pilotés par l'engagement |
| « Le placement vient-il de bouger pour mon audience réelle ? » | Tendance du pixel ou du taux de lecture | La plus large et la plus réactive ; une baisse du taux d'ouverture chez un fournisseur est l'alerte la plus précoce |
| « Que pense réellement Gmail de ma réputation ? » | Google Postmaster Tools | Le verdict du serveur de réception lui-même, qui fait autorité là où il publie |
| « Est-ce que j'arrive en boîte de réception avec un programme nouveau, qui démarre à froid ? » | Liste de test | Les panels et les tableaux de bord ont besoin d'un volume réel et engagé que vous n'avez pas encore |
| « Quelle est l'ampleur de mes messages manquants ou bloqués ? » | Liste de test | La seule méthode qui mesure les messages acceptés puis supprimés, ou bloqués à la passerelle |
| « Quel est mon vrai taux de plaintes chez Microsoft ? » | SNDS et JMRP | Les plaintes publiées par le fournisseur valent mieux que toute déduction |
| « Quel est mon taux de placement en boîte de réception derrière une passerelle B2B d'entreprise ? » | Liste de test (avec prudence) | Aucun panel ni tableau de bord ne couvre ces destinations ; les listes de test sont le seul éclairage, et il est mince |

Deux règles découlent de l'ensemble du tableau :

- **Ne comparez jamais un chiffre de placement à un autre sans connaître les deux méthodes.** Les taux des panels sont plus élevés que ceux des listes de test par construction, car le panel exclut les messages bloqués et manquants. Un fournisseur de mesure qui annonce un chiffre plus élevé utilise peut-être simplement des données de panel.
- **Recoupez avant d'agir.** Les listes de test et les tendances du pixel font apparaître des pistes ; les rapports DMARC, les taux de plaintes, les journaux de rebonds, le statut sur les listes de blocage et les tableaux de bord des fournisseurs les confirment. Un mauvais résultat sur liste de test, ou une baisse des ouvertures sur une journée, n'est que du bruit tant qu'une seconde méthode ne va pas dans le même sens.

## Voir aussi

- [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation), y compris la pile de surveillance qu'alimentent ces méthodes et les taux actuels de placement en boîte de réception des études de référence
- [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure)
- [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools)
- [Microsoft SNDS et JMRP](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp)
- [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite), les seuils à l'aune desquels ces mesures sont jugées
- [Outils de test de la délivrabilité](https://emailmarketing.net/fr/apprendre/reference/outils-de-test-et-de-diagnostic-de-la-delivrabilite), y compris les fournisseurs de tests sur liste de test et de placement en boîte de réception

# Pratiques d'infrastructure d'envoi

> Adresses IP dédiées ou partagées, stratégie de sous-domaines, chauffe de domaine, hygiène de l'adresse From, raccordement des feedback loops, outils de surveillance de la réputation et cadre de dépannage.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi

Avant de dimensionner un parc d'adresses IP, vous devez décider s'il vous faut vraiment une adresse IP dédiée, comment bâtir la réputation de vos domaines, et comment surveiller les deux. Les guides des ESP Postmark, AWS SES et Twilio SendGrid s'accordent sur la plupart des réponses, rassemblées ci-dessous. Pour dimensionner et segmenter les parcs d'adresses IP, voir [Allocation de base des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip).

## Adresses IP dédiées ou partagées

[Allocation de base des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip) explique comment dimensionner les parcs d'adresses IP dédiées. La question qui se pose d'abord est de savoir s'il faut une adresse IP dédiée.

| Aspect | Adresse IP dédiée | Adresse IP partagée |
|---|---|---|
| Impact des autres expéditeurs | Aucun : la réputation vous appartient entièrement | Les autres expéditeurs du pool peuvent améliorer ou abîmer votre situation |
| Exigence de volume | Un volume élevé et soutenu est indispensable | Tout volume |
| Chauffe | Obligatoire, sur des semaines ou des mois | Aucune ; envoi immédiat |
| Coût | Élevé | Plus faible |
| Gestion de la réputation | À votre charge | Gérée par le fournisseur |
| Tolérance aux erreurs | Faible : chaque erreur retombe sur votre réputation | Plus élevée : le volume du pool absorbe les erreurs |

<a id="dedicated-ip-volume-floors-canonical"></a>

### Planchers de volume pour une adresse IP dédiée

« Quel volume justifie une adresse IP dédiée ? » n'a pas de réponse unique, car les chiffres publiés mesurent **des choses différentes**. Les planchers et les minimums des éditeurs ci-dessous varient dans un rapport d'environ 5–10x, mais ils ne se contredisent pas : ils répondent à des questions différentes. Les deux planchers ci-dessous sont les chiffres de référence ; les autres recommandations sur les adresses IP dédiées y renvoient.

| Plancher | Chiffre | Ce qu'il mesure |
|---|---|---|
| Plancher d'isolement du courrier transactionnel | ~**1 000 messages/jour** | Le volume bas à partir duquel isoler le courrier transactionnel sur sa propre adresse IP dédiée reste lisible pour les serveurs de réception (GreenArrow, [Segmentation avancée des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip)). Le courrier transactionnel est isolé parce qu'il est très pertinent, même sous le plancher statistique général. |
| Plancher statistique général pour chaque adresse IP | **40 000 messages/semaine** (~5 700/jour) | Le volume soutenu minimal dont toute adresse IP a besoin pour que les fournisseurs de messagerie recueillent des données d'engagement et de plaintes statistiquement significatives (GreenArrow, [Allocation de base des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip)). En dessous, une adresse IP n'envoie pas assez pour que sa réputation se stabilise. |

**Seuils des éditeurs pour les adresses IP dédiées (règles maison).** Les ESP publient leurs propres minimums. Ceux-ci reflètent autant les gammes de produits et les coûts de support de chaque éditeur que les statistiques des serveurs de réception. Selon le modèle de l'éditeur, ils se situent au-dessus ou en dessous des deux planchers, et ils ne se contredisent pas :

| Éditeur | Seuil | Présentation |
|---|---|---|
| AWS SES | « quelques centaines par jour » (*a few hundred per day*) pour attribuer la première adresse IP dédiée ; en dessous, les clients sont orientés vers les adresses IP partagées | La barre la plus basse. SES renvoie automatiquement les adresses IP dédiées à faible volume vers le pool partagé (voir [Architecture multi-tenant](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture)) |
| Twilio SendGrid | ~**50 000/mois** (~1 650/jour) recommandés | En dessous, un pool partagé bien géré est conseillé |
| Mailgun | ≥ **100 000/mois** (~3 300/jour) recommandés | Voir [Rétablissement après un incident de réputation](https://emailmarketing.net/fr/apprendre/operations/retablissement-apres-un-incident-de-reputation) |
| Postmark | ~**300 000/mois** (~10 000/jour) pour entretenir correctement une adresse IP dédiée | La barre la plus haute |

En résumé, une adresse IP dédiée au courrier transactionnel peut se justifier dès ~1 000/jour. Toute adresse IP qui porte un flux général ou de masse a besoin de ~40 000/semaine avant que les serveurs de réception puissent lire sa réputation de façon statistique. Les minimums des éditeurs sont des règles maison commerciales qui s'ajoutent aux deux.

Postmark ajoute des mises en garde. Une adresse IP dédiée n'est **pas une solution miracle** : pour les expéditeurs sous la barre de volume, elle peut nuire à la délivrabilité, et « une IP dédiée est un moyen pour les ESP de réduire leurs coûts de support » (*a dedicated IP is a way for ESPs to lower their support overhead*) autant qu'une fonction de livraison. Les adresses IP dédiées exigent aussi **un volume régulier et prévisible**, et les pics soudains sont signalés comme suspects. Le filtrage moderne accorde de plus en plus de poids à la **réputation du domaine** par rapport à la réputation de l'adresse IP.

## Réputation du domaine et stratégie de sous-domaines

La **réputation du domaine** est l'opinion que les serveurs de réception (fournisseurs de messagerie et services antispam) ont de votre domaine. Contrairement à la réputation d'IP, elle est **portable**. Elle suit le domaine d'un système d'envoi et d'un fournisseur à l'autre, si bien qu'un domaine qui a un passé de spam emporte ce passé vers toute nouvelle infrastructure. Une mauvaise réputation de domaine peut pénaliser jusqu'au courrier transactionnel (Postmark).

La réputation de l'adresse IP et celle du domaine sont évaluées séparément, mais elles interagissent : une mauvaise réputation d'IP peut nuire à un domaine qui envoie par cette adresse IP, même quand le dossier du domaine lui-même est bon.

### Séparation par sous-domaines

AWS SES et Postmark recommandent tous deux de séparer les flux de messages par **sous-domaine**. C'est l'équivalent, au niveau du domaine, de la séparation des adresses IP par réputation décrite dans [Segmentation avancée des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip) :

- Envoyez le marketing depuis un sous-domaine comme `marketing.example.com` et le courrier transactionnel depuis `orders.example.com`, plutôt que tout depuis `example.com` (AWS SES).
- Les sous-domaines développent des **réputations indépendantes** (par exemple `notify.example.com` et `newsletter.example.com`), si bien qu'un incident marketing, comme une adresse piège touchée ou le déclenchement d'un filtre de contenu, ne fait pas tomber la livraison transactionnelle. Ils ne s'influencent qu'indirectement (Postmark).
- Surveillez les **domaines sosies** (par exemple `company.com` et `company-mail.com`). Leur réputation et les abus qui les concernent peuvent influer sur la façon dont le courrier de votre marque est jugé (SendGrid).

### Les quatre domaines de chaque message (Postmark)

1. **Domaine de signature DKIM (`d=`)** : signez avec votre propre domaine, et non avec un domaine par défaut de l'éditeur, pour que la réputation se construise à votre profit.
2. **Domaine du Return-Path** : utilisez un Return-Path personnalisé (CNAME) qui correspond à votre domaine From ou qui est aligné sur lui. Il est indispensable à l'alignement SPF dans le cadre de [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).
3. **Domaine des adresses From et de réponse** : il doit identifier clairement la marque. Publiez-y une politique DMARC.
4. **Domaines des URL du contenu** : les liens tiers ne nuisent à la livraison que lorsque les domaines liés ont été vus en train d'agir de façon trompeuse ou malveillante. Ne liez malgré tout que des sites de confiance que vous contrôlez (SendGrid).

## Hygiène de l'adresse From (AWS SES)

- Certains fournisseurs d'accès rattachent une réputation à l'**adresse From** elle-même, et c'est aussi la première impression du destinataire.
- N'envoyez jamais de courrier de masse depuis une adresse chez un fournisseur de messagerie (par exemple `sender@hotmail.com`). De gros volumes depuis une adresse de messagerie grand public sont traités avec méfiance. Envoyez depuis un domaine qui vous appartient.
- **Évitez les adresses `no-reply@`** en adresse From ou Reply-To. Elles signalent que vous ne voulez pas de retour des destinataires, alors que les réponses sont un signal d'engagement positif.
- Tenez à jour l'enregistrement WHOIS du domaine. Un enregistrement honnête et actuel est un signe de légitimité.

## Chauffe de domaine

Les nouveaux domaines et sous-domaines ont besoin d'une chauffe tout comme les nouvelles adresses IP (voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)), et le domaine conserve son historique plus longtemps. Le calendrier de Postmark donne des volumes **pour chaque fournisseur de réception**, par exemple pour Gmail, pour Yahoo et pour Microsoft :

| Période | Volume quotidien par fournisseur |
|---|---|
| Jours 1–2 | 50–100 |
| Jours 3–4 | 200 (si les indicateurs sont sains) |
| Jours 5–7 | 400 |
| Jours 8–10 | 600–800 |
| Jours 11–14 | 1 000–1 500 |
| Jours 15–17 | 2 000–3 000 |
| Jours 18–21 | 4 000–5 000 |
| Jours 22–25 | 7 500–10 000 |
| Jours 26–30 | Volume cible complet |

Réglez la progression en doublant à peu près le volume chaque jour au début. À des volumes importants, ralentissez à des hausses quotidiennes de 20–50 % (30–50 % par jour pendant les semaines 2–3, puis 20–30 % par jour). Comptez **3–6 semaines** pour obtenir une réputation établie et une livraison fiable à plein volume. Aucun calendrier unique ne convient aux seuils de tous les fournisseurs.

Le Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) donne un chiffre différent. Ses *Sender Best Common Practices* (version 4.0, août 2026, section 2.5) suggèrent de considérer **6 semaines** comme une durée moyenne de chauffe d'un domaine, ce qui se situe en haut de la fourchette ci-dessus. Les deux chiffres répondent à des questions légèrement différentes : la fourchette ci-dessus correspond au moment où Postmark prévoit une livraison fiable à plein volume, et le chiffre du M3AAWG à une durée typique pour l'ensemble de la chauffe. Le M3AAWG ajoute ces points :

- Chauffez aussi un **nouveau sous-domaine**, par précaution, même lorsque le domaine organisationnel a déjà une réputation établie. Un domaine sans historique d'envoi est traité avec la même prudence qu'un domaine dont l'historique est mauvais.
- Répartissez les messages de chaque jour sur la journée au lieu d'envoyer le lot d'un coup, et envoyez les campagnes selon un calendrier régulier jusqu'à ce que le domaine soit chauffé.
- Surveillez les journaux SMTP pour repérer les reports de remise et les rebonds, et ralentissez si les reports de remise augmentent brusquement. Surveillez les pics de désabonnements et de plaintes. Un fort pic d'ouvertures ou de clics peut signifier que des équipements de sécurité analysent vos emails, et une baisse peut signifier qu'ils arrivent dans le courrier indésirable.
- Le M3AAWG ne recommande pas la chauffe artificielle, et avertit qu'elle peut être contraire à la loi.

Pendant la chauffe, commencez par vos destinataires les plus engagés et élargissez l'audience par paliers (comparez avec la règle d'envoyer d'abord aux plus engagés dans [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)) :

| Jours | Audience |
|---|---|
| 1–4 | Les plus engagés (ont déjà ouvert **et** cliqué) |
| 5–7 | Ont ouvert au cours des 60 derniers jours |
| 8–10 | Ont ouvert au cours des 90 derniers jours |
| 11–14 | Ont interagi au cours des 120 derniers jours |
| 15+ | Engagement de moins en moins récent ; campagnes de réengagement en dernier |

La règle la plus importante : n'augmentez jamais le volume avant d'avoir examiné, pour chaque fournisseur, les indicateurs d'engagement et de rebonds de l'envoi précédent. Si les indicateurs se dégradent, réduisez le volume de 25–30 % jusqu'à ce qu'ils redeviennent normaux. [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite) présente les déclencheurs précis de mesures correctives. Mieux vaut prendre une ou deux semaines de plus que de se précipiter et d'abîmer la délivrabilité à long terme.

## Feedback loops et raccordement des notifications

Une **feedback loop (FBL)** est un canal par lequel un fournisseur de messagerie transmet à l'expéditeur les plaintes pour spam des destinataires. Elle a ces exigences opérationnelles :

- Inscrivez-vous aux FBL des fournisseurs auxquels vous envoyez (seuls certains en proposent). Word to the Wise tient une liste de référence des pages d'inscription aux FBL de chaque fournisseur d'accès (Postmark). Les plateformes d'ESP les mettent généralement en place à l'avance et transmettent automatiquement les plaintes, comme le fait AWS SES.
- Les notifications de plainte masquent l'adresse de la personne qui s'est plainte. Intégrez des en-têtes X traçables ou des identifiants dans le corps, pour pouvoir rattacher chaque plainte à une adresse et à une campagne (AWS SES).
- La boîte qui reçoit les notifications de rebonds et de plaintes doit accepter les messages de façon fiable, et ne doit pas filtrer les notifications comme du spam (AWS SES). Voir [Hygiène de base de données](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil) pour savoir quoi faire de ces données.
- **Gmail** fournit les données de plaintes par Postmaster Tools plutôt que par une FBL qui signale chaque message. Étiquetez les campagnes avec des **identifiants de feedback loop** uniques pour voir les taux de plaintes ventilés par campagne ou par expéditeur, et pour isoler rapidement le contenu problématique (SendGrid).

## Outils de surveillance de la réputation

| Outil | Ce qu'il apporte à un expéditeur |
|---|---|
| Google Postmaster Tools | La réputation du domaine et des adresses IP chez Gmail, notée **Bad / Low / Medium(Fair) / High** (Bad signifie que le courrier est presque toujours rejeté ou classé en spam ; High signifie qu'il est rarement filtré) ; un tableau de bord du taux de spam (à surveiller chaque jour) ; les données des identifiants de FBL |
| Outils postmaster de Microsoft (Outlook.com) et SNDS | Les données de réputation et de plaintes pour les services de Microsoft |
| Postmaster de Yahoo | Les données de livraison et de plaintes chez Yahoo |
| Senderscore.org | Un score propriétaire de 0–100 de la performance globale d'une adresse IP |
| Cisco Talos Intelligence | La réputation des adresses IP et des domaines, notée Good / Neutral / Poor, avec un historique de volume |
| MXToolbox | La vérification du statut sur les listes de blocage pour les adresses IP et les domaines, plus des vérifications de santé du DNS et des domaines ; SendGrid le qualifie de « meilleure option de recherche gratuite » (*the best free lookup option*) |

Vérifiez aussi que des enregistrements de **DNS inverse (PTR)** existent et concordent pour chaque adresse IP d'envoi, ce qui est une exigence de Google et de Yahoo envers les expéditeurs de gros volumes (SendGrid). Validez l'authentification (SPF, DKIM et DMARC) avec des outils de vérification publics.

### Listes de blocage (denylists)

- Les fournisseurs et les services antispam inscrivent les adresses IP et les domaines qui présentent beaucoup d'adresses pièges touchées, un volume élevé de plaintes, ou les deux (SendGrid).
- L'impact varie beaucoup. Certaines listes influencent fortement les grands fournisseurs ; beaucoup ne sont que du bruit.
- Si vous êtes inscrit sur une grande liste de blocage, **arrêtez immédiatement d'envoyer**, suivez la procédure de retrait de liste, puis reprenez avec un volume nettement réduit (Postmark).
- Méfiez-vous des listes payantes qui facturent le retrait au lieu d'évaluer le comportement de l'expéditeur (SendGrid).

## Cadre de dépannage (Postmark)

Quand le placement ou la livraison baisse, diagnostiquez ces cinq domaines, dans l'ordre :

1. **Authentification** : vérifiez SPF, DKIM, l'alignement du Return-Path personnalisé et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) avec des outils de validation publics.
2. **Contenu** : évaluez le message avec un outil de vérification fondé sur SpamAssassin, et faites des tests sur liste de test. Si un changement de modèle a précédé la baisse, annulez les modifications une à une (voir les règles de contenu dans [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite)).
3. **Engagement** : comparez les taux de rebonds, de plaintes et d'ouverture aux seuils ; placez les rebonds définitifs en suppression ; évitez `noreply@`.
4. **Réputation** : vérifiez la réputation du domaine et des adresses IP dans les outils postmaster et les recherches sur les listes de blocage ci-dessus.
5. **Infrastructure** : confirmez les enregistrements rDNS (PTR), les inscriptions aux FBL et la santé du pool d'adresses IP, et vérifiez que le logiciel d'envoi signe correctement avec DKIM.

Il n'y a pas de solution miracle. La délivrabilité exige une surveillance continue de ces cinq domaines, fondée sur des listes propres et un engagement fort.

## Voir aussi

- [Allocation de base des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip) et [Segmentation avancée des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip)
- [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip), l'équivalent au niveau de l'adresse IP de la chauffe de domaine
- [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite)
- [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil), pour exploiter les données des feedback loops et des rebonds

# Procédures de dépannage de la livraison

> Des procédures de décision guidées par les symptômes (symptôme → hypothèse → test discriminant → correction) pour les quatre modes d'échec de la livraison — non livré, retardé, en spam, introuvable —, avec des branches par fournisseur et une bibliothèque de scénarios.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/procedures-de-depannage-de-la-livraison

Quand un client ou un tableau de bord signale un problème de livraison, partez du symptôme et lancez le test qui distingue les causes probables. Chaque procédure ci-dessous donne ce test et indique où mène chaque résultat.

Une liste de contrôle vous dit ce qui est vrai en matière de réputation, de contenu ou d'infrastructure. Le diagnostic fonctionne autrement : vous réduisez les causes possibles un test à la fois. Les procédures sont écrites pour qu'une personne ou un agent automatisé puisse en suivre une depuis le début et s'arrêter à la première branche qui correspond.

Les procédures renvoient à des contenus plus détaillés : les catalogues de codes d'erreur de [Gmail](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/depannage-gmail) et de [Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/codes-d-erreur-smtp-de-yahoo) et les [codes d'état étendus](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp), la [pile de surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation), le [fonctionnement interne du filtrage de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/fonctionnement-interne-du-filtrage-de-microsoft) et la [carte des canaux d'escalade](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-et-de-levee-des-restrictions). Quand le diagnostic révèle une atteinte systémique, [le rétablissement après un incident de réputation](https://emailmarketing.net/fr/apprendre/operations/retablissement-apres-un-incident-de-reputation) explique la suite.

## Étape 0 : le message a-t-il été accepté ?

Tout problème de livraison relève de l'une de deux catégories très différentes, et la première tâche consiste toujours à établir laquelle. N'appliquez pas une procédure de placement en spam à un message qui n'a jamais reçu de 250. N'appliquez pas une procédure de rebond à un message qui a été accepté puis classé en courrier indésirable.

| | **Non accepté** (échec du transfert) | **Accepté** (transfert réussi) |
|---|---|---|
| Preuve SMTP | 4xx (reporté, nouvelle tentative prévue) ou 5xx (rebond, abandon) | `250 ... OK` enregistré dans vos journaux ou votre MTA |
| Ce que voit le destinataire | Rien, ou l'expéditeur reçoit un rapport de non-remise (NDR) ou un rebond | Le message se trouve quelque part côté destinataire |
| Événement Postmark | `Bounced`, `Delayed`, `Queued`, `Processed` | `Delivered` |
| Procédure à suivre | **A** (non livré) ou **B** (retardé) | **C** (en spam) ou **D** (introuvable) |

**Comment établir l'acceptation :**
- **Dans les journaux de votre propre MTA ou ESP :** lisez la dernière réponse SMTP pour ce destinataire. Un `250` signifie que le serveur de réception a pris la responsabilité du message. Toute autre réponse signifie que ce n'est pas le cas.
- **Expéditeurs par API (le modèle Postmark) :** un événement `Delivered` signifie que le serveur distant a renvoyé `250 2.0.0 OK`. `Delivered` signifie l'acceptation, et non le placement en boîte de réception : le message peut encore être classé en spam ou supprimé plus tard. `Processed` signifie que le message a été remis au MTA d'envoi et attend le verdict du serveur distant. `Queued` signifie que la plateforme a accepté le message mais ne l'a pas encore envoyé. Vérifiez si le compte ou le flux est en pause pour des taux de rebonds ou de plaintes élevés, et consultez la page d'état de la plateforme.
- **Microsoft 365 côté destinataire :** lancez un **suivi des messages** (message trace) dans le Centre d'administration Exchange, puis Flux de messagerie, puis Suivi des messages. L'état `Delivered` dans la colonne STATUS signifie que le message a été accepté. Pour tout autre état, la vue Details donne une explication « How to fix it ». Les données de suivi apparaissent de 10 min à 1 h après l'envoi. Les suivis de plus de 7 jours ne sont disponibles qu'en CSV et peuvent mettre jusqu'à une heure à être générés.

Si vous ne trouvez pas du tout le message dans vos journaux, le problème s'est produit avant la livraison : l'envoi n'a jamais eu lieu. Les raisons courantes sont un flux en pause, une erreur d'API, une adresse présente dans la liste de suppression, ou un filtre ou une règle côté expéditeur. Vérifiez le code de réponse de la plateforme d'envoi elle-même avant d'incriminer le serveur de réception.

---

## Procédure A : message non livré (rebond ou rejet, 5xx)

**Symptôme :** les journaux de l'expéditeur montrent un échec permanent, ou l'expéditeur a reçu un NDR. Le serveur de réception a refusé le message purement et simplement.

Le signal qui distingue les causes est le **texte du rejet**, et non le seul code numérique. Lisez la réponse SMTP complète et le code d'état étendu ([classe RFC 3463](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp) : `5.1.x` pour l'adressage, `5.7.x` pour la politique ou la sécurité). Orientez selon ce que dit le texte :

| Le rejet mentionne… | Hypothèse | Test qui distingue les causes | Correction |
|---|---|---|---|
| "user unknown", "mailbox does not exist", `5.1.1`, `550 5.1.1` | Destinataire invalide | Une seule adresse ou beaucoup ? Une seule oriente vers une faute de frappe ou une adresse abandonnée. Beaucoup orientent vers un problème de qualité de la liste | Placez l'adresse en suppression (un rebond définitif implique une suppression permanente). S'il y en a beaucoup, auditez la source d'acquisition et voir [hygiène de base de données](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil) |
| "quota exceeded", "mailbox full", "out of storage", `5.2.2` | La boîte du destinataire est pleine | Un seul destinataire, et c'est passager | Traitez-le comme un échec temporaire : réessayez, puis placez en suppression après des échecs répétés. Votre réputation n'est pas en cause |
| Cite une **liste de blocage** (Spamhaus, Barracuda, SpamCop, SURBL) ou indique "listed in DNSBL" | L'adresse IP ou le domaine est inscrit sur une liste de blocage | Une interrogation DNSBL sur chaque adresse IP et chaque domaine d'envoi | Trouvez d'abord la cause profonde, puis demandez le retrait. Voir [Listes de blocage DNS et zones Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus) et la [procédure de retrait de liste](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation#blocklist-delisting-workflow). Ne demandez pas le retrait avant d'avoir corrigé les pratiques |
| "banned sending IP", "access denied", vocabulaire de réputation, `5.7.x` | Le fournisseur vous a bloqué pour réputation | Un seul fournisseur ou tous ? Un seul fournisseur avec un tableau de bord au rouge oriente vers la réputation chez ce fournisseur | Suivez la branche du fournisseur ci-dessous, et escaladez par le [canal du fournisseur](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-et-de-levee-des-restrictions) |
| Mentionne le contenu, les liens ou les pièces jointes, "message content rejected", ou "spam" dans un 5xx | Un filtre de contenu a bloqué le message | Faites un test sur liste de test ou une vérification antispam du message exact, et retirez les éléments un à un | Corrigez le contenu ([contenu et design](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite)) : supprimez les raccourcisseurs d'URL et corrigez le HTML |
| Vocabulaire d'authentification : échec SPF, DKIM ou DMARC, `5.7.1`, `5.7.26`, "unauthenticated" | Échec d'authentification | Examinez `Authentication-Results` et vérifiez la politique DMARC | Corrigez l'alignement ([DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)). L'authentification est obligatoire pour les expéditeurs de gros volumes chez Gmail et Yahoo |
| Erreur HELO ou EHLO, `501 5.5.4`, "invalid HELO", adresse IP non routable | Identité de connexion ou DNS inverse (rDNS) | Vérifiez qu'un enregistrement PTR existe et concorde, et que le HELO donne un nom de domaine pleinement qualifié (FQDN), et non une adresse IP privée | Corrigez le rDNS et le HELO. Les serveurs de réception, dont Microsoft, rejettent le courrier qui annonce `10.x`, `172.16–31.x` ou `192.168.x` |
| "too many messages", ou vocabulaire de débit ou de connexion (`421`, `4.7.x`, qui est techniquement un report de remise) | Limitation de débit | Voir la procédure B | Ralentissez. Voir [réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta) |

**Branches 5xx propres à chaque fournisseur** (pour les rejets de réputation et de contenu du tableau ci-dessus) :
- **Gmail :** [Erreurs SMTP de Gmail et dépannage](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/depannage-gmail) présente le catalogue complet des codes `421` et `550-5.7.x`, avec une correction pour chacun. Les recommandations de Gmail sur la non-remise citent aussi l'envoi de plus de 500 messages par jour ou d'un message à plus de 500 destinataires (les limites des comptes Gmail personnels), un destinataire qui n'existe pas, un destinataire dont l'espace de stockage est plein, et un HELO ou EHLO mal formé.
- **Microsoft :** pour `550 5.7.606-649 Access denied, banned sending IP [x.x.x.x]`, utilisez le **portail de retrait de liste** sur `sender.office.com` ([canaux d'escalade de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-de-microsoft)). Pour le diagnostic à partir des en-têtes, du niveau de confiance spam (SCL) et du niveau de plainte en nombre (BCL), voir le [fonctionnement interne du filtrage de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/fonctionnement-interne-du-filtrage-de-microsoft). La liste complète des codes NDR de Microsoft figure dans son guide « Email non-delivery reports in Exchange Online ».
- **Yahoo :** le catalogue des codes se trouve dans [Codes d'erreur SMTP de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/codes-d-erreur-smtp-de-yahoo).
- **Passerelles B2B et d'entreprise** (Proofpoint, Mimecast, Barracuda, clients M365) : elles utilisent des systèmes de réputation et des portails de retrait de liste entièrement différents. Voir [délivrabilité vers les passerelles B2B](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/delivrabilite-vers-les-passerelles-b2b).

---

## Procédure B : message retardé ou reporté (4xx, « Delayed », bloqué en file d'attente)

**Symptôme :** le message n'est pas encore livré mais n'a pas échoué définitivement. La file d'attente de l'expéditeur affiche `4xx` ou `421`, ou Postmark affiche `Delayed` : le serveur distant a demandé d'attendre, et Postmark réessaie la plupart des domaines toutes les ~10 min pendant 12 heures au plus avant de déclarer le rebond. Le serveur de réception dit « pas maintenant », et le diagnostic porte sur le pourquoi et le pour combien de temps.

Les reports de remise ont quatre causes courantes. Elles semblent identiques au départ, et chacune appelle une réponse différente :

| Cause | Signature | Test qui distingue les causes | Réponse |
|---|---|---|---|
| **Liste grise** | Le premier message d'une nouvelle combinaison d'adresse IP et d'expéditeur est reporté, puis passe lors d'une nouvelle tentative depuis la même adresse IP | Le message est-il livré à la tentative suivante sans rien changer ? Le report est-il lié à la combinaison de l'adresse IP, de l'expéditeur et du destinataire ? | Ne faites rien d'autre que réessayer depuis la même adresse IP. C'est pourquoi il est important de garder un expéditeur sur le même pool ou la même adresse IP. Voir [liste grise](https://emailmarketing.net/learn/rfc/rfc6647-greylisting) |
| **Limitation de débit** | Les reports augmentent avec le volume et se concentrent chez un fournisseur : `421`, "try again later", `4.7.28` | Les reports augmentent-ils avec votre rythme d'envoi ? Est-ce un seul fournisseur ? | Réduisez la concurrence et le débit vers cette destination, et espacez les tentatives. Voir [réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta) et les [valeurs de référence par fournisseur](https://emailmarketing.net/fr/apprendre/operations/reglages-de-reference-par-fournisseur) |
| **Report de remise pour réputation (avant un blocage)** | Des réponses 4xx persistantes qui ne se résorbent pas, un tableau de bord du fournisseur qui se dégrade, souvent avant un blocage définitif | Votre réputation dans Google Postmaster Tools (GPT) ou dans Smart Network Data Services (SNDS) est-elle en baisse ? Le texte du report mentionne-t-il la réputation ? | Traitez-le comme un incident naissant : suivez la procédure C et voir [rétablissement après incident](https://emailmarketing.net/fr/apprendre/operations/retablissement-apres-un-incident-de-reputation). Ne vous contentez **pas** de réessayer plus fort |
| **Serveur du destinataire en panne, ou problème réseau** | Des reports vers un seul domaine de destination quel que soit votre débit, et des délais de connexion dépassés | Est-ce un seul domaine de destination, de façon passagère, et sans lien avec votre volume ? | Attendez et gardez le calendrier normal de nouvelles tentatives. Les recommandations de Microsoft lui-même citent « la destination prévue ne répond pas » comme la cause la plus probable d'un retard |

**L'erreur critique à éviter** est de répondre à un report de remise pour réputation en réessayant plus agressivement. Insister auprès d'un fournisseur qui vous reporte pour réputation transforme un blocage temporaire en blocage définitif. Pour distinguer une limitation de débit d'un blocage qui s'annonce, ralentissez. Une limitation de débit disparaît quand vous ralentissez. Un problème de réputation persiste, et le tableau de bord se dégrade.

**Microsoft :** `host xxxx.outlook.com [x.x.x.x]: 451 4.7.550 Access denied, please try again later` signifie que Microsoft a temporairement restreint l'adresse IP parce qu'il a détecté une activité suspecte et qu'il l'évalue. La restriction est levée automatiquement une fois le trafic jugé acceptable. Réduisez le volume, laissez l'évaluation se faire, et n'escaladez pas immédiatement.

**Les reports de remise de mots de passe à usage unique (OTP) et d'autres emails transactionnels** demandent un traitement particulier. Pour l'utilisateur, un mot de passe à usage unique reporté a échoué, même si SMTP le considère toujours comme en cours d'acheminement. Si le courrier transactionnel partage un flux ou une adresse IP avec le courrier marketing, et que le volume marketing déclenche une limitation de débit, l'OTP est reporté lui aussi. C'est l'argument en faveur de la [séparation des flux](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi), avec le courrier transactionnel sur son propre sous-domaine et son propre pool. Pour le diagnostiquer, comparez les horodatages des reports d'OTP avec les heures des pics d'envoi marketing.

---

## Procédure C : accepté, mais arrivé dans le dossier spam ou le courrier indésirable

**Symptôme :** les journaux indiquent `Delivered` ou `250`, mais le message se trouve dans le dossier spam ou le courrier indésirable, ou dans un onglet Gmail que l'expéditeur ne compte pas comme la boîte de réception. C'est le problème de placement, et c'est la demande la plus fréquente que reçoit un consultant en délivrabilité. Il n'y a aucun signal SMTP : le serveur de réception a accepté le message puis a décidé où l'acheminer. Les tests qui distinguent les causes sont les tableaux de bord, les en-têtes et les tests sur liste de test, et non les codes de réponse.

### C-1. Délimiter d'abord l'échec

Le test préliminaire le plus précieux consiste à savoir si le problème touche **un seul fournisseur ou tous les fournisseurs**. La réponse coupe les causes possibles en deux :

- **Tous les fournisseurs orientent vers une cause côté expéditeur.** Tous les filtres voient un problème d'authentification, de contenu, de liste ou de réputation. Commencez par l'authentification et le contenu.
- **Un seul fournisseur oriente vers la réputation ou le filtre de ce fournisseur.** Passez à la branche du fournisseur (C-3). Un message qui arrive en boîte de réception chez Yahoo mais en spam chez Gmail n'a pas un problème de contenu. Il a un problème de réputation chez Gmail ou de personnalisation par Gmail.

Établissez le périmètre avec un **test sur liste de test ou de placement en boîte de réception** chez plusieurs fournisseurs (Litmus, Validity/Everest, GlockApps, Mailgun), en gardant ses limites à l'esprit. Les adresses de test n'ont aucun historique d'engagement avec vous, si bien qu'elles passent à côté de la personnalisation propre à chaque utilisateur et donnent des résultats plutôt pessimistes (voir [les limites de la mesure du placement](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation#4-tests-sur-liste-de-test-et-de-placement-en-boîte-de-réception) et [les distorsions du suivi](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure)). Comparez les résultats du test avec Postmaster Tools et avec l'engagement réel chez chaque fournisseur.

### C-2. Tests côté expéditeur (quand le courrier arrive en spam chez tous les fournisseurs)

Lancez-les dans l'ordre, et arrêtez-vous dès qu'un test révèle la cause :

1. **Authentification.** Examinez les en-têtes d'un message arrivé en courrier indésirable. `Authentication-Results:` doit afficher `spf=pass dkim=pass` **et** l'alignement DMARC (le domaine `From` correspond au domaine DKIM `d=` ou au domaine du Return-Path). Tous les grands fournisseurs signalent le courrier non authentifié comme à haut risque, et les règles de Gmail et de Yahoo pour les expéditeurs de gros volumes l'excluent. Vérifiez que SPF respecte la [limite de 10 requêtes DNS](https://emailmarketing.net/fr/apprendre/authentification/spf), que DKIM est vérifié, et qu'un Return-Path personnalisé est en place pour l'alignement. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).
2. **Taux de plaintes.** C'est le signal le plus dommageable. La règle opérationnelle de Postmark est qu'un taux de plaintes supérieur à **0,1 %** (1 pour 1 000) annonce une baisse de délivrabilité, et Google impose un plafond strict de **0,3 %** (voir [Exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs)). Consultez les données de plaintes pour chaque fournisseur dans [GPT](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools) et dans [SNDS et JMRP](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp).
3. **Taux de rebonds.** Un taux élevé d'adresses invalides ressemble aux pratiques de liste d'un spammeur. Le plafond opérationnel de Postmark est un taux de rebonds définitifs inférieur à 5 %, et jamais supérieur à 10 %. La cible plus stricte de Klaviyo est un taux de rebonds total inférieur à 1 %, et le taux sain de Postmark pendant la chauffe est inférieur à 2 %. L'ensemble des valeurs, avec l'attribution de chaque chiffre, figure dans le [tableau de référence des seuils](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite#canonical-threshold-table). Des rebonds élevés orientent vers un problème de qualité de la liste qui abîme la réputation.
4. **Contenu.** Passez le message exact dans un outil de vérification fondé sur SpamAssassin (la cible de Postmark Spam Check est un score inférieur à 5, et un score négatif est meilleur) et dans mail-tester. Les déclencheurs courants sont les raccourcisseurs d'URL (bit.ly) au lieu de liens à votre marque, les messages composés uniquement d'images ou avec des images trop lourdes, un HTML cassé ou incomplet, des domaines de liens et d'images qui ne correspondent pas au domaine `From`, et un lien de désabonnement absent ou cassé. Si **un changement de modèle a précédé la baisse**, revenez en arrière pas à pas, en retirant un élément à la fois, pour isoler le déclencheur. Voir [contenu et design](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite).
5. **Réputation.** Vérifiez la réputation du domaine et des adresses IP dans les tableaux de bord des fournisseurs et par des interrogations DNSBL. Une mauvaise note ici signifie que la cause est un historique accumulé, et non ce seul message. Voir [rétablissement après incident](https://emailmarketing.net/fr/apprendre/operations/retablissement-apres-un-incident-de-reputation).

### C-3. Branches de placement pour chaque fournisseur (quand le courrier arrive en spam chez un seul fournisseur)

| Fournisseur | Test qui distingue les causes | Ce qu'il montre | Suite |
|---|---|---|---|
| **Gmail** | [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools) : réputation du domaine et des adresses IP (Bad, Low, Medium, High), tableau de bord du taux de spam, taux de réussite de l'authentification | Une baisse de la réputation du domaine de High à Medium annonce un classement en courrier indésirable. Gmail personnalise pour chaque utilisateur selon son historique de contacts, si bien qu'un utilisateur de Gmail peut recevoir une campagne en boîte de réception alors qu'un autre reçoit la même campagne en spam. Des résultats de test qui divergent du placement réel sont donc attendus | N'envoyez qu'aux utilisateurs de Gmail engagés et encouragez un engagement positif. GPT n'affiche aucune donnée sous ses seuils de volume ; diagnostiquez alors par l'engagement |
| **Microsoft** (Outlook.com et M365) | Examinez les en-têtes : **SCL** et **BCL** dans `X-Forefront-Antispam-Report`, et `compauth` | Un SCL élevé signifie un verdict de spam fondé sur le contenu ou la réputation. Un BCL élevé signifie une pénalité pour envoi en nombre. L'en-tête indique quel filtre s'est déclenché. Le [fonctionnement interne du filtrage de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/fonctionnement-interne-du-filtrage-de-microsoft) le décode en détail | Pour un faux positif, le destinataire soumet le message à Microsoft pour analyse. Vérifiez la couleur de filtrage dans [SNDS](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp) (vert, jaune ou rouge) et les adresses pièges touchées, et escaladez par les [canaux de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-de-microsoft) |
| **Yahoo et AOL** | Les [flux de performance de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/flux-de-donnees-de-delivrabilite-de-yahoo) et la feedback loop (FBL) de plaintes | Le placement est piloté par les plaintes, et Yahoo accorde un grand poids à l'engagement | Placez en suppression les personnes qui se plaignent et n'envoyez qu'aux destinataires engagés. Voir [exigences de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs) |
| **Apple iCloud** | Il n'y a pas de tableau de bord pour les expéditeurs ; déduisez le placement des tests sur liste de test et de l'engagement | Mail Privacy Protection (MPP) gonfle les ouvertures, donc considérez les ouvertures comme peu fiables. Le placement dépend de l'authentification et de la réputation | [Apple iCloud](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/apple-icloud-mail-exigences-postmaster) |
| **Passerelle B2B** | L'outil de vérification de réputation d'IP de la passerelle (ipcheck.proofpoint.com, barracudacentral.org) | Le placement dépend de la politique du client définie par l'administrateur et des données de réputation de la passerelle, et non d'un filtrage de type grand public | [Délivrabilité vers les passerelles B2B](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/delivrabilite-vers-les-passerelles-b2b) |

### C-4. Microsoft : la procédure pour le courrier arrivé dans le courrier indésirable

Microsoft documente cette démarche pour un faux positif :

1. Confirmez que le message a été livré (dans le suivi des messages, STATUS = Delivered, et non bloqué).
2. Faites **signaler le message à Microsoft** par le destinataire comme faux positif, pour analyse.
3. Vérifiez que l'expéditeur n'annonce pas d'adresse IP non routable et n'échoue pas au DNS inverse.
4. Vérifiez que le nom d'expéditeur et l'objet sont transparents et que les domaines de redirection sont cohérents : tous les liens mènent à un seul domaine, et non à un ensemble dispersé comme `unsubscribe.bulkmailer.com`, `profile.excite.com` et `options.yahoo.com`.
5. Pour un problème de réputation systémique, passez par SNDS et le support aux expéditeurs.

---

## Procédure D : message « introuvable » (accepté, ni en boîte de réception ni en spam)

**Symptôme :** les journaux indiquent `Delivered`, mais le destinataire ne trouve le message nulle part, ni dans la boîte de réception ni dans le dossier spam. C'est le cas le plus difficile à diagnostiquer, parce que le serveur de réception a signalé un succès. Les causes possibles, de la plus probable à la moins probable :

1. **Le message est dans le dossier spam ou le courrier indésirable, et le destinataire n'y a pas regardé.** C'est l'explication la plus fréquente. Faites chercher le destinataire dans tous les dossiers, y compris les onglets Gmail (Promotions, Notifications, Réseaux sociaux), les vues Prioritaire et Autres d'Outlook, et le courrier indésirable. Puis suivez la procédure C.
2. **Le message a été filtré ou supprimé après acceptation.** Le fournisseur l'a accepté puis l'a écarté par un filtrage de réputation agressif. Le tableau de bord du fournisseur et, chez Microsoft, un suivi des messages révèlent un verdict de filtrage postérieur à l'acceptation. C'est un problème de réputation : voir la procédure C-3 et le [rétablissement après incident](https://emailmarketing.net/fr/apprendre/operations/retablissement-apres-un-incident-de-reputation).
3. **Une règle ou un transfert côté destinataire.** Une règle de boîte de réception a déplacé ou supprimé le message, ou un transfert défaillant l'a perdu. Le premier geste de tri de Microsoft consiste à faire vérifier par l'utilisateur **Outlook sur le web**. Si le message s'y trouve mais pas dans l'application de bureau ou mobile, le problème vient de l'application ou d'une règle locale, et non de la livraison. Pour les problèmes Outlook qui ne touchent qu'un utilisateur, lancez l'**Assistant Support et récupération** de Microsoft (Support and Recovery Assistant).
4. **Une livraison à la mauvaise adresse.** Un alias ou une faute de frappe correspondait par hasard à une boîte valide. Confirmez l'adresse exacte du destinataire dans vos journaux.
5. **Un incident de service.** Avant une enquête approfondie, vérifiez l'état de santé du service du fournisseur (Centre d'administration Microsoft 365, puis Service health, ou la page d'état du fournisseur). Un service de réception dégradé retarde ou achemine mal le courrier dans toute l'organisation, et aucune correction n'est nécessaire côté expéditeur.

**Un seul utilisateur ou plusieurs** est la question clé de la procédure D. Si un seul destinataire n'a pas reçu un message, la cause est l'application de messagerie, une règle ou l'adresse (utilisez les outils ci-dessus). Si plusieurs destinataires chez un même fournisseur n'ont pas reçu de messages, la cause est la réputation ou le filtrage (procédure C). Si plusieurs destinataires chez tous les fournisseurs n'ont pas reçu de messages, la cause est l'authentification ou un incident côté envoi.

---

## Bibliothèque de scénarios (exemples détaillés)

Des tickets concrets et la branche que chacun emprunte :

| Ticket | Procédure | Test, constat et correction |
|---|---|---|
| « Livré mais en spam, chez Gmail seulement » | C, un seul fournisseur | Un test sur liste de test confirme que seul Gmail est touché. GPT affiche une réputation de domaine Medium. Le contenu n'est pas en cause, puisque Yahoo place le message en boîte de réception. N'envoyez qu'aux utilisateurs de Gmail engagés, encouragez l'engagement, et attendez-vous à un rétablissement sur plusieurs semaines |
| « Classement soudain en courrier indésirable chez Microsoft après des années en boîte de réception » | C-3 Microsoft | L'en-tête montre un bond du SCL ou du BCL. SNDS est passé au jaune ou au rouge, ou montre des adresses pièges touchées. Un changement récent de liste ou de volume est le déclencheur. Placez le segment fautif en suppression, soumettez le faux positif, et utilisez les [canaux d'escalade de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-de-microsoft) |
| « OTP transactionnel reporté chez Yahoo » | B, limitation de débit | Les reports coïncident avec un pic d'envoi marketing sur le flux partagé. Déplacez le courrier transactionnel sur son propre flux et son propre pool, et le report disparaît |
| « Les taux d'ouverture se sont effondrés chez un fournisseur » | C, ou artefact de mesure | Écartez d'abord la [distorsion due à MPP et aux clics de robots](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure), puisque les ouvertures sont peu fiables depuis MPP. Si les clics et les conversions ont aussi baissé, le placement a vraiment baissé : suivez la procédure C |
| « Nouvelle IP : messages soudain rejetés / reportés » | A ou B | Lisez le texte. Un `5.7.1` qui cite les consignes IPv6 renvoie aux exigences d'authentification et de PTR de l'[envoi en IPv6](https://emailmarketing.net/fr/apprendre/operations/envoyer-des-emails-en-ipv6). Un `451 4.7.550` de Microsoft signifie une limitation de débit sur une nouvelle adresse IP : laissez la montée en charge se faire, ce qui prend des semaines. Une liste grise implique de réessayer depuis la même adresse IP |
| « Pic de rebonds pendant la nuit, chez un seul fournisseur » | A, réputation | Faites des interrogations DNSBL et consultez le tableau de bord. S'il s'agit d'une inscription sur une liste de blocage ou d'un blocage pour réputation par le fournisseur, corrigez la cause profonde puis suivez la [procédure de retrait de liste](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation#blocklist-delisting-workflow). Si le volume a aussi bondi, soupçonnez un [compte compromis](https://emailmarketing.net/learn/esp-operations/compromised-accounts) |
| « Le destinataire dit n'avoir jamais rien reçu, le journal dit Delivered » | D | Cherchez d'abord dans tous les dossiers. Demandez ensuite si un seul utilisateur ou plusieurs sont touchés. Pour un seul utilisateur, testez Outlook sur le web |

---

## Escalader auprès du fournisseur (quand le libre-service est épuisé)

Avant d'ouvrir un canal auprès d'un fournisseur, suivez les procédures jusqu'à obtenir une hypothèse précise étayée par des preuves. Le support des fournisseurs ferme les tickets qui arrivent sans diagnostic. Apportez les adresses IP et le domaine d'envoi, le texte exact du rejet SMTP ou du NDR, des exemples d'en-têtes (`Authentication-Results`, `X-Forefront-Antispam-Report`), des captures d'écran des tableaux de bord GPT ou SNDS, la date de début du problème, et ce que vous avez modifié autour de cette date.

[Canaux d'escalade et de levée des restrictions](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-et-de-levee-des-restrictions) et [Canaux d'escalade de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-de-microsoft) recensent les canaux : le formulaire d'escalade de Google pour les expéditeurs de gros volumes et sa condition d'éligibilité (0,3 % sur 7 jours), le portail de retrait de liste de Microsoft (`sender.office.com`), distinct du support aux expéditeurs, le support aux expéditeurs de Yahoo, et l'adresse `icloudadmin@` d'Apple. Chaque canal ne règle qu'une partie des problèmes. Les portails de retrait de liste lèvent les blocages d'IP. Ils ne règlent pas les problèmes de contenu ou de plaintes, qui ne se corrigent qu'une fois le comportement de l'expéditeur modifié.

## Voir aussi

- [Surveillance et remédiation de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation), y compris la procédure de retrait de liste
- [Rétablissement après un incident de réputation](https://emailmarketing.net/fr/apprendre/operations/retablissement-apres-un-incident-de-reputation)
- [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi), sur le cadre en 5 volets de Postmark : authentification, contenu, engagement, réputation et infrastructure
- [Réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta)
- [Valeurs de référence par fournisseur](https://emailmarketing.net/fr/apprendre/operations/reglages-de-reference-par-fournisseur)
- [Erreurs SMTP de Gmail et dépannage](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/depannage-gmail)
- [Fonctionnement interne du filtrage de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/fonctionnement-interne-du-filtrage-de-microsoft)
- [Codes d'erreur SMTP de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/codes-d-erreur-smtp-de-yahoo)
- [Canaux d'escalade et de levée des restrictions](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-et-de-levee-des-restrictions)
- [Codes d'état étendus](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp)
- [Notifications d'état de livraison](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison)

# Réglage de la livraison par le MTA

> La théorie des files d'attente sortantes et le réglage de la livraison comme discipline : diagnostic par l'âge des files, adaptation de la concurrence et du débit par destination, réutilisation des connexions, temporisation adaptative et détection des sites hors service, équité de l'ordonnanceur et automatisation de l'adaptation du trafic pilotée par les rebonds.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta

Si vos files d'attente sortantes grossissent ou si les fournisseurs reportent vos messages, la cause tient souvent à l'intensité avec laquelle votre serveur de messagerie sollicite chaque destination. Le réglage de la livraison couvre la façon dont un agent de transfert de courrier (MTA) décide de cette pression, et la façon dont les opérateurs diagnostiquent et corrigent l'engorgement de la livraison.

Les notions ci-dessous valent pour tout MTA. Les modèles de diagnostic des files d'attente, de rétroaction sur la concurrence et d'ordonnancement viennent de la documentation de Postfix, et les modèles de règles d'adaptation du trafic et d'automatisation viennent de celle de KumoMTA. Tout MTA sérieux, commercial ou open source, en implémente une variante. Pour les valeurs concrètes par fournisseur que ces mécanismes appliquent, voir [Réglages de référence par fournisseur](https://emailmarketing.net/fr/apprendre/operations/reglages-de-reference-par-fournisseur).

## Pourquoi c'est une discipline de la délivrabilité

Les fournisseurs de messagerie imposent par expéditeur des plafonds de connexions, de débit de messages et de messages par connexion, et répondent aux dépassements par des reports de remise 4xx (souvent `421`) ou des pénalités de limitation de débit. Un MTA qui dépasse ces limites transforme de bons messages en messages reportés et fait vieillir ses files d'attente. Chez les fournisseurs qui notent les « schémas de trafic inhabituels », il abîme aussi la réputation de ses adresses IP. Régler la livraison consiste à maintenir la pression sortante juste sous la tolérance de chaque destination, à ralentir automatiquement lorsque la destination signale une difficulté, et à diagnostiquer vite les problèmes de file d'attente lorsqu'ils apparaissent.

## La répartition par âge des files d'attente comme outil de diagnostic (le modèle « qshape »)

La vue la plus informative d'un MTA sortant est un tableau à deux dimensions, avec **le domaine de destination sur un axe et l'âge des messages sur l'autre**, et un décompte dans chaque cellule. Postfix fournit cette vue sous le nom `qshape`. Les tranches d'âge sont fines pour les messages récents, typiquement 5, 10, 20, 40, 80, 160, 320, 640, 1280 et 1280+ minutes, avec une colonne de total par domaine. Lancez-la séparément sur les files entrante et active (les messages en cours de traitement) et sur la file des messages reportés (ceux qui ont déjà subi un échec temporaire).

Règles de lecture :

1. **Les problèmes se trouvent en haut à gauche.** De gros décomptes pour un seul domaine dans les tranches récentes signalent un problème actif, en cours. Une concentration dans les tranches anciennes signale un problème passé en train de se résorber.
2. **La concentration sur un domaine désigne le goulet d'étranglement.** Triez par total de ligne. Les domaines dominants sont ceux où la livraison échoue ou est limitée.
3. **Un arriéré dans la file active compte plus qu'un arriéré dans la file des messages reportés.** Les messages bloqués dans la file active empêchent le traitement des nouveaux, tandis que les messages reportés attendent seulement leur prochaine tentative.
4. **Une file active pleine alors que la file entrante ne l'est pas** signifie qu'une ou plusieurs destinations se vident plus lentement que les messages n'arrivent pour elles.
5. **Une vue par expéditeur détecte le backscatter.** Pivoter le même tableau par expéditeur plutôt que par destinataire montre quand la file est dominée par des messages de rebond (MAILER-DAEMON), ce qui signifie que la charge vient du traitement de rebonds auto-infligés, pas de nouveaux messages.

Schémas caractéristiques :

| Schéma | Signature dans le tableau des âges | Diagnostic |
|---|---|---|
| Sain | Files entrante et active quasi vides ; petits totaux de messages reportés répartis dans les tranches anciennes | Fonctionnement normal |
| Arriéré de messages reportés, âges anciens | Gros totaux de messages reportés, avec des décomptes qui progressent vers les tranches les plus anciennes ; files entrante et active courtes | Un problème passé déjà résolu, dont les nouvelles tentatives se résorbent. « Un volume élevé de messages reportés n'est pas en soi un motif d'alarme » (*high volume of deferred mail is not a direct cause for alarm*) |
| Backscatter de rebonds | Comme ci-dessus, mais la vue par expéditeur montre surtout MAILER-DAEMON | Un mauvais envoi antérieur (par exemple vers une liste victime d'une attaque par dictionnaire) génère encore du travail de rebonds |
| Saturation de la file active | Décompte actif proche de son plafond (exemple Postfix : 9 996 sur une limite de 10 000 ; 20 000 dans les versions ultérieures), presque tout dans la tranche la plus récente, avec un domaine dominant | Une destination se vide bien plus lentement que les messages n'arrivent. Les agents de livraison sont monopolisés, et les nouveaux messages sont retardés pour toutes les destinations |
| Arriéré sur une destination à fort volume | Un domaine avec de gros décomptes dans toutes les tranches plus récentes que le début du problème, et toujours en hausse | La destination est hors service ou en limitation de débit depuis à peu près la plus ancienne tranche touchée ; l'engorgement est en cours |

Ordres de grandeur (chiffres de Postfix, indicatifs pour tout MTA de type stockage et retransmission) : une file de messages reportés supporte de 100 000 à 1 000 000 de messages environ, et de bonnes performances sont peu probables au-delà.

## Adaptation de la concurrence par destination

Les MTA ouvrent un nombre limité de connexions parallèles vers chaque destination, et ajustent ce nombre en fonction des résultats de livraison. Ce mécanisme ressemble délibérément au démarrage lent (*slow start*) de TCP.

- **La concurrence initiale** est faible (valeur par défaut de Postfix : 5 livraisons simultanées), afin de sonder avec douceur une destination nouvelle ou en cours de rétablissement.
- **La concurrence maximale** plafonne le parallélisme pour chaque destination (valeur par défaut de Postfix : 20). Les réglages propres à une destination permettent de respecter les plafonds des fournisseurs, par exemple pour un fournisseur qui ne tolère que 2 connexions.
- **La rétroaction positive** augmente la concurrence après des livraisons réussies, et **la rétroaction négative** la diminue après des échecs de connexion ou de négociation. L'incrément de rétroaction est une fonction de la concurrence actuelle N :
  - `+1` par succès donne une montée exponentielle (5, puis 10, puis 20) : rapide, mais sujette aux oscillations ;
  - `+1/N` par succès donne une montée linéaire, un emplacement de plus après N succès : la plus douce ;
  - `+1/√N` se situe entre les deux.
  Une rétroaction fractionnaire associée à une troncature entière produit une hystérésis naturelle : la concurrence n'augmente d'un cran qu'après `1/g(N)` succès consécutifs.
- **L'asymétrie compte.** La rétroaction négative s'applique dès le début d'une série d'échecs (« hystérésis inverse »), afin que la surcharge soit corrigée immédiatement, et non après toute une fenêtre d'échecs.
- Effet mesuré (tests de l'ordonnanceur de Postfix face à un serveur de réception qui impose des limites de concurrence par des réponses `421`) : une rétroaction fixe de ±1 a reporté environ 50 % des messages ; une rétroaction en `1/N`, environ 16,5 % ; en `1/√N`, environ 24,5 %. Une rétroaction plus douce réduit fortement les reports de remise chez les serveurs de réception qui imposent des limites.
- Réserve : une rétroaction inférieure à 1 a peu d'effet quand le volume vers une destination est faible, car les livraisons sont trop rares pour que les compteurs évoluent.

### Détection des sites hors service et mise en pénitence

Ce mécanisme est distinct de la rétroaction sur la concurrence. Lorsqu'une cohorte entière de tentatives de livraison (N tentatives, N étant la concurrence actuelle) échoue avec des erreurs de connexion ou de négociation, la destination est déclarée **hors service** après un nombre configurable de cohortes en échec (valeur par défaut de Postfix : 1 cohorte). Les destinations hors service sont mises en pénitence : elles sont complètement ignorées pendant une période, au lieu d'être sollicitées sans relâche avec une concurrence de 1. Séparer « le site est hors service » de « le site est lent » permet de garder une rétroaction douce sur la concurrence sans gaspiller des agents de livraison sur des hôtes injoignables.

## Adaptation du débit, réutilisation des connexions et vocabulaire des paramètres

Au-delà de la concurrence, les MTA modernes adaptent le trafic vers chaque destination selon plusieurs axes indépendants (les noms viennent de KumoMTA, et tout MTA a des équivalents) :

| Paramètre (notion) | Signification | Valeur globale par défaut typique (KumoMTA) |
|---|---|---|
| Limite de connexions | Nombre maximal de connexions simultanées vers la destination | 10 |
| Débit de connexions | Nombre maximal de nouvelles connexions par unité de temps | 100 par minute |
| Débit de messages | Nombre maximal de messages par unité de temps, indépendamment des connexions | 100 par seconde |
| Livraisons par connexion | Messages envoyés avant de fermer puis de rouvrir une session SMTP | 100 |
| Délai d'inactivité | Durée pendant laquelle une connexion en cache peut rester inactive avant d'être fermée | 60 s |
| Délais d'expiration des données | Délais pour la phase DATA et pour le point final | 30 s et 60 s |
| Mode TLS | Opportuniste ou obligatoire, par destination | Opportuniste |
| Échecs de connexion consécutifs avant temporisation | Le nombre d'échecs qui déclenche le ralentissement | 100 |

**La réutilisation des connexions** (envoyer de nombreux messages par une seule connexion) est un levier important. L'établissement d'une connexion, la négociation TLS et la comptabilité par connexion du serveur de réception coûtent tous plus cher qu'un `MAIL FROM` supplémentaire. Mais les fournisseurs plafonnent le nombre de messages par connexion et répondent aux dépassements par des erreurs comme « Max message per connection reached », donc la bonne valeur dépend du fournisseur (50 pour Gmail, 20 pour Yahoo, 5 pour Apple dans les valeurs de référence de la communauté). Un réglage voisin est le nombre de destinataires par copie d'un message (valeur par défaut de Postfix : 50 destinataires par copie ; les listes de destinataires plus longues sont réparties en copies parallèles).

**Regroupement des destinations (MX rollup)** : les limites d'adaptation devraient s'appliquer à chaque infrastructure de réception, et non à chaque domaine de destinataire. Des milliers de domaines hébergés partagent le parc MX de Google ou de Microsoft. Regrouper dans un même compartiment d'adaptation tous les domaines dont les enregistrements MX correspondent à un suffixe (par exemple `.google.com` ou `.googlemail.com`) vous évite de multiplier par inadvertance votre nombre effectif de connexions par le nombre de domaines de destinataires. À l'inverse, un fournisseur dont les noms MX correspondent à des silos régionaux (par exemple les noms de sites de Mimecast) devrait être limité par site MX, et non par fournisseur.

## Calendrier des nouvelles tentatives et temporisation adaptative sur les 4xx

Les messages en échec temporaire (4xx) reçoivent un horodatage dans le futur, avec une **temporisation exponentielle** entre un plancher et un plafond (valeurs par défaut de Postfix : minimum 300 s, maximum 4 000 s), et la file des messages reportés est réexaminée périodiquement (par défaut toutes les 300 s). Les messages qui ne peuvent pas être livrés pendant la **durée de vie en file d'attente** (5 jours par défaut ; les rebonds ont souvent leur propre durée, également de 5 jours) sont renvoyés comme échecs permanents.

Règles opérationnelles :

- **Ne raccourcissez pas les intervalles entre tentatives pour « vider l'arriéré ».** Retenter plus souvent des messages non livrables sature la file active et monopolise les agents de livraison sur des sites hors service, ce qui prive les messages livrables de ressources. Corriger la cause fonctionne toujours mieux que réessayer plus fort.
- **Les délais d'expiration bornent le débit dans le pire des cas.** Par exemple, avec 100 agents de livraison, une destination qui a 2 hôtes MX dont un est hors service, et un délai de connexion de 30 secondes, le débit plafonne à environ 6 messages par seconde, car la moitié des tentatives de connexion consomment un délai complet. Des délais de connexion plus courts (et un passage rapide au MX suivant) rétablissent le débit pendant une panne partielle.
- **Isolez les destinations problématiques.** Attribuez aux destinations chroniquement lentes ou instables un pool de livraison dédié avec des délais réduits et une concurrence ajustée, ou dirigez-les vers un relais de repli (« cimetière ») avec son propre rythme de tentatives, afin qu'elles ne puissent pas dégrader la livraison principale.

## Équité de l'ordonnanceur et préemption

À l'intérieur du MTA, un ordonnanceur décide quel message obtient le prochain emplacement de livraison libre :

- **Le tourniquet entre transports et destinations** garantit qu'aucune destination ne monopolise les agents de livraison.
- **Premier entré, premier sorti (FIFO) au sein d'une destination**, selon l'heure d'entrée en file, sauf en cas de préemption.
- **La préemption** permet aux petits messages de passer devant les envois de masse sans priver ces derniers de ressources. À mesure que les destinataires d'un gros message sont servis, celui-ci accumule des « emplacements de livraison » (un pour K destinataires servis ; coût par défaut de Postfix K=5). Un candidat à la préemption est choisi en maximisant `enqueue_time / recipient_count` (le plus ancien relativement à sa taille en premier), et doit disposer d'un nombre minimal d'emplacements (3 par défaut). **Les prêts d'emplacements** (jusqu'à 3 emplacements par défaut, avec une remise de 50 %) permettent à un petit message de passer immédiatement et de « rembourser » l'avance sur les livraisons suivantes. Cela accélère les messages de taille transactionnelle sans renoncer à l'équité envers les campagnes de masse. C'est l'équivalent, dans le MTA, de la pratique des fournisseurs de services de messagerie (ESP) qui séparent les flux transactionnels et de masse.

## Automatisation de l'adaptation du trafic pilotée par les rebonds

Les tables d'adaptation statiques fixent le plafond, et l'automatisation ajuste le trafic en dessous en temps réel, en analysant ce que disent les fournisseurs dans leurs réponses SMTP. Le modèle est la Traffic Shaping Automation de KumoMTA, qui fonctionne comme un démon séparé : il surveille les journaux de livraison et renvoie la configuration au MTA. Il peut fonctionner en grappe, afin que tous les nœuds réagissent ensemble :

- **Correspondance** : des règles d'expressions régulières sur le texte des réponses de rebond et de report, limitées à un fournisseur ou un site, à un client (tenant) ou à une campagne.
- **Déclenchement** : immédiat, ou seulement au-delà d'un seuil (par exemple 2 correspondances par heure, ce qui distingue un cas isolé d'une tendance).
- **Action** : soit **Suspend** (arrêter complètement l'envoi vers cette destination depuis cette file), soit **SetConfig** (resserrer un paramètre d'adaptation : ramener `connection_limit` à 1, plafonner `max_message_rate` à 1 par minute, réduire `max_deliveries_per_connection`). Une suspension limitée à un client existe pour les réponses qui signalent un problème d'expéditeur (par exemple une authentification absente) plutôt qu'un problème de trafic.
- **Expiration** : chaque action a une durée (couramment de 15 minutes à 4 heures). À son terme, l'adaptation normale reprend automatiquement. La limitation automatique se rétablit ainsi d'elle-même : aucun opérateur n'a besoin de penser à la lever.

Règles représentatives de la communauté (voir [Réglages de référence par fournisseur](https://emailmarketing.net/fr/apprendre/operations/reglages-de-reference-par-fournisseur) pour le tableau complet) :

- Réponses « unusual rate » de Gmail : plafond de 10 messages par minute pendant 30 minutes.
- Reports pour plaintes `[TSS04]` de Yahoo : suspension de 2 heures.
- « exceeded the maximum number of connections » d'Outlook : limite de 1 connexion pendant 1 heure.
- Une règle générique par défaut couvre la famille de textes vus chez plusieurs fournisseurs, comme « temporarily deferred », « rate limited due to IP reputation » et « Server busy », et ramène à la fois le débit de messages à 1 par minute et les connexions à 1, pendant 90 minutes.

Principes de conception pour écrire vos propres règles :

1. **Analysez les mots du fournisseur, pas seulement le code.** `421` seul est ambigu, tandis que `[TS02]`, `[TS03]` et « Max message per connection reached » appellent chacun une réponse différente (voir les guides des codes d'erreur de [Gmail](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/depannage-gmail), de [Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/codes-d-erreur-smtp-de-yahoo) et de [Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs)).
2. **Adaptez l'action au reproche.** Pour les reproches sur les connexions, réduisez les connexions. Pour les reproches sur le volume, réduisez le débit de messages. Pour les reports liés à la réputation ou aux plaintes, et pour les inscriptions sur des listes de blocage, suspendez et laissez la réputation retomber. Pour les rejets de contenu, suspendez et alertez une personne, car la limitation de débit ne corrigera pas le contenu.
3. **Ralentissez davantage pour les signaux de réputation que pour les limites mécaniques.** Atteindre un plafond de connexions est une erreur de réglage ; « deferred due to user complaints » est un événement de réputation.
4. **Gardez des durées courtes, et laissez les règles se redéclencher.** Une pénalité de 30 à 120 minutes qui se renouvelle tant que le fournisseur continue de se plaindre converge vers le bon débit sans paralyser durablement la file d'attente.

## Organiser la configuration d'adaptation en couches

Conservez les données d'adaptation en couches, afin que les mises à jour ne détruisent pas les connaissances locales : une couche éditeur ou par défaut, une couche communautaire ou partagée, et une couche locale avec vos propres règles. Les couches ultérieures prennent le pas sur les précédentes, avec une option explicite pour « tout remplacer pour ce domaine ». Ne modifiez jamais directement les couches distribuées, car les mises à niveau les écrasent. La plupart des déploiements ont besoin de règles locales, car les valeurs de référence partagées ne prétendent volontairement pas tout couvrir.

## Voir aussi

- [Réglages de référence par fournisseur](https://emailmarketing.net/fr/apprendre/operations/reglages-de-reference-par-fournisseur), avec des valeurs de départ maintenues par la communauté pour chaque fournisseur
- [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip), la politique de montée en charge que ces mécanismes appliquent
- [Codes d'état étendus](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp), le vocabulaire de codes qu'analysent les règles d'automatisation
- [Erreurs SMTP de Gmail et dépannage](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/depannage-gmail)
- [Codes d'erreur SMTP de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/codes-d-erreur-smtp-de-yahoo)
- [Comcast/Xfinity](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/postmaster-comcast-xfinity)

# Réglages de référence par fournisseur

> Des valeurs de référence d'adaptation du trafic par fournisseur, maintenues par la communauté (limites de connexions, messages par connexion, débits, exigences TLS et règles de limitation automatique), tirées des fichiers d'adaptation de KumoMTA, sourcées et datées.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/reglages-de-reference-par-fournisseur

Quand vous configurez la façon dont votre MTA adapte le trafic vers chaque destination, vous avez besoin de valeurs concrètes pour commencer. Les valeurs ci-dessous proviennent des fichiers d'adaptation que le projet KumoMTA maintient publiquement. Il y a deux fichiers :

- le fichier `policy-extras/shaping.toml` maintenu par l'éditeur, avec les valeurs par défaut et les grands fournisseurs (plusieurs sections portent la mention « provided directly by », c'est-à-dire fournies directement par le fournisseur) ;
- le fichier `community/shaping.toml` alimenté par la communauté, avec d'autres fournisseurs et des règles d'automatisation pilotées par les rebonds.

**Récupérés le 2026-07-20 sur la branche `main`.** Ces valeurs évoluent quand les fournisseurs changent de politique. Considérez-les comme des points de départ attribués, à vérifier sur vos propres données de reports de remise, et non comme des faits sur les limites actuelles des fournisseurs. Voir [Réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta) pour la signification de chaque paramètre et le fonctionnement du modèle d'automatisation.

Comment lire les tableaux :

- **Regroupement MX (MX rollup)** : les limites s'appliquent à chaque **infrastructure MX de réception**, si bien que tous les domaines de destinataires qui résolvent vers le même ensemble d'hôtes MX partagent un même compartiment. Les blocs de fournisseurs sont reconnus par suffixe MX. Par exemple, tout ce dont le MX se trouve sous `.google.com` ou `.googlemail.com` compte comme « google », ce qui couvre Gmail **et** les domaines hébergés sur Google Workspace. Selon la note du fichier datée du 2024-09-03, leurs noms d'hôtes MX résolvent vers des adresses IP communes, et ils sont donc adaptés ensemble.
- **`provider_connection_limit` ou `connection_limit`** : la variante « provider » s'applique à l'ensemble du regroupement du fournisseur, et la variante simple s'applique à chaque site. Mimecast utilise délibérément des limites par site, car chaque nom de site Mimecast correspond à un parc régional de MTA distinct.
- Quand une cellule est vide, la valeur globale par défaut s'applique.

## Valeurs globales par défaut

| Paramètre | Valeur par défaut |
|---|---|
| connection_limit | 10 |
| max_connection_rate | 100/min |
| max_deliveries_per_connection | 100 |
| max_message_rate | 100/s |
| idle_timeout | 60 s |
| data_timeout / data_dot_timeout | 30 s / 60 s |
| enable_tls | Opportunistic |
| consecutive_connection_failures_before_delay | 100 |
| remember_broken_tls | 3 jours |

Une **règle d'automatisation par défaut**, pour toutes les destinations, reconnaît la famille de messages de report de remise qu'utilisent de nombreux fournisseurs : `Messages from <IP> temporarily deferred`, `All messages from <IP> will be permanently deferred`, `has been temporarily rate limited due to IP reputation`, `Unfortunately, messages from <IP> weren't sent`, `Server busy. Please try again later from`. En cas de correspondance, elle fixe `max_message_rate = 1/minute` **et** `connection_limit = 1` pendant **90 minutes**.

## Valeurs de référence par fournisseur

| Fournisseur (correspondance MX) | Limite de connexions | Livraisons par connexion | TLS | Autre |
|---|---|---|---|---|
| Google (`.google.com`, `.googlemail.com`) | 5 (pour tout le fournisseur) | 50 | **Required** : Google renvoie des échecs temporaires et limite le débit des injections sans TLS | consecutive_connection_failures_before_delay = 5 |
| Yahoo (`.yahoodns.net`) : valeurs « provided by Yahoo directly » | par défaut (10) | 20 | par défaut | |
| Microsoft grand public (`.olc.protection.outlook.com`) | 5 (pour tout le fournisseur) | 50 | par défaut | Les ensembles MX grand public, O365 et DANE sont des groupes de serveurs périphériques distincts, adaptés séparément |
| Office 365 (`.mail.protection.outlook.com`) | 5 (pour tout le fournisseur) | 50 | par défaut | |
| Office 365 DANE (`.mx.microsoft`) | 5 (pour tout le fournisseur) | 50 | par défaut | DANE laissé désactivé dans la valeur de référence (DNSSEC n'est pas prêt sur la plupart des sites) |
| Apple iCloud (`.icloud.com`) | 10 (pour tout le fournisseur) | 5 | par défaut | Nombre de livraisons par connexion très faible |
| Comcast (`comcast.net`) : « provided directly by Comcast » | 25 | 1000 | Required | idle_timeout = 30 s ; consecutive_connection_failures_before_delay = 24 |
| Mimecast (`.mimecast.com`, `.mimecast.co.za`, `.mimecast-offshore.com`) : « provided directly by Mimecast » | 10 **par site** | 100 | par défaut | Par site, pas pour tout le fournisseur (parcs régionaux) |
| mail.com : « provided directly by mail.com » | par défaut | 100 | par défaut | |
| Orange (`.orange.fr`) | 2 (pour tout le fournisseur) | 100 | Required | |
| GMX et WEB.DE (`.web.de`, `.gmx.net`) *(communauté)* | 4 | 20 | Required | consecutive_connection_failures_before_delay = 5 |
| Yahoo Japan (`yahoo.co.jp`) *(communauté)* | 2 | 20 | par défaut | max_message_rate = 10/s ; parc MX distinct de celui de Yahoo |
| Barracuda (`.barracudanetworks.com.`) *(communauté, daté du 2026-03-27)* | 10 (pour tout le fournisseur) | 15 | Required | |
| Netvigator (`.netvigator.com.`) *(communauté, daté du 2026-03-27)* | 5 (pour tout le fournisseur) | 10 | Required | |
| KPN (`.kpnmail.nl.`) *(communauté)* | 10 | 10 | Required | |
| Tencent QQ (`.qq.com`) *(communauté)* | 4 | 8 | Required | |
| NetEase 163.com (`.netease.com`) *(communauté)* | 4 | 7 | RequiredInsecure (TLS imposé, mais certificats non validés) | |
| Smarthost Mailgun (`smtp.mailgun.com`) : « provided directly by Mailgun » pour les expéditeurs qui relaient via Mailgun | 7000 | 3 | par défaut | Smarthost, pas un fournisseur de messagerie |

## Règles de limitation automatique par fournisseur (contributions de la communauté)

Le fichier communautaire ajoute ces ajustements par-dessus les valeurs de référence, en réaction aux rebonds. Un déclencheur `N/hr` signifie que la règle se déclenche dès que la réponse a correspondu N fois en une heure, et chaque action expire au bout de sa durée. Pour la signification de chaque réponse, voir les codes d'erreur de [Gmail](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/depannage-gmail), [Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/codes-d-erreur-smtp-de-yahoo), [Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs), [Apple](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/apple-icloud-mail-exigences-postmaster), [Comcast](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/postmaster-comcast-xfinity) et [GMX et WEB.DE](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/gmx-web-de-exigences-postmaster).

| Fournisseur | Réponse reconnue (expression régulière, abrégée) | Déclencheur | Action | Durée |
|---|---|---|---|---|
| Gmail | "Our system has detected that this message" | 5/h | Suspend | 1 h |
| Gmail | "Our system has detected an unusual rate" | 2/h | max_message_rate = 10/min | 30 min |
| Gmail (exemple, livré en commentaire, car il suspend des clients entiers) | "This message does not have authentication information" | Aucun | SuspendTenant | 3 h |
| Yahoo | `[TS02]` (schémas de trafic inhabituels, soumettre les IP pour examen) | 3/h | max_message_rate = 1/min | 30 min |
| Yahoo | `[TS03]` (schémas de trafic inhabituels) | 3/h | max_message_rate = 10/min | 30 min |
| Yahoo | `421 4.7.0 [TSS04]` (report, plaintes d'utilisateurs) ; figure aussi dans le fichier de l'éditeur : tout `[TS?S04]` → Suspend 2 h, sans seuil | 2/h | Suspend | 2 h |
| Yahoo | `421 4.7.0 [TSS05]` (report, plaintes d'utilisateurs) | 2/h | Suspend | 4 h |
| Yahoo | `421 [IPTS04]` | 2/h | Suspend | 2 h |
| Yahoo | `421 [IPTS05]` | 2/h | Suspend | 4 h |
| Yahoo | `553 5.7.1 [BL` (IP inscrite chez Spamhaus) | 5/h | Suspend | 2 h |
| Yahoo | "Max message per connection reached" | 3/h | max_message_rate = 10/min | 1 h |
| Yahoo Japan | "VS98-IP0 deferred" (`553 Mail from <IP> not allowed`) | 2/h | Suspend | 1 h |
| Yahoo Japan | `421 [TSS04]` ou `421 [IPTS04]` (volume ou plaintes) | 2/h | Suspend | 1 h |
| Yahoo Japan | "Timeout waiting for command" | 2/h | Suspend | 30 min |
| GMX et WEB.DE | "Too many connections" | 3/h | connection_limit = 1 | 30 min |
| GMX et WEB.DE | "Reject due to policy restrictions." | 5/h | max_message_rate = 1/min | 1 h |
| GMX et WEB.DE | "Reject due to policy violations." | 5/h | Suspend | 1 h |
| GMX et WEB.DE | `554 … Reject due to policy restrictions.` | 5/h | Suspend | 2 h |
| Outlook | "Unfortunately … part of their network is on our block list" | 5/h | Suspend | 2 h |
| Outlook | "Access denied, please try again later" | 5/h | Suspend | 1 h |
| Outlook | "Server busy. Please try again later" | 5/h | Suspend | 30 min |
| Outlook | même texte « Server busy » (seconde règle) | 3/h | max_message_rate = 1/min | 15 min |
| Outlook | "has been temporarily rate limited" | 3/h | Suspend | 30 min |
| Outlook | "exceeded the maximum number of connections" | 2/h | connection_limit = 1 | 1 h |
| Outlook | "exceeded maximum number of messages per connection" | 2/h | max_deliveries_per_connection = 2 | 1 h |
| Outlook | "Connection refused … exceed max concurrent connections. IB007" | 2/h | connection_limit = 1 | 1 h |
| Outlook | "Temporary server error. Please try again later" | 5/h | Suspend | 1 h |
| Apple | "Service unavailable - try again later" | 5/h | Suspend | 15 min |
| Apple | `[BS02] Temporary server error.` | 5/h | Suspend | 15 min |
| Apple | `[HCM1] Your mail from <IP> was deferred` | 3/h | Suspend | 15 min |
| Apple | "rejected due to having a domain present in the Spamhaus DBL" | 3/h | Suspend | 4 h |
| Comcast (fichier de l'éditeur) | `RL0000` (débit limité) | 2/h | max_connection_rate = 10000/h | 2 h |
| Comcast (fichier de l'éditeur) | `RL000010` (domaine limité) | Immédiat | SuspendTenant | 5 min |
| Orange | "Trop de connexions" | 2/h | connection_limit = 1 | 1 h |
| Orange | "Service refuse" | 2/h | Suspend | 1 h |
| Orange | "Client host blocked for spamming issues" (variante avec l'URL de réinitialisation Cloudmark) | 5/h | Suspend | 2 h |
| Orange | "Client host blocked for spamming issues … spamhaus" | 5/h | Suspend | 2 h |
| Mimecast | "Internal resource temporarily unavailable" | 3/h | Suspend | 30 min |
| Netvigator | "Too many messages for this session" | 3/h | Suspend | 30 min |
| QQ | `550 Sender frequency limited` / `550 Ip frequency limited` / `550 Connection frequency limited` / `550 Domain frequency limited` / `550 Mail content denied` | 5/h chacune | Suspend | 1 h |
| 163.com | `451 DT:SPM` (report antispam) | 5/h | Suspend | 15 min |
| 163.com | `421 Too many connections` | 2/h | connection_limit = 1 | 1 h |
| 163.com | `554 DT:SPM` | 2/h | connection_limit = 1 | 1 h |
| 163.com | `550 RP:ORQ` ou `554 HL:ITC` (limite quotidienne atteinte) | 2/h chacune | Suspend | 1 h |

## Lire la tendance

D'un fournisseur à l'autre, la logique de limitation de la communauté suit les principes de conception de [Réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta) :

- Les réponses sur des limites mécaniques (trop de connexions, ou trop de messages par session) entraînent la réduction d'un paramètre pendant environ une heure.
- Les problèmes de capacité passagers (« server busy », « service unavailable ») entraînent de courtes suspensions de 15–30 minutes.
- Les événements de réputation (reports pour plaintes d'utilisateurs, rejets pour inscription sur une liste de blocage) entraînent les suspensions les plus longues (2–4 heures), car continuer d'envoyer malgré eux aggrave la réputation.

Notez aussi à quel point les valeurs de référence sont basses par rapport à la valeur globale par défaut. Les plus grands fournisseurs sont limités à 5 connexions pour tout le fournisseur, et plusieurs fournisseurs régionaux (Orange, Yahoo Japan) à seulement 2.

## Réserves

- Les valeurs sont celles qui fonctionnaient pour les opérateurs de KumoMTA à la date de récupération. Les fournisseurs modifient leurs limites sans préavis, et la réputation de chaque adresse IP influe sur ce qu'obtient réellement un expéditeur donné. Vérifiez les valeurs sur vos propres journaux de reports de remise.
- Plusieurs entrées portent des dates dans le fichier (Barracuda et Netvigator sont datés du 2026-03-27, et la note sur le regroupement Google et Workspace est datée du 2024-09-03). Chaque ligne a sa propre fraîcheur.
- Le fichier communautaire précise explicitement que ses règles sont fournies en l'état, et qu'elles doivent être combinées avec le fichier de valeurs par défaut de l'éditeur pour une couverture complète.
- Ce sont des limites que les expéditeurs s'imposent eux-mêmes, et non des garanties publiées par les fournisseurs, sauf lorsqu'une ligne porte la mention « provided directly by » (Yahoo, Comcast, Mimecast, mail.com, Mailgun).

# Rétablissement après un incident de réputation

> La procédure de rétablissement après une compromission ou un effondrement de la réputation : sécuriser le compte, purger les files d'attente, reconstruire les listes de suppression, nouvelle chauffe ou chauffe initiale, lecture des reports de remise pendant le rétablissement, calendriers de chauffe automatisés tels que les appliquent les éditeurs, et quand remplacer ou réhabiliter une adresse IP ou un domaine.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/retablissement-apres-un-incident-de-reputation

Quand un compte ou une clé d'API compromis a fait passer du spam par votre infrastructure, ou qu'une erreur de liste ou un autre événement a fait s'effondrer la réputation de vos adresses IP ou de vos domaines, le rétablissement demande des jours ou des semaines de travail méthodique. La procédure ci-dessous couvre la séquence de rétablissement, ce qui distingue une nouvelle chauffe d'une chauffe initiale, et la façon d'interpréter les résistances des serveurs de réception pendant la reconstruction.

Pour la détection, le diagnostic et le retrait des listes de blocage, voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation). Pour construire une réputation à partir de zéro, voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip).

## Séquence de restauration après une compromission

La séquence ci-dessous combine les consignes documentées par SendGrid pour restaurer la réputation après une compromission et les pratiques courantes des fournisseurs de services de messagerie (ESP) face aux incidents. L'ordre compte, car chaque étape suppose que la précédente est terminée. Relancer une chauffe sur un compte non sécurisé ou avec une file d'attente encore sale ne fait que brûler de nouveau la réputation que vous essayez de reconstruire.

### 1. Arrêter l'hémorragie

- **Suspendez tout envoi pendant plusieurs jours.** Les consignes de SendGrid sont explicites : arrêtez les envois, pour éviter d'aggraver les dégâts de réputation, avant de tenter quoi que ce soit d'autre. Les messages envoyés pendant que les serveurs de réception vous pénalisent activement aggravent les dégâts.
- **Sécurisez le compte.** Renouvelez chaque identifiant et chaque clé d'API, révoquez les clés d'API inconnues et les accès des coéquipiers ou des sous-utilisateurs, activez et imposez l'authentification à deux facteurs (2FA), et recherchez les domaines, expéditeurs, webhooks ou modèles que l'attaquant a ajoutés. Fermez la voie de la compromission avant l'envoi du moindre message de rétablissement. Sinon, l'attaquant reprend dès que vous reprenez.
- **Purgez les files d'attente.** Videz ou supprimez tout ce qui reste en file d'attente ou en report de remise depuis la période de l'incident. Du spam reporté qui continue d'être retenté des heures ou des jours après le « rétablissement » continue de générer des plaintes, des adresses pièges touchées et des blocages à votre nom.

### 2. Reconstruire la couche de données

- **Reconstruisez les listes de suppression.** Les attaquants suppriment ou exportent souvent les listes de suppression (rebonds, plaintes, désabonnements), et les messages envoyés pendant la compromission ont généré de nouveaux rebonds et de nouvelles plaintes que vous devez respecter. Restaurez les suppressions depuis une sauvegarde, intégrez-y chaque rebond et chaque plainte de feedback loop (FBL) de la période de l'incident, et supprimez définitivement toute adresse à laquelle l'attaquant a écrit et qui ne figurait pas dans votre liste opt-in.
- **Réduisez la liste d'envoi aux destinataires récemment engagés** (« retirez de votre liste de contacts les destinataires non engagés », selon la formulation de SendGrid). Les envois de rétablissement n'utilisent que vos meilleures données, les destinataires qui ont récemment ouvert ou cliqué, exactement comme au début d'une [chauffe](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip), mais avec une marge d'erreur encore plus faible.

### 3. Revérifier l'infrastructure

- **Confirmez l'authentification de bout en bout :** SPF, DKIM et un enregistrement [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) à politique contraignante sur tous les domaines d'envoi. SendGrid classe la mise en place de DMARC sur tous les domaines d'envoi parmi les étapes essentielles de la restauration. Elle bloque la poursuite de l'usurpation de votre domaine, et montre aux serveurs de réception que vous en avez la maîtrise.
- **Vérifiez de nouveau que vous respectez les exigences des fournisseurs envers les expéditeurs de gros volumes** ([Gmail](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs), [Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs), [Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs)). C'est souvent au moment d'un incident qu'une application jusque-là latente devient effective.
- **Inscrivez-vous à tous les canaux de surveillance avant de reprendre :** [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools), [Microsoft SNDS et JMRP](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp), et la [feedback loop de plaintes de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/feedback-loop-de-plaintes-de-yahoo). Ils vous donnent le verdict de chaque fournisseur, qui décide si vous pouvez franchir chaque palier de volume.

### 4. Obtenir les retraits de liste et prévenir

- Demandez le retrait des listes de blocage en suivant la [procédure de retrait de liste](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation#blocklist-delisting-workflow), après avoir corrigé la cause profonde. La compromission est l'une des rares causes d'inscription que les opérateurs lèvent couramment et vite, dès que vous pouvez montrer que le compte est sécurisé.
- Si des blocages persistent chez un fournisseur précis après le rétablissement, contactez directement son canal postmaster ou son support, en décrivant l'incident et les corrections apportées. SendGrid recommande explicitement de demander aux équipes de support des grands fournisseurs une aide adaptée à votre cas.

### 5. Remontée progressive

- Reprenez avec une **chauffe manuelle** : de petits volumes vers des destinataires engagés, augmentés progressivement (voir les calendriers ci-dessous). Sur les plateformes à chauffe automatisée, il peut falloir réactiver l'automatisation ou replacer l'IP en chauffe. Une IP qui a conservé dans la plateforme son statut de chauffe « terminée » a tout de même perdu sa réputation auprès des serveurs de réception extérieurs.
- **Fixez les attentes** à l'aide du calendrier annoncé par SendGrid. Les mesures de réputation internes (les scores d'engagement propres à la plateforme) se rétablissent assez vite. La réputation externe auprès des serveurs des destinataires peut demander **jusqu'à un mois**, voire plus, d'envois patients et réguliers. D'après ce que documente la communauté, le rétablissement complet du placement en boîte de réception après des dégâts sévères prend **8 à 12 semaines** (voir [Retrouver le placement en boîte de réception](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation#recovering-inbox-placement)).
- Suivez en continu la qualité de l'engagement pendant la montée en charge. SendGrid désigne la **récence de l'engagement** et le **taux d'ouverture unique** comme les scores à surveiller. Sur toute plateforme, les équivalents sont les tendances des ouvertures, des clics et du taux de plaintes chez chaque fournisseur.

## Nouvelle chauffe après un incident ou chauffe initiale

La nouvelle chauffe reprend les mécanismes d'une [chauffe initiale](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip), mais la situation diffère sur des points qui changent le plan :

| Dimension | Chauffe initiale (nouvelle IP ou nouveau domaine) | Nouvelle chauffe (après un incident) |
|---|---|---|
| Réputation de départ | Légèrement négative : inconnue, et traitée avec méfiance | Activement négative : les serveurs de réception ont un historique concret de mauvais comportement lié à l'actif |
| Préalable | Rien d'autre que la configuration DNS et l'authentification | Cause profonde corrigée, files d'attente purgées, suppressions reconstruites, retraits de liste demandés. Monter en charge avant cela redéclenche les pénalités |
| Rythme | Un calendrier standard (par exemple +50 % par semaine, ou le plan par paliers d'un éditeur) | La même courbe, mais attendez-vous à devoir marquer une pause ou revenir en arrière chez certains fournisseurs. Les serveurs de réception qui vous ont bloqué vous limitent de nouveau, plus fort et plus longtemps |
| Audience | Destinataires récemment engagés | Encore plus strict : uniquement les destinataires récemment engagés, avec les flux à haut risque (reconquête, réengagement, tiers) suspendus pendant tout le rétablissement |
| Signaux qui conditionnent chaque hausse | Taux de reports de remise et d'échecs, placement en boîte de réception | Les mêmes, plus une vérification des listes de blocage avant chaque hausse. Une nouvelle inscription pendant une nouvelle chauffe est traitée plus sévèrement que la première |
| Durée | Quelques semaines jusqu'au volume complet | Confiance externe : de jusqu'à un mois (SendGrid) à 8 à 12 semaines pour le rétablissement complet du placement en boîte de réception |

Deux autres règles documentées par les éditeurs concernent la nouvelle chauffe :

- **L'inactivité remet la chauffe à zéro.** SendGrid indique que si une IP n'a pas envoyé de messages depuis **plus de 30 jours**, la chauffe doit reprendre avant le retour au volume normal. Une pause de rétablissement de plusieurs semaines crée donc à elle seule une obligation de nouvelle chauffe, indépendamment de l'incident.
- **Prévenir coûte moins cher.** Selon SendGrid, « établir une réputation positive d'expéditeur demande moins d'efforts que réparer une réputation existante » (*establishing a positive reputation as a sender takes less effort than repairing an existing reputation*). Prévoyez le temps de rétablissement en conséquence.

## Traitement des reports de remise pendant le rétablissement

Les reports de remise (échecs temporaires 4xx) sont le principal retour en temps réel pendant une remontée. Les serveurs de réception expliquent rarement une pénalité de réputation, mais ils limitent toujours le débit. Les notions ci-dessous viennent de la documentation de SendGrid sur les reports de remise, et les mécanismes valent pour tout agent de transfert de courrier (MTA).

**Ce qu'est un report de remise :** le serveur du destinataire ne peut pas accepter le message pour le moment. C'est une condition temporaire, pas un rejet, et une nouvelle tentative peut aboutir. Tous les expéditeurs reçoivent des reports de remise. Le signal tient à leur taux et à leur répartition, pas à leur existence.

**Nouvelles tentatives (mise en œuvre de SendGrid, typique des ESP) :** les messages reportés sont retentés avec un délai qui croît de façon exponentielle, **pendant 72 heures au plus**. Un message qui n'est toujours pas livré au-delà est finalisé comme bloqué ou expiré. Pendant une chauffe automatisée, une IP en chauffe qui atteint son plafond horaire cesse d'envoyer, et les autres adresses IP du compte prennent le relais. Sans adresse IP de secours, les messages sont retentés environ toutes les **15 minutes pendant 72 heures** avant d'expirer.

**Types de reports de remise.** Identifiez qui limite le débit :

| Type | Exemples de motifs | Signification pendant le rétablissement |
|---|---|---|
| Externe (à l'initiative du serveur de réception) | "IPs were throttled by recipient server" | Le fournisseur vous limite en raison de votre réputation. C'est le signal central du rétablissement |
| Externe (fondé sur une limite) | "IPs reached ISP-suggested hourly limits" | Vous avez dépassé le seuil de chauffe ou de montée en charge pour ce fournisseur. C'est un problème de rythme, pas nécessairement de réputation |
| Interne (à l'initiative de la plateforme) | "reached ISP-suggested max connection limits", "max port limit", "max connection limit" | Votre propre plateforme ralentit volontairement la livraison pour protéger la réputation. Ne luttez pas contre elle |

**Règles opérationnelles pendant une remontée :**

- **Quand le taux de reports de remise augmente chez un fournisseur, maintenez ou réduisez le volume chez ce fournisseur.** Les reports de remise sont une limitation de débit, l'étape qui précède le blocage (voir les [signaux d'alerte](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation#warning-signs-and-thresholds)). N'avancez pas dans la montée en charge tant qu'un fournisseur reporte à un taux élevé.
- **Ne forcez pas le passage malgré les reports de remise.** Ouvrir davantage de connexions, ou réinjecter les messages reportés comme de nouveaux messages, transforme la limitation de débit en blocages.
- **Pour les reports dus à une limite**, réduisez le débit de livraison, ou répartissez la livraison sur davantage d'adresses IP déjà chauffées. Pour les reports où le serveur de réception vous limite, laissez le système de nouvelles tentatives rythmer la livraison. Le tableau de corrections documenté par SendGrid indique « aucune action requise ; livraison ralentie automatiquement » (*no action required; delivery auto-slowed*).
- **Mesurez l'impact par le délai de livraison de bout en bout**, c'est-à-dire l'écart entre l'acceptation du message par votre plateforme et sa livraison finale. Des reports avec des délais de bout en bout courts signifient que la limitation absorbe votre montée en charge sans nuire aux campagnes. Des délais qui s'allongent signifient que vous montez plus vite que le serveur de réception ne l'accepte.
- **Suspendez complètement** lorsque, chez un fournisseur, les reports de remise se transforment en blocages définitifs, ou en expirations à 72 heures, dans des proportions significatives. Ce fournisseur vous dit que la réputation n'est pas prête. Ramenez le volume chez lui presque à zéro, et reconstruisez avec vos seuls destinataires les plus engagés.

## Calendriers de chauffe automatisés tels que mis en œuvre

Les automatisations des éditeurs sont des données de référence utiles pour construire votre propre logique de montée en charge. Les mécanismes sont décrits de façon conceptuelle, et chaque chiffre est attribué à son éditeur.

### Chauffe automatisée de SendGrid (calendrier de plafonds horaires sur 41 jours)

SendGrid limite une IP dédiée en chauffe par un plafond d'envoi horaire qui augmente d'environ 40 % par jour sur 42 jours (jours 0 à 41). Lorsque le plafond est atteint, l'IP en chauffe s'arrête pour le reste de l'heure, et les autres adresses IP du compte absorbent le surplus, y compris d'autres adresses IP en chauffe qui ont encore de la marge. Sans adresse IP de secours, les messages sont retentés environ toutes les 15 min pendant 72 h au plus. Après le jour 41, l'IP sort de la chauffe. Le calendrier, tel que l'éditeur le publie :

| Jour | Plafond horaire | Jour | Plafond horaire | Jour | Plafond horaire |
|-----|-----------|-----|-----------|-----|-----------|
| 0 | 20 | 14 | 2 222 | 28 | 246 953 |
| 1 | 28 | 15 | 3 111 | 29 | 345 735 |
| 2 | 39 | 16 | 4 356 | 30 | 484 029 |
| 3 | 55 | 17 | 6 098 | 31 | 677 640 |
| 4 | 77 | 18 | 8 583 | 32 | 948 696 |
| 5 | 108 | 19 | 11 953 | 33 | 1 328 175 |
| 6 | 151 | 20 | 16 734 | 34 | 1 859 444 |
| 7 | 211 | 21 | 23 427 | 35 | 2 603 222 |
| 8 | 295 | 22 | 32 798 | 36 | 3 644 511 |
| 9 | 413 | 23 | 45 917 | 37 | 5 102 316 |
| 10 | 579 | 24 | 64 284 | 38 | 7 143 242 |
| 11 | 810 | 25 | 89 998 | 39 | 10 000 539 |
| 12 | 1 000 | 26 | 125 997 | 40 | 14 000 754 |
| 13 | 1 587 | 27 | 176 395 | 41 | 19 601 056 |

SendGrid ajoute deux mises en garde. Les flux transactionnels ne doivent pas être contraints à un calendrier strict, car vous ne maîtrisez pas la fréquence de leurs déclenchements. Et aucun calendrier ne remplace les bonnes pratiques d'envoi : une montée progressive ne garantit pas à elle seule la réputation.

### Chauffe de Mailgun (modèle par paliers de volume et API)

La chauffe automatique de Mailgun repose sur des **paliers de volume** plutôt que sur des jours calendaires. Chaque palier a un plafond quotidien, et l'IP passe au palier suivant dès qu'elle a envoyé le volume du palier. La progression entre paliers et la fenêtre de 24 heures sont indépendantes : envoyer tout le volume d'un palier fait passer au suivant quel que soit le nombre d'heures écoulées, et la fenêtre de 24 heures démarre avec le premier message.

Les plafonds de palier publiés par Mailgun sont de **1 000 par jour pour le palier 1 et de 2 500 par jour pour le palier 2**. Les plafonds suivants ne sont pas publiés, et selon le modèle de calendrier de l'API, un plan peut compter jusqu'à 15 paliers. Atteindre trop tôt un plafond quotidien arrête tous les envois de cette IP jusqu'à la réinitialisation de la fenêtre de 24 heures. **Le trafic excédentaire est redirigé, pas perdu** : le volume qui dépasse le plafond de l'IP en chauffe bascule vers les adresses IP partagées du compte ou vers d'autres adresses IP dédiées. Les messages partent donc quand même, simplement pas depuis l'IP en chauffe. Une chauffe complète prend généralement **4 à 8 semaines**.

Vous pouvez piloter la chauffe par l'API (référence de l'API Mailgun, propre à cet éditeur) :

| Opération | Point de terminaison | Rôle |
|---|---|---|
| GET | `/v3/ip-warmups` | Lister l'état des chauffes d'IP en cours |
| GET | `/v3/ip-warmups/{addr}` | État d'une chauffe en cours (palier actuel, limites du palier et limites horaires, nombre total de paliers) |
| POST | `/v3/ip-warmups/{addr}` | Créer un plan de chauffe pour une IP |
| DELETE | `/v3/ip-warmups/{addr}` | Annuler le plan de chauffe |

Les consignes de Mailgun pour la chauffe manuelle (un article archivé de son centre d'aide, capture de 2023) font trois recommandations :

- Utilisez des adresses IP dédiées à partir de **100 000 emails par mois**. C'est la règle propre à Mailgun. Pour la comparer aux minimums des autres éditeurs et au plancher statistique général pour chaque IP, voir le [tableau de référence des volumes planchers pour une adresse IP dédiée](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi#dedicated-ip-volume-floors-canonical).
- Commencez à **100 emails le premier jour** et augmentez d'environ **20 % par jour**, en envoyant chaque jour. Envoyer trois fois par semaine ou moins fonctionne, mais construit la confiance plus lentement.
- N'utilisez pas du tout de domaines de **moins de 30 jours**. Les serveurs de réception associent les domaines fraîchement achetés aux spammeurs qui changent de domaine dès qu'un domaine est grillé.

**Conséquences pour concevoir votre propre automatisation de montée en charge.** Les deux mises en œuvre s'accordent sur quatre points. Plafonnez l'actif en chauffe au lieu de mettre les messages en file d'attente et de forcer, et faites passer le surplus par un chemin déjà chauffé. Augmentez les plafonds de façon géométrique (environ 20 à 50 % par jour). Faites dépendre la progression du volume effectivement envoyé, et pas seulement du temps écoulé. Et traitez les résistances des serveurs de réception (les reports de remise) comme une condition d'arrêt que l'automatisation doit respecter.

## Remplacer ou réhabiliter ? Points de décision

Après un incident grave, le raccourci tentant est de passer à une nouvelle adresse IP ou à un nouveau domaine. La réponse par défaut est de **réhabiliter**, car le remplacement échappe rarement au problème :

- **Les nouveaux actifs partent d'une réputation négative, pas neutre.** Les serveurs de réception présument qu'une nouvelle IP appartient à un spammeur bloqué qui a déménagé (voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)), et ils considèrent les domaines de moins de 30 jours environ comme le signe de spammeurs qui font tourner leurs domaines (Mailgun). Changer d'actifs est exactement le schéma que les filtres sont conçus pour repérer.
- **La réputation suit les messages, pas seulement l'actif.** La réputation du domaine, les empreintes de contenu et la qualité de la liste vous suivent sur la nouvelle IP. Si la cause profonde n'est pas corrigée, le nouvel actif se grille plus vite que l'ancien ne s'est rétabli.
- **Les inscriptions dues à une compromission se lèvent vite.** Les opérateurs de listes de blocage et les fournisseurs annulent couramment les inscriptions causées par une compromission documentée et corrigée : dans ce scénario, la réhabilitation est donc une option réelle (voir la [procédure de retrait de liste](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation#blocklist-delisting-workflow)).

Le remplacement, avec une chauffe complète à partir de zéro, n'est le bon choix que lorsque la réhabilitation est impossible ou coûte plus cher que de repartir de zéro :

| Facteur | En faveur de la réhabilitation | En faveur du remplacement |
|---|---|---|
| Statut d'inscription | Retrait de liste possible ; l'opérateur réagit aux preuves de correction | Inscription permanente ou répétée après des demandes mal menées ; l'actif figure sur des listes sans moyen réaliste d'en être retiré |
| Profondeur de l'historique | Un incident court sur un actif par ailleurs sain | Un long historique d'abus antérieur à votre arrivée (par exemple une IP ou un domaine hérité qui avait déjà été utilisé de façon abusive) |
| Réaction des fournisseurs après correction | Reports de remise en baisse, et tableaux de bord de réputation qui se redressent en quelques semaines | Blocages définitifs persistants chez les grands fournisseurs malgré une nouvelle chauffe propre sur plusieurs semaines |
| Rôle de l'actif | Le domaine principal de la marque (réputation organique et intrinsèque, Brand Indicators for Message Identification (BIMI), reconnaissance par les clients : pratiquement irremplaçable) | Une IP d'envoi dédiée ou un sous-domaine d'envoi, peu coûteux à remplacer et à chauffer de nouveau |
| Économie du temps | Rétablissement prévu en un temps à peu près égal ou inférieur à celui d'une chauffe (une nouvelle chauffe sur un actif réhabilité peut aller plus vite que les 4 à 8 semaines, voire plus, d'une chauffe initiale) | Rétablissement au point mort au-delà du calendrier d'une chauffe initiale |

Pour les domaines, il existe une voie médiane pratique. Ne remplacez jamais le domaine organisationnel. Réhabilitez-le, et faites passer les flux d'emails sur un sous-domaine neuf, correctement délégué et chauffé à partir de zéro. Cela isole les dégâts sans la pénalité d'un nouveau domaine. Pour les mécanismes d'isolation des flux, voir [Meilleures pratiques M3AAWG pour les domaines d'envoi](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-domaines-d-envoi) et [Segmentation avancée des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip). Quel que soit l'actif remplacé, retirez proprement l'actif grillé, en le gardant authentifié et en laissant en place ses enregistrements DNS de protection (voir [Protection de la marque : gestion des domaines](https://emailmarketing.net/fr/apprendre/reference/protection-de-la-marque-gestion-des-domaines)).

## Voir aussi

- [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation), y compris la procédure de rétablissement fondée sur les segments engagés
- [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)
- [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi), sur la stratégie de sous-domaines et la chauffe des domaines
- [Listes de blocage DNS et zones Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus)
- [Emails obligatoires et réglementaires](https://emailmarketing.net/fr/apprendre/operations/emails-obligatoires-et-reglementaires), pour les envois qui ne peuvent pas attendre la fin d'une période de rétablissement

# Surveillance et rétablissement de la réputation

> Comment les expéditeurs surveillent en pratique la réputation de leurs IP et de leurs domaines : surveillance des listes de blocage, tests sur liste de test et de placement en boîte de réception, tableaux de bord des fournisseurs, feedback loops, signaux d'alerte, et procédure de retrait de liste et de rétablissement.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation

Votre réputation d'expéditeur peut se dégrader à tout moment, et les conséquences s'aggravent alors du classement en dossier spam à l'inscription sur des listes de blocage, puis au rejet pur et simple. Voici comment surveiller la réputation en continu, et que faire lorsqu'elle baisse.

La réputation d'expéditeur fonctionne comme une cote de crédit. Sans historique d'envoi, vous n'avez ni mauvaise ni bonne réputation : un historique de performances doit exister avant que les fournisseurs de messagerie vous accordent du « crédit », sous la forme d'une tolérance envers votre volume et d'un placement en boîte de réception. La réputation n'est pas figée. Pour savoir de quoi la réputation est faite, voir [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email). Pour la construire sur de nouvelles adresses IP, voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip).

## Livraison et délivrabilité : pourquoi surveiller

- **Livraison** : le serveur de réception a accepté le message (visible dans vos journaux sous la forme d'un 250 OK).
- **Délivrabilité** : l'endroit où le message a atterri après son acceptation. Il peut s'agir de la boîte de réception, d'un onglet comme Promotions ou Updates, du dossier spam, ou de nulle part, parce que le message a été supprimé en silence (« manquant »).

Confirmer la livraison grâce aux réponses SMTP est simple. Connaître le placement est beaucoup plus difficile, car chaque fournisseur de messagerie applique, après avoir accepté un message, ses propres algorithmes d'acheminement et de filtrage, qui ne sont pas publics. Un message qui arrive en boîte de réception chez Yahoo peut partir dans le dossier spam chez Gmail ou Microsoft. Sans données de placement, les problèmes de délivrabilité sont difficiles à détecter et à diagnostiquer : les indicateurs d'engagement baissent en silence tandis que le taux de livraison reste élevé.

Quelle part des messages disparaît réellement : l'étude de référence 2026 de Litmus a constaté que **87,25 %** des emails marketing légitimes atteignaient la boîte de réception (environ **1 sur 7 n'y arrive donc jamais**), avec de fortes différences selon le fournisseur :

| Fournisseur | Part de marché | Taux de boîte de réception | Taux de spam | Manquants |
|---|---|---|---|---|
| Gmail | 42,9 % | 89,8 % | 6,4 % | 3,8 % |
| Yahoo | 15,7 % | 87,3 % | 6,4 % | 6,3 % |
| Microsoft | 14,4 % | 77,4 % | 15,1 % | 7,5 % |
| Apple | 3,6 % | 82,0 % | 10,8 % | 7,2 % |

Pour un ensemble plus large de valeurs de référence, datées et attribuées à leurs éditeurs, auxquelles comparer vos propres chiffres, voir [Valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/reference/valeurs-de-reference-chiffrees-de-la-delivrabilite). Il couvre le placement mesuré par Validity sur liste de test par fournisseur, pays, région et secteur, ainsi que les taux d'engagement de chaque secteur.

## La pile de surveillance

Un programme efficace de surveillance de la réputation combine cinq sources de données indépendantes. Aucune ne suffit à elle seule.

### 1. Vos propres indicateurs d'engagement et de livraison

Les premiers signaux d'alerte se trouvent dans des données que vous avez déjà. Suivez ces indicateurs pour chaque fournisseur de messagerie, et pas seulement de façon agrégée :

- Taux d'ouverture, taux de clics et taux de conversion. Une baisse significative chez un fournisseur alors que les autres restent stables est le signe classique d'un placement dans le dossier spam de ce fournisseur.
- Taux de rebonds, ventilé par catégorie (adresse invalide, blocage par la politique du serveur, blocage pour réputation, temporaire).
- Taux de désabonnement et taux de plaintes pour spam.
- Messages supprimés sans avoir été lus, réponses et transferts, lorsque ces données sont disponibles.

Regardez **les tendances d'une semaine sur l'autre**, et non le bruit quotidien. Les fournisseurs de messagerie fondent leurs décisions sur des tendances dans le temps, et les indicateurs quotidiens sont trop volatils pour justifier une action. Les filtres antispam recourent de plus en plus à un apprentissage automatique qui s'ajuste en temps réel : l'objectif est donc de repérer une tendance avant qu'elle ne devienne un problème.

### 2. Surveillance des listes de blocage (DNSBL et RBL)

Une liste de blocage, qu'il s'agisse d'une DNSBL (DNS-based Block List) ou d'une RBL (Realtime Block List), est une liste interrogeable d'adresses IP (et parfois de domaines, d'URL ou de noms d'utilisateur) soupçonnées d'envoyer du spam. Deux faits déterminent la façon de s'en servir :

- **Les listes de blocage ne bloquent rien par elles-mêmes.** Les fournisseurs de messagerie utilisent les données des listes de blocage **en complément de leurs propres indicateurs internes** pour décider de ce qu'ils bloquent. Une inscription est une donnée d'entrée, pas un verdict.
- **Toutes les listes n'ont pas le même poids.** Il existe des centaines de DNSBL, et la plupart ont un impact négligeable. Chaque fournisseur accorde du poids à des listes différentes, et Gmail ignore largement les listes de blocage tierces au profit de ses propres systèmes.

Voici les listes qui méritent d'être surveillées, à peu près par ordre d'impact :

| Liste de blocage | Remarques |
|---|---|
| Spamhaus | La plus influente ; utilisée par la majorité des fournisseurs d'accès et des fournisseurs de services de messagerie |
| SpamCop | Fondée sur les signalements des utilisateurs de SpamCop ; impact modéré |
| Barracuda Reputation Block List | Largement consultée |
| Invaluement | Liste antispam d'adresses IP et de domaines, sur abonnement |
| SORBS | Impact plus faible ; encore surveillée par certains serveurs de réception |

En pratique, les blocages pour réputation apparaissent comme **des événements d'échec ou de rebond dans vos journaux de livraison**. Lisez le texte complet du rejet SMTP, qui nomme généralement la liste de blocage. Des interrogations DNSBL automatiques et régulières sur toutes vos adresses IP et tous vos domaines d'envoi détectent les inscriptions avant que les serveurs des destinataires ne le fassent.

### 3. Tableaux de bord des fournisseurs de messagerie (outils postmaster)

Les grands fournisseurs vous montrent directement comment le côté réception voit votre réputation :

- **Google Postmaster Tools** : notes de réputation du domaine et des adresses IP, taux de plaintes pour spam, taux de réussite SPF, DKIM et DMARC, et erreurs de livraison pour les messages envoyés à Gmail.
- **Microsoft SNDS (Smart Network Data Services)** : données par adresse IP sur les messages envoyés aux domaines grand public de Microsoft, dont le volume, le verdict du filtre (vert, jaune ou rouge), le taux de plaintes et les adresses pièges touchées.

Ces outils sont gratuits. Configurez-les avant que les problèmes surviennent, car ils fournissent un historique que vous ne pourrez pas reconstituer après coup.

### 4. Tests sur liste de test et de placement en boîte de réception

Un test sur liste de test envoie une campagne à un panel de boîtes de test réparties chez différents fournisseurs, et indique où chaque copie a atterri : la boîte de réception, le spam, un onglet précis de Gmail (Primary, Promotions, Updates, Social ou Forums), ou nulle part. Les outils commerciaux (par exemple Litmus Spam Testing, Mailgun Inbox Placement et Everest de Validity) fournissent :

- **Le taux de placement en boîte de réception (IPR)** : le pourcentage d'emails livrés avec succès qui atteignent la boîte de réception plutôt que le spam, ventilé par fournisseur.
- Des analyses avant envoi face aux principaux filtres antispam commerciaux, ainsi que des vérifications de listes de blocage et d'authentification (validation SPF, DKIM et DMARC).
- Une prédiction de l'onglet Gmail pour un message donné.

Les tests sur liste de test ont des limites. Les panels de test ne peuvent pas mesurer l'engagement de vrais destinataires, et les boîtes de test n'ont aucun historique d'engagement avec vous : les résultats penchent donc vers la prudence. Servez-vous-en pour isoler les problèmes de contenu, de modèle ou d'infrastructure. Testez une variable à la fois, car les tests de contenu sont surtout utiles lorsqu'ils portent sur des messages précis. Combinez les résultats avec vos données d'engagement réelles pour avoir une vue complète.

### 5. Feedback loops (FBL)

La plupart des grands fournisseurs de messagerie proposent des feedback loops qui indiquent quels destinataires ont marqué vos messages comme spam. S'y inscrire compte pour votre délivrabilité globale. Les données des FBL vous permettent de supprimer immédiatement les personnes qui se plaignent (voir [le traitement des suppressions](#les-listes-de-suppression-comme-défense-de-la-réputation)), et elles mesurent les retours négatifs pour chaque fournisseur. Vérifiez si votre plateforme d'envoi vous inscrit automatiquement ou si vous devez le faire vous-même. **Si vous ignorez les retours des FBL, votre réputation chute fortement, et vos envois sont soumis à une limitation de débit ou entièrement bloqués.**

<a id="warning-signs-and-thresholds"></a>
## Signaux d'alerte et seuils

Le tableau ci-dessous donne les seuils de fonctionnement que publie Klaviyo, et qui s'appliquent quelle que soit la plateforme que vous utilisez. Ce sont **les chiffres maison de Klaviyo**, délibérément plus stricts que le consensus des différentes sources. Pour l'éventail des valeurs attribuées, et les limites d'application que publient d'autres fournisseurs, voir le [tableau de référence des seuils](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite#canonical-threshold-table) :

| Indicateur | Objectif de Klaviyo | Signal en cas de dépassement |
|---|---|---|
| Taux d'ouverture | ≥ 33 % (brut, ouvertures par des machines incluses) | Liste peu engagée, ou placement dans le dossier spam |
| Taux de clics | ≥ 1 % | Contenu ou appel à l'action faible, ou problème de placement si les ouvertures ont aussi baissé |
| Taux de rebonds | < 1,0 % | Liste non nettoyée ; les fournisseurs y voient une mauvaise pratique |
| Taux de désabonnement | < 0,3 % | Attentes non satisfaites, ou fréquence trop élevée |
| Taux de plaintes pour spam | < 0,01 % | Le signal le plus dommageable |

Sur les plaintes en particulier, le **< 0,01 %** de Klaviyo est un chiffre maison prudent. L'objectif plus largement partagé dans le secteur est **< 0,1 %** (AWS SES, Postmark, SendGrid), et le plafond de **0,3 %** fixé par Gmail et Yahoo est une limite stricte à ne jamais atteindre. Le [tableau de référence des seuils](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite#canonical-threshold-table) met tous ces chiffres en regard. L'objectif de taux d'ouverture de Klaviyo est un chiffre **brut**, qui inclut les ouvertures par des machines et que gonfle Apple Mail Privacy Protection (MPP). Ne le comparez pas à un taux dont les robots ont été filtrés.

D'autres signaux d'alerte précèdent une perte de réputation :

- **Les pics de volume.** Tripler votre volume d'envoi habituel peut déclencher la détection de comptes compromis chez les fournisseurs, et les hausses soudaines attirent le filtrage quelle que soit la qualité du contenu. Gardez des envois réguliers, et montez en charge progressivement pour les hausses importantes prévues (voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)).
- **La hausse des rebonds temporaires ou des reports de remise chez un fournisseur.** C'est souvent une limitation de débit, l'étape qui précède le blocage.
- **Les adresses pièges touchées** (visibles dans SNDS). Elles prouvent une mauvaise acquisition des adresses ou une mauvaise hygiène, et les fournisseurs d'accès signalent les expéditeurs dont le trafic touche une proportion d'adresses pièges supérieure à la normale.
- **Une baisse de la qualité de base de votre liste.** Les bases marketing se dégradent d'environ **22 % par an** (les adresses changent, les gens changent d'emploi, des boîtes sont abandonnées) : une liste qui n'est pas activement entretenue dérive donc toujours vers les problèmes.

<a id="suppression-lists-as-a-reputation-defense"></a>
## Les listes de suppression comme défense de la réputation

La suppression automatique transforme les signaux négatifs en protection. Voici les mécanismes standard, tels que les grandes plateformes d'envoi les mettent en œuvre ; reproduisez-les sur toute infrastructure :

- **Rebonds définitifs** (permanents, comme une adresse invalide) : supprimez immédiatement et définitivement.
- **Rebonds temporaires** (comme une boîte pleine ou un serveur hors service) : supprimez après plusieurs échecs consécutifs (par exemple 7 rebonds temporaires consécutifs).
- **Plaintes pour spam** (issues des FBL) : supprimez immédiatement, et n'écrivez plus jamais à cette personne. Un rejet comme « not delivering to a user who marked your messages as spam » montre que le système de suppression fonctionne comme prévu : ne le contournez pas.
- **Désabonnements** : supprimez immédiatement des emails marketing. Les emails transactionnels (confirmations de commande, d'expédition ou de modification du compte) ne dépendent pas du statut d'abonnement et peuvent encore être envoyés aux destinataires supprimés. Les séries de bienvenue, les relances après abandon de panier et les messages de retour en stock relèvent toutefois du marketing, et non du transactionnel.

Ces mécanismes s'accordent avec la règle de retrait des *Sender Best Common Practices* du Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) (version 4.0, août 2026, section 2.2). Le M3AAWG considère comme une meilleure pratique de retirer une adresse qui produit un rebond au moins deux fois de suite, sur une période de deux semaines ou plus, quels que soient le code ou le texte de l'échec, et laisse à chaque expéditeur le soin de fixer le nombre exact et la durée. L'exemple de rebonds temporaires ci-dessus est le réglage de la plateforme Klaviyo. Ce nombre est supérieur au minimum de deux fixé par le M3AAWG : il respecte donc la règle, tout en attendant plus longtemps avant de retirer une adresse. Comptez un rebond par campagne plutôt qu'un par nouvelle tentative, puisque la règle du M3AAWG porte sur des campagnes consécutives.

Deux précautions empêchent la règle de retirer de bons abonnés :

- **« Rebond définitif » ci-dessus désigne un échec lié à l'adresse**, comme un utilisateur inconnu. Le M3AAWG demande aussi aux expéditeurs de lire le texte du rebond, car le code seul ne dit pas s'il faut retirer l'adresse, et le texte peut révéler l'inscription de l'expéditeur sur une liste de blocage. Un refus définitif pour des raisons de politique ou de réputation (un code `5.7.x`) concerne généralement vos envois, et non le destinataire. Examinez-le au lieu de supprimer l'adresse.
- **Ne comptez pas les rebonds reçus pendant une période où vous étiez bloqué** dans le compteur de retrait d'une adresse. Ils ne disent rien des adresses.

[Codes d'état étendus SMTP](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp#les-codes-détat-et-la-règle-de-retrait-du-m3aawg) indique comment appliquer la règle du M3AAWG à chaque classe de code.

## Rétablissement lorsque la réputation baisse

### Diagnostic méthodique (dans l'ordre)

1. **Vérifiez l'infrastructure et l'authentification.** SPF, DKIM et DMARC doivent réussir et être alignés (voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)). Un écart entre le domaine From et le domaine d'envoi réel (même `mail.example.com` par rapport à `example.com`) suffit pour que certains serveurs de réception classent les messages en spam ou les rejettent.
2. **Consultez les listes de blocage** pour chaque adresse IP et chaque domaine d'envoi, et lisez les textes de rejet dans vos journaux.
3. **Consultez les tableaux de bord des fournisseurs.** La réputation du domaine ou des adresses IP s'est-elle dégradée, et quand ? Rapprochez la date des changements de campagne ou de liste.
4. **Examinez les changements de segmentation et de liste.** Une nouvelle source d'acquisition, une liste importée ou une campagne vers des contacts inactifs depuis longtemps est le déclencheur le plus courant.
5. **Évaluez le contenu et le calendrier.** Soumettez le message problématique à un test sur liste de test ou à un test antispam pour distinguer les problèmes de contenu des problèmes de réputation.
6. **Suivez l'évolution des plaintes d'une semaine sur l'autre** pour confirmer que vos changements portent leurs fruits.

<a id="blocklist-delisting-workflow"></a>
### Procédure de retrait d'une liste de blocage

1. **Identifiez la liste et l'actif inscrit** (une adresse IP ou un domaine) à partir des messages de rejet ou des interrogations DNSBL.
2. **Trouvez et corrigez d'abord la cause profonde.** Demander un retrait de liste est délicat. Si vous demandez le retrait sans changer le comportement qui a causé l'inscription, vos demandes futures perdent en crédibilité, et des demandes répétées mal gérées peuvent aboutir à une inscription **permanente**. Les causes typiques sont une mauvaise source d'acquisition, des adresses pièges touchées, un compte ou un formulaire compromis, et un pic de plaintes.
3. **Suivez la procédure de retrait propre à cette liste.** Chaque DNSBL gère les retraits différemment, avec des délais différents. Certaines laissent les inscriptions expirer automatiquement ; d'autres exigent une demande accompagnée de preuves de la correction.
4. **Si vous envoyez via un fournisseur partagé**, son équipe abuse ou conformité a souvent déjà engagé le retrait. Coordonnez-vous avec elle plutôt que de déposer des demandes en double. Des relations établies avec les opérateurs de listes de blocage accélèrent nettement la résolution.
5. **Après le retrait, continuez de surveiller.** Une inscription qui revient peu après un retrait est traitée plus sévèrement.

<a id="recovering-inbox-placement"></a>
### Retrouver le placement en boîte de réception

Le rétablissement est lent, et les fournisseurs ne l'expliquent pas. Ils exigent une **amélioration durable des signaux** avant de modifier le placement, et lorsque les dégâts sont profonds, des sous-domaines et des adresses IP entiers peuvent devenir pratiquement inutilisables. La méthode éprouvée consiste à réduire vos envois à vos destinataires les plus engagés, puis à reconstruire :

- Cessez d'envoyer à quiconque ne fait pas partie des segments récemment engagés. C'est une nouvelle chauffe, qui suit la même logique qu'une [chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip).
- Suspendez les flux à haut risque pendant le rétablissement : les envois pour des tiers ou des partenaires, et les flux de reconquête, de mise en sommeil et de réengagement.
- Corrigez la cause profonde que vous avez diagnostiquée (la source de la liste, le contenu ou l'authentification).
- Comptez **8 à 12 semaines** pour revenir pleinement en boîte de réception. C'est le délai de rétablissement que Litmus a documenté pour lui-même après s'être concentré sur les abonnés engagés.
- En palliatif pour les messages critiques, demandez aux destinataires d'ajouter votre **domaine d'envoi** à leurs expéditeurs approuvés. Leur demander d'ajouter une adresse IP à leur liste blanche n'a de sens que pour les adresses IP dédiées, car les attributions d'adresses IP partagées sont en pratique dynamiques.

## Voir aussi

- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email), sur les signaux à partir desquels la réputation est calculée
- [Les deux mondes de la délivrabilité email](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email), sur les raisons pour lesquelles un rétablissement fondé sur l'engagement fonctionne et le contournement du système échoue
- [Contenu et design au service de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite), sur les facteurs liés au contenu que révèlent les tests sur liste de test
- [Segmentation avancée des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip), sur la façon de contenir les dégâts de réputation en isolant les flux d'emails

# Google Postmaster Tools

> Ce que propose Google Postmaster Tools — inscription, chacun des tableaux de bord (conformité, taux de spam, réputation, boucle de rétroaction, authentification, chiffrement, erreurs de distribution) et comment les interpréter.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools

Si vous envoyez des messages à des utilisateurs de Gmail, Google Postmaster Tools vous montre comment Gmail perçoit vos messages. C'est la console de surveillance gratuite que Google met à la disposition des expéditeurs, à l'adresse https://postmaster.google.com/ (une connexion avec un compte Google est nécessaire). Une fois la propriété d'un domaine validée, vous disposez de tableaux de bord sur le taux de spam, la réputation des adresses IP et des domaines, la réussite de l'authentification, le chiffrement, les erreurs de distribution, les données de feedback loop et la conformité aux [exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs).

Les libellés d'interface cités ici sont ceux de l'interface française de Postmaster Tools, tels que les nomme le centre d'aide de Google (orthographe email harmonisée), avec le libellé anglais entre parenthèses.

**Toutes les données portent uniquement sur les messages envoyés à des comptes Gmail personnels** (`@gmail.com` et `@googlemail.com`), et non sur les destinataires Google Workspace.

## Inscription

Prérequis : un compte Google ou Google Workspace. Le domaine que vous ajoutez doit être le **domaine DKIM `d=` ou le domaine SPF (Return-Path)** qui authentifie vos messages.

1. **Ajoutez le domaine** : connectez-vous sur postmaster.google.com, cliquez sur **Ajouter un domaine** (*Add*), puis saisissez le domaine d'authentification.
2. **Validez la propriété** : copiez l'enregistrement TXT fourni dans le DNS du domaine, puis cliquez sur **Valider** (*Verify*). La validation est généralement immédiate, et prend jusqu'à ~10 minutes. Les tableaux de bord n'affichent aucune donnée tant que le domaine n'est pas validé.
3. **Accordez un accès (facultatif)** : **Gérer les domaines** > **Autres options** > **Gérer les utilisateurs** > **Ajouter**, puis saisissez une adresse email Google (*Manage Domains > More > Manage > Add*). Vous pouvez partager un accès en lecture, mais la personne à qui vous l'accordez n'est pas prévenue automatiquement.

Problèmes courants : la validation échoue à cause du délai de propagation DNS ou d'une faute de frappe dans l'enregistrement (réessayez, ou générez une nouvelle chaîne) ; la personne à qui vous accordez un accès doit avoir un compte Google ; et l'absence de données dans un tableau de bord signifie généralement que votre volume est trop faible pour dépasser le seuil de confidentialité.

## Caractéristiques des données

- Les données sont mises à jour **chaque jour**, généralement sous 24 heures. L'état de conformité peut mettre jusqu'à **7 jours** à refléter un changement.
- Les horodatages sont en **UTC**.
- Vous pouvez choisir des périodes de **7, 30, 60, 90 ou 120 jours**.
- Les jours de **faible volume sont omis** pour protéger la vie privée des utilisateurs, donc un trou ne signifie pas zéro.
- Google tente d'**exclure les messages transférés** des données, mais certains peuvent encore apparaître dans les tableaux de bord.
- Les messages non authentifiés sont en grande partie invisibles : la plupart des tableaux de bord ne couvrent que les messages qui ont passé SPF ou DKIM pour le domaine validé.

## Tableaux de bord

### État de conformité (*Compliance status*)

Ce tableau de bord vérifie chaque exigence des consignes de Google pour les expéditeurs d'emails (*Email Sender Guidelines*) et lui attribue l'état **Conforme** (*Compliant*), **Améliorations nécessaires** (*Needs work*) ou **Aucune donnée trouvée** (*No data found*, volume insuffisant).

- Pour tous les expéditeurs, il vérifie l'authentification SPF et DKIM, les enregistrements DNS (PTR), la mise en forme des messages, le chiffrement TLS et le taux de spam signalé par les utilisateurs.
- Pour les expéditeurs de gros volumes (environ 5 000 messages par jour ou plus), il vérifie aussi DMARC, la prise en charge du désabonnement en un clic et le respect des désabonnements.

La conformité est affichée pour le **domaine principal**, mais le trafic du domaine principal comme celui de ses sous-domaines entre dans le calcul. Comptez jusqu'à 7 jours après une correction pour que l'état change.

### Taux de spam (*Spam rate*)

C'est le pourcentage, jour par jour, de vos messages livrés que les utilisateurs de Gmail **marquent eux-mêmes comme spam**. Restez **sous 0,10 %**, et n'atteignez jamais **0,30 %** ([détail des seuils](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs)).

Une mise en garde est essentielle pour lire ce chiffre : le dénominateur est le volume de messages livrés en boîte de réception. Comme le dit Google, « si Gmail envoie automatiquement un nombre important de vos messages dans le dossier spam, le taux affiché dans le tableau de bord peut sembler faible ». Vous pouvez donc avoir à la fois un taux de spam bas et un mauvais placement en boîte de réception, alors lisez ce tableau de bord avec ceux de la réputation.

### Réputation des adresses IP et Réputation des domaines (*IP reputation*, *Domain reputation*)

Les deux tableaux de bord utilisent la même échelle de quatre niveaux :

| Niveau | Signification |
|---|---|
| **Haute** (*High*) | Taux de spam très bas ; respecte les consignes de Google pour les expéditeurs d'emails ; messages rarement filtrés |
| **Moyenne** (*Medium*) | Connu pour envoyer des messages légitimes, avec du spam occasionnel en faible volume ; délivrabilité correcte |
| **Basse** (*Low*) | Historique important d'envoi de spam ; messages probablement marqués comme spam |
| **Mauvaise** (*Bad*) | Volume de spam élevé ; messages presque toujours marqués comme spam ou rejetés dès la session SMTP |

La réputation des domaines ne couvre que les messages authentifiés avec le **domaine DKIM ou SPF exact que vous avez validé**. Rétablir la réputation prend du temps et exige un envoi soutenu qui respecte les règles ; il n'existe pas de raccourci. Les deux tableaux de bord séparent les problèmes d'infrastructure (adresse IP) des problèmes de marque ou de contenu (domaine). Voir [segmentation avancée des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip) pour exploiter délibérément cette séparation.

### Boucle de rétroaction (*Feedback loop*, FBL)

La feedback loop (FBL) de Gmail est **agrégée, et non message par message** : elle ne renvoie pas de signalements de plainte individuels. Les expéditeurs ajoutent plutôt un en-tête `Feedback-ID:`, et Postmaster Tools indique le **taux de spam moyen par identifiant et par jour**, ainsi que le volume d'identifiants uniques signalés.

Format de l'en-tête :

```
Feedback-ID: a:b:c:SenderId
```

- `SenderId` (le champ le plus à droite) est **obligatoire**, compte de 5 à 15 caractères, et doit être unique et stable pour chaque expéditeur.
- `a`, `b` et `c` sont jusqu'à trois champs personnalisés facultatifs (par exemple la campagne, le client ou le flux d'emails). Les données sont agrégées sur les 4 premiers champs séparés par des deux-points, comptés à partir de la droite.
- Ne réutilisez pas la même valeur d'identifiant dans des champs différents, car les agrégats se mélangeraient. N'utilisez pas de valeurs propres à chaque message, comme un Message-ID, car chaque identifiant a besoin d'un volume quotidien suffisant et d'assez de signalements de spam distincts pour produire des données.

Pour obtenir des données de FBL, votre trafic doit être signé DKIM par un domaine que vous contrôlez, ce domaine doit être validé dans Postmaster Tools, et vos adresses IP d'envoi doivent figurer dans l'enregistrement SPF avec des enregistrements PTR valides. Le tableau de bord peut afficher les données par domaine de l'en-tête `From:`, ou pour l'ensemble des domaines de signature DKIM. Les données de FBL ne couvrent que les destinataires @gmail.com.

L'usage principal est d'identifier précisément quelle campagne, quel client ou quel flux génère les plaintes. C'est particulièrement important pour les ESP dont les clients partagent des domaines.

### Authentification (*Authentication*)

Ce tableau de bord indique, jour par jour, le pourcentage des messages tentés qui ont passé **SPF**, **DKIM** et **DMARC**. Les expéditeurs correctement configurés atteignent généralement **≥95 %** de réussite pour DKIM et DMARC. Les taux SPF sont naturellement plus bas, car la livraison par des tiers et le transfert cassent SPF, qui vérifie le chemin (voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)). Les domaines qui n'envoient pas d'emails n'affichent aucun résultat.

Pour diagnostiquer un taux faible :

- Pour DKIM, vérifiez la mise en forme de l'enregistrement TXT, l'exactitude de la clé, ainsi que le TTL et l'expiration DNS.
- Pour SPF, vérifiez la syntaxe de l'enregistrement, et que chaque adresse IP ou service d'envoi autorisé y figure.
- Pour DMARC, assurez-vous d'abord que SPF ou DKIM passe, et envisagez l'alignement souple.

### Chiffrement (*Encryption*)

Ce tableau de bord indique le pourcentage du trafic envoyé en **TLS entrant** (vos messages qui arrivent chez Gmail par TLS) et en **TLS sortant**. TLS est une exigence ferme des consignes pour les expéditeurs, donc ce taux doit être à 100 % ou presque.

### Erreurs de distribution (*Delivery errors*)

Ce tableau de bord indique le pourcentage des messages **authentifiés** qui ont été rejetés ou ont échoué temporairement, par rapport à l'ensemble des messages authentifiés, avec une ventilation par motif d'erreur :

| Motif d'erreur | Cause type | Action |
|---|---|---|
| Fréquence maximale dépassée (*Rate limit exceeded*) | Rythme d'envoi anormalement élevé | Arrêtez, puis reprenez lentement (nouvelle [chauffe](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)) |
| Suspicion de spam (*Suspected spam*) | Message classé comme spam probable | Généralement une réputation basse ; si le problème persiste sur des messages conformes, passez par le formulaire d'escalade de Google pour les expéditeurs de gros volumes |
| Emails pouvant contenir du spam (*Email content is possibly spammy*) | Contenu signalé | Revoyez le contenu ; utilisez le formulaire d'escalade si nécessaire |
| Pièce jointe incorrecte ou non compatible (*Bad or unsupported attachment*) | Type de fichier bloqué | N'envoyez que des types de pièces jointes que Gmail accepte |
| Règles DMARC du domaine d'envoi (*DMARC policy of the sender domain*) | Votre propre politique DMARC (`p=reject` ou `quarantine`) rejette vos messages | Consultez les rapports agrégés DMARC ; envisagez `p=none` le temps de corriger l'alignement |
| L'adresse IP d'envoi a une mauvaise réputation, ou le domaine d'envoi a une mauvaise réputation (*Low IP reputation*, *Low domain reputation*) | Niveau de réputation insuffisant | Corrigez la cause profonde et reconstruisez la réputation |
| L'adresse IP figure dans une ou plusieurs RBL, ou le domaine figure dans une ou plusieurs listes noires publiques (*IP in one or more public RBLs*, *Domain in RBLs*) | Inscription sur une liste de blocage publique | Demandez le retrait à l'opérateur de la liste de blocage |
| Enregistrement PTR incorrect ou manquant (*PTR record missing*) | Pas de DNS inverse | Ajoutez un enregistrement PTR (vérifiez-le avec l'outil Dig de Google Admin Toolbox) |

Attention : dans ce tableau, « mauvaise réputation » est le libellé de Google pour une réputation *Low*, qui correspond au niveau **Basse** des tableaux de bord de réputation, et non au niveau **Mauvaise** (*Bad*).

Les échecs temporaires sont une limitation de débit. Google conseille d'« arrêter complètement l'envoi pendant une courte période, puis de reprendre à un rythme plus lent » (« completely stop sending for a short period of time, then resume sending at a slower rate »). [Erreurs SMTP de Gmail et dépannage](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/depannage-gmail) répertorie les codes SMTP précis.

## Place dans une démarche de délivrabilité

1. **Inscrivez chaque domaine d'authentification** (les domaines DKIM d= et les domaines SPF Return-Path) avant que les problèmes surviennent, car il n'existe aucune donnée pour la période antérieure à l'inscription.
2. **Chaque jour** : surveillez le taux de spam au regard des seuils de 0,10 % et de 0,30 %, ainsi que les deux niveaux de réputation.
3. **Pour chaque campagne** : utilisez `Feedback-ID` et la FBL pour attribuer les plaintes aux flux, aux clients ou aux campagnes.
4. **Lors d'un incident de livraison** : rapprochez les motifs du tableau de bord Erreurs de distribution de vos journaux SMTP, et vérifiez les tableaux de bord Authentification et Chiffrement pour repérer une régression.
5. **Pour la conformité** : vérifiez chaque élément de l'État de conformité. Seuls les expéditeurs conformes dont le taux de spam reste <0,3 % pendant 7 jours consécutifs peuvent obtenir une levée des restrictions par Google.

Les recommandations de Google en matière d'hygiène de base de données qui accompagnent ces outils : n'envoyez qu'à des destinataires qui ont donné leur opt-in, confirmez les adresses à l'inscription (opt-in confirmé), demandez périodiquement si les personnes sont toujours intéressées, cessez d'écrire aux personnes qui n'interagissent pas, et rendez le désabonnement très simple.

Yahoo propose des outils comparables. Voir [feedback loop de plaintes de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/feedback-loop-de-plaintes-de-yahoo) et [flux de performance de Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/flux-de-donnees-de-delivrabilite-de-yahoo).

# Microsoft SNDS et JMRP

> Smart Network Data Services (données de réputation par adresse IP pour Outlook.com : résultats de filtrage, taux de plaintes, adresses pièges touchées) et la feedback loop du Junk Email Reporting Program : données fournies, seuils et inscription.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp

Les deux programmes gratuits de Microsoft pour les expéditeurs qui écrivent à Outlook.com (outlook.com, hotmail.com, live.com, msn.com) :

- **SNDS (Smart Network Data Services)** : un tableau de bord de données d'envoi par adresse IP. Selon Microsoft, la délivrabilité vers Outlook.com repose sur votre réputation, et SNDS fournit les données nécessaires pour comprendre et améliorer votre réputation chez Outlook.com. Il aide aussi les propriétaires d'adresses IP à détecter sur leurs réseaux les serveurs compromis, les logiciels malveillants, les virus et les botnets.
- **JMRP (Junk Email Reporting Program)** : la feedback loop de Microsoft ; elle rend compte des problèmes de courrier indésirable signalés par les utilisateurs d'Outlook.com, en renvoyant le message complet de tout email qu'un destinataire a marqué comme courrier indésirable ou comme phishing.

Ce sont les équivalents chez Microsoft de Google Postmaster Tools et de la feedback loop de plaintes de Yahoo (*Complaint Feedback Loop*). Ils portent sur les messages envoyés aux **boîtes aux lettres grand public Outlook.com**, pas aux locataires Microsoft 365/Exchange Online.

Les libellés du portail SNDS sont décrits en français, suivis du libellé anglais entre parenthèses.

## Migration du portail (2026)

SNDS a quitté l'ancien domaine `sendersupport.olc.protection.outlook.com` pour un nouveau portail à l'adresse `https://substrate.office.com/ip-domain-management-snds/` (lien court `https://aka.ms/snds`). Les utilisateurs de l'accès automatisé devaient faire pointer leurs URL vers le nouveau portail avant que l'ancien domaine ne devienne obsolète, le **22 juin 2026**. Depuis le **22 juillet 2026**, **le nombre d'adresses pièges touchées n'apparaît plus** dans les données SNDS, afin de préserver l'intégrité des systèmes anti-abus de Microsoft.

## SNDS : données fournies

Les données sont agrégées par adresse IP et par jour. Vers **minuit PST**, un traitement agrège les données de la veille (il peut mettre quelques heures à se terminer). Les données sont conservées et consultables pendant **90 jours**.

| Champ | Signification |
|---|---|
| Période d'activité (*Activity period*) | Première et dernière heure de la journée PST pendant lesquelles une activité de l'IP a été observée |
| Commandes RCPT (*RCPT commands*) | Nombre de commandes `RCPT TO` émises. Référence : plus d'un tiers des IP qui envoient vers Outlook.com maintiennent **sous 10 %** la part des commandes RCPT qui n'aboutissent pas à un destinataire de message ; une forte proportion d'échecs révèle des problèmes de qualité de liste ou une collecte d'adresses par sondage de l'espace de noms (*namespace mining*) |
| Commandes DATA (*DATA commands*) | Nombre de transmissions effectives de messages |
| Destinataires des messages (*Message recipients*) | Nombre final de destinataires prévus. Chez les expéditeurs sérieux, l'écart avec le nombre de commandes RCPT reste faible |
| Résultat du filtrage (*Filter result*) | Verdict du filtre anti-spam, par code couleur, pour les messages de l'IP ce jour-là (voir ci-dessous) |
| Taux de plaintes (*Complaint rate*) | Plaintes ÷ destinataires des messages. Référence : plus de 30 % des IP qui envoient vers Outlook.com maintiennent leur taux de plaintes **sous 0,3 %** |
| Adresses pièges touchées (*Trap hits*) | Messages envoyés à des comptes pièges inexistants gérés par Outlook.com. Les expéditeurs légitimes en touchent rarement ; les spammeurs peuvent difficilement les éviter. **Retiré des rapports depuis le 22 juillet 2026** |
| Exemples de HELO / MAIL FROM (*Sample HELO / MAIL FROM*) | Exemples réels des commandes d'identité SMTP observées depuis l'IP ; utiles pour repérer un trafic qui n'est pas le vôtre (compromission, infrastructure usurpée) |

### Seuils du résultat du filtrage

| Couleur | Signification |
|---|---|
| Vert (*Green*) | Spam < 10 % des messages de l'IP |
| Jaune (*Yellow*) | 10 % ≤ spam ≤ 90 % |
| Rouge (*Red*) | Spam > 90 % |

### Lire SNDS dans une démarche de délivrabilité

- **Résultats de filtrage rouges ou jaunes** avec un volume normal → problème de contenu ou de réputation ; vérifiez l'authentification et les causes des plaintes.
- **Taux de plaintes ≥ 0,3 %** → au-dessus de la limite de sécurité pratique (le même chiffre que Yahoo et Gmail publient comme seuil ferme) ; resserrez l'hygiène de base de données et le consentement.
- **Volume, valeurs HELO ou adresses pièges touchées inattendus** → hôte probablement compromis ou utilisation non autorisée de votre espace d'adresses IP.
- L'absence de données pour une IP signifie généralement qu'elle a envoyé trop peu de messages vers Outlook.com ce jour-là pour figurer dans les rapports.

## SNDS : inscription et accès

1. Connectez-vous à SNDS avec un **compte Microsoft**.
2. **Demandez l'accès** (*Request access*) aux IP (ou à la plage CIDR / à l'ASN) dont vous êtes responsable.
3. SNDS détermine les contacts autorisés par des **requêtes DNS inverse et WHOIS** sur la plage et propose les adresses email associées ; les plages allant jusqu'à un **/23** peuvent être autorisées par DNS inverse quand leurs noms de domaine suivent un schéma cohérent.
4. Cliquez sur le lien de l'email de vérification envoyé à l'adresse choisie pour confirmer l'autorisation.

**Accès automatisé** : SNDS fournit une URL d'accès aux données simple (avec une clé, sans connexion interactive) destinée aux systèmes automatisés qui récupèrent les données quotidiennes ; elle convient pour alimenter la surveillance et les alertes.

## JMRP : la feedback loop d'Outlook.com

- Service gratuit qui fournit des rapports sur les problèmes de courrier indésirable signalés par les utilisateurs d'Outlook.com.
- Renvoie le **message complet avec ses en-têtes** de tout email qu'un destinataire a marqué comme **courrier indésirable ou phishing**.
- Objectif : identifier les destinataires qui ne veulent plus de vos messages (retirez-les immédiatement) et repérer les contenus ou segments qui génèrent des plaintes.
- Inscription : par le portail SNDS, à l'adresse `https://substrate.office.com/ip-domain-management-snds/snds/jmrp` (exige la même connexion avec un compte Microsoft et la même autorisation des IP que SNDS).
- Les premiers retours peuvent arriver dès 72 heures après l'inscription.
- L'inscription à JMRP est l'étape de résolution documentée par Microsoft pour le blocage `550 SC-004` (IP bloquée en raison de plaintes) ; voir [Exigences de Microsoft envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs).

Contrairement aux feedback loops fondées sur ARF de certains fournisseurs, les rapports JMRP sont rattachés à l'**IP d'envoi** : les messages doivent donc provenir d'un espace d'IP que vous avez fait autoriser dans SNDS. Traitez chaque rapport JMRP comme un désabonnement : continuer d'écrire à un plaignant fait monter directement le taux de plaintes SNDS et le risque d'un blocage SC-004.

## Voir aussi

- [Exigences de Microsoft envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs) — politiques, obligation d'authentification de 2025 et codes d'erreur SMTP
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email) — les signaux de plaintes et d'adresses pièges dans les systèmes de réputation
- [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip) — utiliser SNDS pour surveiller les nouvelles IP pendant la chauffe

# Adresses pièges : types et ce qu'elles révèlent

> Les types d'adresses pièges (pièges vierges, pièges recyclés, pièges à fautes de frappe), comment chacun arrive sur une liste, ce qu'une adresse piège touchée révèle sur la qualité des données, et comment réagir.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/adresses-pieges

D'après « What Spamtraps Tell Us » de Word to the Wise (Laura Atkins, mars 2025), qui actualise son article antérieur « A Brief Guide to Spamtraps » (2011). Les adresses pièges (spam traps, ou spamtraps) sont des adresses email exploitées par des listes de blocage, des organisations antispam et des fournisseurs de messagerie pour détecter les mauvaises pratiques d'envoi. Les fournisseurs de messagerie et les systèmes de réputation s'appuient sur les adresses pièges touchées pour justifier le blocage d'un expéditeur.

## Types d'adresses pièges

| Type | Ce que c'est | Comment il arrive sur une liste | Ce que révèle une adresse piège touchée |
|---|---|---|---|
| **Piège vierge** | Une adresse fabriquée qui n'a jamais existé, souvent sur un domaine qui n'a jamais servi à l'email | Des expéditeurs qui inventent des adresses, ou qui les achètent à un vendeur de listes | Des pratiques d'envoi qui ne reposent pas sur la permission (voir les [pires pratiques](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/word-to-the-wise-meilleures-pratiques-email#buying-lists)) |
| **Piège recyclé** | Une adresse ou un domaine qui a reçu des messages légitimes à un moment donné, a été désaffecté, a renvoyé des rebonds pendant au moins **12 mois**, puis a été rouvert comme piège | Une mauvaise gestion des rebonds, ou la réactivation d'une base de contacts périmée ; fréquent dans les listes achetées | Une hygiène de base de données ou un traitement des rebonds insuffisants |
| **Piège à fautes de frappe** | Une vraie faute de frappe dans une adresse, généralement dans la partie **domaine** ; des organisations de sécurité et de lutte contre le spam ont acheté des domaines correspondant à des fautes de frappe courantes et en ont fait des adresses de surveillance | Une personne se trompe en saisissant sa propre adresse sur un formulaire d'inscription | L'expéditeur veut travailler en opt-in, mais ne vérifie pas l'exactitude des données recueillies |

## L'idée clé : les adresses pièges sont un signal, pas le problème

> Les adresses pièges ne sont PAS le problème ; elles sont un signal.

Les adresses pièges trahissent des problèmes plus profonds de collecte et de tenue à jour des données. Corollaire essentiel : **si vos processus de gestion de liste laissent entrer des adresses pièges, vous envoyez probablement aussi des messages à de vraies personnes qui n'en veulent pas**, et c'est là que se trouvent les vrais dégâts de réputation (voir [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)).

## Comment réagir

N'essayez pas de traquer et de retirer une à une les adresses pièges : corrigez les causes profondes.

- **N'achetez pas de listes.**
- **Ne réactivez jamais d'anciennes adresses de votre base** (source des pièges recyclés).
- **Mettez en place une vérification des adresses** sur les formulaires d'inscription de votre site web (source des pièges à fautes de frappe).
- Gérez correctement les rebonds, pour que les adresses désaffectées quittent la liste bien avant la fin de la période de recyclage de 12 mois.

# Boîte à outils antispam de l'OCDE (2006)

> Le cadre politique transfrontière de l'OCDE contre le spam : huit éléments, la recommandation du Conseil sur la coopération en matière d'application des lois, et les meilleures pratiques BIAC/MAAWG pour les fournisseurs d'accès et le marketing par email.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/boite-a-outils-antispam-de-l-ocde

Si vous devez comparer des lois nationales contre le spam, ou comprendre comment les autorités de différents pays coopèrent pour les faire appliquer, la boîte à outils antispam de l'Organisation de coopération et de développement économiques (OCDE) est ce qui se rapproche le plus d'une architecture de référence convenue à l'échelle internationale pour les politiques nationales de lutte contre le spam.

L'**Anti-Spam Toolkit of Recommended Policies and Measures** (boîte à outils antispam de politiques et mesures recommandées) a été produit par le **groupe de travail de l'OCDE sur le spam** (OECD Task Force on Spam), que le Conseil de l'OCDE a approuvé en 2004 et dont le mandat s'est achevé en juin 2006. Les comités ICCP et CCP ont déclassifié la boîte à outils le 29 mars 2006. Le Conseil de l'OCDE a adopté la **Council Recommendation on Cross-Border Co-operation in the Enforcement of Laws Against Spam** (recommandation du Conseil sur la coopération transfrontière dans l'application des lois contre le spam) qui l'accompagne le **13 avril 2006**. L'OCDE comptait alors 30 pays membres, et la recommandation invite aussi les économies non membres à en tenir compte.

La boîte à outils est un **cadre de politique et d'application des lois**. Elle n'impose en elle-même aucune obligation aux expéditeurs. Elle intègre en annexe deux documents de meilleures pratiques du secteur : l'un de BIAC et du MAAWG pour les fournisseurs d'accès, l'autre de BIAC pour les professionnels du marketing par email.

## Ce qui tient toujours et ce qui est daté

La boîte à outils est antérieure à la maturité de SPF, DKIM et DMARC, aux obligations de 2024 de Gmail et Yahoo pour les expéditeurs de gros volumes, à la messagerie pensée d'abord pour le mobile et aux systèmes de réputation modernes. Ses sections **techniques** (élément IV) citent SPF, « DKIM/META », Sender-ID, la liste grise, BATV et SES, et les contrôles PTR. Elles ont un intérêt historique, et la pratique actuelle est traitée dans des articles consacrés à chacun de ces sujets.

Ce qui reste **directement utile aujourd'hui**, c'est le cadre de politique et d'application transfrontière des lois : la liste de contrôle pour concevoir une législation, les types de consentement, le raisonnement sur la responsabilité, le modèle de coopération entre autorités, et les listes de meilleures pratiques pour les fournisseurs d'accès et les expéditeurs, que les documents du M3AAWG ont ensuite développées. Utilisez la boîte à outils pour le cadre, et les références liées pour la pratique technique actuelle.

## Les huit éléments

La boîte à outils s'organise autour de huit éléments liés d'un cadre de politique publique complet :

| # | Élément | Proposition centrale |
|---|---|---|
| I | **Approches réglementaires** | Une législation antispam claire et simple qui fixe ce qui est permis et ce qui ne l'est pas |
| II | **Application des lois** | Des autorités dotées de pouvoirs, des sanctions rapides, une coopération transfrontière |
| III | **Initiatives du secteur** | Autorégulation, codes de conduite et politiques d'utilisation acceptable qui fonctionnent avec la loi |
| IV | **Mesures techniques** | Des outils antispam en couches. Aucune méthode ne suffit à elle seule |
| V | **Éducation et sensibilisation** | Éduquer à la fois les destinataires et les expéditeurs. Cibler les utilisateurs, les groupes et les petites et moyennes entreprises (PME) |
| VI | **Partenariats de coopération** | Collaboration public-privé dans la conception et l'application |
| VII | **Mesure du spam** | Mesurer l'efficacité des politiques et des mesures techniques (le programme Email Metrics du MAAWG est cité) |
| VIII | **Coopération mondiale (ouverture)** | Étendre le cadre aux économies non membres de l'OCDE, avec une aide bilatérale et multilatérale |

## Élément I : conception de la réglementation

La législation doit viser à **préserver les avantages des communications électroniques**, à **interdire et sanctionner le spam tel que le définit le droit national**, et à **réduire la quantité de spam** en ciblant différentes étapes de l'envoi. La valeur d'une législation dépend de la certitude que les sanctions seront appliquées.

Quatre principes législatifs généraux :

- **Orientation politique** : définir tôt les principaux objectifs. Ils doivent sous-tendre toute la stratégie.
- **Simplicité réglementaire** : la législation doit être courte et simple.
- **Efficacité de l'application** : associer la loi à un régime de sanctions efficace, à des normes de preuve appropriées et à des autorités dotées de moyens. Une mauvaise application rend inutile une bonne législation.
- **Liens internationaux** : le spam franchit les frontières, donc prévoir la coopération et l'échange d'informations avec les autorités étrangères.

### Liste de contrôle des meilleures pratiques législatives

Le tableau de la boîte à outils pour l'élément réglementaire est une liste de contrôle utile pour toute juridiction qui rédige ou compare une loi antispam :

| Question | Approche recommandée |
|---|---|
| **Services concernés (champ d'application)** | Choisir une loi propre à une technologie (qui vise les médias qui posent problème aujourd'hui) ou technologiquement neutre (souple et pérenne). La voix en temps réel peut faire l'objet d'une réglementation distincte. |
| **Finalité commerciale** | Décider si la loi couvre uniquement les messages commerciaux et transactionnels, ou aussi les messages non commerciaux (politiques, religieux). Certaines catégories peuvent être expressément exclues (par exemple les établissements d'enseignement qui écrivent à leurs anciens élèves). |
| **Consentement** | Trois approches, souvent combinées : **exprès** (une autorisation active, c'est-à-dire l'opt-in) ; **déduit ou implicite** (d'un comportement ou d'une relation d'affaires existante) ; **présumé** (supposé jusqu'à son retrait, c'est-à-dire l'opt-out). |
| **Adresse de désabonnement** | Les messages doivent comporter un opt-out fonctionnel. Cela suppose une **adresse de retour valide**, et une **adresse postale** peut aussi être exigée. Leur absence, ou le fait de ne pas cesser les envois dans le délai légal, doit pouvoir être sanctionné. |
| **Informations sur l'origine des messages** | Interdire les en-têtes et les identifiants d'expéditeur falsifiés ou dissimulés. Exiger que le professionnel du marketing qui se trouve derrière l'expéditeur soit clairement identifié. |
| **Pas d'envoi en masse** | Un email ne peut être qualifié de spam qu'au-dessus d'un seuil de volume, **généralement de 50 à 100 messages sur 24 heures**, afin de ne pas viser les envois en masse légitimes comme les newsletters. |
| **Étiquetage** | La loi peut exiger une mention spécifique pour les contenus publicitaires ou pornographiques. |
| **Personne qui autorise ou qui en tire profit** | Sanctionner non seulement la personne qui envoie matériellement, mais aussi quiconque a commandité ou autorisé l'envoi ou en a tiré un profit financier. Cette personne est plus facile à identifier, ce qui facilite l'application de la loi. |
| **Collecte d'adresses et attaques par dictionnaire** | Prévoir des sanctions supplémentaires en cas d'utilisation de logiciels de collecte d'adresses, de listes collectées ou de génération automatique d'adresses. |
| **Accès illégal** | Interdire l'utilisation non autorisée de ressources informatiques protégées (des machines compromises utilisées pour envoyer). |
| **Contenu trompeur ou frauduleux** | Les escroqueries et le phishing peuvent relever des infractions informatiques ordinaires. La loi antispam peut y ajouter l'interdiction des objets trompeurs et fonctionner avec le droit de la lutte contre la fraude et de la consommation. |
| **Menaces de sécurité (logiciels malveillants)** | Souvent érigées en infractions par la loi ou par la **Convention du Conseil de l'Europe sur la cybercriminalité**. |
| **Compétence transfrontière** | Couvrir les messages envoyés vers ou depuis la juridiction, ainsi que les messages commandités depuis la juridiction ou qui profitent à quelqu'un qui s'y trouve. Donner aux autorités le pouvoir de coopérer au-delà des frontières. |

Cette liste de contrôle correspond aux régimes nationaux : [CAN-SPAM (États-Unis)](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis) suit le modèle de l'opt-out et du consentement présumé ; la [LCAP (CASL, Canada)](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel) et le [PECR (Royaume-Uni)](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email) suivent le modèle du consentement exprès, l'opt-in. Voir aussi [directive ePrivacy et RGPD (UE)](https://emailmarketing.net/fr/apprendre/conformite/directive-eprivacy-et-rgpd-marketing-par-email) et [le Spam Act australien](https://emailmarketing.net/fr/apprendre/conformite/australie-spam-act-2003-et-application-par-l-acma).

## Élément II : application des lois et recommandation du Conseil

La **Recommendation on Cross-Border Co-operation in the Enforcement of Laws Against Spam** (annexe I) est le cœur de la boîte à outils, contraignant dans son esprit. Elle ne couvre que les **violations graves** : les comportements qui (a) causent ou peuvent causer un préjudice, financier ou autre, à un nombre important de destinataires, (b) touchent un nombre particulièrement élevé de destinataires, ou (c) causent un préjudice substantiel. La décision d'apporter son aide appartient toujours à l'**autorité chargée de l'application des lois contre le spam** (Spam Enforcement Authority) qui reçoit la demande.

Les gouvernements devraient améliorer leur législation afin :

1. D'établir un **cadre national** de lois, d'autorités chargées de leur application et de pratiques.
2. D'améliorer la **capacité de coopération** des autorités avec leurs homologues étrangers (partager des informations, apporter une assistance aux enquêtes).
3. D'améliorer les **procédures** de coopération, en hiérarchisant les demandes et en utilisant des ressources et des réseaux communs.
4. De développer des **modèles de coopération** entre les autorités chargées de l'application des lois et les entités du secteur privé.

La recommandation comporte quatre parties opérationnelles :

| Partie | Obligation des pays membres |
|---|---|
| **(a) Cadre national** | Maintenir des lois efficaces et des autorités chargées de l'application des lois contre le spam. Donner à ces autorités le pouvoir d'obtenir des preuves, d'enquêter et d'agir en temps utile contre les violations commises depuis leur territoire ou qui l'affectent. Permettre d'agir à la fois contre les **expéditeurs** et contre **ceux qui profitent** de l'envoi. Réexaminer périodiquement les cadres. Envisager une **réparation du préjudice financier**. |
| **(b) Capacité de coopération** | Prévoir des moyens de partager des informations avec les autorités étrangères sur demande, sous réserve de garanties. Permettre l'assistance aux enquêtes (obtention d'informations, de documents et de dossiers, et localisation de personnes et de biens). **Désigner un point de contact** et l'enregistrer auprès du Secrétariat de l'OCDE, qui tient et publie la liste. |
| **(c) Procédures** | Avant de demander une assistance, mener une enquête préliminaire pour confirmer que la demande est justifiée. Hiérarchiser les demandes. Utiliser des ressources communes (le site web de l'OCDE sur le spam, les canaux informels, les réseaux d'application des lois existants). |
| **(d) Coopération avec le secteur privé** | Les autorités, les entreprises, les organisations professionnelles et les associations de consommateurs devraient coopérer sur l'éducation des utilisateurs, la transmission des données de plaintes, et le partage d'outils d'enquête, d'analyses et d'informations sur les tendances. Encourager la coopération pour localiser et identifier les spammeurs, réduire les données inexactes d'enregistrement des domaines et renforcer la sécurité d'Internet. |

L'OCDE a chargé ses comités ICCP et CCP de suivre les progrès dans un délai de trois ans. Ce modèle de points de contact désignés, d'assistance mutuelle hiérarchisée et de partage de données avec le secteur privé est l'ancêtre des canaux pratiques d'escalade et de transmission d'aujourd'hui, décrits dans [Cross-Provider Escalation & Mitigation Channels](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-et-de-levee-des-restrictions), et de la réception des signalements d'abus, décrite dans [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk).

## Élément III : initiatives du secteur

La loi antispam devrait fonctionner avec l'autorégulation du secteur privé. Le groupe de travail a salué le travail de BIAC et du MAAWG sur les meilleures pratiques. Il a noté que, dans certaines juridictions, de tels codes pourraient être **officiellement enregistrés auprès de l'agence nationale chargée de l'application des lois**, afin que l'autorité puisse imposer leur respect là où l'association professionnelle ne le peut pas.

Les acteurs et leurs obligations :

- **Fournisseurs de services ou de biens en ligne** : respecter la vie privée des clients. Adopter des politiques d'entreprise claires en matière d'email et les appliquer de façon cohérente (par exemple, ne jamais demander d'informations personnelles, ou idéalement ne jamais insérer de lien cliquable dans un email). Authentifier les emails ou utiliser des signatures numériques. Prévenir le phishing par des noms de domaine clairs et l'**enregistrement défensif de domaines**, la surveillance des sites ressemblants et le contrôle des messages de rebond. Indiquer aux clients quels emails l'entreprise enverra et n'enverra pas.
- **Professionnels du marketing direct** : adopter et appliquer un code de conduite du marketing électronique. Nouer des relations plus étroites avec les fournisseurs d'accès pour réduire les faux positifs. Aligner les codes sur la législation antispam aux niveaux national et international.
- **Fournisseurs d'accès et opérateurs de réseaux** : pratiquer l'autorégulation. **Adopter et faire respecter des politiques d'utilisation acceptable (AUP)** en tant que clauses contractuelles dont la violation permet la suspension ou la résiliation. Informer les abonnés sur le filtrage antispam et antivirus.

### Meilleures pratiques BIAC et MAAWG pour les fournisseurs d'accès et les opérateurs de réseaux (annexe II)

Ici, « fournisseurs d'accès et opérateurs de réseaux » désigne **toute entité qui exploite un serveur SMTP connecté à Internet**. Chaque pratique ne s'applique que si le droit national ne la contredit pas :

| # | Pratique |
|---|---|
| 1 | Traiter les **équipements d'utilisateurs finaux compromis**, avec des processus rapides pour les gérer ou les empêcher d'être une source de spam |
| 2 | Utiliser une **authentification conforme aux normes du secteur** pour les emails, pour les sources, ou pour les deux |
| 3 | **Bloquer les pièces jointes potentiellement infectieuses**. Lorsque le contenu est filtré, obtenir l'accord préalable du client comme l'exige la loi |
| 4 | **Surveiller activement le volume entrant et sortant** pour détecter les activités inhabituelles et leur source, et y répondre |
| 5 | Mettre en place des **processus inter-entreprises** pour réagir aux signalements d'incidents des autres opérateurs, et **accepter les plaintes des utilisateurs finaux** |
| 6 | **Communiquer les politiques et procédures de sécurité** aux abonnés |
| 7 | N'envoyer des **notifications de non-livraison (NDN) que pour les messages émis par leurs propres titulaires de compte**, ce qui évite le [backscatter](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/backscatter-et-batv) |
| 8 | Veiller à ce que **seuls leurs titulaires de compte utilisent leurs serveurs de soumission** (authentification de la soumission) |
| 9 | Tenir des **enregistrements WHOIS, DNS et d'enregistrement des adresses IP exacts** (WHOIS, SWIP, RWHOIS), avec des contacts de rôle (postal, téléphone, email) pour résoudre les abus |
| 10 | Veiller à ce que toutes les adresses IP publiques aient un **DNS direct et un DNS inverse** corrects et des entrées WHOIS ou SWIP, et à ce que l'espace d'adresses privé respecte la **RFC 1918** |

Ces pratiques sont les précurseurs directs du [M3AAWG Senders BCP](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs) et des contrôles opérationnels de [Sending Infrastructure Practices](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi). [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk) développe les comptes de rôle et l'hygiène du WHOIS, et [IPv6 Reverse DNS](https://emailmarketing.net/fr/apprendre/operations/dns-inverse-en-ipv6) les attentes sur les PTR.

### Meilleures pratiques BIAC pour le marketing par email (annexe III)

C'est un code volontaire pour les professionnels du marketing. Lorsque le droit national est plus strict, c'est la loi qui prévaut. Il contient neuf recommandations et un ensemble de conseils techniques :

| # | Recommandation |
|---|---|
| 1 | Respecter les **exigences de consentement du pays depuis lequel opère le professionnel du marketing**, sauf s'il cible sciemment ou intentionnellement les consommateurs d'un autre pays |
| 2 | **Conserver une trace des demandes d'opt-in et d'opt-out** afin de pouvoir nettoyer les listes avant les envois. Enregistrer la preuve du consentement, y compris la date et l'heure, l'adresse IP d'origine et l'URL ou le support de collecte, et la fournir sur demande |
| 3 | Dans tous les emails marketing (et non les emails transactionnels), proposer un **opt-out par email ou par le web évident, clair et efficace**. Ne pas le cacher. Confirmer l'opt-out sans exiger d'autre action du consommateur |
| 4 | Chaque message doit **identifier clairement l'expéditeur**. La ligne d'objet et le corps doivent refléter fidèlement le contenu, l'origine et la finalité, et l'identité de l'expéditeur doit figurer **au-dessus de la ligne de flottaison** si possible. Éviter les lignes d'objet sur les « offres gratuites » ou les « prix gagnés », qui déclenchent les filtres anti-spam. Indiquer l'**adresse postale** principale de l'expéditeur. |
| 5 | Fournir un **lien vers la politique de confidentialité de l'expéditeur** |
| 6 | Les professionnels du marketing, les courtiers et les propriétaires de listes doivent **s'assurer que les adresses de la liste ont été obtenues légalement**. Examiner la politique de confidentialité et les procédures de collecte du courtier, et obtenir une garantie contractuelle que la collecte était légale |
| 7 | **Faire preuve d'une grande discrétion dans le marketing auprès des enfants et des jeunes**. Les contenus pour adultes (contenus sexuellement explicites, jeux et jeux d'argent, tabac, alcool, armes à feu) exigent un traitement adapté à l'âge et, le cas échéant, la mention **« SEXUALLY EXPLICIT »** en tête de la ligne d'objet. Demander l'autorisation parentale lorsque c'est obligatoire |
| 8 | Disposer d'un **système de traitement des plaintes équitable, efficace, confidentiel et facile à utiliser** |
| 9 | Ne communiquer les adresses de clients existants à des affiliés tiers ou au sein d'un groupe de sociétés **que si** leur usage est conforme à la finalité de la collecte, si un opt-out facile existe ou si le consentement a été donné. Être transparent sur les liens entre marques |

**Conseils techniques pour les professionnels du marketing électronique** (annexe III) :

- Tous les serveurs (entrants, sortants, sites web) doivent avoir des entrées de **DNS inverse (PTR)**. Les résolutions directe et inverse doivent correspondre, et les machines d'envoi doivent **s'identifier avec ce nom dans HELO ou EHLO**.
- Publier des **enregistrements SPF, des enregistrements domain-key (le prédécesseur de DKIM), ou les deux** pour les expéditeurs et pour les sites tiers associés à un envoi, et les tenir à jour.
- Attribuer aux serveurs de messagerie sortants des **adresses IP distinctes de celles des autres serveurs du site**.
- Tenir les **enregistrements WHOIS exacts et complets**.
- Maintenir les **comptes de rôle (postmaster@, abuse@)** fonctionnels et activement surveillés pour tous les domaines d'expéditeur, y compris les sites cités dans le contenu.

**Gestion des rebonds** (annexe III) :

| Type de rebond | Règle |
|---|---|
| **Définitif (5xx)** : utilisateur inexistant ou boîte indisponible | **Supprimer** rapidement l'adresse de toutes les listes dès que les refus atteignent **3 ou plus en 14 jours**. Si un 5xx signale un *blocage pour spam* plutôt qu'une mauvaise adresse, l'adresse peut être réactivée une fois le blocage levé. |
| **Temporaire (4xx)** : échec passager | **Retirer** l'adresse quand les refus dépassent **5 lors de campagnes consécutives d'une même liste, ou 5 au total sur plusieurs listes en 10 jours**. |

Pour un traitement moderne, propre à chaque fournisseur, comparez avec [Enhanced Status Codes](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp), [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil) et [Suppression-List Architecture](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture).

## Éléments IV à VIII (en bref)

- **IV Mesures techniques** : aucun outil ne suffit à lui seul. La superposition de couches à l'origine, sur le réseau fédérateur, à la passerelle et chez le destinataire réduit considérablement le spam. La pratique actuelle est traitée sous [authentification](https://emailmarketing.net/fr/apprendre/authentification/spf), [sécurité du transport](https://emailmarketing.net/learn/transport-security/mta-sts) et filtrage.
- **V Éducation et sensibilisation** : les gouvernements mènent des campagnes publiques. Les fournisseurs d'accès utilisent leurs canaux clients (site web, portail, SMS, newsletters) pour expliquer comment éviter le spam, quels filtres existent, comment signaler un abus, et quel est le **contact du service abus**. « L'éducation des destinataires est aussi importante que celle des expéditeurs. »
- **VI Partenariats de coopération** : la stratégie antispam doit être élaborée en partenariat entre les secteurs public et privé. Les fournisseurs d'accès et les autorités chargées de l'application des lois doivent rester en contact pour signaler les cas de spam et partager des données réseau.
- **VII Mesure du spam** : mesurer afin d'évaluer les stratégies nationales. Le groupe de travail a salué et encouragé l'**Email Metrics Program du MAAWG**.
- **VIII Coopération mondiale (ouverture)** : mettre la boîte à outils et les meilleures pratiques à la disposition des économies non membres de l'OCDE, et promouvoir l'action antispam à l'étranger par des accords bilatéraux et multilatéraux. Un site compagnon (historiquement `www.oecd-antispam.org`) hébergeait des informations à jour sur les lois nationales contre le spam et la liste des points de contact nationaux chargés de l'application des lois.

## Pourquoi c'est toujours important pour exploiter un ESP

Tournez-vous vers la boîte à outils quand une question est juridictionnelle ou transfrontière plutôt que technique : quel modèle législatif suit un pays cible, comment les autorités chargées de l'application des lois coopèrent au-delà des frontières, à quoi ressemblent, en termes de politique, la politique d'utilisation acceptable et les obligations d'un fournisseur d'accès en matière d'abus, et comment les meilleures pratiques des expéditeurs et des professionnels du marketing ont été mises par écrit avant que le M3AAWG ne les formalise. Pour la délivrabilité au quotidien, ce sont les exigences précises des fournisseurs et les normes d'authentification qui s'appliquent. Le cadre de l'OCDE régit la couche juridique et interinstitutionnelle qui les entoure.

# Glossaire de la délivrabilité

> Définitions, par ordre alphabétique, des termes de délivrabilité employés dans cette base de connaissances, avec des liens vers les articles de fond.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/glossaire

Un terme de délivrabilité vous est inconnu ? Cherchez-le ici. Pour chaque terme, vous trouverez une définition courte, utile en pratique, et un lien vers l'article où le sujet est approfondi. Seuls les termes de délivrabilité y figurent : le vocabulaire du design et de la rédaction des emails en est exclu. Quand le terme anglais diffère du terme français, il est donné entre parenthèses, et l'ordre des entrées est l'ordre alphabétique anglais.

## A

**Taux d'acceptation (taux de livraison)** (*acceptance rate, delivery rate*) : part, en pourcentage, des messages envoyés qu'acceptent les serveurs de réception (SMTP 250). Un message accepté n'est pas pour autant placé en boîte de réception, puisqu'il peut encore finir dans le dossier spam. Voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation).

**Liste blanche** (*allowlist, safelist*) : liste d'expéditeurs (adresses, domaines ou adresses IP) que le destinataire tient de son côté, et dont le courrier contourne une partie du filtrage. Elle s'oppose à la liste de blocage. Pour des emails critiques, demander aux destinataires d'y inscrire votre domaine d'envoi dépanne, mais ne tient pas lieu de stratégie de délivrabilité. Les fournisseurs de messagerie ont presque tous renoncé à leurs programmes officiels de liste blanche, même si la certification CSA existe encore (voir [GMX et WEB.DE](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/gmx-web-de-exigences-postmaster)).

**Apple Mail Privacy Protection (MPP)** : fonction d'Apple Mail qui télécharge les images en avance, en passant par un proxy. Les pixels de suivi des ouvertures se déclenchent alors sans lecture réelle, et les adresses IP des destinataires restent cachées. Elle explique en grande partie pourquoi les taux d'ouverture sont surévalués et pourquoi les clics méritent plus de poids. Voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite).

**ARC (Authenticated Received Chain)** : protocole défini par la RFC 8617. Les intermédiaires (services de transfert, listes de diffusion) y consignent les résultats d'authentification obtenus avant eux, si bien qu'un email qui casse légitimement SPF ou DKIM en chemin reste évaluable. Voir [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc).

**ARF (Abuse Reporting Format)** : format de message, spécifié par la RFC 5965, dans lequel les feedback loops de plaintes transmettent à l'expéditeur le clic d'un destinataire sur « ceci est du spam ». Voir [Feedback loops de plaintes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes).

**En-tête Authentication-Results** (*Authentication-Results header*) : en-tête, spécifié par la RFC 8601, dans lequel le serveur de réception inscrit ses verdicts SPF, DKIM, DMARC et apparentés pour un message. Pour savoir comment un serveur de réception a vraiment jugé votre authentification, c'est cet en-tête qu'il faut lire. Voir [L'en-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results).

## B

**Filtre bayésien** (*Bayesian filter*) : filtre anti-spam fondé sur la statistique. Il apprend la fréquence des jetons dans du spam connu et dans des emails légitimes (le « ham »), au lieu d'appliquer des règles fixes. Les fournisseurs actuels l'emploient parmi bien d'autres couches d'analyse du contenu. Voir [Contenu et design au service de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite).

**BIMI (Brand Indicators for Message Identification)** : norme d'affichage du logo d'une marque à côté de ses messages authentifiés. Il lui faut DMARC en politique contraignante (`quarantine` ou `reject`) et, chez la plupart des fournisseurs, un Verified Mark Certificate. Voir [BIMI](https://emailmarketing.net/fr/apprendre/authentification/bimi).

**Liste de blocage (DNSBL ou RBL)** (*blocklist*) : liste d'adresses IP ou de domaines suspectés d'envoyer du spam, consultable par requête DNS. Pour les serveurs de réception, c'est une source parmi d'autres, en plus de leurs indicateurs internes, et Spamhaus y a le plus de poids. Voir [Listes de blocage DNS et zones Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus).

**Rebond** (*bounce*) : échec de livraison qui revient à l'expéditeur. Le rebond définitif (5.X.X) est permanent, comme une adresse invalide ou un rejet par la politique du serveur de réception. Le rebond temporaire (4.X.X) est passager, comme une boîte pleine ou un report de remise. Voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite) et [Codes d'état étendus SMTP](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp).

**Taux de rebonds** (*bounce rate*) : part des messages envoyés qui ont rebondi, en pourcentage. Seuils d'exploitation habituels : sain sous 2 %, à examiner au-dessus de 5 %, et 10 % à ne jamais franchir. Voir le [tableau des seuils](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite).

**Expéditeur de gros volumes** (*bulk sender*) : expéditeur au-delà du seuil de volume d'un fournisseur (pour Gmail, environ 5 000 messages par jour à destination de Gmail). Franchir ce seuil entraîne des exigences renforcées, notamment l'authentification, le désabonnement en un clic et des plafonds de taux de plaintes. Voir [Exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs).

## C

**CAN-SPAM** : loi des États-Unis (2003) sur l'email commercial. Elle impose des en-têtes et des lignes d'objet conformes à la vérité, une adresse postale, et un opt-out opérationnel honoré dans les 10 jours ouvrés. À la différence de la LCAP et du RGPD, elle se fonde sur l'opt-out. Voir [Loi CAN-SPAM (États-Unis)](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis).

**Loi canadienne anti-pourriel (LCAP)** (*CASL*) : loi anti-spam du Canada. Avant tout envoi de messages électroniques commerciaux, elle impose un consentement exprès ou implicite, et elle fixe aussi des règles d'identification et de désabonnement. Voir [LCAP (CASL)](https://emailmarketing.net/fr/apprendre/conformite/lcap-loi-canadienne-anti-pourriel).

**Plainte (signalement de spam)** (*complaint, spam report*) : geste d'un destinataire qui marque un message comme spam. Aucun signal isolé ne nuit davantage à la réputation, et certains fournisseurs le font remonter aux expéditeurs grâce aux feedback loops. Voir [Feedback loops de plaintes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes).

**Taux de plaintes** (*complaint rate*) : part des messages livrés qui ont reçu une plainte, en pourcentage. L'objectif se situe sous 0,1 %. Gmail et Yahoo appliquent un plafond de 0,3 %, à ne jamais atteindre. Voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite).

**Consentement (exprès ou implicite)** (*consent, express vs. implied*) : exprès, il résulte d'un opt-in explicite dont une trace est conservée. Implicite, il découle d'une relation commerciale existante. Le type de consentement qui suffit, et sa durée de validité, varient selon la juridiction (la LCAP fixe une durée limite au consentement implicite). Voir [Conformité](https://emailmarketing.net/fr/apprendre/conformite).

**CSA (Certified Senders Alliance)** : programme de certification d'expéditeurs basé en Allemagne. GMX, WEB.DE et d'autres serveurs de réception européens respectent sa liste blanche. Voir [GMX, WEB.DE et mail.com](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/gmx-web-de-exigences-postmaster).

## D

**DANE pour SMTP** (*DANE for SMTP*) : mécanisme qui s'appuie sur DNSSEC (enregistrements TLSA) pour authentifier le certificat TLS d'un serveur de réception, et qui ferme ainsi la brèche de rétrogradation du STARTTLS opportuniste. Voir [DANE](https://emailmarketing.net/learn/transport-security/dane-smtp).

**Adresse IP dédiée** (*dedicated IP*) : adresse IP d'envoi réservée à un seul expéditeur, qui contrôle toute sa réputation et en répond entièrement. Elle n'a d'intérêt qu'à partir d'un volume minimum régulier, car avec peu de volume l'IP dédiée reste trop « froide » pour se bâtir une réputation. Voir [Allocation de base des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip).

**Report de remise (réponse de liste grise ou de limitation de débit)** (*deferral*) : refus temporaire en 4XX, qui invite l'expéditeur à retenter plus tard. Quand les reports augmentent chez un fournisseur, il s'agit souvent d'une limitation de débit, dernière étape avant le blocage. Voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation).

**Livraison et délivrabilité** (*delivery vs. deliverability*) : il y a livraison quand le serveur de réception a accepté le message. La délivrabilité concerne sa destination ensuite, qu'il s'agisse de la boîte de réception, d'un onglet, du dossier spam ou d'une disparition silencieuse. Voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation).

**DKIM (DomainKeys Identified Mail)** : signature cryptographique définie par la RFC 6376, calculée sur certains en-têtes et sur le corps, et contrôlée grâce à une clé publique publiée dans le DNS. Elle atteste qu'un domaine assume la responsabilité du message et que celui-ci n'a pas été altéré en chemin. Voir [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim).

**DMARC** : Domain-based Message Authentication, Reporting and Conformance. Le domaine publie une politique (`none`, `quarantine` ou `reject`) visant les messages en échec sur SPF ou DKIM alignés, et reçoit des rapports en retour. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) et [Déploiement de DMARC en détail](https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc).

**Alignement DMARC** (*DMARC alignment*) : condition selon laquelle le domaine de l'en-tête From visible doit coïncider, exactement ou au niveau du domaine organisationnel, avec le domaine validé par SPF ou DKIM. Sans alignement, une authentification ne permet pas de réussir DMARC. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

**Double opt-in (opt-in confirmé)** (*double opt-in, confirmed opt-in*) : inscription en deux temps, où aucun email ne part vers l'adresse avant que l'abonné ait cliqué sur un lien de confirmation. Ce parcours supprime les rebonds liés aux fautes de frappe, arrête les inscriptions malveillantes et apporte la preuve du consentement. Voir [Hygiène de base de données](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil).

**DSN (Delivery Status Notification)** : message de rebond structuré pour les machines, défini par la RFC 3464, qui rend compte d'un échec, d'un retard ou d'un succès de livraison, avec un code d'état par destinataire. Voir [Delivery Status Notifications](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison).

## E

**Collecte d'adresses email (scraping)** (*email harvesting*) : récupération d'adresses sans consentement, le plus souvent par des robots qui parcourent les sites web. Ces listes fourmillent d'adresses pièges et d'adresses invalides : n'y envoyez jamais rien. Voir [Hygiène de base de données](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil).

**Validation d'adresses email** (*email validation*) : contrôle préalable à l'envoi, qui porte sur la syntaxe de l'adresse, sur la présence d'enregistrements MX fonctionnels et, au moyen de services de vérification, sur l'existence de la boîte. Pratiquée dès l'inscription, elle prévient des rebonds définitifs ultérieurs. Voir [Hygiène de base de données](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil).

**Engagement** : ensemble des réactions des destinataires sur lesquelles les fournisseurs notent les expéditeurs, par exemple les ouvertures, les clics, le temps de lecture, les réponses, les suppressions sans lecture et les messages sortis du dossier spam. C'est sur cette base statistique que se juge le caractère « désiré et attendu » des emails. Voir [Fondamentaux](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email).

**Codes d'état étendus** (*enhanced status codes*) : codes à trois éléments définis par la RFC 3463 (`5.1.1`, par exemple, désigne une boîte de destination invalide), grâce auxquels un logiciel peut interpréter les réponses SMTP et classer les rebonds. Voir [Codes d'état étendus SMTP](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp).

**Expéditeur d'enveloppe (MAIL FROM, Return-Path, 5321.MailFrom)** (*envelope sender*) : adresse fournie avec la commande SMTP `MAIL FROM`, là où reviennent les rebonds. Il ne faut pas la confondre avec l'en-tête From visible. SPF s'évalue sur son domaine. Voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) et [SMTP](https://emailmarketing.net/learn/rfc/rfc5321-smtp).

## F

**Faux positif** (*false positive*) : email légitime pris à tort pour du spam. Les fournisseurs pèsent ce risque face à celui de laisser passer du spam, ce qui explique qu'un bon historique d'engagement puisse faire pencher la balance en faveur d'un message douteux.

**Feedback loop (FBL)** : dispositif par lequel un fournisseur transmet à l'expéditeur les plaintes pour spam de ses destinataires (en général au format ARF), afin que l'expéditeur mette aussitôt les plaignants en liste de suppression. Voir [Feedback loops de plaintes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes).

**FCrDNS (forward-confirmed reverse DNS)** : situation dans laquelle le PTR de l'adresse IP d'envoi donne un nom d'hôte qui, résolu à son tour, redonne cette même adresse IP. Pour la plupart des grands fournisseurs, c'est un prérequis d'infrastructure. Voir [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi).

**En-tête Feedback-ID** (*Feedback-ID header*) : mécanisme FBL propre à Gmail. L'expéditeur ajoute cet en-tête, dont Gmail regroupe les identifiants pour produire dans Postmaster Tools des statistiques de taux de spam par campagne, sans dévoiler l'identité des plaignants. Voir [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools).

**En-tête From (5322.From)** (*From header*) : adresse d'auteur montrée aux destinataires, définie dans la RFC 5322. C'est sur son domaine que repose l'alignement DMARC. Voir [Format des messages](https://emailmarketing.net/learn/rfc/rfc5322-message-format).

## G

**RGPD** (*GDPR*) : règlement de l'UE sur la protection des données. En marketing par email, il demande une base légale (le plus souvent le consentement explicite), le respect des droits des personnes concernées et la possibilité de retirer facilement son consentement. Il va bien au-delà d'une loi antispam. Voir la [vue d'ensemble de la conformité](https://emailmarketing.net/fr/apprendre/conformite).

**Google Postmaster Tools** : tableau de bord gratuit que Google met à la disposition des expéditeurs. Pour les emails à destination de Gmail, il présente la réputation des domaines et des adresses IP, le taux de spam, les taux de réussite de l'authentification et les erreurs de livraison. Voir [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools).

**Liste grise** (*greylisting*) : technique côté réception, où le serveur refuse temporairement les emails de sources inconnues puis les accepte à la tentative suivante. Elle marche parce qu'une bonne partie des logiciels de spam ne retentent pas. Côté expéditeur, elle apparaît sous forme de reports de remise. Voir [SMTP](https://emailmarketing.net/learn/rfc/rfc5321-smtp).

## H

**Rebond définitif** (*hard bounce*) : échec permanent de livraison (5.X.X), comme une adresse ou un domaine inexistant, ou un rejet par la politique du serveur de réception. Supprimez l'adresse sans attendre et n'y envoyez plus rien. Voir [Hygiène de base de données](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil).

**Pot de miel** (*honeypot*) : piège de deux sortes. C'est soit une adresse piège vierge disposée pour démasquer les collecteurs d'adresses, soit un champ de formulaire invisible que seuls les robots complètent, qui sert à écarter leurs inscriptions. Voir [Adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges).

## I

**Taux de placement en boîte de réception (IPR)** (*inbox placement rate*) : part, en pourcentage, des emails livrés qui arrivent en boîte de réception et non dans le dossier spam, mesurée d'ordinaire fournisseur par fournisseur à l'aide de tests sur liste de test. Voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation).

**Chauffe d'IP (warm-up)** (*IP warming*) : hausse graduelle du volume sur une adresse IP (ou un domaine) neuve, qui laisse aux serveurs de réception le temps de se forger un historique de réputation. Envoyer d'emblée tout le volume depuis une IP froide provoque le filtrage. Voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip).

## L

**Attrition de la liste** (*list churn*) : vitesse à laquelle une liste perd des adresses, par désabonnement, rebond ou abandon. Une base de données marketing se dégrade d'environ 22 % par an, si bien que l'hygiène relève de l'entretien permanent et non d'une action unique. Voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation).

**Hygiène de base de données** (*list hygiene*) : travail permanent de retrait des adresses invalides, en rebond, plaignantes ou désengagées, qui garde en bon état les indicateurs sur lesquels les fournisseurs vous notent. Voir [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil).

**En-tête List-Unsubscribe** (*List-Unsubscribe header*) : en-tête défini par la RFC 2369, qui indique des points de terminaison de désabonnement (mailto ou HTTPS), dont les clients de messagerie font un bouton de désabonnement intégré. Voir [List-Unsubscribe et désabonnement en un clic](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic).

## M

**Fournisseur de messagerie** (*mailbox provider, MBP ou ISP*) : organisation qui exploite les boîtes des destinataires (Gmail, Yahoo, Microsoft, serveurs d'entreprise). En anglais, « mailbox provider » et « ISP » désignent indistinctement le côté réception, et le français dit « fournisseur de messagerie ».

**MTA, MSA, MDA, MUA** : rôles de la chaîne de traitement du courrier. Le Mail Transfer Agent fait circuler les emails d'un serveur à l'autre, le Mail Submission Agent reçoit ceux que soumettent les clients, le Mail Delivery Agent les range dans la boîte, et le Mail User Agent est le client de messagerie du destinataire. Voir [Architecture de l'email](https://emailmarketing.net/learn/rfc/rfc5598-email-architecture).

**MTA-STS** : mécanisme de politique, diffusé en HTTPS, grâce auquel un domaine de réception impose un TLS authentifié au SMTP entrant. Il met en échec les attaques par rétrogradation de STARTTLS sans passer par DNSSEC. Voir [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts).

**Enregistrement MX** (*MX record*) : enregistrement DNS qui indique quels serveurs reçoivent le courrier d'un domaine. La validation des adresses le contrôle, et un domaine doit en posséder un (ou, faute de mieux, un enregistrement A) pour que les rebonds lui parviennent.

## O

**Désabonnement en un clic** (*one-click unsubscribe*) : mécanisme de la RFC 8058. Une URI HTTPS placée dans `List-Unsubscribe`, complétée par un en-tête `List-Unsubscribe-Post`, suffit au destinataire pour se désabonner en une requête POST, sans passer par une page. Les exigences de 2024 de Gmail et de Yahoo l'ont rendu obligatoire pour les expéditeurs de gros volumes. Voir [List-Unsubscribe et désabonnement en un clic](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic).

**Taux d'ouverture** (*open rate*) : part, en pourcentage, des messages livrés dont le pixel de suivi a été chargé. Apple MPP et le préchargement des images le faussent à la hausse : prenez-le pour une estimation, et fiez-vous davantage aux clics et aux conversions. Voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite).

**Opt-in et opt-out** : avec l'opt-in, le destinataire a demandé expressément à recevoir les emails (le modèle de consentement de la LCAP et du RGPD). Avec l'opt-out, les envois restent permis jusqu'à ce qu'il se désabonne (le modèle de CAN-SPAM). Voir [Conformité](https://emailmarketing.net/fr/apprendre/conformite).

## P

**PECR** : Privacy and Electronic Communications Regulations. Ce sont, au Royaume-Uni, les règles de consentement du marketing électronique, appliquées aux côtés du RGPD britannique (UK GDPR). Voir [PECR (Royaume-Uni)](https://emailmarketing.net/fr/apprendre/conformite/royaume-uni-pecr-et-marketing-par-email).

**Postmaster** : fonction chargée du système de messagerie d'un domaine. L'adresse réservée `postmaster@` doit pouvoir recevoir des emails. Les fournisseurs affichent leurs exigences envers les expéditeurs sur leurs « pages postmaster » (par exemple [Exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs)).

**Centre de préférences** (*preference center*) : page qui permet aux abonnés d'ajuster la fréquence, les thèmes et les canaux plutôt que de tout quitter. Des gens qui se seraient peut-être plaints restent ainsi abonnés, avec moins d'envois. Voir [Hygiène de base de données](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil).

## Q

**Quarantaine** (*quarantine*) : politique DMARC qui invite les serveurs de réception à se méfier des messages en échec (le plus souvent en les dirigeant vers le dossier spam) sans aller jusqu'au rejet. Au sens large, le fait pour un filtre de retenir des messages suspects. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

## R

**Campagne de réengagement (reconquête)** (*re-engagement, win-back campaign*) : dernier message adressé aux abonnés inactifs pour qu'ils confirment leur intérêt, avant que la politique de mise en sommeil ne les retire de la liste. Voir [Hygiène de base de données](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil).

**DNS inverse (enregistrement PTR)** (*reverse DNS, PTR record*) : résolution DNS qui associe une adresse IP à un nom d'hôte. Une adresse IP d'envoi doit disposer d'un enregistrement PTR non générique, confirmé dans l'autre sens (voir FCrDNS). À défaut, de nombreux fournisseurs refusent ses emails. Voir [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi).

## S

**Liste de test (seed list)** : ensemble de boîtes de test, réparties chez divers fournisseurs et surveillées, qui indique où un message a abouti (boîte de réception, onglet, dossier spam ou nulle part). Ces boîtes n'ont aucun historique d'engagement, et leurs résultats sont donc en général plus sombres que la réalité. Voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation).

**Réputation d'expéditeur** (*sender reputation*) : notes que les serveurs de réception donnent à vos adresses IP et à vos domaines d'envoi, à partir des plaintes, des rebonds, de l'engagement, des adresses pièges touchées, des schémas de volume et de l'authentification. Cette réputation détermine si vos emails arrivent en boîte de réception, subissent une limitation de débit ou sont bloqués. Voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation).

**Adresse IP partagée** (*shared IP*) : adresse IP d'envoi que de nombreux expéditeurs utilisent et dont ils se partagent la réputation. Elle est adaptée tant que votre volume reste sous le seuil qui justifie une IP dédiée, et en contrepartie vous subissez le comportement des autres expéditeurs. Voir [Allocation de base des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip).

**SMTP** : Simple Mail Transfer Protocol (RFC 5321), protocole qui achemine l'email de serveur en serveur. La gestion des rebonds s'appuie d'abord sur ses codes de réponse. Voir [SMTP](https://emailmarketing.net/learn/rfc/rfc5321-smtp).

**SNDS (Smart Network Data Services)** : tableau de bord que Microsoft offre aux expéditeurs, organisé par adresse IP, pour le courrier destiné à ses domaines grand public. On y trouve le volume, les verdicts du filtre, le taux de plaintes et les adresses pièges touchées, et il va de pair avec JMRP, la feedback loop de plaintes de Microsoft. Voir [Microsoft SNDS et JMRP](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp).

**Rebond temporaire** (*soft bounce*) : échec passager de livraison (4.X.X), comme une boîte pleine, un serveur hors service ou une limitation de débit. Le système retente l'envoi de lui-même. Si une adresse accumule les rebonds temporaires, placez-la en liste de suppression. Voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite).

**Adresse piège** (*spam trap*) : adresse qui dégrade votre réputation dès que vous lui envoyez un email. Un piège vierge n'a jamais servi à personne, et seules des listes achetées ou collectées y mènent. Un piège recyclé est une ancienne adresse réelle, délaissée puis convertie en piège. Un piège à fautes de frappe punit le manque de rigueur dans le traitement des inscriptions. Voir [Adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges).

**SpamAssassin** : filtre de contenu libre (open source), largement déployé, qui attribue une note aux messages selon des ensembles de règles. On retrouve ces notes dans les en-têtes posés par certains serveurs de réception, ainsi que dans les comptes rendus de tests sur liste de test. Voir [Outils de test et de diagnostic de la délivrabilité](https://emailmarketing.net/fr/apprendre/reference/outils-de-test-et-de-diagnostic-de-la-delivrabilite).

**SPF (Sender Policy Framework)** : enregistrement DNS défini par la RFC 7208, qui énumère les hôtes habilités à envoyer des emails au nom d'un domaine et se vérifie sur l'expéditeur d'enveloppe. Il ne tolère que 10 requêtes DNS, et le transfert le met en échec. Voir [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf).

**Usurpation d'identité (spoofing)** : fait de contrefaire l'identité d'un expéditeur (le plus souvent l'en-tête From) pour se présenter comme une source digne de confiance. C'est la menace que SPF, DKIM et DMARC ont pour but de contrer. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc).

**Politique de mise en sommeil (sunset policy)** : règles qui espacent d'abord les envois vers les adresses devenues inactives, puis les placent en liste de suppression, avant qu'elles ne deviennent des rebonds définitifs ou des adresses pièges recyclées (au bout d'environ 12 mois sans activité). Voir [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil).

**Liste de suppression** (*suppression list*) : liste d'adresses exclues de tout envoi, parce qu'elles se sont désabonnées, ont rebondi définitivement ou ont porté plainte. Elle protège votre réputation, alors ne passez jamais outre. Voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation).

## T

**Limitation de débit** (*throttling*) : plafonnement, par un serveur de réception, du nombre d'emails qu'il prend à un expéditeur sur une période donnée, qui se manifeste par des reports de remise. Par extension, le terme désigne aussi la limitation du débit d'envoi que l'expéditeur s'applique pour rester sous ces plafonds. Voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite).

**TLS-RPT** : mécanisme de rapports (RFC 8460) grâce auquel les serveurs de réception informent un domaine des négociations TLS ratées sur le courrier qu'il reçoit. Il vient compléter MTA-STS et DANE. Voir [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt).

**Pixel de suivi** (*tracking pixel*) : image distante et invisible, dont le téléchargement enregistre une « ouverture ». Les indicateurs d'ouverture reposent sur ce mécanisme, que les proxys de récupération d'images rendent peu fiable. Voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite).

**Email transactionnel** (*transactional email*) : email qu'une action du destinataire lui-même déclenche (reçu, réinitialisation de mot de passe, notification). Les règles de consentement marketing et les suppressions marketing ne s'y appliquent généralement pas, contrairement aux enjeux de délivrabilité : gardez-le séparé des flux marketing. Voir [Segmentation et allocation avancées des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip).

## U

**Email commercial non sollicité (UCE)** (*unsolicited commercial email*) : email commercial expédié sans la permission du destinataire. C'est du spam au sens opérationnel, et bien souvent au sens juridique aussi.

**Taux de désabonnement** (*unsubscribe rate*) : part des emails livrés qui entraînent un désabonnement, en pourcentage (niveau sain : sous environ 0,3 %). Pour votre réputation, un désabonnement coûte bien moins qu'une plainte, alors facilitez-le. Voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite).

## V

**VMC (Verified Mark Certificate)** : certificat prouvant la propriété d'un logo (le plus souvent une marque déposée). Gmail, entre autres, l'exige avant d'afficher un logo BIMI. Voir [BIMI](https://emailmarketing.net/fr/apprendre/authentification/bimi).

## Voir aussi

- [Outils de test et de diagnostic de la délivrabilité](https://emailmarketing.net/fr/apprendre/reference/outils-de-test-et-de-diagnostic-de-la-delivrabilite), pour appliquer concrètement nombre de ces notions
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)

# Inscriptions Spamhaus en détail : politiques SBL, CSS, PBL et DBL, et retrait de liste

> Le détail, liste par liste, des critères d'inscription de Spamhaus, de sa politique d'extension des inscriptions, du retrait en libre-service ou après enquête, des codes de retour et d'erreur, et de la bonne façon d'interroger les zones côté serveur de réception, au-delà de la présentation des zones dans Listes de blocage et Spamhaus.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/inscriptions-spamhaus-en-detail

Quand Spamhaus inscrit une adresse IP partagée ou le domaine d'un client de votre plateforme, vous devez connaître la politique réelle de cette liste, la façon dont l'inscription peut s'étendre et la procédure exacte pour obtenir son retrait. Les sections ci-dessous traitent chaque liste à tour de rôle.

[Listes de blocage DNS et zones Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus) explique le fonctionnement des listes de blocage DNS (DNSBL), donne les tableaux complets des zones et des codes de retour, et présente les recommandations de Spamhaus aux expéditeurs.

## SBL : Spamhaus Blocklist (`127.0.0.2`)

Une équipe de recherche qui travaille à partir du renseignement en sources ouvertes (OSINT) tient la SBL à la main, et la base compte en moyenne **30 000 à 40 000 inscriptions**. La zone est **reconstruite et rechargée toutes les 5 minutes, en continu (24/7)**, si bien que les nouvelles inscriptions comme les retraits prennent effet rapidement.

### Ce qui est inscrit

La SBL inscrit les adresses IP « sous le contrôle de spammeurs et d'abuseurs, utilisées par eux ou mises à leur disposition pour des emails non sollicités envoyés en masse ou d'autres formes d'abus sur Internet » :

- **Plages de snowshoe spam** : « des plages et des domaines à l'identification médiocre ou changeant fréquemment ».
- **Hébergement de spam** : les adresses IP qui hébergent des sites web promus par spam, ou des ressources utilisées par des opérations de spam et de logiciels malveillants. L'adresse IP n'a pas besoin d'envoyer des emails pour être inscrite.
- **Services de spam** : l'hébergement « bulletproof » (« des actions explicites ou tacites visant à ne pas déconnecter les clients qui spamment »), les logiciels de spam (spamware, « des logiciels dont le but principal est de faciliter l'envoi en grand volume d'emails non sollicités ») et les outils de scraping d'adresses.
- **Menaces de sécurité** : serveurs de commande et de contrôle (C&C) de botnets, sites infectés par des logiciels malveillants, pages de phishing et infrastructures de rançongiciels.

Des **inscriptions informatives** existent à côté des inscriptions bloquantes. Spamhaus les décrit comme « un signal d'alerte précoce indiquant que l'IP inscrite a un mauvais comportement. Les inscriptions informatives sont indicatives et n'entraînent pas le blocage des IP. » Considérez-en une comme le dernier avertissement avant une inscription SBL bloquante.

### Politique d'extension des inscriptions

Quand un réseau ignore ses inscriptions, Spamhaus étend l'inscription au-delà des adresses IP abusives, « aux adresses IP de l'infrastructure même de ce réseau, à des plages étendues de ce réseau, voire à ce réseau tout entier ». Les déclencheurs sont les suivants :

- ignorer des inscriptions SBL pendant de longues périodes ;
- prétendre supprimer des spammeurs qui reviennent sans cesse (en déplaçant des clients d'une adresse IP à une autre) ;
- fournir un hébergement bulletproof ;
- des problèmes persistants de spam ou de sécurité.

Pour un ESP, c'est le risque qui menace toute l'entreprise. Tolérer un seul mauvais client peut transformer l'inscription d'une seule adresse IP en inscription des serveurs MX de l'entreprise, de son site web ou de toute son allocation.

### Retrait de liste SBL

Seul le **fournisseur d'accès ou le réseau responsable de l'adresse IP inscrite** peut demander le retrait. Les utilisateurs finaux et les clients d'un ESP ne le peuvent pas, et doivent passer par leur fournisseur. La procédure :

1. Lisez la page de l'inscription SBL (accessible depuis l'outil de vérification) pour comprendre le problème de spam précis.
2. Corrigez-le **définitivement**. Pour un client spammeur, Spamhaus attend généralement du fournisseur qu'il résilie ou déconnecte le serveur, supprime les entrées DNS servies par ses serveurs DNS principaux, supprime les enregistrements PTR, empêche les serveurs MX d'accepter des emails pour le client, et supprime les entrées SWIP et rWhois. Autrement dit, il faut déprovisionner entièrement le client, et pas seulement suspendre ses envois.
3. Le service abus ou sécurité du fournisseur d'accès envoie une demande de retrait à la SBL Removals Team **en décrivant comment le problème a été résolu**. Une explication est exigée, pas un simple « merci de retirer l'inscription ».

Aucun délai n'est publié au-delà de « une fois que l'abus a pris fin ». Les enquêtes peuvent exiger une preuve de consentement et une nouvelle demande d'autorisation auprès de la liste en cause (voir [Listes de blocage DNS et zones Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus)). Le retrait de liste est toujours gratuit : « Toute offre, d'où qu'elle vienne, de retirer une inscription Spamhaus contre paiement est une escroquerie. »

## CSS : Combined Spam Sources (`127.0.0.3`)

CSS est la partie **automatisée** de la zone SBL. Elle cible « les adresses IP impliquées dans l'envoi d'emails à faible réputation », et elle n'observe que le trafic SMTP sur le port 25. Elle compte **2 à 4 millions d'inscriptions** à tout moment, avec **300 000 à 400 000 nouvelles inscriptions toutes les 24 heures**. C'est la liste sur laquelle un client d'ESP légitime mais négligent a le plus de chances de se retrouver.

### Détection et granularité

Les inscriptions résultent de « multiples événements et heuristiques », que Spamhaus ne divulgue pas. Les déclencheurs qu'il nomme sont :

- **les opérations de snowshoe** : des sources de spam statiques réparties finement sur des adresses IP et des domaines, que les autres listes ne détectent pas ;
- **les hôtes compromis** : installations non sécurisées, serveurs mal configurés, comptes piratés et systèmes de gestion de contenu (CMS) exploités ;
- **la mauvaise hygiène de base de données** : des emails non sollicités envoyés par des expéditeurs qui gèrent mal leurs abonnés.

Granularité : **IPv4 /32 ; IPv6 /64** (selon la pratique d'attribution de la RFC 4291). Les inscriptions de blocs IPv6 plus larges sont agrégées si de nombreux /64 d'un même réseau se comportent mal. C'est pourquoi les ESP qui envoient en IPv6 doivent séparer leurs clients au minimum par /64.

### Causes fréquentes pour l'infrastructure d'un ESP

- un nom HELO ou EHLO qui n'est pas un FQDN (`localhost.localdomain`, un simple `mail`) ;
- un rDNS absent, ou un rDNS qui ne correspond pas au DNS direct (l'enregistrement PTR doit donner un nom d'hôte qui se résout vers la même adresse IP) ;
- l'absence de chauffe d'IP, si bien que des adresses IP froides qui envoient du volume ressemblent à des expéditeurs de snowshoe (voir [Recommandations pour la chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)) ;
- des listes de clients constituées en simple opt-in ou conservées sans hygiène, qui touchent des adresses pièges (« utilisez le double opt-in pour éviter les adresses pièges ») ;
- les réglages par défaut des panneaux de contrôle (Plesk, cPanel, DirectAdmin) et des répartiteurs de charge qui présentent des identités génériques, et les DNS avec caractères génériques.

### Expiration et retrait de liste CSS

**Une inscription expire normalement d'elle-même trois jours (72 h) après la dernière détection de spam.** « Dans certains cas d'abus chronique, les inscriptions peuvent durer plus longtemps. » Comme l'expiration est automatique, la première décision consiste à choisir entre attendre et retirer vous-même l'inscription.

Le retrait en libre-service se fait via [check.spamhaus.org](https://check.spamhaus.org/) : « La cause du problème DOIT être identifiée et corrigée avant de retirer une IP de CSS. » Le nombre de retraits en libre-service est **limité**, et l'adresse IP est de nouveau inscrite immédiatement si la cause persiste. Épuiser ses retraits sans corriger la cause profonde transforme un désagrément de 72 heures en inscription chronique. La procédure CSS de l'outil de vérification contrôle les bases des RFC 5321 et 5322 (rDNS, HELO) avant d'autoriser le retrait.

## PBL : Policy Blocklist (`127.0.0.10` / `127.0.0.11`)

La PBL relève de la **politique, pas de l'abus**. Elle inscrit « des plages d'adresses IP d'utilisateurs finaux qui ne devraient pas tenter de livrer directement des emails SMTP non authentifiés à un quelconque serveur de messagerie sur Internet ». Une inscription PBL n'accuse personne de spam. La liste contient **plus de 1,4 milliard d'adresses IPv4, soit environ 40 % de l'espace IPv4 routable**, principalement des plages haut débit et d'accès commuté de fournisseurs d'accès, plus quelques blocs CIDR IPv6. La zone est reconstruite **toutes les 15 minutes**.

Les données proviennent de deux sources, que distingue le code de retour :

| Code | Qui a inscrit la plage |
|---|---|
| `127.0.0.10` | Le fournisseur d'accès lui-même, via un compte PBL (une déclaration qui fait autorité sur son propre espace d'adresses) |
| `127.0.0.11` | La recherche de Spamhaus : un espace d'utilisateurs finaux à forte concentration de machines zombies de botnets |

### Retrait en libre-service

L'opérateur d'un serveur de messagerie sur une adresse IP inscrite à la PBL peut retirer **une seule adresse IP** via le Reputation Checker, si toutes ces conditions sont réunies :

- l'adresse IP est **statique** (les adresses IP dynamiques doivent plutôt relayer par le smarthost du fournisseur d'accès) ;
- un serveur de messagerie sortant fonctionne réellement sur cette adresse ;
- le DNS direct (A) et le DNS inverse (PTR) sont correctement configurés ;
- l'adresse IP est attribuée à la personne ou à l'entreprise qui demande le retrait. Les demandes envoyées depuis des adresses de messagerie gratuite (Gmail, Hotmail, Yahoo) sont refusées, et la demande doit provenir d'une adresse sur un domaine qui correspond au serveur de messagerie.

Le retrait prend effet en **environ 15 minutes**. Les exclusions **expirent au bout d'un an**, et elles sont **annulées immédiatement si du spam est détecté**. Retirer de nombreuses adresses IP une à une fait annuler les exclusions et révoquer l'accès : les retraits de plusieurs plages doivent donc être faits par le fournisseur d'accès propriétaire de l'espace. C'est important quand un ESP acquiert une plage située dans un bloc PBL d'un réseau d'accès : demandez au fournisseur en amont d'exclure la plage dans son compte PBL, au lieu de retirer les adresses IP une par une.

Pour les utilisateurs finaux derrière la PBL, la bonne solution n'est pas du tout le retrait, mais la **soumission authentifiée sur le port 587 ou 465** vers le smarthost de leur fournisseur. La PBL n'affecte que la livraison directe vers les serveurs MX sur le port 25.

### Comptes PBL des fournisseurs d'accès

Les réseaux gèrent leur propre espace d'adresses avec un compte PBL. Pour y avoir droit, un réseau doit disposer d'au moins une allocation IPv4 /24 ou IPv6 /48, d'un domaine principal vérifiable dans l'IP-Whois, le rWhois ou le rDNS, d'une adresse `abuse@` fonctionnelle, et d'une adresse email professionnelle sur le domaine principal (ou sur un domaine apparenté). Un compte contient des **Master Ranges** (l'allocation complète), qui contiennent à leur tour des **inscriptions de zone PBL** (les parties effectivement inscrites). Les modifications prennent effet en moins de 15 minutes. Un ESP qui exploite sa propre allocation devrait détenir un compte PBL, ne serait-ce que pour s'assurer que ses plages transactionnelles et d'envoi sont exclues, et pour inscrire tout espace d'accès client qu'il exploite.

## DBL : Domain Blocklist (`127.0.1.x`)

La DBL n'inscrit que des domaines : « Aucune adresse IP n'est inscrite dans la DBL. » Elle compte plus de 80 miroirs environ dans le monde. Les inscriptions sont en majorité automatisées, avec une intervention manuelle si nécessaire, et **expirent automatiquement dès que le domaine ne répond plus aux critères d'inscription**. Le tableau complet des codes de retour figure dans [Listes de blocage DNS et zones Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus). La distinction essentielle oppose les codes `127.0.1.2–.6`, où le domaine lui-même est mauvais (spam, phishing, logiciel malveillant, C&C de botnet), aux codes `127.0.1.102–.106`, pour les **sites légitimes détournés**, c'est-à-dire des domaines légitimes compromis et utilisés à des fins abusives.

### Causes d'inscription

Spamhaus ne divulgue délibérément pas ses critères (« Nous ne discutons pas des critères précis que nous utilisons »), mais il énonce ces principes de réputation :

- **Une réputation inconnue compte comme une mauvaise réputation.** « Les réputations se construisent dans le temps, et construire une bonne réputation prend plus longtemps qu'en construire une mauvaise. » Les nouveaux domaines d'envoi partent avec un handicap (voir aussi ZRD pendant les 24 premières heures).
- **L'anonymat nuit à la réputation** (enregistrements WHOIS anonymisés, opérateurs cachés).
- **Les réputations des domaines et des adresses IP s'influencent mutuellement.** Un hébergement propre avec un rDNS correct compte pour le domaine.
- **La rotation de domaines du snowshoe** : de nombreux domaines qui changent souvent constituent en eux-mêmes le signal. « Les expéditeurs légitimes investissent dans une infrastructure durable, à long terme. »
- **SPF, DKIM et DMARC ne protègent pas contre l'inscription.** Les spammeurs s'authentifient aussi, et les enregistrements d'authentification ne justifient jamais à eux seuls un retrait de liste.
- Spamhaus **n'analyse pas les sites web**. Les inscriptions proviennent du trafic observé : « quand nous voyons ces signes, cela signifie avec certitude que le site web ou le serveur n'est pas sécurisé, qu'il est infecté ou compromis ».

### Sites légitimes détournés (`127.0.1.102–.106`)

Ce sont des sites légitimes compromis : un CMS ou des extensions obsolètes, des identifiants faibles, ou une mauvaise sécurité du serveur. Quand c'est possible, les inscriptions visent **des noms d'hôte plutôt que le domaine entier**, pour éviter de bloquer le site légitime. Les étapes de retrait que prescrit Spamhaus sont les suivantes : mettre le site hors ligne pendant la correction, supprimer les fichiers infectés, mettre à jour le CMS et toutes les extensions, auditer la sécurité du serveur, et changer tous les mots de passe en activant l'authentification à deux facteurs (2FA). Pour un ESP, c'est la famille de codes à vérifier quand le domaine du propre site web d'un client (utilisé dans les liens) est inscrit alors que les pratiques d'envoi du client semblent saines.

### Règles d'interrogation que les serveurs de réception doivent respecter

- **N'interrogez jamais d'adresses IP dans la DBL.** Une requête d'IP renvoie toujours une inscription (`127.0.1.255`), à dessein, pour qu'un filtre mal configuré qui rejette les emails contenant des liens vers des IP littérales échoue de manière visible.
- **Caractères génériques** : la DBL inscrit les domaines au niveau du domaine enregistré, et chaque nom d'hôte ou sous-domaine d'un domaine inscrit renvoie une inscription (`www.bank.phish.example.tld` correspond à une inscription de `example.tld`). Les variantes ressemblantes du domaine ne correspondent pas.
- Vérifiez à trois étapes : le domaine rDNS de l'adresse IP qui se connecte, à la connexion ; les domaines HELO et `MAIL FROM`, avant DATA ; et les URL, les domaines des en-têtes et les adresses de contact, lors de l'inspection du contenu.
- Points de test : `test.dbl.spamhaus.org` renvoie `127.0.1.2` (le test opérationnel de la RFC 5782), `dbltest.com.dbl.spamhaus.org` renvoie `127.0.1.2`, et tout ce qui n'est pas inscrit renvoie NXDOMAIN.
- **Validez la plage de la réponse** : seules les réponses comprises dans `127.0.1.0/24` sont des inscriptions DBL. C'est important en Chine, où la manipulation du trafic par le Golden Shield peut altérer les réponses DNS. Toute autre valeur signifie que le domaine n'est pas inscrit. (Les miroirs de Spamhaus en Chine ne servent la DBL qu'en requêtes d'IP, si bien que les utilisateurs situés en Chine obtiennent les réponses sur les domaines depuis l'extérieur du pays.)
- La DBL fonctionne dans les déploiements RPZ (« pare-feu DNS ») et pour le filtrage du spam dans les commentaires de blogs. Microsoft Exchange ne prend pas en charge nativement les DNSBL de domaines (des produits tiers sont nécessaires).

### Retrait de liste DBL

- **Automatique** : la plupart des inscriptions expirent d'elles-mêmes une fois que l'activité qui les a déclenchées s'arrête. Pour une inscription passagère, corriger la cause et attendre constitue souvent toute la procédure.
- **Manuel** : utilisez le formulaire du Reputation Checker. « Utiliser le formulaire ne garantit pas le retrait », et les personnes qui demandent des retraits trop souvent sont bloquées. Les retraits approuvés sont traités immédiatement, en quelques minutes chez Spamhaus, mais les copies locales des serveurs de réception peuvent avoir **jusqu'à 24 heures** de retard (contactez Spamhaus si le domaine est toujours inscrit 24 h après l'approbation).
- **La réinscription est automatique** si le problème est de nouveau détecté : un retrait de liste sans correction de la cause profonde ne dure donc pas.
- Le retrait de liste est toujours gratuit.

### Recommandations DBL pour les raccourcisseurs d'URL et les redirecteurs (les domaines de suivi des clics des ESP se comportent exactement de la même façon)

Spamhaus conseille à ces services de vérifier chaque domaine de destination dans la DBL **avant** de créer un lien court, puis de vérifier de nouveau plus tard (après environ 1 jour et environ 1 semaine). Refusez les destinations dont les enregistrements A figurent dans la SBL (et, en option, dans la XBL). N'autorisez jamais la modification de l'URL de destination après la création du lien, et n'enchaînez pas les liens par d'autres raccourcisseurs. Suspendez les liens abusifs avec une réponse 404 ou 410 (et non une page intermédiaire). Exigez un CAPTCHA ou une autre protection contre les robots pour créer des liens, envisagez ZRD pour filtrer les domaines qui viennent d'être enregistrés, et faites fonctionner des adresses `abuse@` et `postmaster@` ainsi que des feedback loops pour le service. Un ESP dont le domaine partagé de suivi des clics est inscrit dans la DBL a généralement ignoré plusieurs de ces règles à la fois.

## Interroger correctement les zones (FAQ sur l'utilisation des DNSBL)

Un serveur de réception, y compris un ESP qui filtre ses propres emails entrants ou les emails de sa plateforme, doit suivre ces règles :

- **N'interrogez que ZEN** pour les vérifications d'IP : « Les sous-zones de Zen (SBL, XBL, PBL) ne doivent pas être interrogées séparément », et ne combinez jamais des requêtes ZEN avec des requêtes SBL, XBL ou PBL. Une seule réponse ZEN contient déjà tous les codes applicables.
- **N'appliquez pas les DNSBL aux emails sortants**, « en particulier la PBL », car vos propres clients de smarthost se trouvent légitimement dans l'espace PBL. La surveillance des emails sortants exige d'autres outils (voir [Surveillance et rétablissement de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation)).
- **N'interrogez jamais via des résolveurs publics** (8.8.8.8, Cloudflare, Quad9, résolveurs partagés par les clients d'un fournisseur d'accès), sauf si le résolveur prend en charge EDNS Client Subnet (ECS). Le réseau d'origine doit être identifiable. Les requêtes qui passent par un résolveur anonyme reçoivent la réponse `127.255.255.254`. Les requêtes provenant de grands environnements d'hébergement mutualisé sont refusées.
- **Traitez les codes d'erreur comme « ne pas bloquer »** : `127.255.255.254` (une requête via un résolveur anonyme ou public), `127.255.255.255` (volume de requêtes dépassé) et `127.255.255.252` (une faute de frappe dans le nom de zone). Un filtre qui les traite comme des inscriptions rejette tous les emails.
- **Testez** depuis le réseau du serveur de messagerie lui-même : `dig 2.0.0.127.zen.spamhaus.org +short` doit renvoyer `127.0.0.x`, et `dig 1.0.0.127.zen.spamhaus.org +short` doit renvoyer NXDOMAIN. Le Blocklist Tester, sur `blt.spamhaus.com`, vérifie toute la chaîne en envoyant des emails de test.
- **Niveaux d'accès** : les miroirs publics gratuits sont réservés aux petites et moyennes organisations non commerciales, dans le cadre d'une utilisation équitable. La politique d'utilisation équitable des DNSBL ne publie aucun chiffre ferme, et les services commerciaux de filtrage anti-spam et les fournisseurs d'accès doivent s'abonner quel que soit leur volume. Le niveau gratuit **DQS** est limité à « ne pas dépasser régulièrement **100 000 requêtes par jour** », pour un usage non commercial. Au-delà, utilisez DQS payant ou le **Data Feed** par rsync (un transfert local de zone, qui exige d'exploiter votre propre résolveur). DQS donne aussi accès à certains jeux de données disponibles uniquement par ce biais, comme ZRD, HBL et AuthBL.
- **N'automatisez pas les recherches sur check.spamhaus.org.** L'outil de vérification web est destiné à un usage manuel, et une utilisation automatisée fait bloquer par le pare-feu l'adresse IP qui interroge.

## Synthèse des procédures de retrait de liste

| Liste | Code | Qui peut obtenir le retrait | Mécanisme | Délai |
|---|---|---|---|---|
| SBL | 127.0.0.2 | Uniquement le fournisseur d'accès ou le réseau responsable | Corriger définitivement le problème, puis le service abus écrit à la SBL Removals Team pour expliquer la correction. Une preuve de consentement peut être exigée | La zone se recharge toutes les 5 min une fois le retrait approuvé. La durée de l'enquête varie |
| CSS | 127.0.0.3 | Libre-service (nombre d'utilisations limité) | Corriger la cause (rDNS, HELO, hygiène), puis utiliser l'outil de vérification, ou attendre | Expiration automatique environ 72 h après la dernière détection. Réinscription immédiate si rien n'est corrigé |
| XBL | 127.0.0.4 | Libre-service | Éliminer le logiciel malveillant ou corriger la compromission, puis utiliser l'outil de vérification | Réinscription rapide si l'infection persiste |
| PBL | 127.0.0.10/.11 | Le titulaire de l'adresse IP (une seule IP) ou le fournisseur d'accès propriétaire de l'espace (plages) | L'outil de vérification (IP statique, serveur de messagerie, DNS concordant, et demandeur qui n'utilise pas de messagerie gratuite). Les fournisseurs d'accès utilisent leur compte PBL | Environ 15 min. L'exclusion expire au bout de 1 an et est annulée si du spam est détecté |
| DBL | 127.0.1.x | Le titulaire du domaine | Expiration automatique, ou formulaire de l'outil de vérification (sans garantie) | Immédiat après approbation. Les serveurs de réception peuvent avoir jusqu'à 24 h de retard |

Toutes les vérifications et demandes commencent sur l'**[IP & Domain Reputation Checker](https://check.spamhaus.org/)**. Il est gratuit, ne demande aucun compte pour vérifier, et évalue automatiquement l'adresse IP depuis laquelle vous le consultez. L'outil en ligne est une application JavaScript protégée contre les robots, et seul son texte d'accueil a pu être capturé (« Do you have problems sending email? … Relax, you're in the right place », soit « Vous avez des problèmes pour envoyer des emails ? … Pas d'inquiétude, vous êtes au bon endroit », d'après un instantané de la Wayback Machine daté du 2026-07-09). Son comportement décrit ci-dessus provient des pages officielles de Spamhaus sur les listes de blocage et de ses FAQ.

Le retrait d'une zone Spamhaus ne débloque pas immédiatement la livraison. Les serveurs de réception rafraîchissent leurs copies selon leur propre calendrier (en quelques minutes pour les utilisateurs de DQS ou de ZEN, et jusqu'à 24 h pour les plus lents), et les dégâts sur votre réputation auprès de chaque serveur de réception se résorbent séparément.

# Listes de blocage DNS et zones Spamhaus

> Le fonctionnement des DNSBL, les listes de blocage de Spamhaus (SBL/CSS/XBL/PBL/DBL/ZRD/AuthBL/HBL, réunies dans ZEN), les raisons d'une inscription, le déroulement d'un retrait de liste et les recommandations opérationnelles de Spamhaus en matière de délivrabilité.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus

Lorsqu'une liste de blocage largement utilisée inscrit votre adresse IP ou votre domaine, des serveurs de réception partout sur Internet peuvent refuser vos messages au même moment. Spamhaus est le fournisseur de données de réputation le plus utilisé dans l'univers de l'email.

Des fournisseurs de messagerie comme Comcast, RoadRunner et Sky utilisent des filtres anti-spam commerciaux et des données de réputation de fournisseurs comme Cloudmark et Spamhaus. Les plus grands fournisseurs de messagerie gratuite (Gmail, Hotmail et Outlook.com, et Verizon Media, l'ancien Yahoo et AOL) s'appuient surtout sur un filtrage qu'ils ont construit eux-mêmes à partir des données de leurs propres utilisateurs, et peuvent ou non le combiner avec des données commerciales. Une inscription par un fournisseur de données de réputation largement adopté peut donc bloquer la livraison auprès de milliers de réseaux de réception à la fois.

Il existe des centaines de listes de blocage dans le secteur, mais seules quelques-unes ont une portée large. N'importe quel outil complet de vérification des listes de blocage (voir [Outils de test de délivrabilité](https://emailmarketing.net/fr/apprendre/reference/outils-de-test-et-de-diagnostic-de-la-delivrabilite)) montrera votre adresse IP ou votre domaine inscrit quelque part, donc le sérieux à accorder à une inscription dépend de qui l'a émise. Une inscription sur la SBL de Spamhaus a une portée considérable, tandis qu'une inscription sur une liste disparue ou confidentielle peut être ignorée.

## Fonctionnement d'une DNSBL

Une liste de blocage fondée sur le DNS (DNSBL) publie ses données d'inscription sous forme de zone DNS. Le serveur de réception vérifie une adresse IP qui se connecte (ou un domaine vu pendant la transaction) au moyen d'une requête DNS ordinaire de type `A` :

- **Listes d'adresses IP** : inversez les octets de l'adresse IP et ajoutez la zone. Pour vérifier `192.0.2.99` dans ZEN, interrogez `99.2.0.192.zen.spamhaus.org`.
- **Listes de domaines** : ajoutez le domaine devant la zone, par exemple `example.com.dbl.spamhaus.org`.

Si l'adresse IP ou le domaine n'est **pas** inscrit, la requête renvoie NXDOMAIN. S'il **est** inscrit, la requête renvoie une ou plusieurs adresses dans `127.0.0.0/8`, et le code de retour précis indique quel jeu de données l'a inscrit et pourquoi. Une seule requête ZEN peut renvoyer plusieurs réponses dans le même paquet, une par jeu de données où figure l'adresse IP. C'est pourquoi interroger ZEN équivaut à interroger séparément SBL, CSS, XBL et PBL, et coûte moins cher.

Les serveurs de réception utilisent la réponse à différentes étapes :

| Étape SMTP | Ce qui est vérifié | Listes utilisées |
|---|---|---|
| Connexion initiale | L'adresse IP qui se connecte ; le domaine du DNS inverse (rDNS) de cette adresse IP | ZEN (SBL, CSS, XBL et PBL), DBL |
| Transaction SMTP | Chaîne HELO, domaine `MAIL FROM` | DBL, ZRD |
| Analyse du contenu (après DATA) | Domaines et URL des en-têtes et du corps, empreintes de fichiers | DBL, ZRD, HBL |

## Les zones Spamhaus

| Zone | Type | Contenu |
|---|---|---|
| `sbl.spamhaus.org` | IP | SBL : sources de spam avérées, opérations de spam et infrastructures au service du spam (inclut CSS) |
| `xbl.spamhaus.org` | IP | XBL : systèmes exploités ou compromis (hôtes infectés par un logiciel malveillant, proxys ouverts, nœuds de botnet) |
| `pbl.spamhaus.org` | IP | PBL : une liste de politique qui recense les plages d'adresses IP qui ne devraient pas envoyer directement vers les serveurs MX (plages dynamiques ou résidentielles, objets connectés) |
| `zen.spamhaus.org` | IP | ZEN : SBL, CSS, XBL et PBL en une seule requête. La liste d'adresses IP recommandée |
| `dbl.spamhaus.org` | Domaine | DBL : domaines à mauvaise réputation (spam, phishing, logiciel malveillant, serveur de commande et de contrôle (C&C) de botnet, domaines légitimes détournés) |
| `zrd.spamhaus.org` | Domaine | ZRD : Zero Reputation Domains, c'est-à-dire des domaines dont l'enregistrement a été observé au cours des dernières 24 heures |
| `authbl` (DQS) | IP | AuthBL : adresses IP impliquées dans des attaques d'authentification par bourrage d'identifiants (credential stuffing) ou par force brute |
| `hbl` (DQS) | Empreinte | HBL : empreintes SHA-256 et SHA-1 de fichiers malveillants, de portefeuilles de cryptomonnaie, et d'adresses email et d'URL vues dans du spam |

### Codes de retour

Une requête pour un élément inscrit renvoie un ou plusieurs de ces codes :

| Code de retour | Zones | Signification |
|---|---|---|
| `127.0.0.2` | sbl, zen | Inscription SBL (une source ou une opération de spam examinée manuellement) |
| `127.0.0.3` | sbl, zen | Inscription CSS (détection automatisée Combined Spam Sources) |
| `127.0.0.4` | xbl, zen | Inscription XBL (hôte compromis) |
| `127.0.0.9` | sbl, zen | Données SBL DROP (blocs d'adresses détournés ou loués à des spammeurs ; ne jamais les router) |
| `127.0.0.10` | pbl, zen | PBL : une plage désignée par le fournisseur d'accès (ISP) lui-même |
| `127.0.0.11` | pbl, zen | PBL : une plage désignée par Spamhaus |
| `127.0.0.20` | authbl | Inscription AuthBL |
| `127.0.0.30` | sbl, zen | BCL (Botnet Controller List) |
| `127.0.1.2` | dbl | Domaine de spam |
| `127.0.1.4` | dbl | Domaine de phishing |
| `127.0.1.5` | dbl | Domaine de logiciel malveillant |
| `127.0.1.6` | dbl | Domaine de C&C de botnet |
| `127.0.1.102` | dbl | Site légitime détourné : un site légitime compromis utilisé pour du spam |
| `127.0.1.103` | dbl | Site légitime détourné : un redirecteur utilisé dans du spam |
| `127.0.1.104` | dbl | Site légitime détourné : phishing sur un site piraté |
| `127.0.1.105` | dbl | Site légitime détourné : logiciel malveillant sur un site piraté |
| `127.0.1.106` | dbl | Site légitime détourné : C&C de botnet sur un site piraté |
| `127.0.1.255` | dbl | Erreur : une adresse IP a été interrogée dans la DBL (les requêtes d'adresses IP renvoient toujours « inscrit », pour signaler l'erreur d'usage) |
| `127.0.2.2` – `127.0.2.24` | zrd | Âge du domaine en heures depuis la première observation (2–24 h) |
| `127.0.3.2` | hbl | Adresse email vue dans du spam |
| `127.0.3.10` | hbl | Empreinte de fichier malveillant |
| `127.0.3.15` | hbl | Empreinte de fichier suspect |
| `127.0.3.20` | hbl | Portefeuille de cryptomonnaie vu dans du spam |
| `127.0.3.30` | hbl | URL vue dans du spam |
| `127.255.255.250` | toutes | Erreur : clé DQS désactivée |
| `127.255.255.251` | toutes | Erreur : clé DQS utilisée illégalement |
| `127.255.255.252` | toutes | Erreur : faute de frappe dans le nom de la DNSBL |

Toute réponse dans `127.255.255.0/24` est un **signal d'erreur, pas une inscription**. Traitez-la comme « ne pas bloquer ».

### Conditions d'utilisation

L'utilisation des miroirs DNSBL publics de Spamhaus est gratuite pour les utilisateurs **à faible volume et non commerciaux**, dans le cadre de la politique d'utilisation équitable des DNSBL (DNSBL Fair Use Policy). Les utilisateurs commerciaux et à fort volume doivent passer par le service sur abonnement Data Query Service (DQS). ZEN ne couvre que les adresses IP. Elle n'offre aucune protection contre les domaines malveillants, et c'est le rôle de DBL et de ZRD.

## Pourquoi un expéditeur se retrouve inscrit

Pour un expéditeur légitime, par opposition à un hôte compromis, les inscriptions remontent presque toujours à des problèmes de données, et non de contenu :

- **Adresses pièges touchées** : le signal le plus fort d'une mauvaise acquisition d'adresses ou d'une mauvaise hygiène de base de données (voir la typologie des adresses pièges plus bas).
- **Volumes de plaintes élevés** auprès des serveurs de réception et par les feedback loops.
- **Envoi à des listes achetées, louées, collectées, issues d'un enrichissement de fichiers ou de co-enregistrement.** La position de Spamhaus est alignée sur celle du Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) : « La pratique consistant à vendre, acheter ou envoyer à des listes d'adresses email achetées, qu'il s'agisse de B2B, de B2C ou d'autres catégories, contrevient directement aux valeurs fondamentales du M3AAWG. » (« The practice of selling, buying or sending to lists of purchased email addresses – whether B2B, B2C or other categories, is in direct violation of M3AAWG core values. ») Le consentement n'est pas transférable, donc une liste achetée ne peut jamais porter de consentement.
- **Taux élevés d'utilisateurs inconnus** (rebonds définitifs) : la signature d'une liste périmée ou fabriquée.
- **Des volumes irréguliers, par à-coups**, qui ressemblent à ceux d'un hôte infecté.
- **Une infrastructure compromise** : un formulaire piraté, un relais ouvert, des identifiants SMTP volés (qui mènent à des inscriptions XBL, CSS ou AuthBL).
- **Un envoi direct vers les serveurs MX depuis une plage d'adresses IP dynamique ou résidentielle** (qui mène à une inscription PBL, qui n'est pas une accusation de spam, seulement une déclaration de politique sur cette plage d'adresses IP).
- **Des domaines tout neufs** qui envoient dès leur enregistrement (inscrits dans ZRD pendant les 24 premières heures, ce qui est une raison d'enregistrer vos domaines bien avant leur première utilisation).

## Retrait de liste

Toute vérification et tout retrait passent par l'**IP & Domain Reputation Checker, sur [check.spamhaus.org](https://check.spamhaus.org/)**. Il est gratuit, la vérification ne demande aucun compte, et l'outil détecte et évalue automatiquement l'adresse IP de votre client au chargement de la page. Il indique quel jeu de données vous inscrit et pourquoi, et vous guide dans le diagnostic et le retrait.

Particularités de chaque liste :

- **PBL** : retrait en libre-service pour les utilisateurs finaux qui exploitent légitimement un serveur de messagerie sur l'adresse IP. Vous pouvez aussi faire passer vos messages par le smarthost de votre fournisseur. Les plages désignées par le fournisseur d'accès (`127.0.0.10`) sont des déclarations de politique du propriétaire du réseau.
- **XBL** : libre-service, après avoir assaini l'appareil compromis ou supprimé le logiciel malveillant. Une nouvelle inscription suit rapidement si l'infection persiste.
- **CSS** (`127.0.0.3`) : des inscriptions automatisées qui se résorbent en grande partie d'elles-mêmes. Avant de demander un retrait, vous devez respecter les bonnes pratiques d'envoi de la RFC 5321 et de la RFC 5322 (rDNS valide, HELO concordant, etc.). L'outil de vérification comprend une étape de diagnostic dédiée à CSS.
- **SBL** (`127.0.0.2`) : examen manuel. Le retrait suppose de convaincre un chercheur de Spamhaus que le problème est résolu. Les enquêtes exigent souvent une **preuve de consentement** (voir la collecte des données plus bas), et les fournisseurs d'accès et les fournisseurs de données de réputation peuvent aussi exiger que vous redemandiez l'autorisation à toute votre liste.
- **DBL** : les inscriptions expirent automatiquement une fois que le domaine ne répond plus aux critères d'inscription. Le retrait manuel passe par l'outil de vérification (« utiliser le formulaire ne garantit pas le retrait »). Les retraits approuvés se propagent en quelques minutes, ou jusqu'à 24 heures pour certains miroirs.

**Le retrait de liste est toujours gratuit.** Spamhaus : « Toute offre, d'où qu'elle vienne, de retirer une inscription Spamhaus contre paiement est une escroquerie. »

Les blocages chez les serveurs de réception qui citent Spamhaus (par exemple `554 The IP address of your mail server (…) was found in the Spamhaus blocklist. See https://check.spamhaus.org/`) sont levés selon le calendrier propre au serveur de réception une fois l'inscription retirée, généralement 24–72 heures après la disparition du problème qui les a déclenchés.

## Les recommandations de Spamhaus en matière de délivrabilité (Deliverability 101)

Le livre électronique « Deliverability 101 » de Spamhaus est écrit du point de vue du fournisseur de données de réputation. Son message central rejoint les [fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email) : il n'y a pas de raccourci, donc envoyez régulièrement des emails correctement authentifiés et soigneusement ciblés à un public engagé. Les sections ci-dessous couvrent ce qu'il apporte en plus.

### Ce qui alimente la réputation (dans le modèle de Spamhaus)

La réputation se compose d'un nombre inconnu de variables que les fournisseurs d'accès et les fournisseurs de données de réputation ne dévoilent pas. Les composantes connues sont :

| Composante | Remarques |
|---|---|
| Adresses pièges touchées | Elles démasquent aussi bien les expéditeurs illégitimes que les expéditeurs légitimes dont l'hygiène des données est mauvaise |
| Volumes de plaintes | Les serveurs de réception pondèrent le nombre de plaintes par adresse IP. Les seuils sont secrets et varient selon le fournisseur d'accès, et une bonne réputation vaut un peu plus d'indulgence |
| Indicateurs d'engagement | Clics, ouvertures, achats. Les ouvertures et les clics sont des preuves plus faibles depuis Apple Mail Privacy Protection. Spamhaus lui-même, comme de nombreux équipements antispam, ouvre les spams et suit les liens qui ne sont pas des liens d'inscription, donc une ouverture ou un clic n'est **pas** une preuve de consentement |
| Gestion des rebonds et des adresses invalides | Le taux d'utilisateurs inconnus est une signature majeure des spammeurs |
| Volumes réguliers dans chaque flux d'envoi | Les fournisseurs d'accès se préoccupent davantage du spam de botnet que des emails marketing, et les variations brusques de volume ressemblent à des hôtes infectés. Les flux « par à-coups » dégradent même une réputation bien établie chez les grands fournisseurs de messagerie gratuite |

Il existe une asymétrie fondamentale, voulue et sans exception : **il est bien plus facile de faire chuter une réputation que de la réparer.** La réputation des adresses IP est aussi devenue moins centrale que celle des domaines et du contenu. Avec les 340 sextillions d'adresses d'IPv6, les criminels grillent des adresses IP sans compter, donc les filtres s'appuient sur les domaines. Le placement en boîte de réception est recalculé exceptionnellement vite en fonction des réactions des utilisateurs finaux, et le traitement peut changer d'un instant à l'autre. La mise en liste blanche (autrefois « whitelisting ») par les fournisseurs d'accès n'existe plus.

### Paraître légitime : liste de contrôle de configuration

Les intentions comptent bien moins que le comportement. Les filtres anti-spam ne peuvent pas distinguer un expéditeur bien intentionné d'un spammeur si les bases du comportement manquent :

- Authentifiez tout, avec au minimum SPF et DKIM. Gardez l'enregistrement SPF **aussi restreint que possible**, car autoriser l'Internet entier comme expéditeur invite aux abus. Voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) pour les règles d'alignement.
- **Stratégie de domaine pour les clients d'un fournisseur de services de messagerie (ESP)**, de la meilleure à la pire : (1) déléguer un sous-domaine du domaine principal de la marque, par exemple `email.customerbrand.com` ; (2) `customerbrand.espdomain.com` ; (3) en dernier recours, un domaine sosie comme `customerbrand-email.com`. Si un domaine sosie est inévitable, il doit clairement se rattacher à la marque, car le phishing a rendu les utilisateurs méfiants envers les domaines ressemblants.
- N'utilisez pas d'enregistrements WHOIS anonymisés sur les domaines d'envoi. Une entreprise légitime n'a aucune raison de cacher son identité, et les bureaux d'enregistrement qui ont activé la confidentialité par défaut après le RGPD lèvent généralement l'anonymat d'un enregistrement sur demande.
- Limitez le nombre de domaines d'envoi distincts, car plus il y a de domaines uniques qui envoient le même message, plus les alertes se multiplient. Utilisez le domaine principal de l'entreprise ou ses sous-domaines.
- Chaque domaine qui envoie des emails doit disposer d'adresses `abuse@` et `postmaster@` fonctionnelles et d'un site web actif. Les domaines de liens et de suivi doivent rediriger vers le site principal de l'entreprise.
- Utilisez si possible des adresses IP contiguës sur le même réseau, et n'utilisez pas plus d'adresses IP que nécessaire. Des centaines d'adresses IP dispersées sur plusieurs réseaux, c'est la définition même du snowshoeing (voir [Attribution des adresses IP : les bases](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip)).
- Les ESP devraient publier une politique d'utilisation acceptable (AUP) et des conditions d'utilisation (ToS) faciles à trouver et appliquées, et surveiller les journaux SMTP pour repérer les rebonds inattendus, les échecs temporaires (tempfails) et les anomalies des flux d'envoi.
- La réputation s'établit pendant la chauffe, alors planifiez-la. Choisissez des destinataires très engagés pour les premiers envois, et augmentez le volume en fonction des résultats de chaque envoi précédent (voir [Chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip)).

### Acquisition d'adresses et preuves de consentement

Pour chaque contact, enregistrez les éléments suivants, et tenez l'enregistrement à jour :

- La date et l'heure d'inscription, **en UTC**
- Le canal par lequel l'adresse a été obtenue
- L'adresse IP qui l'a soumise

Si une adresse IP ou un domaine est inscrit sur une liste de blocage et qu'une intervention manuelle est nécessaire, les fournisseurs d'accès et les fournisseurs de données de réputation **exigent souvent cette preuve de consentement**. Sans elle, la résolution prend plus de temps ou échoue. Ces enregistrements vous protègent aussi contre les plaintes fondées sur le RGPD et sur des lois similaires.

Règles pour les formulaires : les cases d'opt-in doivent être cochées volontairement (les cases précochées sont malhonnêtes, et illégales dans certains pays). Protégez les formulaires par CAPTCHA ou reCAPTCHA. Depuis août 2016 environ, les abus de formulaires d'inscription non sécurisés par des robots ne cessent de croître. Ils empoisonnent les bases de données (y compris par la soumission malveillante d'adresses pièges) et équivalent à une attaque par déni de service (DoS).

Méthodes d'acquisition, classées :

| Méthode | Verdict |
|---|---|
| Double opt-in (opt-in confirmé, COI) | La référence. Un email de confirmation contient un lien à cliquer pour confirmer, et sans clic aucun email marketing n'est envoyé. Il fournit un consentement démontrable, un risque d'adresses pièges quasi nul et un meilleur engagement |
| Simple opt-in | Praticable mais risqué : intention incertaine, soumissions avec fautes de frappe, par des robots ou d'adresses jetables, empoisonnement par des adresses pièges, taux de plaintes plus élevés, et inscription possible sur des listes de blocage |
| Opt-out | À éviter absolument. Il garantit des rebonds nombreux, des plaintes, des adresses pièges touchées, des blocages par les fournisseurs d'accès et des inscriptions sur des listes de blocage. L'autorisation ne s'acquiert pas après coup |
| Listes achetées ou louées, collecte d'adresses, enrichissement de fichiers (appending, e-pending), listes de co-enregistrement ou de partenaires | Jamais. Le consentement n'est pas transférable, et les dégâts sont graves et durables |

### Fréquence, engagement et politique de mise en sommeil (sunset policy)

Annoncez la fréquence d'envoi dans le message de confirmation ou de bienvenue, et tenez-vous-y. Des emails inattendus ou irréguliers provoquent des signalements de spam. Spamhaus donne cet exemple d'échelle de mise en sommeil :

1. Le destinataire n'a rien ouvert depuis **plus de 1 semaine** : passez-le d'un envoi hebdomadaire à un envoi mensuel.
2. Il n'a rien ouvert depuis **plus de 1 mois** : envoyez un message « souhaitez-vous poursuivre votre abonnement ? » avec un lien de confirmation.
3. Pas de réponse : ajoutez l'adresse à la liste de suppression et arrêtez.

Examinez l'engagement en continu, et écartez par segmentation les destinataires qui n'interagissent pas. Le seuil de départ habituel est d'un an d'inactivité, resserré ensuite à six mois puis à trois, selon les résultats. Envoyer en masse à des adresses qui n'ont jamais consenti, c'est du spam, et continuer d'envoyer à des adresses auxquelles aucun message n'a jamais pu être livré aussi.

L'idée que les fournisseurs d'accès et les fournisseurs de données de réputation « durcissent les règles » pendant les fêtes de fin d'année est un mythe : rien ne change côté réception. Les expéditeurs qui puisent dans de vieux segments ou des segments inactifs (ou qui achètent des listes) pour le chiffre d'affaires des fêtes provoquent eux-mêmes le déclin de leur réputation, avec des échecs temporaires, des reports de remise, des blocages et parfois des inscriptions chez Spamhaus.

### Gestion des rebonds

**Rebond définitif** : un échec permanent (5xx) qui n'est pas retenté. Si vous en recevez un, n'envoyez plus jamais à ce contact : supprimez-le ou placez-le en liste de suppression. Codes que les expéditeurs voient souvent :

| Code | Signification |
|---|---|
| 550 | Adresse email inexistante (la grande majorité des 550 signifient « utilisateur inconnu ») |
| 512 | Erreur DNS : le domaine du destinataire n'existe pas dans le DNS |
| 551 | Utilisateur non local, ou adresse invalide : relais refusé |
| 552 | Espace de stockage alloué dépassé (boîte pleine, que certains serveurs traitent comme permanente) |
| 553 | Nom de boîte aux lettres invalide (adresse de destinataire mal formée) |

Dans le marketing, la plupart des rebonds définitifs résultent directement d'une mauvaise hygiène des données. Notez que des domaines inexistants peuvent devenir plus tard des adresses pièges.

**Rebond temporaire** : un échec passager (4xx) qui est retenté. Le système d'envoi réessaie jusqu'à ce que le message soit accepté ou que le délai expire. Ce délai est fixé côté expéditeur et varie selon les réseaux :

| Code | Signification |
|---|---|
| 421 | Service indisponible ou problème de connexion : trop de connexions simultanées, manque de ressources chez le serveur de réception, ou baisse de réputation |
| 450 | Boîte aux lettres indisponible : boîte corrompue ou hors ligne, ou refus pour cause de réputation ou d'inscription sur une liste de blocage |
| 451 | Erreur locale de traitement |
| 452 | Trop d'emails ou de destinataires, ou limite de stockage du serveur dépassée |

Certains fournisseurs d'accès réagissent à une baisse de réputation par des **échecs temporaires** (tempfails) (« 421 4.7.0 [TS01] Messages from x.x.x.x temporarily deferred due to user complaints »). Les messages sont reportés jusqu'à ce que le flux s'arrête ou que la réputation se rétablisse. Ne retirez pas automatiquement de la liste les adresses touchées par un échec temporaire. Corrigez plutôt le problème de qualité de la liste.

**Blocage définitif par un fournisseur d'accès** (hard block) : un rejet par la politique du serveur de réception qui vise tout le flux, généralement `554`, souvent avec une URL à consulter (par exemple une référence Spamhaus). Les causes sont un blocage d'URL ou du contenu du corps, une authentification absente, une mauvaise réputation de l'adresse IP ou du domaine, ou la présence sur une liste de blocage utilisée par le serveur de réception. Les blocages sont en général levés au bout d'un délai arbitraire de 24–72 heures une fois le déclencheur disparu. Sinon, réglez d'abord la cause profonde, puis ouvrez un ticket auprès du réseau qui bloque. **Certains fournisseurs d'accès, notamment Gmail, n'offrent aucun canal de correction.** Les serveurs de réception montent généralement en puissance dans cet ordre : classement dans le dossier spam, puis échecs temporaires et limitation de débit, puis rebonds, puis blocages définitifs.

### Plaintes et feedback loops

Certaines causes de plaintes sont sous votre contrôle : pas de véritable inscription, des attentes sur la fréquence ou le contenu qui n'ont jamais été fixées, trop d'emails ou un changement brutal de fréquence, des listes achetées, un contenu non pertinent, et des envois après un désabonnement. Retirez une adresse immédiatement lorsqu'elle se désabonne, quel que soit le délai de grâce que la loi applicable autorise. D'autres causes sont plus difficiles à maîtriser : les destinataires qui ne se souviennent tout simplement pas de s'être inscrits (écrivez-leur rapidement après l'inscription, car un premier email reçu des semaines plus tard est oublié), les fautes de frappe dans les adresses collectées en point de vente, et les utilisateurs excédés qui signalent toute leur boîte de réception comme spam.

Réduisez les plaintes en tenant la promesse faite lors de l'opt-in, en proposant un centre de préférences avec des options de fréquence, en ne précochant jamais de cases, en n'achetant jamais de listes et en rendant le désabonnement très simple. N'exigez jamais de connexion pour se désabonner, ce qui est illégal dans certains pays, et placez le lien là où on le trouve plus vite que le bouton spam, par exemple en haut du message.

Les sources de données de surveillance sont SNDS d'Outlook et de Hotmail (volume de messages, reports de remise, taux de plaintes et adresses pièges touchées, par adresse IP), Google Postmaster Tools (volumes de plaintes et réputation des domaines), et toutes les **feedback loops (FBL)** disponibles. Par une FBL, les fournisseurs d'accès renvoient les plaintes de spam de leurs utilisateurs au réseau d'origine au format ARF (Abuse Reporting Format), avec les données personnelles (PII) masquées. Traitez les signalements rapidement, et placez immédiatement les plaignants en liste de suppression.

### Typologie des adresses pièges

Les adresses pièges prouvent un problème de collecte ou d'hygiène des données, donc corrigez le processus, pas le piège. Leurs propriétaires ne révèlent jamais leurs adresses pièges. Elles font partie du secret du filtrage, et les acteurs malveillants qui identifient des pièges se contentent de les supprimer de leurs listes sans rien corriger. Les types sont :

| Type | Ce que c'est | Ce que le fait de le toucher prouve |
|---|---|---|
| Classique ou piège vierge | Une adresse jamais attribuée à un utilisateur réel (souvent sur des domaines « fourre-tout », `*@example.com`) qui se met à recevoir des messages | Une liste fabriquée ou générée |
| Semée | Des adresses dispersées délibérément à des endroits où personne ne regarde (par exemple dans le code source d'une page web) | Du scraping ou de la collecte d'adresses, ou un achat auprès de quelqu'un qui en fait. Elle repère aussi le non-respect des désabonnements |
| Domaine à faute de frappe | Des pièges sur des domaines comme `yaaho.com`, `ynail.com`, `homail.com` | Des fautes de frappe à la saisie. Ces domaines reçoivent aussi de vrais messages, et sont pondérés en conséquence. Le double opt-in à la collecte évite ces pièges |
| Adresse morte (piège recyclé) | Des adresses autrefois valides qu'un fournisseur d'accès a désactivées, qui ont renvoyé des rebonds définitifs pendant un temps (souvent 12+ mois), puis ont été réactivées discrètement comme pièges | Des rebonds définitifs ignorés, ou des listes périmées |
| Vivante | Des adresses d'utilisateurs réels dont les messages non sollicités servent aux décisions de blocage | L'envoi de messages non sollicités. Dangereux quand le propriétaire a des relations dans le milieu |
| Enregistrement de domaine ou adresses de rôle (un sous-ensemble des pièges vivants) | `postmaster@`, `abuse@`, `admin@` et les adresses publiées dans le WHOIS | La collecte d'adresses. Ces adresses ne devraient presque jamais figurer sur une liste marketing |

### Contexte juridique (consultez un juriste ; il existe des lois sur l'email et la protection des données dans au moins 77 pays)

- **CAN-SPAM (États-Unis)** : loi fédérale. La Federal Trade Commission (FTC) a poursuivi des contrevenants avec succès.
- **LCAP (CASL, Canada)** : s'applique si le message est adressé à un domaine canadien ou à un utilisateur canadien, ou s'il transite par le Canada.
- **RGPD (UE, en vigueur depuis le 2018-05-25)** : couvre les résidents de l'UE et de l'EEE, ainsi que les transferts de données hors de ces zones. Les amendes sont lourdes, et les preuves de consentement réduisent sensiblement l'exposition.
- **CCPA (Californie, en vigueur depuis le 2020-01-01)** : droit de savoir, droit à l'effacement, droit de s'opposer à la vente des données et droit à la non-discrimination. Les moins de 16 ans doivent donner leur consentement par opt-in, et les moins de 13 ans ont besoin du consentement de leurs parents.

# Outils de test et de diagnostic de la délivrabilité

> Un catalogue pratique d'outils de diagnostic gratuits (aboutmy.email, mail-tester, learndmarc, internet.nl, Google CheckMX, MXToolbox Email Health, check.spamhaus.org) : ce que chacun teste, ce qu'il demande en entrée et sa place dans un processus de travail.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/outils-de-test-et-de-diagnostic-de-la-delivrabilite

Quand vous mettez en place une nouvelle configuration d'envoi, ou qu'un problème de livraison apparaît, des outils interactifs gratuits peuvent vérifier la configuration et aider à diagnostiquer le problème. Ils se répartissent en deux familles :

- **Les outils fondés sur un message** : vous envoyez un vrai email à une adresse générée, et l'outil analyse ce qui est réellement arrivé. Exemples : aboutmy.email, mail-tester.com et learndmarc.com. Ils testent tout le trajet réel : l'adresse IP qui s'est réellement connectée, la signature DKIM réellement appliquée, et les en-têtes que votre plateforme produit réellement.
- **Les outils fondés sur le domaine et le DNS** : vous saisissez un domaine ou une adresse IP, et l'outil examine de l'extérieur les enregistrements publiés et le comportement des serveurs. Exemples : internet.nl, Google CheckMX, MXToolbox Email Health et check.spamhaus.org. Ils testent la configuration, et non un message précis.

Utilisez les deux. Les outils fondés sur le DNS confirment que les enregistrements sont corrects. Les outils fondés sur un message confirment que le courrier qu'envoie réellement votre infrastructure s'authentifie et est aligné.

## Référence rapide

| Outil | Entrée | Question principale à laquelle il répond |
|---|---|---|
| [aboutmy.email](https://aboutmy.email/) | Envoi d'un email à une adresse générée | Ce message s'authentifie-t-il, est-il aligné, et respecte-t-il les exigences de Gmail et de Yahoo envers les expéditeurs de gros volumes ? (30+ contrôles) |
| [mail-tester.com](https://www.mail-tester.com/) | Envoi d'un email à une adresse générée | Quel score une installation SpamAssassin standard, avec des contrôles d'authentification et de listes de blocage, donne-t-elle à ce message ? (0–10) |
| [learndmarc.com](https://www.learndmarc.com/) | Envoi d'un email à une adresse générée, ou collage des en-têtes | Pas à pas : pourquoi SPF, DKIM et DMARC réussissent-ils ou échouent-ils pour ce message ? |
| [internet.nl/test-mail](https://internet.nl/test-mail/) | Nom de domaine | Ce domaine de messagerie respecte-t-il les normes ouvertes modernes (IPv6, DNSSEC, SPF, DKIM, DMARC, STARTTLS, DANE, RPKI) ? |
| [Google CheckMX](https://toolbox.googleapps.com/apps/checkmx/) | Domaine, avec un sélecteur DKIM facultatif | Les enregistrements MX, SPF, DKIM et DMARC sont-ils corrects, tels que les voient les résolveurs de Google lui-même ? |
| [MXToolbox Email Health](https://mxtoolbox.com/emailhealth/) | Domaine ou adresse email | Un bilan de santé large : 100+ listes de blocage, des tests MX, SMTP et DNS, et des résultats regroupés en problèmes, avertissements et réussites |
| [check.spamhaus.org](https://check.spamhaus.org/) | Adresse IP, domaine ou empreinte | Est-ce inscrit sur une liste de blocage Spamhaus, pourquoi, et comment obtenir le retrait de liste ? |

## Outils fondés sur un message

### aboutmy.email (Word to the Wise)

Conçu par Steve Atkins, de Word to the Wise. Gardez la page ouverte (sans la quitter ni l'actualiser) et envoyez un email à l'adresse à usage unique qu'elle affiche. Idéalement, envoyez un vrai message de campagne depuis la vraie plateforme d'envoi. Vous obtenez un rapport détaillé qui analyse « l'authentification, la taille, la structure et le degré de conformité aux meilleures pratiques ». L'outil est gratuit.

Ce qu'il contrôle (30+ contrôles) :

- **L'authentification, en profondeur** : pas seulement la réussite ou l'échec de SPF, mais la requête DNS effectivement réalisée, les enregistrements trouvés, l'adresse IP vérifiée et le résultat. De même pour DKIM, avec le sélecteur, la clé publique et la vérification de la signature, et pour DMARC, avec l'alignement. BIMI est contrôlé s'il est configuré.
- **La conformité** : une section dédiée qui vérifie le message au regard des exigences de Gmail et de Yahoo envers les expéditeurs de gros volumes (désabonnement en un clic avec List-Unsubscribe, authentification, alignement, etc.).
- **Les en-têtes et le contenu** : l'analyse de la structure MIME, et des avertissements sur les en-têtes.
- **Les images** : chaque image du message, listée par hôte, avec la taille de son fichier, ses dimensions natives et affichées, et des avertissements quand de grandes images sont réduites dans le client de messagerie.

Lisez un rapport dans cet ordre : d'abord **Authentication** (corrigez tout ce qui y apparaît en rouge avant le reste), puis **Compliance** (les exigences de Gmail et de Yahoo ne sont pas des suggestions), puis les avertissements sur les en-têtes et le contenu, puis la liste de contrôle « Good Practice ».

**Quand l'utiliser** : c'est la meilleure vérification unique avant un lancement et après une modification d'une plateforme d'envoi. Utilisez-le pour une nouvelle adresse IP, un nouveau domaine ou un nouvel ESP, après un changement de clés DKIM ou de domaine From, ou pour confirmer la conformité aux exigences de [Gmail](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs) et de [Yahoo](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs) envers les expéditeurs.

### mail-tester.com

Créé par des personnes liées à Mailpoet et AcyMailing, c'est le testeur classique qui donne une « note sur 10 ». La page génère une adresse aléatoire (du type `xyz…@srv1.mail-tester.com`). Envoyez-y votre message et cliquez sur « Then check your score ».

Ce qu'il contrôle :

- **SpamAssassin** : une installation SpamAssassin non modifiée note le message. mail-tester inverse le signe pour qu'un score plus élevé soit meilleur, avec 10/10 pour objectif.
- **L'authentification** : l'évaluation SPF, DKIM et DMARC du message reçu.
- **Les listes de blocage** : l'adresse IP et le domaine d'envoi, vérifiés auprès des principales DNSBL.
- **La qualité du contenu** : les liens cassés, le rapport entre images et texte, le poids et les problèmes de validité du HTML, et la présence d'un mécanisme de désabonnement.

Il est gratuit par l'interface web, avec une limite quotidienne de vérifications gratuites. Les offres payantes et l'API lèvent la limite. Les pages de résultats restent accessibles à leur URL pendant un certain temps, ce qui vous permet de les partager avec un hébergeur ou un ESP.

**Mises en garde** : le score n'est qu'une approximation. Une installation SpamAssassin standard est bien plus simple que le filtrage de Gmail ou d'Outlook, et un 10/10 ne garantit pas le placement en boîte de réception, car la réputation et l'engagement priment (voir [Fondamentaux](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)). Tout ce qu'il signale mérite d'être corrigé, mais ne faites pas du score un objectif.

**Quand l'utiliser** : une vérification rapide d'une combinaison de modèle et d'infrastructure, et une première étape pratique quand un client signale que ses messages arrivent en spam.

### learndmarc.com (URIports)

Un outil visuel d'apprentissage et de diagnostic, parrainé par URIports. Envoyez un email à l'adresse générée sur son serveur (`neo.learndmarc.com`), et il rejoue le processus de validation à l'écran, étape par étape, en temps réel :

1. **Connexion** : l'adresse IP source, le nom d'hôte issu du DNS inverse, et l'expéditeur d'enveloppe.
2. **SPF** : la requête sur le domaine `MAIL FROM`, sa réussite ou non, et l'alignement de SPF avec le domaine From:.
3. **DKIM** : chaque signature trouvée, avec son sélecteur, son algorithme et le résultat de sa vérification, et l'alignement de DKIM.
4. **DMARC** : la façon dont les résultats SPF et DKIM et leur alignement se combinent pour donner le verdict DMARC final selon la politique publiée par le domaine.

Il propose aussi un analyseur d'en-têtes (collez la source brute du message au lieu de l'envoyer), un quiz de 10 questions avec explications, et des résultats que vous pouvez partager, anonymiser ou imprimer. Il fonctionne mieux sur un ordinateur.

**Quand l'utiliser** : c'est l'outil le plus clair pour comprendre et expliquer un échec d'authentification. Il est idéal quand SPF réussit mais que DMARC échoue (un problème d'alignement), pour déboguer des échecs causés par le transfert, ou pour expliquer à un client ce que signifie l'alignement [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc). Il ne teste que l'authentification, sans aucun contrôle du contenu, des listes de blocage ou du placement.

## Outils fondés sur le domaine et le DNS

### Test de messagerie d'internet.nl

Géré par la Dutch Internet Standards Platform, « une initiative de la communauté Internet et du gouvernement néerlandais ». Vous saisissez le nom de domaine d'un service de messagerie. Il teste l'adoption des normes ouvertes modernes. Plusieurs d'entre elles comptent même pour les domaines **sans** service de messagerie, par exemple la publication d'un enregistrement MX nul, de SPF et de DMARC sur les domaines qui n'envoient pas de courrier :

- **IPv6** : la joignabilité des serveurs de noms et des serveurs de messagerie
- **DNSSEC** : la signature et la validation du domaine et des domaines MX
- **Authentification** : la présence des enregistrements DMARC, DKIM et SPF, leur syntaxe, et la sévérité de la politique (il signale les politiques laxistes comme `p=none` ou `~all`)
- **Sécurité du transport** : la qualité de la configuration STARTTLS, et **DANE** (enregistrements TLSA liés aux certificats MX)
- **RPKI** : l'autorisation d'origine de route pour les adresses IP des serveurs de messagerie

Le résultat est un score global en pourcentage, avec des résultats pour chaque section et chaque sous-test, un lien permanent que vous pouvez partager (utile à transmettre à un hébergeur), et un widget que vous pouvez intégrer.

**Mises en garde** : il mesure l'adoption des normes, et non la délivrabilité en tant que telle. DNSSEC, DANE et RPKI sont d'excellentes pratiques d'hygiène, de plus en plus attendues en Europe (et par certains gouvernements), mais le placement chez Gmail ou Outlook ne les exige pas. Un score modeste peut aller de pair avec un placement parfait en boîte de réception, donc lisez le détail de chaque section, et non le chiffre global.

**Quand l'utiliser** : les audits d'infrastructure, les revues de sécurité et de conformité, et la vérification de STARTTLS et de DANE après un changement de MX ou de certificat.

### Google Admin Toolbox CheckMX

Le vérificateur DNS gratuit de Google, à l'adresse `toolbox.googleapps.com/apps/checkmx/`. Vous saisissez un nom de domaine, et éventuellement un **sélecteur DKIM**. Il est destiné aux administrateurs Google Workspace, mais fonctionne pour n'importe quel domaine. Il récupère et vérifie les enregistrements MX, SPF, DKIM (pour le sélecteur indiqué) et DMARC tels que les voient les résolveurs de Google, et signale les problèmes DNS courants : enregistrements absents ou en double, trop de requêtes DNS SPF, erreurs de syntaxe et priorités mal configurées.

**Quand l'utiliser** : un second avis rapide sur les enregistrements DNS. Il est particulièrement précieux parce qu'il montre comment Google voit vos enregistrements, et Google est le serveur de réception qui compte le plus pour beaucoup d'expéditeurs. C'est une bonne première vérification quand c'est précisément Gmail qui rejette le courrier ou le classe en spam.

### MXToolbox Email Health

Un rapport de santé agrégé, à l'adresse `mxtoolbox.com/emailhealth/`. Vous saisissez un domaine ou une adresse email. Il lance « des centaines de tests de performance du domaine, de l'email et du réseau », regroupés en cinq sections (listes de blocage, serveur de messagerie, serveur web, DNS, et une synthèse des problèmes). Chaque section affiche **Errors, Warnings et Passed** :

- **Listes de blocage** : le domaine et les adresses IP de ses serveurs de messagerie, vérifiés auprès de **100+ DNSBL** (listes d'adresses IP comme de domaines)
- **Serveurs de messagerie** : chaque enregistrement MX sondé pour la connectivité SMTP, les contrôles de bannière et d'accueil, un test de relais ouvert, la concordance du DNS inverse (PTR), la prise en charge de TLS, et la durée de la transaction
- **DNS** : 15+ tests sur les serveurs de noms faisant autorité (cohérence du SOA, joignabilité des NS, etc.), plus des contrôles des enregistrements SPF et DMARC

Les utilisateurs gratuits ont droit à **un Email Health Check toutes les 24 heures**. Les offres payantes ajoutent des vérifications illimitées, et une surveillance qui relance 30+ tests toutes les quelques minutes, avec des alertes. Les recherches MXToolbox individuelles (une seule vérification de liste de blocage, `spf:`, `dmarc:`, `smtp:`, etc.) restent gratuites et illimitées pour un usage occasionnel.

**Mises en garde** : avec 100+ listes de blocage vérifiées, attendez-vous à du bruit, car beaucoup des listes contrôlées n'ont presque aucun effet en pratique. Pondérez une inscription selon la portée de la liste (Spamhaus compte bien plus que des listes confidentielles), comme l'explique [Listes de blocage et Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus).

**Quand l'utiliser** : une première vérification large lors d'incidents du type « nos emails rebondissent soudain partout », et des bilans de santé périodiques des domaines d'envoi et des hôtes MX.

### check.spamhaus.org (IP & Domain Reputation Checker)

L'outil de vérification officiel et gratuit de Spamhaus, et le seul moyen faisant autorité de vérifier et de résoudre les inscriptions Spamhaus, car les recherches dans les zones Spamhaus par des tiers peuvent être obsolètes ou bloquées. Vous saisissez une adresse IP, un domaine ou une empreinte. Il détecte aussi l'adresse IP de votre propre client au chargement de la page, et vous avertit immédiatement si cette adresse est inscrite. Vous n'avez pas besoin de compte pour vérifier. La procédure de retrait de liste comporte des étapes de vérification.

Pour une ressource inscrite, il indique quel jeu de données l'inscrit (SBL, CSS, XBL, PBL, DBL…), **pourquoi** elle a été inscrite, ce qu'il faut corriger pour que l'inscription ne se reproduise pas, et une demande de retrait guidée. Les inscriptions CSS ont une étape de dépannage dédiée qui exige des pratiques d'envoi conformes aux RFC 5321 et 5322 avant le retrait. Le retrait est toujours gratuit, et les « services de retrait de liste » payants sont des escroqueries.

**Quand l'utiliser** : immédiatement après tout rebond qui mentionne Spamhaus (par exemple `554 … found in the Spamhaus blocklist. See https://check.spamhaus.org/`), et de façon proactive quand vous mettez en service de nouvelles adresses IP (pour trouver les inscriptions laissées par les utilisateurs précédents, et le statut PBL de la plage). Pour le détail complet des zones et des codes de retour, voir [Listes de blocage et Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus).

## La place de chaque outil dans un processus de délivrabilité

| Étape | Outils |
|---|---|
| **Mise en service de nouvelles adresses IP ou de nouveaux domaines** | D'abord check.spamhaus.org (inscriptions héritées, statut PBL), puis Google CheckMX et internet.nl (enregistrements et normes corrects), puis aboutmy.email (un message réel s'authentifie et est aligné). Faites tout cela avant le début de la [chauffe](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip) |
| **Avant le lancement d'une campagne ou d'un modèle** | mail-tester.com (le contenu, et le score d'un filtre standard), aboutmy.email (la conformité et le poids du message rendu) |
| **Modification de l'authentification (nouvelle clé DKIM, modification SPF, changement de politique DMARC)** | learndmarc.com et aboutmy.email, pour confirmer à la fois la réussite et l'alignement. Google CheckMX pour la syntaxe des enregistrements |
| **Rebonds soudains ou incident de blocage** | Lisez d'abord la réponse SMTP. Puis check.spamhaus.org si Spamhaus est mentionné, MXToolbox Email Health pour une vérification large, et learndmarc.com si le rejet mentionne l'authentification |
| **Audit périodique** | MXToolbox Email Health (dans la limite gratuite de 1 vérification toutes les 24h) et internet.nl. Relancez aboutmy.email après toute modification de la plateforme |

Aucun de ces outils ne mesure si le courrier arrive réellement en boîte de réception ou dans le dossier spam chez les vrais fournisseurs de messagerie, ni votre réputation chez eux. Pour cela, utilisez les données des serveurs de réception, comme Google Postmaster Tools, Microsoft SNDS et les feedback loops, avec vos propres indicateurs d'engagement (voir [Fondamentaux](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)).

# Position du M3AAWG sur l'email froid (novembre 2025)

> La position de consensus du secteur : l'envoi trompeur d'emails froids non sollicités est une pratique abusive. Définition complète, liste des tactiques trompeuses, indicateurs de détection et non-transférabilité du consentement.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/position-du-m3aawg-sur-l-email-froid

Si un client soutient que sa prospection à froid relève de la vente et non du spam, la réponse du secteur est claire : envoyer des emails non sollicités avec des méthodes de livraison trompeuses est un abus. Le Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), dont les membres comprennent les grands fournisseurs de messagerie, a exposé cette position dans une déclaration d'une page.

Cette déclaration est la *M3AAWG Position on Cold Email*, de novembre 2025, version 1.0 (M3AAWG-154 ; URL de référence m3aawg.org/M3AAWGPositionOnColdEmail). C'est la position explicite du secteur sur la « prospection à froid » (cold outreach), et elle porte sur **les pratiques trompeuses utilisées pour diffuser des emails froids qui imitent ou semblent être des communications individuelles, mais qui sont en réalité considérés comme du spam.**

## Définition

> En termes de marketing par email, un « email froid » (Cold Email) est un email non sollicité, envoyé par des expéditeurs par ailleurs légitimes et identifiables, qui cherche à créer une relation d'affaires, une vente, une opportunité commerciale ou un autre avantage professionnel auprès d'un **destinataire qui n'a aucune relation, aucun lien ni aucun consentement préalable avec l'expéditeur ou l'entreprise**.

Notez que les expéditeurs sont décrits comme « par ailleurs légitimes et identifiables ». La position ne vise pas les opérations de spam criminelles. Ce qui définit l'email froid, c'est l'absence de toute relation, de tout lien ou de tout consentement préalable.

## Les tactiques trompeuses visées

Pour paraître personnellement liés au destinataire et ressembler à des messages individuels, les emails froids envoyés en masse utilisent souvent :

- l'authentification (SPF, DKIM et DMARC, techniquement conforme mais utilisée comme camouflage) ;
- des liens d'opt-out ;
- la personnalisation (prénom, fonction, nom de l'entreprise, etc.) ;
- d'autres contenus générés par IA.

Les méthodes de livraison trompeuses, utilisées pour échapper à la détection des filtres antispam :

- l'envoi à intervalles aléatoires ;
- les **domaines sosies**, qui ressemblent à des domaines légitimes mais n'ont en réalité aucun rapport avec eux (exemple du M3AAWG : `paypal-security.com` pour `paypal.com`) ;
- les comptes d'envoi multiples.

> **La pratique consistant à utiliser ou à faciliter des méthodes de livraison trompeuses pour masquer l'envoi d'emails froids est en contradiction directe avec les valeurs fondamentales du M3AAWG.**

## Indicateurs de détection

Les indicateurs de réputation qui signalent qu'un expéditeur envoie des emails froids comprennent notamment :

| Indicateur | Pour aller plus loin |
|---|---|
| Détection par des adresses pièges | [Adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges) · [Réponse aux incidents d'adresses pièges](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response) |
| Inscription sur des listes de blocage | [Listes de blocage et Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus) |
| Nombreux rebonds définitifs pour utilisateur inconnu | [DSN](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison) |
| Taux de plaintes élevés | [Feedback loops de plaintes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes) |

## Pratiques particulièrement graves

Toute tentative de faire ce qui suit « est particulièrement grave et n'est acceptable en aucune manière » :

- contourner les limites de volume d'envoi ;
- échapper aux filtres antispam ;
- masquer les domaines d'envoi ;
- **simuler artificiellement l'engagement des abonnés** (par exemple avec des outils qui simulent une chauffe ou un engagement) ;
- utiliser d'autres outils ou services qui exploitent des failles chez les fournisseurs de messagerie ou les plateformes cloud.

## Le consentement n'est pas transférable d'un canal à l'autre

La position du M3AAWG est que **la forme précise de consentement obtenue pour faire du marketing auprès d'une personne n'est pas transférable d'un canal marketing à un autre**. Son exemple : le consentement à être contacté ou sollicité par téléphone ne donne pas à l'entreprise le consentement de contacter cette personne par email froid.

## La position

> **La position du M3AAWG est que l'utilisation de méthodes de livraison trompeuses et fallacieuses pour envoyer des emails non sollicités (y compris des emails froids) est une pratique abusive.**

Les *Sender Best Common Practices* du M3AAWG (version 4.0, août 2026, section 4.5) résument cette position en un paragraphe, dont la formulation est plus large que celle de la prise de position. Ce résumé indique que le M3AAWG considère l'email froid lui-même comme abusif, sans la réserve sur les méthodes de livraison trompeuses ou fallacieuses. Il renvoie ensuite à la Position on Cold Email pour le détail complet. Si vous lisez les deux, la prise de position est le document auquel renvoie le résumé.

## Ce que cela signifie pour un ESP

- L'email froid peut être légal dans certaines juridictions (par exemple sous le régime d'opt-out de CAN-SPAM ; voir [CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis)). Mais l'organisation professionnelle qui réunit les grands fournisseurs de messagerie classe l'email froid livré de façon trompeuse comme un **abus**, et non comme du marketing. Être légal ne rend pas un courrier délivrable ni acceptable.
- La liste des indicateurs de détection sert aussi de liste de contrôle pour le contrôle et la surveillance des clients. Des adresses pièges touchées, des inscriptions sur des listes de blocage, des rebonds pour utilisateur inconnu et des plaintes, réunis sur le flux d'un même client, forment l'empreinte de l'email froid.
- Les clients qui font tourner leurs domaines, utilisent des domaines sosies, exploitent des fermes de comptes de messagerie, rendent leur calendrier d'envoi aléatoire ou utilisent des services qui simulent l'engagement (services de « warm-up ») relèvent de la clause « particulièrement grave ».
- La position **s'ajoute à et englobe** toutes les autres recommandations de meilleures pratiques du M3AAWG. Elle s'appuie explicitement sur la *M3AAWG Position on Selling Email Address Lists* (m3aawg.org/SellingEmailLists) et la *M3AAWG Position on Email Appending* (m3aawg.org/AppendingPosition). La vente de listes et l'enrichissement de fichiers étaient déjà condamnés, et cette position applique la même approche à la façon dont la prospection à froid est livrée.

## Voir aussi

- [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement)
- [Les deux mondes de la délivrabilité email](https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email)
- [Meilleures pratiques M3AAWG pour les expéditeurs](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs)

# Programmes de certification des expéditeurs : Validity Certification et la CSA

> Les deux programmes commerciaux de liste blanche encore en activité, Validity Sender Certification et la Certified Senders Alliance : critères d'admission exacts, seuils de performance, structure des coûts, serveurs de réception qui reconnaissent chacun, et une évaluation honnête des cas où la certification est rentable.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/programmes-de-certification-des-expediteurs

Si vous envisagez de payer une certification d'expéditeur, son utilité dépend des fournisseurs de messagerie que vous devez atteindre et du fait que vous envoyez en tant que marque ou en tant que plateforme. La mise en liste blanche formelle par des tiers relève [largement du passé](https://emailmarketing.net/fr/apprendre/reference/glossaire), mais deux programmes commerciaux subsistent avec un vrai soutien des serveurs de réception.

**Validity Sender Certification** est l'ancienne Return Path Certification. C'est une liste blanche d'adresses IP, reconnue principalement par Microsoft, Yahoo et AOL, Comcast, et les réseaux filtrés par Cloudmark. La **Certified Senders Alliance (CSA)** est un programme allemand d'eco et du DDV, et sa liste blanche est utilisée par GMX et WEB.DE et par la majeure partie du marché germanophone des boîtes aux lettres. Les deux programmes visent des expéditeurs différents. Validity certifie **des marques sur des adresses IP dédiées et exclut explicitement les ESP**. La CSA certifie **des plateformes d'envoi, ESP compris, au niveau de l'infrastructure**.

**Aucun des deux programmes n'influence Gmail.** Gmail utilise ses propres systèmes de réputation et [ignore largement les signaux de tiers](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation). Aucune certification, payante ou non, n'améliore le placement chez Gmail.

---

## Validity Sender Certification

Source : « Sender Certification Requirements » (Validity, © 2024, publié pour 2025 ; récupéré en juillet 2026). Les adresses IP certifiées sont ajoutées à la liste blanche de Validity, les fournisseurs de messagerie partenaires en sont informés, et Validity commence à surveiller ces adresses IP 24×7. Validity revendique des relations avec « plus de 75 fournisseurs mondiaux de messagerie et de sécurité ». Les partenaires pour lesquels il indique des seuils sont Microsoft, Yahoo et AOL, Comcast, et Cloudmark.

### Candidature et pré-approbation

1. Vous souscrivez, et Validity lance un audit complet du programme d'envoi.
2. Vous remplissez le **Sender Certification Questionnaire** (généralement dès le premier jour). Cela débloque les flux de données de certification (taux de plaintes, adresses pièges touchées et volume d'envoi pour chaque adresse IP, issus des fournisseurs et des filtres partenaires de Validity) et lance l'audit.
3. Si le programme satisfait aux exigences Business Model, Measurability et Infrastructure, le compte peut obtenir une **activation préliminaire** du statut certifié **avant la fin de l'audit**. C'est l'état « pré-approuvé » mis en avant sur validity.com/sender-certification/get-pre-approved. Les avantages préliminaires durent **jusqu'à 60 jours** pendant l'audit.
4. Si les corrections demandées par l'audit ne sont pas terminées à l'issue de la période préliminaire de 60 jours, ou si les exigences sont enfreintes à un moment quelconque de l'abonnement, les adresses IP sont **suspendues de la liste blanche** (l'accès aux flux de données continue). Elles sont réactivées une fois les corrections faites.

Obligations continues : répondre à toute notification du programme dans un délai de **3 jours**, et engager les actions requises dans un délai de **10 jours**. Informer Validity par écrit dans un délai de **2 jours ouvrés** de toute compromission d'une adresse IP ou d'un domaine, et ne le réactiver qu'après examen des contre-mesures par Validity.

### Éligibilité (modèle d'affaires)

- L'entreprise peut être vérifiée par une source tierce publique (un registre national, Dun & Bradstreet), a une adresse physique enregistrée, est **légalement immatriculée et en activité depuis au moins 1 an**, et n'utilise pas d'agent enregistré qui masque sa propriété.
- Chaque marque approuvée a un site web ou des pages de destination HTTPS valides, et les a **depuis au moins les 6 derniers mois**.
- **Adresses IP dédiées uniquement.** Les adresses IP partagées ne sont pas éligibles, et le candidat doit être la seule entité sur les adresses IP depuis **au moins 60 jours**.
- Les adresses IP certifiées ne peuvent transporter que des **emails transactionnels et commerciaux construits à partir de modèles**. Les emails d'entreprise ou individuels (1:1) ne sont pas autorisés, pas plus que le contenu libre dans les messages (par exemple, du texte saisi dans un formulaire web).

**Catégories d'entreprises exclues** (non certifiables) : fournisseurs de services email (expéditeurs qui envoient au nom de marques qui ne leur appartiennent pas, comme les ESP, les concessions de licences de marque, les éditeurs et les services en marque blanche), agences, expéditeurs tiers et affiliés, génération de prospects, loueurs de listes, enchères au centime, activités illégales et traite des êtres humains. Pour un ESP, cela signifie que vous ne pouvez certifier ni votre propre plateforme ni vos pools partagés. Seuls les clients sur des adresses IP dédiées qui possèdent entièrement leur marque peuvent s'inscrire, chacun individuellement.

### Volumes minimums et limites d'adresses IP

- Chaque adresse IP doit délivrer **au moins 100 messages à chacun de Microsoft et Yahoo sur chaque période glissante de 30 jours** (d'après les données de Validity). Les adresses IP sans volume mesurable et régulier ne sont pas examinées. Une fois certifiées, ces adresses IP sont **suspendues au bout de 30 jours et retirées du programme au bout de 90 jours**.
- Une adresse IP ne peut pas cibler un seul fournisseur de messagerie (avec des exceptions ponctuelles, uniquement avec l'accord écrit préalable de Validity).
- Le nombre maximal d'adresses IP certifiées dépend du volume annuel contractuel :

| Volume d'envoi annuel | IP max. | | Volume d'envoi annuel | IP max. |
|---|---|---|---|---|
| 1 200 000 | 2 | | 120 000 000 | 8 |
| 3 000 000 | 2 | | 180 000 000 | 9 |
| 7 500 000 | 3 | | 240 000 000 | 10 |
| 12 000 000 | 4 | | 420 000 000 | 13 |
| 36 000 000 | 5 | | 600 000 000 | 16 |
| 60 000 000 | 6 | | 1 200 000 000 | 18 |
| 90 000 000 | 7 | | Plus de 1 200 000 000 | 22 |

### Exigences techniques et de programme (synthèse)

- **Infrastructure** : aucun relais ouvert. [DNS inverse confirmé par le direct (FCrDNS)](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip). [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf) sur tous les domaines Return-Path, sans `+all` ni `?all` et sans mécanisme `ptr`. Tous les emails signés [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim), avec des clés d'au moins 1024 bits (2048 recommandés) et **sans balise `l=`** (utilisez `x=` à la place). [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) au minimum à `p=none` sur le domaine From, aligné, avec un `rua` fonctionnel. ARC recommandé pour le transfert. Les comptes de rôle `abuse@` et `postmaster@` sur tous les domaines d'envoi et Return-Path. Une preuve de propriété du domaine par un jeton TXT de Validity, qui doit rester dans le DNS pendant toute la durée de l'adhésion. Les rebonds définitifs retirés de tous les envois futurs. TLS recommandé.
- **Contenu** : une identification claire de la marque. Des lignes d'objet exactes, sans « RE: » ni « FWD: ». Une adresse postale dans les emails commerciaux et transactionnels. **Aucun raccourcisseur d'URL** (Bitly, TinyURL et similaires). **Aucune pièce jointe, de quelque nature que ce soit.** Aucun contenu masqué. Un Message-ID valide. Des en-têtes conformes à la RFC 5322.
- **Désabonnement** : [List-Unsubscribe (RFC 2369) couvert par la signature DKIM, désabonnement en un clic RFC 8058](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic), et un lien dans le corps. Les demandes sont traitées dans un délai de **2 jours**. Les liens restent fonctionnels **au moins 60 jours** après l'envoi. Les demandes faites par d'autres moyens (courrier postal, téléphone, abuse@) sont aussi honorées.
- **Consentement** : [double opt-in, ou simple opt-in avec notification](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement). Une autre base légale, comme un intérêt légitime documenté, exige une preuve écrite. Interdits : l'opt-in présélectionné, le simple opt-in sans notification, la collecte, la location, l'achat ou l'enrichissement de listes, et la prospection par email. La co-inscription exige des inscriptions distinctes et non cochées pour chaque marque et un consentement démontrable. Le transfert à un ami exige un CAPTCHA sur le formulaire, un email et au plus une relance, aucun lien externe, un commentaire personnel de 140 caractères au plus, et au plus 100 messages par utilisateur en 24 h.
- **FBL** : inscrivez-vous à toutes les [feedback loops](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes) disponibles. Le minimum obligatoire est Microsoft JMRP, la Comcast IP & Domain FBL et la Yahoo FBL.

### Seuils de performance (en dépasser un entraîne une suspension partielle ou totale)

**Microsoft SRD (votes « courrier indésirable » du programme Sender Reputation Data), cumul sur 30 jours :**

| Volume SRD par adresse IP | 0–4 | 5–10 | 11+ |
|---|---|---|---|
| Taux SRD autorisé | non appliqué | 5 votes indésirables | 45 % |

| Volume SRD du groupe (toutes les adresses IP certifiées) | 0–9 | 10–30 | 31–50 | 51+ |
|---|---|---|---|---|
| Taux SRD autorisé | non appliqué | 75 % | 65 % | 55 % |

Le seuil de groupe s'applique lorsqu'au moins 2 adresses IP sont certifiées. S'il est dépassé, toutes les adresses IP qui ont au moins 1 vote indésirable sont suspendues.

**Taux de plaintes, moyenne sur 30 jours de tout le volume d'envoi** (appliqués seulement au-delà d'un nombre minimal de plaintes) :

| Source | Seuil | Appliqué au-delà de |
|---|---|---|
| Taux de plaintes Microsoft | 0,2 % | 200 plaintes |
| Taux de plaintes en boîte de réception Yahoo et AOL | 0,2 % | 200 plaintes |
| Taux de plaintes Comcast | 0,3 % | 100 plaintes |
| Taux de plaintes Cloudmark | 1,0 % | 100 plaintes |

**Adresses pièges, cumul sur 30 jours :**

| Catégorie d'adresses pièges | Adresses pièges touchées autorisées |
|---|---|
| Adresses pièges critiques | 3 |
| Adresses pièges importantes | 5 |
| RP Trap Network | 100 |
| Adresses pièges Cloudmark | 100 |

**Listes de blocage (inscriptions en cours) :** 1 inscription sur une liste de blocage critique, ou 2 sur des listes importantes, franchissent le seuil. Des inscriptions répétées ou excessives peuvent entraîner une suspension ou une résiliation.

---

## Certified Senders Alliance (CSA)

La CSA a été fondée en 2004 et est gérée par **eco** (l'association des professionnels de l'Internet) avec le **DDV** (l'association allemande du marketing direct). Elle **certifie des plateformes IP** (IPv4 uniquement). La partie certifiée est l'entreprise qui exploite et contrôle la plateforme d'envoi, ce qui décrit exactement un ESP, à l'opposé du modèle de Validity.

La CSA tient une liste d'adresses IP certifiées qu'elle diffuse aux fournisseurs de messagerie et de sécurité participants, qui l'intègrent à leurs filtres. Ces partenaires renvoient des données de conformité en direct, que les entreprises certifiées consultent dans le **Certification Monitor**. Les documents contractuels (critères, conditions de participation, règlement de procédure, grille tarifaire) sont publiés sur certified-senders.org/resources. Le droit allemand s'applique, et la juridiction compétente est Cologne.

> À propos des documents : les anciennes URL de PDF de 2017 citées plus haut servent désormais les éditions de **juin 2026** des critères et des conditions de participation (les anciens documents ont expiré le 19 juillet 2026). Les chiffres ci-dessous sont donc à jour selon les versions de juin 2026, récupérées en juillet 2026.

### Qui peut participer

- L'entreprise **exploite la plateforme technique** qui contrôle l'envoi d'emails en masse, et en porte la responsabilité. Elle a en général besoin d'**au moins 3 mois d'historique d'envoi** sur l'infrastructure.
- La certification couvre **toutes les adresses IP utilisées pour l'email commercial en masse**. Chaque adresse IPv4 et son FQDN doivent être déclarés dans le Certification Monitor, et les adresses IP déclarées ne peuvent servir qu'à l'email commercial en masse (pas aux emails internes de l'entreprise).
- Pour les ESP et les autres fournisseurs de plateformes, seules les adresses IP sous le **contrôle exclusif** de l'entreprise peuvent être certifiées, et les serveurs sortants certifiés doivent être clairement séparables des serveurs non certifiés.
- Les marques qui exploitent leur propre plateforme doivent contrôler et surveiller entièrement la livraison sur celle-ci. Sinon, elles ne peuvent pas être certifiées.
- **Les hébergeurs sont exclus** pour les serveurs que des clients louent et utilisent de façon autonome.
- Le modèle d'affaires ne doit pas entrer en conflit avec les principes éthiques d'eco et du DDV (un motif de refus à part entière).

### Processus de certification, frais et contrat

1. Renvoyez l'offre individuelle signée et payez les **frais d'évaluation** (fixés par la grille tarifaire de la CSA, et **non remboursés** en cas d'échec de la certification).
2. Évaluation : un contrôle de réputation des adresses IP déclarées à partir des données des partenaires participants, et un examen de documents (exemples de newsletters, liste des adresses IP). Des erreurs laissées sans correction à plusieurs reprises peuvent entraîner la fixation d'un délai. Si le délai n'est pas respecté, la CSA peut facturer de nouveaux frais d'évaluation.
3. La décision revient au **Complaints and Certification Committee (CCC)**, qui compte quatre membres, deux élus par eco et deux par le DDV. La certification exige une majorité. Après un refus (en raison de doutes sur la conformité ou d'un conflit éthique), l'entreprise **peut présenter une nouvelle candidature après 6 mois**.
4. Les cotisations mensuelles (facturées trimestriellement, au prorata) commencent à l'approbation. La catégorie tarifaire dépend du **chiffre d'affaires annuel total** de l'entreprise ou de sa société mère (d'après une enquête annuelle sur le chiffre d'affaires ; une entreprise qui ne répond pas est placée dans la catégorie la plus élevée). Le contrat dure 1 an, se renouvelle automatiquement et prévoit un **préavis de 3 mois**.
5. Un retard de paiement de **plus de 30 jours** entraîne le retrait temporaire des adresses IP de la liste (réinscription environ 5 jours ouvrés après le paiement). Un retard de **plus de 60 jours** entraîne la résiliation pour motif grave. Après la fin du contrat, toutes les références à la CSA doivent être supprimées dans un délai de 4 semaines (6 mois pour les imprimés), avec une **pénalité contractuelle de 500 € par semaine** au-delà.

Statuts des adresses IP sur la liste certifiée : **Active** (tous les avantages, plus la surveillance et les rapports), **Failed** (exigences techniques non satisfaites ; aucun avantage), **Delisted** (une sanction ; aucun avantage, mais la surveillance continue), **Monitored** (pendant la certification) et **Parked** (attribué par l'entreprise aux adresses IP inutilisées ; inscrites, mais l'envoi est interdit, ce qui permet de préparer le DNS à l'avance).

Pendant toute la durée de la certification, l'entreprise doit prouver qu'elle contrôle chaque adresse IP, soit par un enregistrement DNS TXT sur le FQDN du serveur de la forme `CSA-certified-host=<token>`, soit par une organisation titulaire dans le WHOIS qui correspond au nom de l'entreprise sous contrat. Les serveurs sortants doivent avoir un FCrDNS complet (l'enregistrement PTR donne le FQDN, et l'enregistrement A du FQDN renvoie la même adresse IP), annoncer le FQDN en HELO ou EHLO, et avoir des noms d'hôte qui ne ressemblent pas à des identifiants codés de connexion commutée (`server-80-12-54125.example.org` échoue). Une vérification absente ou des résolutions en échec donnent le statut « failed ».

### Critères obligatoires (juin 2026)

**Confiance et transparence :** une adresse postale et un contact numérique faciles à trouver sur le site web, des informations sur la confidentialité accessibles, et des messages et un dialogue SMTP conformes aux RFC (actuellement RFC 6532, 2142, 2369, 5321, 5322, 7208, 6376, 8058).

**Prévention des abus :**
- Un compte de rôle pour les abus (de préférence `abuse@org-domain.tld`) enregistré dans le Certification Monitor. Répondez à l'**eco Complaints Office dans les 24 heures, les jours ouvrés**.
- Les fournisseurs de plateformes doivent pouvoir faire respecter la conformité pour chaque client (blocage, limitation de débit, plafonds de volume, plafonds de domaines d'envoi) et doivent protéger les comptes clients (par exemple, avec la 2FA).
- Les liens de redirection et de suivi des clics doivent pouvoir être désactivés **dans les 24 heures** suivant une notification de phishing ou d'usage abusif.
- L'en-tête **`X-CSA-Complaints: csa-complaints@eco.de`**, inséré et signé DKIM sur les seuls serveurs certifiés, dans les 4 semaines suivant la certification, et confirmé par un envoi de test.
- Aucun relais ouvert, aucun proxy public et aucun backscatter. Une surveillance continue. Une livraison en **TLS** conforme à l'état de l'art actuel.

**Authentification :**
- SPF pour le domaine MAIL FROM, se terminant par **`-all` ou `~all`**.
- Une signature DKIM valide sur chaque email (RFC 6376). Pour les ESP, `d=` doit pouvoir être rattaché au domaine d'envoi du client (une signature supplémentaire avec le domaine de l'ESP est autorisée). La signature doit couvrir au moins **From, X-CSA-Complaints, Date, To**, et le **paramètre de longueur `l=` est interdit**.
- **L'alignement DKIM souple** est obligatoire : le domaine organisationnel de `d=` doit correspondre au domaine de l'en-tête From (avec une exception pour les ESP, uniquement lorsque le client n'a pas de domaine à lui).

**Hygiène de base de données :**
- La plateforme doit pouvoir insérer **List-Unsubscribe** (la méthode URL de la RFC 2369 avec POST en HTTPS, qui peut être combinée avec **List-Unsubscribe-Post**, le désabonnement en un clic de la RFC 8058) et **List-Help** (un lien mailto: ou HTTPS ; HTTP n'est pas autorisé) dans chaque email.
- Chaque email publicitaire doit comporter un désabonnement fonctionnel qui n'exige **aucune connexion**. Les ESP doivent offrir à leurs clients une fonction de désabonnement simple par un lien dans le corps (les pages de préférences et de sélection sont autorisées).
- Une gestion des rebonds conforme à la RFC 5321, avec un **enregistrement MX (ou un enregistrement A en solution de repli) sur le domaine de l'expéditeur d'enveloppe**. Tout nouvel envoi vers des boîtes connues comme inexistantes doit être empêché.

**Seuils de performance (fenêtres de 7 jours) :**

| Indicateur | Seuil | Base de calcul |
|---|---|---|
| Taux de plaintes pour spam | Au plus **0,3 %** par adresse IP ou par entreprise | Plaintes divisées par les emails arrivés en boîte de réception |
| Taux d'absence de DKIM | Au plus **3,0 %**, moyenne de l'entreprise | Emails non signés divisés par le total des emails envoyés (données validées par les partenaires) |
| Taux de rebonds définitifs | Au plus **1,0 %** par adresse IP ou par entreprise | |
| Réputation générale | Aucun problème significatif de réputation d'IP ou de DKIM auprès des fournisseurs participants (adresses pièges touchées, analyseurs de contenu, taux de spam) | |

**Recommandé (non obligatoire) :** inscrivez-vous aux FBL publiques et mettez en œuvre l'**en-tête CFBL (RFC 9477)**. Envoyez en multipart HTML et texte. Publiez DMARC avec un `rua` exploitable, `p=reject` étant recommandé. Utilisez **DANE (RFC 7671, avec DNSSEC), avec MTA-STS (RFC 8461) en solution de repli** lorsque DNSSEC n'est pas envisageable. Utilisez DKIM avec des clés de 2048 bits et SHA-256. Utilisez le double opt-in (l'email de confirmation ne doit contenir **aucune publicité**). Indiquez la fréquence d'envoi lors de l'inscription. Fournissez une adresse de réponse fonctionnelle. Utilisez **des adresses IP distinctes pour les newsletters et pour le courrier transactionnel**. Évitez les raccourcisseurs d'URL. Étendez l'alignement DKIM au domaine MAIL FROM, et gardez cohérents les domaines des en-têtes List, Reply-To et Sender.

La CSA publie une **liste de contrôle** d'autoévaluation (certified-senders.org/csa-checklist) qui transpose ces critères en questions de préparation à réponse oui ou non. Il est utile de la parcourir avant de payer les frais d'évaluation.

### L'Email Directive de la CSA : le socle juridique allemand transposé en contenu de certification

Les critères de certification de la CSA renvoient à son « Email Marketing Directive », qui résume le droit allemand et européen. C'est ce qui donne à la certification CSA une portée juridique en Allemagne. Elle compte même pour les expéditeurs non certifiés qui écrivent à des utilisateurs allemands (comparez avec l'attente de double opt-in (DOI) signalée dans [les exigences de GMX et WEB.DE](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/gmx-web-de-exigences-postmaster)).

**Permission (chapitre 2 de la directive)**, fondée sur le Règlement général sur la protection des données (RGPD) et la directive ePrivacy 2002/58/CE telle que transposée dans la loi contre la concurrence déloyale (UWG), la TMG et la TTDSG (lois sur les télémédias) et la loi fédérale sur la protection des données (BDSG) :
- La « publicité » s'entend largement (newsletters, vœux d'anniversaire, études de marché, promotion de la marque, appels aux dons). Les emails transactionnels n'exigent pas de consentement, jusqu'à ce qu'un élément publicitaire y soit ajouté. À partir de là, les règles complètes du consentement s'appliquent.
- Le consentement doit être **transparent** (quelle entreprise, quels produits, quels canaux, sans consentement en blanc ; la Cour fédérale de justice (BGH) a jugé qu'un consentement nommant environ 8 entreprises peut être valable, tandis que le tribunal régional supérieur (OLG) de Francfort a jugé que 59 partenaires étaient trop nombreux), **actif** (pas de cases précochées ni de montages en opt-out), **libre**, et **documenté** (le texte du consentement, le lieu, ainsi que l'horodatage et l'adresse IP de l'inscription et du clic de confirmation DOI).
- **Le double opt-in est de fait la norme de preuve** (reconnu par la BGH comme preuve que la demande provient de l'adresse). L'email de confirmation DOI ne doit contenir **aucune publicité** (des tribunaux ont même contesté des logos en pied de page). Les inscriptions non confirmées devraient être supprimées dans un délai d'**environ 2 semaines**.
- Le consentement n'a pas de date d'expiration légale, mais le tribunal régional (LG) de Munich I a considéré qu'un consentement **inutilisé pendant environ 1,5 an** était caduc.
- Retirer son consentement doit être plus facile que de le donner. Les preuves de consentement sont conservées **3 ans après le retrait** (le délai de prescription du §195 BGB) pour se défendre en cas de réclamation.
- **L'exception pour les clients existants du §7(3) UWG** (publicité par email sans consentement) exige les quatre conditions : l'adresse a été obtenue dans le cadre d'une vente conclue, la publicité ne porte que sur des biens ou services propres et similaires, une mention claire du droit d'opposition est donnée lors de la collecte de l'adresse et dans chaque email, et le client ne s'y est pas opposé.
- **Le B2B n'est pas exempté.** Le droit allemand exige aussi l'opt-in pour la publicité par email en business-to-business (B2B). La règle assouplie du consentement présumé en B2B n'existe que pour le démarchage téléphonique.

**Mentions légales, ou Impressum (chapitre 3 de la directive)**, fondées sur la directive sur le commerce électronique 2000/31/CE et la loi sur les télémédias : chaque email commercial doit comporter des **mentions légales complètes, en texte intégral, dans l'email lui-même** (et non derrière des liens). Elles comprennent la raison sociale avec la forme juridique, l'adresse postale complète, les représentants légaux, le tribunal d'immatriculation et le numéro, une adresse email (un numéro de téléphone est recommandé), et le numéro de TVA le cas échéant. L'identité de l'expéditeur et le caractère commercial du message doivent être évidents. Les infractions sont passibles d'amendes jusqu'à **50 000 €**.

### Quels serveurs de réception reconnaissent la CSA

Les fournisseurs de messagerie participants (listés sur certified-senders.org/participants, récupéré en juillet 2026) comprennent la totalité du marché grand public germanophone (**GMX, WEB.DE, mail.com, 1&1, freenet, mail.de, T-Online, Arcor, Kabel Deutschland (Vodafone), unitymedia, Swisscom**) et des acteurs internationaux : **Microsoft (Outlook.com, Office 365), Yahoo, AOL, Comcast, Orange, Seznam.cz, Fastmail** et divers hébergeurs. Les participants de sécurité et de filtrage comprennent **Cloudmark, Cisco Talos, abusix, Hornetsecurity, Open-Xchange, Halon et Excello (virusfree)**.

Le poids accordé à la certification varie. Les fournisseurs allemands en font un signal de premier plan : GMX et WEB.DE orientent activement les expéditeurs de gros volumes vers la CSA et font transiter les retours de plaintes par elle, et ils n'exploitent pas de FBL publique à eux. Pour les grands participants internationaux, c'est une donnée parmi d'autres, et non un moyen de contourner les filtres.

---

## La certification en vaut-elle la peine ?

Pour un opérateur d'ESP, les coûts et les bénéfices se présentent ainsi :

- **Gmail : non.** Gmail ne participe à aucun des deux programmes, et ignore la certification et les listes de blocage de tiers au profit de ses propres systèmes. Si votre problème est le placement chez Gmail, la certification n'apporte rien. Corrigez plutôt les [fondamentaux de l'engagement et du taux de spam](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs).
- **La certification est un plancher, pas un coup de pouce.** Les critères d'admission des deux programmes reprennent pour l'essentiel le [M3AAWG Senders BCP](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs), plus une surveillance, et un expéditeur qui les respecte réellement a généralement déjà une bonne délivrabilité. La valeur ajoutée tient à (a) les flux de données (les flux de Validity sur les adresses pièges, les plaintes et le SRD, et le Certification Monitor de la CSA avec les données des partenaires, qui compte parce que les retours de plaintes de GMX et WEB.DE ne sont disponibles par aucun autre moyen), (b) le bénéfice du doute pendant les incidents et la [chauffe](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip), et (c) une trace documentée de la conformité.
- **La CSA mérite d'être étudiée par tout ESP qui a un volume significatif en Allemagne, en Autriche et en Suisse (DACH).** C'est le seul programme conçu pour certifier des plateformes et des ESP. C'est de fait le canal de FBL et d'escalade de GMX et WEB.DE, et ses critères transposent les exigences juridiques allemandes (DOI, Impressum) que vous devez de toute façon respecter pour écrire en Allemagne en toute sécurité. Les coûts augmentent avec le chiffre d'affaires de l'entreprise (les frais d'évaluation plus les cotisations mensuelles). Prenez au sérieux les obligations de conformité (réponse aux signalements d'abus en 24 h, désactivation des liens en 24 h, seuils sur des fenêtres de 7 jours), car perdre la certification après une participation publique est en soi un signal de réputation.
- **Validity est une décision pour chaque marque, et non pour l'ESP.** Les ESP sont une catégorie exclue. Seuls les clients sur des adresses IP dédiées sont éligibles, et ils doivent posséder leur marque, avoir au moins 1 an d'existence, être seuls sur leurs adresses IP depuis au moins 60 jours, et envoyer un volume soutenu vers Microsoft et Yahoo. Il convient aux marques B2C à fort volume dont les problèmes se situent chez Microsoft (SRD et JMRP), Yahoo et AOL, Comcast, ou chez des fournisseurs d'accès régionaux filtrés par Cloudmark. Ses seuils (0,2 % de plaintes chez Microsoft et Yahoo, 3 adresses pièges critiques touchées en 30 jours, 1 inscription sur une liste de blocage critique) sont plus stricts que les objectifs d'exploitation habituels. Traitez-les comme un niveau de service à tenir, sinon attendez-vous à une suspension en cours de contrat.
- **Aucun des deux programmes ne remplace un bon consentement.** Les deux interdisent purement et simplement les listes achetées, louées et enrichies. La certification ne peut pas blanchir une mauvaise pratique d'acquisition, et les deux programmes retirent la certification plus vite que les fournisseurs de messagerie ne pardonnent.

# Protection de la marque : gestion des domaines

> Protéger un portefeuille de domaines contre le détournement, l'abus de domaines sosies et l'usurpation d'identité : inventaire, verrous du bureau d'enregistrement et du registre, enregistrement défensif, surveillance, procédures de retrait, et enregistrements DNS de protection pour les domaines qui n'envoient pas d'emails et les domaines parqués.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/protection-de-la-marque-gestion-des-domaines

Vos domaines peuvent être attaqués même si personne n'y pénètre. Les attaquants qui ne peuvent pas prendre le contrôle des vrais domaines d'une marque se rabattent sur la meilleure solution suivante : ils enregistrent une variante de ces domaines, ou envoient des emails en usurpant leur identité. La protection des domaines d'une marque s'organise en trois niveaux : des **exigences de sécurité minimales** que toute organisation devrait respecter, des **mesures renforcées** à mesure que la marque gagne en maturité, et des **parades propres à chaque attaque**.

Le fonctionnement de l'authentification est traité dans [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf), [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim) et [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc). Les pratiques ci-dessous concernent la gestion du portefeuille de domaines qui les entoure.

## Exigences de sécurité minimales

| Exigence | Pratique |
|---|---|
| **Inventaire des domaines** | Recensez chaque domaine que possède l'entreprise. Un tableur suffit, mais un outil dédié est préférable, car il peut aussi gérer les certificats et les serveurs de noms. Pour chaque domaine, notez sa finalité et nommez les personnes responsables de sa sécurité et de sa maintenance. Tenez l'inventaire à jour à mesure que des domaines et des collaborateurs sont ajoutés, retirés ou changent. Suivez la façon dont chaque domaine est hébergé et configuré dans le DNS, et assurez-vous que tout prestataire externe travaille avec votre fournisseur d'infrastructure DNS. |
| **Protéger les comptes de titulaire** | Faites de la protection des noms de domaine un volet permanent de la politique de sécurité. Gardez confidentiels les identifiants des comptes de titulaire, et n'autorisez leur récupération que par les administrateurs de domaines les plus haut placés, dans des circonstances exceptionnelles. Lors des changements de personnel, changez les identifiants des comptes concernés, en particulier les mots de passe. N'utilisez jamais l'adresse email d'un contact de transfert comme identifiant des pages d'administration des domaines en libre-service : les pirates cherchent les contacts de transfert dans le WHOIS et vérifient systématiquement si cette adresse sert aussi de nom d'utilisateur. Utilisez des adresses de rôle, et non des adresses personnelles, pour les contacts. **Authentification multifacteur (MFA) sur chaque compte de domaine.** |
| **Coordonnées à jour** | Toute modification du nom de l'entreprise, de son adresse légale, de son numéro de téléphone ou de son adresse email doit déclencher une mise à jour auprès de chaque bureau d'enregistrement. Les bureaux d'enregistrement sont une défense essentielle contre les tentatives de détournement, et des coordonnées à jour leur donnent les meilleurs moyens de vous protéger. |
| **Politiques officielles** | Formalisez par écrit les décisions et les processus, en particulier pour la mise hors service ou la reconfiguration des domaines, pour la gestion des changements, et pour les services habilités à effectuer des modifications. |
| **Tout documenter** | Les politiques, les registres et une communication régulière avec le personnel permettent à l'entreprise de rester préparée aux incidents, et d'accepter rapidement les changements légitimes. |

## Mesures de sécurité renforcées (« gains rapides »)

- **Alias de rôle pour le contrôle des domaines et les notifications** : envoyez les notifications des bureaux d'enregistrement et des fournisseurs DNS à un compte de rôle (`domainregistrar@example.com`), et non à la boîte d'une personne, afin qu'elles arrivent toujours quand des collaborateurs partent, sont en vacances ou en congé.
- **Choisissez délibérément l'autorité DNS.** Des serveurs faisant autorité open source hébergés en interne, une appliance sur site et un service DNS faisant autorité dans le cloud ont chacun des points forts différents dans leur prise en charge de DNSSEC, de l'authentification des emails et de la sécurité. Auditez la configuration obtenue avec des outils gratuits (par exemple Zonemaster, https://zonemaster.iis.se/en/).
- **Choisissez le bon bureau d'enregistrement.** Les bureaux d'enregistrement se spécialisent : certains servent les petits budgets et les amateurs, d'autres les spéculateurs en gros volumes, d'autres certaines langues. Enregistrez les domaines de production et les domaines essentiels chez un **bureau d'enregistrement pour entreprises** spécialisé dans la protection des actifs critiques. Un bureau d'enregistrement grand public peut convenir pour les enregistrements défensifs. Les fonctionnalités minimales à exiger sont une infrastructure redondante, une protection contre l'expiration accidentelle, la surveillance des domaines (le domaine est-il en ligne et répond-il ?), la double authentification (2FA) sur la console de gestion, un service de **verrou du bureau d'enregistrement** (registrar lock : la combinaison de `clientTransferProhibited`, `clientUpdateProhibited` et `clientDeleteProhibited`, qui empêche la suppression, le transfert ou la modification non autorisés) et la prise en charge de DNSSEC.
- **Enregistrement défensif.** Enregistrez à l'avance les variantes de domaine de premier niveau (TLD) de la marque (`brand.co.uk` quand vous êtes `brand.com`). Établissez une politique pour les domaines à haut risque qui ne serviront jamais en production : noms ressemblants, fautes de frappe, abréviations et formes courtes courantes (par exemple « BofA » pour « Bank of America »), combinés à des mots souvent détournés comme « login » ou « account », et toute variante que vous avez déjà dû combattre. Vous ne pouvez pas en enregistrer un nombre illimité : fixez des priorités et un budget, réévaluez-les à la lumière de l'expérience, et coordonnez-les avec vos programmes de surveillance et de retrait. **Ce que votre tolérance au risque et votre budget ne vous permettent pas d'acheter, surveillez-le.**
- **Gérez les certificats SSL et TLS avec le DNS.** La même équipe fait face à des enjeux juridiques et techniques similaires pour les deux. Surveillez les journaux de transparence des certificats pour repérer les **enregistrements de certificats ressemblants**, et pas seulement les domaines ressemblants. Publiez des **enregistrements CAA** pour empêcher l'émission de certificats non autorisés pour vos domaines.
- **Codes d'état EPP et verrous.** Appliquez `clientTransferProhibited`, `clientDeleteProhibited` et `clientUpdateProhibited` aux domaines de l'organisation. Au-delà, envisagez un **verrou du registre** (registry lock : une protection contre les modifications ou suppressions non autorisées, confirmée par un canal distinct et mise en place par l'intermédiaire du bureau d'enregistrement) et, au-dessus encore, des services de **verrou du bureau d'enregistrement** qui exigent une confirmation par un canal distinct avant toute modification. Une fois les verrous posés, vérifiez régulièrement le WHOIS pour confirmer que le domaine est toujours verrouillé, et que ses serveurs de noms, sa configuration DNS et ses contacts n'ont pas été modifiés à votre insu. Envisagez un service tiers qui vous alerte en cas de modification.
- **Sauvegardez la configuration DNS.** Stocker la configuration DNS de façon sécurisée vous permet de toujours la restaurer, par exemple après la compromission d'un compte. Intégrez la restauration urgente des domaines et du DNS au plan de continuité d'activité et aux exercices sur table, vérifiez si votre assurance couvre les incidents de domaine et de DNS, et incluez le détournement de domaine dans la réponse aux incidents.
- **Surveillez les domaines tiers abusifs.** Des services commerciaux le font de manière fiable. Ne pas le faire expose la marque à des abus importants.

## Vecteurs d'attaque et parades

### Cybersquatteurs, domaines sosies (homographes) et empiètements

Surveillez les nouveaux enregistrements de domaines pour repérer les noms ressemblants. De nombreuses marques confient cette tâche à un service géré. Les sources de données sont :

- **ICANN CZDS** (Centralized Zone Data Service) : les fichiers de zone de tous les domaines de premier niveau génériques (gTLD), mais **pas ceux des domaines de premier niveau nationaux (ccTLD)**. Ajoutez les fichiers de zone des ccTLD selon les menaces auxquelles vous faites face.
- **Les enregistrements de certificats SSL** (journaux de transparence des certificats).
- **Les flux payants de domaines nouvellement enregistrés ou nouvellement observés.**

Chaque domaine sosie découvert doit être classé comme bénin ou malveillant. Le kit définit un **domaine malveillant** comme un domaine utilisé pour la distribution de logiciels malveillants, la commande et le contrôle de botnets, le phishing, la compromission de la messagerie en entreprise (BEC) ou le spam. Un enregistrement de mauvaise foi portant sur une marque, mais qui n'est pas aussi utilisé pour ces activités, porte atteinte à la marque sans être malveillant. Cette distinction détermine la voie de remédiation qui fonctionne.

| Catégorie | Voie | Remarques |
|---|---|---|
| **Malveillant** (preuve de phishing, de vol d'identifiants, de logiciel malveillant, de commande et contrôle (C2) de botnet, de spam) | **Envoyez une demande de retrait au bureau d'enregistrement du domaine** (identifié via le WHOIS). Fournissez des preuves détaillées : des captures d'écran du contenu litigieux, et un exemple d'email d'hameçonnage avec ses en-têtes complets. Si l'hébergeur est une entité distincte, le contacter peut faire disparaître le contenu plus vite. Si le bureau d'enregistrement ne répond pas, faites remonter le dossier à l'ICANN, qui accrédite les bureaux d'enregistrement. | Les bureaux d'enregistrement accrédités par l'ICANN ne considèrent normalement un domaine comme malveillant que s'il a été **enregistré et utilisé** pour du phishing, des logiciels malveillants ou la commande et le contrôle (C2) de botnets. **Les domaines compromis (légitimes mais piratés) sont un autre problème, et la suspension est généralement la mauvaise solution.** Après un retrait, surveillez une éventuelle reprise d'activité. Vous pouvez aussi acheter le domaine (certains bureaux d'enregistrement le transfèrent à la marque), ce qui est utile pour alerter les victimes et recueillir des statistiques. |
| **Atteinte à la marque** (contrefaçon de marque, non malveillante) | La même procédure de retrait ne fonctionne que si du phishing, des logiciels malveillants ou de la commande et du contrôle (C2) sont aussi en jeu (pour les gTLD ; pour les ccTLD, les procédures dépendent des conditions d'utilisation de chaque ccTLD). Sinon, adressez-vous de manière informelle au propriétaire (identifié via le contenu hébergé ou le WHOIS), sauf si le titulaire semble malveillant. Recourez ensuite à une procédure formelle **UDRP** ou **URS**, ou à une action civile. Les procédures UDRP et URS coûtent de l'argent et prennent quelques mois, mais leur succès peut transférer le contrôle du domaine à la marque. | Les litiges portant uniquement sur une marque sont des questions juridiques. Faites intervenir un conseil en propriété intellectuelle, et voir [conformité](https://emailmarketing.net/fr/apprendre/conformite) pour les informations juridiques par juridiction. |
| **Suspect mais non prouvé** (ou retraits échoués) | Achetez le domaine, ou surveillez les changements de son contenu hébergé et de ses enregistrements DNS. | Meilleure pratique : acheter un nombre limité de domaines très suspects ou potentiellement utiles, et surveiller les autres par la technologie associée à un examen humain. |

### Usurpation d'identité (spoofing) par email

L'usurpation d'identité désigne des emails qui semblent provenir du domaine légitime (ou d'un domaine presque identique comme `microsoftt.com`) mais n'en proviennent pas. Un attaquant n'a besoin d'aucun contrôle sur un domaine pour envoyer des emails usurpés qui prétendent en provenir. Parades :

- Surveillez les domaines sosies (avec des outils open source ou des prestataires tiers). Quand vous trouvez un abus, déposez une plainte auprès du bureau d'enregistrement, selon la procédure de retrait décrite plus haut.
- **Authentifiez chaque domaine que vous possédez, y compris les domaines qui n'envoient jamais d'emails.** Appliquez SPF, DKIM et DMARC à tout le portefeuille, comme le recommande le [M3AAWG Email Authentication BCP](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-l-authentification-des-emails).
- Envisagez de **supprimer les enregistrements MX** des domaines sur lesquels vous ne recevez ni n'envoyez jamais d'emails.

### Enregistrements DNS de protection pour les domaines qui n'envoient pas d'emails et les domaines parqués

Pour la forme de ces enregistrements, le kit renvoie au M3AAWG Protecting Parked Domains BCP (voir aussi l'[index des documents](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/index-des-documents-m3aawg)). Pour un domaine (ou un sous-domaine) qui n'envoie aucun email, publiez les quatre :

| Enregistrement | Valeur | Effet |
|---|---|---|
| SPF | `example.com. TXT "v=spf1 -all"` | Aucun hôte n'est autorisé à envoyer des emails avec ce MAIL FROM, si bien que les serveurs de réception rejettent sans ambiguïté (hard fail) les falsifications. |
| DKIM | `*._domainkey.example.com. TXT "v=DKIM1; p="` | Un enregistrement de clé générique avec une **clé publique vide**. Il révoque tous les sélecteurs, si bien qu'aucune signature DKIM pour le domaine ne peut être vérifiée. |
| DMARC | `_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:reports@yourbrand.example"` | Demande aux serveurs de réception de rejeter tout message qui utilise le domaine dans l'en-tête From:. L'adresse `rua` vous montre quand même les tentatives d'abus. Les sous-domaines héritent de `p=reject` par défaut (quand `sp` n'est pas défini). Voir [Déploiement de DMARC](https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc). |
| MX nul | `example.com. MX 0 .` | RFC 7505. Il déclare explicitement que le domaine ne reçoit aucun email, si bien que les expéditeurs échouent immédiatement au lieu de réessayer, et que l'absence d'enregistrement MX ne peut pas se replier sur l'enregistrement A. |

Appliquez ces enregistrements aux enregistrements défensifs le jour même de leur achat. Un domaine cousin enregistré à titre défensif mais laissé sans protection est exactement ce qu'un auteur de phishing cherche à usurper. Quand un domaine parqué est ensuite mis en service pour l'envoi, retirez ces enregistrements dans le cadre de la [configuration normale de l'authentification](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-l-authentification-des-emails) et de la chauffe du domaine ([pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi)).

### Prise de contrôle du compte chez le bureau d'enregistrement (ATO)

Un seul identifiant deviné, hameçonné ou obtenu par ingénierie sociale peut livrer à un attaquant **l'ensemble du portefeuille de domaines**, et vous compliquer l'accès à ce portefeuille. Points particuliers :

- **L'email est souvent le seul canal par lequel les bureaux d'enregistrement informent les titulaires de l'activité de leur compte.** Un attaquant qui contrôle le compte peut modifier le DNS pour que ces notifications n'arrivent jamais, par exemple quand les adresses des contacts administratif et technique du titulaire sont hébergées dans le domaine compromis. **Déclarez une adresse de contact extérieure à votre propre domaine**, afin que les notifications d'une prise de contrôle vous parviennent quand même.
- Les auteurs de phishing se font aussi passer pour des bureaux d'enregistrement et des fournisseurs DNS afin de récolter les identifiants des titulaires. L'objectif habituel est de modifier les **adresses IP de vos serveurs de noms**. Contrôler la résolution des noms donne accès à vos emails entrants, à une copie en temps réel de votre site web, à des identifiants capturés, et à l'utilisation du domaine pour du spam ou des activités criminelles.
- **Le domain shadowing** est une variante plus discrète. L'attaquant laisse votre site et vos emails intacts, et crée discrètement de nouveaux sous-domaines sous son propre contrôle (ou des domaines entièrement nouveaux, facturés sur votre moyen de paiement enregistré), par exemple `login.yourcompany.com` ou `email.yourcompany.com`, qui pointent vers son infrastructure. C'est très difficile à détecter, car peu de bureaux d'enregistrement proposent une surveillance des nouveaux domaines ou sous-domaines ajoutés à un compte. Contre-mesures : utilisez cette surveillance là où le bureau d'enregistrement la propose, planifiez des contrôles ponctuels réguliers du compte de gestion des domaines pour repérer les modifications récentes, et récupérez des **rapports de DNS passif sur les nouveaux noms d'hôte qui apparaissent sur vos domaines**.

Liste de contrôle des parades : MFA sur tous les comptes, surveillance des comportements anormaux (comme des connexions inhabituelles), surveillance des domaines sosies, plainte auprès du bureau d'enregistrement quand vous identifiez un abus (selon la procédure de retrait ci-dessus), et procédures de parade documentées et partagées avec les équipes de sécurité.

### Vulnérabilité logicielle

Les attaquants analysent les portails des bureaux d'enregistrement et d'administration à la recherche de vulnérabilités de l'application web (par exemple l'injection SQL). Une seule exploitation réussie peut révéler d'un coup les identifiants de nombreux comptes de domaine. Maintenez les logiciels à jour, et gérez un programme de divulgation responsable des vulnérabilités.

## Pertinence pour un ESP

Pour un ESP, le portefeuille dépasse la marque de l'entreprise. Les domaines d'envoi, les domaines de rebond et de chemin de retour, les domaines de suivi et les sous-domaines délégués par chaque client sont autant d'actifs que les attaquants peuvent détourner discrètement (shadowing), squatter ou usurper. [Pratiques d'infrastructure d'envoi](https://emailmarketing.net/fr/apprendre/operations/pratiques-d-infrastructure-d-envoi) explique comment la réputation des domaines cousins déteint et comment la délégation des domaines clients est organisée, et [listes de blocage et Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus) traite de la stratégie de domaine pour les clients d'un ESP. [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) ne protège explicitement pas contre les domaines sosies. La surveillance et l'enregistrement défensif sont les seuls contrôles pour combler cette lacune.

## Lectures complémentaires citées par le kit

- ICANN SSAC-044, « A Registrant's Guide to Protecting Domain Name Registration Accounts », pour des mesures de sécurité plus approfondies.
- ICANN Centralized Zone Data Service : https://czds.icann.org/home (fichiers de zone des gTLD uniquement).
- ICANN Trademark Clearinghouse : https://newgtlds.icann.org/en/about/trademark-clearinghouse (consultez un conseil juridique).
- M3AAWG Protecting Parked Domains BCP : https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bp-2015-12.pdf

# Réputation des URL et empreintes de contenu

> Comment les filtres de contenu modernes jugent le corps des messages : listes de réputation des URL et des domaines (zones SURBL, mécanique des requêtes, traitement des redirecteurs) et empreintes floues (shingles de rspamd, détection de campagnes quasi identiques), et ce que cela implique pour les domaines de liens et les modèles des expéditeurs.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/reputation-des-url-et-empreintes-de-contenu

Un message peut être entièrement authentifié et envoyé depuis une adresse IP propre, et être quand même filtré à cause de ce qu'il contient. La réputation des adresses IP et des domaines d'envoi ([listes de blocage](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus)) juge qui envoie. Les filtres de contenu ajoutent deux contrôles qui jugent ce qui est envoyé : la réputation de chaque domaine lié dans le corps du message, et une empreinte floue du message, comparée aux campagnes de spam déjà vues.

Ces deux contrôles fonctionnent indépendamment de l'authentification et de la réputation d'IP propres à l'expéditeur. Un message qui renvoie vers un domaine inscrit sur une liste de blocage, ou dont l'empreinte correspond à une campagne connue, est filtré quoi qu'il en soit.

## Partie 1 : réputation des URL et des domaines (SURBL)

SURBL est l'exemple type de la **DNSBL d'URI**. Au lieu d'inscrire des adresses IP d'envoi, elle inscrit des domaines (et quelques adresses IP) qui apparaissent dans le corps d'emails non sollicités ou malveillants. URIBL.com et les listes Spamhaus DBL et HBL (voir [Listes de blocage et Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus)) fonctionnent de la même manière. Les filtres antispam extraient chaque URL d'un message, réduisent chacune à un domaine et interrogent ces zones pour ce domaine. Une correspondance ajoute généralement un score très élevé ou bloque le message purement et simplement.

### Zones des listes et valeurs de retour

Les données publiques sont servies dans une seule zone combinée à valeurs en masque de bits, **`multi.surbl.org`**, qui réunit ces jeux de données :

| Liste | Signification | Valeur du bit (dernier octet) |
|------|---------|------------------------|
| DM | Domaines d'adresses email jetables | 4 |
| PH | Sites de phishing | 8 |
| MW | Sites de logiciels malveillants | 16 |
| CT | Domaines de suivi des clics (click trackers) | 32 |
| ABUSE | Sites d'abus ou de spam en général | 64 |
| CR | Sites piratés (sites légitimes compromis) | 128 |

- Les réponses sont des enregistrements A de la forme **127.0.0.X**. Un domaine inscrit sur plusieurs listes renvoie la somme de leurs bits. Par exemple, **127.0.0.80 signifie MW plus ABUSE (16 plus 64)**.
- **NXDOMAIN** signifie que le domaine n'est pas inscrit, et un enregistrement A qu'il l'est. SURBL indique que l'enregistrement A est « la réponse fortement privilégiée pour un usage automatisé ».
- Le **TTL par défaut est de 60 secondes** sur la zone multi en production, et les données elles-mêmes sont mises à jour environ **toutes les 30–40 secondes**.
- Une réponse **127.0.0.1** n'est pas une inscription. Elle signale que l'accès de l'émetteur de la requête est bloqué à cause d'un volume excessif sur les miroirs publics, et qu'il doit s'inscrire au Sponsored Data Service de SURBL.
- Au-delà de ses listes de domaines, SURBL propose aussi **HASHBL**, des requêtes de réputation fondées sur des empreintes, dans ces catégories : abuse, cracked, malware, phish, email, crypto, phone.
- Pour les opérateurs de filtres, les données sont livrées en DNS (Private Query Service), en rsync (recommandé pour le filtrage d'emails à fort volume), en RPZ (filtrage web), par API REST, en CSV et en RTF (flux JSON en temps réel).

L'existence même de la liste **CT (click tracker)** compte : les domaines de suivi et de redirection sont une catégorie d'inscription à part entière, et non un cas marginal.

### Comment les filtres extraient et interrogent les URL (consignes d'implémentation de SURBL)

Les consignes publiées par SURBL à l'intention des développeurs de filtres décrivent ce que font réellement les filtres de contenu en production :

1. **Extraire chaque URI** du message, en **résolvant complètement les redirections jusqu'au domaine cible final**. Autrement dit, les filtres doivent suivre les redirecteurs et les raccourcisseurs jusqu'à la destination et vérifier ce domaine, et pas seulement le lien visible.
2. Réduire les URI à des domaines ou sous-domaines. Avec la zone multi à caractères génériques, les sous-domaines d'un domaine inscrit correspondent automatiquement, donc les filtres n'ont pas besoin de normaliser au niveau du domaine enregistré.
3. **Ne pas résoudre les domaines extraits dans le DNS.** C'est la chaîne du domaine elle-même qui sert de clé de recherche.
4. Interroger en ajoutant le domaine devant la zone (`domainundertest.com.multi.surbl.org`) et en faisant une recherche d'enregistrement A.
5. Les **URL à adresse IP numérique** (`http://10.20.30.40/`) sont vérifiées avec les octets inversés, comme le font les DNSBL : `40.30.20.10.multi.surbl.org` (octets en base 10).
6. Tenir une **liste blanche locale** de domaines connus et à fort trafic (yahoo.com, w3.org, google.com) pour éviter des requêtes inutiles.
7. **Vérifier que les réponses se situent dans 127/8.** Une réponse hors de 127.0.0.0/8 indique un résolveur DNS qui utilise des caractères génériques ou des redirections et corrompt les résultats ; utilisez un serveur de noms cache local.

SURBL interdit explicitement deux pratiques, car toutes deux provoquent des faux positifs avec l'hébergement mutualisé : ne **pas** utiliser les données d'URI du corps des messages pour vérifier les adresses IP des expéditeurs, et ne **pas** résoudre les domaines inscrits en adresses IP pour inscrire ensuite ces adresses IP sur une liste de blocage.

### Ce qu'implique ce mécanisme

- L'inscription d'un seul domaine touche **chaque message qui renvoie vers lui**, quel que soit l'expéditeur et quelle que soit l'adresse IP. Pour un ESP, l'inscription d'un domaine partagé sur une DNSBL d'URI est un incident qui touche de nombreux clients.
- Comme les filtres résolvent les redirections, cacher une mauvaise destination derrière un raccourcisseur ou votre propre domaine de redirection n'échappe pas au contrôle. Cela expose au contraire **votre domaine de redirection** à une inscription lorsque les destinations qu'il masque font l'objet d'abus. C'est exactement ce que capte la liste CT de SURBL.
- Comme les sous-domaines d'un domaine inscrit correspondent dans la zone à caractères génériques, une inscription au niveau du domaine enregistré fait tomber tous les sous-domaines clients qui en dépendent.

## Partie 2 : empreintes de contenu par hachage flou (rspamd)

Le hachage flou (fuzzy hashing) détecte qu'un message est une **quasi-copie d'un spam déjà signalé**, même après que le spammeur l'a modifié. Le module `fuzzy_check` et le worker `fuzzy_storage` de rspamd en sont une implémentation ouverte entièrement documentée. Les systèmes commerciaux d'empreintes, et les réseaux d'empreintes partagées comme Razor, Pyzor et DCC, suivent les mêmes principes. rspamd fournit aussi un flux d'empreintes floues public et partagé que de nombreuses installations interrogent par défaut, si bien qu'une empreinte apprise n'importe où peut compter dans les scores partout.

### Comment l'empreinte est construite : les shingles

- Le texte du message est découpé en mots, puis en **séquences de trois mots qui se chevauchent (trigrammes)**, appelées « shingles ».
- Chaque shingle est haché avec **plusieurs fonctions de hachage (32 empreintes par shingle)**, et l'empreinte du message est l'ensemble de ces empreintes. (rspamd cite les travaux de Broder sur la ressemblance et le shingling comme fondement.)
- La comparaison est **probabiliste**. La similarité est calculée à partir du nombre et de la position des empreintes de shingles communes au message candidat et aux empreintes stockées, ce qui donne un pourcentage de correspondance plutôt qu'une égalité stricte.
- Algorithmes d'empreinte pour le texte : `mumhash` (la valeur par défaut actuelle, et recommandée), `xxhash`, `fasthash`, `siphash` (ancien). Changer d'algorithme invalide toutes les données stockées.
- **Les images et les pièces jointes sont comparées à l'identique**, et non de façon floue, au moyen d'empreintes blake2b de leur contenu. Un seul octet modifié rompt la correspondance. C'est pourquoi les campagnes de spam par images régénèrent leurs images à chaque envoi, et pourquoi les filtres combinent par ailleurs les empreintes exactes avec des empreintes perceptuelles d'images.

Principales valeurs par défaut de `fuzzy_check` : `min_bytes = 1k` (la taille minimale d'une pièce jointe ou d'une image prise en compte), `min_height/min_width = 32` px pour les images, `min_length = 0` (toutes les parties texte sont vérifiées), `text_multiplier = 4.0`, `timeout = 2s`, `retransmits = 1`. `mime_types` sélectionne les types de pièces jointes hachés (par exemple `application/*`), et `short_text_direct_hash` hache à l'identique les textes trop courts pour le shingling.

### Empreintes floues de la structure HTML (rspamd v3.14+)

Depuis la v3.14.0, rspamd peut aussi calculer l'empreinte de la **structure du DOM**, indépendamment du texte. Il utilise des jetons de la forme `tagname[.class][@domain]` (par exemple `a.button@example.com`). Seule la première classe CSS est utilisée, les classes de suivi connues sont filtrées, et les domaines des liens sont normalisés en eTLD+1.

L'empreinte combinée est pondérée ainsi : shingles de structure 50 %, **domaines des appels à l'action (CTA) 30 %**, ensemble des domaines des liens 15 %, et décomptes de caractéristiques (balises et liens) 5 %. Pour éviter de correspondre à des modèles génériques, elle exige au moins `min_html_tags` (10 par défaut ; les configurations d'exemple utilisent 15), au moins 2 liens et une profondeur de DOM d'au moins 3.

La pondération des domaines de CTA vise le phishing. Un message de phishing qui clone parfaitement le modèle d'une marque obtient une similarité de structure d'environ 0,9, mais avec des domaines de CTA différents, la similarité combinée s'effondre (l'exemple documenté : une similarité de structure de 0,9 avec des domaines de CTA non concordants donne une similarité combinée de 0,45). À l'inverse, une campagne de spam qui garde son domaine de CTA tout en remaniant son texte correspond toujours.

### Pourquoi les modifications et le bourrage de jetons ne permettent pas d'y échapper

L'empreinte est un grand ensemble d'empreintes de trigrammes de mots qui se chevauchent, comparées de façon probabiliste. Par conséquent :

- **Les petites modifications** (mots échangés, noms insérés, paragraphes réordonnés) ne changent que les shingles qui chevauchent la modification. La plupart des shingles correspondent toujours, et la similarité reste au-dessus du seuil.
- **Le bourrage de jetons** (ajout de mots aléatoires, de texte masqué ou de chaînes destinées à casser les empreintes) ajoute des shingles mais ne supprime pas ceux qui correspondent. Il ne dilue que légèrement le ratio de similarité, tandis que le nombre absolu de shingles connus comme mauvais continue de correspondre. Pour mettre en échec la correspondance par shingles, il faut réécrire pratiquement tout le corps du message, et même alors, l'empreinte de la structure HTML (v3.14+) correspond encore au modèle et au domaine de CTA inchangés.
- Les champs de fusion propres à chaque destinataire, les URL de désabonnement et les jetons de suivi laissent aussi intacte la plupart des shingles communs. C'est exactement pourquoi une campagne signalée par ses premiers destinataires est reconnue dans le reste de l'envoi.

### Poids, seuils et score progressif

Les empreintes stockées portent un **poids** qui augmente à mesure que des sources (signalements d'utilisateurs, adresses pièges touchées, pots de miel) signalent de nouveau la même empreinte. Le score est volontairement progressif, et non binaire :

- Chaque flag ou règle a un `max_score` (un seuil sur le poids de l'empreinte). En dessous du seuil, le symbole vaut 0. Le score monte ensuite du seuil jusqu'à **2× le seuil**, selon une courbe en tangente hyperbolique : ≈50 % du poids de la métrique au seuil, et le score complet à 2×. Par exemple, avec un poids de signalement de 1 et un seuil de 20, une empreinte doit recevoir ≥ 20 plaintes indépendantes avant de compter.
- Les empreintes sont organisées par **flags** numériques qui associent des catégories à des symboles. La disposition conventionnelle : le flag 1 correspond au spam confirmé (`FUZZY_DENIED`, max_score 20), le flag 2 au spam probable (`FUZZY_PROB`, max_score 10), et le flag 3 au contenu légitime placé sur liste blanche (`FUZZY_WHITE`, max_score 2). Les numéros de flag doivent être uniques parmi les règles en écriture, et `skip_hashes` place des empreintes précises sur liste blanche.
- Apprentissage : `rspamc -f <flag> -w <weight> fuzzy_add <message>` (ou `-S FUZZY_DENIED`) ajoute une empreinte, et `fuzzy_del` en supprime une. `read_only = true` rend une règle interrogeable uniquement, et une condition d'apprentissage facultative écrite en Lua peut bloquer l'apprentissage ou changer son flag.

Côté exploitation, le worker fuzzy_storage :

- a une architecture à écrivain unique, avec une file de mises à jour synchronisée sur disque tous les `sync = 1min` ;
- stocke les données dans SQLite (par défaut) ou Redis ;
- fait **expirer** les empreintes via `expire` (90d est la valeur initiale recommandée, pour que les anciennes empreintes disparaissent à mesure que les campagnes meurent) ;
- nécessite environ 400k empreintes par 100 Mo de RAM (1,5M ≈ 500 Mo) ;
- n'accepte l'apprentissage que depuis les adresses IP `allow_update` ;
- prend en charge un chiffrement facultatif du transport en Curve25519 (`encrypted_only = true`), et une réplication maître-esclave (TCP 11335) avec traduction des flags pour chaque esclave.

## Conséquences pour les expéditeurs

Ensemble, les deux mécanismes aboutissent à des règles concrètes pour quiconque exploite un ESP ou un programme d'envoi :

- **Chaque domaine présent dans le corps porte une réputation** : domaines des liens, domaines d'hébergement des images, domaines de redirection et de suivi des clics, et même les domaines écrits en texte brut. Leur réputation est évaluée séparément de celle du domaine From et de l'adresse IP d'envoi.
- **Les clients qui partagent un domaine de suivi partagent son sort.** Un domaine de suivi des clics ou d'habillage des liens utilisé dans tout un ESP réunit la réputation des destinations de tous les clients. Un seul client abusif peut le faire inscrire sur une DNSBL d'URI (la catégorie CT de SURBL existe exactement pour cela), ce qui filtre d'un coup les emails de tous les clients. Les parades sont des sous-domaines de suivi propres à chaque client sur des domaines qui appartiennent au client (via un CNAME), une surveillance proactive des domaines de suivi sur les DNSBL d'URI, et un contrôle des URL de destination auprès de SURBL, d'URIBL et de la DBL au moment de l'envoi.
- **Les raccourcisseurs publics font plus de mal que de bien.** Les filtres les résolvent de toute façon jusqu'à la destination, et le domaine du raccourcisseur porte la réputation accumulée de tous ceux qui en ont abusé. Voir [Contenu et design pour la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite).
- **Garder des domaines de liens propres est une tâche de surveillance continue**, et non une vérification ponctuelle. Interrogez multi.surbl.org (et la Spamhaus DBL) sur vos domaines de suivi, d'images et de pages de destination aussi souvent que vous vérifiez les listes de blocage d'IP, et vérifiez les URL de chaque campagne sortante avant de l'envoyer.
- **Les empreintes font peser les plaintes sur le reste de l'envoi.** Les quelques milliers de premiers destinataires qui signalent une campagne créent son empreinte floue et lui ajoutent du poids, et le reste du même envoi y correspond ensuite. Envoyer par segments avec des pauses (d'abord aux destinataires les plus engagés, en surveillant les premiers signaux de plaintes, puis en continuant) exploite directement la fenêtre de score entre le seuil et 2× le seuil.
- **Modifier un modèle ne remet pas à zéro la réputation de son contenu.** De petites modifications du texte, la rotation des lignes d'objet ou la personnalisation des champs de fusion laissent intacte l'empreinte par shingles (ainsi que l'empreinte de la structure HTML et des domaines de CTA). La seule vraie remise à zéro est un contenu réellement différent, envoyé à un public qui le souhaite. La réputation du contenu est un symptôme de la qualité de la liste, et non un problème à régler en travaillant le contenu.
- **Des domaines de CTA constants jouent dans les deux sens.** Garder vos liens sur vos propres domaines stables et bien réputés aide l'empreinte de structure à vous distinguer des clones de phishing de votre modèle. Disperser les liens sur des domaines jetables ressemble à une tentative de contournement.

## Voir aussi

- [Listes de blocage et Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus), sur le fonctionnement des DNSBL d'adresses IP et de domaines, dont la Spamhaus DBL et HBL, les autres grands jeux de données de réputation des domaines
- [Contenu et design pour la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite), avec les règles pratiques de contenu (raccourcisseurs, images, liens) que ces mécanismes expliquent
- [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation), sur la place des vérifications des domaines de suivi et de liens sur les DNSBL d'URI dans un programme de surveillance

# Ressources de la communauté et des experts de la délivrabilité

> Guide commenté des principaux sites d'experts indépendants de la délivrabilité (Word to the Wise, Spam Resource, EmailKarma) et de leur usage pour suivre l'actualité.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/ressources-communautaires-et-experts-de-la-delivrabilite

Quand vous devez savoir si quelque chose a changé cette semaine chez un fournisseur de messagerie, ou pourquoi un filtre se comporte comme il le fait, la documentation des éditeurs a rarement la réponse. Le domaine de la délivrabilité est restreint, et une grande partie de ses connaissances de terrain qui font autorité se trouve sur une poignée de blogs d'experts indépendants.

Trois d'entre eux sont les références habituelles. Voici ce qui fait la réputation de chacun, et comment les utiliser pour suivre l'actualité, comme les changements de politique des fournisseurs de messagerie, le comportement des listes de blocage et les nouvelles normes d'authentification.

## Word to the Wise (wordtothewise.com)

- **Qui** : Laura Atkins (CEO) et Steve Atkins. Laura est une vétérane reconnue de la lutte antispam, qui traque les abus sur Internet depuis des décennies. Steve couvre le versant technique et les protocoles en profondeur. Ils dirigent un cabinet de conseil (stratégie, délivrabilité, formation, mentorat) en parallèle du blog.
- **Thèmes** : l'authentification des emails (SPF, DKIM, DMARC, et des travaux émergents comme DKIM2 et BIMI), la réputation d'expéditeur, le placement en boîte de réception, la délivrabilité B2B, et l'explication du comportement technique des filtres à des interlocuteurs non techniques. Le blog est particulièrement solide sur les raisons pour lesquelles les filtres se comportent comme ils le font, et sur les fondamentaux de la permission et du consentement.
- **Ressources phares** :
  - Le blog, à `wordtothewise.com/blog/`. Ses archives remontent aux années 2000, et le reste du secteur le cite souvent.
  - Le livre blanc *Email Best Practices*, résumé dans [WttW Email Best Practices](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/word-to-the-wise-meilleures-pratiques-email).
  - Les articles explicatifs sur les adresses pièges (« A Brief Guide to Spamtraps », 2011 ; « What Spamtraps Tell Us », 2025), résumés dans [Adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges).
  - **Tools for Email People** (`tools.wordtothewise.com`) : des utilitaires pratiques pour les professionnels de l'email.
  - **AboutMy.Email** (`aboutmy.email`) : envoyez un message de test et obtenez un rapport technique détaillé sur son authentification et sa conformité aux normes.

## Spam Resource (spamresource.com)

- **Qui** : Al Iverson. Le site existe depuis plus de 24 ans et publie presque tous les jours, ce qui en fait la meilleure source unique pour les dernières nouvelles de la délivrabilité : fermetures de fournisseurs, changements de filtres, actions réglementaires et de la FTC, et acquisitions.
- **Thèmes** (d'après le plan du site, `spamresource.com/p/site-map.html`) :

| Domaine | Ressources notables |
|---|---|
| Guides de délivrabilité pour chaque fournisseur de messagerie | Gmail, Yahoo et AOL, Microsoft Outlook et Hotmail (OLC), Apple iCloud, GMX et Mail.com, Mail.de, indexés sous l'étiquette `ISP Deliverability Guides` |
| Conformité MAGY | *2025 MAGY Sender Compliance Guide* (les normes de Microsoft, Apple, Gmail et Yahoo pour les expéditeurs de gros volumes) : `/2025/04/2025-magy-sender-compliance-guide.html` |
| Données sur les domaines et l'infrastructure | Liste des domaines MAGY (`/2025/04/magy-domains-list-2025-update.html`), listes de domaines des fournisseurs de messagerie, données sur les enregistrements MX, suivi des domaines morts ou inactifs |
| Authentification | SPF, DKIM, DMARC, ARC, BIMI (y compris les fournisseurs qui prennent en charge les logos, et des guides de création de logos). Voir aussi [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) |
| **DELIVTERMS** | Une série de glossaire emblématique (« 33 DELIVTERMS and counting »), avec un billet par terme de délivrabilité, par exemple Deliverability, DKIM, Blocklists, Spamhaus, Google Postmaster Tools |
| Outils | Tutoriels sur Google Postmaster Tools, outils et classements de domaines Wombatmail, validateurs SPF, DKIM et DMARC, manuels de terrain SMTP, outils DNS |
| Conformité et droit | CAN-SPAM, LCAP (CASL), RGPD et consentement, politiques sur l'email froid |
| Plateformes précises | Astuces pour Salesforce Marketing Cloud et Pardot ; analyses d'ESP |

- **URL clés des guides par fournisseur** : Gmail `/2024/02/isp-deliverability-guide-gmail-updated.html` ; Yahoo, AOL et Verizon `/2019/12/isp-deliverability-guide-yahooaolverizon.html` ; Microsoft `/2023/04/isp-deliverability-guide-microsoft-olc.html` ; Apple iCloud `/2020/05/isp-deliverability-guide-apples-icloud.html`.
- Le site publie aussi une newsletter (inscription sur `ml.spamresource.com`).

## EmailKarma (emailkarma.net)

- **Qui** : Matt Vernhout (Pickering, Ontario, Canada), une figure de longue date de la délivrabilité et des politiques de l'email. Il est particulièrement solide sur la **réglementation canadienne (LCAP, ou CASL)** et sur le travail des organisations professionnelles.
- **Thèmes** : les connaissances en marketing par email, l'actualité du secteur, l'authentification (SPF, DKIM et DMARC), la réputation d'expéditeur, le placement en boîte de réception, et la conformité aux exigences changeantes des fournisseurs. Le site publie plusieurs billets par mois et compte plus de 50 pages d'archives.
- **Contenus récurrents** : des chroniques questions-réponses sur les questions courantes du marketing par email ; la série pédagogique « Email Deliverability Fundamentals » (par exemple des explications sur SPF) ; la couverture des grandes annonces des fournisseurs de boîtes de réception (Gmail, Yahoo, Outlook) ; des contributions invitées ; et des listes sélectionnées d'autres blogs de délivrabilité et de livres recommandés.
- Le site comprend une déclaration sur son usage de l'IA (« I use AI to help improve my writing as an editor... all the thoughts and content are mine », soit « j'utilise l'IA comme éditeur pour améliorer mes textes... toutes les idées et tout le contenu sont les miens »).

## Comment utiliser ces sources

1. **Les dernières nouvelles, du type « quelque chose a-t-il changé chez Gmail cette semaine ? »** : cherchez d'abord sur Spam Resource, qui publie presque tous les jours. Lisez ensuite Word to the Wise pour une analyse plus approfondie, puis EmailKarma, surtout pour les angles canadiens.
2. **Les exigences des fournisseurs** : les ISP Deliverability Guides de Spam Resource et son guide de conformité MAGY sont des synthèses tenues à jour et datées des exigences de Gmail, Yahoo, Microsoft et Apple envers les expéditeurs de gros volumes. Vérifiez toujours la date du billet, et privilégiez la mise à jour la plus récente.
3. **La terminologie** : la série DELIVTERMS de Spam Resource est un glossaire que vous pouvez citer pour chaque terme.
4. **Les questions conceptuelles sur le « pourquoi »** (pourquoi les filtres se comportent d'une certaine façon, comment raisonner sur la permission et le consentement, ce que signifient les adresses pièges) : Word to the Wise est la source analytique la plus solide.
5. **Le diagnostic** : orientez les expéditeurs vers AboutMy.Email (de Word to the Wise) pour un rapport technique et d'authentification sur un message, et vers Google Postmaster Tools (Spam Resource propose des tutoriels) pour les données de réputation Gmail au niveau du domaine.
6. Ce sont des blogs, donc chaque billet est un instantané daté. Pour tout ce qui dépend de la politique actuelle, vérifiez la documentation actuelle du fournisseur lui-même avant de conseiller qui que ce soit.

# Sécurité du routage et détournement d'adresses IP

> Le détournement BGP et d'adresses IP et le marché des transferts et de la location d'IPv4 comme vecteurs d'abus par email : comment les spammeurs obtiennent un espace d'adresses IP « propre » et neuf, les recherches qui chiffrent les abus sur les préfixes transférés ou loués, les observations de Spamhaus sur le détournement de réseaux, et RPKI/ROA comme parade.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/securite-du-routage-et-detournement-d-adresses-ip

Si vous acquérez ou vérifiez de l'espace d'adresses IP pour un fournisseur de services de messagerie (ESP), l'historique de cet espace compte autant que sa réputation actuelle. On aborde généralement la réputation email au niveau des adresses IP et des domaines. La couche inférieure, qui détermine qui a le droit d'annoncer une plage d'adresses IP dans la table de routage mondiale, sert elle aussi aux abus.

Les spammeurs, les hébergeurs « bulletproof » et les opérateurs de botnets ont besoin d'un approvisionnement constant en espace IPv4 **pas encore « grillé »** (inscrit sur des listes de blocage), car leurs envois consument vite la réputation. Les adresses IPv4 étant épuisées, trois moyens d'obtenir de l'espace neuf sont devenus des canaux d'abus :

- le **détournement BGP ou d'adresses IP** : annoncer un espace d'adresses qui ne vous appartient pas ;
- le **marché des transferts d'IPv4** : acheter des blocs, y compris des blocs au passé d'abus caché ;
- le **marché de la location d'IPv4** : louer des blocs au mois, ce qui dissimule l'utilisateur réel dans le WHOIS.

La parade est **la RPKI et les Route Origin Authorizations (ROA)**, qui permettent à un expéditeur légitime de prouver, et à un serveur de réception de vérifier, que le routage d'une plage est autorisé.

Pour la liste de contrôle de ce qu'il faut examiner avant d'attribuer à des clients un bloc loué ou acheté, voir [IP-Acquisition Diligence](https://emailmarketing.net/learn/esp-operations/ip-acquisition-diligence). Pour la façon dont les inscriptions qui en résultent apparaissent et sont retirées, voir [Listes de blocage et Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus) et [Inscriptions Spamhaus en détail](https://emailmarketing.net/fr/apprendre/reference/inscriptions-spamhaus-en-detail).

## Pourquoi le détournement est un problème d'email

Les spammeurs font tourner les adresses IP comme ils font tourner les domaines. Une adresse IP qui envoie du spam acquiert vite une mauvaise réputation et se fait inscrire, si bien que l'opérateur a besoin **d'adresses IP neuves et propres en permanence**. Annoncer un espace d'adresses IP qui appartient légitimement à quelqu'un d'autre, ou qui a été délaissé, répond à ce besoin sans aucune démarche auprès d'un registre qui permettrait de remonter de l'abus jusqu'à l'opérateur. L'espace volé sert à une rafale de spam ou à l'hébergement de logiciels malveillants, puis il est libéré avant ou pendant son inscription, et le cycle recommence.

C'est l'équivalent, au niveau du réseau, du [snowshoe spam](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip), qui répartit la charge finement sur de nombreuses adresses IP pour rester sous les seuils appliqués à chacune. La différence est que les adresses IP elles-mêmes sont prises sans autorisation.

Les jeux de données DROP, EDROP et ASN-DROP de Spamhaus, ainsi que le code de retour SBL DROP (`127.0.0.9`, « blocs d'adresses détournés ou loués à des spammeurs ; ne jamais les router »), existent précisément pour signaler ce phénomène (voir [Listes de blocage et Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus)).

## Comment les criminels acquièrent des plages d'adresses IP

Spamhaus recense quatre façons d'acquérir des plages. Deux sont légitimes sur le papier, et deux sont abusives :

| Voie | Fonctionnement | Où intervient l'abus |
|---|---|---|
| Attribution directe par un registre Internet régional (RIR) | Devenir membre d'un RIR et recevoir une allocation | Légitime, mais lent, et l'espace est de plus en plus rare |
| Attribution par un fournisseur d'accès | Un fournisseur en amont alloue de l'espace à un client en aval | Légitime, mais les hébergeurs bulletproof profitent des fournisseurs en amont peu attentifs |
| **Détournement de plages délaissées** | Se faire passer pour le propriétaire d'origine d'un espace dormant | Router un espace que personne ne surveille |
| **Vol temporaire de plages allouées** | Annoncer une partie de l'espace actif de quelqu'un, puis la libérer | « Rotation de routes » : envoyer du spam, puis disparaître |

### L'espace historique est la cible favorite

Les plages attribuées **avant la création de l'ARIN en 1997** (allocations « historiques », legacy) sont des cibles de choix pour le détournement. Elles représentent environ **35,9 % de tout l'espace d'adresses IPv4**. Elles ont été attribuées avant les pratiques modernes d'enregistrement, elles n'ont souvent pas de propriétaire qui paie pour elles ou qui s'en occupe, et elles **ne peuvent pas être révoquées pour défaut de paiement**. Un bloc peut donc rester dormant et oublié pendant des années, jusqu'à ce qu'un attaquant le remette en service.

### Le cas Chemstress (147.50.0.0/16) : comment se déroule un détournement

Spamhaus documente la prise de contrôle type d'un /16 dormant. Elle montre qu'un détournement est une **opération d'ingénierie sociale contre le registre**, et pas seulement une astuce technique avec BGP :

| Date | Étape |
|---|---|
| 2011-08-19 | Enregistrer un domaine ressemblant qui utilise le nom du contact ARIN d'origine |
| 2011-12-12 | Persuader l'ARIN, par l'ingénierie sociale, de remplacer les coordonnées du bloc par celles de l'attaquant |
| 2011-12-16 | Commencer des annonces de routes BGP non autorisées pour le /16 |
| 2012-06-10 | Remplacer l'adresse de l'entreprise par celle d'un service de réexpédition du courrier |

Une fois la fiche du registre falsifiée, l'annonce de route frauduleuse paraît autorisée à tout réseau qui ne vérifie que le WHOIS.

## Combattre les abus en bordure de réseau

Spamhaus préconise de bloquer le trafic malveillant au **niveau du routage, sur les routeurs de bordure** (via BGP), plutôt que d'attendre une détection au niveau applicatif (SMTP ou HTTP). Il nomme ces schémas d'abus :

- **Les systèmes autonomes malveillants.** Des acteurs malveillants exploitent leur propre système autonome (AS) et annoncent des routes via BGP. Les chaînes de systèmes autonomes compromis sont fréquentes, et les criminels exploitent les relations de type **« client d'un client »** pour qu'aucun fournisseur en amont ne se sente responsable.
- **L'acceptation des routes sans vérification.** Les fournisseurs en amont propagent souvent des routes malveillantes pendant **des mois**, faute d'une vérification suffisante et en raison de « processus automatisés configurés pour accepter, presque aveuglément, tout ce que les clients annoncent ».
- **L'interconnexion directe pour rester invisible.** Des groupes criminels s'interconnectent directement avec un fournisseur cible et maintiennent leurs réseaux hors de la table de routage mondiale, afin que les outils de surveillance des routes ne les détectent pas.

**Parades que Spamhaus recommande aux opérateurs de réseau :**

- Déployer les listes **DROP, EDROP et ASN-DROP** sur les routeurs de bordure pour refuser la connectivité aux réseaux dont on sait qu'ils sont criminels.
- **Vérifier les routes qu'annoncent vos clients BGP.** Examinez l'historique d'abus et de routage d'un client avant d'accepter ses routes, et surveillez la **rotation de routes** : annoncer, envoyer du spam, retirer.
- Adopter **BGP Flowspec (RFC 5575 et RFC 7674)** pour pousser en temps réel des listes de contrôle d'accès (ACL) dynamiques vers les équipements de bordure. Par exemple, injecter via Flowspec les données de la **BCL** (Botnet Controller List) pour mettre en trou noir les serveurs de commande et de contrôle des botnets, une adresse IP à la fois.
- Faire travailler ensemble les équipes réseau et les équipes antiabus, qui travaillent généralement en silos séparés.

Pour donner un ordre de grandeur, Spamhaus indique que ses DNSBL protègent environ **2,7 milliards de boîtes aux lettres**, qu'il a été fondé en 1998, et qu'il compte environ **30 enquêteurs dans 9 pays**. La liste BCL reste petite, mais elle s'agrandit.

## Le marché des transferts d'IPv4 comme canal d'abus

Quand vous achetez un bloc sur le marché secondaire, vous achetez peut-être un passé d'abus caché, ou le vendeur est peut-être un abuseur récidiviste qui se débarrasse d'un espace grillé. Giotsas, Livadariu et Gigis (**PAM 2020**, « A first look at the misuse and abuse of the IPv4 Transfer Market ») l'ont mesuré sur une décennie de transferts (du 2009-10-12 au 2019-08-24). Ils ont combiné des listes de blocage d'adresses IP, des données de pots de miel, la détection de détournements de préfixes et des listes de réputation d'AS :

| Constat | Valeur |
|---|---|
| Préfixes routés transférés avec au moins 1 signalement sur une liste de blocage | **environ 40 %** |
| Préfixes routés non transférés avec au moins 1 signalement sur une liste de blocage | **6 %** |
| Probabilité d'inscription sur une liste de blocage, sous-préfixes /24 transférés par rapport aux non transférés | **6× plus probable** |
| Espace transféré dans son ensemble, selon le type d'abus | **4× à 25× plus susceptible** d'être inscrit sur une liste de blocage |
| Transferts dont la date ou l'organisation destinataire déclarées **ne concordaient pas** avec le WHOIS et le routage BGP | **plus de 65 %** |
| Préfixes transférés couverts par un ROA avec un **ASN d'origine incohérent** | **6 %** |
| Taux d'espace inscrit sur des listes de blocage pour les systèmes autonomes qui sont **à la fois acheteurs et vendeurs**, par rapport à ceux qui n'ont qu'un rôle | **2× plus élevé** |

Le calendrier révèle un **contournement délibéré des filtres**. Les signalements sur les listes de blocage **culminent dans l'année qui suit** la date du transfert, pour tous les types d'activité malveillante (spam, phishing, logiciels malveillants, commande et contrôle de botnets, détournement de préfixes, scans non sollicités, contenus illicites). L'abus apparaît après le transfert même quand l'espace d'adresses était utilisé et visible des scans **au moins un mois avant** celui-ci.

Le déséquilibre persiste après exclusion de l'espace légitime des fournisseurs de cloud et des très grands réseaux (AWS, Google Cloud), dont les services d'infrastructure sont détournés pour des machines virtuelles éphémères de logiciels malveillants. **Les auteurs de détournements BGP récidivistes et les hébergeurs bulletproof sont surreprésentés** parmi les acteurs du marché. Les auteurs présentent ces chiffres comme une **borne inférieure**, car les transactions non déclarées n'apparaissent jamais dans les bases des RIR.

## Le marché de la location d'IPv4 : un canal plus récent, invisible dans le WHOIS

La location consiste à louer un bloc pour une durée pouvant descendre à un mois, le préfixe restant enregistré au nom du bailleur. Elle est moins transparente que l'achat. Comme le RIR ne traite aucun transfert, **l'identité du locataire n'est jamais enregistrée dans le WHOIS**. L'utilisateur réel du bloc d'adresses est masqué, et les plaintes pour abus et les notifications de vulnérabilités ne lui parviennent pas. Les acteurs malveillants s'en servent pour **faire tourner rapidement des blocs « propres » et jeter ceux qui ont servi**, contournant ainsi l'inscription des adresses IP sur les listes de blocage.

Degen et al. (**TMA 2025**, University of Twente / CAIDA, « From Scarcity to Opportunity: Examining Abuse of the IPv4 Leasing Market ») ont comparé les préfixes loués et non loués sur 82 jours (de décembre 2024 à mars 2025) à l'aide des listes de blocage FireHOL :

| Constat | Valeur |
|---|---|
| Préfixes loués inscrits (FireHOL Level 1) par rapport aux préfixes non loués, instantané de février 2025 | **2,89× plus probable** (0,518 % contre une moyenne de 0,179 %) |
| La même comparaison sur l'ensemble agrégé complet, plus large, de 253 listes de blocage | **1,84× plus probable** (32,0 % contre 17,4 %) |
| Prévalence des services d'anonymisation (VPN et proxys) dans l'espace loué par rapport à l'espace non loué | **2,59× plus fréquents** |
| Hausse des inscriptions de catégorie `abuse` **30 jours** après le début de la location | **+60,2 %** |
| Hausse des inscriptions de catégorie `abuse` **150 jours** après le début de la location | jusqu'à **+269 %** |
| Hausse des inscriptions de catégorie `malware` **150 jours** après le début de la location | **+37,9 %** |

Les inscriptions des préfixes loués étaient **stables avant le début de la location, puis ont augmenté régulièrement** tout au long de la période de mesure. C'est la signature d'un bloc qui reste propre jusqu'à ce qu'un locataire commence à en abuser. Le chiffre Level 1 (2,89×) est un minimum prudent, et celui de l'ensemble étendu de listes est une limite supérieure.

**La taille du marché (TMA 2025).** Plus de **6 184 transferts** portant sur **30,2 millions d'adresses** ont eu lieu en 2024. Un seul courtier a déclaré **757 transferts pour 60,7 millions de dollars US**. Les adresses IPv4 servent désormais de garantie de prêt : une entreprise a émis **206 millions de dollars US** d'obligations garanties par ses actifs IPv4. Les délais d'attente auprès des RIR en février 2025 étaient de **498 jours au RIPE NCC, 615 jours à l'ARIN et 1 417 jours au LACNIC**. C'est cette pénurie qui pousse d'abord les opérateurs vers les marchés secondaire et de la location.

Fait notable, **certains courtiers proposent désormais la gestion RPKI, le « parking » de préfixes (annonce d'un préfixe depuis l'AS du courtier), des services de réputation d'adresses IP et le retrait de liste en tant que service** comme prestations complémentaires. Ce sont des usages légitimes des mêmes outils que ceux qu'exploitent les abuseurs.

**Ce que cela signifie pour les opérateurs.** Un bloc loué ou transféré a statistiquement plus de chances d'être sale qu'un espace routé choisi au hasard, et son historique est plus difficile à voir. Vérifier la réputation avant d'acquérir un bloc n'est pas facultatif : examinez son historique sur les listes de blocage, ses enregistrements SWIP et WHOIS antérieurs, et SenderScore et Talos (voir [IP-Acquisition Diligence](https://emailmarketing.net/learn/esp-operations/ip-acquisition-diligence)).

## RPKI et ROA : la parade

La **RPKI (Resource Public Key Infrastructure)** utilise la cryptographie pour lier des préfixes IP aux numéros d'AS autorisés à les émettre, afin que les réseaux puissent rejeter les fausses annonces de routes. La validation de l'origine est actuellement la **seule** fonction de la RPKI utilisée en exploitation.

### Route Origin Authorization (ROA)

Un ROA est un objet signé, publié par le détenteur légitime de la ressource, qui contient trois champs (RFC 6482) :

| Champ | Signification |
|---|---|
| **Préfixe** | Le bloc d'adresses IP autorisé |
| **Numéro d'AS d'origine** | L'unique AS autorisé à émettre ce préfixe dans BGP |
| **maxLength** | La longueur de préfixe la plus spécifique que l'AS peut annoncer |

Par exemple, un ROA pour `192.0.1.0/24` avec un **maxLength de /25** autorise l'annonce de ce `/24` ou de ses deux `/25` adjacents, mais **rien de plus spécifique**. Limiter le maxLength bloque le détournement classique, dans lequel l'attaquant annonce un sous-préfixe plus spécifique (que BGP préfère toujours) pour détourner le trafic.

### États de la Route Origin Validation (ROV)

Un routeur compare chaque annonce BGP à l'ensemble des **Validated ROA Payloads (VRP)** et lui attribue l'un de trois états :

| État | Condition | Action type |
|---|---|---|
| **Valid** | Le préfixe et l'AS d'origine sont couverts par au moins 1 VRP, dans la limite du maxLength | Accepter |
| **Invalid** | Mauvais AS d'origine, ou plus spécifique que ce qu'autorise le maxLength | Rejeter, ou donner une préférence plus faible à la route |
| **NotFound** (inconnu) | Aucun VRP ne couvre le préfixe (aucun ROA n'est publié) | Accepter (ouvert par défaut) |

L'espace sans ROA aboutit à l'état **NotFound**, et non Invalid, si bien que la RPKI ne protège que les préfixes dont le détenteur légitime a publié un ROA. C'est l'action directe pour un expéditeur qui veut un espace propre : **publiez des ROA pour vos plages d'envoi**. L'annonce de votre espace par un pirate, plus spécifique ou avec la mauvaise origine, est alors évaluée **Invalid** et écartée par les réseaux qui appliquent la ROV, et l'infrastructure de routage d'un serveur de réception traite vos propres annonces comme autorisées.

Cela vous protège aussi en tant qu'acheteur. Le constat de PAM 2020 selon lequel **6 % des préfixes transférés couverts par un ROA avaient un ASN d'origine incohérent** est exactement le type d'incohérence que la ROV fait apparaître.

La documentation RPKI note que **la grande majorité des détournements de routes sont involontaires**, dus à des erreurs de saisie de l'origine ou à des fuites de routes. Une large couverture ROA rend les erreurs d'origine, accidentelles comme malveillantes, **faciles à repérer et à rejeter**.

### Au-delà de la validation de l'origine

- **BGPsec (RFC 8205)** valide tout le chemin d'AS, et pas seulement l'origine, mais son déploiement réel « pourrait s'avérer limité ».
- **ASPA (Autonomous System Provider Authorization)** est un travail à l'état de projet sur la validation des chemins, une voie médiane émergente entre la ROV, qui ne vérifie que l'origine, et BGPsec complet.

## À retenir pour un ESP

1. L'espace d'adresses IP neuf est une marchandise pour les spammeurs. Le détournement, l'achat et la location sont autant de moyens de l'obtenir, et tous trois laissent des traces mesurables sur les listes de blocage.
2. **Les blocs loués ont 1,84 à 2,89 fois, et les blocs transférés 4 à 25 fois, plus de chances d'être sales** qu'un espace routé choisi au hasard, et la location masque délibérément l'opérateur dans le WHOIS. Vérifiez un bloc avant de l'attribuer (voir [IP-Acquisition Diligence](https://emailmarketing.net/learn/esp-operations/ip-acquisition-diligence)).
3. **Publiez des ROA** pour vos préfixes d'envoi. Un détournement de votre espace devient alors Invalid chez les réseaux qui appliquent la ROV, et cela montre que l'exploitation est rigoureuse. Avant d'acquérir un bloc, vérifiez que son ROA et son origine sont cohérents.
4. Les listes DROP, EDROP et ASN-DROP de Spamhaus, et la BCL (éventuellement via BGP Flowspec), vous permettent de refuser en bordure de votre propre réseau le trafic des réseaux dont on sait qu'ils sont criminels.

# Typologie des abus par email

> La couche de classification des articles sur les abus : une entrée par type d'abus, avec sa définition, sa victime, les signaux de détection visibles par un ESP, l'acteur type (client intentionnel, client compromis ou tiers externe) et l'article de la base de connaissances qui prend en charge la réponse.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/typologie-des-abus-par-email

Quand un signalement d'abus arrive à votre service, la première tâche est de le classer : **de quel type d'abus s'agit-il, qui en est la victime, et qui en est l'acteur ?** Ces trois réponses déterminent la procédure à suivre.

Chaque entrée ci-dessous définit un type d'abus, nomme sa victime, liste les signaux de détection visibles du côté de l'ESP (et non de celui du serveur de réception), identifie l'acteur type et renvoie aux recommandations pour la réponse. Pour les priorités de tri et la boucle de remédiation elle-même, voir [Abuse Desk Operations](https://emailmarketing.net/learn/esp-operations/abuse-desk).

## L'axe de l'acteur

Un même symptôme sortant, du spam qui s'échappe de vos adresses IP, a quatre causes très différentes, et chacune demande une réponse différente. Se tromper d'acteur est l'erreur de tri la plus coûteuse :

| Catégorie d'acteur | Description | Posture de réponse |
|---|---|---|
| **Client intentionnel** | Le titulaire du compte est l'auteur de l'abus : il s'est inscrit pour abuser, ou il y a glissé peu à peu | Sanctionner : suspendre ou résilier. Les comptes frauduleux n'ont **ni récupération de données ni avertissement préalable** ([Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk)) |
| **Client compromis** | Un compte légitime sous le contrôle d'un attaquant (par des identifiants, une clé d'API ou un système de gestion de contenu piraté) | Rétablir : contenir l'abus, rendre le compte à son propriétaire et le protéger contre une nouvelle compromission ([Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts)) |
| **Client négligent (intermédiaire)** | Le client n'envoie pas d'abus, mais l'un de ses actifs mal protégés (un formulaire, un script, un achat de listes peu regardant) fait de lui un vecteur | Former le client et imposer des contrôles. Passer à la sanction s'il refuse de corriger le problème |
| **Externe** | L'attaquant ne touche jamais à un compte client. Il abuse de votre marque, de vos signatures ou de formulaires tiers depuis l'extérieur | Surveiller, signaler et faire retirer. L'infrastructure de l'ESP peut être la victime, et non la source |

Ce qui distingue les deux premiers est un **historique d'utilisation légitime antérieure**, le test qui permet de distinguer les comptes compromis des comptes malveillants dans [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts#compromised-vs-malicious-accounts). Analysez soigneusement les indicateurs avant de présumer du mécanisme : ce qui ressemble à une compromission est souvent un abus d'inscription à une offre d'essai, et l'inverse est vrai aussi.

## Tableau récapitulatif

| Type d'abus | Victime principale | Principaux signaux côté ESP | Acteur type | Recommandations pour la réponse |
|---|---|---|---|---|
| [Spam / UBE](#spam--ube) | Les destinataires, et la réputation partagée de l'ESP | Pics de plaintes et de rapports de feedback loop (FBL), adresses pièges touchées, inscriptions sur des listes de blocage, pics de rebonds | Client intentionnel ou négligent | [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk) · [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting) |
| [Phishing (y compris spear phishing et BEC)](#phishing-y-compris-le-spear-phishing-et-le-bec) | La marque usurpée et les destinataires escroqués | URL hostiles dans le contenu, avis de retrait de signaleurs de confiance ou de marques, correspondances sur les listes de phishing de DBL et de SURBL | Client intentionnel (inscription frauduleuse) ou client compromis | [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk) (P2) · [Réputation des URL et empreintes de contenu](https://emailmarketing.net/fr/apprendre/reference/reputation-des-url-et-empreintes-de-contenu) |
| [Usurpation de marque et domaines sosies](#usurpation-de-marque-et-domaines-sosies) | La marque et ses clients | Rapports DMARC montrant des sources non autorisées, et tentatives d'inscription avec des domaines sosies lors de la vérification | Externe (ou inscription frauduleuse qui utilise le domaine sosie) | [Protection de la marque](https://emailmarketing.net/fr/apprendre/reference/protection-de-la-marque-gestion-des-domaines) · [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) |
| [Snowshoeing](#snowshoeing-ip-et-domaine) | Les filtres et les serveurs de réception, et l'espace d'adresses IP de l'ESP | Un client qui demande de nombreuses adresses IP ou de nombreux domaines, des identités tournantes, des inscriptions CSS | Client intentionnel | [Inscriptions Spamhaus en détail](https://emailmarketing.net/fr/apprendre/reference/inscriptions-spamhaus-en-detail) · [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting) |
| [Bombardement d'inscriptions](#bombardement-dinscriptions-list-bombing--subscription-bombing) | Une boîte de réception ciblée | Rafales d'inscriptions vers une même adresse ou un même domaine sur toute la plateforme, avalanches d'emails de confirmation | Externe, via les formulaires de clients négligents | [Subscription Bombing](https://emailmarketing.net/learn/esp-operations/subscription-bombing) |
| [Distribution de logiciels malveillants et de rançongiciels](#distribution-de-logiciels-malveillants-et-de-rançongiciels) | Les machines des destinataires | Détections lors de l'analyse des pièces jointes, inscriptions de logiciels malveillants sur SURBL, avis urgents de signaleurs de confiance | Client compromis ou inscription frauduleuse | [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk) (P2) · [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) |
| [Fraude 419, avance de frais et autres contenus frauduleux](#fraude-419-avance-de-frais-et-autres-contenus-frauduleux) | Les destinataires (financièrement) | Heuristiques de contenu, faible volume avec un envoi de style messagerie web, texte des plaintes | Client intentionnel (inscription frauduleuse) ou compte compromis (« voyageur en détresse ») | [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk) · [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) |
| [Backscatter](#génération-de-backscatter) | Les titulaires des adresses falsifiées, et l'ESP qui renvoie les rebonds | Rebonds sortants vers des adresses auxquelles vous n'avez jamais écrit, inscriptions de type Backscatterer | Personne : c'est une erreur de configuration, et un spammeur externe fournit les adresses falsifiées | [Abuse Desk : backscatter](https://emailmarketing.net/learn/esp-operations/abuse-desk#backscatter) |
| [Rejeu DKIM](#rejeu-dkim) | Le domaine signataire (celui du client ou de l'ESP) | Plaintes ou blocages pour des messages dont vous n'avez aucune trace d'envoi, et un même identifiant de message vu à une échelle massive par les serveurs de réception | Externe (il suffit d'un seul message signé) | [DKIM Replay Attacks](https://emailmarketing.net/fr/apprendre/authentification/attaques-par-rejeu-dkim) |
| [Prise de contrôle de compte / envoi compromis](#prise-de-contrôle-de-compte--envoi-compromis) | Le client, puis tous ceux qui partagent l'infrastructure | Une rupture avec le comportement habituel du compte : nouvelle zone géographique ou nouvel user-agent, volume soudain, nouveaux contenus ou destinataires | Client compromis | [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) |
| [Abus de clés d'API](#abus-de-clés-dapi) | Le client, et les pools partagés | Envois inhabituels par l'API sans connexion au tableau de bord, renseignements sur des clés divulguées, une nouvelle intégration d'API juste avant un pic d'adresses pièges touchées ou de plaintes | Client compromis (identifiant divulgué) | [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) · [Spam-Trap Incident Response](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response) |
| [Spam d'affiliation](#spam-daffiliation) | Les destinataires, la marque de l'annonceur et la réputation de l'ESP | Réponses lors de la vérification (programmes gérés par des tiers), contenu chargé de redirecteurs, taux de plaintes très supérieurs à ceux des propres flux du client | Client intentionnel ou négligent (via ses affiliés) | [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting) · [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement) |
| [Email froid / prospection sans consentement](#email-froid--prospection-sans-consentement) | Les destinataires, et la réputation de l'ESP | Envois en masse par petits lots « personnalisés », listes B2B achetées, volume délibérément réparti entre comptes ou domaines | Client intentionnel (qui se présente souvent comme légitime) | [Position du M3AAWG sur l'email froid](https://emailmarketing.net/fr/apprendre/reference/position-du-m3aawg-sur-l-email-froid) |
| [Collecte d'adresses / scraping](#collecte-dadresses--scraping) | Les titulaires des adresses, puis quiconque écrit à la liste | Visible avant l'envoi par l'ESP : listes importées pleines de comptes de rôle, d'adresses pièges et d'adresses invalides | Collecteur externe, avec un client intentionnel ou négligent comme acheteur | [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement) · [Adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges) |
| [Relais ouvert / abus de proxy](#relais-ouvert--abus-de-proxy) | Tout l'écosystème de réception, et l'opérateur du relais | Trafic de tiers qui passe par l'infrastructure du client, inscriptions SBL ou XBL des hôtes du client | Abuseur externe qui exploite l'erreur de configuration d'un client négligent | [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) · [Listes de blocage et Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus) |
| [SMS et messagerie : abus par ricochet](#sms-et-messagerie--abus-par-ricochet) | Les destinataires des messages sur l'autre canal | Abus scriptés des fonctions qui envoient des messages web vers des SMS ou des notifications, volume inhabituel pour une seule fonction | Externe, par script, ou compte compromis | [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) (éléments du Web Messaging BCP) |

## Spam / UBE

**Définition** (Spamhaus) : **Unsolicited Bulk Email** (email non sollicité envoyé en masse). *Non sollicité* signifie que le destinataire n'a pas accordé de permission vérifiable. *En masse* signifie que le message fait partie d'un ensemble plus large de messages substantiellement identiques. Les deux conditions doivent être réunies : « le spam est une question de consentement, pas de contenu ». Le spam est la catégorie mère. La plupart des autres types listés ici sont du spam assorti d'une caractéristique aggravante, comme la tromperie, un logiciel malveillant ou la fraude.

- **Victime** : les destinataires. Comme les ESP sont jugés sur l'ensemble de leur trafic, tous les autres clients qui partagent les mêmes adresses IP ou domaines sont aussi des victimes ([Multi-Tenant Architecture](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture)).
- **Signaux côté ESP** : pics du taux de plaintes FBL, [adresses pièges touchées](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges), hausse des rejets et des reports de remise chez les grands serveurs de réception, [inscriptions sur des listes de blocage](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus), et profils de rebonds inhabituels lors de l'import d'une liste. Pour les seuils et les mesures correctives, voir [Indicateurs et valeurs de référence](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite).
- **Acteur** : un client intentionnel (listes achetées, pas de consentement) ou un client négligent (une hygiène de base de données qui s'est dégradée). Distinguez-le d'une compromission en comparant avec le comportement habituel du compte.
- **Réponse** : la boucle de remédiation du [service abus](https://emailmarketing.net/learn/esp-operations/abuse-desk) : valider le signalement, notifier le client en citant les conditions d'utilisation, corriger, suspendre, résilier. Prévenez-le par la [vérification des clients](https://emailmarketing.net/learn/esp-operations/customer-vetting). Pour les incidents déclenchés par des adresses pièges, voir [Spam-Trap Incident Response](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response).

## Phishing (y compris le spear phishing et le BEC)

**Définition** : des emails qui se font passer pour un tiers de confiance afin de voler des identifiants, des données de paiement ou de l'argent. Le **spear phishing** vise des personnes précises avec des prétextes documentés. La **compromission de la messagerie en entreprise (BEC, business email compromise)**, telle que la décrit l'Internet Crime Complaint Center (IC3) du FBI, en est l'extrémité la plus sophistiquée : l'attaquant se fait passer pour un salarié, un fournisseur ou un dirigeant (par usurpation d'identité, par des domaines sosies ou via une boîte réellement compromise) pour déclencher des virements frauduleux. L'Anti-Phishing Working Group (APWG) la décrit comme l'usurpation de l'identité d'un tiers de confiance pour amener un salarié à envoyer de l'argent ou des actifs sensibles. Le BEC ne comporte souvent aucune URL ni pièce jointe malveillante. C'est de l'ingénierie sociale pure, que les filtres de contenu ne peuvent pas intercepter.

- **Victime** : deux victimes, la marque usurpée (atteinte à sa réputation et difficultés DMARC) et le destinataire escroqué.
- **Signaux côté ESP** : des URL hostiles ou trompeuses dans le contenu des clients (correspondances sur la liste de phishing de SURBL, ou sur Spamhaus DBL et HBL ; voir [Réputation des URL et empreintes de contenu](https://emailmarketing.net/fr/apprendre/reference/reputation-des-url-et-empreintes-de-contenu)), et des avis de retrait émis par des sociétés de protection des marques et des signaleurs de confiance. Côté hébergement, cherchez des kits de phishing sur les sites des clients : le Hosting Abuse BCP note que le phishing passe presque toujours par des comptes d'utilisateurs finaux compromis dotés de scripts obsolètes. Le BEC pur transite rarement par un ESP en volume, car il est ciblé et à faible volume. Les campagnes de phishing d'identifiants visant vos propres clients, menées pour préparer des prises de contrôle de compte, y transitent en revanche bel et bien.
- **Acteur** : une inscription frauduleuse (intentionnelle) ou un compte ou un site client compromis. L'acteur est externe quand seule votre marque est imitée (voir l'entrée suivante).
- **Réponse** : P2 dans les [niveaux de priorité du service abus](https://emailmarketing.net/learn/esp-operations/abuse-desk#complaint-priority-tiers-hosting-abuse-bcp), car les activités malveillantes passent avant le spam. Suspendez immédiatement le mécanisme d'envoi, puis déterminez si le compte est compromis ou frauduleux. Le phishing qui vise vos clients pour récolter leurs identifiants de l'ESP alimente [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts).

## Usurpation de marque et domaines sosies

**Définition** : un attaquant externe envoie des emails au nom d'une marque sans toucher à l'infrastructure de la marque. L'attaquant usurpe soit le domaine exact (une adresse From falsifiée, que met en échec une politique [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) contraignante), soit utilise des **domaines cousins ou sosies** (fautes de frappe, termes ajoutés comme « -login », autres domaines de premier niveau). Un domaine sosie s'authentifie parfaitement en son propre nom, et passe donc DMARC sans difficulté.

- **Victime** : la marque et ses destinataires. L'ESP est aussi victime quand sa propre marque, ou les domaines de ses clients, sont imités pour hameçonner des identifiants.
- **Signaux côté ESP** : des rapports agrégés DMARC de clients qui montrent des sources non autorisées ([Rapports agrégés DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc)), des inscriptions qui utilisent, lors de la vérification, des domaines sosies de marques connues (un signe classique d'inscription frauduleuse ; voir [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting)), et des alertes de surveillance de la transparence des certificats et des enregistrements de domaines.
- **Acteur** : externe. Dans la variante que voit un ESP, un client frauduleux enregistre le domaine sosie et vous demande de l'authentifier. C'est pourquoi les contrôles d'[authentification des domaines clients](https://emailmarketing.net/learn/esp-operations/customer-domain-authentication) ont leur place dans l'intégration des nouveaux clients.
- **Réponse** : [Protection de la marque et gestion des domaines](https://emailmarketing.net/fr/apprendre/reference/protection-de-la-marque-gestion-des-domaines) couvre l'inventaire des domaines, l'enregistrement défensif, la surveillance et les procédures de retrait. Une politique DMARC contraignante traite l'usurpation du domaine exact.

## Snowshoeing (IP et domaine)

**Définition** (Spamhaus) : répartir finement le spam sur **de nombreuses adresses IP et de nombreux domaines** pour diluer la réputation de chaque identité et rester sous les seuils des filtres. Il utilise « des plages et des domaines à l'identification médiocre ou changeant fréquemment », et le spammeur utilise les adresses IP légitimement (ce ne sont pas des botnets). La variante par domaine fait tourner de la même façon des domaines fraîchement enregistrés.

- **Victime** : les filtres et les serveurs de réception, que le spammeur contourne. L'ESP est aussi victime, car son espace d'adresses IP et ses outils de délégation de domaines sont accaparés, tout comme ses autres clients quand des inscriptions CSS touchent des plages partagées.
- **Signaux côté ESP** : lors de la vérification, des prospects qui demandent un nombre inhabituellement élevé d'adresses IP ou de domaines d'envoi pour leur volume, des enregistrements WHOIS anonymisés, de nombreux ESP précédents, et le moindre indice d'un changement d'infrastructure pour échapper à une inscription (un signal d'alerte explicite du [Vetting BCP](https://emailmarketing.net/learn/esp-operations/customer-vetting)). En exploitation, des changements fréquents de domaine, des envois qui s'arrêtent et reprennent pour répartir les indicateurs entre plateformes, et des inscriptions [Spamhaus CSS](https://emailmarketing.net/fr/apprendre/reference/inscriptions-spamhaus-en-detail#css--combined-spam-sources-127003) (« de nombreux domaines changeant fréquemment constituent en soi le signal »).
- **Acteur** : un client intentionnel, par définition. Le snowshoeing est une organisation délibérée, jamais un accident.
- **Réponse** : voir [Inscriptions Spamhaus en détail](https://emailmarketing.net/fr/apprendre/reference/inscriptions-spamhaus-en-detail) pour le fonctionnement de l'inscription et le retrait de liste. Résiliez plutôt que de corriger, car une opération de snowshoeing n'a aucune configuration légitime à restaurer. Prévenez-le par la vérification et par un modèle de droits par paliers, dans lequel les nouveaux comptes n'obtiennent pas de grands ensembles d'adresses IP ou de domaines.

## Bombardement d'inscriptions (list bombing / subscription bombing)

**Définition** : une attaque par déni de service (DoS) contre une boîte de réception. Un script soumet l'adresse de la victime à des milliers de formulaires d'inscription non protégés, et l'avalanche d'emails légitimes de confirmation et de bienvenue noie la boîte, souvent afin de masquer des notifications de fraude.

- **Victime** : le titulaire de la boîte ciblée. Les victimes secondaires sont les propriétaires des formulaires (leurs listes sont empoisonnées et reçoivent des soumissions d'adresses pièges) et l'ESP (Spamhaus a inscrit des adresses IP d'envoi d'ESP lors de la vague de 2016).
- **Signaux côté ESP** : des taux d'inscription inhabituels vers une même adresse ou un même domaine à travers les formulaires de nombreux clients de la plateforme, des avalanches de messages de confirmation vers une même adresse, et un démarrage brutal, sans montée progressive.
- **Acteur** : un attaquant externe. Les clients dont les formulaires ne sont pas protégés sont des intermédiaires négligents.
- **Réponse** : [Subscription Bombing & Signup-Form Abuse](https://emailmarketing.net/learn/esp-operations/subscription-bombing) donne la procédure complète : signatures de détection, exigences de CAPTCHA et d'opt-in confirmé (COI), suppression de chaque adresse ciblée pendant une attaque, et coordination au sein du secteur.

## Distribution de logiciels malveillants et de rançongiciels

**Définition** : des emails qui livrent des charges malveillantes, soit en pièces jointes (droppers, documents à macros), soit par des liens vers des sites qui hébergent des exploits ou des téléchargements. Cela inclut la diffusion de rançongiciels et le recrutement dans des botnets.

- **Victime** : les machines et les organisations des destinataires. La réputation de l'ESP s'effondre vite, car la distribution de logiciels malveillants déclenche les réactions les plus sévères des serveurs de réception et des listes de blocage.
- **Signaux côté ESP** : des détections lors de l'analyse des pièces jointes sortantes à la recherche de logiciels malveillants (le Web Messaging BCP recommande de restreindre les types de fichiers qui peuvent être téléversés et de les analyser), des correspondances sur les listes de logiciels malveillants de SURBL ou sur Spamhaus HBL pour les domaines liés, et des avis urgents de signaleurs de confiance et d'équipes d'intervention en cas d'urgence informatique (CERT). Côté hébergement, cherchez des logiciels malveillants déposés sur les sites des clients (P2 dans les niveaux de priorité de l'hébergement).
- **Acteur** : rarement un client d'ESP délibéré, car les outils des ESP grand public sont un mauvais canal pour les logiciels malveillants (les pièces jointes sont limitées et le contenu est inspecté). En général, l'acteur est un site ou un compte client compromis, ou une inscription frauduleuse qui abuse de l'envoi en offre gratuite.
- **Réponse** : P2 dans le [service abus](https://emailmarketing.net/learn/esp-operations/abuse-desk). Arrêtez immédiatement les envois, sans délai de correction pour le trafic lui-même. Déterminez ensuite si le compte est compromis ou frauduleux, comme le décrit [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts). Pour la détection dans le contenu, voir [Réputation des URL et empreintes de contenu](https://emailmarketing.net/fr/apprendre/reference/reputation-des-url-et-empreintes-de-contenu).

## Fraude 419 (avance de frais) et autres contenus frauduleux

**Définition** : des fraudes où le contenu lui-même constitue le délit. Il s'agit par exemple de la fraude à l'avance de frais (appelée « 419 », d'après l'article du code pénal nigérian sur la fraude), qui promet des gains importants contre un paiement préalable ; des arnaques à la loterie et à l'héritage ; des fraudes aux faux emplois et au trop-perçu ; des arnaques sentimentales qui se développent dans la durée ; et de l'appel du « voyageur en détresse », envoyé depuis un compte piraté à ses propres contacts.

- **Victime** : les destinataires, financièrement. Le volume est généralement faible par rapport au spam en masse (UBE). Ce qui rend ce type grave, c'est le préjudice que chaque message peut causer.
- **Signaux côté ESP** : des heuristiques de contenu et des signatures de filtrage anciennes (ces arnaques existent depuis des décennies et leur formulation change à peine), un texte de plainte qui décrit l'arnaque, et des comptes à faible volume qui envoient des messages de style personnel à des destinataires dispersés. Pour la variante du voyageur en détresse, cherchez un compte établi qui écrit soudain à toute sa liste de contacts.
- **Acteur** : une inscription frauduleuse intentionnelle, ou un compte compromis pour les variantes personnalisées. Le [Compromised User ID BCP](https://emailmarketing.net/learn/esp-operations/compromised-accounts#containment-and-remediation-compromised-user-id-bcp) classe les arnaques du voyageur en détresse dans la catégorie « identifiant permanent, exploitation personnalisée », qui exige toujours une intervention humaine.
- **Réponse** : tri par le [service abus](https://emailmarketing.net/learn/esp-operations/abuse-desk). Les signalements de fraude peuvent aussi arriver par les forces de l'ordre, et ils passent avant le spam dans la file d'attente. Les comptes frauduleux sont résiliés sans les étapes de courtoisie.

## Génération de backscatter

**Définition** : des rebonds mal dirigés. Un serveur accepte un message portant une adresse de retour falsifiée, puis envoie le rebond à cette adresse innocente, au lieu de rejeter le message pendant la session SMTP. En volume, ces rebonds constituent eux-mêmes du spam en masse (UBE), et l'opérateur qui les envoie est inscrit sur des listes de blocage.

- **Victime** : les titulaires des adresses falsifiées (souvent les vrais utilisateurs d'une marque usurpée), puis l'ESP qui génère les rebonds, par les listes de blocage spécialisées dans le backscatter et par l'atteinte à sa réputation.
- **Signaux côté ESP** : des notifications d'état de livraison (DSN) ou des réponses automatiques sortantes vers des adresses auxquelles vous n'avez jamais livré de messages, des plaintes du type « des rebonds pour des emails que je n'ai jamais envoyés », et des inscriptions sur des DNSBL qui ciblent le backscatter.
- **Acteur** : aucun au sens habituel. Le backscatter est une **erreur de configuration** : accepter un message puis le renvoyer en rebond plus tard, des répondeurs automatiques sans garde-fous, ou des systèmes de challenge-response. Le spammeur externe qui falsifie les adresses de vos clients fournit le déclencheur, mais ne touche jamais à vos systèmes.
- **Réponse** : [Abuse Desk : backscatter](https://emailmarketing.net/learn/esp-operations/abuse-desk#backscatter) décrit les contre-mesures : rejeter pendant la session SMTP, Bounce Address Tag Validation (BATV), supprimer les rebonds en fonction de SPF, et nettoyer la file d'attente. Pour le fonctionnement des rebonds, voir [DSN](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison).

## Rejeu DKIM

**Définition** : un attaquant obtient un seul message portant une signature DKIM légitime (par exemple via une offre d'essai gratuite ou une confirmation d'inscription envoyée à une boîte qu'il contrôle) et le renvoie tel quel à des millions de destinataires. Chaque copie porte une signature valide, si bien que la réputation du domaine `d=` est dépensée pour des messages que ce domaine n'a jamais envoyés à ces destinataires.

- **Victime** : le domaine signataire. C'est l'ESP lui-même quand les clients signent avec des domaines que l'ESP partage entre eux, ou sinon le propre domaine du client. Les destinataires sont les victimes secondaires du spam.
- **Signaux côté ESP** : l'anomalie caractéristique est une **atteinte à la réputation sans trace d'envoi correspondante**. Vous recevez des plaintes et des blocages pour des messages, des destinataires ou des volumes absents de vos journaux, vous voyez un même Message-ID à une échelle massive dans les retours des serveurs de réception, ou vous voyez la réputation du domaine s'effondrer sur un flux dont les propres indicateurs semblent sains.
- **Acteur** : externe. L'attaquant n'a besoin de recevoir qu'un seul message signé, et une inscription à une offre gratuite suffit. C'est pourquoi le rejeu est précisément une attaque contre les ESP qui proposent des essais en libre-service.
- **Réponse** : [DKIM Replay Attacks](https://emailmarketing.net/fr/apprendre/authentification/attaques-par-rejeu-dkim) couvre les contre-mesures et leurs compromis : un `x=` court, des sélecteurs et des clés distincts pour chaque flux, la sursignature, et des contrôles sur les comptes d'essai. L'hygiène des clés est traitée dans [DKIM Key Rotation](https://emailmarketing.net/fr/apprendre/authentification/rotation-des-cles-dkim). La vérification des inscriptions aux essais limite l'accès de l'attaquant à des messages fraîchement signés ([Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting)).

## Prise de contrôle de compte / envoi compromis

**Définition** : un compte client légitime entièrement ou partiellement sous contrôle non autorisé (un « compte utilisateur compromis » selon les termes du Compromised User ID BCP). L'attaquant l'utilise pour envoyer du spam, du phishing ou des fraudes en profitant de la réputation acquise par le client et de l'infrastructure de l'ESP.

- **Victime** : d'abord le client (sa réputation, ses données et ses contacts), puis tous les locataires qui partagent ses adresses IP ou ses domaines, puis les destinataires.
- **Signaux côté ESP** : une **rupture avec le comportement habituel du compte lui-même**. Par exemple, des connexions depuis de nouvelles zones géographiques ou depuis des lieux trop éloignés pour qu'on puisse passer de l'un à l'autre, des user-agents inconnus, des changements soudains de volume ou de l'ensemble des destinataires, de nouveaux types de contenu, des messages envoyés supprimés, et des réglages de transfert ou de reply-to modifiés. D'autres signaux sont une hausse brutale des plaintes FBL sur un compte à l'historique sain, et des renseignements issus de fuites d'identifiants qui mentionnent des adresses email de clients.
- **Acteur** : un client compromis, par définition. Le test de l'historique d'utilisation légitime antérieure distingue ce cas de l'abus à l'inscription.
- **Réponse** : [Compromised Accounts & Outbound Abuse](https://emailmarketing.net/learn/esp-operations/compromised-accounts) couvre tout le cycle de vie : sources de détection, contre-mesures pour les quatre types de compromission, réauthentification forcée des utilisateurs, et gestion des compromissions répétées. Les signalements arrivent souvent par le [service abus](https://emailmarketing.net/learn/esp-operations/abuse-desk). Pour le fonctionnement des FBL, voir [Complaint Feedback Loops](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes).

## Abus de clés d'API

**Définition** : des envois abusifs réalisés avec des identifiants d'API volés ou divulgués plutôt que par une connexion interactive. Les clés peuvent avoir été publiées dans des dépôts publics, récupérées sur des serveurs clients compromis, ou hameçonnées. L'abus de clés d'API est un sous-type de prise de contrôle de compte (ATO) avec son propre profil de détection. Il est traité à part parce que le trafic d'API échappe aux anomalies de connexion sur lesquelles repose l'essentiel de la détection des prises de contrôle. Cette distinction reflète la pratique des plateformes d'envoi (recommandations de sécurité des éditeurs sur la révocation des clés divulguées, et analyse des secrets du type de celle que propose GitHub), et non une catégorie formellement définie par le M3AAWG.

- **Victime** : le client titulaire de la clé, et l'infrastructure partagée.
- **Signaux côté ESP** : des envois par l'API sans activité correspondante sur le tableau de bord, de nouvelles adresses IP ou de nouveaux ASN sources sur le chemin de l'API, des notifications d'analyse des secrets (clés divulguées dans des dépôts publics), et une intégration d'API nouvelle ou modifiée juste avant un pic d'adresses pièges touchées ou de plaintes. [Spam-Trap Incident Response](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response#4-re-vetting-the-customer) cite explicitement ce dernier signal comme une raison de vérifier à nouveau le client. Des profils de volume sans rapport avec l'historique de l'intégration sont un autre signal.
- **Acteur** : un client compromis (identifiant divulgué). Distinguez ce cas d'un client intentionnel qui scripte des abus avec sa propre clé, ce qui est du spam ordinaire envoyé par une API.
- **Réponse** : [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts). Cela applique le modèle « identifiant temporaire ou permanent » aux identifiants machine. Révoquez immédiatement la clé (une réinitialisation du mot de passe ne suffit pas, car la clé survit aux changements de mot de passe), émettez des clés de remplacement à portée limitée, et auditez ce que la clé a touché. Pour prévenir cet abus sur toute la plateforme, donnez aux nouveaux comptes des droits par paliers, avec un accès à l'API restreint tant que l'ancienneté et la réputation n'en justifient pas davantage ([Customer Vetting, fraud-prevention practices](https://emailmarketing.net/learn/esp-operations/customer-vetting#fraud-prevention-practices-hosting-abuse-bcp)), et appliquez des limites pour chaque locataire afin de contenir les dégâts ([Multi-Tenant Architecture](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture)).

## Spam d'affiliation

**Définition** : du spam envoyé par des affiliés tiers qui font la promotion de l'offre d'un client ou d'un annonceur contre commission. L'annonceur peut être parfaitement légitime. L'abus vient d'affiliés dont personne n'a vérifié les listes ni les méthodes. Le Vetting BCP désigne cette catégorie comme une source historique d'abus, et note que les programmes qu'une entreprise gère elle-même sont plus risqués que ceux gérés par des réseaux tiers réputés.

- **Victime** : les destinataires (qui n'ont jamais consenti à recevoir des messages de l'expéditeur réel), la marque de l'annonceur, et l'ESP si les emails des affiliés ou le trafic vers les pages promues touchent son infrastructure. Le « spamvertising sur le réseau » a sa propre ligne dans les niveaux de priorité des abus d'hébergement.
- **Signaux côté ESP** : des réponses lors de la vérification qui reconnaissent des programmes d'affiliation, un contenu chargé de redirecteurs et de chaînes de suivi qui aboutissent à des offres tierces ([Réputation des URL et empreintes de contenu](https://emailmarketing.net/fr/apprendre/reference/reputation-des-url-et-empreintes-de-contenu) traite des redirecteurs), des taux de plaintes et d'adresses pièges touchées très supérieurs à ceux des flux du même client vers sa propre liste, et des inscriptions Spamhaus DBL des domaines promus, même quand vos adresses IP d'envoi restent propres.
- **Acteur** : un client intentionnel (qui achète sciemment du trafic généré par du spam) ou un client négligent (qui gère un programme sans contrôler ses affiliés). Les affiliés eux-mêmes sont extérieurs à la relation avec l'ESP, et c'est précisément ce vide de responsabilité qui rend la catégorie dangereuse.
- **Réponse** : [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting) (examen renforcé lors de l'intégration, et questions sur la gestion du programme). [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement) explique pourquoi les listes d'affiliés produisent des profils de plaintes proches de ceux des listes achetées. Faites appliquer les règles par la boucle habituelle du service abus, et tenez le client responsable de ses affiliés.

## Email froid / prospection sans consentement

**Définition** (M3AAWG, novembre 2025) : des emails non sollicités envoyés par des expéditeurs *par ailleurs légitimes et identifiables*, qui cherchent à nouer une relation d'affaires avec des destinataires **sans relation, lien ni consentement préalable**. Ils sont envoyés avec des tactiques trompeuses pour imiter des emails individuels : petits lots aléatoires, domaines sosies ou jetables, et une authentification techniquement valide qui sert de camouflage. La position du M3AAWG est que l'email froid livré de manière trompeuse **est du spam**.

Les *Sender Best Common Practices* du M3AAWG (version 4.0, août 2026, section 4.5) résument la position de façon plus large : elles présentent l'email froid comme abusif sans la réserve sur la livraison trompeuse, et renvoient à la prise de position pour le détail complet.

- **Victime** : les destinataires, et l'ESP. Les opérations d'email froid répartissent délibérément le volume entre comptes, sous-domaines et fournisseurs pour éviter la détection. Elles consomment la réputation partagée et, à l'échelle des comptes, ressemblent beaucoup au snowshoeing.
- **Signaux côté ESP** : de nombreux petits envois « personnalisés » construits sur le même modèle, des listes B2B achetées ou collectées par scraping (comptes de rôle, aucune preuve d'opt-in), la création rapide de domaines ou de sous-comptes, des intégrations d'outils d'envoi vendus pour des « séquences outbound », et des taux de plaintes modestes en valeur absolue mais extrêmes au regard du volume.
- **Acteur** : un client intentionnel, généralement sincèrement convaincu que ses messages sont légitimes. C'est pourquoi la [position du M3AAWG](https://emailmarketing.net/fr/apprendre/reference/position-du-m3aawg-sur-l-email-froid) existe : elle donne aux services abus une réponse de consensus du secteur à l'argument « mais ce n'est pas du spam, c'est de la prospection commerciale ».
- **Réponse** : [Position du M3AAWG sur l'email froid](https://emailmarketing.net/fr/apprendre/reference/position-du-m3aawg-sur-l-email-froid) expose l'argumentaire sur la définition et les indicateurs de détection. L'application des règles relève de la politique (une interdiction dans la politique d'utilisation acceptable, et un filtrage lors de la vérification), via [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting) et le [service abus](https://emailmarketing.net/learn/esp-operations/abuse-desk). Pour comprendre pourquoi le consentement ne peut pas être transféré, voir [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement).

## Collecte d'adresses / scraping

**Définition** : la collecte d'adresses email sans consentement, en explorant des sites web, en faisant du scraping de plateformes et de fuites de données, ou en générant des adresses à partir de dictionnaires, pour constituer ou vendre des listes. L'abus que rencontre un ESP vient ensuite : un client qui écrit à une liste collectée.

- **Victime** : les titulaires des adresses, puis le client qui écrit à la liste et l'ESP. Les listes collectées sont pleines de [pièges vierges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges) (placés précisément pour attraper les collecteurs), d'adresses invalides et de comptes de rôle.
- **Signaux côté ESP** : à l'import de la liste, une forte proportion de comptes de rôle, des répartitions de domaines invraisemblables, et aucune métadonnée d'opt-in. Au premier envoi, des taux élevés de rebonds définitifs accompagnés de pièges vierges touchés. Cette combinaison est la signature, car les pièges vierges indiquent presque exclusivement des données collectées ou achetées. Un autre signal est un client incapable de produire une preuve d'opt-in pour des adresses que vous contrôlez par sondage (la [technique d'audit utilisée lors des incidents d'adresses pièges](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response#investigating-opt-in-claims)).
- **Acteur** : le collecteur est externe. L'acteur auquel l'ESP doit faire face est le client intentionnel ou négligent qui a acheté ou collecté la liste.
- **Réponse** : [Méthodes de consentement](https://emailmarketing.net/fr/apprendre/gestion-des-listes/methodes-de-consentement) place la collecte d'adresses tout en bas de l'éventail des méthodes d'acquisition, et toutes les politiques d'utilisation acceptable l'interdisent. [Adresses pièges](https://emailmarketing.net/fr/apprendre/reference/adresses-pieges) et [Spam-Trap Incident Response](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response) couvrent l'incident qui la révèle. CAN-SPAM aggrave les sanctions pour l'envoi à des listes collectées ([CAN-SPAM](https://emailmarketing.net/fr/apprendre/conformite/loi-can-spam-etats-unis)).

## Relais ouvert / abus de proxy

**Définition** : des tiers font transiter des emails par une infrastructure qui ne devrait pas les relayer pour eux. Le cas classique est un serveur SMTP qui accepte les messages de n'importe qui vers n'importe qui (un **relais ouvert**). Les équivalents modernes sont les proxys ouverts, les scripts de messagerie web ou PHP-mailer piratés, et les instances cloud mal configurées qui relaient sans authentification.

- **Victime** : tout l'écosystème de réception, car le relais masque l'origine de l'abus, et l'opérateur du relais, dont les adresses IP sont inscrites. Spamhaus les inscrit sur la SBL ou la XBL, et la PBL existe précisément parce que l'espace d'adresses IP des utilisateurs finaux ne devrait pas envoyer de messages directement aux serveurs MX ([Listes de blocage et Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus)).
- **Signaux côté ESP** : c'est surtout une catégorie qui concerne les hébergeurs. Cherchez des serveurs virtuels ou dédiés de clients qui envoient des messages n'ayant jamais transité par le chemin de soumission de l'ESP, des anomalies d'analyse de trafic lors des autoanalyses du réseau, des inscriptions sur des listes de blocage des adresses IP des hôtes clients, et des plaintes qui attribuent des messages à une infrastructure client que le client ne reconnaît pas.
- **Acteur** : un abuseur externe qui exploite l'erreur de configuration ou les logiciels non mis à jour d'un client négligent. C'est le scénario central du Hosting Abuse BCP, dans lequel les systèmes de gestion de contenu et les scripts obsolètes sont la principale voie de compromission.
- **Réponse** : le socle de prévention des abus chez les hébergeurs dans [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) (obligations contractuelles de mise à jour, pare-feu applicatifs web (WAF), et une plage d'adresses IPv6 distincte pour chaque client afin que les blocages puissent être précis), la boucle de remédiation du [service abus](https://emailmarketing.net/learn/esp-operations/abuse-desk), et le fonctionnement du retrait de liste dans [Inscriptions Spamhaus en détail](https://emailmarketing.net/fr/apprendre/reference/inscriptions-spamhaus-en-detail).

## SMS et messagerie : abus par ricochet

**Définition** : l'abus des fonctions de messagerie autres que l'email sur des plateformes proches de l'email, comme les passerelles du web vers les SMS, les envois de cartes électroniques et d'invitations, les fonctions « partager cet article », les systèmes de notifications et de commentaires dans les applications, et les API REST de messagerie. Le Web Messaging BCP du M3AAWG traite ces fonctions et la messagerie web comme une seule surface d'attaque. Toute fonction qui relaie un contenu fourni par un utilisateur à un destinataire qu'il choisit sera scriptée pour du spam dès que le filtrage sur le chemin de l'email en fait le canal le moins coûteux.

- **Victime** : les destinataires sur l'autre canal. Le spam par SMS coûte plus cher et est plus intrusif, message par message, que l'email, et les opérateurs sanctionnent sévèrement la plateforme. Les relations de la plateforme avec les opérateurs et les agrégateurs jouent le rôle que jouent les listes de blocage pour l'email.
- **Signaux côté ESP** : un volume inhabituel pour une seule fonction (messages envoyés, invitations émises) par rapport aux références de ressources auditées que prescrit le Web Messaging BCP, des schémas d'abus d'inscription qui alimentent la fonction, des charges utiles identiques sur de nombreux comptes, et des messages courts chargés d'URL.
- **Acteur** : externe, par des inscriptions scriptées, ou des comptes compromis. Les acteurs sont les mêmes que pour les abus par email : le canal change, mais la procédure non.
- **Réponse** : [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts). Les trois couches de défense du Web Messaging BCP (accès à l'interface utilisateur, filtrage du contenu et contrôles de diffusion) ont été écrites exactement pour cette surface. Appliquez des limites de débit à « presque tous les services web qui acceptent ou relaient du contenu généré par les utilisateurs ». Les régimes de conformité côté opérateurs (par exemple l'enregistrement 10DLC aux États-Unis) sortent du périmètre email de cette référence. L'entrée figure ici parce que l'abus arrive par les mêmes comptes et les mêmes formulaires que ceux que surveille le versant email.

## Utiliser la typologie

Pour un signalement qui n'a pas encore été classé, suivez cette séquence :

1. Identifiez le type d'abus à partir des signaux ci-dessus.
2. Placez-le dans les [niveaux de priorité du service abus](https://emailmarketing.net/learn/esp-operations/abuse-desk#complaint-priority-tiers-hosting-abuse-bcp). Les contenus pédopornographiques (CSAM) et les menaces passent avant tout, et les activités malveillantes (phishing, logiciels malveillants) passent avant le spam.
3. Déterminez la catégorie d'acteur avant de choisir entre rétablissement et sanction. Les étapes de courtoisie que vous devez à un client compromis sont exactement celles que vous devez refuser à un client frauduleux.
4. Transmettez le dossier aux recommandations propres à ce type.

Plusieurs types surviennent souvent ensemble : une prise de contrôle de compte qui mène au phishing, une collecte d'adresses qui mène au spam puis à un incident d'adresses pièges, ou une inscription frauduleuse qui mène au snowshoeing. Classez le dossier selon le mécanisme que vous devez neutraliser, et non selon le contenu que vous avez observé.

# Valeurs de référence de la délivrabilité (données chiffrées)

> Des tableaux de valeurs de référence datés et attribués à leur éditeur : taux de boîte de réception, de spam et de messages manquants mesurés par listes de test de Validity, par fournisseur, pays, région et secteur ; taux d'engagement par secteur de Marigold et Freshworks ; chiffres d'adoption et de maturité des expéditeurs de Sinch.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/valeurs-de-reference-chiffrees-de-la-delivrabilite

Si vous voulez savoir si votre taux de boîte de réception est normal, quel taux d'ouverture observe votre secteur ou combien d'expéditeurs ont DMARC, les chiffres ci-dessous donnent les réponses publiées. Ils proviennent de rapports d'éditeurs : ce sont donc **des repères indicatifs, pas une vérité de terrain**. Servez-vous-en pour juger si votre programme se situe à peu près dans la norme, jamais comme un objectif à manipuler ni comme une promesse de ce que vous obtiendrez.

Pour ce que ces indicateurs signifient et les seuils qui appellent une action, voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite). Pour la façon dont le placement et l'engagement sont mesurés, et pour le biais de chaque méthode, voir [Méthodologie de mesure du placement](https://emailmarketing.net/fr/apprendre/operations/methodologie-de-mesure-du-placement) et [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure). La mesure n'est pas réexpliquée ici.

## Comment lire chaque chiffre de cette page (garde-fous)

1. **Chaque chiffre est daté et attribué.** Une valeur de référence sans année et sans éditeur ne vaut rien : passez votre chemin. Tous les chiffres ci-dessous portent les deux.
2. **Ne mélangez jamais les données de listes de test de Validity avec les données d'enquête de Sinch.** Elles mesurent des choses différentes, par des méthodes différentes :
   - Les chiffres de **Validity** mesurent le placement à l'aide d'adresses de test : des boîtes de test indiquent si le message a atteint la boîte de réception, est parti en spam ou a disparu. Cela montre où les messages sont arrivés, mais sans aucun engagement de vrais destinataires ([Méthodologie de mesure du placement](https://emailmarketing.net/fr/apprendre/operations/methodologie-de-mesure-du-placement) recense les faiblesses structurelles des données de listes de test).
   - Les chiffres de **Marigold et Freshworks** sont des taux d'engagement (ouvertures, clics, désabonnements) calculés sur de vrais envois. **L'engagement n'est pas le placement.** Un taux d'ouverture élevé ne prouve pas que les messages ont atteint la boîte de réception, et les deux mesures sont gonflées ou faussées par les effets décrits dans [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure) (Apple Mail Privacy Protection, clics des scanners de sécurité). Les valeurs de référence des taux d'ouverture antérieures et postérieures à MPP ne sont pas comparables.
   - Les chiffres de **Sinch** sont les réponses à une enquête dans laquelle des expéditeurs décrivent leurs propres pratiques. Ils sont sujets au biais de sélection (les répondants sont des clients d'ESP) et aux erreurs de déclaration. Ils décrivent ce que les expéditeurs disent faire, et non des résultats mesurés.
3. **Indicatifs, pas des références absolues.** Chaque éditeur mesure sa propre clientèle avec sa propre méthode. Les taux absolus varient d'une année à l'autre et diffèrent entre des rapports qui mesurent « la même » chose. Les relations entre les chiffres durent plus longtemps que les pourcentages exacts : Microsoft est plus exigeant que Gmail, Apple est le pire en placement, la finance fait moins bien que l'immobilier, et l'engagement varie d'environ 2x selon les secteurs.
4. **Aucun chiffre inventé.** Seuls les chiffres imprimés dans les rapports sources figurent ici. Quand un rapport donne une fourchette ou une réserve, elle est reproduite.

---

## 1. Valeurs de référence du placement en boîte de réception : Validity (listes de test, 2022)

**Source :** Validity, *2023 Email Deliverability Benchmark*.

**Méthode :** données de listes de test. Les clients de Validity Everest envoient des campagnes à des adresses de test réparties chez des centaines de fournisseurs de messagerie et de filtres anti-spam dans le monde. Un logiciel enregistre si chaque message a atteint la boîte de réception, est parti en spam ou a disparu, et les résultats sont regroupés dans l'Everest Mailbox Provider Community.

**Période :** le rapport est daté de 2023, mais les données de placement portent sur **l'année civile 2022** (« les taux de placement en boîte de réception étaient juste en dessous de 85 pour cent en 2022 »). Seuls les expéditeurs qui ont accepté le regroupement de leurs données sont inclus, et les chiffres sont un instantané.

Trois indicateurs sont utilisés d'un bout à l'autre :

- **Taux de placement en boîte de réception (IPR) :** les messages livrés en boîte de réception, divisés par l'ensemble des messages envoyés.
- **Taux de placement en spam :** les messages livrés dans le dossier spam ou courrier indésirable, divisés par l'ensemble des messages envoyés.
- **Taux de messages manquants :** les messages acceptés puis reportés ou bloqués, qui ne sont jamais arrivés ni en boîte de réception ni en spam.

Comparez avec le « taux de livraison » qu'affichent les ESP. Validity situe le taux de rebonds moyen cumulé (définitifs et temporaires) des programmes fondés sur la permission à **environ 1,5 %**, si bien que le taux « livré » qu'affiche un ESP est d'environ 98,5 %. Ce chiffre ne mesure que l'acceptation, pas le placement.

### Monde

| Indicateur | Taux |
|---|---|
| Boîte de réception | **84,8 %** |
| Spam | 6,1 % |
| Manquant | 9,1 % |

À retenir : environ **1 sur 6** des emails marketing légitimes et fondés sur la permission n'a jamais atteint la boîte de réception (15,2 % sont partis en spam ou ont disparu), et environ **1 sur 10** n'a pas été accepté du tout.

### Par fournisseur de messagerie mondial (MAGY et Apple)

« MAGY » désigne Microsoft, AOL, Gmail et Yahoo. L'IPR cumulé de MAGY était de **86 %**, au-dessus de la moyenne mondiale. Gmail était le plus performant des fournisseurs mondiaux et Microsoft le plus difficile, tandis qu'Apple faisait nettement moins bien que tous les autres.

| Fournisseur | Boîte de réception | Spam | Manquant |
|---|---|---|---|
| **Gmail** | 88,1 % | 3,8 % | 8,1 % |
| **Yahoo** (AOL compris) | 87,4 % | 3,8 % | 8,8 % |
| **Microsoft** (Outlook et Hotmail) | 82,5 % | 6,6 % | 10,9 % |
| **Apple** (iCloud et me.com) | 66,3 % | 22,9 % | 10,8 % |

Validity attribue le faible IPR d'Apple, et son taux de spam environ 3x supérieur à la moyenne, en grande partie à la difficulté de mesurer l'engagement depuis **Mail Privacy Protection (MPP)** : les expéditeurs qui se fient aux ouvertures finissent par écrire à des listes moins réactives. Le chiffre d'Apple concerne les abonnés sur des domaines Apple, mais l'effet va plus loin, car de nombreux utilisateurs de Gmail, Microsoft et Yahoo lisent leurs emails dans Apple Mail (voir [Apple iCloud Mail : exigences postmaster](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/apple-icloud-mail-exigences-postmaster) et [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure)).

### Parts de marché des fournisseurs de messagerie (part d'une liste type)

| Fournisseur | Part de marché relative |
|---|---|
| Gmail | 47 % |
| Yahoo | 17 % |
| Microsoft | 16 % |
| AOL | 6 % |
| Autres | 14 % |

MAGY détient **87 %** de la part de marché relative (« sept emails sur huit »). Au moins environ 75 % d'une liste type se trouve chez ces quatre fournisseurs, qui n'en font en pratique que trois, puisque Yahoo et AOL forment une seule entreprise.

### Par pays (9)

| Pays | Boîte de réception | Spam | Manquant |
|---|---|---|---|
| **Allemagne** | 97,8 % | 0,3 % | 1,9 % |
| **Chine** | 92,7 % | 3,6 % | 3,7 % |
| **Canada** | 90,0 % | 3,9 % | 6,1 % |
| **Royaume-Uni** | 89,8 % | 2,2 % | 8,0 % |
| **Australie** | 89,7 % | 2,4 % | 7,9 % |
| **France** | 88,7 % | 2,0 % | 9,3 % |
| **Brésil** | 86,9 % | 6,6 % | 6,5 % |
| **États-Unis** | 84,6 % | 6,3 % | 9,1 % |
| **Inde** | 68,9 % | 5,7 % | 25,4 % |

L'interprétation de Validity : les pays les plus performants (Allemagne, Canada) ont des régimes de consentement stricts (le double opt-in est la norme en Allemagne, et le Canada a la LCAP). Les États-Unis sont à la traîne parce que l'autorisation y repose encore surtout sur l'opt-out. Le taux très élevé de messages manquants en Inde reflète la fréquence des escroqueries par email et une moindre qualité des données. La carte mondiale du rapport indique 69,8 % pour l'Inde, tandis que la page de détail par pays donne la répartition complète de 68,9 % / 5,7 % / 25,4 % utilisée ici.

### Par région

Chaque région a un chiffre global (tous fournisseurs, MAGY compris) et un chiffre **limité aux fournisseurs régionaux** (hors MAGY). Les fournisseurs régionaux filtrent davantage selon des règles que selon l'engagement, et leur chiffre est systématiquement inférieur au chiffre global.

| Région | Global boîte de réception | Global spam | Global manquant | Régionaux seuls boîte de réception | Régionaux seuls spam | Régionaux seuls manquant |
|---|---|---|---|---|---|---|
| **Europe** | 91,0 % | 2,0 % | 7,0 % | 80,2 % | 9,9 % | 9,9 % |
| **Amérique latine** | 87,4 % | 6,4 % | 6,2 % | 81,1 % | 3,8 % | 15,1 % |
| **Amérique du Nord** | 84,6 % | 6,3 % | 9,1 % | 87,9 % | 3,0 % | 9,1 % |
| **Asie-Pacifique** | 78,2 % | 3,6 % | 17,2 % | voir la répartition ci-dessous | | |

L'Europe était la région la plus performante (91 %), et l'Asie-Pacifique la moins performante (78 %). L'Asie-Pacifique se scinde nettement :

| Sous-groupe Asie-Pacifique (fournisseurs régionaux, hors MAGY) | Boîte de réception | Spam | Manquant |
|---|---|---|---|
| Fournisseurs d'Australie et de Nouvelle-Zélande | 90,6 % | 1,1 % | 8,3 % |
| Fournisseurs asiatiques (hors Océanie) | 58,0 % | 8,5 % | 33,5 % |

Les principaux fournisseurs régionaux cités pour chaque région : **Amérique du Nord** : AT&T, Comcast, Charter, Bell, Shaw, Telmex. **Amérique latine** : BOL, Terra, UOL. **Europe** : Alice, BT Mail, GMX, Orange, Virgin Media, T-Online. **Asie-Pacifique** : Telstra/Bigpond, QQ (Tencent), 126 (Netease).

### Par secteur (15 secteurs)

Les secteurs ont été attribués à l'aide de ZoomInfo, et un secteur devait compter au moins 10 clients pour figurer dans le tableau.

| Secteur | Boîte de réception | Spam | Manquant |
|---|---|---|---|
| Immobilier | 97,1 % | 0,8 % | 2,1 % |
| Médias et Internet | 94,9 % | 1,9 % | 3,2 % |
| Voyage et hôtellerie | 94,5 % | 2,6 % | 2,9 % |
| Sociétés holding | 91,6 % | 3,5 % | 4,9 % |
| Construction | 90,9 % | 3,3 % | 5,8 % |
| Santé | 89,8 % | 6,9 % | 3,3 % |
| Services aux consommateurs | 89,7 % | 4,3 % | 6,0 % |
| Éducation | 89,5 % | 4,6 % | 5,9 % |
| Logiciels | 89,1 % | 2,7 % | 8,2 % |
| Commerce de détail | 87,7 % | 2,4 % | 9,9 % |
| Industrie manufacturière | 84,7 % | 3,3 % | 12,0 % |
| Organisations à but non lucratif | 83,5 % | 5,9 % | 10,6 % |
| Services aux entreprises | 83,4 % | 7,0 % | 9,6 % |
| Télécommunications | 80,8 % | 8,4 % | 10,8 % |
| Finance et assurance | 80,0 % | 8,4 % | 11,6 % |

Les services aux entreprises, les télécommunications et la finance et l'assurance étaient les moins performants, avec un taux cumulé de spam et de messages manquants en moyenne environ 33 % au-dessus de la valeur de référence mondiale. L'immobilier arrivait en tête avec 97,1 %.

### B2B : plateforme d'hébergement et passerelle de filtrage

Le courrier B2B passe par une **plateforme d'hébergement** et souvent aussi par une **passerelle de filtrage tierce** distincte. Cela fait deux couches, et chacune peut envoyer le message en spam ou le bloquer. Les IPR B2B sont inférieurs à ceux du B2C, avec des taux de messages manquants nettement plus élevés. Validity note que le placement en boîte de réception B2B **pourrait descendre jusqu'à 68 %** quand on considère ensemble la plateforme d'hébergement et l'application de filtrage.

**Part mondiale de l'hébergement B2B** (95 % des emails marketing B2B vont vers Google Workspace ou Microsoft 365) :

| Plateforme d'hébergement | Part |
|---|---|
| Microsoft Office 365 | 48 % |
| Google Workspace (« Google Apps ») | 47 % |
| Autres | 5 % |

**Placement mondial sur les plateformes d'hébergement :** boîte de réception **79,6 %**, spam 4,1 %, manquants **16,3 %**.

**Part mondiale des passerelles de filtrage :**

| Passerelle | Part |
|---|---|
| Proofpoint | 46 % |
| Barracuda | 15 % |
| Mimecast | 15 % |
| Cisco Email Security | 13 % |
| Autres | 11 % |

**Placement mondial sur les passerelles de filtrage :** boîte de réception **84,9 %**, spam 4,6 %, manquants 10,5 % (proche des moyennes mondiales). Voir [Délivrabilité B2B et passerelles de messagerie d'entreprise](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/delivrabilite-vers-les-passerelles-b2b) pour la façon dont ces passerelles filtrent, réécrivent les liens et gèrent les retraits de liste.

---

## 2. Valeurs de référence de l'engagement par secteur

**Ces chiffres mesurent l'engagement, pas le placement.** Les ouvertures, les clics et les désabonnements sont calculés sur de vrais envois. Ils sont faussés par Apple MPP (qui gonfle les ouvertures), par les clics des scanners de sécurité et des robots, et par les faux négatifs quand les images sont désactivées (voir [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure)). Traitez-les comme un contexte approximatif pour vous comparer à vos pairs au sein d'un mélange d'audiences stable, et non comme des indicateurs de placement. Les deux éditeurs ci-dessous sont présentés dans des **tableaux séparés et attribués**, car ils utilisent des listes de secteurs et des méthodes différentes. Ne les fusionnez pas et n'en faites pas la moyenne.

### Marigold (Campaign Monitor by Marigold), 18 secteurs

**Source :** Marigold, *The Essential Guide to Deliverability* : « Campaign Monitor by Marigold a analysé des milliards d'emails ». Les indicateurs sont le taux d'ouverture, le taux de clics (CTR), le taux de clics par ouverture (CTOR) et le taux de désabonnement. Marigold cite Litmus pour le retour sur investissement (ROI) de l'email, de **36 $ pour 1 $**, et donne un CTR moyen de « 2,3 % toutes régions confondues ».

| Secteur | Ouverture | Clics | Clics par ouverture | Désabonnement |
|---|---|---|---|---|
| Publicité et marketing | 20,5 % | 1,8 % | 9,0 % | 0,2 % |
| Agriculture, sylviculture, pêche, chasse | 27,3 % | 3,4 % | 12,5 % | 0,3 % |
| Biens de consommation courante | 20,0 % | 1,9 % | 11,1 % | 0,1 % |
| Éducation | 28,5 % | 4,4 % | 15,7 % | 0,2 % |
| Services financiers | 27,1 % | 2,4 % | 10,1 % | 0,2 % |
| Restauration, alimentation et boissons | 18,5 % | 2,0 % | 10,5 % | 0,1 % |
| Administration et politique | 19,4 % | 2,8 % | 14,3 % | 0,1 % |
| Services de santé | 23,7 % | 3,0 % | 13,4 % | 0,3 % |
| Informatique, technologie et logiciels | 22,7 % | 2,0 % | 9,8 % | 0,2 % |
| Logistique et commerce de gros | 23,4 % | 2,0 % | 11,7 % | 0,3 % |
| Médias, divertissement, édition | 23,9 % | 2,9 % | 12,4 % | 0,1 % |
| Organisations à but non lucratif | 26,6 % | 2,7 % | 10,2 % | 0,2 % |
| Autres | 19,9 % | 2,6 % | 13,2 % | 0,3 % |
| Services professionnels | 19,3 % | 2,1 % | 11,1 % | 0,2 % |
| Immobilier, design, construction | 21,7 % | 3,6 % | 17,2 % | 0,2 % |
| Commerce de détail | 17,1 % | 0,7 % | 5,8 % | 0,1 % |
| Voyage, hôtellerie, loisirs | 20,2 % | 1,4 % | 8,7 % | 0,2 % |
| Bien-être et remise en forme | 19,2 % | 1,2 % | 6,0 % | 0,4 % |
| **Moyennes globales** | **21,5 %** | **2,3 %** | **10,5 %** | **0,1 %** |

### Freshworks, 12 secteurs

**Source :** Freshworks, *Email Deliverability Best Practices*, « données compilées à partir de plusieurs rapports sectoriels ». Aucune période de mesure n'est indiquée : considérez donc les chiffres comme non datés. Les indicateurs sont le taux d'ouverture, le taux de clics, les rebonds définitifs, les rebonds temporaires et les désabonnements. À cause des colonnes de rebonds, ce tableau est en partie une valeur de référence de la qualité des listes, et pas seulement de l'engagement.

| Secteur | Ouverture | Clics | Rebonds définitifs | Rebonds temporaires | Désabonnement |
|---|---|---|---|---|---|
| Agriculture et services alimentaires | 23,1 % | 3,1 % | 0,40 % | 0,61 % | 0,23 % |
| Beauté et soins personnels | 16,5 % | 1,8 % | 0,25 % | 0,32 % | 0,30 % |
| Informatique et électronique | 21,4 % | 2,1 % | 0,45 % | 0,80 % | 0,27 % |
| E-commerce | 16,2 % | 2,01 % | 0,21 % | 0,25 % | 0,27 % |
| Éducation et formation | 32,4 % | 2,85 % | 0,29 % | 0,54 % | 0,21 % |
| Services financiers | 28,57 % | 1,26 % | 0,55 % | 0,34 % | 0,29 % |
| Jeux et sports | 29,44 % | 3,44 % | 0,37 % | 0,44 % | 0,20 % |
| Santé et remise en forme | 21,42 % | 2,83 % | 0,31 % | 0,40 % | 0,36 % |
| Informatique et logiciels | 23,1 % | 2,12 % | 0,40 % | 0,43 % | 0,27 % |
| Médias, marketing et publicité | 23,9 % | 3,12 % | 0,21 % | 0,28 % | 0,18 % |
| Immobilier, design et construction | 18,97 % | 1,68 % | 0,41 % | 0,59 % | 0,28 % |
| Restaurants | 24,01 % | 1,47 % | 0,32 % | 0,51 % | 0,31 % |

Les deux tableaux divergent sur les niveaux de secteurs aux noms proches (par exemple un taux d'ouverture de 17,1 % pour le commerce de détail chez Marigold contre 16,2 % pour l'e-commerce chez Freshworks, et 28,5 % pour l'éducation chez Marigold contre 32,4 % pour l'éducation chez Freshworks). Cela montre directement pourquoi les chiffres d'engagement de différents éditeurs ne doivent pas être mis en commun.

---

## 3. Adoption et maturité des expéditeurs : Sinch (enquête, juillet 2024)

**Source :** combinaison de **Sinch Mailgun, *State of Email Deliverability 2025*** et de **Sinch Mailjet, *Road to the Inbox 2025***. Les deux rapports utilisent la **même enquête**, que Sinch a menée en **juillet 2024** auprès de **plus de 1 100 expéditeurs d'emails** aux États-Unis, au Royaume-Uni, en France, en Allemagne et en Espagne. Les répondants étaient des utilisateurs de Mailjet, Mailgun et Email on Acid, invités par email ou dans l'application, avec un lot à gagner comme incitation.

Les chiffres sont **déclaratifs** et proviennent de clients d'ESP. Lisez-les comme ce que les expéditeurs disent faire, et non comme des résultats mesurés, et ne les comparez pas aux données de placement de Validity ci-dessus. Quand les deux rapports citent la même statistique (par exemple DMARC 53,8 %), il s'agit d'un seul chiffre issu d'une seule enquête, présenté une seule fois ci-dessous.

L'échantillon penche vers les petits expéditeurs, ce qui compte si vous généralisez à partir de lui : **62,5 %** envoient moins de 50 000 emails par mois, et **52,3 %** ont ≤10 salariés.

### Adoption de l'authentification

| Indicateur | Valeur | Détail de la source |
|---|---|---|
| Utilisent DMARC (2024) | **53,8 %** | Contre **42,6 %** en 2023 (une hausse de 11,2 points, soit environ 26 % en valeur relative, attribuée aux exigences de Google et Yahoo de février 2024) |
| Expéditeurs de gros volumes, ou aux plus gros volumes, qui utilisent DMARC | Environ 56 % (2023), jusqu'à **environ 70 % et plus** (2024) | L'adoption a progressé le plus vite chez les expéditeurs de gros volumes |
| Utilisent à la fois SPF et DKIM | 66,2 % | Environ 9 % n'en utilisent qu'un ; plus de 25 % ne savent pas |
| Leur politique DMARC est `p=none` | Environ 31,8 % | La politique la plus courante |
| Leur politique DMARC est `p=quarantine` | Environ 19,3 % | |
| Leur politique DMARC est `p=reject` | Environ 17,7 % | |
| Ne connaissent pas leur politique DMARC | Environ 31,3 % | Contre plus de 40 % en 2023 (la connaissance a progressé avec l'adoption) |
| Ont mis en place BIMI | Moins de 6 % | 11,4 % de plus « y travaillent » ; 24,5 % ne savent pas |

La plupart des utilisateurs de DMARC restent à `p=none`, qui n'impose rien. Sinch et les experts qu'il cite y voient le déficit de maturité : l'adoption a progressé, mais la plupart des expéditeurs ne sont pas passés à une politique contraignante. Voir [Déploiement de DMARC en détail](https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc) pour déployer une politique, et [BIMI (Brand Indicators for Message Identification)](https://emailmarketing.net/fr/apprendre/authentification/bimi), qui exige `p=quarantine` ou `p=reject`. Google et Yahoo n'exigeaient que `p=none` au lancement, et un minimum plus strict est attendu (voir [Exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs) et [Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs)).

### L'idée fausse sur le taux de livraison

Le constat principal de Sinch est que les expéditeurs comprennent systématiquement mal ce que mesure le « taux de livraison » (delivery rate). À la question de sa définition :

| Idée sur le « taux de livraison » | Part |
|---|---|
| Le % d'emails qui arrivent en **boîte de réception** (faux) | 50,9 % |
| La délivrabilité globale (faux) | 22,8 % |
| « Ne sait pas » | 11,6 % |
| Le nombre total d'emails envoyés (faux) | 2,5 % |
| **Correct :** le % livré dans **n'importe quel dossier** (spam compris) | **12,3 %** |

**Environ 88 % n'ont pas su dire correctement ce que mesure le taux de livraison.** Le taux de livraison compte les messages acceptés dans n'importe quel dossier, spam compris : un taux de livraison de 98 % ne dit donc rien de l'arrivée en boîte de réception. [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite) et [Méthodologie de mesure du placement](https://emailmarketing.net/fr/apprendre/operations/methodologie-de-mesure-du-placement) mettent en garde contre exactement cette confusion entre messages livrés et messages en boîte de réception, et l'enquête la chiffre.

### Surveillance et hygiène de base de données

| Pratique | Valeur |
|---|---|
| Attribuent à la délivrabilité une importance de 8/10 ou plus | 78,5 % |
| Se sentent « très confiants » dans leurs connaissances en délivrabilité | 27 % |
| Estiment qu'« éviter le spam » est un défi majeur | 48 % |
| Ne surveillent **pas** leur réputation auprès des grands fournisseurs de messagerie (par exemple Gmail Postmaster Tools) | 70 % |
| Ont commencé à utiliser Google Postmaster Tools après les exigences de 2024 | 19,2 % |
| Surveillent activement les taux d'ouverture et de clics | 57,4 % |
| Surveillent activement le taux de livraison | 53,1 % |
| Surveillent activement le taux de rebonds | 46,5 % |
| Surveillent activement le taux de désabonnement | 39,5 % |
| Surveillent activement le taux de plaintes pour spam | 32 % |
| Surveillent les listes de blocage | 32,7 % (plus de 50 % ne le font pas ; 14,5 % ne savent pas) |
| Nettoient rarement ou jamais leurs listes | 39 % |
| Ont une politique de mise en sommeil pour les abonnés inactifs | Environ 24 % (environ 59 % n'en ont pas ; environ 17 % ne savent pas) |
| Reconnaissent avoir acheté une liste ou collecté des adresses par scraping | 9,4 % |
| Utilisent le double opt-in pour confirmer les nouveaux abonnés | Environ 40 % |
| Séparent les flux d'emails transactionnels et promotionnels | Environ 37 % (50,3 % ne le font pas ; 12,6 % ne savent pas) |

Les actions que les expéditeurs déclarent avoir engagées après les exigences : 37 % ont commencé à surveiller de près leur taux de plaintes pour spam, 35,8 % ont renforcé l'hygiène de leurs listes, 33,1 % ont mis en place le désabonnement en un clic (RFC 8058), 19,2 % ont adopté Google Postmaster Tools, 18,6 % ont ajusté leur fréquence d'envoi, et 12,5 % ont modifié leur processus d'opt-in. Moins d'un quart (23 %) ont signalé un quelconque problème de délivrabilité causé par les changements de Google et Yahoo.

Seuls **32 %** surveillent leur taux de plaintes pour spam, alors que Gmail et Yahoo appliquent un seuil de **0,3 %**. L'indicateur le plus directement lié à l'exigence est l'un des moins suivis. Voir [Google Postmaster Tools](https://emailmarketing.net/fr/apprendre/outils-postmaster/google-postmaster-tools), [List-Unsubscribe et désabonnement en un clic](https://emailmarketing.net/fr/apprendre/gestion-des-listes/list-unsubscribe-et-desabonnement-en-un-clic) et [Hygiène de base de données et politiques de mise en sommeil](https://emailmarketing.net/fr/apprendre/operations/hygiene-de-base-de-donnees-et-politiques-de-mise-en-sommeil).

### Apple Branded Mail et BIMI (Marigold)

**Source :** Marigold, *The Essential Guide to Deliverability*. Il s'agit d'une comparaison de fonctionnalités, et non de données d'enquête. Il existe deux façons d'afficher le logo d'une marque dans la boîte de réception :

| | BIMI | Apple Business Connect : Branded Mail |
|---|---|---|
| Où il s'affiche | Plusieurs fournisseurs, dont Gmail, Yahoo, Fastmail et Apple Mail | Apple Mail uniquement (l'écosystème Apple) |
| Exige DMARC à `p=quarantine` ou `p=reject` | Oui | Oui |
| Coût du certificat | Un Verified Mark Certificate (VMC), payant, est requis pour l'affichage dans Gmail et Apple | Gratuit |
| Bénéfice | Reconnaissance de la marque, confiance, authenticité de l'expéditeur | Identique |

Les deux exigent une politique DMARC contraignante, ce qui explique pourquoi la majorité restée à `p=none`, mentionnée plus haut, ne peut encore utiliser ni l'un ni l'autre. Voir [BIMI (Brand Indicators for Message Identification)](https://emailmarketing.net/fr/apprendre/authentification/bimi).

---

## Voir aussi

- [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite), sur ce que signifie chaque indicateur et les seuils qui appellent une action
- [Méthodologie de mesure du placement](https://emailmarketing.net/fr/apprendre/operations/methodologie-de-mesure-du-placement), sur le biais connu des chiffres issus des listes de test, des panels, des pixels et des tableaux de bord (contexte de la section 1)
- [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure), sur les raisons pour lesquelles les taux d'engagement de la section 2 sont faussés
- [Délivrabilité B2B et passerelles de messagerie d'entreprise](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/delivrabilite-vers-les-passerelles-b2b), sur les passerelles de filtrage derrière les chiffres B2B
- [Déploiement de DMARC en détail](https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc), derrière les chiffres d'adoption de la section 3
- [BIMI (Brand Indicators for Message Identification)](https://emailmarketing.net/fr/apprendre/authentification/bimi)
- [Exigences de Gmail envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-gmail-envers-les-expediteurs), sur les règles de 2024 pour les expéditeurs de gros volumes qui ont entraîné l'adoption
- [Exigences de Yahoo envers les expéditeurs](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-yahoo-envers-les-expediteurs)

# Les deux mondes de la délivrabilité email

> Travailler avec les fournisseurs de messagerie (emails désirés et attendus) ou contre eux (techniques de contournement) : pourquoi le contournement échoue et pourquoi envoyer moins peut rapporter plus.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/strategie/les-deux-mondes-de-la-delivrabilite-email

Quand vos emails sont filtrés, deux voies s'offrent à vous : les rendre plus désirés par les destinataires, ou chercher à franchir les filtres grâce à des astuces techniques. Ces deux approches conduisent à deux « mondes » de la délivrabilité très différents, et seul le premier tient dans la durée.

## Monde 1 : travailler avec les fournisseurs de messagerie

Ici, votre but rejoint celui des fournisseurs : des emails que les destinataires **désirent** et **attendent**, c'est-à-dire ceux que les fournisseurs cherchent à livrer en boîte de réception.

Deux conditions définissent ces emails :

- **Désirés :** ils apportent aux destinataires quelque chose qui compte pour eux.
- **Attendus :** les destinataires les reconnaissent, parce qu'ils se sont inscrits ou qu'ils sont déjà en relation commerciale avec votre marque.

Un fournisseur ne peut pas lire dans l'esprit de ses utilisateurs, mais il peut observer leur comportement à grande échelle, sur des dizaines de milliers de boîtes, et cela lui en apprend plus qu'une question. Les plaintes et l'engagement pèsent le plus : combien de destinataires signalent un message comme spam, combien l'ouvrent et le lisent, combien le suppriment sans le lire, et combien de temps ils y passent. Les algorithmes de filtrage traduisent ces mesures en un verdict : vos emails sont-ils désirés et attendus ?

Le comportement n'est pas le seul critère. Les fournisseurs examinent aussi le **contenu**, où certains mots ou certaines tournures peuvent pousser un message vers le filtrage anti-spam, et les **détails techniques de l'envoi**, comme le nombre de connexions que vous ouvrez, l'authentification des emails et les calendriers de chauffe.

Dans ce monde, les expéditeurs envoient sans détour et ne cherchent pas de failles techniques pour « déjouer » le système. Les fournisseurs existent pour livrer les emails que leurs utilisateurs accueillent volontiers : dans un programme fondé sur des emails désirés et attendus, le reste suit donc en règle générale. Des problèmes de livraison surviennent quand même, et on peut en règle générale les corriger.

Des taux d'ouverture de **5 % à 20 % ou plus** sont courants ici, et la cible est la **boîte de réception**.

## Monde 2 : travailler contre les fournisseurs de messagerie

Ici, les expéditeurs tentent de tromper les filtres anti-spam pour leur faire accepter ou livrer des emails que les destinataires ne désirent pas et n'attendent pas.

Beaucoup d'expéditeurs y arrivent sans l'avoir voulu. Imaginons que vos emails suscitent beaucoup de plaintes ou très peu d'engagement, et que les fournisseurs se soient mis à les filtrer. Deux réactions sont possibles :

- **(A)** Examiner le programme lui-même : trouver d'où viennent les plaintes ou les adresses pièges touchées et éliminer cette cause, pour que les destinataires désirent et attendent davantage les emails. Cette réaction vous garde dans le monde 1.
- **(B)** Laisser la cause profonde en place et mettre tous vos efforts dans des contournements, par exemple étaler les emails sur de nombreuses adresses IP pour qu'aucune n'attire l'attention, faire tourner les noms de domaine, ou envoyer le message entier sous forme d'image que les filtres de contenu ne savent pas lire. Cette réaction vous fait entrer dans le monde 2.

Le monde 2 se définit par la tentative de **contourner le système**. Beaucoup de mauvais conseils circulent en matière de délivrabilité, si bien que de nombreux expéditeurs choisissent cette voie de bonne foi.

Cette voie échoue parce que les fournisseurs emploient des équipes dédiées et compétentes, chargées de repérer les contournements que les expéditeurs opposent à leurs filtres et de les neutraliser. **Toutes les méthodes de contournement finissent par cesser de fonctionner.** Chacun des contournements cités plus haut est déjà bien compris, et les fournisseurs disposent de contre-mesures conçues pour repérer et pénaliser chacun d'eux.

Des taux d'ouverture autour de **0,1 %** sont typiques dans ce monde, et la « solution » habituelle à de faibles ouvertures consiste à envoyer davantage. Souvent, la cible n'est même plus la boîte de réception, seulement le **dossier Bulk ou le dossier spam**, du moment que les emails ne sont pas refusés purement et simplement.

## Ce qui rend un email désiré et attendu

1. **La permission est indispensable.** Un email que personne n'a demandé est non désiré par définition : les destinataires doivent donc vous avoir invité à leur écrire.
2. **Ce que vous envoyez doit correspondre à ce que les gens attendent.** Un abonné qui s'est inscrit à une « bonne affaire du jour » et reçoit chaque jour une publicité sans la moindre bonne affaire reçoit autre chose que ce qu'il voulait ou attendait.
3. **Le volume doit être raisonnable et attendu.** Envoyer cinq messages par jour à des personnes à qui l'on n'a jamais dit à quelle fréquence on leur écrirait, c'est envoyer plus qu'elles n'attendent, et sans doute plus qu'elles ne le souhaitent. Indiquez aux abonnés, au moment de l'inscription, à quelle fréquence ils recevront vos emails.
4. **La permission ne se cache pas.** Un consentement glissé dans des conditions générales que personne ne lit produit malgré tout des emails que le destinataire n'attend pas. Une case précochée a le même effet, car certaines personnes ne la remarquent jamais.
5. **L'email doit être identifiable.** Un abonné s'est inscrit auprès d'une marque précise. Si les messages qui arrivent ne portent pas cette marque, il voit des emails d'un expéditeur qu'il ne reconnaît pas et les jugera sans doute non désirés et inattendus, aussi soigné qu'ait été le parcours d'inscription.
6. **Retirez les abonnés inactifs.** Quand un abonné n'a ni ouvert ni cliqué depuis un certain temps, cessez de lui écrire. Quelqu'un qui a ignoré trois emails par semaine pendant six mois s'est de fait « désabonné émotionnellement ». Retirer ces adresses augmente la part de votre liste qui lit et désire vos emails, si bien que l'ensemble de vos envois devient plus désiré.

Les fournisseurs le disent ouvertement : leurs filtres servent à repérer et à bloquer les emails que les destinataires ne désirent pas ou n'attendent pas.

## Exemples de techniques de contournement (qui ne fonctionnent pas vraiment)

1. **Utiliser trop d'adresses IP (snowshoeing d'IP).** L'expéditeur étale son volume en couches minces sur de nombreuses adresses IP, en espérant que chacune envoie trop peu pour attirer l'attention. Les fournisseurs connaissent ce schéma et pénalisent les expéditeurs qui utilisent plus d'adresses IP que leur volume ne le justifie. GreenArrow recommande que chaque adresse IP envoie au moins environ 20 000 messages par jour.
2. **Utiliser trop de noms de domaine (snowshoeing de domaines).** La même astuce, appliquée aux domaines : les spammeurs font défiler des noms de domaine « jetables » pour se débarrasser d'une mauvaise réputation et dissimuler qui ils sont.

Les spammeurs endurcis vont plus loin, avec des méthodes comme la prise de contrôle des comptes ESP d'autres expéditeurs, les attaques par rejeu DKIM, l'envoi par des botnets et l'abus de relais ouverts. Certaines constituent des infractions pénales.

Au regard de l'objectif d'atteindre la boîte de réception :

- Les filtres sont conçus précisément pour détecter le snowshoeing d'IP et de domaines : recourir à l'un ou à l'autre peut suffire, à lui seul, à envoyer vos emails dans le dossier spam chez de nombreux fournisseurs.
- Au mieux, le snowshoeing fait arriver les emails dans le **dossier spam** : certains messages qui auraient été rejetés purement et simplement sont livrés en spam à la place.

## Les deux dimensions

Deux dimensions séparent les deux mondes, et chacune est une échelle avec de nombreuses positions entre ses extrémités :

- les emails **désirés et attendus** à un bout, les emails **non désirés et inattendus** à l'autre
- l'**absence de contournement** à un bout, le **contournement du système** à l'autre

Progresser, c'est aller vers des emails désirés et attendus, et vers l'absence de contournement.

Le piège, pour un expéditeur déjà dans le monde 2, c'est qu'un progrès sur **une seule** dimension n'améliore pas la livraison.

- Des emails devenus désirés et attendus, mais qui s'appuient encore sur des techniques de contournement, sont filtrés à cause du contournement.
- Des emails qui ne contournent plus rien, mais restent non désirés et inattendus, sont filtrés parce qu'ils ne sont pas désirés. Ce changement peut même faire passer des emails qui arrivaient dans le dossier spam à un rejet complet.

Les deux dimensions doivent progresser **ensemble**.

## Moins, c'est plus : une économie qui va contre l'intuition

Rendre les emails plus désirés et attendus veut en général dire en envoyer **moins**, et envoyer moins peut rapporter **plus d'argent**, parce que ce volume réduit atteint la boîte de réception. GreenArrow l'illustre par un exemple simplifié et hypothétique :

- Les emails du dossier spam sont ouverts dans 0,3 % des cas, car environ 95 % des destinataires ne consultent jamais leur dossier spam.
- Les emails de la boîte de réception sont ouverts dans 10 % des cas, soit 30 fois plus souvent.
- On suppose que chaque ouverture a autant de chances de mener à l'action qui génère des revenus.
- Les changements qui rendent les emails désirés et attendus divisent le volume par 5, et les font arriver en boîte de réception.

Le volume est 5 fois plus faible, tandis que le revenu par email est 30 fois plus élevé : **le revenu total est multiplié par 6**.

## Mettre en œuvre les changements

Devenir plus désiré et attendu demande en général un examen attentif et complet de tout le programme d'email. Laissez les données guider la démarche : changez un élément, puis observez l'effet sur les taux de plaintes et l'engagement.

Prévoyez plusieurs cycles, car l'amélioration de la délivrabilité est un processus itératif. Chaque campagne enrichit votre historique d'envoi, et cet historique désigne la prochaine amélioration. Ce sont les fournisseurs de messagerie qui décident en dernier ressort de livrer en boîte de réception, de classer dans le dossier spam ou de rejeter, et ces pratiques visent à faire de vos emails ceux qu'ils choisissent de placer en boîte de réception.

## Voir aussi

- [Allocation de base des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/allocation-de-base-des-adresses-ip)
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)
- [Segmentation et allocation avancées des adresses IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/segmentation-et-allocation-avancees-des-adresses-ip)