Outlook.com lehnt E-Mails ab: DMARC-Fehler 550 5.7.1 beheben

Deine E-Mail ist technisch sauber verschickt worden, landet aber trotzdem nicht bei Hotmail oder Outlook.com? Seit Anfang November 2026 berichten Betreiber kleiner Mailserver und eigener Domains über neue Zustellprobleme. Statt einer angenommenen Nachricht kommt eine Fehlermeldung wie 550 5.7.1 zurück. Besonders auffällig: Microsoft nennt SPF, DKIM und DMARC als Ursache, obwohl SPF und DKIM beim Absender durchaus korrekt eingerichtet sein können.

Eine konkrete, vergleichsweise einfache Lösung gibt es für einen Teil der Fälle: einen fehlenden DMARC-Eintrag im DNS ergänzen. Das behebt aber nicht jede Zurückweisung. Microsoft hat am 9. November in seinem Supportforum auch eine laufende Beeinträchtigung der Zustellung an Outlook.com, Hotmail und Live eingeräumt. Deshalb zeige ich dir hier, wie du den Fehler richtig einordnest, die drei Authentifizierungsverfahren prüfst und vermeidest, durch hektische DNS-Änderungen alles noch schlimmer zu machen.

Stand: 10. November 2026. Der Störungsstatus kann sich kurzfristig ändern. Dieser Ratgeber richtet sich vor allem an Betreiber eigener Domains und E-Mail-Dienste; als reiner Empfänger findest du weiter unten eigene Hinweise.

Was ist bei Outlook.com und Hotmail passiert?

Berichte von Maildienstleistern beschreiben seit dem 5. November Ablehnungen an Microsofts private Postfächer – also unter anderem Adressen mit @outlook.com, @hotmail.com oder @live.com. Betroffen sind nicht nur große Newsletter-Versender, sondern offenbar auch kleinere Absender mit vergleichsweise wenig täglichem Mailverkehr. Die Meldung ist deshalb besonders ärgerlich für Handwerker, Vereine, kleine Onlineshops oder selbst betriebene Mailserver.

Eine häufig dokumentierte Rückmeldung lautet sinngemäß 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records. Teilweise tauchen auch 550 5.7.23 und die Kennung AS9031519 auf. Das ist eine Ablehnung während der SMTP-Zustellung – die Nachricht wurde also nicht einfach nur in den Spamordner des Empfängers verschoben.

Wichtig: Die Fehlermeldung ist zunächst eine Diagnose des empfangenden Systems. Sie beweist nicht automatisch, dass alle drei Verfahren fehlen. Ein fehlender DMARC-DNS-Eintrag kann ein Auslöser sein. Es gibt aber auch Berichte über weiterhin abgewiesene E-Mails mit bereits vorhandenen Authentifizierungseinträgen. Microsofts Support bezeichnete solche Fälle am 9. November als Teil einer untersuchten Dienstbeeinträchtigung.

Schnellcheck: Welcher Fall trifft auf dich zu?

• Du nutzt eine eigene Domain und bekommst einen Bounce mit 550 5.7.1 oder AS9031519: Prüfe zuerst den DMARC-Eintrag der sichtbaren Absenderdomain.
• SPF und DKIM sind gültig, aber DMARC fehlt: Einen einfachen DMARC-DNS-Eintrag ergänzen und die Zustellung später erneut testen.
• DMARC ist vorhanden, dennoch kommt eine Ablehnung: Ausrichtung (Alignment), Versanddienst und die vollständige Fehlermeldung prüfen. Anschließend mögliche Microsoft-Störung berücksichtigen.
• Nur einzelne Outlook-/Hotmail-Adressen sind betroffen: Auf Empfängerdomain und Rückmeldung achten. Das ist noch kein Beweis für einen Fehler deines Mailprogramms.
• Du bist ausschließlich der Empfänger: Du kannst die DNS-Authentifizierung der fremden Absenderdomain nicht selbst korrigieren. Bitte den Absender um Prüfung oder nutze vorübergehend einen zweiten Kontaktweg.

SPF, DKIM und DMARC – was steckt hinter den Kürzeln?

Die drei Verfahren sollen verhindern, dass jemand ohne Erlaubnis E-Mails im Namen deiner Domain verschickt. Sie prüfen allerdings Unterschiedliches. Für die Fehlersuche ist diese Unterscheidung entscheidend.

SPF: Darf dieser Server für die Domain versenden?

SPF ist ein DNS-TXT-Eintrag, der festlegt, welche Server für eine Domain E-Mails verschicken dürfen. Nutzt du einen Webhoster, einen Newsletter-Dienst und zusätzlich ein Shopsystem, müssen die jeweils erforderlichen Versandwege berücksichtigt sein. Fehler entstehen oft, wenn der neue Newsletter-Anbieter zwar eingerichtet wurde, im SPF-Eintrag aber fehlt.

DKIM: Hat der zuständige Maildienst die Nachricht signiert?

DKIM hängt eine kryptografische Signatur an die Mail. Der Empfänger kann mit einem öffentlichen Schlüssel aus dem DNS überprüfen, ob die Signatur gültig ist. Die Schlüssel und DNS-Namen richten sich nach deinem Mailanbieter. Den konkreten DKIM-Eintrag solltest du deshalb aus dessen Verwaltungsoberfläche übernehmen, statt ihn selbst zu erfinden.

DMARC: Passt die Authentifizierung zur sichtbaren Absenderadresse?

DMARC verbindet die technische Authentifizierung mit der Adresse, die der Empfänger im Von-Feld sieht. Es reicht nicht, dass irgendein beteiligter Server einen SPF- oder DKIM-Test besteht: Mindestens einer der beiden Wege muss auch zur sichtbaren Absenderdomain passen, das sogenannte Alignment. DMARC legt außerdem fest, wie Empfänger mit nicht authentifizierten Nachrichten grundsätzlich umgehen sollen.

Genau hier steckt die Falle. Du kannst in einem Prüfbericht spf=pass und dkim=pass lesen – und dennoch keinen gültigen, passend ausgerichteten DMARC-Nachweis für die sichtbare Absenderdomain haben.

Lösung 1: Fehlenden DMARC-Eintrag im DNS ergänzen

Bei einer eigenen Domain ist das der naheliegendste erste Schritt. Und keine Sorge: Für den Einstieg muss niemand sofort eine strenge Sperrpolitik aktivieren. Ein einfacher Monitoring-Eintrag genügt, um die Domain grundsätzlich mit einem veröffentlichten DMARC-Datensatz auszustatten. Eine Erfolgsgarantie für Outlook.com ist das nicht.

Schritt 1: Zuständigen DNS-Anbieter ermitteln

Öffne die Domainverwaltung bei deinem Hoster oder Registrar. Dort findest du normalerweise einen Bereich wie „DNS“, „DNS-Zone“, „Zone Editor“ oder „DNS-Einträge“. Entscheidend ist der Dienst, bei dem die autoritativen Nameserver deiner Domain liegen. Ein Eintrag im falschen Kundenmenü bewirkt nichts.

Schritt 2: Vorhandenen DMARC-Datensatz suchen

Suche nach einem TXT-Eintrag mit dem Namen _dmarc beziehungsweise _dmarc.deinedomain.de. Gibt es bereits einen solchen Eintrag, erst einmal nichts doppelt anlegen. DMARC benötigt einen eindeutigen Datensatz; mehrere konkurrierende DMARC-TXT-Records können die Prüfung ungültig machen.

Schritt 3: Nur falls nötig einen TXT-Eintrag anlegen

Falls wirklich kein DMARC-Datensatz existiert, ist dieser vorsichtige Ausgangspunkt für die meisten eigenen Domains geeignet:

Typ:   TXT
Name:  _dmarc
Wert:  v=DMARC1; p=none

Die Domain deinedomain.de ist hier nur ein Beispiel. Je nach Hoster gibst du als Namen nur _dmarc ein oder den vollständigen Namen _dmarc.deinedomain.de. Manche Bedienoberflächen ergänzen die Domain automatisch – andernfalls entsteht versehentlich _dmarc.deinedomain.de.deinedomain.de. Die TTL kann beim Standardwert bleiben.

Was bedeutet p=none? Damit teilst du empfangenden Systemen mit, dass die Domain DMARC einsetzt, verlangst aber aufgrund der eigenen DMARC-Richtlinie noch keine Quarantäne oder Ablehnung. Die Nachricht muss trotzdem die übrigen Prüfungen bestehen und kann weiterhin von einem Anbieter zurückgewiesen werden. Erst nach Kontrolle aller legitimen Versandwege solltest du über strengere Richtlinien wie p=quarantine oder p=reject nachdenken.

Schritt 4: DNS-Eintrag unabhängig kontrollieren

Nach dem Speichern kann die DNS-Änderung aufgrund bestehender Caches verzögert sichtbar werden. Unter Windows öffnest du die Eingabeaufforderung oder PowerShell und gibst Folgendes ein; ersetze die Beispieldomain durch deine echte Domain:

nslookup -type=TXT _dmarc.deinedomain.de

Unter Linux oder macOS mit installiertem dig geht es so:

dig +short TXT _dmarc.deinedomain.de

In der Antwort sollte genau dein veröffentlichter DMARC-Wert erscheinen. Taucht gar nichts auf, prüfe zunächst die zuständige DNS-Zone und den Hostnamen. Erscheinen mehrere unterschiedliche Einträge mit v=DMARC1, muss der Konflikt behoben werden.

Schritt 5: Neue Testmail verschicken

Versende nach der DNS-Aktualisierung eine neue Testmail aus demselben System, das zuvor gescheitert ist, an eine Outlook.com- oder Hotmail-Adresse. Schau nicht nur nach, ob sie ankommt: Prüfe auch, ob ein erneuter Zustellfehler zurückgeht. Bereits endgültig abgewiesene Nachrichten werden durch eine DNS-Korrektur nicht automatisch nachträglich zugestellt. Wichtige Nachrichten musst du gegebenenfalls erneut verschicken.

Lösung 2: SPF richtig prüfen – aber nicht blind überschreiben

Steht im Bounce ein SPF-Hinweis, kontrolliere den TXT-Datensatz deiner Versanddomain. Er beginnt normalerweise mit v=spf1. Der Eintrag muss die tatsächlichen Versandserver berücksichtigen. Ein externer Formular-Dienst oder ein Newsletter-Tool braucht unter Umständen eine Ergänzung, auch wenn die normale Firmenmail problemlos funktioniert.

Am häufigsten läuft hier etwas schief, weil mehrere Systeme unabhängig voneinander eingerichtet wurden. Ein besonders typischer Fehler sind zwei separate SPF-Einträge mit v=spf1 am selben Domainnamen. Stattdessen müssen die erlaubten Versanddienste sinnvoll in einer einzigen SPF-Policy zusammengeführt werden. Wie das bei deinem Anbieter aussieht, steht in dessen Originaldokumentation. Bestehende Syntax nicht auf Verdacht ersetzen.

Lösung 3: DKIM und DMARC-Alignment kontrollieren

Wenn du E-Mails beispielsweise über einen Shop, einen Newsletter-Anbieter oder eine WordPress-Seite verschickst, verwendet die Versandplattform womöglich ihre eigene Signaturdomain. Das kann völlig legitim sein. Für DMARC muss aber entweder der über SPF geprüfte Domainbezug oder die DKIM-Signaturdomain passend zur sichtbaren Von-Adresse ausgerichtet sein.

Bitte den Mailanbieter, die vollständigen Authentifizierungsergebnisse beziehungsweise die Nachrichtenheader einer erfolgreich angenommenen Vergleichsmail bereitzustellen. Dort sind Angaben wie spf=pass, dkim=pass sowie dmarc=pass oder dmarc=fail interessant. Der DKIM-Wert d= nennt die Signaturdomain. Prüfe außerdem, ob die Adresse im sichtbaren Von-Feld wirklich die gewünschte Domain verwendet.

Besonders wichtig: Manche Website-Formulare senden technisch über den Server deines Webhosters, obwohl als Von-Adresse eine fremde Adresse des Besuchers eingesetzt ist. Das führt schnell zu Authentifizierungsproblemen. Besser ist häufig ein echtes Postfach deiner eigenen Domain als Absender; die Besucheradresse gehört dann in das Reply-To-Feld. Das ist kein Outlook-Spezialtrick, sondern saubere Mailtechnik.

Lösung 4: Wenn alle DNS-Einträge stimmen und Microsoft trotzdem ablehnt

Gibt es genau einen gültigen DMARC-Datensatz, und SPF, DKIM sowie Alignment sind nachweislich in Ordnung, solltest du nicht endlos neue DNS-Werte ausprobieren. Die am 9. November dokumentierte Microsoft-Aussage zu einer Dienstbeeinträchtigung macht deutlich, dass nicht jeder Fehler allein beim Absender liegen muss.

Gehe dann am besten so vor:

• Speichere die vollständige Unzustellbarkeitsnachricht (NDR/Bounce) inklusive des SMTP-Fehlercodes und einer eventuell enthaltenen Kennung wie AS9031519.
• Notiere Datum und Uhrzeit mit Zeitzone, die betroffene Empfängerdomain, den Versanddienst und – wenn vorhanden – die Message-ID und den protokollierten SMTP-Dialog. Personenbezogene Mailinhalte nur teilen, wenn wirklich erforderlich.
• Prüfe, ob andere Empfänger außerhalb von Outlook.com/Hotmail die Nachrichten erhalten und ob das Problem alle oder nur einzelne Empfänger betrifft.
• Wende dich mit den technischen Daten an deinen Mailhoster beziehungsweise den verwendeten Versanddienst. Der kann die Ablehnung anhand seiner SMTP-Logs und der Microsoft-Postmaster-Kanäle fachlich weiterverfolgen.
• Falls der Versanddienst keine Lösung findet, nutze das Microsoft-Sender-Support-Umfeld beziehungsweise die im Microsoft-Supportthread genannten Kontaktwege. Sicherheitsrelevante DNS-Sperren oder Schutzfunktionen dafür nicht abschalten.

Bei dringenden Geschäftsmails ist ein zweiter Kontaktweg sinnvoll. Ein veränderter Absender von einem fremden Freemailkonto kann allenfalls eine temporäre Notlösung sein, nicht die eigentliche Behebung des Domainproblems. Wichtige Informationen nicht versehentlich doppelt versenden, wenn die ursprüngliche Nachricht noch in der Warteschlange eines Mailservers liegt.

Was kannst du tun, wenn du die fehlenden Nachrichten empfangen sollst?

Schau zunächst nach, ob der Absender wirklich eine Unzustellbarkeitsnachricht erhalten hat. Bei einer endgültigen SMTP-Ablehnung hilft es meist nicht, nur den Outlook-Spamordner zu durchsuchen: Die Nachricht wurde womöglich überhaupt nicht in dein Postfach aufgenommen.

Bitte den Absender, die genaue Bounce-Meldung an seinen Administrator oder Mailanbieter weiterzugeben. Wenn du dringend auf eine Rechnung, Buchung oder Antwort wartest, vereinbart einen alternativen, passenden Übertragungsweg. Der Empfänger kann die SPF-, DKIM- und DMARC-Einträge einer fremden Domain nicht selbst ändern.

Diese Fehler solltest du bei der Reparatur vermeiden

• DMARC doppelt anlegen: Vor einem neuen TXT-Eintrag immer den vorhandenen DNS-Bestand prüfen.
• Sofort p=reject aktivieren: Wenn legitime Shop- oder Newsletter-Systeme noch nicht richtig authentifiziert sind, können dadurch eigene E-Mails verloren gehen.
• SPF komplett neu schreiben: Damit schließt du unter Umständen bestehende Versanddienste aus. Änderungen nur anhand einer vollständigen Senderliste vornehmen.
• DNS-Cache ignorieren: Änderungen sind nicht zwangsläufig sofort auf allen empfangenden Systemen sichtbar.
• Nur einen Testaccount prüfen: Eine erfolgreich zugestellte Nachricht beweist noch nicht, dass alle Versandwege und alle Empfängerserver funktionieren.
• Outlook-Programm zurücksetzen: Bei einer SMTP-Ablehnung mit DMARC-Hinweis bringt die Neuinstallation der Windows-App normalerweise nichts. Das Problem spielt sich zwischen Mailservern ab.

Häufige Fragen zum Outlook.com-Zustellproblem

Ist DMARC jetzt für jede kleine Domain Pflicht?

Microsoft hatte bereits zum 5. Mai 2025 besondere Anforderungen für Absender eingeführt, die täglich mehr als 5.000 Nachrichten an Outlook.com-Adressen senden. Die nun im November 2026 berichteten Ablehnungen bei kleineren Absendern sind davon zu unterscheiden. Aus einzelnen Fehlermeldungen lässt sich noch keine endgültig bestätigte allgemeine neue Pflicht für sämtliche Kleinstversender ableiten. Einen sauberen DMARC-Eintrag einzurichten, ist dennoch sinnvoll.

Reicht v=DMARC1; p=none immer aus?

Nein. Damit veröffentlichst du eine DMARC-Policy, aber SPF oder DKIM und die passende Domainausrichtung müssen weiterhin stimmen. Außerdem können serverseitige Störungen, Reputation, andere Filter und zusätzliche Richtlinien die Zustellung beeinflussen.

Wie lange dauert die Korrektur?

Das Speichern des DNS-Eintrags geht oft schnell. Wann alle beteiligten Server die Änderung berücksichtigen, hängt von DNS-TTLs und Caches ab. Wenn die Einträge öffentlich korrekt sichtbar sind, ein erneuter Versand aber weiterhin scheitert, ist die vollständige Fehlermeldung der nächste Ansatzpunkt.

Muss ich den Mailanbieter wechseln?

Nein, nicht als erste Maßnahme. Prüfe zuerst DNS, Authentifizierung und die aktuelle Fehlerlage beim Empfänger. Ein Anbieterwechsel kann neue SPF-, DKIM- und DMARC-Probleme erzeugen, wenn der Umzug nicht sauber vorbereitet ist.

Fazit: Erst DMARC prüfen, dann sauber eingrenzen

Bei Outlook.com und Hotmail werden im November 2026 Nachrichten zurückgewiesen, obwohl der Absender auf den ersten Blick alles richtig eingerichtet hat. Fehlt bei deiner Domain DMARC, ist ein gültiger TXT-Eintrag mit p=none ein sinnvoller erster Schritt. Sind SPF, DKIM und DMARC bereits korrekt eingerichtet, ist wahlloses Herumschrauben am DNS dagegen keine gute Idee. Dann brauchst du die genaue SMTP-Ablehnung und gegebenenfalls Unterstützung des Versanddienstes oder von Microsoft.

Mehr zu Microsoft-Problemen auf computer4you.de: Outlook-Fehler 0x8004010F beheben betrifft ein anderes Fehlerbild im Desktop-Programm. Und warum ein vermeintlich korrekter Absender noch kein Sicherheitsbeweis ist, erkläre ich im Ratgeber zu Phishing trotz echtem Absender.

Quellen und weiterführende Dokumentation

• Microsoft Q&A: SPF validation error – Supportantwort vom 9. November 2026 zur laufenden Zustellbeeinträchtigung.
• MailRoute: Outlook rejecting email without DMARC – Dokumentation der beobachteten Ablehnungen seit Anfang November.
• Microsoft Learn: DMARC für Microsoft 365 konfigurieren – technische Erklärung von SPF, DKIM, Alignment und Richtlinien.
• Microsoft: Anforderungen für Absender mit hohem Mailaufkommen – ältere Regeln für mehr als 5.000 Nachrichten pro Tag.