Runbook d'incident de délivrabilité e-mail : comment réagir à une chute soudaine

Un runbook d'incident de délivrabilité e-mail est le plan écrit que suit votre équipe lorsque la délivrance chute brutalement : les rebonds explosent, les messages stagnent dans les files d'attente, les plaintes augmentent ou des clients disent que les messages n'arrivent jamais. Avoir décidé des étapes à l'avance est essentiel, car la première heure est celle où l'essentiel des dégâts est soit contenu, soit aggravé. Ce guide nous donne un runbook pratique : un triage en 30 minutes, un tableau de décision, les preuves à collecter, les étapes de reprise, des modèles de messages, un format de revue et des garde-fous.

Ce qui constitue un incident de délivrabilité

Toute baisse n'est pas un incident. Le trafic normal fluctue selon le calendrier, l'audience et le contenu. Nous parlons d'incident lorsqu'une mesure clé sort rapidement de sa plage normale et que la cause n'est pas évidente : taux de rebond, volume de reports, taux de plaintes, délai de livraison des messages importants ou placement en boîte de réception chez un grand fournisseur de messagerie. Dégainer le runbook tôt coûte peu. Attendre coûte de la réputation.

Définissez vos niveaux de gravité à l'avance. Un schéma simple à trois niveaux fonctionne bien : un point de surveillance de faible niveau suivi par une seule personne, un incident standard avec un responsable désigné et des mises à jour toutes les heures, et un incident critique lorsque le courrier transactionnel, comme les réinitialisations de mot de passe ou les reçus de paiement, est affecté ou qu'un identifiant peut être compromis. Les définitions ci-dessous sont des exemples à adapter, pas un standard.

Niveau	Déclencheur d'exemple (à ajuster à votre trafic)	Réponse
Surveillance	Un indicateur sort de sa plage habituelle pour un seul envoi	Le responsable vérifie dans l'heure et note ses constats
Incident	Un indicateur double par rapport à sa référence, ou un grand fournisseur reporte ou rejette une part importante des messages	Ouvrir le runbook, nommer un responsable, mettre en pause les envois en masse non critiques, informer les parties prenantes toutes les heures
Critique	Courrier transactionnel retardé ou rejeté, identifiants compromis soupçonnés, ou inscription sur une liste de blocage d'une IP ou d'un domaine d'envoi principal	Runbook complet, les quatre rôles pourvus, mise à jour toutes les 30 minutes jusqu'au confinement

Les 30 premières minutes : triage et confinement

L'objectif de la première demi-heure n'est pas de trouver la cause racine. Il s'agit d'empêcher les dégâts de s'étendre et de classer le problème assez bien pour savoir où chercher. Suivez ces étapes dans l'ordre et notez l'heure de chacune.

1. Minutes 0 à 5 : déclarer. Ouvrez un canal partagé, nommez le responsable d'incident, notez l'heure à laquelle le problème a été remarqué et celle à laquelle il a probablement commencé. Utilisez l'UTC pour tous les horodatages afin que les journaux, les rapports et les personnes situées dans des fuseaux différents concordent.
2. Minutes 5 à 10 : protéger le courrier transactionnel. Vérifiez que les réinitialisations de mot de passe, les codes à usage unique et les reçus sont toujours délivrés en envoyant quelques messages de test vers des boîtes que vous contrôlez chez les principaux fournisseurs. S'ils échouent, traitez l'incident comme critique.
3. Minutes 10 à 15 : mettre en pause ou limiter le reste. Mettez en pause les campagnes promotionnelles, les newsletters et toute automatisation planifiée qui peut attendre. Pour les flux que vous ne pouvez pas arrêter complètement, réduisez le débit d'envoi. Ne supprimez pas encore le courrier en file d'attente, car il constitue une preuve.
4. Minutes 15 à 25 : classer. Lisez les nombres de rebonds, de reports et de plaintes par fournisseur de messagerie pour le dernier jour, en les comparant à la semaine précédente. Utilisez le tableau de décision ci-dessous pour choisir la famille de causes la plus probable.
5. Minutes 25 à 30 : répartir le travail et envoyer la première mise à jour. Confiez à chaque investigateur une question précise, et envoyez une courte mise à jour interne avec les faits connus à ce stade et l'heure de la suivante.

Garder le courrier transactionnel sur son propre flux, son propre domaine et son propre pool d'IP simplifie considérablement ce triage, car vous pouvez mettre les promotions en pause sans toucher aux reçus. Si ce n'est pas encore fait, consultez la séparation des flux d'e-mails transactionnels et marketing et faites-en un projet une fois l'incident terminé.

Tableau de décision symptôme-cause

Servez-vous de ce tableau pour transformer ce que vous observez en première vérification à effectuer. Il liste des causes probables, pas des certitudes, et plusieurs peuvent coexister. La première colonne correspond à ce qu'affichent vos tableaux de bord. La deuxième indique la question à poser. La troisième renvoie à la vérification qui confirme ou écarte l'hypothèse.

Symptôme	Périmètre	Causes probables	Premières vérifications
Pic de rebonds (rejets 5xx)	Tous les fournisseurs, à partir d'un instant précis	Authentification cassée, enregistrement DNS expiré ou supprimé, identifiant erroné, envoi depuis un domaine non vérifié	Enregistrements DNS SPF, DKIM et DMARC ; modifications récentes du DNS ou du fournisseur ; texte d'erreur dans les réponses de rebond
Pic de rebonds (rejets 5xx)	Un fournisseur	Blocage de politique ou inscription en liste de réputation chez ce fournisseur, changement soudain de volume ou de contenu	Texte du rebond de ce fournisseur, ses données postmaster, historique récent des envois vers ce fournisseur
Pic de rebonds avec erreurs d'utilisateur inconnu	Surtout une campagne ou un import	Adresses obsolètes, achetées ou mal saisies ajoutées à une liste	Source de la liste, ancienneté des adresses, résultats de validation
Pic de reports (4xx)	Un ou deux fournisseurs	Limitation de débit, premières inquiétudes sur la réputation, trop de connexions	Texte des reports, débit d'envoi et concurrence actuels, ancienneté de la file
Pic de reports (4xx)	Tous les fournisseurs	Problème réseau ou DNS de votre côté, échecs TLS, limites de ressources sur les serveurs d'envoi	Délais d'attente dépassés et erreurs TLS dans les journaux, résolution DNS depuis les hôtes d'envoi
Pic de plaintes	Une campagne ou un segment	Audience inattendue, source d'inscription peu claire, lien de désabonnement difficile à trouver	Définition du segment, source d'inscription, visibilité du lien de désabonnement, données de boucle de rétroaction
Ouvertures et clics en baisse, rebonds stables	Un fournisseur	Messages déplacés vers le dossier spam sans aucun rejet	Données postmaster, résultats de tests en boîtes seed ou panel, changements récents de contenu ou de volume
Ouvertures et clics en baisse, rebonds stables	Tous les fournisseurs	Problème de domaine de suivi, blocage des images, liens cassés ou changement de mesure	Certificat et DNS du domaine de suivi, tests de liens, tout changement récent de modèle
Du courrier provenant de sources inconnues passe pour votre domaine dans les rapports DMARC	Visible dans les rapports agrégés	Usurpation d'identité, ou outil tiers oublié qui envoie en votre nom	Sources des rapports agrégés DMARC, liste des expéditeurs approuvés, journaux d'accès de vos identifiants d'envoi

Deux situations méritent une attention particulière. Une hausse soudaine de volume que vous n'avez pas planifiée, associée à un pic de plaintes, peut signaler un compte compromis ou une clé divulguée qui envoie en votre nom. C'est d'abord un événement de sécurité, ensuite un événement de délivrabilité. Par ailleurs, un problème limité à un seul fournisseur relève souvent de la réputation chez ce fournisseur, tandis qu'un problème touchant tous les fournisseurs et apparu à la minute près indique généralement quelque chose que vous avez modifié ou qui a expiré. Pour approfondir chaque famille, notre guide sur les codes de rebond SMTP explique comment lire les réponses 4xx et 5xx, et la checklist de dépannage du dossier spam traite pas à pas les problèmes de placement.

Preuves à collecter avant de modifier quoi que ce soit

Les preuves disparaissent vite. Les journaux tournent, les files se vident et les rapports sont écrasés. Collectez d'abord, corrigez ensuite. Enregistrez tout dans un dossier partagé dont le nom contient l'heure de début de l'incident, et notez le fuseau horaire de chaque export.

Preuve	Ce qu'elle nous apprend	Comment la capturer
Journaux d'événements des 7 derniers jours	Nombres de messages acceptés, reportés, rebondis et signalés comme plaintes, par fournisseur, flux et campagne	Export depuis votre tableau de bord MigoSMTP, l'API ou les webhooks ; consultez votre compte MigoSMTP ou la documentation de l'API pour connaître les options exactes
Réponses brutes de rebond et de report	La formulation exacte utilisée par les fournisseurs pour expliquer le problème	Copiez un échantillon de chaque message distinct, avec le code d'état enrichi, par fournisseur
En-têtes complets de messages de test délivrés et placés en spam	Résultats d'authentification, routage et éventuels verdicts de filtres	Envoyez des tests vers des boîtes que vous contrôlez et sauvegardez la source originale de chacun
Rapports agrégés DMARC	Quelles sources envoient en tant que votre domaine et si SPF et DKIM réussissent et sont alignés	Récupérez les rapports des 7 à 14 derniers jours et comparez-les à la période précédente
Données postmaster des fournisseurs de messagerie	Signaux de réputation du domaine et de l'IP, taux de spam et résultats d'authentification lorsque le fournisseur les publie	Capturez ou exportez les tableaux de bord des domaines concernés
Vérifications de listes de blocage et de DNS	Si les IP ou domaines d'envoi sont listés, et si les enregistrements sont corrects aujourd'hui	Interrogez les principales listes de blocage sur lesquelles vous vous appuyez et résolvez vos enregistrements SPF, DKIM, DMARC, DNS inverse et de suivi
Historique des changements	Ce qui a été déployé, modifié ou basculé autour de l'heure de début	Interrogez toute l'équipe : mises en production, modifications DNS, nouveaux outils, imports de listes, changements de modèles

Des vérifications DNS rapides peuvent être lancées depuis n'importe quel terminal. Les commandes ci-dessous utilisent un domaine et un sélecteur fictifs pour montrer le principe ; remplacez-les par vos propres valeurs.

# Is the SPF record still published and valid?
dig +short TXT example.com

# Is the DKIM key for the selector still published?
dig +short TXT selector1._domainkey.example.com

# What DMARC policy is published?
dig +short TXT _dmarc.example.com

# Does the sending IP have the expected reverse DNS name?
dig +short -x 192.0.2.25

Pour lire les en-têtes, suivez notre guide sur la lecture des en-têtes d'e-mail pour déboguer la délivrance et l'authentification. Pour les tableaux de bord de réputation, l'article sur Google Postmaster Tools explique ce que signifient les signaux et comment les configurer avant d'en avoir besoin.

Étapes de confinement et de reprise

Le confinement arrête les dégâts. La reprise ramène le volume en toute sécurité. Ce sont deux phases distinctes, et les mélanger est la façon dont les équipes rallument l'incendie. Ne relancez pas les flux en pause simplement parce que les indicateurs semblent meilleurs pendant une heure.

Actions de confinement selon la cause

• Échec d'authentification : rétablissez ou corrigez l'enregistrement DNS, confirmez avec un message de test que SPF, DKIM et DMARC réussissent et sont alignés, et seulement ensuite reprenez le trafic.
• Identifiant ou compte compromis : désactivez et remplacez l'identifiant, examinez ce qui a été envoyé, prévenez le titulaire du compte et suivez votre processus de sécurité. La rotation des clés est abordée dans nos conseils de sécurité des clés d'API.
• Mauvaise liste ou mauvais segment : retirez le segment, supprimez les adresses qui ont rebondi ou formulé une plainte, et retracez comment les adresses sont entrées dans la liste pour que cela ne se reproduise pas.
• Problème de contenu ou de lien : retirez le modèle, supprimez le lien ou la pièce jointe suspects, et testez la version corrigée avant de la renvoyer.
• Inscription sur une liste de blocage : déterminez d'abord pourquoi l'inscription a eu lieu, corrigez cette cause, puis suivez la procédure de retrait propre à la liste concernée. Notre guide de retrait des listes de blocage détaille les étapes.
• Limitation de débit par un fournisseur : réduisez la concurrence et le nombre de messages par connexion pour ce fournisseur, et laissez la file se vider au rythme qu'il autorise.

Un plan de reprise par étapes

1. Reprenez d'abord les abonnés les plus engagés et les plus récents, à une fraction du volume normal.
2. Maintenez chaque palier pendant au moins une journée complète de retours des fournisseurs, et plus longtemps pour les fournisseurs qui rapportent leurs données avec un décalage.
3. N'augmentez le volume que tant que les taux de rebond, de report et de plainte restent au niveau de votre référence d'avant l'incident, ou en dessous.
4. Si un signal se dégrade, revenez au palier précédent plutôt que de rester sur place.
5. Réintégrez les segments plus froids en dernier, et envisagez une passe de réengagement ou le retrait des contacts qui n'ont pas interagi depuis longtemps.
6. Ne déclarez la reprise qu'une fois les signaux restés sains à plein volume pendant une durée convenue dès le départ.

La même montée en charge prudente est décrite pour une nouvelle infrastructure dans notre article sur le warm-up, et elle s'applique aussi ici. Voyez la reprise comme une version réduite du warm-up, en commençant par votre meilleur trafic.

Modèles de communication

Une bonne communication réduit le nombre de questions qui interrompent les personnes en train de résoudre le problème. Gardez des messages courts, factuels et réguliers. Indiquez ce qui est connu, ce qui ne l'est pas, ce que nous faisons et quand tombera la prochaine mise à jour. Évitez de blâmer et évitez de promettre une heure de résolution que vous ne maîtrisez pas. Adaptez les textes fictifs ci-dessous à votre propre ton.

Mise à jour pour les parties prenantes internes

Subject: Email delivery incident - update 1 (14:30 UTC)

Status: Investigating, contained.
Impact: Promotional emails to one large mailbox provider are being
delayed or filtered. Order confirmations and password resets are
being delivered normally in our tests.
Actions taken: Promotional sends paused at 14:10 UTC. Evidence
collection in progress. No changes made to DNS yet.
Next steps: Review provider responses and authentication reports.
Needed from you: Please do not schedule new campaigns until we confirm.
Next update: 15:30 UTC or sooner if anything changes.
Incident lead: [name]

Message pour le support et les équipes en contact avec les clients

Subject: For support: delayed or missing marketing emails

What customers may report: Some people have not received recent
newsletters or promotions.
What we know: We are investigating a delivery problem affecting one
mailbox provider. Account and transactional emails are working.
What to say: We are aware that some emails are delayed and are working
on it. Please ask the customer to check their spam folder and to add
our sending address to their contacts.
What not to say: Do not name a cause or promise a time until the
incident lead confirms.
Escalate to the incident lead if: a customer reports missing password
reset or payment emails.
Next update: 16:00 UTC.

Un exemple concret avec des chiffres fictifs

Une équipe envoie normalement environ 200 000 e-mails promotionnels et 15 000 e-mails transactionnels par jour. Son taux de rebond habituel est d'environ 0,6 pour cent et son taux de plaintes habituel d'environ 0,05 pour cent. Un mardi à 09:00 UTC, une campagne vers 80 000 contacts part. À 09:40, le tableau de bord affiche 2 400 rebonds définitifs pour cette campagne, soit 3 pour cent, et un grand fournisseur reporte la plupart des messages restants.

À 09:45, l'investigateur d'astreinte ouvre le runbook. À 09:55, le flux promotionnel est en pause et la bonne délivrance des reçus de test est confirmée. Le tableau de décision oriente vers un pic de rebonds avec erreurs d'utilisateur inconnu, concentré sur une seule campagne. L'examen de l'historique de la liste montre que 30 000 des 80 000 adresses provenaient d'un ancien tableur d'événement, importé deux jours plus tôt et jamais validé. Environ 2 000 des 2 400 rebonds viennent de cet import.

Le confinement est simple : supprimer les adresses qui ont rebondi, retirer l'import non validé de tous les segments et le faire passer par une validation avant tout nouvel usage. L'équipe relance le flux à 10 pour cent du volume normal vers ses contacts les plus engagés le lendemain matin, le porte à 25, 50 puis 100 pour cent au cours des jours suivants tant que le taux de rebond reste sous 1 pour cent, et confirme la reprise après trois jours sans anomalie à plein volume. La revue ajoute un garde-fou : tout nouvel import doit passer la validation et être exclu des campagnes jusqu'à approbation par une personne désignée. Le coût de l'incident a été une journée de pause et quelques campagnes retardées, au lieu d'une longue réparation de réputation.

Garde-fous et seuils d'alerte à ajuster

La plupart des incidents sont découverts par les clients parce que personne ne surveillait le bon chiffre. Les garde-fous avancent la détection. Les valeurs ci-dessous sont des exemples choisis pour montrer la forme d'une alerte raisonnable. Ce ne sont pas des standards universels, et les bons chiffres dépendent de votre audience, de vos fournisseurs et de votre historique. Mesurez votre propre référence pendant plusieurs semaines, puis fixez des seuils relatifs à celle-ci. Consultez les directives d'expéditeur en vigueur des fournisseurs de messagerie qui comptent pour vous afin de connaître les limites qu'ils publient, et lisez notre guide sur les indicateurs à mesurer pour décider quoi suivre.

Signal	Alerte d'exemple (à ajuster à votre référence)	Action automatique suggérée
Taux de rebonds définitifs par campagne	Avertir au-delà de 2 fois votre référence, arrêter au-delà de 4 fois, ou lorsque votre propre limite absolue est franchie	Mettre la campagne en pause et alerter son responsable
Taux de plaintes par fournisseur	Avertir à la moitié de la limite publiée par un fournisseur, déclencher l'astreinte aux trois quarts	Mettre le segment en pause et examiner la source d'inscription
Part de reports par fournisseur	Avertir lorsque les reports dépassent une part que vous ne voyez normalement jamais, par exemple 10 pour cent pendant 15 minutes	Réduire le débit d'envoi vers ce fournisseur
Ancienneté de la file du courrier transactionnel	Avertir lorsque le plus ancien message attend plus de quelques minutes	Appeler l'investigateur d'astreinte
Volume d'envoi	Avertir lorsque le volume horaire dépasse un multiple de la normale pour cette heure	Rechercher des identifiants compromis ou des tâches qui s'emballent
Santé du DNS et des certificats	Vérification quotidienne que les enregistrements SPF, DKIM, DMARC et de suivi se résolvent ; avertir plusieurs semaines avant l'expiration d'un certificat	Ouvrir un ticket pour corriger avant la panne
Nouveaux imports de listes	Bloquer l'utilisation en campagne tant qu'ils ne sont pas validés et approuvés	Exiger une approbation nominative dans le flux de travail

Au-delà des alertes, ajoutez des garde-fous structurels : flux séparés, plafonds d'envoi par campagne, mise en quarantaine des nouvelles sources, et un responsable attitré pour chaque domaine et chaque IP. Le comportement de débit et de nouvelles tentatives compte aussi ; il est expliqué dans le guide sur les limites de débit, les nouvelles tentatives et le backoff de notre centre d'aide.

Rôles d'astreinte

Un runbook fonctionne mieux lorsque les rôles sont connus avant que l'alerte ne sonne. Dans une petite entreprise, une personne peut tenir plusieurs rôles, mais chacun doit avoir un titulaire désigné et un suppléant.

Rôle	Responsabilité	Ne fait pas
Responsable d'incident	Déclare et clôt l'incident, prend les décisions, fixe les heures de mise à jour	Mener personnellement toutes les investigations
Investigateur technique	Lit les journaux, les en-têtes et le DNS, teste les correctifs, propose le confinement	Modifier les paramètres de production sans prévenir le responsable
Responsable des envois ou des campagnes	Sait ce qui a été envoyé, à qui et pourquoi ; met en pause et relance les flux	Reprendre le trafic sans l'accord du responsable
Communicant	Envoie les mises à jour aux parties prenantes et au support, tient la chronologie	Spéculer sur les causes

Revue post-incident

Tenez la revue dans les quelques jours qui suivent, tant que les souvenirs et les journaux sont frais. Gardez-la sans recherche de coupable : le but est de trouver ce qui, dans le système, a laissé passer le problème, pas qui a cliqué sur le bouton. Une fiche d'une page suffit pour la plupart des incidents.

1. Résumé : ce qui s'est passé et quel a été l'impact, en deux ou trois phrases.
2. Chronologie : début, détection, confinement, reprise. Le tout en UTC.
3. Cause racine et facteurs contributifs : la cause directe, et les failles qui ont permis l'incident ou ralenti sa détection.
4. Ce qui a bien fonctionné : les étapes qui ont marché et qu'il faut conserver.
5. Actions : chacune avec un responsable et une date, comme une nouvelle alerte, une étape de validation, une vérification DNS ou un circuit d'approbation modifié.
6. Suivi : une date pour confirmer que les actions sont terminées et que les indicateurs sont stables.

Checklist d'incident

1. Incident déclaré, responsable nommé, heure de début notée en UTC.
2. Courrier transactionnel vérifié par des messages de test et maintenu sur son propre flux.
3. Flux en masse et promotionnels non critiques mis en pause ou limités.
4. Symptôme classé avec le tableau de décision : rebond, report, plainte ou baisse d'engagement ; un fournisseur ou tous.
5. Preuves sauvegardées : journaux d'événements, réponses brutes, en-têtes, rapports DMARC, données postmaster, vérifications de listes de blocage et de DNS.
6. Historique des changements recueilli auprès de toute l'équipe.
7. Cause corrigée et vérifiée avec un message de test avant toute reprise.
8. Reprise échelonnée à partir des contacts engagés à volume réduit, avec des critères de réussite convenus.
9. Mises à jour aux parties prenantes et au support envoyées à l'heure prévue.
10. Revue tenue, actions attribuées, garde-fous et alertes mis à jour.

MigoSMTP fournit des fonctions d'envoi, des journaux et des événements qui aident pour plusieurs de ces étapes. Consultez votre compte MigoSMTP ou la documentation de l'API pour connaître le détail des rapports, webhooks et contrôles disponibles pour vous.

Pour aller plus loin et sources

• RFC 5321 : Simple Mail Transfer Protocol (codes de réponse et comportement des nouvelles tentatives)
• RFC 3463 : Enhanced Mail System Status Codes
• RFC 7489 : Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 6591 : Authentication Failure Reporting Using the Abuse Reporting Format
• Google : Email sender guidelines