Stand: Juli 2026

Zusammenfassung: Nach dieser Anleitung publiziert deine Domain einen korrekten SPF-Record für Microsoft 365 — inklusive der Sonderfälle Hybrid-Setup, Newsletter-Subdomain und geparkte Domains.

Voraussetzungen

  • Ein Microsoft-365-Tenant mit eigener Domain
  • Zugriff auf die DNS-Verwaltung deiner Domain — die liegt nicht bei Microsoft, sondern bei deinem Domain-/DNS-Anbieter

Was ist SPF?

SPF (Sender Policy Framework) ist ein TXT-Record im DNS deiner Domain. Er listet auf, welche Mailserver E-Mails mit deiner Domain als Absender verschicken dürfen. Empfangende Server schlagen den Record bei jeder eingehenden Mail nach und prüfen, ob der einliefernde Server auf der Liste steht. Ohne SPF kann jeder beliebige Server Mails in deinem Namen verschicken — und deine legitimen Mails landen schneller im Spam.

Zur Einordnung: SPF allein ist noch kein vollständiger Schutz. Erst zusammen mit DKIM und DMARC wird daraus ein belastbares Fundament — Microsoft selbst empfiehlt ausdrücklich alle drei.

Die Ausgangslage bei Microsoft 365

Zwei Dinge unterscheiden Microsoft 365 von klassischen Hostern:

1. Es gibt keine SPF-Oberfläche in Microsoft 365. Microsofts Dokumentation sagt es klar: Der SPF-TXT-Eintrag wird bei der Domänenregistrierungsstelle angelegt — in Microsoft 365 selbst ist keine SPF-Konfiguration verfügbar. Du trägst den Record also dort ein, wo deine DNS-Zone liegt. Wie das dort jeweils geht, zeigen unsere Anleitungen für IONOS, Strato, All-Inkl und Netcup.

2. Microsoft empfiehlt -all (Hardfail). Während deutsche Hoster fast durchweg das mildere ~all vorgeben, empfiehlt Microsoft für 365-Domains ausdrücklich -all — mit der Begründung, dass DKIM und DMARC ohnehin dazugehören und DMARC bei ~all ohne DKIM-Signatur nicht greift.

Die einzige Ausnahme: Den SPF-Eintrag deiner *.onmicrosoft.com-Domain kannst du nicht ändern — der wird von Microsoft verwaltet.

Schritt-für-Schritt-Anleitung

1. Prüfen, ob SPF schon aktiv ist

Am schnellsten im Terminal:

dig TXT beispiel.de +short | grep spf1

Alternativ wirf deine Domain in den kostenlosen MXAudit-Scanner — der prüft den Record gleich auf Syntax und Lookup-Limit mit. Viele Domains haben bereits einen SPF-Record vom Hoster; der muss dann um Microsoft 365 ergänzt werden, nicht ersetzt.

2. Den richtigen Record wählen

Nur Microsoft 365 versendet (der Normalfall):

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

Die meisten Microsoft-365-Organisationen benötigen genau diesen include-Wert. Er verweist auf eine flache Liste von Microsoft-IP-Bereichen (IPv4 + IPv6) und kostet nur einen einzigen DNS-Lookup.

Hybrid-Setup mit lokalem Exchange/Mailserver: Ergänze die öffentliche IP deines Servers, Microsofts eigenes Beispiel:

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

Newsletter-/Massenversand über einen externen Dienst: Microsoft empfiehlt dafür eine eigene Subdomain (z. B. marketing.beispiel.de), damit der Ruf deiner Hauptdomain unberührt bleibt. Der Record der Subdomain (Microsofts Beispiel mit dem fiktiven Dienst Adatum):

v=spf1 include:servers.adatum.com include:spf.protection.outlook.com -all

Geparkte Domains, die nie senden: Verbiete den Versand komplett:

v=spf1 -all

3. Record beim DNS-Anbieter eintragen

Lege den gewählten Wert als TXT-Record auf der Hauptdomain (Host @) an — bei deinem Registrar oder DNS-Hoster, nicht im Microsoft-365-Admin-Center. Gibt es dort schon einen TXT-Eintrag mit v=spf1, bearbeite ihn und füge include:spf.protection.outlook.com hinzu — pro Domain ist nur ein SPF-Eintrag zulässig.

4. Subdomains bedenken

Laut Microsoft braucht jede definierte Subdomain einen eigenen SPF-Eintrag — der Record der Hauptdomain gilt nicht automatisch mit. Für nicht definierte Subdomains übernimmt DMARC den Schutz.

5. Warten, bis die Änderung aktiv ist

DNS-Änderungen brauchen Zeit: Je nach TTL und Caching kann es einige Stunden dauern, bis alle Server weltweit den neuen Record sehen.

Die Bestandteile im Detail

BestandteilBedeutung
v=spf1Versionskennung, steht immer am Anfang
include:spf.protection.outlook.comerlaubt die Microsoft-365-Versandinfrastruktur (flache IPv4/IPv6-Liste, 1 Lookup)
ip4: / ip6:erlaubt einzelne eigene Server (Hybrid-Szenario)
-allHardfail: nicht gelistete Server werden abgelehnt — Microsofts Empfehlung für 365-Domains

Sonderfälle für US-Behörden-Clouds: GCC High und DoD nutzen statt des Standard-Includes v=spf1 include:spf.protection.office365.us -all.

Ergebnis prüfen

Prüfe deine Konfiguration mit dem kostenlosen MXAudit-Scanner — er zeigt dir sofort, ob dein SPF-Record syntaktisch korrekt ist und wie viele DNS-Lookups er verbraucht (das Limit liegt bei 10).

Oder direkt im Terminal:

dig TXT beispiel.de +short | grep spf1

Die Ausgabe muss genau einen Record mit v=spf1 enthalten.

Häufige Fehler

Zweiten SPF-Record angelegt statt den bestehenden ergänzt. Wer den Microsoft-Record neben den vorhandenen Hoster-Record setzt, erzeugt permerror — empfangende Server werten SPF dann gar nicht mehr aus. Alle include-Werte gehören in einen einzigen Record.

Subdomains vergessen. Jede sendende Subdomain (Newsletter, Ticketsystem) braucht ihren eigenen SPF-Eintrag. Die Hauptdomain deckt sie nicht ab.

~all aus alter Gewohnheit. Bei Microsoft 365 spricht nichts für Softfail: Microsoft empfiehlt -all, gerade weil DKIM und DMARC dazukommen. Wer ~all behält, verschenkt Schutzwirkung.

+all am Ende. Ein +all erlaubt jedem Server das Senden und macht den gesamten Record wirkungslos — nicht übernehmen.

Weiterleitungen schlagen fehl. Leitet ein Empfänger deine Mail automatisch weiter, schlägt SPF beim Endempfänger oft fehl — der weiterleitende Server steht ja nicht in deinem Record. Das ist eine Designschwäche von SPF und kein Konfigurationsfehler; DKIM und DMARC fangen diesen Fall ab.