117 von 117 Codes
Basis-Antwortcodes
Systemstatus oder System-Hilfeantwort. In der Praxis selten verwendet.
Hilfemeldung als Antwort auf den Befehl HELP, mit Informationen zur Nutzung des Servers oder eines bestimmten Befehls.
Begrüßung des Servers beim Verbindungsaufbau: Der Dienst ist bereit. Antwortet auch auf STARTTLS, um anzuzeigen, dass die TLS-Aushandlung beginnen kann.
Der Server schließt die Verbindung, normalerweise als Antwort auf den Befehl QUIT.
Die Authentifizierung per AUTH war erfolgreich. Wird meist vom erweiterten Code 2.7.0 begleitet.
Die angeforderte Aktion wurde abgeschlossen. Die übliche Antwort auf EHLO, MAIL FROM, RCPT TO und am Ende von DATA, wenn der Server die Nachricht annimmt.
Der Empfänger ist nicht lokal, aber der Server nimmt die Nachricht an und leitet sie an die angegebene Adresse weiter.
Der Server bestätigt nicht, ob der Benutzer existiert (VRFY ist deaktiviert, um das Ausspähen von Konten zu verhindern), nimmt die Nachricht aber an und versucht, sie zuzustellen.
Antwort auf ETRN: Der Server hat begonnen, die Nachrichten aus der Warteschlange für die angeforderte Domain bzw. den Knoten zuzustellen.
Base64-codierte Challenge des Servers während AUTH. Der Client muss mit dem nächsten Wert des Mechanismus antworten (zum Beispiel Benutzername oder Passwort bei AUTH LOGIN).
Antwort auf DATA: Der Server erwartet den Nachrichteninhalt, der mit einer Zeile endet, die nur einen Punkt enthält.
Der Dienst ist nicht verfügbar und der Server schließt die Verbindung: Herunterfahren, Überlastung, zu viele Verbindungen oder ein vorübergehendes Sendelimit. Der Absender soll es später erneut versuchen.
Der Benutzer muss sein Passwort ändern oder zu einem anderen Authentifizierungsmechanismus wechseln, bevor er sich anmelden kann. Wird vom erweiterten Code 4.7.12 begleitet.
Das Postfach ist vorübergehend nicht verfügbar: belegt, gesperrt oder durch Richtlinien vorübergehend abgelehnt. Greylisting antwortet meist mit diesem Code oder mit 451.
Die Aktion wurde wegen eines lokalen Serverfehlers abgebrochen, etwa einer fehlgeschlagenen DNS-Abfrage oder eines Filters, der nicht geantwortet hat. Der Absender soll es später erneut versuchen.
Der Server hat momentan nicht genug Speicherplatz, um die Nachricht anzunehmen. Zeigt auch an, dass die Anzahl der Empfänger pro Nachricht überschritten wurde: Der Client muss die restlichen in einer weiteren Transaktion senden.
Vorübergehender Authentifizierungsfehler (zum Beispiel antwortet der Anmeldedaten-Server nicht) oder TLS ist bei STARTTLS vorübergehend nicht verfügbar.
Der Server kann die in MAIL FROM oder RCPT TO übergebenen Parameter derzeit nicht verarbeiten, könnte sie aber später akzeptieren.
Antwort auf ETRN: Der Server kann die Warteschlange des angeforderten Knotens derzeit nicht abarbeiten.
Antwort auf ETRN: Der angeforderte Knoten bzw. die Domain darf die Zustellung seiner Warteschlange nicht anfordern.
Der Server erkennt den Befehl nicht oder die Zeile ist zu lang. Wird auch von AUTH verwendet, wenn eine Zeile des Austauschs die zulässige Maximallänge überschreitet.
Der Befehl ist gültig, seine Parameter oder Argumente aber nicht: zum Beispiel eine falsch formatierte Adresse in MAIL FROM oder ein ungültiger Name bei EHLO.
Der Server erkennt den Befehl, hat ihn aber nicht implementiert oder deaktiviert, wie VRFY oder EXPN auf vielen Servern.
Die Befehle kamen in falscher Reihenfolge, zum Beispiel RCPT TO vor MAIL FROM oder DATA ohne gültige Empfänger. Manche Server geben ihn zurück, wenn ohne Authentifizierung gesendet werden soll.
Der Server unterstützt den angegebenen Parameter nicht, zum Beispiel einen AUTH-Mechanismus, den er nicht kennt.
Der Host nimmt keinerlei E-Mails an. Wird statt 220 als Begrüßung gesendet, und der Client soll es nicht erneut versuchen.
Der Server verlangt eine Authentifizierung oder den Start von TLS per STARTTLS, bevor er den Befehl annimmt. Typisch bei Nutzung des Submission-Ports 587 ohne Anmeldedaten.
Der gewählte Authentifizierungsmechanismus ist laut Serverrichtlinie zu schwach. Manche Anbieter geben ihn zurück, wenn sie App-Passwörter oder OAuth verlangen.
Benutzername oder Passwort falsch bzw. Anmeldedaten abgelehnt. Wird vom erweiterten Code 5.7.8 begleitet.
Der gewählte Authentifizierungsmechanismus ist nur über eine verschlüsselte Verbindung erlaubt: Zuerst muss STARTTLS ausgeführt werden.
Das Postfach existiert nicht oder ist nicht verfügbar, oder die Nachricht wurde aufgrund von Richtlinien abgelehnt (Spam, Blacklists, SPF, DKIM oder DMARC). Der begleitende erweiterte Code nennt die konkrete Ursache.
Der Empfänger ist nicht lokal und der Server leitet die Nachricht nicht weiter; er kann angeben, an welche Adresse sie zu senden ist.
Der zugewiesene Speicherplatz wurde überschritten: Das Postfach des Empfängers ist voll oder die Nachricht überschreitet die per SIZE-Erweiterung angekündigte Maximalgröße.
Die E-Mail-Adresse ist ungültig oder nicht zulässig, zum Beispiel wegen falscher Syntax oder weil der Absender diese Adresse nicht verwenden darf.
Die Transaktion ist fehlgeschlagen. Als Begrüßung bedeutet er, dass es für diesen Client keinen SMTP-Dienst gibt; nach DATA, dass die Nachricht abgelehnt wurde, oft wegen ihres Inhalts oder der Reputation des Absenders.
Der Server erkennt einen in MAIL FROM oder RCPT TO übergebenen Erweiterungsparameter nicht oder hat ihn nicht implementiert.
Die Domain des Empfängers veröffentlicht einen Null-MX (einen MX-Eintrag, der auf „.“ zeigt): Sie erklärt damit, keine E-Mails zu empfangen, daher ist ein erneuter Versuch sinnlos.
Erweiterte Statuscodes (RFC 3463)
Status ohne weitere Details: Wird verwendet, wenn nur die Klasse des Ergebnisses bekannt ist (Erfolg, vorübergehender oder permanenter Fehler).
Es gibt ein Problem mit einer Adresse der Nachricht, das zu keinem der spezifischeren Codes passt.
Das Postfach des Empfängers existiert auf dem Zielserver nicht. Der klassische Bounce wegen einer vertippten Adresse oder eines gelöschten Kontos.
Die Zieldomain bzw. das Zielsystem existiert nicht oder kann keine E-Mails annehmen, zum Beispiel weil die Domain nicht auflösbar ist.
Die Empfängeradresse hat eine ungültige Syntax.
Die Empfängeradresse passt auf mehr als ein Postfach im Zielsystem.
Die Empfängeradresse ist gültig. Erscheint als 2.1.5 in der positiven Antwort auf RCPT TO.
Das Postfach existierte, wurde aber verschoben, und es ist keine Weiterleitungsadresse bekannt.
Die Absenderadresse hat eine ungültige Syntax.
Die Domain des Absenders existiert nicht oder nimmt keine Antworten an, zum Beispiel weil sie weder MX- noch A-Einträge hat.
Die Nachricht wurde an ein System übergeben, das keine Statusbenachrichtigungen unterstützt, daher lässt sich die endgültige Zustellung nicht bestätigen.
Die Domain des Empfängers veröffentlicht einen Null-MX: Sie erklärt damit, keine E-Mails zu empfangen.
Das Postfach existiert, aber etwas im Zusammenhang damit hat die Zustellung verhindert, und es gibt keinen spezifischeren Code.
Das Postfach existiert, ist aber deaktiviert und nimmt keine Nachrichten an, zum Beispiel ein gesperrtes Konto.
Das Postfach des Empfängers hat sein Speicherkontingent überschritten.
Die Nachricht überschreitet die Maximalgröße, die der Empfänger erhalten darf.
Der Empfänger ist eine Verteilerliste, die nicht in ihre Mitglieder aufgelöst werden konnte.
Im Zielsystem ist ein Problem aufgetreten, das zu keinem der spezifischeren Codes passt.
Der Speicher des Ziel-Mailsystems ist voll.
Der Zielhost nimmt keine Nachrichten an, wegen eines bevorstehenden Herunterfahrens, Überlastung oder Wartung.
Das Zielsystem unterstützt eine Funktion nicht, die die Nachricht erfordert.
Die Nachricht überschreitet die Maximalgröße, die der Server für jeden Empfänger akzeptiert.
Das Zielsystem ist falsch konfiguriert und kann die Nachricht nicht annehmen.
Die Nachricht wurde angenommen, aber mit einer anderen als der angeforderten Priorität (Erweiterung MT-PRIORITY).
Es gab ein Netzwerk- oder Routingproblem, das zu keinem der spezifischeren Codes passt.
Der Zielserver hat beim Verbindungsversuch nicht geantwortet.
Die Verbindung wurde aufgebaut, brach aber ab oder wurde instabil, bevor die Zustellung abgeschlossen war.
Ein für die Zustellung nötiger Verzeichnisdienst ist ausgefallen, typischerweise die DNS-Auflösung.
Es wurde keine Route zum Ziel gefunden, zum Beispiel weil die Domain keine nutzbaren MX- oder A-Einträge hat.
Das Mailsystem ist überlastet und kann die Nachricht derzeit nicht verarbeiten.
Eine Routing-Schleife wurde erkannt: Die Nachricht hat zu oft dieselben Server durchlaufen.
Die maximale Zeit für Zustellversuche ist abgelaufen und die Nachricht wird verworfen, ohne zugestellt worden zu sein.
Es gab ein Problem mit dem Zustellprotokoll, das zu keinem der spezifischeren Codes passt.
Der Befehl ist ungültig, zu diesem Zeitpunkt nicht erlaubt oder unbekannt.
Der Befehl enthält einen Syntaxfehler und der Server kann ihn nicht interpretieren.
Die Nachricht hat mehr Empfänger, als der Server in einer Transaktion akzeptiert.
Der Befehl ist gültig, seine Argumente aber nicht oder sie werden nicht unterstützt.
Zwischen Client und Server besteht eine Inkompatibilität der Protokollversion.
Eine Zeile des AUTH-Austauschs überschreitet die maximale Länge, die der Server zulässt.
Es gab ein Problem mit dem Nachrichteninhalt, das zu keinem der spezifischeren Codes passt.
Das Ziel unterstützt den Inhaltstyp der Nachricht oder eines ihrer Anhänge nicht.
Für die Zustellung müsste der Inhalt konvertiert werden, aber der Absender hat das untersagt.
Für die Zustellung müsste der Inhalt konvertiert werden, und der Server kann das nicht.
Die Nachricht wurde zugestellt, aber bei der Konvertierung des Inhalts gingen Informationen verloren.
Die Konvertierung des Nachrichteninhalts ist fehlgeschlagen.
Der per URL referenzierte Nachrichteninhalt konnte nicht abgerufen werden (Erweiterung BURL).
Absender oder Empfänger unterstützen keine Adressen mit Nicht-ASCII-Zeichen (internationalisierte E-Mail, SMTPUTF8).
Der Server muss mit UTF-8-Text antworten, aber der Client hat keine SMTPUTF8-Unterstützung angekündigt.
Die Nachricht enthält UTF-8-Header und kann nicht an einen oder mehrere Empfänger übertragen werden, die diese nicht unterstützen, daher wird sie abgelehnt.
Sicherheitsstatus ohne weitere Details. Erscheint bei erfolgreicher Authentifizierung (2.7.0), bei vorübergehenden AUTH-Fehlern (4.7.0) und bei Ablehnungen aufgrund von Richtlinien.
Der Absender ist nicht berechtigt, an diesen Empfänger zu senden: Sperre wegen Blacklist, Reputation, Spamfilter oder unerlaubtem Relay-Versuch. In der Variante 4.7.1 weist er meist auf Greylisting hin.
Der Absender darf nicht an diese Verteilerliste senden.
Die Nachricht müsste von einem Sicherheitsprotokoll in ein anderes konvertiert werden, was nicht möglich ist.
Die Nachricht erfordert Sicherheitsfunktionen, die das Ziel nicht unterstützt.
Eine kryptografische Operation beim Transport ist fehlgeschlagen, zum Beispiel die Prüfung einer Signatur oder die Entschlüsselung.
Das Ziel unterstützt den in der Nachricht verwendeten kryptografischen Algorithmus nicht.
Die Integritätsprüfung ist fehlgeschlagen: Die Nachricht wurde unterwegs verändert oder die Prüfsumme stimmt nicht.
Die Anmeldedaten sind ungültig: Benutzername oder Passwort falsch.
Der gewählte Authentifizierungsmechanismus ist schwächer, als die Serverrichtlinie verlangt.
Für den angeforderten Authentifizierungsmechanismus ist eine externe Verschlüsselungsschicht wie TLS nötig. Gedacht vor allem für Mechanismen, die das Passwort im Klartext senden.
Der angeforderte Authentifizierungsmechanismus ist nur über eine verschlüsselte Verbindung erlaubt.
Der Benutzer muss sein Passwort ändern oder zu einem anderen Authentifizierungsmechanismus wechseln.
Das Konto des Benutzers, der sich anmelden will, ist deaktiviert.
Der Server nimmt nur Nachrichten von Systemen an, zu denen eine etablierte Vertrauensbeziehung besteht.
Die Priorität der Nachricht ist zu niedrig, um sie derzeit anzunehmen (Erweiterung MT-PRIORITY).
Die Nachricht ist für die angegebene Priorität zu groß (Erweiterung MT-PRIORITY).
Das Postfach hat seit dem vom Absender angegebenen Datum den Besitzer gewechselt, daher wird die Nachricht nicht zugestellt (Erweiterung RRVS).
Die Domain des Empfängers hat seit dem vom Absender angegebenen Datum den Besitzer gewechselt (Erweiterung RRVS).
Der Server kann nicht wie vom Absender angefordert prüfen, ob das Postfach den Besitzer gewechselt hat (Erweiterung RRVS).
Die Nachricht hat keine gültige DKIM-Signatur, obwohl die Richtlinie des Empfängers eine verlangt.
Die Nachricht hat gültige DKIM-Signaturen, aber keine erfüllt die Richtlinie des Empfängers (zum Beispiel wegen der signierenden Domain oder des Algorithmus).
Die Nachricht hat keine gültige DKIM-Signatur derselben Domain, die im From-Header steht.
Die sendende IP ist im SPF-Eintrag der Absenderdomain nicht autorisiert.
Die SPF-Auswertung ergab einen Fehler, zum Beispiel wegen eines fehlerhaften Eintrags oder zu vieler DNS-Abfragen.
Die sendende IP hat kein Reverse-DNS (PTR), oder der zurückgegebene Name löst nicht wieder auf diese IP auf.
Mehrere Authentifizierungsprüfungen der Nachricht sind gleichzeitig fehlgeschlagen, etwa SPF und DKIM.
Die Domain des Absenders veröffentlicht einen Null-MX, könnte also weder Antworten noch Bounces empfangen, daher wird die Nachricht abgelehnt.
Die Nachricht scheint Teil eines Massenversands ähnlicher missbräuchlicher Nachrichten zu sein.
Die Validierung der ARC-Kette ist fehlgeschlagen; sie bewahrt die Authentifizierungsergebnisse, wenn die Nachricht über Weiterleitungen oder Mailinglisten läuft.
Die Nachricht verlangt REQUIRETLS und der nächste Server auf dem Weg unterstützt diese Erweiterung nicht, daher kann sie nicht mit garantierter Verschlüsselung zugestellt werden.
Füge die komplette Serverantwort ein, zum Beispiel 550 5.7.1 Message rejected, um Basis- und erweiterten Code gleichzeitig zu sehen. Bei einem Basiscode zeigt die Suche auch die erweiterten Codes an, die ihn üblicherweise begleiten.
So funktioniert es
In einer SMTP-Sitzung erhält jeder Befehl des Clients (EHLO, MAIL FROM, RCPT TO, DATA …) eine Serverantwort, die mit einem dreistelligen Code beginnt. Die erste Ziffer sagt, wie es ausging: 2 bedeutet Erfolg, 3, dass der Server weitere Daten erwartet, 4 einen vorübergehenden und 5 einen permanenten Fehler. Die zweite gibt den Bereich an: x0z Syntax, x1z Information, x2z Verbindung und x5z Mailsystem. Der Text nach dem Code ist frei, jeder Server formuliert seinen eigenen; Programme werten nur die Zahl aus.
Da drei Ziffern wenig über die Ursache verraten, definierte RFC 3463 die erweiterten Statuscodes im Format Klasse.Subjekt.Detail: 5.1.1 ist ein permanenter Fehler (5) der Adressierung (1), weil das Postfach nicht existiert (1). Die Klasse wiederholt die Bedeutung der ersten Ziffer (2, 4 oder 5), das Subjekt ordnet die Ursache ein und das Detail präzisiert sie. Server, die sie verwenden, kündigen das mit der Erweiterung ENHANCEDSTATUSCODES in der Antwort auf EHLO an, und derselbe Code erscheint im Feld Status der Unzustellbarkeitsnachrichten.
Die Tabelle enthält die Basiscodes aus RFC 5321 und die der gängigen Erweiterungen (AUTH, STARTTLS, ETRN und Null-MX) sowie alle erweiterten Codes aus der IANA-Registry, jeweils mit den Basiscodes, mit denen sie üblicherweise auftreten. Große Anbieter ergänzen eigene Texte und Hilfelinks, aber immer auf Basis dieser Nummern.
Beispiele
550 5.1.1 <nadie@example.com>: Recipient address rejected: User unknown in local recipient table5xx Permanent · X.1.1 Bad destination mailbox addressDer typische Bounce von Postfix, wenn das Konto nicht existiert. Erneute Versuche helfen nicht: Die Adresse muss korrigiert werden. Hat derselbe Empfänger früher funktioniert, wurde das Konto höchstwahrscheinlich gelöscht.450 4.2.0 <ana@example.com>: Recipient address rejected: Greylisted4xx Transient · X.2.0 Other or undefined mailbox statusGreylisting: Der Server weist den unbekannten Absender vorübergehend ab und erwartet einen erneuten Versuch. Ein legitimer Mailserver tut das nach wenigen Minuten von selbst und die Nachricht kommt an; viele Spam-Programme versuchen es nie erneut.AUTH LOGIN334 VXNlcm5hbWU6Die 334 enthält die Challenge in Base64: VXNlcm5hbWU6 ist „Username:“ und die nächste, UGFzc3dvcmQ6, ist „Password:“. Sind die Anmeldedaten falsch, antwortet der Server mit 535 5.7.8; verlangt er vorher Verschlüsselung, mit 538 oder 530.Anwendungsfälle
- Anhand der Fehlermeldung des Servers verstehen, warum eine E-Mail zurückkam.
- Unterscheiden, ob ein Fehler vorübergehend ist und die Warteschlange es erneut versucht, oder permanent und du handeln musst.
- Authentifizierungsfehler diagnostizieren, wenn du den E-Mail-Versand aus einer Anwendung, einem Drucker oder einem Server einrichtest.
- Ablehnungen wegen SPF, DKIM, DMARC, Reverse-DNS oder Blacklists in den Logs des Mailservers interpretieren.
- Bounces in einer Plattform für Massenversand klassifizieren, um nicht existierende Adressen auszutragen.
- Eine mit telnet, openssl s_client oder swaks mitgeschnittene SMTP-Sitzung lesen.
Häufige Fragen
Was ist der Unterschied zwischen einem 4xx- und einem 5xx-Fehler?
Ein 4xx ist vorübergehend: Der sendende Server legt die Nachricht in die Warteschlange und versucht es in Abständen erneut, meist vier bis fünf Tage lang, bevor er aufgibt und einen Bounce erzeugt. Ein 5xx ist permanent: Der Bounce kommt sofort, und dieselbe Nachricht ohne Änderung erneut zu senden, schlägt wieder fehl.
Warum enthält die Antwort zwei Codes, wie 550 5.1.1?
Der erste ist der dreistellige Basiscode, den RFC 5321 vorschreibt. Der zweite ist der erweiterte Statuscode nach RFC 3463, der die Ursache präzisiert: Ein 550 kann auf ein nicht existierendes Postfach (5.1.1), eine Sperre durch Richtlinien (5.7.1) oder einen SPF-Fehler (5.7.23) zurückgehen. Für die Diagnose solltest du vor allem auf den erweiterten Code achten.
Was bedeutet der Bindestrich in 550-5.7.1?
Dass die Antwort mehrere Zeilen umfasst. Alle tragen denselben Code, aber die Zwischenzeilen trennen ihn mit einem Bindestrich vom Text und die letzte mit einem Leerzeichen – so weiß der Client, wann die Antwort zu Ende ist. Dasselbe siehst du in der Liste der Erweiterungen, die EHLO zurückgibt.
Warum werde ich mit 550 5.7.1 abgelehnt, obwohl die Adresse existiert?
Weil sich 5.7.1 nicht auf den Empfänger bezieht, sondern auf den Absender: Der Server erlaubt dir nicht, ihm diese Nachricht zuzustellen. Übliche Ursachen sind, dass die sendende IP auf einer Blacklist steht, die SPF-, DKIM- oder DMARC-Prüfung der Domain fehlschlägt, die IP kein Reverse-DNS hat oder versucht wurde, den Server ohne Authentifizierung als Relay zu nutzen. Der Text zum Code liefert meist den entscheidenden Hinweis.
Warum bekomme ich 530 oder 535, wenn ich E-Mails aus einer Anwendung sende?
530 bedeutet, dass der Server eine Authentifizierung oder den Start von TLS verlangt, bevor er die Nachricht annimmt; 535, dass Benutzername oder Passwort falsch sind. Prüfe, dass die Anwendung Port 587 mit STARTTLS oder 465 mit implizitem TLS nutzt, dass die Authentifizierung aktiviert ist und dass du bei Anbietern wie Gmail oder Microsoft 365 ein App-Passwort oder OAuth statt des normalen Passworts verwendest.