Eine E-Mail bounct mit dem Code 550 5.4.1 bei einem Microsoft-365-Kunden, obwohl SPF, DKIM und DMARC auf PASS stehen. Woran liegt das? Die Antwort passt in einen Satz: Die Empfängeradresse existiert im Verzeichnis des empfangenden Servers nicht, oder der Zugriff dort wird ausdrücklich verweigert. Es ist eine Verzeichnisablehnung und hat mit der sender reputation nichts zu tun. Dahinter stecken 4 mögliche Ursachen, und eine einzelne Adresse behandeln Sie anders als eine ganze Domain.
Bei Exchange Online ist es meistens das Directory-Based Edge Blocking, ein Mechanismus, der ungültige Adressen filtert, bevor der Inhalt der Nachricht geprüft wird. Genau hier laufen viele Kampagnen auf Grund: Ihr CMO fragt, warum die Öffnungsrate sinkt, Ihr E-Mail-Tool zeigt eine einwandfreie technische Konfiguration, und der NDR (Non-Delivery Report) bleibt unverständlich, solange Sie seinen genauen Wortlaut nicht lesen.
Was der Code 550 5.4.1 bedeutet
550 ist ein permanenter Statuscode (Klasse 5yz der RFC 5321 vom Oktober 2008). Der Server versucht den Versand nicht erneut, anders als bei temporären 4xx-Fehlern, bei denen dieselbe RFC mindestens 4 bis 5 Tage lang Wiederholungsversuche vorsieht. Der Subcode 5.4.1 (Enhanced Status Code nach RFC 3463 vom Januar 2003) meldet ein Routing- oder Zugriffsproblem auf Empfängerseite, kein Inhaltsproblem und keinen Blacklist-Eintrag. Das unterscheidet ihn vom 550 5.7.1, bei dem eine Filterrichtlinie oder eine verschlechterte Absenderreputation die Ablehnung auslöst. Hier lief der Austausch von EHLO und MAIL FROM reibungslos, und RCPT TO wurde syntaktisch akzeptiert. Erst bei der Auflösung im Verzeichnis flog die Adresse raus. Einen Überblick über die Familien der 4xx- und 5xx-Codes gibt die vollständige Systematik der SMTP-Fehler.
Gelöschtes oder nie angelegtes Postfach: der häufigste Fall
Der NDR zeigt „550 5.4.1 Recipient address rejected: Access denied“. Die Adresse hat im Exchange-Online-Verzeichnis nie existiert, oder sie wurde nach einem Weggang oder einer Kontoschließung entfernt. Ein erneuter Versuch ändert nichts, denn das Ziel der Nachricht gibt es auf Empfängerseite nicht mehr.
Prüfen Sie zuerst die Schreibweise der Adresse: Eine falsch abgetippte Domain reicht für diese Ablehnung. Stimmt die Adresse und bounct sie über mehrere Tage weiter, ist sie tot. Sie gehört dann zu einem ehemaligen Kontakt oder einer gestrichenen Stelle und stammt oft aus einem nie aktualisierten CRM-Import.
Akzeptierte Domain falsch als Internal Relay oder Authoritative konfiguriert
Ein typisches Symptom verrät diese Ursache: Die Ablehnung trifft alle Empfänger derselben Domain, nicht nur eine Adresse. In Exchange Online ist eine akzeptierte Domain entweder Authoritative (das M365-Verzeichnis ist maßgeblich, jede fehlende Adresse wird per DBEB abgelehnt) oder Internal Relay (ein Teil der Postfächer liegt woanders, der Mailfluss geht über einen Connector zu einem anderen System weiter).
Das Problem tritt meist in Hybridumgebungen auf. Der Microsoft-365-Tenant ist als Authoritative konfiguriert, aber auf einem lokalen Exchange-Server, der nicht vollständig synchronisiert ist, liegen noch Postfächer. Exchange Online lehnt dann völlig gültige Adressen ab, weil es sie im Verzeichnis nicht kennt. Laut Microsoft Learn bleibt die akzeptierte Domain bei DBEB während der Synchronisierung der Benutzer auf Internal Relay. Auf Authoritative wechselt man erst, wenn alle Empfänger in Microsoft 365 vorhanden sind.
Die übliche Korrektur der Administratoren, wenn die Domain eigentlich stimmt, gültige Adressen aber trotzdem bouncen: die akzeptierte Domain im Exchange Admin Center (Nachrichtenfluss > Akzeptierte Domänen) von Authoritative auf Internal Relay umstellen, speichern und wieder auf Authoritative zurückstellen. In PowerShell geht das mit dem Cmdlet Set-AcceptedDomain und dem Parameter -DomainType. Der Wechsel zwingt Exchange Online, den Verzeichnisstatus neu bereitzustellen, und leert einen veralteten Verzeichnis-Cache.
Directory-Based Edge Blocking: die Ablehnung an der Grenze, vor jedem Filter
„Wenn die Adresse nicht im Verzeichnis steht, blockiert der Dienst die Nachricht, noch bevor die Filterung beginnt.“ (Exchange-Online-Dokumentation, Microsoft Learn)
DBEB (Directory-Based Edge Blocking) weist unbekannte Adressen am Netzwerkrand des Dienstes ab, bevor die Nachricht in die Anti-Spam-Pipeline von Microsoft 365 gelangt. Das ist etwas anderes als eine Relay-Sperre oder eine Verbindungsverweigerung, die der Artikel zum SMTP-Fehler 554 5.0.0 getrennt behandelt: Dort wird schon die Verbindung verweigert. Hier kommt sie zustande, und erst die Auflösung der Adresse scheitert. In Hybridumgebungen funktioniert DBEB nur, wenn der MX-Record der Domain auf Microsoft 365 zeigt, wie dieselbe Seite festhält. Für die Aktivierung nennt Microsoft 5 bis 10 Minuten.
Der vollständige NDR enthält oft einen zusätzlichen Code: „550 5.4.1 Recipient address rejected: Access denied. AS(201806281)“. Er kennzeichnet eine DBEB-Ablehnung und bestätigt, dass die Sperre vom Exchange-Online-Verzeichnis ausgeht. Warum die Adresse dort fehlt, sagt er nicht. Tritt er unmittelbar nach dem Anlegen eines Postfachs in einer Hybridumgebung auf, ist ein Synchronisierungsverzug zwischen dem lokalen Verzeichnis (Microsoft Entra Connect, das 2023 umbenannte frühere Azure AD Connect) und Exchange Online weiterhin die wahrscheinlichste Ursache: Das Postfach existiert lokal, die Änderung wartet auf ihre Replikation. Der Administrator erzwingt dann auf dem Entra-Connect-Server mit Start-ADSyncSyncCycle -PolicyType Delta einen Delta-Zyklus, bevor er weitersucht.
Toter Alias oder tote Verteilerliste
Vierter Fall: Die abgelehnte Adresse ist ein Alias oder eine deaktivierte Verteilerliste. Eine gelöschte Verteilergruppe und ein von einem freigegebenen Postfach entfernter Alias zeigen auf dem Bildschirm dasselbe Symptom. Am hartnäckigsten ist die dynamische Verteilergruppe on-premises in einer Hybridumgebung. Sie lässt sich bauartbedingt nicht nach Exchange Online synchronisieren, egal wie lange man wartet.
Für diesen Fall dokumentiert Microsoft eine Umgehung: In Exchange Online legen Sie einen E-Mail-Kontakt an, der die externe Adresse der lokalen dynamischen Gruppe übernimmt. Bei einem einfach gelöschten Alias legen Sie ihn auf dem Zielpostfach neu an oder sagen dem Absender, dass sich die Adresse geändert hat.
Was der 550 5.4.1 über den Zustand der Liste verrät
„Meine Kampagnen enden in Ablehnungen, und mein E-Mail-Tool zeigt trotzdem eine tadellose technische Konfiguration.“ Diesen Satz hört man oft von Growth- oder Lifecycle-Verantwortlichen, die dem 550 5.4.1 zum ersten Mal begegnen. Dann greift man zu SPF, DKIM, IP warming und sender reputation, wie bei jeder gewöhnlichen Zustellbarkeitsablehnung. Bei genau diesem Code bringt das nichts, denn alle 4 Ursachen liegen auf Empfängerseite, in deren Verzeichnis.
Der Reflex SPF, DKIM, Warmup kommt aus einer guten Gewohnheit. Nur prüft kein ESP standardmäßig, ob die Adresse beim Empfänger noch existiert, sondern lediglich, ob ihr Format gültig ist. Diesen blinden Fleck deckt eine Listenprüfung ab, und Sie müssen dafür keine weitere Ebene täglich überwachen.
Eine gelöschte Adresse, ein toter Alias, eine ganze Domain, die mangels Synchronisierung falsch eingestellt ist: In allen 4 Fällen steckt eine Liste mit toten Einträgen dahinter. Die häufen sich schnell an. CaptainVerify hat 2025 126 Millionen Adressen geprüft, nur 57 % davon waren gültig. Außerdem verliert eine Liste jährlich rund 23 % ihrer gültigen Adressen, so die Analyse zum tatsächlichen Wert einer E-Mail-Adresse.
Hier hilft eine Listenprüfung vor dem Versand. Sie beseitigt die ganze Fehlerkategorie, ohne dass Sie DNS oder die Exchange-Konfiguration anfassen. Eine Adresse, die im Verzeichnis des Empfängers nicht mehr existiert, fällt bei der Prüfung auf, bevor eine bereits gestartete Kampagne bounct. Vor dem nächsten Versand genügt eine geprüfte Stichprobe, um zu sehen, wie viele Adressen mit 550 5.4.1 zurückkämen, ohne dass Sie dafür die IP umsonst aufwärmen. Das ist eine Frage der list hygiene, und sie lässt sich klären, bevor Sie an der Versandinfrastruktur arbeiten.
Häufig gestellte Fragen
Ist der 550 5.4.1 identisch mit dem 550 5.7.1? Nein. Der 5.4.1 meldet ein Routing- oder Zugriffsproblem der Adresse im Verzeichnis, der 5.7.1 eine Filterrichtlinie oder eine verschlechterte Absenderreputation. Die Korrekturen unterscheiden sich völlig: Beim einen setzen Sie auf Verzeichnisseite an, beim anderen bei der Reputation.
Wie lange sollte man nach einer Resynchronisierung des Hybridverzeichnisses warten? Microsoft Entra Connect synchronisiert laut Microsoft Learn standardmäßig alle 30 Minuten, danach muss Exchange Online die Änderung noch übernehmen. Rechnen Sie mit einigen Stunden, bevor Sie auf eine andere Ursache schließen. Ein früherer neuer Versuch endet mit derselben Ablehnung.
Lässt eine Ablehnung mit 550 5.4.1 meine globale hard bounce-Rate steigen? Ja, jedes Auftreten zählt als hard bounce, in den Statistiken Ihres E-Mail-Tools wie in denen der empfangenden Mailanbieter. Häufen sich diese Ablehnungen in derselben Liste, leidet die sender reputation, auch wenn sonst kein Zustellbarkeitsfehler vorliegt. Wie sich solche Ablehnungen aufschaukeln, erklärt der Artikel zu SMTP-Ablehnungen und ihrem Anstieg.
