Kann ich die Mail einfach noch einmal senden?

Bei einem Code mit 4 vorne ja, und meist müssen Sie nicht einmal das: Der Server versucht die Zustellung selbst weiter. Bei einem Code mit 5 vorne hilft unverändertes erneutes Senden in der Regel nicht. Erst muss die Ursache behoben sein, etwa die Adresse korrigiert oder der DNS-Eintrag ergänzt.

Was bedeutet die Zahl 550 vor dem Statuscode?

Das ist der einfache SMTP-Antwortcode nach RFC 5321. Die 5 vorne steht für eine dauerhafte Ablehnung, 550 bedeutet, dass das Postfach nicht verfügbar ist: nicht gefunden, kein Zugriff oder aus Richtliniengründen abgelehnt. Den genauen Grund liefern der erweiterte Code dahinter und die Klartextzeile.

Warum kommen nur Mails an Gmail- oder Outlook.com-Adressen zurück?

Diese Anbieter prüfen SPF, DKIM und DMARC streng. Gmail lehnt nicht authentifizierte Mails mit 5.7.26 ab, Outlook.com bei hohem Versandvolumen mit 5.7.515. Kleinere Empfängerserver sind oft weniger streng. Kommen gezielt bei diesen Anbietern Berichte zurück, prüfen Sie die DNS-Einträge Ihrer Domain.

Ich bekomme Unzustellbarkeitsberichte zu Mails, die ich nie geschrieben habe. Bin ich gehackt?

Nicht zwingend. Prüfen Sie die Gesendeten Elemente. Stehen dort fremde Mails, ändern Sie sofort das Passwort und informieren Sie Ihren Administrator. Ist dort nichts Ungewöhnliches, hat vermutlich ein Spammer Ihre Adresse als Absender gefälscht. Diese sogenannten Backscatter-Berichte können Sie laut Microsoft ignorieren.

Ist Microsoft schuld, wenn das Microsoft-Logo im Bericht steht?

Nein, nicht unbedingt. Das Logo zeigt nur, dass Microsoft 365 den Bericht erzeugt hat. Wer abgelehnt hat, steht beim Remote-Server bzw. Generating server, und die Grafik im neueren Berichtsformat markiert, auf welcher Seite das Problem meist behoben werden muss.

Wie lange dauert es, bis ein korrigierter SPF- oder DMARC-Eintrag wirkt?

Microsoft gibt an, dass DNS-Änderungen bis zu 72 Stunden brauchen können, bis sie auf allen DNS-Servern angekommen sind. Oft geht es schneller. Testen Sie danach mit einer neuen Nachricht.

E-Mail & OutlookRedaktion Die Netzhandwerker · 14. November 2026 · 11 Min. Lesezeit

Outlook „Fehler bei der Nachrichtenzustellung“: Statuscodes 5.1.1, 5.4.1, 5.7.1, 5.7.26 lesen und beheben

Mitarbeiterin in einem kleinen Büro sitzt nachdenklich am Schreibtisch mit Laptop, Telefon und einem ausgedruckten Blatt

Die Meldung ist ein Unzustellbarkeitsbericht: Ein Mailserver auf dem Weg zum Empfänger hat Ihre Nachricht abgelehnt, Outlook selbst ist in der Regel nicht kaputt. Ob Sie sich vertippt haben, das Postfach des Empfängers streikt oder Ihre eigene Domain den Echtheitsnachweis nicht besteht, lesen Sie an drei Stellen ab: am Statuscode wie 5.1.1 oder 5.7.26, am Namen des ablehnenden Servers und an der englischen Klartextzeile. Die Tabelle unten ordnet jedem gängigen Code zu, wer zuständig ist und was Sie als Nächstes prüfen.

5.x.xDauerhafter Fehler: Unverändert erneut senden hilft laut RFC 3463 in der Regel nicht.

4.x.xVorübergehender Fehler: Der Server versucht die Zustellung selbst erneut.

4–5 TageSo lange soll ein Server laut RFC 5321 im Allgemeinen mindestens weiter versuchen.

72 StundenBis zu dieser Dauer können DNS-Änderungen laut Microsoft brauchen, bis sie überall wirken.

Stand 14.11.2026. Grundlage: Microsoft-Learn-Dokumentation zu Unzustellbarkeitsberichten in Exchange Online und Exchange Server, Microsoft-Support zu 5.7.515, Google-Workspace-Liste der Gmail-SMTP-Fehler sowie RFC 3463 und RFC 5321.

Kurze Antwort: Was die Meldung bedeutet
So ist der Bericht aufgebaut
Lesen Sie die Bounce-Mail in drei Schritten
Statuscode, Zuständigkeit, nächster Schritt: die Übersicht
Lösung in der richtigen Reihenfolge: einfache Fälle zuerst
Prüfreihenfolge für die eigene Domain
Wann es komplizierter wird
Vorbeugung

Kurze Antwort: Was die Meldung bedeutet

„Fehler bei der Nachrichtenzustellung an folgende Empfänger oder Gruppen“ ist die Überschrift eines Unzustellbarkeitsberichts, englisch Non-Delivery Report (NDR) oder Bounce. Der Bericht kommt als normale Mail in Ihren Posteingang, nachdem Outlook die Nachricht bereits erfolgreich an Ihren Mailserver übergeben hat. Abgelehnt hat sie ein Server danach: Ihr eigener Anbieter, ein Server unterwegs oder der Server des Empfängers.

Das zeigt den Unterschied zu Fehlern, bei denen Outlook gar nicht erst senden kann und eine Hex-Nummer wie 0x800CCC0E meldet. Diese Fälle behandelt der Beitrag Outlook-Fehler 0x800CCC0E, 0x8004010F und Co.

Der wichtigste Baustein im Bericht ist der erweiterte Statuscode nach RFC 3463 im Format Klasse.Bereich.Detail:

Erste Ziffer: 4 bedeutet vorübergehend, ein späterer Versuch kann klappen. 5 bedeutet dauerhaft, die Nachricht oder das Ziel muss sich ändern.
Zweite Ziffer: 1 Adresse, 2 Postfach, 3 Mailsystem, 4 Netz und Weiterleitung, 5 Protokoll, 6 Inhalt, 7 Sicherheit und Richtlinien.
Dritte Ziffer: der genaue Fall, etwa 5.1.1 für ein unbekanntes Postfach.

Als grober Wegweiser: 5.1.x deutet meist auf die Adresse, 5.2.x auf Postfach oder Sendelimit, 5.4.x auf den Weg zum Server, 5.7.x auf fehlende Berechtigung oder einen nicht bestandenen Echtheitsnachweis Ihrer Domain.

So ist der Bericht aufgebaut

Microsoft 365 erzeugt Berichte in einem neueren Format mit diesen Teilen: Ursache, einer Grafik mit den drei Beteiligten Absender, Microsoft 365 und Empfänger (rot markiert ist, wo das Problem meist behoben werden muss), einer Anleitung für den Absender, weiteren Informationen für Administratoren und den Stationen der Nachricht. Das Microsoft-Logo im Bericht heißt laut Microsoft nicht, dass Microsoft 365 den Fehler verursacht hat.

Ältere Berichte und viele fremde Server liefern zwei Blöcke: oben eine allgemein verständliche Benutzerinformation, darunter die Diagnoseinformationen für Administratoren. Dieser zweite Block ist schematisch so aufgebaut (Beispiel mit Platzhaltern):

Diagnostic information for administrators:
Generating server: mail.ihr-anbieter.example

[email protected]
mx.kunde.example
Remote Server returned '550 5.1.1 User unknown'

Original message headers:
...

Generating server: der Server, der den Bericht erstellt hat. Steht darunter kein eigener ablehnender Server, hat dieser Server die Mail auch selbst abgelehnt.
Remote server: der Server, der die Annahme verweigert hat. Er fehlt, wenn der Empfangsserver die Mail zunächst angenommen und erst später abgelehnt hat, etwa wegen Inhaltsregeln.
SMTP-Antwort: die Klartextzeile des ablehnenden Servers, laut Microsoft unverändert in US-ASCII, also meist englisch.
Original message headers: die Kopfzeilen Ihrer Mail. Hier stehen der Weg der Nachricht und die Ergebnisse von SPF, DKIM und DMARC.

Die Beschriftungen können je nach Server und Sprache übersetzt erscheinen. Die SMTP-Antwort und die Kopfzeilen bleiben nach Microsoft-Angaben englisch.

Lesen Sie die Bounce-Mail in drei Schritten

Statuscode suchen. Er steht in der Regel im Admin-Block, oft zusammen mit einem dreistelligen SMTP-Code davor, etwa 550 5.1.1. Nach RFC 5321 steht 4yz für eine vorübergehende, 5yz für eine dauerhafte Ablehnung. Ein 4er-Code im Bericht heißt meist: Der Server versucht es weiter, Sie bekommen nur eine Verzögerungsmeldung.
Ablehnenden Server bestimmen. Gehört der Name zur Domain des Empfängers oder zu dessen Mailanbieter, hat die Empfängerseite abgelehnt. Bei Empfängern mit Microsoft 365 endet er häufig auf mail.protection.outlook.com. Ist nur Ihr eigener Server genannt und kein Remote-Server, liegt die Ursache eher bei Ihnen: Adresse, Konto oder Sendelimit.
Klartextzeile lesen. Derselbe Code kann je nach Server Verschiedenes bedeuten. 5.2.2 heißt bei Google und Exchange Server „Postfach voll“, in Exchange Online dagegen „Submission quota exceeded“, also ein Sendelimit Ihres eigenen Kontos. Der Text entscheidet, nicht die Zahl allein.

Statuscode, Zuständigkeit, nächster Schritt: die Übersicht

Die Tabelle bündelt die Codes, die in Outlook- und Microsoft-365-Umgebungen am ehesten auftauchen. Klartext in Anführungszeichen ist die englische Formulierung aus der Microsoft- oder Google-Dokumentation. Andere Server formulieren teils anders.

Code und Klartext	Wer ist zuständig	Was Sie jetzt prüfen
5.1.1 „Bad destination mailbox address“, „User unknown“; 5.1.10 „Recipient not found“	Sie (Tippfehler, veralteter Vorschlag) oder Empfänger (Adresse gelöscht oder geändert)	Adresse Zeichen für Zeichen prüfen, Eintrag aus der AutoVervollständigen-Liste löschen, Adresse neu eintippen, neue Mail statt Antwort auf eine alte
5.2.2 „Mailbox full“ bzw. Gmail: Posteingang ohne Speicherplatz	Empfänger	Empfänger auf anderem Weg informieren, später erneut senden
5.2.2 „Submission quota exceeded“ (Exchange Online)	Ihr eigenes Konto hat ein Sendelimit überschritten	Gesendete Elemente auf fremde Mails prüfen, Administrator einschalten; Microsoft nennt eine Kontoübernahme als mögliche Ursache
5.2.3, 5.3.4 Nachricht zu groß	Sie oder Größenlimit des Empfängers	Anhang verkleinern oder weglassen und erneut senden
5.4.1 „Recipient address rejected: Access denied“	Empfängerseite: Die Adresse existiert in deren Microsoft 365 nicht	Schreibweise prüfen; stimmt sie, Empfänger telefonisch informieren, deren Administrator prüft die Einrichtung
5.4.1 „Relay Access Denied“	Empfängerseite: Der Server nimmt Mail für diese Domain nicht an, Server- oder DNS-Fehler	Empfänger informieren, vollständigen Bericht weitergeben
5.4.6, 5.4.14 „Routing loop detected“	Weiterleitungsregeln bei Absender oder Empfänger	Posteingangsregeln und Weiterleitungen beider Seiten prüfen
4.4.7, 5.4.300 „Message expired“	Meist der Empfangsserver	Adresse prüfen, später erneut senden; bleibt es, Empfänger informieren
4.4.316 „Connection refused“, später als 5.4.316 „Message expired, connection refused“	Laut Microsoft fast immer Server oder Netz des Empfängers	Abwarten, erneut senden; die IP-Adresse im Bericht zeigt, wessen Server nicht antwortet
5.7.1 „Delivery not authorized“	Empfänger oder Gruppenbesitzer: Absender nicht freigegeben, Gruppe nur für Mitglieder, Regel blockiert	Empfänger bzw. Besitzer der Gruppe um Freigabe bitten
5.7.1 „Unable to relay“, „Client was not authenticated“	Empfangsserver nimmt keine anonyme Mail an oder MX zeigt auf falschen Server	Empfänger informieren; trifft es Mails an Ihre Domain, eigenen MX-Eintrag prüfen
5.7.1 mit „blocked using Blocklist“	Absender-IP Ihres Mailsystems steht auf einer Sperrliste	Administrator folgt dem Hinweis zur Entfernung im Bericht
5.7.12, 5.7.133, 5.7.134 Absender nicht authentifiziert	Empfänger nimmt nur Mail von innerhalb der eigenen Organisation an	Nur dessen Administrator kann das ändern; Empfänger informieren
5.7.23 „Sender Policy Framework violation“	Ihre Domain: SPF-Eintrag unvollständig oder falsch	SPF-Eintrag Ihrer Domain prüfen
5.7.26 (Gmail) „sender is unauthenticated“, SPF „hard fail“ oder „not accepted due to domain's DMARC policy“	Ihre Domain: SPF bzw. DKIM nicht bestanden oder DMARC verletzt	SPF, DKIM und DMARC der Absenderdomain prüfen
5.7.509 „does not pass DMARC verification and has a DMARC policy of reject“	Ihre Domain	DMARC-Ausrichtung prüfen: SPF oder DKIM muss zur From-Domain passen
5.7.515 „does not meet the required authentication level“ (Outlook.com, Hotmail, Live)	Ihre Domain bei hohem Versandvolumen	SPF, DKIM und DMARC vollständig einrichten
5.7.513 „blocked … using Customer Block list“	Empfänger hat Ihre Absender-IP gesperrt	Empfänger direkt um Aufhebung bitten
5.7.520 „does not allow external forwarding“	Ihre Organisation blockiert automatische Weiterleitung nach außen	Administrator fragen, ob die Weiterleitung erlaubt werden soll
5.1.8 „bad outbound sender“, 5.7.501 „spam abuse detected“	Ihr Konto wurde wegen Spamversand gesperrt, laut Microsoft meist nach einer Übernahme	Passwort ändern, Geräte prüfen, Administrator einschalten

Die Faustregel daraus: Bei 5.1.x und 5.2.x schauen Sie zuerst auf Adresse und Postfach, bei 5.4.x und 4.x.x auf den Empfangsserver, bei 5.7.x mit SPF, DKIM oder DMARC im Text auf Ihre eigene Domain.

Lösung in der richtigen Reihenfolge: einfache Fälle zuerst

Microsoft nennt die falsche Adresse ausdrücklich als häufigste Ursache für 5.1.x-Fehler. Gehen Sie deshalb von außen nach innen vor:

Adresse vergleichen. Stellen Sie die Adresse im Bericht der Adresse in Ihrer gesendeten Mail gegenüber. Weichen beide voneinander ab, leitet der Empfänger Ihre Mail vermutlich per Regel an eine ungültige Adresse weiter. Das muss er selbst korrigieren.
AutoVervollständigen-Eintrag löschen. Outlook merkt sich Empfänger in einer eigenen Liste, auch Nickname-Cache genannt. Nach einem Postfachumzug kann der gespeicherte Eintrag ungültig sein, obwohl die Adresse gleich aussieht. So löschen Sie ihn: neue Nachricht öffnen, die ersten Buchstaben eintippen, den Vorschlag mit der Maus markieren, aber nicht auswählen, dann auf das X daneben klicken oder die Entf-Taste drücken. Danach die Adresse vollständig neu eintippen und eine neue Nachricht schreiben, statt die alte erneut zu senden. Outlook im Web führt eine eigene Liste, dort löschen Sie den Eintrag ebenfalls.
Postfach voll oder Nachricht zu groß. Bei „Mailbox full“ können nur der Empfänger oder sein Administrator Platz schaffen. Bei 5.2.3 oder 5.3.4 senden Sie die Nachricht ohne oder mit kleinerem Anhang erneut.
Vorübergehende Fehler abwarten. Bei 4.x.x versucht Ihr Server die Zustellung selbst weiter. RFC 5321 empfiehlt mindestens 30 Minuten zwischen den Versuchen und eine Aufgabe frühestens nach im Allgemeinen 4 bis 5 Tagen. Wie lange Ihr Anbieter tatsächlich wartet, legt er selbst fest. Erst wenn ein dauerhafter Bericht folgt, ist die Mail endgültig nicht angekommen.
Empfänger lehnt ab. Bei 5.7.1, 5.7.12, 5.7.513 oder 5.4.1 „Access denied“ können Sie selbst meist nichts ändern. Rufen Sie den Empfänger an und lassen Sie ihm den vollständigen Bericht zukommen, damit sein Administrator die Ursache findet. Bei einer internen Verteilergruppe nennt der Bericht die gesperrte Gruppe; deren Besitzer kann Sie freischalten.

Prüfreihenfolge für die eigene Domain

Kommen Mails an mehrere fremde Empfänger zurück und nennt der Klartext SPF, DKIM, DMARC oder „authentication“, liegt die Ursache fast sicher bei Ihrer Absenderdomain. Google verlangt für Gmail SPF oder DKIM, Microsoft lehnt bei Outlook.com Domains mit hohem Versandvolumen ohne bestandene Prüfung mit 5.7.515 ab. Prüfen Sie in dieser Reihenfolge:

Umfang klären: Betrifft es einen Empfänger oder viele? Einzelfälle sprechen eher für die Gegenseite, viele Fälle für Ihre Domain.
MX-Eintrag: Bei Microsoft 365 zeigt er auf <domain>.mail.protection.outlook.com oder eine Adresse unter mx.microsoft. Microsoft unterstützt für in Exchange Online eingebundene Domains nur einen MX-Eintrag. Ein falscher MX führt vor allem dazu, dass Mails an Sie nicht ankommen.
SPF: Der TXT-Eintrag muss alle Systeme nennen, die in Ihrem Namen senden: Microsoft 365, Newsletterdienst, Shop, Ticketsystem, Multifunktionsgerät. Endet er auf -all und fehlt eine Quelle, lehnt Gmail deren Mails mit 5.7.26 ab.
DKIM: Die Mails müssen mit einem Schlüssel Ihrer eigenen Domain signiert sein, nicht nur mit der Domain des Dienstleisters.
DMARC: Unter _dmarc.ihre-domain.de muss ein TXT-Eintrag stehen, mindestens v=DMARC1; p=none. DMARC besteht nur, wenn SPF oder DKIM besteht und zur Domain im From-Feld passt.
Kopfzeilen im Bericht lesen: In den Original-Kopfzeilen zeigt die Zeile Authentication-Results die Ergebnisse spf=, dkim= und dmarc=. Steht dort etwas anderes als pass, wissen Sie, welcher Baustein fehlt.
Drittanbieter: Prüfen Sie für jeden Dienst, der in Ihrem Namen sendet, ob Absenderadresse im Umschlag und DKIM-Signatur Ihre Domain verwenden.

Geduld nach Änderungen

Laut Microsoft können geänderte DNS-Einträge bis zu 72 Stunden brauchen, bis alle DNS-Server sie kennen. Testen Sie danach mit einer neuen Mail, nicht mit der zurückgekommenen.

Die Einträge MX, SPF, DKIM und DMARC können Sie mit dem Werkzeug MX-Einträge prüfen in einem Durchgang abfragen.

Wann es komplizierter wird

Sie haben die Mail gar nicht verschickt

Sehen Sie in den Gesendeten Elementen nach. Finden Sie dort fremde Nachrichten, wurde Ihr Konto vermutlich übernommen: Passwort ändern, Geräte auf Schadsoftware prüfen und den Administrator informieren, der das Konto bei einer Sperre wieder freischalten muss. Ist dort nichts Verdächtiges, handelt es sich wahrscheinlich um Backscatter: Ein Spammer hat Ihre Adresse als Absender gefälscht, und der Bericht landet bei Ihnen. Solche Berichte können Sie laut Microsoft ignorieren.

Sperrliste oder Kontosperre

Steht im Bericht „blocked using Blocklist“ mit dem Hinweis auf [email protected], ist die IP-Adresse Ihres sendenden Systems bei Microsoft gesperrt. Die Entfernung beantragt der Administrator über den im Bericht genannten Weg oder das Delist-Portal von Microsoft. Bei 5.1.8, 5.7.501 bis 5.7.503 oder 5.7.705 und 5.7.708 ist ein Konto oder der ganze Mandant wegen Spamverdacht gesperrt; hier hilft nur, die Ursache zu beseitigen und den Microsoft-Support über den normalen Weg zu kontaktieren.

Weiterleitungen

Automatische Weiterleitungen können SPF und DKIM brechen und dadurch DMARC-Ablehnungen auslösen. Microsoft nennt Weiterleitung ausdrücklich als einen Grund für DMARC-Fehler. Prüfen Sie bei rätselhaften 5.7.x-Fehlern, ob die Mail über eine Weiterleitung lief.

Viele Fehler gleichzeitig bei Microsoft 365

Kommen plötzlich zahlreiche Berichte zurück, lohnt im Microsoft 365 Admin Center der Blick unter Health › Service health auf bekannte Störungen. Administratoren können dort auch die NDR-Diagnose starten und den Statuscode einfügen. Was Sie während einer Störung tun können, beschreibt der Notfallplan für Outlook- und Microsoft-365-Störungen.

Vorbeugung

AutoVervollständigen pflegen: Ändert ein Kontakt seine Adresse oder zieht Ihr Betrieb mit dem Postfach um, löschen Sie veraltete Vorschläge. Die ganze Liste leert Outlook unter File › Options › Mail › Send messages › Empty Auto-Complete List (Bezeichnungen der englischen Oberfläche laut Microsoft).
Jeden Versandweg erfassen: Führen Sie eine kurze Liste aller Dienste, die mit Ihrer Domain Mails verschicken. Kommt ein neuer hinzu, ergänzen Sie SPF und richten DKIM ein, bevor die ersten Mails rausgehen.
DMARC einführen: Starten Sie mit p=none und werten Sie die Berichte aus, bevor Sie die Richtlinie verschärfen. So sehen Sie fehlende Absender, bevor Empfänger deren Mails ablehnen.
Weiterleitungen sparsam einsetzen: Regeln, die Mail automatisch nach außen schicken, sind eine häufige Quelle für Schleifen und DMARC-Probleme.
Berichte nicht löschen, sondern lesen: Der Statuscode und die Klartextzeile sparen bei jeder Nachfrage beim Empfänger oder Anbieter Zeit. Leiten Sie den vollständigen Bericht weiter, nicht nur einen Screenshot.

Passend dazu

Zeigt der Bericht 5.7.23, 5.7.26, 5.7.509 oder 5.7.515, liegt die Ursache meist in den DNS-Einträgen Ihrer Domain. Mit dem Werkzeug „MX-Einträge prüfen“ sehen Sie MX, SPF, DKIM und DMARC auf einen Blick und erkennen, welcher Eintrag fehlt oder falsch ist.

Mehr dazu: MX-Einträge prüfen: DNS, SPF, DKIM, DMARC testen

Quellen

Microsoft Learn: Email nondelivery reports (NDRs) and SMTP errors in Exchange Online, learn.microsoft.com
Microsoft Learn: Fix NDR 550 5.1.1 to 5.1.20 in Exchange Online, learn.microsoft.com
Microsoft Learn: Fix NDR error 550 5.7.1 in Exchange Online, learn.microsoft.com
Microsoft Learn: Fix NDR error 550 5.4.1 in Exchange Online, learn.microsoft.com
Microsoft Learn: DSNs and NDRs in Exchange Server, learn.microsoft.com
Microsoft Learn: The Outlook AutoComplete list, learn.microsoft.com
Microsoft Support: Fix NDR error 550 5.7.515 in Outlook.com, support.microsoft.com
Google Workspace: Gmail SMTP errors and codes, knowledge.workspace.google.com
RFC 3463: Enhanced Mail System Status Codes, www.rfc-editor.org
RFC 5321: Simple Mail Transfer Protocol, www.rfc-editor.org

Alle Quellen gelesen am 14.11.2026.

Erstellt von der Redaktion Die Netzhandwerker mit KI-Unterstützung. Die Sachangaben wurden vor der Veröffentlichung automatisch gegen die genannten Quellen geprüft.