E-Mail kommt nicht an? SMTP-Fehlercodes richtig lesen

Den technischen Teil des Rückläufers finden

Zustellfehler werden häufig als Delivery Status Notification, Unzustellbarkeitsbericht oder Bounce zurückgesendet. Neben einer verständlichen Zusammenfassung kann die Nachricht strukturierte Felder enthalten. Besonders hilfreich sind Final-Recipient, Action, Status, Remote-MTA beziehungsweise der ablehnende Server sowie Diagnostic-Code. Diese Angaben beziehen sich auf einen einzelnen Empfänger; bei mehreren Adressen kann dieselbe Nachricht für einige Empfänger zugestellt und für andere abgelehnt worden sein.

Bewahren Sie den vollständigen technischen Rückläufer und die Originalkopfzeilen auf. Ein Screenshot mit abgeschnittenem Fehlertext ist für die Analyse oft zu wenig. Leiten Sie vertrauliche Nachrichteninhalte jedoch nicht unnötig weiter: Für eine erste Untersuchung reichen meist Adressen beziehungsweise Domains, Zeitpunkt, Message-ID, Statuscode und Diagnosezeile.

4xx bedeutet vorläufig, 5xx dauerhaft für diesen Versuch

Bei den klassischen dreistelligen SMTP-Antworten kennzeichnet die erste Ziffer die grundlegende Reaktion. 4xx ist eine vorläufige negative Antwort: Der sendende Mailserver sollte die Zustellung später erneut versuchen. 5xx ist eine dauerhafte negative Antwort: Derselbe unveränderte Versuch soll nicht automatisch wiederholt werden. „Dauerhaft“ bedeutet dabei nicht, dass der Fehler niemals behoben werden kann – eine korrigierte Adresse, Konfiguration oder Nachricht kann einen neuen Versuch ermöglichen.

Manuelles, häufiges Neuversenden hilft bei einem 4xx-Fehler nicht und kann bei volumen- oder reputationsbezogenen Begrenzungen sogar zusätzliche Last erzeugen. Prüfen Sie stattdessen, ob die Nachricht in der Warteschlange liegt, wann der nächste automatische Versuch vorgesehen ist und ob sich der Diagnosecode zwischen den Versuchen verändert.

Erweiterte Statuscodes als Klasse, Bereich und Detail lesen

Erweiterte Statuscodes haben das Format X.Y.Z, etwa 5.1.1 oder 4.4.2. Der erste Teil beschreibt Erfolg, vorläufigen Fehler oder dauerhaften Fehler. Der zweite Teil ordnet den betroffenen Bereich ein: 1 steht beispielsweise für Adressen, 2 für das Postfach, 3 für das Mailsystem, 4 für Netzwerk oder Routing und 7 für Sicherheits- oder Richtlinienfragen. Der dritte Teil präzisiert den Befund. Die IANA führt das aktuelle Register der standardisierten Codes.

Der Text hinter dem Code bleibt wichtig. Anbieter verwenden standardisierte Codes zusammen mit eigenen Hinweisen, Links oder Sitzungskennungen. Ein allgemeines 5.7.1 kann eine Richtlinienablehnung beschreiben, belegt für sich genommen aber weder eine bestimmte Blockliste noch automatisch einen SPF-, DKIM- oder DMARC-Fehler.

Häufige Gruppen richtig einordnen

• 5.1.1: Zielpostfachadresse ungültig. Schreibweise, Alias, Empfängerstatus und die tatsächlich zuständige Empfängerplattform prüfen.
• X.2.2: Postfach voll. Klasse und Diagnose entscheiden, ob der Zustand vorläufig behandelt oder dauerhaft gemeldet wurde.
• 5.3.4 oder X.2.3: Nachricht überschreitet ein System- oder Postfachlimit. Größe inklusive Anhänge und Transportkodierung prüfen; Anhänge nicht blind erneut senden.
• 4.4.1 beziehungsweise 4.4.2: Ziel antwortet nicht oder die Verbindung brach ab. DNS, Erreichbarkeit und wiederholte Versuche über einen geeigneten Zeitraum prüfen.
• 5.7.1: Zustellung nicht autorisiert oder Nachricht abgelehnt. Den vollständigen Anbietertext und die betroffene Phase auswerten, bevor Authentifizierung oder Reputation als Ursache festgelegt werden.

Eine Diagnosekette statt einzelner Vermutungen

Prüfen Sie zuerst, ob die sendende Anwendung die Nachricht überhaupt an den vorgesehenen Mailserver übergeben hat. Danach folgt der Weg des Servers: Warteschlange, DNS- und MX-Auflösung, Verbindungsaufbau, Empfängerannahme und schließlich die Antwort nach Übertragung des Nachrichteninhalts. Die Stelle, an der der Fehler auftritt, bestimmt die nächste Prüfung.

• Adresse und Domain exakt prüfen; bei 5.1.x nicht zuerst an Spamfilter denken.
• Bei 4.4.x DNS, Zielserver und Verbindungsverlauf prüfen, ohne aus einem einzelnen Timeout einen dauerhaften Ausfall abzuleiten.
• Bei Größen- und Inhaltsfehlern die gesamte transportierte Nachricht betrachten, nicht nur die sichtbare Dateigröße eines Anhangs.
• Bei 5.7.x den exakten Diagnosetext, die verlinkte Anbieterhilfe und die Ergebnisse von SPF, DKIM und DMARC getrennt bewerten.
• Erst nach einer konkreten Korrektur erneut senden; bei vorläufigen Fehlern zunächst die vorgesehene Serverwarteschlange arbeiten lassen.

Beispiel: Warum 550 5.7.1 nicht als Diagnose genügt

Zwei Empfänger können denselben Zahlencode mit unterschiedlichen Texten zurückgeben. Ein Anbieter nennt möglicherweise eine nicht bestandene Absenderauthentifizierung, ein anderer eine lokale Empfängerrichtlinie und ein dritter nur eine allgemeine Ablehnung. Deshalb gehören Code, kompletter Text, ablehnender Host und Anbieterreferenz immer zusammen. Öffentliche Anbieterlisten sind Beispiele, aber keine universelle Übersetzung für Antworten anderer Systeme.

Falls SPF, DKIM oder DMARC ausdrücklich genannt werden, prüfen Sie die betroffene Versandquelle und die vom vertrauenswürdigen Empfangssystem protokollierten Ergebnisse. Ein allgemeiner Zustellfehler ist kein Grund, DNS-Einträge auf Verdacht zu ändern. Unkoordinierte Änderungen können andere legitime Versanddienste beeinträchtigen.

Diese Angaben helfen bei einer Eskalation

• Zeitpunkt mit Zeitzone, Absender und betroffener Empfänger beziehungsweise Empfängerdomain.
• Message-ID und vollständige DSN-Felder Action, Status, Remote-MTA und Diagnostic-Code.
• Information, ob alle Empfänger, nur eine Domain oder nur einzelne Nachrichten betroffen sind.
• Ergebnis bisheriger automatischer Versuche und jede bereits vorgenommene konkrete Änderung.
• Keine Passwörter, privaten Schlüssel oder unnötigen vertraulichen Nachrichteninhalte mitsenden.

Zustellprobleme im Betrieb schneller eingrenzen

Für geschäftliche Maildienste sollten Warteschlangen, Rückläufer und wiederkehrende Fehlergruppen beobachtet werden. Eine einzelne Ablehnung ist noch kein Trend; wiederholte 4xx-Antworten für dieselbe Domain oder mehrere 5.1.1-Fehler nach einer Migration können dagegen auf ein gemeinsames Problem hinweisen. Dokumentieren Sie Schwellenwerte und Zuständigkeiten, damit nicht erst ein Nutzerbericht die Untersuchung startet.

Wenn der betroffene Maildienst bei NUXOA betrieben wird, übermitteln Sie die technischen Angaben ohne Zugangsdaten über den vorgesehenen Support- oder Kontaktweg. Mit dem vollständigen Diagnosecode lässt sich schneller unterscheiden, ob Adresse, Routing, Zielsystem, Nachricht oder Richtlinie untersucht werden muss.