SMTP-Fehlercodes und Bounces verstehen: 4xx, 5xx und was zu tun ist
Eine Mail kommt zurück, und im Text steht eine Zahlenfolge, die niemand für Menschen geschrieben hat. Dieser Text ordnet die Codes ein: welche du ignorieren kannst, weil der Server sie selbst löst, und bei welchen du sofort etwas tun solltest.
4xx oder 5xx: vorübergehend oder endgültig
Die erste Ziffer entscheidet alles Weitere.
- 4xx heißt vorübergehend. Der Empfängerserver sagt: gerade nicht, versuch es später. Dein Server tut das automatisch, meist über mehrere Stunden bis Tage. Du musst in aller Regel nichts tun.
- 5xx heißt endgültig. Der Empfänger nimmt diese Mail nicht an, und ein erneuter Versuch ändert daran nichts. Hier musst du handeln, entweder an der Adresse oder an deiner Konfiguration.
Hinter dem dreistelligen Code steht oft ein zweiter, feiner gegliederter: 5.1.1, 4.7.0 und so weiter. Der ist meist aussagekräftiger als die drei Ziffern davor. Und der Klartext dahinter ist am aussagekräftigsten von allem, denn dort schreiben die großen Anbieter, was tatsächlich los ist.
Ein Missverständnis vorweg: Ein 5xx bedeutet nicht, dass du etwas falsch gemacht hast. „Postfach existiert nicht" ist ein 5xx und heißt nur, dass die Adresse überholt ist.
Nachschlagetabelle der häufigsten Codes
| Code | Klartext | Was zu tun ist |
|---|---|---|
550 5.1.1 | Empfänger existiert nicht | Adresse prüfen und aus dem Verteiler nehmen. Wiederholte Versuche schaden dem Ruf deiner Domain. |
550 5.7.1 | Abgelehnt, oft Richtlinie oder Spam-Verdacht | Klartext lesen. Häufig fehlen SPF oder DKIM, oder der Inhalt hat einen Filter ausgelöst. |
554 5.7.1 | Sperrliste, die IP ist beim Empfänger blockiert | Prüfen, welche Liste greift, Ursache abstellen, Delisting beantragen. |
550 5.7.26 | Authentifizierung fehlt oder passt nicht zum Absender | SPF und DKIM für die Absenderdomain einrichten, DMARC-Alignment prüfen. |
550 5.7.708 | Verkehr von dieser IP wird nicht angenommen | Über einen Relay-Dienst mit gepflegter Reputation senden statt über eine geteilte Hoster-IP. |
552 5.2.3 | Nachricht zu groß | Anhang verkleinern oder als Link versenden. Grenzen liegen häufig bei 10 bis 25 MB. |
552 5.2.2 | Postfach des Empfängers ist voll | Nichts tun. Meist meldet sich der Empfänger, oder es löst sich von selbst. |
421 4.7.0 | Zu viele Verbindungen, Drosselung | Nichts tun, der Server wiederholt. Bei Massenversand die Rate senken. |
451 4.7.1 | Greylisting, bitte später erneut | Nichts tun. Der zweite Versuch kommt meist durch, üblicherweise nach 5 bis 30 Minuten. |
452 4.2.2 | Postfach vorübergehend voll | Nichts tun, der Server wiederholt. |
535 5.7.139 | Anmeldung abgelehnt, Basic Authentication deaktiviert | Betrifft die Einlieferung, nicht die Zustellung. Siehe den Beitrag zu Microsoft 365 weiter unten. |
530 5.7.57 | Nicht angemeldet eingeliefert | Zugangsdaten im Gerät oder Programm hinterlegen, Verschlüsselung auf STARTTLS. |
Die fünf Fälle, die den Großteil ausmachen
550 5.1.1: die Adresse gibt es nicht
Der mit Abstand häufigste dauerhafte Bounce. Ursachen sind Tippfehler, ausgeschiedene Mitarbeiter und Adressbestände, die seit Jahren mitgeschleppt werden. Wichtig ist die Konsequenz: Solche Adressen gehören aus dem Verteiler, und zwar zügig. Empfängerserver werten eine hohe Quote unbekannter Adressen als Zeichen dafür, dass hier jemand ungepflegte Listen abarbeitet, und stufen die Reputation des Absenders herab. Ein einzelner Tippfehler ist harmlos, ein Prozentwert im zweistelligen Bereich ist ein Problem.
554 5.7.1: Sperrliste
Deine sendende IP-Adresse steht auf einer Liste, der der Empfänger vertraut. Das trifft besonders oft Server bei großen Hostern, wo sich viele Kunden eine Adresse teilen: Es genügt, dass ein anderer Kunde auf demselben Block Werbung verschickt hat. Delisting hilft nur dann dauerhaft, wenn die Ursache abgestellt ist. Aus diesem Grund ist der Versand über einen Dienst, der Reputation als Aufgabe betreibt, meist stabiler als der Versand über die eigene oder die geteilte Adresse des Hosters.
421 4.7.0: zu viele Verbindungen
Kein Fehler, sondern eine Bremse. Große Anbieter begrenzen, wie viele Mails sie in kurzer Zeit von einer Adresse annehmen. Bei Newslettern aus dem eigenen Mailserver ist das der Klassiker: Die ersten hundert gehen durch, dann schließt sich das Tor. Dein Server wiederholt automatisch, aber die Zustellung zieht sich. Abhilfe schafft, den Versand zu verteilen und ihn über eine Adresse laufen zu lassen, die bei den Anbietern eingeführt ist.
550 5.7.26: die Authentifizierung passt nicht
Der Empfänger findet weder gültiges SPF noch gültiges DKIM für die Absenderadresse, oder die geprüfte Domain passt nicht zu der, die im Postfach angezeigt wird. Das ist ein reines Konfigurationsproblem und lässt sich vollständig lösen, siehe SPF, DKIM und DMARC einrichten. Seit die großen Anbieter ihre Anforderungen verschärft haben, ist dieser Code deutlich häufiger geworden.
552: die Nachricht ist zu groß
Die Grenzen liegen je nach Empfänger zwischen 10 und 35 MB, und sie gelten nach der Kodierung des Anhangs, die eine Datei um rund ein Drittel größer macht. Eine 20-MB-Datei kann also an einer 25-MB-Grenze scheitern. Für Scans und Rechnungen lohnt es sich, die Auflösung zu senken oder statt der Datei einen Link zu verschicken.
Bounce-Rate: ab wann es gefährlich wird
Als Faustregel gilt: Dauerhafte Bounces unter einem Prozent sind normaler Betrieb. Zwischen einem und drei Prozent solltest du den Adressbestand ansehen. Darüber wird es kritisch, weil Empfängerserver anfangen, auch die gültigen Mails skeptischer zu behandeln.
Vorübergehende Bounces zählen dabei nicht mit. Sie sagen etwas über die Auslastung der Gegenseite aus, nicht über die Qualität deiner Adressen.
Harte Bounces automatisch unterdrücken
Der wichtigste Handgriff ist auch der langweiligste: Adressen, die dauerhaft abgelehnt wurden, dürfen nicht wieder angeschrieben werden. Wer das von Hand pflegt, vergisst es. Deshalb führen Versanddienste eine Unterdrückungsliste, in die dauerhafte Bounces automatisch einlaufen.
Für die eigene Anwendung ist die Regel einfach: Ist der Fehler dauerhaft, die Adresse sperren. Ist er vorübergehend, nichts tun und später nachsehen. Genau nach dieser Unterscheidung ist auch das Feld reason der MailBridge-API aufgebaut, mit einem stabilen Schlüssel je Ursache, auf den du programmieren kannst.
Wo du die Codes bei MailBridge findest
Im Portal steht zu jeder eingelieferten Mail der Status, und zu jedem Bounce die Originalantwort des Empfängerservers plus eine Erklärung im Klartext mit Handlungsempfehlung. Die Bounce-Rate des Tages und die häufigsten Gründe der letzten sieben Tage stehen im Dashboard. Details dazu in den Anleitungen zu Bounces und NDR und zum Protokoll.
Wenn die Fehlermeldung schon beim Einliefern kommt und nicht beim Zustellen, liegt es an der Anmeldung. Für den häufigsten Fall gibt es einen eigenen Beitrag: SMTP-Relay für Microsoft 365.