Bounce-Management: Hard- vs. Soft-Bounces verstehen
Jede E-Mail, die nicht zugestellt werden kann, erzeugt einen Bounce. RFC 3463 (Januar 2003, Gregory Vaudreuil, Lucent Technologies) standardisiert die Status-Code-Klassen: 2.X.X = Erfolg, 4.X.X = persistent transient failure (Soft-Bounce, Retry möglich), 5.X.X = permanent failure (Hard-Bounce, keine Retry). Dieser Deep-Dive erklärt die Bounce-Klassifikation, M3AAWG-Schwellwerte für gesunde Versand-Listen, automatische Suppression-Lists und die Integration in Postfix, Mailcow und transaktionale Sender.
Was ist ein Bounce und warum er klassifiziert wird
Ein Bounce (Delivery Status Notification, DSN) ist die Rückmeldung eines empfangenden Mailservers, dass eine E-Mail nicht zugestellt werden konnte. Die Klassifikation in Hard- und Soft-Bounces folgt RFC 3463 (Enhanced Mail System Status Codes, Januar 2003, Gregory Vaudreuil/Lucent Technologies), die formale DSN-Struktur ist in RFC 3464 definiert. Status-Codes folgen dem Format class.subject.detail — Klasse 2.X.X bedeutet Erfolg, 4.X.X persistent transient failure (Soft-Bounce, vorübergehend), 5.X.X permanent failure (Hard-Bounce, endgültig).
Die Klassifikation ist nicht akademisch — sie ist die Grundlage jeder gesunden Versand-Liste. Hard-Bounces müssen sofort aus Verteilern entfernt werden, weil jede weitere Zustellung an dieselbe Adresse als Negativ-Signal wertet (Mailbox-Provider lesen Wiederhol-Versand an permanente Fehler als „Spammer-Verhalten“). Soft-Bounces hingegen lösen automatische Retry-Mechanismen aus — typisch 3-5 Versuche über 24-72 Stunden, erst dann werden sie als Hard-Bounce eskaliert. Die Bounce-Rate (Anteil aller Bounces am Gesamt-Versand) ist neben Beschwerderate und Spam-Trap-Hits der wichtigste Reputations-Treiber. Siehe IP-Reputation für die Konsequenzen.
RFC 3463 — Status-Code-Klassen im Überblick
- 2.X.X — Success: Positive Zustellungs-Aktion. Beispiel: 2.0.0 OK (Standard-Erfolg).
- 4.X.X — Persistent Transient Failure: Temporäres Problem, das durch Wiederholung gelöst werden kann. Beispiele: 4.2.2 Mailbox full, 4.4.1 No answer from host, 4.7.0 General security or policy.
- 5.X.X — Permanent Failure: Endgültiger Fehler. Beispiele: 5.1.1 Bad destination mailbox, 5.1.2 Bad destination system address, 5.2.2 Mailbox full (permanent), 5.7.1 Delivery not authorized (DMARC-Reject).
Die wichtigsten Status-Codes in der Praxis
Die zweite Stelle im Status-Code (Subject) klassifiziert die Problem-Art: X.1.X = Addressing, X.2.X = Mailbox, X.3.X = Mail-System, X.4.X = Network/Routing, X.5.X = Protokoll, X.6.X = Content/Media, X.7.X = Security/Policy. Diese Tabelle zeigt die in DACH-Email-Operations häufigsten Codes mit Bedeutung und empfohlener Reaktion.
| Code | Klasse | Bedeutung | Reaktion |
|---|---|---|---|
5.1.1 | Hard-Bounce | Bad destination mailbox (Adresse existiert nicht) | Sofort aus Liste entfernen |
5.1.2 | Hard-Bounce | Bad destination system address (Domain existiert nicht) | Sofort entfernen, Tippfehler prüfen |
5.1.10 | Hard-Bounce | Recipient address has null MX (Domain ohne MX-Record) | Sofort entfernen |
5.2.2 | Hard-Bounce | Mailbox full (permanent) | Nach 3-5 Versuchen entfernen |
5.7.1 | Hard-Bounce | Delivery not authorized (DMARC-Reject, SPF-Fail, IP-Block) | Authentifizierung prüfen (Sender-Side) |
5.7.27 | Hard-Bounce | Sender address has null MX (eigene Domain ohne MX) | Eigene MX-Konfiguration prüfen |
4.2.2 | Soft-Bounce | Mailbox full (temporär) | Retry für 72 Std, dann Hard-Bounce |
4.4.1 | Soft-Bounce | No answer from host (Server nicht erreichbar) | Retry für 48 Std |
4.4.7 | Soft-Bounce | Message expired (Retry-Frist überschritten) | Als Hard-Bounce behandeln |
4.7.0 | Soft-Bounce | General security or policy (Greylisting, Rate-Limit) | Retry nach 5-15 Minuten |
4.7.1 | Soft-Bounce | Delivery temporarily denied (Reputations-Drossel) | Reputation prüfen, Sendung pausieren |
Bounce-Rate-Schwellwerte und Provider-Reaktionen
Die Bounce-Rate ist neben Beschwerderate und Spam-Trap-Hits der wichtigste Reputations-Treiber. Mailbox-Provider tracken die Bounce-Rate pro Versand-IP und pro From-Domain — schlechte Werte führen zu Drosselung, Quarantäne oder Hard-Block. M3AAWG Sender Best Common Practices nennen 5 % als kritische Schwelle, ESP wie SendGrid und Postmark sperren Konten ab 10 %.
Gesund (< 2 %)
Bounce-Rate unter 2 % gilt als Indikator für gesunde Listen-Hygiene. Bei Transaktionsmails (Bestellbestätigungen) sollten Sie unter 1 % liegen — alles darüber deutet auf fehlende Email-Validierung im Anmelde-Prozess.
Warnstufe (2 - 5 %)
Bounce-Rate zwischen 2 und 5 % erfordert Listen-Bereinigung. Inaktive Adressen seit 6+ Monaten entfernen oder reaktivieren. Double-Opt-In für Neu-Anmeldungen aktivieren. Drittanbieter wie Kickbox oder NeverBounce für Listen-Validierung.
Kritisch (> 5 %)
Über 5 % triggern Mailbox-Provider Drosselungs-Algorithmen. Bei 10 %+ sperren typische ESPs (SendGrid, Postmark, Mailgun) den Account vorübergehend. Spamhaus PBL-/SBL-Listung wird wahrscheinlich. Sofortmaßnahmen: Versand pausieren, alle Bounces auswerten, Liste re-confirmieren.
Konsequenz nach Provider
- Google (Postmaster Tools): Bei Bounce-Rate über 2 % fällt Domain-Reputation typisch von „High“ auf „Medium“, über 5 % auf „Low“. „Low“ und „Bad“ lösen Spam-Quarantäne-Trigger aus.
- Microsoft (SNDS): IP-Status kippt von „Green“ über „Yellow“ zu „Red“. „Red“ führt zur Spam-Quarantäne; bei wiederholter Reputations-Verletzung Hard-Block über die
550; 5.7.515-Hochvolumen-Regel (Microsoft seit 5. Mai 2025). - Spamhaus: Hohe Bounce-Rate korreliert mit Spam-Trap-Hits — Listung auf SBL oder CSS innerhalb von Tagen möglich.
- Email-Service-Provider (ESP): SendGrid sperrt automatisch ab 10 %, Postmark fordert Account-Reactivation, Mailchimp markiert betroffene Listen.
Automatische Suppression-Lists implementieren
Eine Suppression-List ist die zentrale Datenstruktur des Bounce-Managements: Adressen, an die nicht mehr versendet wird. Sie wird kontinuierlich aus Hard-Bounces, Spam-Beschwerden, Unsubscribes und manuellen Sperren gespeist. Bei Email-Service-Providern ist die Suppression-Logik integriert — bei Self-Hosted-Sendern muss sie implementiert werden. M3AAWG empfiehlt: nach 3-5 Soft-Bounces in Folge temporäre Suspension, nach 1 Hard-Bounce permanente Entfernung.
Hard-Bounce-Suppression (sofort)
Bei jedem Status-Code 5.X.X (außer 5.4.X temporäre Routing-Probleme) Adresse in Suppression-List eintragen. Beispiel-SQL für eigene Sender-Datenbank: UPDATE recipients SET suppressed=true, suppressed_reason='hard_bounce', suppressed_at=NOW() WHERE email='X';. Vor jedem Versand prüfen: SELECT email FROM recipients WHERE suppressed=false;.
- 5.1.1 / 5.1.2 / 5.1.10 → Adresse permanent entfernen
- 5.7.1 (DMARC) → Authentifizierung beim Sender prüfen, nicht Empfänger sperren
- 5.2.2 (Mailbox full permanent) → nach 3 erfolgreichen Bounces in Folge entfernen
Soft-Bounce-Tracking (Retry + Eskalation)
Bei Status-Code 4.X.X Counter inkrementieren. Nach Schwelle (typisch 3-5 Versuche binnen 72 Std) als Hard-Bounce behandeln. Beispiel: UPDATE recipients SET soft_bounce_count=soft_bounce_count+1, last_soft_bounce=NOW() WHERE email='X'; — bei soft_bounce_count >= 5 automatisch suppressen.
Spam-Beschwerde-Suppression (Feedback-Loop)
Mailbox-Provider liefern Feedback-Loops (FBL): bei „Als Spam markieren“ geht eine ARF-formatted (Abuse Reporting Format) Meldung an eine voreingerichtete Postmaster-Adresse. Microsoft JMRP, Yahoo FBL, AOL FBL, Google FBL (über Postmaster Tools). Adressen sofort suppressen — gegen den Wunsch des Empfängers zu versenden ist ein Spam-Trap-Risiko.
Unsubscribe-Suppression (RFC 8058)
Seit Februar 2024 verlangen Google und Yahoo One-Click-Unsubscribe für Hochvolumen-Sender (≥ 5.000 Mails/Tag) via List-Unsubscribe-Header und List-Unsubscribe-Post-Header. Klick auf den Header-Link löst HTTP-POST aus, das die Suppression direkt persistiert. RFC 8058 standardisiert das Verfahren.
List-Unsubscribe: <https://example.com/unsub?u=abc>List-Unsubscribe-Post: List-Unsubscribe=One-Click
5 Bounce-Management-Fehler und ihre Lösung
Fehler 1: Hard-Bounces bleiben in der Liste
Symptom: Bounce-Rate steigt monatlich, Domain-Reputation in Postmaster Tools kippt.
Ursache: Keine automatische Suppression. Manuelle Listen-Pflege scheitert ab 1.000+ Adressen.
Lösung: Bounce-Webhook (bei ESP) oder Log-Parser (bei Self-Hosted) implementieren. Adressen mit Status-Code 5.X.X sofort in Suppression-Tabelle eintragen.
Fehler 2: Soft-Bounces wie Hard-Bounces behandelt
Symptom: Viele aktive Adressen werden fälschlich entfernt — Mailing-Liste schrumpft schnell.
Ursache: Suppression-Logik unterscheidet nicht zwischen 4.X.X und 5.X.X.
Lösung: Soft-Bounce-Counter implementieren. Erst nach 3-5 Soft-Bounces in Folge oder nach finalem 4.4.7 (Message expired) als Hard-Bounce eskalieren.
Fehler 3: DMARC-Reject wird als Mailbox-Fehler interpretiert
Symptom: Nach DMARC-Aktivierung viele 5.7.1-Bounces — Adressen werden fälschlich suppressed.
Ursache: 5.7.1 (Delivery not authorized) bedeutet Authentifizierungs-Problem auf Sender-Seite, nicht ungültige Empfänger-Adresse.
Lösung: 5.7.X-Codes als „Sender-Konfigurations-Problem“ klassifizieren und an Operations-Team eskalieren, nicht Adressen suppressen. DMARC-Aggregat-Reports prüfen (siehe Kapitel 04 DMARC).
Fehler 4: Keine Feedback-Loop-Integration
Symptom: User-Reported-Spam-Rate steigt — keine Reaktion möglich.
Ursache: Microsoft JMRP, Yahoo FBL, AOL FBL nicht registriert. Spam-Beschwerden gehen verloren.
Lösung: Postmaster-Adresse einrichten, Provider-FBLs registrieren. ARF-Parser implementieren, der Beschwerden direkt in Suppression-List einträgt.
Fehler 5: Suppression-Liste nicht im Multi-Service-Setup synchronisiert
Symptom: Mailchimp und SendGrid haben unterschiedliche Suppression-Listen — Empfänger werden über einen Service trotz Unsubscribe wieder kontaktiert.
Ursache: Suppression-Lists sind pro ESP isoliert.
Lösung: Globale Suppression-Datenbank als Single Source of Truth. Jeder ESP synchronisiert vor Versand. Cross-ESP-Webhooks für Bounces und Unsubscribes konfigurieren.
ESP-Webhook-Patterns für skalierbares Bounce-Management
Bei Hochvolumen-Versand ist Log-Polling für Bounce-Erkennung zu langsam — Email-Service-Provider bieten Webhook-Endpunkte, die in Echtzeit über Bounces, Spam-Beschwerden und Unsubscribes informieren. Die folgende Übersicht zeigt die wichtigsten Webhook-Event-Schemata der dominanten DACH-relevanten ESPs und das gemeinsame Implementierungs-Pattern: HMAC-signierte Payloads + idempotente Verarbeitung + Retry-Backoff bei Empfänger-Fehlern.
| ESP | Bounce-Events | Signatur | Retry-Policy |
|---|---|---|---|
| SendGrid (Twilio) | bounce, dropped, spamreport, unsubscribe | X-Twilio-Email-Event-Webhook-Signature (ECDSA) | Re-Tries 24h bei 4xx/5xx, dann Webhook-Disable |
| Postmark | Bounce, SpamComplaint, SubscriptionChange | HTTPS + Basic Auth (Account-Token) | Re-Tries für 45 Tage bei 5xx-Codes |
| Mailgun | failed, complained, unsubscribed | HMAC-SHA256 (token + timestamp + signature) | 8 Stunden, dann Event verworfen |
| Brevo (ehemals Sendinblue) | hard_bounce, soft_bounce, spam, unsubscribed | HMAC-SHA256 (sib-event-signature) | Re-Tries 24h bei 5xx |
| Amazon SES | Bounce, Complaint, Delivery via SNS-Topic | SNS-Signature (RSA-SHA256) | SNS-Standard: maximal 100.015 Retries über 23 Tage |
Webhook-Implementierungs-Pattern für eigene Suppression-Logic
- 1. HMAC-Signatur verifizieren VOR Verarbeitung: ohne Signatur-Check kann Angreifer beliebige Adressen suppressen (Denial-of-Service auf eigene Versand-Pipeline).
- 2. Idempotenter Insert via Event-ID: ESPs senden Events bei Retry erneut.
INSERT ... ON CONFLICT (event_id) DO NOTHINGverhindert Doppel-Suppression. - 3. Hard-Bounce (5.X.X außer 5.4.X) sofort suppressen, Soft-Bounce-Counter inkrementieren: Suppression-Logik aus Sektion oben anwenden.
- 4. DMARC-Reject 5.7.1 separat behandeln: nicht Empfänger suppressen, sondern Authentifizierungs-Drift-Alarm an Operations-Team senden.
- 5. Antwort-Status 200 binnen 1 s: ESPs erwarten schnelle Antwort. Schwere Verarbeitung (Datenbank-Joins, Notifications) async in Queue verlagern.
- 6. Cross-ESP-Synchronisation: Globale Suppression-Datenbank als Single Source of Truth, jeder ESP synchronisiert über Webhook + nightly Reconciliation per CSV-Export.
Quellen: SendGrid Event Webhook, Postmark Bounce Webhook, Mailgun Webhooks, Brevo Transactional Webhooks, Amazon SES SNS Notifications (Abruf 19. Mai 2026).
Bounce-Symptome im Monitoring erkennen
Wolf-Agents misst die Bounce-Rate nicht direkt (das machen Postmaster Tools, SNDS, ESP-Dashboards) — aber das 6-Stunden-Monitoring erkennt die Folgen schlechten Bounce-Managements: Spamhaus-Listing, MX-Reachability-Probleme, DMARC-Failure-Spikes in Aggregat-Reports. Die kontinuierliche Stack-Detection markiert auch Provider-Wechsel, die häufig nach Bounce-getriebenen Sperren passieren.
- 13 DNSBLs Blacklist-Monitoring — Spamhaus ZEN/SBL/XBL/PBL/DBL, Barracuda, SpamCop, SORBS, SURBL, ivmSIP, PSBL, UCEPROTECT, GBUdb. Alarmierung binnen 6 Stunden bei Listung — typische Folge schlechten Bounce-Managements.
- MX-Reachability-Check — automatische Erreichbarkeits-Prüfung der MX-Hosts mit Detection von Konfigurations-Drift, fehlenden MX-Records (5.1.10-Bounce-Auslöser) und Greylisting-Verhalten.
- DMARC-Report-Aggregation (geplant) — Wolf-Agents arbeitet an DMARC-rua-Aggregation, die 5.7.1-Spikes binnen Stunden erkennt und korrekte Authentifizierungs-Drift-Diagnose liefert.
- Customer-Alert-Hub — Webhook-Integration mit ESP-Bounce-Events (SendGrid, Postmark, Mailgun, Brevo). Cross-Service-Korrelation für Multi-ESP-Senders.
Compliance-Konsequenz: Email-Marketing-Recht + DSGVO
DSGVO Art. 17 (Recht auf Löschung) + UWG §7
Adressen nach Unsubscribe oder Spam-Beschwerde weiter zu kontaktieren, ist DSGVO-relevant (Verarbeitung ohne Rechtsgrundlage) und UWG-relevant (unzumutbare Belästigung, §7 Abs. 2 Nr. 3). Saubere Suppression-Listen sind nicht nur Reputations-, sondern Rechts-Schutz.
NIS2 Art. 21 Abs. 2 lit. b (ICT-Sicherheit)
Plötzlich steigende Bounce-Raten können Indikator für Account-Takeover (BEC, Phishing) sein. Bounce-Monitoring als Teil der NIS2-Vorfall-Erkennung dokumentieren.
DSGVO Art. 32 (Stand der Technik)
Transaktionale Sicherheits-Emails (Passwort-Reset, Login-Alert) müssen zugestellt werden. Schlechtes Bounce-Management, das diese Mails systematisch in Spam-Quarantäne schickt, kann als unzureichende technische Maßnahme gewertet werden.
Vertiefen Sie weiter
Hauptkapitel
Verwandte Deep-Dives
Bedrohungen + Verifikation
Wie steht Ihre Domain bei Bounce-Management?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Hard- und Soft-Bounces?
Hard-Bounces (RFC 3463 Klasse 5.X.X — permanent failure) sind permanente Zustellungs-Fehler, die nicht durch Wiederholung gelöst werden: ungültige Adresse (5.1.1), gelöschtes Konto (5.1.10), Domain existiert nicht (5.1.2), DMARC-Reject (5.7.1). Hard-Bounces müssen sofort aus Verteiler-Listen entfernt werden. Soft-Bounces (RFC 3463 Klasse 4.X.X — persistent transient failure) sind temporäre Probleme: Mailbox voll (4.2.2), Server nicht erreichbar (4.4.1), Rate-Limit (4.7.0). Soft-Bounces werden typisch 3-5 Tage lang automatisch wiederholt, erst dann als endgültig behandelt.
Welche Bounce-Rate ist akzeptabel?
M3AAWG Sender Best Common Practices nennen 5 % als kritische Schwelle — darüber drosseln Mailbox-Provider die Zustellung. Branchen-Benchmarks für Email-Marketing: Hard-Bounce-Rate unter 2 % gilt als gesund, 2-5 % erfordert Listen-Bereinigung, über 5 % führt zu Provider-Reaktionen. Bei transaktionalen Sendern (Bestellbestätigungen, Passwort-Resets) sollte die Bounce-Rate unter 1 % bleiben — höhere Werte deuten auf fehlende Email-Validierung im Anmelde-Prozess. Postmark, SendGrid und andere Provider sperren Konten ab 10 % Bounce-Rate.
Wie funktioniert das Status-Code-Schema in RFC 3463?
RFC 3463 (Januar 2003, Gregory Vaudreuil, Lucent Technologies) definiert Enhanced Mail System Status Codes im Format class.subject.detail. Drei Klassen: 2.X.X = Success (positive Zustellung), 4.X.X = Persistent Transient Failure (temporär, Retry möglich), 5.X.X = Permanent Failure (endgültig). Subject-Kategorien: X.0.X = undefiniert, X.1.X = Adressing-Probleme, X.2.X = Mailbox-Probleme, X.3.X = Mail-System, X.4.X = Netzwerk/Routing, X.5.X = Protokoll, X.6.X = Content/Media, X.7.X = Security/Policy. Beispiele: 5.1.1 = Bad destination mailbox (Adresse existiert nicht), 5.2.2 = Mailbox full, 4.4.1 = No answer from host (DNS/Routing).
Was ist eine Bounce-Suppression-List?
Eine Suppression-List ist eine Liste von Adressen, an die nicht mehr versendet wird — typisch nach Hard-Bounce, Spam-Beschwerde oder Unsubscribe. Email-Service-Provider (SendGrid, Mailchimp, HubSpot, Brevo) führen automatisch globale Suppression-Lists. Self-Hosted-Sender (Postfix mit OpenDKIM/OpenDMARC, Mailcow) müssen eigene Suppression-Logik implementieren — z.B. via Datenbank-Flag bei Hard-Bounce, ausgewertet beim nächsten Versand. M3AAWG empfiehlt: nach 3-5 Soft-Bounces in Folge die Adresse temporär suspendieren, nach 1 Hard-Bounce permanent entfernen.
Wie erkenne ich DMARC-Bounces?
DMARC-Reject führt zu Bounce mit SMTP-Status 550 und Status-Code 5.7.1 (typischer Wortlaut: „Unauthenticated email from <domain> is not accepted due to domain DMARC policy“). DMARC-Quarantine ist KEIN Bounce — die Mail wird angenommen und in den Spam-Ordner verschoben. Wenn nach DMARC-Enforcement-Aktivierung (Kapitel 05) plötzlich Hard-Bounces mit 5.7.1 auftreten, deutet das auf Authentifizierungs-Probleme bei legitimen Sendern hin (häufig: vergessene SaaS-Dienste im SPF, DKIM-Selektor nicht gesetzt). Lösung: DMARC-Aggregat-Reports prüfen, fehlende Sender identifizieren, SPF/DKIM ergänzen.
Wie integriere ich Bounce-Management in Postfix?
Postfix erkennt Hard-Bounces automatisch über SMTP-Codes der Empfangs-Server und schreibt sie in /var/log/mail.log. Tools wie pflogsumm aggregieren Bounces. Für automatische Suppression: BounceHandler-Skripte parsen das Log und tragen Adressen in eine Datenbank ein, die als Postfix-Check-Tabelle vor jedem Versand abgefragt wird. Mailcow integriert Bounce-Tracking nativ über Rspamd und Postfix-Statistik-Module. Bei transaktionalen Sendern empfiehlt sich Webhook-basiertes Bounce-Reporting (SendGrid Event Webhook, Postmark Bounce Webhook) — die Verarbeitung ist asynchron und skaliert.
Welche Tools zeigen meine Bounce-Statistik?
Für Self-Hosted: pflogsumm (Postfix-Log-Auswertung), Mailcow-Statistik, Rspamd-Dashboard. Für Cloud-Mail: Microsoft 365 Mail Flow Reports im Admin Center, Google Workspace Email Log Search. Für Email-Service-Provider: SendGrid Activity Feed, Mailchimp Reports, Postmark Activity, Brevo Statistics. Externe Reputations-Tools: Google Postmaster Tools (Domain-spezifische Bounce-Rate), Microsoft SNDS (IP-spezifische Bounce-Daten), Wolf-Agents Email Security Monitoring (Drift-Erkennung bei plötzlichem Bounce-Anstieg via Health-Check-Sweep alle 6 Stunden).