SMTP-Bounce-Codes verstehen: Was bedeuten 4xx- und 5xx-Fehlermeldungen bei der E-Mail-Zustellung?

Grundlagen: SMTP-Statuscodes, Enhanced Status Codes und die Trennung zwischen temporären (4xx) und permanenten (5xx) Fehlern

SMTP-Fehlermeldungen entstehen als Antworten eines SMTP-Servers auf einzelne Schritte im Zustellprozess (z. B. MAIL FROM, RCPT TO, DATA). Zentral sind dabei die dreistelligen SMTP-Statuscodes nach RFC 5321 sowie die präziseren Enhanced Status Codes nach RFC 3463. Für die Fehleranalyse entscheidet oft weniger der sichtbare Text als die Kombination aus numerischem Code, Enhanced Status Code und dem Protokollkontext: Ein identischer 5xx-Code kann je nach Phase eine ganz andere Ursache haben als in einer anderen SMTP-Command-Sequenz.

Wichtig ist außerdem die Trennung zwischen temporären und permanenten Fehlern. Temporäre Fehler signalisieren, dass eine erneute Zustellung später Erfolg haben kann; permanente Fehler deuten darauf hin, dass ein automatischer Retry ohne Veränderung der Rahmenbedingungen nicht zum Ziel führt. Mail-Transfer-Agents (MTAs) treffen darauf basierend ihre Retry- und Queue-Entscheidungen, während Mail-Provider häufig zusätzliche Hinweise in Freitext oder proprietären Erweiterungen liefern.

SMTP-Statuscodes: Aufbau und Aussagekraft der dreistelligen Codes

Der dreistellige SMTP-Code besteht aus einer ersten Ziffer für die Klasse (Erfolg, Zwischenstatus, temporärer Fehler, permanenter Fehler) und zwei weiteren Ziffern, die den Fehler grob kategorisieren. In der Praxis dominieren Antworten der Klassen 2xx, 4xx und 5xx. Klasse 3xx ist im SMTP-Protokoll eher selten und beschreibt Zwischenzustände, die zusätzliche Client-Aktionen erfordern.

Die zweite Ziffer differenziert typischerweise zwischen Syntax/Protokoll, Verbindungszustand, Mail-System-Status und Routing. Die dritte Ziffer verfeinert die Bedeutung, bleibt aber ohne Enhanced Status Code oft zu unspezifisch für eine zielgerichtete Gegenmaßnahme. Deshalb enthalten viele Serverantworten heute sowohl den dreistelligen Code als auch einen Enhanced Status Code in der Form x.y.z.

• 2xx (Success): Die Operation wurde akzeptiert; relevant sind u. a. 250 (OK) und 251 (User not local; will forward).
• 4xx (Transient Failure): Temporärer Fehler; die Zustellung bleibt typischerweise in der Queue und wird gemäß Retry-Plan erneut versucht, z. B. 421 (Service not available) oder 450/451/452 (Mailbox-/Serverzustand verhindert Annahme).
• 5xx (Permanent Failure): Dauerhafter Fehler; erneute Versuche ohne Korrektur scheitern, z. B. 550 (Requested action not taken: mailbox unavailable) oder 553 (Mailbox name not allowed).
• Kontextbezug: Eine Antwort auf RCPT TO bewertet meist Empfänger/Policy, eine Antwort auf DATA eher Content-/Policy-Checks (Spam, Malware, Authentisierung, Richtlinien), auch wenn der Code ähnlich aussieht.

Enhanced Status Codes (RFC 3463): Warum x.y.z die eigentliche Diagnose trägt

Enhanced Status Codes ergänzen den groben SMTP-Code um eine standardisierte, maschinenlesbare Klassifizierung. Die erste Ziffer des Enhanced Codes spiegelt die Fehlerklasse (2, 4, 5). Die zweite Ziffer beschreibt die Kategorie (z. B. Adressstatus, Mailboxstatus, Mail-System-Status, Netzwerk/Routing, Zustellung/Protokoll, Security/Policy). Die dritte Ziffer spezifiziert den Einzelfall. Viele Provider nutzen diese Codes konsistent, selbst wenn der Freitext variiert oder lokalisiert wird.

Für Log-Parsing und Automatisierung ist der Enhanced Status Code häufig stabiler als Freitext. Er erlaubt zudem eine klare Abgrenzung: 5.1.1 steht typischerweise für eine nicht existente Mailbox (permanent), 4.2.2 für ein temporär überfülltes Postfach. Auch sicherheits- und policybezogene Ablehnungen werden darüber deutlich, etwa 5.7.1 für „Delivery not authorized, message refused“ in unterschiedlichen Ausprägungen (Authentisierung, Reputation, Richtlinien).

Nachschlagewerk: Häufige Bounce-Codes und Serverantworten mit Bedeutung, Ursachen (SPF/DKIM/DMARC, Blacklisting, Postfach voll, Policies) und Gegenmaßnahmen

SMTP-Bounces bestehen in der Praxis aus einer numerischen Antwort (z. B. 550) und häufig zusätzlich aus einer erweiterten Statusmeldung nach RFC 3463 (z. B. 5.1.1). Erst die Kombination aus Code, Enhanced Status und dem Freitext der Gegenstelle liefert eine belastbare Diagnose: 550 5.1.1 weist typischerweise auf einen nicht existierenden Empfänger hin, während 550 5.7.1 meist eine Policy- oder Authentifizierungsentscheidung (z. b. DMARC, Spamfilter, Reputation) bezeichnet. Provider ergänzen diese Signale oft um interne IDs, URL-Hinweise oder Schlagworte wie blocked, rate limited oder policy.

Leseregeln: Was 4xx/5xx und Enhanced Status praktisch bedeuten

4xx-Antworten sind temporär: Die Zustellung kann bei späterem Versuch gelingen, etwa nach Greylisting, bei momentaner Überlast oder wenn ein Zielsystem kurzzeitig keine Annahme erlaubt. 5xx-Antworten gelten im SMTP-Sinn als permanent und sollten ohne Änderung an Inhalt, Authentisierung oder Zieladresse nicht erneut gesendet werden. Enhanced Status Codes präzisieren die Kategorie: x.1.x adressiert meist die Adresse/den Empfängerstatus, x.2.x das Zielsystem (Quota, Ressourcen), x.3.x Mail-System-Status, x.4.x Routing/Netzwerk, x.5.x Mail-Delivery-Protokollstatus und x.7.x Policies, Authentisierung und Sicherheitsentscheidungen.

• Temporär (4xx): Wiederholungsversuche mit Backoff sind sinnvoll; parallel Ursachen prüfen, z. b. Greylisting (451 4.7.1), Rate Limits (421 4.7.0) oder DNS-Transienten (451 4.4.0).
• Permanent (5xx): Re-Send erst nach Korrektur; häufige Klassen sind 550 5.1.1 (Empfänger unbekannt), 552 5.2.2 (Mailbox voll) oder 550 5.7.1 (Policy/Authentisierung).
• Provider-Erweiterungen: Freitext wie SPF fail, DKIM=fail, DMARC=reject, rDNS missing oder Links auf Providerportale sind oft entscheidungsrelevant und sollten zusammen mit dem Zeitpunkt und der sendenden IP protokolliert werden.

Tabelle: Häufige SMTP-Codes und Gegenmaßnahmen (kompakt, aber praxisnah)

Typische Fehlerbilder nach Ursache: schnelle Zuordnung aus dem Freitext

Viele Serverantworten enthalten Schlüsselwörter, die unabhängig vom SMTP-Code eine klare Richtung vorgeben. Bei Authentisierung und Domain-Alignment ist der Kontext entscheidend: Ein scheinbar generisches 550 5.7.1 kann sowohl eine DMARC-Entscheidung (DMARC policy reject) als auch eine IP-Sperre (blocked using oder listed) markieren. Ebenso ist „Mailbox full“ nicht immer 552; einige Provider signalisieren Quota-Probleme als 4.2.2 oder verpacken sie in 5.2.2.

• SPF: Hinweise wie SPF fail, sender SPF unauthorized oder not permitted to send; Gegenmaßnahmen: korrekten Return-Path/Envelope-From ausrichten, SPF-Record aktualisieren (v=spf1 include:...), DNS-Propagation abwarten, Lookup-Limit (10) beachten.
• DKIM: Hinweise wie DKIM=fail, bad signature oder body hash did not verify; Gegenmaßnahmen: Signatur über ausgehenden MTA erzwingen, Header-/Body-Modifikationen durch Gateways minimieren, Selector/DNS (selector._domainkey) prüfen, Schlüsselrotation sauber durchführen.
• DMARC: Hinweise wie DMARC=fail, p=reject, alignment failed; Gegenmaßnahmen: sichtbare From-Domain und authentisierte Domain alignen, DKIM-Signing auf From-Domain, SPF mit passender Envelope-Domain; DMARC-Record (v=DMARC1; p=...) prüfen.
• Blacklisting/Reputation: Hinweise wie blocked, listed, rejected for policy reasons, teils mit URL/Case-ID; Gegenmaßnahmen: betroffene sendende IP identifizieren, Bounce-Log mit IP/Queue-ID korrelieren, Delisting gemäß Listenbetreiber, Versandhygiene (Spamfallen, Complaints) und Volumenrampe.
• Postfach voll / Konto inaktiv: Hinweise wie mailbox full, quota exceeded, user is over quota, account disabled; Gegenmaßnahmen: bei 4.2.2 zeitlich begrenzte Retries, bei 5.2.2 je nach Persistenz/Policy als Hard-Fail behandeln; Adresse in Verteilerpflege markieren.
• Provider-Policies (Inhalt/Transport): Hinweise wie message rejected, content rejected, unsupported attachment, TLS required; Gegenmaßnahmen: MIME-Struktur und Dateitypen prüfen, URL-Ziele (Redirects, Shortener) bereinigen, TLS-Konfiguration anpassen und Cipher-/SNI-Probleme ausschließen.

Präzise Gegenmaßnahmen: Diagnostikpunkte, die den Bounce tatsächlich erklären

Wirksame Fehlerbehebung orientiert sich an der SMTP-Transaktionsphase. Tritt der Fehler bereits bei RCPT TO auf, liegt er häufig in Adresse, Policy oder Reputation; bei DATA eher in Content-Scans, Größenlimits oder DMARC-Entscheidungen auf Basis der vollständigen Nachricht. Für Authentisierung und Domain-Reputation sind insbesondere Envelope-From, sichtbares From, DKIM-Signing-Domain und die sendende IP samt Reverse DNS gemeinsam zu betrachten. Provider-spezifische Referenzen (Ticket-/Error-IDs) sollten unverändert übernommen werden, da sie die interne Nachverfolgung ermöglichen.

• DNS- und Alignment-Checks: dig TXT example.com
dig TXT _dmarc.example.com
dig TXT selector._domainkey.example.com
• SPF-Auswertung (sichtbar machen): Headeranalyse auf Received-SPF und Authentication-Results; bei eigenem MTA sicherstellen, dass MAIL FROM zur SPF-autorisierten Domain passt (kein ungeplantes Rewriting durch Relays).
• DKIM/DMARC-Validierung: Authentication-Results auf dkim=pass/dmarc=pass; bei wiederholten body hash-Fehlern nachträgliche Modifikationen (Disclaimer, Link-Rewriting) eliminieren oder Signing erst nach diesen Eingriffen durchführen.
• Reputation und Blockhinweise operationalisieren: Bounce-Freitext nach Tokens wie listed, block, bulk klassifizieren; sendende IP und Zeitpunkt pro Queue-ID korrelieren, um betroffene Versandströme abzugrenzen.
• Retry-Strategie anpassen: Bei 421/451 Retries mit Backoff und Jitter; bei 5.1.1 und konsistenten 5.7.1 ohne inhaltliche/konfigurationsseitige Änderung keine erneuten Zustellversuche auslösen.

Provider- und Gateway-Spezifika: Erweiterte Diagnosen, Log-Korrelation, Retry- und Remediation-Strategien im Betrieb

SMTP-Fehlerbilder verändern sich deutlich, sobald zwischen absenden­dem System und Zielprovider zusätzliche Stationen stehen: ausgehende Relays, Secure-E-Mail-Gateways (SEG), Cloud-Filter, Tenant-Grenzen oder vorgeschaltete Anti-Spam-Systeme. In solchen Ketten ist der in der Bounce-Nachricht sichtbare Code oft nur die „letzte“ Antwort; die eigentliche Ursache liegt in einer vorgelagerten Policy-Entscheidung oder einer temporären Schutzmaßnahme (Greylisting, Rate Controls). Belastbare Diagnosen entstehen erst durch das Zusammenführen von SMTP-Dialog, Queue-Status, Provider-spezifischen Hinweisen und korrespondierenden Log-IDs.

Provider-typische Erweiterungen: Wenn der Code allein nicht reicht

Viele Provider ergänzen den numerischen SMTP-Code um erweiterte Statuscodes nach RFC 3463/5248 (z. B. 5.7.1) und um Freitext, der interne Klassifizierungen oder URLs zu Postmaster-Ressourcen enthält. Für den Betrieb ist entscheidend, diese Zusätze konsistent zu extrahieren und zu normalisieren, statt ausschließlich auf den dreistelligen Code zu reagieren. Ein 550 kann je nach Kontext „User unknown“, „Policy rejection“, „Blocked“ oder „Authentication required“ bedeuten; erst die Kombination aus 5.X.Y und Text liefert die verwertbare Kategorie.

Gateways verändern zudem den sichtbaren Absenderpfad: Die Verbindung zur Zielseite kommt dann von einer Relay-IP, während die Reputation und Authentisierung auf der Absenderdomain beruhen. In diesen Fällen muss zwischen Transport-Identität (sendende IP, HELO/EHLO-Name) und Identität auf Inhalts-/Header-Ebene (From, SPF, DKIM, DMARC) getrennt werden, weil Provider ihre Entscheidungen entlang unterschiedlicher Signale treffen.

Log-Korrelation über die Zustellkette: Message-ID, Queue-ID, Trace-Header

Für reproduzierbare Analysen braucht es eine stabile Korrelation von Ereignissen: vom Applikations-Event über MTA-Queue und Gateway-Tracking bis zur finalen Provider-Antwort. Geeignet sind persistente Message-IDs (Header), interne Queue-IDs des MTAs und Correlation-IDs, die Gateways in Headern oder Logs ausgeben. Wo möglich, sollte die Bounce-Verarbeitung nicht nur den SMTP-Code speichern, sondern auch die komplette Remote-Antwortzeile, den Zeitpunkt, den Ziel-MX, die verwendete Absender-IP und den TLS-Status, weil genau diese Details bei Provider-Supportfällen abgefragt werden.

• Header-basierte Korrelation: Persistenz und Durchreichung von Message-ID; zusätzliches internes Tagging über X-Correlation-ID oder X-Entity-Ref-ID (sofern die Mail-Infrastruktur das unverändert transportiert).
• MTA-Queue- und Delivery-Events: Abgleich der Queue-ID mit Versandlogs und Zustellversuchen; bei Postfix typischerweise über postqueue -p und postcat -q QUEUEID; bei systemd-journald-Setups ergänzend über journalctl -u postfix.
• Gateway-Tracking: SEG-/Cloud-Gateway-Logs anhand der vom Gateway vergebenen Message-Trace-ID; bei Bedarf Export in SIEM und Join mit MTA-Events über Message-ID und Zeitfenster (Clock-Drift prüfen, NTP erzwingen).
• Provider-Rückkanäle: Auswertung von Feedback-Loops, Postmaster-Dashboards und Block-/Delist-Portalen, sofern angeboten; Verlinkungen aus Bounce-Texten als Erstindikator speichern, jedoch nicht automatisiert „blind“ ausführen.

In Multi-Tenant-Szenarien ist außerdem relevant, ob ein Gateway unterschiedliche Absender-Domains über gemeinsame IP-Pools ausliefert. Dann können Provider-Drosselungen oder Blöcke tenantspezifisch erscheinen, technisch aber durch „Neighbor Reputation“ ausgelöst werden. Operativ hilft eine Trennung nach IP-Pools oder eine strengere Rate-Limitierung je Absenderdomain, um die Fehlerdomänen zu verkleinern.

Retry-Strategien: Differenzierung nach Fehlerklasse, Provider-Policy und Zeit

Retry-Logik muss die Semantik der Antworten respektieren: 4xx bedeutet grundsätzlich temporär, kann aber bei wiederholtem Auftreten auf ein dauerhaftes Policy-Problem hindeuten (z. B. kontinuierliches Throttling durch zu hohe Versandrate). 5xx gilt als permanent, dennoch existieren Grenzfälle wie falsch klassifizierte Policies oder kurzzeitige Blockierungen, die bei zu aggressiver Hard-Bounce-Behandlung unnötige Zustellverluste verursachen. Bewährt hat sich eine regelbasierte Einordnung, die numerischen Code, erweiterten Status, Textmuster und Wiederholungsraten kombiniert.

• Backoff und Jitter: Exponentielles Backoff mit Zufallskomponente, um Lastspitzen zu vermeiden; technische Steuerung über MTA-/Job-Queue-Parameter wie maximal_backoff_time, minimal_backoff_time und queue_run_delay (MTA-spezifisch dokumentationskonform setzen).
• Retry-Fenster nach Kategorie: Greylisting (451) typischerweise mit kurzen Retries über mehrere Stunden; Quota/„mailbox full“ (4.2.2) mit längeren Abständen und harter Obergrenze; Rate-Limits (421/4.7.0) mit sofortiger Reduktion der Parallelität und schrittweiser Erhöhung nach Stabilisierung.
• Early-Abort bei eindeutigen Hard-Bounces: Bei 5.1.1 oder stabilen „user unknown“-Signaturen direkte Suppression, um Reputation und Kosten zu schützen; Ausnahmen nur, wenn ein Adress-Lookup nachweislich fehlerhaft war (z. B. kürzlich geänderte Alias-Regeln).
• Adaptive Ratensteuerung: Versand pro Provider-Domain/MX-Gruppe drosseln; Steuerung über getrennte Transport-Pools oder smarte Scheduler, die Rücklaufquoten für 4xx und Provider-spezifische „throttle“-Indikatoren berücksichtigen.

Für Gateways, die Antworten maskieren oder umschreiben, ist der Zeitpunkt der Ablehnung zentral: Wird bereits während RCPT TO oder DATA abgewiesen, spricht das eher für Empfänger-/Policy-Checks; spätere NDRs (DSNs) nach erfolgreicher Annahme deuten auf nachgelagerte Content-Scans oder interne Zustellpfade beim Provider. Diese Unterscheidung beeinflusst die Priorisierung der Remediation (Adresshygiene versus Authentisierung/Content versus Reputation).

Remediation im Betrieb: Von Auth-Alignment bis Entstörung in Gateways

Bei providergetriebenen Policies sind Gegenmaßnahmen am wirksamsten, wenn sie entlang der tatsächlichen Ablehnungsursache ansetzen. Dafür müssen Bounce-Kategorien mit technischen Kontrollen verknüpft werden: Authentisierung (SPF/DKIM), Alignment (DMARC), Transport (TLS, HELO/EHLO-FQDN, PTR), Reputation (IP/Domain), Inhaltsrisiken (URLs, Attachments) sowie Listen- und Consent-Qualität. In Gateway-Umgebungen kommen zusätzliche Fehlerquellen hinzu: Header-Rewriting, S/MIME- oder TLS-Interception, Anhangsmodifikation, URL-Rewriting und Quarantäne-Flows, die zu unerwarteten Signaturen oder False Positives führen.

• Auth- und Alignment-Fixes priorisieren: Bei 5.7.1-Policies erst prüfen, ob SPF für die tatsächlich sendende IP passt, ob DKIM-Signaturen nach Gateway-Verarbeitung noch valide sind und ob DMARC Alignment zwischen From und DKIM/SPF besteht; Gateways dürfen signierte Header nicht unerwartet verändern.
• Gateway-Einfluss isolieren: Kontrollversand über einen Bypass-Transport oder einen separaten Connector, um zu unterscheiden, ob Ablehnungen durch Gateway-Modifikationen entstehen; die Route muss auditierbar bleiben, z. B. über getrennte Next-Hops und klar erkennbare Received-Ketten.
• Reputation und Blocklisten sauber trennen: IP-Block, Domain-Block und URL-Block gesondert behandeln; Delisting nur mit verifizierten Nachweisen aus Provider-/RBL-Hinweisen, nicht aus generischen Bounce-Texten. Änderungen an IP-Pools oder Absenderdomänen sollten versioniert werden, um Effekte später zu korrelieren.
• Operative Playbooks pro Provider: Wiederkehrende Textmuster (z. B. „TLS required“, „authentication required“, „suspected spam“) in Regeln überführen und mit konkreten Prüfpunkten verknüpfen; für Eskalationen relevante Artefakte bündeln: Remote-Antwort, Ziel-MX, Zeitstempel, sendende IP, Message-ID, vollständige Header.

Im Regelbetrieb ist schließlich die Konsistenz der Messpunkte entscheidend: Bounce-Raten sollten nach Provider, Fehlerklasse (4xx/5xx), erweitertem Status (5.7.1 etc.) und Versandroute (IP-Pool/Gateway) segmentiert werden. Erst diese Zerlegung ermöglicht belastbare Entscheidungen über Rate-Limits, Pool-Separation oder gezielte Authentisierungs- und Content-Anpassungen, ohne pauschal in die Zustelllogik einzugreifen.