SMTP-Fehlercodes: Lexikon mit Bedeutung je Code

Ein SMTP-Fehlercode ist die Antwort, mit der ein Mailserver einen Schritt der Zustellung quittiert oder ablehnt. Er steht in jeder Unzustellbarkeitsmeldung, meist ganz unten im technischen Teil, und besteht fast immer aus zwei Zahlen hintereinander: 550 5.7.1. Die erste ist der Antwortcode aus RFC 5321, dreistellig. Die zweite ist der erweiterte Statuscode aus RFC 3463, drei Zahlen mit Punkten. Dahinter folgt ein freier Text, den jeder Server selbst formuliert.

Der dreistellige Code sagt, ob die Mail noch eine Chance hat. Der erweiterte Code sagt, warum nicht. Wer nur auf 550 schaut, weiß, dass es dauerhaft ist, aber nicht, ob die Adresse falsch ist, das Postfach gesperrt oder die eigene Domain als Fälschung gilt. Das steht in der zweiten Zahl und im Text dahinter.

Wie ein SMTP-Fehlercode aufgebaut ist#

Die erste Ziffer des dreistelligen Codes ist die wichtigste. RFC 5321 ordnet sie so:

Die Faustregel aus RFC 5321 für die Grenze zwischen 4 und 5: Ein Fehler ist vorübergehend, wenn die Mail beim nächsten Versuch ankommen kann, ohne dass jemand etwas ändert. Muss sich etwas ändern, die Adresse, die Domain, der Inhalt, ist er dauerhaft.

Der erweiterte Code hat die Form Klasse.Bereich.Detail. Die Klasse wiederholt die erste Ziffer (2, 4 oder 5). Der Bereich in der Mitte sagt, wo das Problem liegt, und das IANA-Register sagt gleich dazu, wer nach der Logik des Standards zuständig ist:

X.7 ist der Bereich, in dem die meisten Probleme einer kleinen Firma landen: Sperrlisten, fehlende Anmeldung, SPF, DKIM, DMARC.

Wer den Fehler beheben muss#

Das steht nicht im Code, sondern daneben. Ein Rückläufer nennt den Server, der abgelehnt hat, im maschinenlesbaren Teil als Remote-MTA, im lesbaren Teil oft als „host … said“ oder „Remote server returned“. Drei Fälle:

1. Der Server gehört dem Empfänger. Dann hat er deine Mail gesehen und abgelehnt, und der Grund steht im Code. Bei X.1 und X.2 liegt es an der Adresse oder am Postfach, bei X.7 meist an deiner Domain oder deinem Server.
2. Der Server gehört deinem eigenen Anbieter. Dann ist die Mail nie hinausgegangen. Typisch sind 535 5.7.8 (Anmeldung abgelehnt) und Sperren wegen Spamverdacht auf dem eigenen Konto. Der Empfänger weiß davon nichts.
3. Es steht gar kein fremder Server da, sondern nur, dass die Zustellung nach Tagen aufgegeben wurde. Das ist ein abgelaufener 4xx-Fall, Ursache meist ein Server, der nicht erreichbar war.

Wie man den Rückläufer und die Header dabei liest, steht in E-Mail abgelehnt: 550 5.7.1. Kommt gar kein Rückläufer und die Mail ist trotzdem nicht da, ist das ein anderer Fall: E-Mail kommt nicht an.

Die 4xx-Codes: vorübergehend#

Ein 4xx ist keine Ablehnung, sondern ein „später“. Dein Server stellt die Mail zurück und versucht es erneut. Einen Rückläufer bekommst du erst, wenn er aufgibt, oft mit einem Hinweis auf Verzögerung vorher. Handeln musst du nur, wenn derselbe Code über Stunden wiederkommt.

421 Dienst nicht verfügbar#

Der Server schließt die Verbindung, laut RFC 5321 möglich als Antwort auf jeden Befehl, wenn er weiß, dass er herunterfahren muss. In der Praxis auch eine Bremse: Gmail antwortet mit 421 4.7.28, wenn von einer Adresse ungewöhnlich viele Mails kommen, und begrenzt die Rate vorübergehend. Nächster Schritt: nichts, solange es Einzelfälle sind. Bei Massenversand die Menge pro Stunde senken.

450 Postfach vorübergehend nicht verfügbar#

„Mailbox busy or temporarily blocked for policy reasons“, so RFC 5321. Dahinter steckt oft Greylisting: Der Empfänger lehnt eine unbekannte Kombination aus Absender und Server beim ersten Mal ab und nimmt sie beim zweiten Versuch an. Gmail nutzt 450 4.2.1, wenn ein Empfänger zu viele Mails in kurzer Zeit bekommt. Nächster Schritt: abwarten. Was Greylisting genau ist, steht in E-Mail kommt nicht an.

451 Lokaler Fehler#

Der Empfänger hatte beim Verarbeiten ein Problem, oft beim Nachschlagen im DNS. Der erweiterte Code 4.4.3 steht für einen nicht erreichbaren Verzeichnis- oder DNS-Server, 4.7.24 für einen Fehler beim Auswerten von SPF (RFC 7372). Bei Letzterem lohnt ein Blick auf den eigenen SPF-Eintrag, denn ein Eintrag mit zu vielen Abfragen kann beim Empfänger genau diesen Fehler auslösen. Den Stand zeigt der E-Mail-Check.

452 Zu wenig Speicher#

Das Postfach oder der Server ist voll. Gmail schreibt dazu bei 452 4.2.2, das Postfach des Empfängers habe keinen Speicher mehr. Nächster Schritt: Empfänger auf anderem Weg informieren, sonst nichts.

454 Vorübergehender Fehler bei Anmeldung oder Verschlüsselung#

Mit 454 4.7.0 meldet ein Server laut RFC 4954 einen vorübergehenden Fehler bei der Anmeldung, ausdrücklich nicht ein falsches Passwort. Das Mailprogramm soll dann nicht nach dem Passwort fragen, sondern den Fehler melden. Nächster Schritt: später erneut senden; hält es an, den eigenen Anbieter fragen.

4.4.1 und 4.4.7: keine Antwort, abgelaufen#

4.4.1 heißt, der Zielserver hat auf den Verbindungsversuch nicht geantwortet. 4.4.7 heißt bei Microsoft 365, die Mail lag zu lange in der Warteschlange, bevor sie zugestellt werden konnte. Beide Codes landen im Rückläufer, wenn der sendende Server nach Tagen aufgibt. Ursache ist fast immer der Empfänger: Server weg, MX-Eintrag falsch, Domain abgelaufen. Ob der MX der Gegenseite stimmt, zeigt eine MX-Abfrage; was dort stehen sollte, erklärt MX-Eintrag.

Die 5xx-Codes: dauerhaft#

Ein 5xx heißt, die Mail ist zurück, und ohne Änderung kommt sie auch beim zehnten Versuch nicht an.

500 bis 504: Protokollfehler#

500 Befehl unbekannt, 501 Fehler in den Parametern, 502 Befehl nicht umgesetzt, 503 falsche Reihenfolge, 504 Parameter nicht unterstützt. Diese Codes betreffen nicht dich als Absender, sondern das Programm, das mit dem Server spricht: ein Drucker, ein Kontaktformular, ein selbst gebautes Skript. Nächster Schritt: Einstellungen des Geräts oder der Software prüfen, meist Port, Verschlüsselung oder Anmeldeverfahren.

530 und 535: Anmeldung#

530 5.7.0 heißt laut RFC 4954 „Anmeldung erforderlich“: Der Server nimmt die Mail erst nach einer Anmeldung an. 535 5.7.8 heißt, die Zugangsdaten sind falsch oder reichen nicht. Beides kommt vom eigenen Ausgangsserver. Microsoft 365 meldet den ersten Fall als 5.7.57, wenn ein Gerät oder eine Anwendung über smtp.office365.com ohne gültige Anmeldung senden will. Nächster Schritt: Benutzername, Passwort und Anmeldeverfahren im sendenden Programm prüfen. Kommt 535 plötzlich bei einem Konto, das gestern noch ging, kann der Anbieter das Konto gesperrt haben, etwa nach Verdacht auf Missbrauch. Das klärt nur der Anbieter.

550 Postfach nicht verfügbar oder Richtlinie#

Der häufigste Code überhaupt, und deshalb der ungenaueste. RFC 5321 nennt drei Gründe in einem Satz: Postfach nicht gefunden, kein Zugriff, oder abgelehnt aus Richtliniengründen. Welcher es ist, steht im erweiterten Code: 5.1.1 heißt Adresse unbekannt, 5.7.1 Richtlinie, 5.7.26 fehlende Authentifizierung. Ohne den erweiterten Code bleibt nur der Text.

551 Empfänger nicht lokal#

Der Server ist für diese Adresse nicht zuständig und nennt gegebenenfalls eine andere. In der Praxis selten; heute antworten Server in diesem Fall meist mit 550 5.7.1 oder 5.4.1.

552 Speicher überschritten#

Das Postfach ist voll oder die Mail zu groß. 5.2.2 heißt Postfach voll, 5.3.4 Nachricht größer als die Grenze des Systems. Gmail meldet 552 5.2.2 mit dem Zusatz, das Postfach sei voll und inaktiv. Nächster Schritt: bei 5.3.4 Anhang verkleinern oder als Link schicken, bei 5.2.2 den Empfänger anders erreichen.

553 Adresse nicht erlaubt#

Die Adresse ist syntaktisch falsch oder der Server lehnt sie ab. Häufig kommt 553 vom eigenen Ausgangsserver, wenn die Absenderadresse nicht zum angemeldeten Konto passt, etwa bei einem Kontaktformular, das im Namen des Besuchers senden will. Nächster Schritt: Absender auf eine eigene Adresse setzen, den Besucher als Antwortadresse (Reply-To).

554 Transaktion gescheitert#

Der Sammelcode für „nein“, laut RFC 5321 auch die Antwort beim Verbindungsaufbau, wenn ein Server gar keine Mails annehmen will. Viele Sperrlisten-Ablehnungen kommen mit 554, ebenso die Spamfilter-Ablehnung nach dem Inhalt. Postfix etwa lehnt bei einem Treffer auf einer DNS-Sperrliste standardmäßig mit 554 ab. Was bei 554 5.7.1 zu tun ist, steht in E-Mail abgelehnt: 550 5.7.1 und 554 5.7.1. Ob dein Server auf einer Sperrliste steht, zeigt der Blacklist-Check.

521 und 556: Domain nimmt keine Mail an#

Beide stammen aus RFC 7504. 521 sendet ein Server beim Verbindungsaufbau, der grundsätzlich keine Mail annimmt. 556 meldet ein Zwischenserver, wenn er schon vorher weiß, dass die Zieldomain keine Mail annimmt, etwa weil sie einen „Null-MX“ nach RFC 7505 veröffentlicht. Der passende erweiterte Code ist 5.1.10. Nächster Schritt: Die Adresse gibt es nicht, auch wenn die Domain existiert. Empfänger nach der richtigen fragen.

Die erweiterten Codes, die man kennen sollte#

5.1.1 Adresse unbekannt#

Laut IANA-Register: Das Postfach existiert nicht, der Teil vor dem @ ist ungültig. Fast immer ein Tippfehler oder eine Adresse, die es nicht mehr gibt. Gmail schreibt dazu, das Konto existiere nicht, und rät, auf Tippfehler und überzählige Leerzeichen zu prüfen. Nächster Schritt: Adresse prüfen, bei Newslettern sofort austragen.

5.1.2 Zieldomain ungültig#

Der Teil nach dem @ nimmt keine Mail an oder existiert nicht. Häufig: Tippfehler in der Domain, abgelaufene Domain, fehlender MX-Eintrag.

5.2.2 Postfach voll#

Laut RFC 3463 ein Fall, den der Empfänger durch Löschen lösen kann. Er wird deshalb oft auch als 4.2.2 gemeldet, und die Mail kommt später doch an.

5.4.1 Zugriff verweigert oder Relay verweigert#

Bei Microsoft 365 zwei Texte unter demselben Code: „Recipient address rejected: Access denied“ heißt, der Empfänger existiert in diesem Microsoft-365-Mandanten nicht; „Relay Access Denied“ heißt, der Server ist für die Zieldomain nicht zuständig, meist nach einem Umzug mit falschem MX. Beide Fälle mit Ursachen und Zuständigkeit stehen in 550 5.4.1 Recipient address rejected.

5.7.1 Zustellung nicht erlaubt#

Laut IANA-Register: Der Absender darf nicht an dieses Ziel senden, als Ergebnis einer Filterung je Server oder je Empfänger. Das reicht von einer Verteilerliste, die nur interne Absender annimmt, über eine Sperrliste bis zu einer Ablehnung wegen fehlender Authentifizierung. Gmail beschreibt seinen 550 5.7.1 so: Empfänger oder Domain haben eine Richtlinie, die diese Mail verbietet. Was im Einzelfall dahintersteht, erklärt E-Mail abgelehnt: 550 5.7.1.

5.7.8 Zugangsdaten ungültig#

Antwort des eigenen Ausgangsservers auf die Anmeldung (RFC 4954): Benutzername oder Passwort stimmen nicht, oder sie reichen für diesen Versand nicht. Das Mailprogramm soll dann neue Zugangsdaten verlangen. Ändert ein neues Passwort nichts, ist das Konto beim Anbieter gesperrt.

5.7.23 SPF fehlgeschlagen#

RFC 7372 hat eigene Codes für die Authentifizierung eingeführt, damit Empfänger nicht alles unter 5.7.1 melden. 5.7.23 heißt: Die SPF-Prüfung ergab fail, und der Empfänger lehnt solche Mails ab. Ursache ist fast immer ein Versandweg, der im SPF-Eintrag fehlt. Nächster Schritt: den Eintrag mit dem E-Mail-Check lesen und den fehlenden Dienst ergänzen.

5.7.25 Reverse DNS fehlgeschlagen#

Die IP-Adresse des sendenden Servers hat die Prüfung des Reverse DNS nicht bestanden. Gmail formuliert es konkreter: Die sendende Adresse hat keinen PTR-Eintrag, oder der Name im PTR-Eintrag zeigt nicht zurück auf die Adresse. Das betrifft eigene Mailserver und Webserver, die direkt senden. Wer den PTR-Eintrag setzt und wie man ihn prüft, steht in PTR-Record.

5.7.26 Mehrere Prüfungen fehlgeschlagen#

Im IANA-Register: Die Mail hat mehr als eine Authentifizierung nicht bestanden, ohne dass gesagt wird, welche. Gmail verwendet 550 5.7.26 für Mails, deren Absender nicht authentifiziert ist, und verlangt SPF oder DKIM. Praktisch heißt das: Die Mail ließ sich deiner Domain nicht zuordnen. Wie man herausfindet, ob es an SPF, DKIM oder dem Abgleich mit der Absenderadresse liegt, steht in dmarc=fail trotz SPF und DKIM pass.

Weitere Codes in Kürze#

Eine Warnung zur Tabelle: Nicht jeder Anbieter hält sich an das Register. Gmail benutzt 550 5.7.27 für Mails, die SPF nicht bestehen, nicht für den Null-MX aus RFC 7505. Microsoft 365 hat eigene Codes oberhalb von 5.7.500, etwa 5.7.509 für eine Absenderdomain, die DMARC nicht besteht und p=reject veröffentlicht, oder 5.7.708 für gesperrten Verkehr von einer Adresse. Im Zweifel gilt die Erklärung des Anbieters, der abgelehnt hat.

Was nicht hilft#

Bei 5xx stumpf erneut senden. RFC 5321 sagt ausdrücklich, dass der Client dieselbe Anfrage nicht wiederholen soll. Eine Mail, die wegen fehlender Authentifizierung abgelehnt wurde, scheitert beim zweiten Mal genauso, und viele erneute Versuche können die eigene Adresse erst recht auf eine Sperrliste bringen.

Bei 4xx sofort nachfassen. Der eigene Server versucht es von selbst, über Stunden und Tage. Wer die Mail in der Zwischenzeit händisch noch einmal schickt, bekommt im besten Fall zwei Zustellungen.

Den Text ignorieren und nur die Zahl googeln. Derselbe Code bedeutet bei Gmail, Microsoft und einem kleinen Hoster Verschiedenes. Der freie Text dahinter ist oft die einzige Stelle, an der der Empfänger den Grund nennt, manchmal mit Link zu seiner Erklärung.

Jeden Rückläufer als falsche Adresse werten. Kommt der Code vom eigenen Anbieter oder lautet er 5.7.x, ist die Adresse in Ordnung. Wer dann austrägt, verliert funktionierende Kontakte und übersieht den eigentlichen Fehler.

Den Spamfilter des Empfängers verantwortlich machen, bevor die eigene Domain geprüft ist. Die meisten 5.7-Ablehnungen bei großen Empfängern haben mit SPF, DKIM, DMARC oder dem Ruf der sendenden Adresse zu tun. Den Stand zeigt in einer halben Minute der E-Mail-Check, warum Mails trotz Zustellung im Spam landen, erklärt Warum landen meine Mails im Spam?. Steht die Adresse auf einer Liste, die ganze Provider sperrt, ist UCEPROTECT die häufigste Erklärung.

Häufige Fragen#

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Ein großer Teil der 5.7-Rückläufer hat seine Ursache in der eigenen Domain. Der E-Mail-Schutz für 390 € richtet SPF, DKIM und DMARC beim bestehenden Anbieter ein, schrittweise bis reject, ohne dass Newsletter oder Buchungssysteme hängen bleiben, mit vier Wochen Auswertung der DMARC-Berichte. Den Stand deiner Domain zeigt vorher kostenlos der E-Mail-Check, eine Sperrliste der Blacklist-Check.

Stand 13.10.2026. IANA-Register, RFC 5321, 3463, 4954, 7372, 7504 und 7505 sowie die Fehlerlisten von Gmail und Microsoft 365 an diesem Tag gelesen.