# 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