Rechnungen, Angebote, Antworten an Kunden: Ab dem 5. November 2026 kamen bei vielen Unternehmen E-Mails zurück, die an Adressen bei Outlook.com, Hotmail, Live und MSN gerichtet waren. Die Rückmeldung lautete „550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records“, später mit dem Zusatz „AS9031519“. Betroffen waren vor allem Absender, deren Domain keinen DMARC-Eintrag hat – auch dann, wenn SPF und DKIM korrekt eingerichtet waren. Microsoft hat den Fehler inzwischen bestätigt und behoben. Abgewiesene Nachrichten werden jedoch nicht nachträglich zugestellt.
Was vom 5. bis 9. November passiert ist
Die frühesten dokumentierten Ablehnungen tauchten am 5. November in den Versandprotokollen des E-Mail-Dienstleisters MailRoute auf. In den folgenden Tagen meldeten Administratoren in Foren und auf Fachlisten dasselbe Muster: Nachrichten an private Microsoft-Postfächer wurden bereits bei der Einlieferung abgewiesen, während dieselben Nachrichten an andere Empfänger ankamen. Der E-Mail-Anbieter Fastmail berichtete von Kunden mit eigener Domain, bei denen SPF und DKIM bestanden, aber kein DMARC-Eintrag vorhanden war. Ein Test des Anbieters EasyDMARC am 8. November bestätigte das Bild.
Auffällig war die Unregelmäßigkeit: Manche Nachrichten derselben Domain kamen an, andere nicht, und ein erneuter Versand war teilweise erfolgreich. Einzelne Administratoren meldeten Ablehnungen auch für Domains mit vollständig eingerichtetem SPF, DKIM und DMARC. Ob diese Fälle dieselbe Ursache hatten, ist bis heute nicht geklärt.
- 5. November 2026MailRoute verzeichnet die ersten Ablehnungen mit „550 5.7.1 … lacks SPF/DKIM/DMARC Auth Records“ für Mails an Outlook.com und Hotmail.
- 6. November, 19:00 UhrBeginn der Störung nach Angaben von Microsoft (18:00 Uhr UTC). Spätere Rückmeldungen tragen zusätzlich die Kennung „AS9031519“.
- 7. und 8. NovemberTests von EasyDMARC und DMARKOFF bestätigen die Ablehnung. In der Testreihe von DMARKOFF weisen ohne DMARC-Eintrag alle 16 getesteten Outlook.com- und Hotmail-Postfächer die Nachricht ab; mit einem Eintrag „p=none“ wird sie angenommen, landet aber im Spam-Ordner.
- 9. November, 06:24 UhrMicrosoft aktualisiert seine Meldung EX1545193 im Microsoft 365 Service Health und bittet Betroffene um Nachrichtenkennungen und Beispielnachrichten.
- 9. November, 12:02 UhrEnde der Störung nach Angaben von Microsoft (11:02 Uhr UTC): Outlook.com, Hotmail und Live nehmen die Nachrichten wieder an.
- 10. November, 06:36 UhrAbschlussmeldung von Microsoft: Ein Update der Spam-Regeln habe Nachrichten fälschlich markiert und blockiert; es wurde vollständig zurückgenommen.
In seiner Abschlussmeldung schreibt Microsoft, ein kürzlich eingespieltes Update der Regeln zur Spam-Abwehr habe dazu geführt, dass E-Mails fälschlich markiert und blockiert wurden. Das Unternehmen kündigte an, seine Abläufe für solche Updates zu überprüfen und die Erkennung zu verbessern, um Fehlalarme zu verringern. Eine neue Anforderung an Absender hat Microsoft nicht angekündigt.
Welche Absender und Empfänger betroffen waren
- Empfänger: Adressen bei Outlook.com, Hotmail.com, Live.com und MSN – also die kostenlosen Microsoft-Postfächer für Privatpersonen. Gerade Selbstständige, kleine Betriebe und viele Privatkunden nutzen diese Adressen.
- Firmenpostfächer in Microsoft 365: In der Testreihe von DMARKOFF nahmen sie die Nachrichten ohne DMARC-Eintrag an, ebenso Gmail.
- Absender: vor allem Domains ohne DMARC-Eintrag. SPF und DKIM allein schützten in dieser Zeit nicht vor der Ablehnung.
- Absender über Exchange Online (Microsoft 365) erhielten teils eine abweichende Rückmeldung mit dem Code 550 5.7.23, der eigentlich einen SPF-Verstoß bezeichnet. Viele Administratoren prüften daraufhin ihren SPF-Eintrag, der korrekt war – die Ursache lag an anderer Stelle.
Die Fehlercodes im Überblick
| Rückmeldung | Bedeutung | Was zu tun ist |
|---|---|---|
| 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) | Ablehnung durch Outlook.com während der Störung vom 5. bis 9. November 2026 | Nachricht erneut senden; DMARC-Eintrag setzen, falls noch keiner vorhanden ist |
| 550 5.7.23 | Rückmeldung an Absender über Exchange Online; bezeichnet formal einen SPF-Verstoß | SPF prüfen; war SPF korrekt, lag es an der Störung – erneut senden |
| 550 5.7.515 Access denied, sending domain does not meet the required authentication level | Regel für Absender mit 5.000 oder mehr Mails pro Tag an Outlook.com (angekündigt im April 2025, gilt seit 5. Mai 2025) | SPF und DKIM bestehen lassen, DMARC mindestens mit „p=none“ und passender Ausrichtung |
Eine Rückmeldung mit 5xx ist eine endgültige Ablehnung. Anders als bei einer vorübergehenden Störung (4xx) versucht der eigene Mailserver die Zustellung nicht erneut. Was zwischen dem 5. und 9. November an Outlook.com-Adressen abgewiesen wurde, liegt beim Empfänger nicht vor – auch nicht im Spam-Ordner.
Warum gerade der DMARC-Eintrag den Unterschied machte
Drei Verfahren sichern heute ab, dass eine E-Mail tatsächlich von der Domain stammt, die im Absender steht. SPF legt fest, welche Server für eine Domain versenden dürfen. DKIM versieht jede Nachricht mit einer digitalen Signatur. DMARC verbindet beide mit der sichtbaren Absenderadresse und sagt dem Empfänger, wie er mit Nachrichten umgehen soll, die die Prüfung nicht bestehen – und wohin er Berichte darüber schickt.
Der DMARC-Eintrag ist ein einzelner TXT-Eintrag im DNS unter „_dmarc.“ vor der eigenen Domain. Ohne ihn fehlt dem Empfänger die ausdrückliche Aussage des Domaininhabers, wie mit gefälschten Nachrichten zu verfahren ist. Die Testreihen legen nahe, dass das fehlerhafte Update genau dieses Fehlen als Merkmal für Spam wertete; Microsoft selbst nennt DMARC in seiner Meldung nicht. Die Testreihe von DMARKOFF zeigte, dass schon ein Eintrag mit der Richtlinie „p=none“ genügte, damit Outlook.com die Nachricht annahm – wenn auch im Spam-Ordner, und sogar dann, wenn der Eintrag nur bei der übergeordneten Domain stand und die versendende Subdomain ihn erbte.
| Verfahren | Was es prüft | Wo es steht |
|---|---|---|
| SPF | Darf dieser Server für die Domain senden? | TXT-Eintrag der Domain, z. B. „v=spf1 include:… -all“ |
| DKIM | Ist die Nachricht unterwegs unverändert geblieben und von der Domain signiert? | Öffentlicher Schlüssel als TXT- oder CNAME-Eintrag unter „selector._domainkey“ |
| DMARC | Passt SPF oder DKIM zur sichtbaren Absenderadresse – und was soll der Empfänger tun, wenn nicht? | TXT-Eintrag unter „_dmarc.“ der Domain |
Ist DMARC Pflicht?
Ein Gesetz, das jedem Unternehmen einen DMARC-Eintrag vorschreibt, gibt es nicht. Die großen Postfachanbieter verlangen ihn aber zunehmend. Google und Yahoo fordern seit Februar 2024 von Massenversendern SPF, DKIM und DMARC. Microsoft hat am 2. April 2025 vergleichbare Anforderungen für Domains angekündigt, die 5.000 oder mehr Nachrichten pro Tag an Outlook.com senden: SPF und DKIM müssen bestehen, DMARC muss mindestens mit der Richtlinie „p=none“ veröffentlicht sein und zu SPF oder DKIM passen. Ab dem 5. Mai 2025 landeten Nachrichten, die das nicht erfüllen, zunächst im Junk-Ordner; inzwischen weist Outlook.com sie laut Microsoft mit dem Code 550 5.7.515 ab.
Für kleinere Absender gilt diese Regel ausdrücklich nicht – und sie galt auch während der Störung nicht. Die Tage im November haben aber gezeigt, wie schnell eine fehlende Angabe im DNS zum Zustellproblem wird. Das BSI beschreibt in der Technischen Richtlinie TR-03182 „E-Mail-Authentifizierung“ prüfbare Anforderungen an E-Mail-Anbieter; die Verfahren SPF, DKIM und DMARC gelten dort als Stand der Technik.
Wie ein DMARC-Eintrag aussehen muss
Der kleinste sinnvolle Eintrag besteht aus der Versionsangabe und der Richtlinie. Empfehlenswert ist zusätzlich eine Adresse für die täglichen Sammelberichte (rua), denn erst diese Berichte zeigen, welche Server im Namen der Domain senden. Ein Beispiel für die Domain example.de:
_dmarc.example.de. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-berichte@example.de"| Angabe | Bedeutung |
|---|---|
| v=DMARC1 | Versionskennung, muss am Anfang stehen |
| p=none | Beobachten: Der Empfänger wendet keine Maßnahme an und schickt Berichte, sofern eine rua-Adresse angegeben ist. Richtig für den Einstieg. |
| p=quarantine | Nicht bestandene Nachrichten landen im Spam-Ordner |
| p=reject | Nicht bestandene Nachrichten werden abgewiesen – der wirksamste Schutz gegen gefälschte Absender |
| rua=mailto:… | Adresse für die täglichen Sammelberichte der Empfänger |
| sp=… | Eigene Richtlinie für Subdomains; ohne Angabe gilt die Richtlinie der Hauptdomain |
| t=y | Testmodus: Empfänger wenden die nächstmildere Richtlinie an, aus „reject“ wird „quarantine“. Ersetzt in der aktuellen DMARC-Fassung RFC 9989 das frühere „pct“ |
DMARC einrichten: so gehen Sie vor
Für eine Domain mit wenigen Versanddiensten ist der erste Schritt in einer Viertelstunde erledigt. Das Verschärfen bis „p=reject“ dauert einige Wochen, weil man die Berichte abwarten muss.
- Bestand prüfen. Mit einem DMARC-Check feststellen, ob für die Domain bereits ein Eintrag existiert und wie SPF und DKIM stehen. Gibt es schon einen Eintrag, nicht einfach einen zweiten anlegen – zwei DMARC-Einträge machen beide ungültig.
- Alle Versandwege auflisten. Neben dem Mailserver oder Microsoft 365 auch Newsletter-Dienst, Online-Shop, Ticketsystem, Warenwirtschaft, Kopierer mit Scan-to-Mail und Buchhaltungssoftware. Jeder dieser Wege muss im SPF-Eintrag stehen oder mit DKIM der eigenen Domain signieren.
- DKIM aktivieren. In Microsoft 365 werden zuerst zwei CNAME-Einträge im DNS veröffentlicht; danach wird DKIM im Microsoft Defender-Portal unter E-Mail & Zusammenarbeit › Richtlinien & Regeln › Bedrohungsrichtlinien › Einstellungen für die E-Mail-Authentifizierung › DKIM je Domain eingeschaltet. Andere Anbieter stellen den Schlüssel als TXT-Eintrag bereit.
- DMARC mit „p=none“ veröffentlichen. Den TXT-Eintrag unter „_dmarc.“ der Domain anlegen, mit einer Berichtsadresse. Nach der Verbreitung im DNS – meist innerhalb weniger Minuten bis Stunden – führen Outlook.com, Gmail und andere Empfänger die DMARC-Prüfung durch; bestehen muss sie weiterhin über SPF oder DKIM.
- Berichte zwei bis vier Wochen auswerten. Die Sammelberichte zeigen jeden Server, der im Namen der Domain sendet, und ob SPF und DKIM dabei bestehen. Unbekannte Absender sind entweder vergessene Dienste – oder Fälschungsversuche.
- Schrittweise verschärfen. Sobald alle legitimen Versandwege bestehen, auf „p=quarantine“ und danach auf „p=reject“ umstellen, bei Bedarf zunächst im Testmodus „t=y“. Erst „p=reject“ verhindert wirksam, dass Dritte Mails im Namen Ihrer Domain verschicken.
Was Unternehmen jetzt konkret tun sollten
- Rückläufer vom 5. bis 9. November suchen. In den Postfächern nach Unzustellbarkeitsberichten mit „5.7.1“, „5.7.23“ oder „AS9031519“ suchen. In Microsoft 365 hilft die Nachrichtenablaufverfolgung im Exchange Admin Center, alle abgewiesenen Nachrichten an outlook.com, hotmail.com und live.com aus diesem Zeitraum zu finden.
- Wichtige Nachrichten erneut senden. Rechnungen, Mahnungen, Angebote, Fristsachen und Antworten an Kunden erneut versenden. Bei Rechnungen lohnt ein kurzer Hinweis an den Empfänger, damit keine Zahlungsfrist strittig wird.
- DMARC-Eintrag prüfen und setzen. Fehlt der Eintrag, ihn wie oben beschrieben mit „p=none“ und Berichtsadresse anlegen. Ein vorhandener Eintrag mit „p=none“ bleibt bestehen – er fordert von Empfängern keine Maßnahme gegen die eigenen Nachrichten.
- Weitere Ablehnungen beobachten. Tauchen nach dem 9. November um 12:02 Uhr weiterhin Ablehnungen mit „AS9031519“ auf, die betroffenen Nachrichten über die Nachrichtenablaufverfolgung prüfen und bei Microsoft-365-Mandanten eine Supportanfrage stellen.
- Zuständigkeit festlegen. Klären, wer die DMARC-Berichte liest und wer neue Versanddienste vorher freigibt. Ein DMARC-Eintrag ohne Auswertung bleibt beim Einstieg stehen und schützt nicht vor Fälschungen.
Warum kommen meine E-Mails plötzlich nicht mehr an?
Die Outlook-Störung war ein Sonderfall. Kommen Nachrichten dauerhaft nicht an, liegen die Ursachen meist an anderer Stelle: ein SPF-Eintrag mit mehr als zehn DNS-Abfragen, ein abgelaufener oder fehlender DKIM-Schlüssel nach einem Anbieterwechsel, ein Mailserver auf einer Sperrliste, ein neuer Versanddienst, der nirgends eingetragen ist, oder ein Postfach, das selbst als Spamquelle aufgefallen ist. Die Rückmeldung des empfangenden Servers nennt in der Regel einen Code, der die Richtung vorgibt – der Blick in den Unzustellbarkeitsbericht ist deshalb immer der erste Schritt.
Einordnung: eine Störung, aber ein deutliches Signal
Microsoft hat den Fehler zurückgenommen, und für kleine Absender gibt es keine neue Pflicht. Trotzdem ist die Richtung eindeutig: Google, Yahoo und Microsoft werten fehlende Authentifizierung zunehmend als Warnzeichen, und das BSI empfiehlt die Verfahren seit Jahren. Wer heute keinen DMARC-Eintrag hat, riskiert nicht nur Rückläufer bei der nächsten Regeländerung, sondern lässt auch zu, dass Dritte Rechnungen und Zahlungsaufforderungen im Namen der eigenen Domain verschicken – ein Einfallstor für Rechnungsbetrug, das sich mit „p=reject“ wirksam schließen lässt.
In unserer Betreuung prüfen wir SPF, DKIM und DMARC für alle Domains unserer Kunden, werten die DMARC-Berichte aus und führen Domains schrittweise bis zur Richtlinie „p=reject“. Mit dem kostenlosen SPF- und DMARC-Test auf unserer Website sehen Sie in einer Minute, wie Ihre eigene Domain heute dasteht.
Häufige Fragen
Warum hat Outlook.com meine E-Mails abgelehnt?
Ein fehlerhaftes Update der Spam-Regeln hat bei Outlook.com Nachrichten von Domains ohne DMARC-Eintrag teilweise abgewiesen, mit der Meldung „550 5.7.1 … lacks SPF/DKIM/DMARC Auth Records (AS9031519)“. Laut Microsoft dauerte die Störung vom 6. November, 19 Uhr, bis 9. November, 12:02 Uhr; erste Ablehnungen wurden bereits am 5. November beobachtet. Am 10. November meldete Microsoft, das Update sei vollständig zurückgenommen.
Kommen die abgelehnten Mails noch an?
Nein. Eine Rückmeldung mit 550 ist eine endgültige Ablehnung, der eigene Server versucht es nicht erneut. Wichtige Nachrichten aus diesem Zeitraum müssen Sie selbst noch einmal senden.
Ist DMARC Pflicht?
Gesetzlich nicht. Google, Yahoo und Microsoft verlangen DMARC aber von Absendern großer Mengen – Microsoft seit Mai 2025 für Domains mit 5.000 oder mehr Mails pro Tag an Outlook.com. Für alle anderen ist der Eintrag dringend empfohlen, auch vom BSI.
Wie muss ein DMARC-Eintrag aussehen?
Ein TXT-Eintrag unter „_dmarc.“ vor der Domain, zum Beispiel „v=DMARC1; p=none; rua=mailto:dmarc-berichte@example.de“. „p=none“ ist der Einstieg, „p=quarantine“ und „p=reject“ sind die schärferen Stufen.
Was ist der Standard-DMARC-Eintrag?
Für den Einstieg „v=DMARC1; p=none“ mit einer Berichtsadresse über „rua=mailto:…“. Er fordert von Empfängern keine Maßnahme gegen die eigenen Nachrichten und liefert die Berichte, die man zum Verschärfen braucht.
Wie richte ich DMARC ein?
Erst alle Versandwege erfassen, SPF und DKIM für jeden davon einrichten, dann den DMARC-Eintrag mit „p=none“ und Berichtsadresse veröffentlichen. Nach zwei bis vier Wochen Auswertung schrittweise auf „p=quarantine“ und „p=reject“ umstellen.
Reichen SPF und DKIM nicht aus?
Für die Zustellung bei Outlook.com reichten sie während der Störung nicht. Grundsätzlich prüfen SPF und DKIM nur den technischen Absender; erst DMARC verbindet sie mit der Adresse, die der Empfänger sieht, und legt fest, was mit Fälschungen passiert.
Wann schlägt DMARC fehl?
Wenn weder SPF noch DKIM besteht oder die dabei geprüfte Domain nicht zur sichtbaren Absenderadresse passt. Häufigster Grund sind Dienste, die im Namen der Domain senden, aber nicht eingetragen sind – etwa Newsletter-Werkzeuge oder Buchhaltungssoftware.
Warum bekomme ich DMARC-Reports?
Weil Ihr DMARC-Eintrag eine Berichtsadresse über „rua“ nennt. Die Empfänger schicken täglich eine Zusammenfassung, welche Server in Ihrem Namen gesendet haben und ob die Prüfung bestanden wurde. Diese Berichte sind die Grundlage, um die Richtlinie zu verschärfen.
Waren auch Firmenpostfächer in Microsoft 365 betroffen?
Gemeldet wurden Ablehnungen für Empfänger bei Outlook.com, Hotmail, Live und MSN. In der Testreihe von DMARKOFF nahmen Firmenpostfächer in Microsoft 365 die Nachrichten ohne DMARC-Eintrag an.
Verwandte Themen: Wer hier weiterdenkt, liest bei Phishing und Ransomware, Patch-Management und Passkey-Umstellung weiter.
Im Text erwähnt
Quellen
- Outlook.com's DMARC Rejections: What Microsoft Said · MailRoute
- Outlook.com: The email is real – but it still isn't getting through · heise online / iX
- Microsoft bug caused Outlook and Hotmail rejections over missing DMARC · IT-Connect
- Outlook rejects mail without DMARC (AS9031519) – Testreihe · DMARKOFF
- Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders · Microsoft
- BSI TR-03182 E-Mail-Authentifizierung · BSIamtlich
- Fix NDR error 550 5.7.515 in Outlook.com · Microsoft
- RFC 9989 – Domain-Based Message Authentication, Reporting, and Conformance (DMARC) · IETF
