SPF, DKIM, DMARC in Microsoft 365: Warum Outlook.com Mails abweist und wie Sie Ihre Domain absichern

• Seit Anfang November 2026 berichten Fachmedien und Administratoren, dass Outlook.com Mails von Domains ohne DMARC-Eintrag abweist, auch wenn SPF und DKIM stimmen; Microsoft hat das bisher nicht bestätigt.
• Belegt ist eine ältere Regel: Seit dem 5. Mai 2025 lehnt Outlook.com Mails von Domains mit mehr als 5.000 Mails pro Tag ab, wenn SPF, DKIM und DMARC nicht korrekt eingerichtet sind.
• Microsoft 365 richtet für eigene Domains weder DKIM-Signaturen noch einen DMARC-Eintrag automatisch ein, beides müssen Administratoren selbst erledigen.
• Ein DMARC-Eintrag mit p=none behebt das Problem nur, wenn SPF oder DKIM zur Absenderdomain passen.
• Microsoft empfiehlt, die DMARC-Richtlinie schrittweise von p=none über p=quarantine auf p=reject zu verschärfen.

SPF, DKIM, DMARC entscheiden darüber, ob Ihre Mails beim Empfänger ankommen. Wie wichtig das ist, zeigt sich gerade bei Microsoft: Seit Anfang November 2026 berichten Fachmedien und Administratoren, dass die Microsoft-Dienste für Privatkunden, also Outlook.com, Hotmail.com, Live.com und MSN.com, Mails von Domains ohne DMARC-Eintrag zurückweisen. Betroffen sind demnach auch Absender, deren SPF und DKIM korrekt eingerichtet sind. Der Absender erhält eine Unzustellbarkeitsnachricht mit dem Fehler „550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records“.

Wichtig: Microsoft hat diese Änderung bis zum 9. November 2026 weder angekündigt noch bestätigt. Wir stützen uns hier auf Berichte, nicht auf eine offizielle Mitteilung.

Offiziell belegt ist dagegen eine Regel, die schon länger gilt. Laut Microsoft müssen Domains, die mehr als 5.000 Mails pro Tag an Adressen von Outlook.com, Hotmail.com und Live.com senden, seit dem 5. Mai 2025 drei Bedingungen erfüllen:

• SPF muss für die sendende Domain bestehen.
• Die DKIM-Prüfung muss bestehen.
• Es muss ein DMARC-Eintrag mit mindestens p=none vorhanden sein, der zu SPF oder DKIM passt, am besten zu beiden.

Mails, die diese Bedingungen nicht erfüllen, lehnt Outlook.com mit dem Fehler „550 5.7.515 Access denied“ ab. Ein Eintrag in der Liste sicherer Absender des Empfängers hilft laut Microsoft nicht. Microsoft betont außerdem, dass alle Absender von diesen Verfahren profitieren, auch unterhalb der Schwelle.

Für Unternehmen bedeutet das: Wer Rechnungen, Angebote oder Bestellbestätigungen an Kunden mit privaten Microsoft-Adressen schickt, sollte SPF, DKIM und DMARC jetzt vollständig einrichten.

Die drei Verfahren ergänzen sich. Jedes beantwortet eine andere Frage.

• SPF (Sender Policy Framework) legt in einem TXT-Eintrag im DNS fest, welche Server Mails für Ihre Domain versenden dürfen. Der Empfänger prüft, ob der einliefernde Server in dieser Liste steht.
• DKIM (DomainKeys Identified Mail) signiert wichtige Teile jeder ausgehenden Mail digital. Der öffentliche Schlüssel liegt im DNS. So erkennt der Empfänger, dass die Mail unterwegs nicht verändert wurde.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) verbindet beide Prüfungen mit der Absenderadresse, die der Empfänger im Feld „Von“ sieht. Eine Mail besteht DMARC, wenn SPF oder DKIM besteht und die geprüfte Domain zur Domain im Absender passt. Außerdem legt DMARC fest, was mit Mails geschehen soll, die durchfallen, und wohin Berichte gesendet werden.

SPF und DKIM allein schützen also nicht davor, dass Angreifer Ihre Domain im sichtbaren Absender missbrauchen. Erst DMARC schließt diese Lücke.

Hier liegt die häufigste Ursache für Probleme. Laut Microsoft-Dokumentation gilt:

• Für die Domain auf onmicrosoft.com sind SPF und DKIM bereits eingerichtet. Den DMARC-Eintrag müssen Sie dagegen selbst im Microsoft 365 Admin Center anlegen.
• Für Ihre eigenen Domains legen Sie den SPF-Eintrag beim Domain-Registrar oder DNS-Anbieter an. Mails werden erst dann mit Ihrer eigenen Domain per DKIM signiert, wenn Sie DKIM für diese Domain aktivieren.
• Für DMARC eigener Domains gibt es in Microsoft 365 weder ein Portal noch PowerShell-Befehle. Der Eintrag entsteht ausschließlich beim Registrar oder DNS-Anbieter.

Viele Tenants versenden deshalb seit Jahren Mails mit korrektem SPF, aber ohne eigene DKIM-Signatur und ohne DMARC-Eintrag. Genau diese Konstellation ist von den aktuellen Abweisungen betroffen.

Wenn Sie Mails ausschließlich über Exchange Online versenden, besteht der SPF-Eintrag Ihrer Domain laut Microsoft aus drei Teilen: der Kennung „v=spf1“, dem Verweis „include:“ auf den Domainnamen spf.protection.outlook.com und der Regel „-all“ am Ende. Zwischen „include:“ und dem Domainnamen steht kein Leerzeichen, und hinter dem Domainnamen folgt kein Punkt. Microsoft nennt beides als typische Fehler, an denen die SPF-Prüfung scheitert.

Beachten Sie außerdem:

1. Pro Domain darf es nur einen SPF-Eintrag geben. Haben Sie bereits einen, ergänzen Sie ihn, statt einen zweiten anzulegen.
2. Weitere Versanddienste wie Newsletter-Systeme, ERP- oder Ticketsysteme nehmen Sie mit eigenem „include:“ oder ihrer IP-Adresse in denselben Eintrag auf.
3. Ein SPF-Eintrag darf insgesamt höchstens 10 DNS-Abfragen auslösen. Sonst schlägt die Prüfung fehl.
4. Den Verweis auf Microsoft 365 sollten Sie nicht durch feste IP-Adressen ersetzen, weil Microsoft seine Versand-IP-Adressen häufig ändert.

DKIM richten Sie im Microsoft Defender Portal oder per Exchange Online PowerShell ein.

1. Öffnen Sie im Microsoft Defender Portal Email & collaboration > Policies & rules > Threat policies > Email authentication settings und dort die Registerkarte DKIM.
2. Wählen Sie Ihre Domain aus. Der Status lautet zunächst „NoDKIMKeys“ oder „CnameMissing“.
3. Übernehmen Sie aus dem Bereich Publish CNAMEs die beiden Werte für „selector1._domainkey“ und „selector2._domainkey“.
4. Legen Sie bei Ihrem DNS-Anbieter zwei CNAME-Einträge mit genau diesen Werten an.
5. Sobald Microsoft 365 die Einträge erkennt, aktivieren Sie Sign messages for this domain with DKIM signatures.

Per PowerShell zeigt der Befehl „Get-DkimSigningConfig“ den Status und die benötigten CNAME-Werte, „Set-DkimSigningConfig -Enabled $true“ schaltet die Signatur ein.

Seit Mai 2025 verwendet Microsoft für neu hinzugefügte Domains ein neues Format der CNAME-Ziele, das auf „dkim.mail.microsoft“ endet. Bestehende Domains behalten das alte Format. Übernehmen Sie die Werte deshalb immer aus dem Portal oder aus PowerShell und bauen Sie sie nie selbst zusammen.

Für Domains, die Sie vor längerer Zeit eingerichtet haben, lohnt sich ein Blick auf die Schlüssellänge. Standard sind 1024 Bit. Mit einer Schlüsselrotation lässt sich auf 2048 Bit umstellen; eine Rotation dauert laut Microsoft vier Tage (96 Stunden), bis der neue Schlüssel signiert.

Den DMARC-Eintrag legen Sie als TXT-Eintrag mit dem Namen „_dmarc“ bei Ihrem DNS-Anbieter an. Für den Einstieg empfiehlt Microsoft eine Richtlinie ohne Wirkung, die nur Berichte anfordert. Der Eintrag beginnt dann mit „v=DMARC1; p=none; rua=mailto:“ und endet mit der Adresse des Postfachs, das die Berichte empfangen soll.

Mit „rua“ erhalten Sie zusammengefasste Berichte darüber, welche Server Mails mit Ihrer Domain versenden und ob diese SPF und DKIM bestehen. Outlook.com versendet solche Berichte laut Microsoft ebenfalls. So finden Sie Versanddienste, an die niemand mehr gedacht hat.

Vergessen Sie die Domain auf onmicrosoft.com nicht. Wenn Sie über sie keine Mails versenden, empfiehlt Microsoft einen DMARC-Eintrag mit p=reject. Sie legen ihn im Microsoft 365 Admin Center unter Settings > Domains an: Domain auswählen, Registerkarte DNS records, Add record, Typ TXT, Name „_dmarc“, Wert „v=DMARC1; p=reject“.

Auch für Domains, die Sie besitzen, aber nicht für Mails nutzen, empfiehlt Microsoft einen DMARC-Eintrag mit p=reject. Für solche Domains sollten Sie keine DKIM-Einträge veröffentlichen.

Ein Eintrag mit p=none erfüllt die Mindestanforderung, schützt Ihre Domain aber noch nicht vor Missbrauch. Microsoft empfiehlt ein schrittweises Vorgehen:

1. p=none: Berichte auswerten und alle legitimen Versandquellen mit SPF und DKIM ausstatten.
2. p=quarantine: Mails, die DMARC nicht bestehen, landen beim Empfänger im Junk-Ordner. Mit dem Wert „pct“ lässt sich der Anteil schrittweise erhöhen, etwa 10, 25, 50, 75 und 100 Prozent.
3. p=reject: Mails, die DMARC nicht bestehen, werden abgelehnt. Erst diese Stufe schützt Ihre Domain wirksam vor gefälschten Absendern.

Beginnen Sie mit Subdomains mit wenig Versand und stellen Sie die Hauptdomain zuletzt um. Subdomains übernehmen die DMARC-Einstellungen der übergeordneten Domain, solange sie keinen eigenen Eintrag haben.

• Zwei SPF-Einträge für dieselbe Domain, etwa nach einem Providerwechsel. Die SPF-Prüfung schlägt dann fehl.
• Mehr als 10 DNS-Abfragen im SPF-Eintrag durch zu viele „include:“-Angaben.
• Nur ein DKIM-CNAME angelegt. Microsoft 365 braucht beide Selektoren, sonst scheitert die spätere Schlüsselrotation.
• TXT- statt CNAME-Eintrag für DKIM. In Microsoft 365 sind immer CNAME-Einträge nötig.
• Doppelter Domainname im Hostnamen, weil der DNS-Anbieter die Domain automatisch anhängt. Tragen Sie nur „selector1._domainkey“ ein.
• Aktiver Proxy bei Cloudflare. Für die DKIM-Einträge muss die Einstellung „DNS only“ gewählt sein.
• Externe Versanddienste mit der Hauptdomain. Microsoft empfiehlt für Newsletter und andere Dienste, die Sie nicht selbst kontrollieren, eine eigene Subdomain, zum Beispiel „newsletter.ihre-domain.de“, mit eigenem SPF und DKIM.
• Weiterleitungen und Verteilerlisten, die Mails verändern und dadurch DMARC brechen. Für eingehende Mails lässt sich ein solcher Dienst in Microsoft 365 als vertrauenswürdiger ARC-Versiegler (Trusted ARC sealer) eintragen.

Senden Sie eine Testmail aus Exchange Online an ein externes Postfach, etwa bei Outlook.com, und öffnen Sie die Kopfzeilen der Nachricht. Im Feld „Authentication-Results“ sollten „spf=pass“, „dkim=pass“ und „dmarc=pass“ stehen. Im Feld „DKIM-Signature“ muss der Wert „d=“ Ihre eigene Domain enthalten, nicht die Domain auf onmicrosoft.com. Ob die DNS-Einträge öffentlich sichtbar sind, prüfen Sie mit „nslookup“ oder „dig“.

1. Alle Domains im Tenant auflisten, auch nicht genutzte Domains und die Domain auf onmicrosoft.com.
2. Für jede Domain prüfen, ob genau ein gültiger SPF-Eintrag existiert.
3. DKIM für jede eigene Domain aktivieren, über die Mails versendet werden.
4. Für jede Domain einen DMARC-Eintrag anlegen, für genutzte Domains zunächst mit p=none und Berichtsadresse, für ungenutzte mit p=reject.
5. Externe Versanddienste wie Newsletter-, ERP- und Shopsysteme ermitteln und in SPF und DKIM aufnehmen.
6. Unzustellbarkeitsnachrichten mit „550 5.7.1“ oder „550 5.7.515“ ernst nehmen und die Absenderdomain prüfen.
7. Die DMARC-Berichte auswerten und die Richtlinie schrittweise bis p=reject verschärfen.

Als Microsoft Solutions Partner für Security richtet die InSys AG^® SPF, DKIM und DMARC für Ihre Domains in Microsoft 365 und Exchange Online ein, nimmt externe Versanddienste auf und begleitet die Umstellung bis p=reject. Mit dem Microsoft Tenant Sicherheitscheck erhalten Sie einen Überblick über die Sicherheitseinstellungen Ihres Tenants. Dauerhaft betreuen wir Ihre Umgebung im Microsoft Secure Score Managed Service. Für den Schutz vor Phishing und gefälschten Absendern ergänzt Microsoft Defender XDR die E-Mail-Authentifizierung. Weitere Maßnahmen finden Sie in unserem Leitfaden zur Microsoft 365 Sicherheit und in der Übersicht unserer Microsoft 365 Beratung.

Sprechen Sie uns an: telefonisch unter +49 (521) 260105-0 oder über das Kontaktformular unten.