E-Mail abgelehnt: 550 5.7.1 und 554 5.7.1 richtig lesen

So sah ein Rückläufer aus, den ich im September dreimal bekommen habe, gekürzt und mit Beispieladressen statt der echten:

<kontakt@empfaenger.example>: host mx.hoster.example[192.0.2.10] said:
    554 5.7.1 <kontakt@empfaenger.example>: Relay access denied
    (in reply to RCPT TO command)
Final-Recipient: rfc822; kontakt@empfaenger.example
Action: failed
Status: 5.7.1
Remote-MTA: dns; mx.hoster.example
Diagnostic-Code: smtp; 554 5.7.1 <kontakt@empfaenger.example>: Relay access denied

5.7.1 steht in RFC 3463 für „Delivery not authorized, message refused“: Der Empfängerserver will diese Mail nicht annehmen, und zwar aus einem Sicherheits- oder Richtliniengrund, nicht weil ein Postfach voll ist oder eine Adresse nicht existiert. Welcher Grund, sagt der Code selbst nicht. Er steht im Text dahinter, und von diesem Text hängt ab, wer etwas tun muss.

Ein 5.7.1 heißt nicht, dass deine Mail Spam ist oder dein Server auf einer Sperrliste steht. Das ist einer von mehreren möglichen Gründen. Im Beispiel oben hat der Empfängerserver die Mail abgelehnt, bevor er auch nur eine Zeile davon gesehen hatte.

Einen Rückläufer in drei Schritten lesen#

Der Rückläufer (auch Unzustellbarkeitsmeldung, NDR oder DSN) kommt meist von deinem eigenen Mailserver. Er gibt nur weiter, was der andere Server geantwortet hat. Drei Angaben ordnen ihn ein:

1. Wer hat abgelehnt? Remote-MTA oder host … said nennt den Server, der Nein gesagt hat. Gehört er zur Domain des Empfängers, liegt die Entscheidung dort. Steht dort dein eigener Anbieter, ist die Mail gar nicht erst hinausgegangen.
2. Wann? in reply to RCPT TO heißt: abgelehnt, als die Empfängeradresse genannt wurde. Der Inhalt war zu diesem Zeitpunkt noch gar nicht übertragen. after end of DATA heißt: Der Server hat die ganze Mail gesehen und dann abgelehnt, wegen des Inhalts oder weil SPF, DKIM oder DMARC nicht gepasst haben.
3. Dauerhaft oder vorübergehend? Beginnt der Code mit 5, ist die Ablehnung nach RFC 3463 dauerhaft: Dieselbe Mail an dieselbe Adresse kommt auch beim nächsten Versuch nicht an. Beginnt er mit 4, versucht es dein Server selbst noch einmal, oft über Stunden. Ein 421 4.7.26 von Gmail ist also eine Warnung, ein 550 5.7.26 die Ablehnung.

Die erste Zahl, 550 oder 554, ist der einfache Antwortcode aus RFC 5321. 550 heißt „Aktion nicht ausgeführt“, unter anderem aus Richtliniengründen, 554 heißt „Übertragung fehlgeschlagen“. Für die Fehlersuche ist der Unterschied unerheblich, beide sind endgültig. Wer nach „554 5.7.1“ sucht, landet beim selben Problem wie mit „550 5.7.1“.

Was hinter 5.7.1 stehen kann#

Die Texte stammen aus der Dokumentation von Microsoft und Google sowie aus Postfix, dem Mailserver vieler Webhoster. Andere Server formulieren es anders, die Bedeutung ist dieselbe.

Microsoft schreibt dazu selbst, dass sich ein 5.7.1 meist nicht auf Absenderseite beheben lässt. Was hilft, ist den Empfänger über einen anderen Weg zu erreichen, per Telefon oder Kontaktformular, und den Rückläufer mitzuschicken. Den braucht dessen Administrator.

Die verwandten Codes: 5.7.26, 5.7.509, 5.7.515#

Seit Gmail und Outlook die Prüfung von Absenderdomains verschärft haben, kommen die meisten Ablehnungen nicht mehr als 5.7.1, sondern mit eigenen Nummern. Bei ihnen liegt die Ursache fast immer beim Absender, genauer bei den DNS-Einträgen seiner Domain.

Zwei Dinge fallen auf. Erstens bedeutet 5.7.26 laut der Liste der IANA „mehrere Authentifizierungsprüfungen gescheitert“, Gmail benutzt ihn aber auch für „gar nicht authentifiziert“. Der Code allein reicht also nicht, der Text entscheidet. Zweitens ist 5.7.509 manchmal genau richtig: Wer eine fremde Absenderadresse fälscht, soll abgewiesen werden. Kommt der Rückläufer zu einer Mail, die du selbst geschickt hast, fehlt dein Versanddienst im SPF-Eintrag, oder er signiert nicht mit DKIM für deine Domain. Wie man das abstellt, ohne Mails zu verlieren, steht in DMARC einrichten.

Gmail verlangt seit dem 1. Februar 2024 von jedem Absender SPF oder DKIM, ab 5.000 Mails am Tag beides plus DMARC. Unter dieser Menge reicht eines von beiden, aber eben nur, wenn es besteht.

Ein echter Fall: Relay access denied#

In eigener Sache: Den Rückläufer vom Anfang habe ich am 15., 16. und 21.09.2026 bekommen, jeweils auf eine Anfrage an einen Website-Betreiber. Drei verschiedene Domains, alle drei bei demselben Webhoster, alle drei mit demselben Satz abgelehnt.

Postfix schickt Relay access denied mit 554, wenn eine Mail an eine Domain geht, für die der Server weder Endziel noch Weiterleiter ist. So steht es in der Postfix-Dokumentation unter reject_unauth_destination. Abgelehnt wurde bei RCPT TO, also bevor Betreff, Text oder Absender geprüft waren. Mein SPF, DKIM und DMARC haben keine Rolle gespielt, der Inhalt auch nicht.

Die MX-Einträge der drei Domains zeigen auch am 04.10.2026 noch auf diese Server. Wahrscheinlich ist das Postfach dort nie eingerichtet oder später gelöscht worden, während der MX-Eintrag stehen blieb. Den Fall nennt Microsoft ausdrücklich als häufige Ursache: Der MX-Eintrag zeigt auf ein System, das die Domain nicht annimmt. Ändern kann das nur, wer die Domain verwaltet. Dem Absender bleibt nur ein anderer Weg, etwa Telefon oder Kontaktformular.

Ob es dir genauso geht, zeigt ein Blick auf den MX-Eintrag des Empfängers. Wie man ihn abfragt und liest, steht in MX-Eintrag prüfen.

Messung: 146 Tiroler Domains und Gmails Mindestregel#

In eigener Sache: In der Nacht auf den 04.10.2026 (23:28 UTC) habe ich die SPF-, DMARC- und MX-Einträge von 149 Tiroler Domains abgefragt, dieselben wie in den Messungen vom September: 34 Tourismusverbände und 115 Betriebe aus meiner Akquise-Liste. Die Abfrage lief über DNS-over-HTTPS bei Cloudflare, rein passiv, ohne Verbindung zu einem Mailserver. Drei Domains gibt es nicht mehr, bleiben 146.

Die Frage war: Bei wie vielen kann SPF gar nicht bestehen? Für diese Domains hängt die Zustellung bei Gmail allein daran, dass jede ausgehende Mail eine gültige DKIM-Signatur trägt. Fehlt sie bei einem einzigen Versandweg, etwa beim Rechnungsprogramm, ist 550 5.7.26 die Antwort.

• 11 Domains haben keinen SPF-Eintrag.
• 7 haben einen fehlerhaften. Vier brauchen mehr als die erlaubten zehn DNS-Abfragen (nach eigener Zählung gemäß RFC 7208, Abschnitt 4.6.4), eine hat zwei SPF-Einträge, zwei verweisen per include: auf einen Namen ohne SPF-Eintrag. Einer davon ist ein Tippfehler: include:spf.<anbieter> statt include:_spf.<anbieter>, der Name ohne Unterstrich existiert nicht. Alle drei Fehler führen zu permerror, und ein Empfänger, der streng prüft, wertet das wie gar keinen Eintrag.
• 4 enden auf ?all. Das Ergebnis ist dann neutral statt pass.

Zusammen sind das 22 von 146. 17 davon haben auch keinen DMARC-Eintrag. Welche Domain wie dasteht, veröffentliche ich nicht. Ob die eigene dazugehört, zeigt der E-Mail-Check in einer Minute.

Was diese Zählung nicht zeigt: ob die 22 Domains mit DKIM signieren. Das lässt sich von außen nicht sicher feststellen, ohne eine Mail von ihnen zu bekommen. Sie sagt also nicht, dass deren Mails abgelehnt werden, sondern dass es nur einen Weg gibt, auf dem sie ankommen.

Was zu tun ist#

1. Rückläufer ganz lesen, nicht nur die Betreffzeile. Server, Zeitpunkt und Text nach dem Code heraussuchen. Kommt die Mail an, aber im falschen Ordner, hilft Mails landen im Spam weiter.
2. Den Text in die Tabellen oben einordnen. Liegt es beim Empfänger, über einen anderen Weg Bescheid geben und den Rückläufer mitschicken.
3. Liegt es bei dir, zuerst die eigene Domain prüfen: SPF, DKIM und DMARC im E-Mail-Check, die IP-Adresse des Ausgangsservers im Blacklist-Check. Fehlt ein Versanddienst im SPF-Eintrag, steht in SPF-Eintrag erstellen, wie man ihn ergänzt, ohne über zehn Abfragen zu kommen.
4. Betrifft es nur einen Versandweg (Newsletter, Shop, Buchungssystem), dort nachsehen, mit welcher Domain er signiert. DKIM muss für deine Domain gelten, nicht für die des Dienstes. Wo man das sieht, steht in DKIM-Selector finden.

Was nicht hilft#

Dieselbe Mail noch fünfmal schicken. Ein 5xx ist nach RFC 3463 dauerhaft. Ohne Änderung an der Mail oder am Ziel kommt die Antwort wieder.

Betreff ändern, Verweise oder Anhänge entfernen, wenn bei RCPT TO abgelehnt wurde. Der Server hat den Inhalt nie gesehen.

Einen zweiten SPF-Eintrag anlegen für den neuen Versanddienst. Zwei Einträge mit v=spf1 sind ein permerror, danach besteht SPF für keinen Weg mehr. Der Dienst gehört als include: in den vorhandenen Eintrag. Wie man ihn prüft, steht in SPF-Eintrag prüfen.

Den eigenen Mailanbieter wechseln, wenn der Fehler beim Empfänger liegt. Ein Relay access denied vom Server des Empfängers trifft jeden Absender gleich.

Häufige Fragen#

Was bedeutet 550 5.7.1?#

Der Empfängerserver hat die Mail dauerhaft abgelehnt, weil eine Sicherheits- oder Richtlinienregel greift. Welche, steht im Text nach dem Code: etwa eine Sperrliste, eine fehlende Anmeldung oder eine Adresse, die keine Mail von außen annimmt.

Was ist der Unterschied zwischen 550 5.7.1 und 554 5.7.1?#

Für die Fehlersuche keiner. 550 und 554 sind zwei einfache Antwortcodes aus RFC 5321, beide endgültig. Entscheidend ist der erweiterte Code 5.7.1 und der Text dahinter.

Muss ich etwas tun, wenn ich 550 5.7.26 von Gmail bekomme?#

Ja, das liegt fast immer bei dir. Gmail hat die Mail abgelehnt, weil sie weder SPF noch DKIM bestanden hat oder weil die DMARC-Richtlinie deiner Domain es verlangt. Den Stand deiner Domain zeigt der E-Mail-Check.

Ich bekomme Rückläufer zu Mails, die ich nie geschrieben habe. Was ist das?#

Dann hat jemand deine Adresse als Absender gefälscht, und der Empfängerserver hat seine Ablehnung an dich zurückgeschickt. Das ist E-Mail-Spoofing. Dagegen hilft eine DMARC-Richtlinie mit p=quarantine oder p=reject.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Das Paket E-Mail-Schutz bringt SPF, DKIM und DMARC beim bestehenden Anbieter in Ordnung, findet jeden Versandweg über die DMARC-Berichte und stellt die Richtlinie schrittweise um, ohne dass Rechnungen oder Newsletter hängen bleiben. Vorher kostenlos selbst prüfen: der E-Mail-Check.

Stand 04.10.2026. Quellen an diesem Tag abgerufen, DNS-Messung in der Nacht auf den 04.10.2026.

Quellen#

• RFC 3463: Enhanced Mail System Status Codes: Aufbau Klasse.Thema.Detail, 5 dauerhaft, 4 vorübergehend, X.7.1 „Delivery not authorized, message refused“
• IANA: SMTP Enhanced Status Codes: Registrierung von X.7.23 (SPF), X.7.25 (Rückwärts-DNS), X.7.26 („Multiple authentication checks failed“) nach RFC 7372
• RFC 5321: SMTP: einfache Antwortcodes 550 und 554
• Google: Gmail SMTP errors and codes: Texte zu 550 5.7.1, 5.7.25, 5.7.26, 5.7.27, 5.7.30 und den 421 4.7.x-Gegenstücken
• Google: Email sender guidelines: SPF oder DKIM für alle Absender, ab 5.000 Mails am Tag SPF, DKIM und DMARC, gültig seit 01.02.2024
• Microsoft: NDRs und SMTP-Fehler in Exchange Online: 5.7.1, 5.7.23, 5.7.509 und weitere
• Microsoft: Fix NDR error 550 5.7.1 in Exchange Online: Ursachen, darunter MX-Einträge auf das falsche System, und wer sie beheben kann
• Microsoft: Fix NDR error 550 5.7.515 in Outlook.com: Anforderungen ab 5.000 Mails an Outlook.com
• Postfix: postconf(5): reject_unauth_destination und relay_domains_reject_code (Standard 554)
• RFC 7208: SPF: zehn DNS-Abfragen (Abschnitt 4.6.4), permerror bei mehreren Einträgen und bei include: ohne Ziel-Eintrag (Abschnitt 5.2)
• RFC 5737 und RFC 2606: Beispiel-IP-Adressen und Beispieldomains im Rückläufer oben
• Eigene Messung: SPF-, DMARC- und MX-Einträge von 149 Tiroler Domains (34 Tourismusverbände, 115 Betriebe) am 03.10.2026 um 23:28 UTC per DNS-over-HTTPS (Cloudflare), passiv; auffällige Verweise mit Google Public DNS gegengeprüft. Veröffentlicht werden nur Summen, keine Namen.