Votre serveur SMTP interne a refusé les connexions pendant quarante minutes — certificat expiré, quota dépassé, ou IP fraîchement listée. La panne est corrigée. L'admin clique « relancer les 12 000 emails en échec ». Une heure plus tard, Gmail throttle votre domaine, les logs montrent des 452 et des 550, et les vrais emails transactionnels (reset password) rebondissent.
Le retry naïf recrée la panne à plus grande échelle.
Pourquoi le blast retry est dangereux
| Risque | Mécanisme | Conséquence |
|---|---|---|
| Rate limit ESP/FAI | Trop de connexions/min | 421, 452 temporaires en cascade |
| Blacklist | Pic suspect depuis votre IP | Tous les envois impactés |
| Queue SMTP locale | Postfix/qmail saturé | Timeouts applicatifs |
| UX | Doublons non dédupliqués | 3 factures identiques |
Un email en échec n'est pas une donnée à vider — c'est un message avec une cause, une priorité et une fenêtre de validité.
Classifier avant de relancer
Hard bounce (5xx) — adresse inexistante, policy reject : ne pas retry. Marquez failed, nettoyez la base.
Soft bounce (4xx) — quota, greylisting, temp unavailable : retry avec backoff.
Timeout applicatif — votre code n'a pas eu de réponse : investiguer séparément du bounce SMTP.
Stockez le code SMTP, le DSN et le nombre de tentatives par message.
Backoff exponentiel et rate limit
Schéma type :
| Tentative | Délai | Action |
|---|---|---|
| 1 | 5 min | Retry auto |
| 2 | 30 min | Retry auto |
| 3 | 2 h | Retry + alerte exploitation |
| 4 | 24 h | Dernière tentative |
| 5 | — | Failed définitif |
Limitez le débit global : ex. 100 emails/minute max en recovery, même si votre ESP autorise plus.
Implémentation : Sidekiq retry, Laravel queue backoff, Celery retry_backoff, ou cron qui lit une table outbound_mail avec next_retry_at.
Prioriser les emails critiques
Pas tous les messages méritent le même SLA :
- P0 — reset password, 2FA, alertes sécurité.
- P1 — confirmations commande, factures.
- P2 — newsletters, marketing différé.
En recovery, traitez P0 d'abord avec un canal séparé si possible (ESP transactionnel dédié).
ESP vs SMTP maison sur hébergement
Sur mutualisé ou VPS, envoyer directement depuis Postfix expose votre IP partagée. Les ESP transactionnels absorbent les pics retry et gèrent SPF/DKIM/DMARC.
Si vous self-host : surveillez postmaster tools, rDNS, et limitez le volume depuis une IP dédiée.
Le sommet : le retry est un test de réputation, pas de persistance
Mesurez les bounces après le retry, pas seulement les envois « acceptés » par votre SMTP.
Décider et avancer sans angle mort
Persistez statut, code erreur et nombre de tentatives par message avant d'avoir besoin d'un recovery. Implémentez backoff et limite de débit en amont — pas le jour de la panne. Séparez transactionnel et marketing via domaines ou ESP distincts. Testez un scénario panne + recovery en staging avec volume réaliste. Comparez hébergeurs et limites email dans notre annuaire.
Questions fréquentes
Faut-il relancer immédiatement après une panne SMTP ?
Non. Attendez que le service soit stable, identifiez la cause (auth, quota, blacklist), puis relancez par batch avec backoff — pas un dump de milliers de messages simultanés.
Quelle différence entre erreur 4xx et 5xx SMTP ?
4xx = temporaire (greylisting, quota) → retry avec backoff. 5xx = permanent (adresse invalide, policy) → ne pas insister, marquer failed et alerter.
Comment éviter la blacklist lors d'un gros retry ?
Limitez le débit (messages/minute), étalez sur plusieurs heures, utilisez un ESP transactionnel (Brevo, Mailgun, Postmark) avec réputation gérée, et surveillez les bounce rates.
Queue maison ou service managé ?
Queue maison (Redis, database) si volume modeste et équipe d'exploitation. ESP + webhooks bounce/complaint dès que le volume ou la délivrabilité devient critique.
Après une panne SMTP, la question n'est pas « combien relancer » — c'est à quel rythme votre réputation peut absorber le rattrapage.