SPF für Microsoft 365 richtig einrichten

Der Basis-Record

Wenn ausschließlich Exchange Online für die Domain versendet, besteht der SPF-Record aus einem einzigen include. spf.protection.outlook.com deckt alle Microsoft-Ausgangsserver ab, Microsoft pflegt die Adressen dahinter selbst. Der Record wird als TXT-Record auf dem Apex der Domain veröffentlicht, also auf beispiel.de und nicht auf einer Subdomain.

Microsoft selbst schlägt in der Admin-Konsole diesen Record vor. Achte darauf, dass er ohne Anführungszeichen im Panel eingetragen wird, falls dein DNS-Anbieter die Quotes selbst setzt.

beispiel.de.  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

Weitere Absender kombinieren

Kaum ein Kunde sendet nur über Exchange Online. Newsletter-Tool, CRM, Ticketsystem, Webshop und die Website selbst versenden ebenfalls im Namen der Domain. Alle diese Dienste kommen in denselben Record, denn eine Domain darf nur einen SPF-Record haben. Das include von Microsoft kostet zwei DNS-Lookups, es bleiben also acht für den Rest.

Der Webserver ist ein typischer Fall, den man vergisst: Kontaktformulare und Shop-Bestellbestätigungen gehen oft direkt vom Server raus. Trage dessen feste IP-Adresse per ip4 ein oder stelle das System auf SMTP-Versand über einen Dienst mit include um.

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:203.0.113.25 -all

Fehler 1: Der alte Record ist noch da

Beim Umzug von einem Hoster zu Microsoft 365 wird oft ein neuer TXT-Record angelegt, statt den vorhandenen zu ersetzen. Zwei Records mit v=spf1 sind laut RFC 7208 ein permerror, und der Empfänger behandelt die Domain wie ohne SPF. Der SPF Checker zeigt dir sofort, ob mehr als ein Record existiert.

Prüfe nach jedem Umzug alle TXT-Records am Apex und lösche den alten. Falls der alte Hoster noch für einzelne Systeme sendet, gehört sein include in den neuen Record, nicht in einen zweiten.

Fehler 2: ~all für immer

Viele Anleitungen empfehlen ~all (softfail) als Einstieg, damit während der Umstellung nichts verloren geht. Das ist sinnvoll, aber nur als Zwischenschritt. Bleibt das ~all stehen, wird gefälschten Mails lediglich ein leichtes Spam-Signal angehängt, und der Schutzeffekt ist gering.

Sobald die DMARC-Reports einige Wochen lang zeigen, dass alle legitimen Absender im Record stehen, stellst du auf -all um. In Kombination mit DMARC p=reject ist -all die Konfiguration, mit der eine Domain wirklich gegen Spoofing geschützt ist.

Fehler 3: Drucker, Scanner und Relays vergessen

Der Klassiker nach einer Migration: Der Multifunktionsdrucker im Büro schickt Scans per Mail, das Warenwirtschaftssystem verschickt Rechnungen, die USV meldet Stromausfälle. Diese Geräte haben zwei Wege in Microsoft 365. Beim SMTP-AUTH-Versand über smtp.office365.com mit einem Postfach-Login gehen die Mails über Exchange Online raus und sind durch das include abgedeckt.

Beim sogenannten Direct Send liefert das Gerät direkt am MX-Endpunkt des Tenants ein, ohne Anmeldung. Die Mail kommt dann von der öffentlichen IP des Kundenstandorts, und genau diese IP muss per ip4 im SPF stehen, sonst gibt es fail. Frag den Kunden gezielt nach solchen Geräten, denn in der DMARC-Auswertung tauchen sie als anonyme Quellen mit wenigen Mails pro Woche auf.

v=spf1 include:spf.protection.outlook.com ip4:198.51.100.14 -all

198.51.100.14 ist die feste öffentliche IP des Bürostandorts, von der Drucker und Warenwirtschaft per Direct Send einliefern.

Hybrid und On-Premises-Relays

In Hybrid-Umgebungen sendet ein Teil der Postfächer weiterhin über den lokalen Exchange-Server, oder ein Smarthost im Rechenzentrum leitet Mails der Fachanwendungen nach außen. Jeder dieser Server, der direkt an fremde Empfänger zustellt, braucht seine öffentliche IP im SPF-Record. Sendet er dagegen ausschließlich über den Outbound-Connector an Exchange Online, ist das include ausreichend.

Dokumentiere die IPs im Record mit einem kurzen Kommentar im Ticketsystem des Kunden. In zwei Jahren weiß sonst niemand mehr, wofür 203.0.113.40 gut war, und beim nächsten Aufräumen fliegt sie raus.

DKIM und DMARC ergänzen

SPF allein reicht nicht, weil es bei Weiterleitungen bricht und weil DMARC-Alignment bei vielen Diensten nur über DKIM erreichbar ist. Microsoft 365 signiert mit zwei Selektoren, selector1 und selector2, die du als CNAME-Records auf den Tenant zeigen lässt. Danach aktivierst du DKIM für die Domain im Defender-Portal.

Der Zielhostname folgt dem Muster selector1-<domain-mit-bindestrichen>._domainkey.<tenant>.onmicrosoft.com. Das Portal zeigt den exakten Wert an, kopiere ihn und tippe ihn nicht ab. Danach kommt der DMARC-Record, zuerst mit p=none und einer rua-Adresse, damit du Reports bekommst.

selector1._domainkey.beispiel.de.  CNAME  selector1-beispiel-de._domainkey.kundetenant.onmicrosoft.com.
selector2._domainkey.beispiel.de.  CNAME  selector2-beispiel-de._domainkey.kundetenant.onmicrosoft.com.
_dmarc.beispiel.de.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de"

Wie Exchange Online SPF-Fehler eingehender Mails behandelt

Auf der Empfangsseite wertet Exchange Online Protection SPF, DKIM und DMARC aus und fasst das Ergebnis im Header Authentication-Results zusammen, ergänzt um eine eigene Bewertung (compauth). Ein SPF-fail allein führt nicht automatisch in den Spam-Ordner, die Entscheidung hängt von DMARC-Policy, Anti-Phishing-Richtlinie und weiteren Signalen ab. In der Anti-Spam-Richtlinie gibt es zusätzlich eine Option, SPF-Hardfail gesondert zu markieren.

Für dich als Betreuer der Absenderdomain heißt das: Der Header Authentication-Results in einer Testmail an ein Microsoft-Postfach ist die verlässlichste Quelle dafür, ob dein Setup funktioniert. Dort stehen spf=pass, dkim=pass und dmarc=pass, oder eben nicht.

Häufige Fragen

Muss ich den SPF-Record auch für die onmicrosoft.com-Domain pflegen?

Nein. Die Tenant-Domain gehört Microsoft, der SPF-Record dort ist vorkonfiguriert. Du kümmerst dich nur um die eigenen Domains, die du im Tenant hinzugefügt hast.

Reicht das include, wenn wir Exchange Online über einen Drittanbieter-Filter senden?

Nicht unbedingt. Wenn ausgehende Mails über einen Security-Gateway wie Proofpoint oder Mimecast laufen, sehen Empfänger dessen IP-Adressen. Dann muss das include des Gateways in den Record, das Microsoft-include kannst du oft trotzdem behalten, falls einzelne Systemmails direkt rausgehen.

Was ist mit Mails aus Power Automate oder SharePoint?

Benachrichtigungen aus Microsoft-Diensten kommen meist von Microsoft-eigenen Domains und nicht von deiner Domain. Nur wenn du Flows mit dem Konnektor "Office 365 Outlook" aus einem Postfach der Domain sendest, laufen sie über Exchange Online und sind durch das include abgedeckt.