Outlook lehnte echte Mails ab: So prüft Ihre IT SPF, DKIM und DMARC in 30 Minuten

Die Offerte kam nie an, im Postfach liegt eine Unzustellbarkeitsmeldung von Outlook.com. Die Panne vom November ist behoben, doch sie zeigt, wo DNS-Einträge Lücken haben. Diese Prüfliste schliesst sie, mit Befehlen und Beispielen.

Redaktion Vortrieb14. November 20268 Min. Lesezeit

Outlook lehnte echte Mails ab: So prüft Ihre IT SPF, DKIM und DMARC in 30 Minuten
Foto: Eesti Post / Wikimedia Commons, Public domain, bearbeitet

Der Vortrieb-Brief

Jeden Dienstag eine Anleitung, eine Vorlage, eine Zahl.

Abonnieren

Kurz gesagt: Vom 5. bis 10. November 2026 lehnte Outlook.com auch Mails kleiner Absender ab, mit Fehlern wie 550 5.7.1 und 550 5.7.23. Microsoft meldete am 10. November, das Problem sei behoben. Unabhängig davon gilt seit Mai 2025: Wer mehr als 5000 Mails pro Tag an Outlook.com, Hotmail und Live schickt, braucht bestandenes SPF und DKIM sowie einen DMARC-Eintrag, sonst folgt der Fehler 550 5.7.515. Die IT prüft die drei DNS-Einträge in rund 30 Minuten, die Vorlage unten zeigt wie.

Am Morgen kommt die Rückmeldung vom Kunden: Die Offerte sei nie angekommen. Im Postfach der Buchhaltung liegt stattdessen eine Unzustellbarkeitsmeldung. So erging es ab dem 5. November 2026 vielen Firmen, die an Adressen bei Outlook.com, Hotmail oder Live schrieben. Gemeldet wurden die Fehler 550 5.7.1 mit dem Zusatz «Message lacks SPF/DKIM/DMARC Auth Records» und 550 5.7.23, eine Ablehnung wegen SPF, wie Nutzer im Microsoft-Forum dokumentierten.

Was Microsoft verlangt und was im November schiefging

Zwei Dinge muss die IT auseinanderhalten. Das erste ist eine feste Regel. Im April 2025 kündigte Microsoft an, dass Domains mit mehr als 5000 Mails pro Tag an die privaten Dienste Outlook.com, Hotmail und Live ab dem 5. Mai strengere Anforderungen erfüllen müssen. SPF muss bestehen, DKIM muss bestehen, und es braucht einen DMARC-Eintrag mit mindestens p=none, der zu SPF oder DKIM passt. Wer die Regel verletzt, landet nicht mehr im Junk-Ordner. Die Mail wird abgewiesen, mit der Meldung «550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level». Microsoft erklärt den Fehler in einer eigenen Support-Anleitung.

Das zweite war eine Panne. Ab dem 5. November 2026 kamen Ablehnungen auch bei Absendern an, die weit unter 5000 Mails pro Tag liegen. Laut CSO Online traf es Domains ohne DMARC-Eintrag oder mit fehlerhaftem SPF und DKIM, teils aber auch korrekt eingerichtete. Ein Microsoft-Sprecher sagte am 10. November: «We’ve resolved an issue that may have prevented some email messages from reaching Outlook.com, Hotmail and Live addresses.» Die Ursache lag gemäss dem Bericht in einer Änderung der Spam-Regeln.

Schema: Eine Mail von beispiel.ch durchläuft bei Outlook.com die Prüfungen SPF, DKIM und DMARC, danach Zustellung oder Abweisung mit 550 5.7.515.
SPF, DKIM und DMARC entscheiden, ob eine Mail ankommt. Quelle: Microsoft Support und Microsoft Learn

Die Panne ist vorbei, die Lehre bleibt. Wer betroffen war, hatte meist eine Lücke in den DNS-Einträgen. Das Bundesamt für Cybersicherheit (BACS) empfiehlt E-Mail-Administratoren ohnehin, «Mechanismen zur Absenderverifikation (SPF, DKIM, DMARC) zu konfigurieren», so steht es im Wochenrückblick vom 29. April 2025 zu CEO-Betrug gegen Gemeinden. Die drei Einträge schützen also doppelt: Ihre Rechnungen kommen an, und Betrüger können Ihre Domain schwerer fälschen. Wie gefälschte Absender die Buchhaltung angreifen, zeigt unsere Anleitung zu Phishing und dem Firmenkonto.

Betroffen sind alle, die aus dem Firmennamen Mails verschicken: Rechnungen aus der Buchhaltungssoftware, Offerten aus dem CRM, Newsletter aus dem Versanddienst, Terminbestätigungen aus dem Webshop. Jeder dieser Dienste verschickt im Namen Ihrer Domain. Jeder muss in den Einträgen vorkommen.

Die Prüfung in 30 Minuten

Sie brauchen keine Zusatzsoftware. Ein Befehlsfenster reicht. Unter Windows nehmen Sie nslookup, unter macOS und Linux dig. Ersetzen Sie in den Beispielen beispiel.ch durch Ihre Domain.

Serverschränke in einem Rechenzentrum: Hier entscheidet sich, ob eine Mail ihr Ziel erreicht.
Serverschränke in einem Rechenzentrum: Hier entscheidet sich, ob eine Mail ihr Ziel erreicht. Foto: Carl Lender from Sunrise, USA / Wikimedia Commons, CC BY 2.0, bearbeitet

SPF (5 Minuten). Der SPF-Eintrag listet alle Server, die für Ihre Domain senden dürfen. Abfrage: nslookup -type=TXT beispiel.ch oder dig TXT beispiel.ch +short. Suchen Sie die Zeile, die mit v=spf1 beginnt. Ein Eintrag für Microsoft 365 mit einem Newsletter-Dienst sieht so aus: v=spf1 include:spf.protection.outlook.com include:spf.versanddienst.example -all. Laut Microsoft-Dokumentation ist pro Domain nur ein SPF-Eintrag erlaubt, und Microsoft empfiehlt am Schluss -all.

DKIM (5 Minuten). DKIM signiert jede Mail. Der Empfänger prüft die Signatur mit einem öffentlichen Schlüssel im DNS. Bei Microsoft 365 heissen die Einträge selector1._domainkey und selector2._domainkey. Abfrage: nslookup -type=CNAME selector1._domainkey.beispiel.ch. Kommt keine Antwort, signiert Microsoft 365 nicht mit Ihrer Domain. Andere Dienste nutzen eigene Selektoren, die Sie in deren Einstellungen finden.

DMARC (5 Minuten). DMARC verbindet beides und sagt dem Empfänger, was bei einem Fehler geschehen soll. Abfrage: nslookup -type=TXT _dmarc.beispiel.ch. Ein Einstieg sieht so aus: v=DMARC1; p=none; rua=mailto:dmarc@beispiel.ch. Fehlt der Eintrag, sind Sie genau in der Gruppe, die im November abgewiesen wurde.

Gegenprobe und Drittanbieter (15 Minuten). Schicken Sie aus jedem Dienst eine Testmail an eine private Outlook.com-Adresse. Öffnen Sie die Kopfzeilen der Nachricht und suchen Sie die Zeile Authentication-Results. Dort sollte spf=pass, dkim=pass und dmarc=pass stehen. Microsoft rät in der Support-Anleitung, auch zu prüfen, ob die Domain im Return-Path zur sichtbaren Absenderadresse passt.

Die vier häufigsten Fehler

  • Zwei SPF-Einträge. Der Newsletter-Dienst verlangte einen Eintrag, jemand legte einfach einen zweiten an. Mehrere SPF-Einträge führen laut Microsoft zu einem permerror, SPF scheitert dann ganz. Die Lösung: alle Angaben in einer Zeile zusammenführen.
  • Mehr als 10 DNS-Abfragen. Jedes include, a, mx, exists und redirect zählt als Abfrage, verschachtelte include-Einträge der Anbieter ebenfalls. Über 10 scheitert SPF mit permerror. Feste IP-Adressen mit ip4 zählen nicht. Werfen Sie alte Dienste aus dem Eintrag, die Sie nicht mehr nutzen.
  • Vergessene Absender. Die Buchhaltungssoftware schickt QR-Rechnungen mit Ihrer Adresse als Absender, steht aber weder im SPF noch signiert sie mit DKIM. Gerade Rechnungen und Mahnungen hängen daran. Wer Rechnungen per Mail verschickt, findet die Grundlagen in unserer Rechnungsvorlage für die Schweiz.
  • DMARC zu früh scharf. Wer direkt p=reject setzt, ohne die Berichte gelesen zu haben, sperrt eigene Dienste aus. Darum stufenweise vorgehen.
Drei Stufen der DMARC-Richtlinie: p=none sammelt Berichte, p=quarantine markiert, p=reject weist ab.
DMARC schrittweise von none über quarantine zu reject verschärfen. Quelle: Microsoft Learn

Von none zu reject, mit Blick aufs Datenschutzgesetz

DMARC kennt drei Stufen. Bei p=none gibt es keine Anweisung, Sie sammeln nur Berichte. Bei p=quarantine soll der Empfänger die Mail annehmen, aber markieren, meist landet sie im Junk-Ordner. Bei p=reject soll er sie abweisen. Die Microsoft-Anleitung zu DMARC rät, mit p=none zu beginnen, die Berichte auszuwerten und dann über quarantine zu reject zu wechseln. Mit pct lässt sich die Stufe zuerst auf einen Teil der Mails anwenden, etwa pct=10, dann 25, 50, 75 und 100.

Die Berichte haben eine Kehrseite. Die täglichen Sammelberichte (rua) enthalten gemäss Microsoft die IP-Adressen der Server, die im Namen Ihrer Domain senden. Personendaten sind nach Art. 5 Bst. a des Datenschutzgesetzes alle Angaben zu einer bestimmten oder bestimmbaren Person, und eine IP-Adresse kann dazu gehören, etwa bei einem Mitarbeitenden, der vom Heimanschluss sendet. Fehlerberichte (ruf) beziehen sich auf einzelne Mails. Lassen Sie die Berichte von einem externen Dienst auswerten, ist dieser Auftragsbearbeiter nach Art. 9 DSG. Sitzt er ausserhalb der Schweiz, gelten die Regeln zur Bekanntgabe ins Ausland. Tragen Sie die Bearbeitung in Ihr Verzeichnis der Bearbeitungstätigkeiten ein und verzichten Sie auf ruf, wenn Sie die Fehlerberichte nicht brauchen.

Vorlage: Prüfliste für die Fachleitung IT

  1. Alle Dienste auflisten, die mit Ihrer Domain Mails versenden: Mailsystem, Buchhaltung, CRM, Newsletter, Webshop, Scanner, Ticketsystem.
  2. SPF abfragen: genau ein Eintrag, alle Dienste enthalten, höchstens 10 DNS-Abfragen, Abschluss mit -all.
  3. DKIM für jeden Dienst einschalten und die Einträge im DNS prüfen.
  4. DMARC-Eintrag mit p=none und einer eigenen Berichtsadresse anlegen, falls er fehlt.
  5. Aus jedem Dienst eine Testmail an eine Outlook.com-Adresse senden und Authentication-Results prüfen.
  6. Vier Wochen lang die DMARC-Berichte lesen und unbekannte Absender klären.
  7. Auf p=quarantine wechseln, mit pct schrittweise bis 100, danach p=reject.
  8. Berichtsauswertung im Verzeichnis der Bearbeitungstätigkeiten erfassen und bei externem Dienst einen Auftragsbearbeitungsvertrag abschliessen.
EintragBeispiel für beispiel.chPrüfen mit
SPF (TXT auf beispiel.ch)v=spf1 include:spf.protection.outlook.com -allnslookup -type=TXT beispiel.ch
DKIM (CNAME auf selector1._domainkey.beispiel.ch)zeigt auf den Schlüssel bei Microsoft 365nslookup -type=CNAME selector1._domainkey.beispiel.ch
DMARC (TXT auf _dmarc.beispiel.ch)v=DMARC1; p=none; rua=mailto:dmarc@beispiel.chnslookup -type=TXT _dmarc.beispiel.ch

Fällt bei der Prüfung auf, dass Fremde Ihre Domain bereits für Betrugsmails nutzen, klären Sie, ob eine Meldung nötig ist. Unsere Übersicht zu den Meldepflichten bei Cybervorfällen hilft dabei.

Häufige Fragen

Gilt die Microsoft-Regel auch für KMU mit wenig Mailverkehr?

Die feste Regel mit dem Fehler 550 5.7.515 gilt für Domains mit mehr als 5000 Mails pro Tag an Outlook.com, Hotmail und Live. Die Panne im November 2026 traf aber auch kleine Absender. Saubere Einträge schützen in beiden Fällen.

Muss ich nach der Panne etwas ändern?

Microsoft meldete am 10. November 2026, das Problem sei behoben. Fehlt Ihnen aber ein DMARC-Eintrag oder scheitern SPF oder DKIM, sollten Sie das trotzdem korrigieren. Das BACS empfiehlt alle drei Verfahren.

Reicht p=none dauerhaft?

Für Outlook.com reicht p=none als Mindestanforderung. Gegen gefälschte Absender schützt p=none aber nicht, weil der Empfänger keine Anweisung erhält. Microsoft empfiehlt, schrittweise auf p=reject zu wechseln.

Sind DMARC-Berichte ein Datenschutzthema?

Ja. Die Sammelberichte enthalten IP-Adressen der sendenden Server, die Personendaten sein können. Erfassen Sie die Bearbeitung im Verzeichnis und regeln Sie die Auswertung durch Dritte vertraglich.

Zum Mitnehmen

  1. Ein SPF-Eintrag, alle Absender. Buchhaltung, Newsletter und Webshop gehören in denselben Eintrag, mit höchstens 10 DNS-Abfragen.
  2. Ohne DMARC kein sicherer Versand. Ein Eintrag mit p=none ist das Minimum, reject das Ziel.
  3. Berichte sind Daten. DMARC-Berichte enthalten IP-Adressen und gehören ins Verzeichnis der Bearbeitungstätigkeiten.

Quellen

  1. Microsoft Tech Community: Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders, 2. April 2025, aktualisiert 30. April 2025
  2. Microsoft Support: Fix NDR error 550 5.7.515 in Outlook.com, aktualisiert September 2026
  3. Microsoft Learn: Set up SPF to identify valid email sources, Juli 2026
  4. Microsoft Learn: Set up DKIM to sign mail, Juli 2026
  5. Microsoft Learn: Set up DMARC to validate the From address domain, Juli 2026
  6. Microsoft Q&A: 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records, 6. November 2026
  7. CSO Online: Microsoft’s email security is unexpectedly blocking legitimate business mail, 9. November 2026, aktualisiert 10. November 2026
  8. Bundesamt für Cybersicherheit BACS: Woche 17: Anhaltende CEO-Betrugsversuche gegen Schweizer Gemeinden, 29. April 2025
  9. Fedlex: Bundesgesetz über den Datenschutz (DSG), SR 235.1, in Kraft seit 1. September 2023

Weiterlesen