Rétablissement après un incident de réputation

Voici la procédure opérationnelle pour les jours et les semaines qui suivent un incident de réputation : un compte ou une clé d’API compromis qui a fait passer du spam par votre infrastructure, une erreur de liste, ou tout événement qui a fait s’effondrer la réputation d’une adresse IP ou d’un domaine. Elle complète Surveillance et correction de la réputation (détection, diagnostic, retrait des listes de blocage) et Chauffe d’IP (warm-up) (construire une réputation à partir de zéro) ; cet article traite de la séquence de rétablissement elle-même, de ce qui distingue une nouvelle chauffe d’une chauffe initiale, et de la façon d’interpréter les résistances des serveurs de réception pendant la reconstruction.

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 ESP face aux incidents. L’ordre compte : chaque étape suppose la précédente 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

• Suspendre 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 creusent le trou.
• Sécuriser 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 et sous-utilisateurs, activez et imposez l’authentification à deux facteurs, et recherchez les domaines, expéditeurs, webhooks ou modèles ajoutés par l’attaquant. Le vecteur de compromission doit être fermé avant l’envoi du moindre message de rétablissement ; sinon, l’attaquant reprend dès que vous reprenez.
• Purger 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

• Reconstruire 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 qu’il faut respecter. Restaurez les suppressions depuis une sauvegarde, intégrez-y chaque rebond et chaque plainte de feedback loop de la période de l’incident, et placez définitivement en liste de suppression toute adresse à laquelle l’attaquant a écrit et qui ne figurait pas dans votre liste opt-in.
• Réduire la liste d’envoi aux seuls 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 se font exclusivement avec vos meilleures données, les personnes qui ont récemment ouvert ou cliqué, exactement comme au début d’une chauffe, mais avec une marge d’erreur encore plus faible.

3. Revérifier l’infrastructure

• Confirmer l’authentification de bout en bout : SPF, DKIM et un enregistrement 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 : cela bloque la poursuite de l’usurpation de votre domaine et montre aux serveurs de réception que vous en avez la maîtrise.
• Revérifier la conformité aux exigences des fournisseurs envers les expéditeurs de gros volumes (Gmail, Yahoo, Microsoft). C’est souvent au moment d’un incident qu’une application jusque-là latente devient effective.
• S’inscrire à tous les canaux de surveillance avant de reprendre : Google Postmaster Tools, Microsoft SNDS/JMRP, la feedback loop de plaintes de Yahoo. Ils fournissent, fournisseur par fournisseur, les verdicts qui conditionnent chaque palier de montée en charge.

4. Obtenir les retraits de liste et prévenir

• Menez les retraits des listes de blocage selon la procédure de retrait de liste, après avoir corrigé la cause profonde. La compromission est l’un des rares motifs d’inscription que les opérateurs lèvent couramment et vite, dès lors que vous pouvez montrer que le compte est sécurisé.
• En cas de blocages persistants 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 solliciter les équipes de support des grands fournisseurs pour obtenir une aide adaptée.

5. Remontée progressive

• Reprenez avec une chauffe manuelle : de petits volumes vers des destinataires engagés, augmentés progressivement (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é en interne son statut « chauffe terminée » n’en a pas moins perdu sa réputation à l’extérieur.
• Fixer les attentes (le calendrier annoncé par SendGrid) : les indicateurs de réputation internes (scores d’engagement côté 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 les retours documentés par 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 Rétablir le placement en boîte de réception).
• Suivez en continu les indicateurs de 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 d’ouverture et de clics par fournisseur et le taux de plaintes.

Nouvelle chauffe après un incident ou chauffe initiale

La nouvelle chauffe reprend les mécanismes d’une chauffe initiale, mais la situation diffère sur des points qui changent le plan :

Deux autres règles documentées par les éditeurs concernent la nouvelle chauffe :

• L’inactivité remet la chauffe à zéro. SendGrid : si une IP n’a pas envoyé depuis plus de 30 jours, il faut reprendre la chauffe avant de revenir 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 canal de 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 ; les mécanismes valent pour tout MTA.

Ce qu’est un report de remise : le serveur du destinataire ne peut pas accepter le message pour l’instant ; 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 à des intervalles qui croissent de façon exponentielle, pendant 72 heures au plus ; au-delà, ils sont finalisés comme bloqués ou expirés. Pendant une chauffe automatisée, une IP en chauffe qui atteint son plafond horaire cesse d’envoyer et les autres IP du compte prennent le relais ; sans IP de secours, les messages sont retentés environ toutes les 15 minutes pendant 72 heures avant d’expirer.

Typologie des reports de remise : identifiez qui limite le débit.

Règles opérationnelles pendant une remontée :

• Hausse du taux de reports de remise chez un fournisseur = maintenir ou réduire le volume chez ce fournisseur. Les reports de remise sont une limitation de débit, l’étape qui précède le blocage (voir signes d’alerte). 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. Multiplier les connexions ou réinjecter les messages reportés comme de nouveaux messages transforme la limitation de débit en blocages.
• Pour les reports liés à une limite, réduisez le débit d’envoi (ou répartissez sur davantage d’IP déjà chauffées) ; pour les reports dus à une limitation par le serveur de réception, 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 faibles 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 les 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 (selon la convention de cette base de connaissances, les mécanismes sont décrits de façon conceptuelle ; les chiffres sont attribués à leurs éditeurs).

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 l’heure et les autres IP du compte (y compris d’autres IP en chauffe qui ont encore de la marge) absorbent le surplus ; sans IP de secours, les messages sont retentés toutes les 15 minutes environ pendant 72 h au plus. Après le jour 41, l’IP sort de la chauffe. Calendrier attribué à l’éditeur :

Les mises en garde de SendGrid : les flux transactionnels ne doivent pas être contraints à un calendrier strict (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, avec 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 du palier fait passer au suivant quel que soit le nombre d’heures écoulées ; la fenêtre de 24 heures démarre au premier message). Plafonds publiés par l’éditeur : palier 1 = 1 000 par jour, palier 2 = 2 500 par jour ; les plafonds des paliers suivants ne sont pas publiés (un plan peut compter jusqu’à 15 paliers selon le modèle de calendrier de l’API). Atteindre trop tôt un plafond quotidien déclenche un arrêt complet des envois sur 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 IP partagées du compte ou vers ses autres IP dédiées ; les messages partent quand même, simplement pas depuis l’IP en chauffe. Durée habituelle d’une chauffe complète : 4 à 8 semaines.

La chauffe se pilote par API (référence de l’API Mailgun, propre à l’éditeur) :

Les consignes manuelles de Mailgun (article archivé de son centre d’aide, capture de 2023) : les IP dédiées sont recommandées à partir de 100 000 emails par mois (c’est la règle maison de Mailgun ; pour la comparer aux minimums des autres éditeurs et au plancher statistique général par IP, voir le tableau de référence des volumes planchers pour une adresse IP dédiée) ; commencez à 100 emails le premier jour et augmentez d’environ 20 % par jour, en envoyant chaque jour (trois envois par semaine ou moins, cela fonctionne mais ralentit la construction de la confiance) ; les domaines de moins de 30 jours ne doivent pas être utilisés du tout, car 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 points sur lesquels les deux mises en œuvre s’accordent) : plafonnez l’actif en chauffe au lieu de mettre en file d’attente et de forcer, le surplus passant par un chemin déjà chauffé ; augmentez les plafonds de façon géométrique (environ 20 à 50 % par jour) ; conditionnez la progression au volume effectivement envoyé, pas seulement au temps écoulé ; et traitez les résistances des serveurs de réception (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 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. Une nouvelle IP est présumée être celle d’un spammeur bloqué qui déménage (voir Chauffe d’IP (warm-up)) ; les serveurs de réception considèrent les domaines de moins de 30 jours environ comme un comportement de spammeur qui fait tourner ses domaines (Mailgun). Changer d’actifs est en soi 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 voie de la réhabilitation est réellement ouverte (voir la procédure de retrait de liste).

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 :

Voie médiane pour les domaines : ne remplacez jamais le domaine organisationnel ; réhabilitez-le tout en faisant passer les flux de messages sur un sous-domaine neuf, correctement délégué et chauffé à partir de zéro, ce qui isole les dégâts sans la pénalité d’un nouveau domaine (voir Meilleures pratiques du M3AAWG pour les domaines d’envoi et Segmentation avancée des adresses IP pour les mécanismes d’isolation des flux). Quel que soit l’actif remplacé, l’actif grillé doit être retiré proprement (en restant authentifié, avec des enregistrements DNS de protection) ; voir Protection de la marque : gestion des domaines.

Voir aussi

• Surveillance et correction de la réputation : détection, diagnostic, retrait des listes de blocage et procédure de rétablissement par le segment engagé.
• Chauffe d’IP (warm-up) : la chauffe initiale de référence, que la nouvelle chauffe adapte.
• Pratiques d’infrastructure d’envoi : stratégie de sous-domaines et chauffe des domaines.
• Listes de blocage DNS et zones Spamhaus : mécanismes d’inscription et de retrait, liste par liste.
• Emails obligatoires et réglementaires : les envois qui ne peuvent pas attendre la fin d’une période de rétablissement.