Uw interne SMTP-server heeft veertig minuten lang verbindingen geweigerd: verlopen certificaat, quotum overschreden of nieuw vermeld IP-adres. De fout is gecorrigeerd. De beheerder klikt op “start de 12.000 mislukte e-mails opnieuw”. Een uur later beperkt Gmail uw domein, de logboeken tonen 452's en 550's, en de echte transactionele e-mails (wachtwoord opnieuw instellen) stuiteren.
Naïeve nieuwe poging herschept de fout op grotere schaal.
Waarom nieuwe explosies gevaarlijk zijn
| Risico | Mechanisme | Gevolg |
|---|---|---|
| Tarieflimiet ESP/FAI | Te veel verbindingen/min | 421, 452 cascade tijdelijk |
| Zwarte lijst | Verdachte piek van uw IP | Alle zendingen getroffen |
| Lokale SMTP-wachtrij | Postfix/qmail vol | Time-outs van toepassing |
| UX | Niet-ontdubbelde duplicaten | 3 identieke facturen |
Een mislukte e-mail is geen data die moet worden gedumpt; het is een bericht met een oorzaak, een prioriteit en een geldigheidsperiode.
Classificeer voordat u opnieuw opstart
Hard bounce (5xx) — niet-bestaand adres, beleid afgewezen: niet opnieuw proberen. Markeren is mislukt, maak de basis schoon.
Zachte bounce (4xx) — quota, grijze lijst, tijdelijk niet beschikbaar: opnieuw proberen met uitstel.
Time-out van toepassing: uw code heeft geen reactie gehad: onderzoek dit afzonderlijk van de SMTP-bounce.
Bewaar de SMTP-code, DSN en aantal pogingen per bericht.
Exponentiële uitstel en tarieflimiet
Typisch diagram:
| Poging | Termijn | Actie |
|---|---|---|
| 1 | 5 minuten | Automatisch opnieuw proberen |
| 2 | 30 minuten | Automatisch opnieuw proberen |
| 3 | 02.00 uur | Opnieuw proberen + exploitatiewaarschuwing |
| 4 | 24 uur | Laatste poging |
| 5 | — | Permanent mislukt |
Beperk de algehele stroom: b.v. Maximaal 100 e-mails/minuut bij herstel, zelfs als uw ESP meer toestaat.
Implementatie: Sidekiq opnieuw proberen, Laravel wachtrij uitstellen, Celery retry_backoff, of cron die een outbound_mail tabel leest met next_retry_at.
Geef prioriteit aan kritieke e-mails
Niet alle berichten verdienen dezelfde SLA:
- P0 — wachtwoord opnieuw instellen, 2FA, beveiligingswaarschuwingen.
- P1 — orderbevestigingen, facturen.
- P2 — nieuwsbrieven, vertraagde marketing.
Verwerk bij herstel eerst P0 met een apart kanaal, indien mogelijk (speciaal transactioneel ESP).
ESP versus SMTP-thuis op hosting
Op gedeeld of VPS maakt het rechtstreeks verzenden vanuit Postfix uw gedeelde IP zichtbaar. Transactionele ESP's absorberen pieken bij nieuwe pogingen en verwerken SPF/DKIM/DMARC.
Als u zelf host: controleer postmaster tools, rDNS en beperk het volume vanaf een speciaal IP-adres.
De top: opnieuw proberen is een test van reputatie, niet van doorzettingsvermogen
Meet het aantal bounces na een nieuwe poging, en stuur niet alleen de verzonden berichten “geaccepteerd” door uw SMTP.
Beslis en ga vooruit zonder blinde vlek
Behoud status, foutcode en aantal pogingen per bericht voordat herstel nodig is. Implementeer back-off en snelheidsbeperking vooraf, niet op de dag van de storing. Gescheiden transactie- en marketingactiviteiten via afzonderlijke domeinen of ESP's. Test een storings- en herstelscenario in fasering met realistisch volume. Vergelijk hosts en e-maillimieten in onze overzicht.
Veelgestelde vragen
Moeten we onmiddellijk opnieuw opstarten na een SMTP-fout?
Nee. Wacht tot de service stabiel is, identificeer de oorzaak (authenticatie, quota, zwarte lijst) en start vervolgens batchgewijs opnieuw op met uitstel - niet een dump van duizenden gelijktijdige berichten.
Wat is het verschil tussen 4xx en 5xx SMTP-fout?
4xx = tijdelijk (greylisting, quota) → opnieuw proberen met uitstel. 5xx = permanent (ongeldig adres, beleid) → niet aandringen, markeren als mislukt en waarschuwen.
Hoe voorkom je de zwarte lijst tijdens een grote nieuwe poging?
Beperk de doorvoer (berichten/minuut), gespreid over meerdere uren, gebruik een transactionele ESP (Brevo, Mailgun, Postmark) met beheerde reputatie en monitor de bouncepercentages.
Interne wachtrij of beheerde service?
Zelfgemaakte wachtrij (Redis, database) als het volume en het operationele team bescheiden zijn. ESP + webhooks stuiteren/klagen zodra het volume of de leverbaarheid van cruciaal belang wordt.
Na een SMTP-storing is de vraag niet "hoeveel er opnieuw moet worden opgestart", maar hoe snel uw reputatie de inhaalslag kan opvangen.