Fehlermeldungen

Der empfangende Server hat den SPF-Record deiner Domain geprüft und die sendende IP nicht darin gefunden. Weil dein Record mit -all endet, ist das eine ausdrückliche Ablehnung.

Dein SPF-Record überschreitet das Limit von 10 DNS-abfragenden Mechanismen. Die Folge ist nicht „teilweise gültig“, sondern: SPF gilt als nicht auswertbar — für alle deine Mails, auch die vom Hauptserver.

DMARC besteht nur, wenn SPF oder DKIM besteht und die dabei geprüfte Domain zur Domain im From:-Header passt. Diese zweite Bedingung — das Alignment — ist fast immer der Grund für diese Meldung.

Diese Meldung sagt etwas sehr Bestimmtes: Der Schlüssel wurde gefunden, die Signatur ist formal in Ordnung — aber der Nachrichtentext ist nach dem Signieren nicht mehr derselbe. Irgendetwas auf dem Weg hat ihn angefasst.

Der Empfänger hat die Signatur gelesen, den passenden öffentlichen Schlüssel im DNS gesucht — und nichts gefunden. Der Fehler liegt fast immer im DNS, nicht im Mailserver.

Diesen Wortlaut verwendet fast ausschließlich Microsoft — Exchange Online und Outlook.com. Inhaltlich ist es ein SPF-Hardfail, die Nummer 5.7.23 ist Microsofts eigene Ausprägung davon.

Microsofts Formulierung für eine DMARC-Ablehnung. Entscheidend ist das Wort verification: Nicht SPF oder DKIM allein sind gescheitert, sondern deren Ausrichtung auf die Domain im From:-Header.

Diese Meldung heißt nicht, dass deine Policy zugeschlagen hat. Sie heißt, dass der empfangende Server den DMARC-Record gefunden, aber nicht auswerten konnte. Der Record selbst ist kaputt.

Der Server hat dich erfolgreich angemeldet und lehnt trotzdem ab: Das Konto, mit dem du dich ausgewiesen hast, darf die Adresse im From-Header nicht benutzen. Das ist eine Berechtigungsfrage, keine Authentifizierungsfrage.

temperror heißt nach RFC 7208: Die Prüfung war nicht durchführbar, nicht negativ. Irgendwo in der Auflösungskette hat DNS keine verwertbare Antwort geliefert — das ist ein anderes Problem als ein fehlerhafter Record.

STARTTLS hebt eine bestehende Klartextverbindung auf Port 25 in eine verschlüsselte. Scheitert dieser Übergang, bricht die Zustellung ab — obwohl der Server erreichbar ist und die DNS-Auflösung stimmt.

Bei SMTP ist eine fehlgeschlagene Zertifikatsprüfung oft folgenlos — die meisten Server verschlüsseln trotzdem opportunistisch. Sobald aber MTA-STS oder DANE im Spiel sind, wird daraus eine harte Ablehnung.

Der Server bricht den Dialog ab, bevor er Anmeldedaten oder einen Absender entgegennimmt: Auf dieser Verbindung ist noch keine Verschlüsselung ausgehandelt, und ohne die geht hier gar nichts.

Der Server hat STARTTLS in seinen Fähigkeiten angekündigt und die Aushandlung dann abgelehnt. Das ist kein Aushandlungsfehler zwischen zwei Seiten, sondern ein lokales Problem auf dem antwortenden Server.

Die Meldung nennt in der Regel die Liste, die den Ausschlag gab. Das ist die wichtigste Information darin — denn die Listen unterscheiden sich enorm in ihrer Bedeutung.

Die erste Ziffer entscheidet: 4xx ist temporär, die Mail ist nicht verloren. Dein Server wird es erneut versuchen. Ein dauerhaftes 421 ist trotzdem ein Warnsignal — es geht praktisch immer um Reputation.

Die Codes 5.7.606 bis 5.7.614 stammen aus Microsofts eigener Sperrliste. Sie ist nicht öffentlich abfragbar — deshalb kann eine IP hier gesperrt sein, während jede öffentliche DNSBL sie als sauber meldet.

Greylisting lehnt jeden unbekannten Absender einmal ab und lässt ihn beim zweiten Versuch durch. Ein echter Mailserver wiederholt automatisch, viele Spam-Werkzeuge nicht. Deshalb ist eine einmalige Verzögerung völlig normal.

Microsoft nimmt von dieser Adresse grundsätzlich keine Post an. Anders als bei einer Listung geht es hier selten um dein Sendeverhalten, sondern um den Adressbereich, in dem du sitzt.

Anders als eine Blacklist-Sperre bezieht sich diese Ablehnung auf die konkrete Nachricht. Absender-IP und Authentifizierung können einwandfrei sein — beanstandet wurde, was in der Mail steht.

Die Nachricht ist größer, als die Dateigröße der Anhänge vermuten lässt. Anhänge werden für den Transport umkodiert und wachsen dabei um rund ein Drittel — das ist die Ursache der meisten überraschten Rückmeldungen zu diesem Fehler.

Diese Sperre gilt einem Anhang, nicht dem Nachrichtentext und nicht deiner Reputation. Sie greift unabhängig davon, ob eine Schadfunktion gefunden wurde — der Dateityp allein genügt.

Diese Ablehnung trifft fast ausschließlich selbst betriebene Mailserver. Der Empfänger schlägt die sendende IP rückwärts nach und findet keinen Namen — oder einen, der sich vorwärts nicht bestätigt.

Der klassische Postfix-Riegel reject_unknown_client_hostname. Anders als 550 5.7.25 ist dieser Code temporär — die Gegenstelle versucht es weiter, und die Mail hängt in der Warteschlange, statt sofort zu bouncen.

Ein Mailserver nimmt Nachrichten nur in zwei Fällen an: für eigene Empfänger, oder von authentifizierten Absendern. Diese Meldung heißt, dass beides nicht zutrifft — und meistens ist das kein Fehler, sondern korrektes Verhalten.

Diese Ablehnung ist eine Aussage über die Empfängerseite, nicht über deine Reputation. Der annehmende Server sagt: Für diese Adresse ist hier kein Postfach eingerichtet.

Diese Meldung kommt fast immer von Exchange Online und ist bewusst nichtssagend: Sie verrät nicht, ob das Postfach existiert. Genau das macht die Diagnose ungewohnt — man muss von außen eingrenzen.

Diese Meldung erscheint beim Einliefern, nicht beim Zustellen — dein Programm meldet sich an einem Postausgangsserver an und wird abgewiesen. In den meisten Fällen ist das Passwort richtig und trotzdem falsch.