Mit SPF, DKIM und DMARC stellst du sicher, dass E-Mails aus deiner Exchange-Online-Domäne von empfangenden Mailservern als echt erkannt werden und Fälschungen abgewiesen oder in Quarantäne verschoben werden. Diese Anleitung richtet sich an Admins im Mittelstand, die eine reine Microsoft-365-Domäne betreiben. Du legst die DNS-Records beim DNS-Anbieter deiner Domäne an, aktivierst DKIM im Defender admin center und schaltest DMARC kontrolliert von Monitoring auf Enforcement. Das Ergebnis: höhere Zustellbarkeit und deutlich weniger Spoofing in deinem Namen.

Voraussetzungen

Eine in Microsoft 365 verifizierte eigene Domäne (z. B. deine-domaene.de), die per Exchange Online verschickt.
Adminzugriff: Rolle Global Administrator oder Security Administrator bzw. die passende Exchange-Online-Rolle für DKIM.
Zugang zur DNS-Verwaltung deines DNS-Anbieters (Registrar oder gehosteter DNS), um TXT- und CNAME-Records anzulegen.
Optional die Exchange Online PowerShell (Modul ExchangeOnlineManagement) für DKIM-Cmdlets und Rotation.
Eine Postfach- oder Verteileradresse für DMARC-Reports (z. B. reports@deine-domaene.de).

Kosten entstehen für die Konfiguration selbst keine; vorausgesetzt wird eine bestehende Microsoft-365-Lizenz mit Exchange Online.

Schritt 1: SPF-Record als TXT anlegen

SPF legt fest, welche Server im Namen deiner Domäne senden dürfen. Für eine reine Exchange-Online-Domäne reicht ein einziger TXT-Record mit dem Microsoft-Include. Wichtig: Pro Domäne darf es nur einen SPF-Record geben.

Lege beim DNS-Anbieter einen TXT-Record an. Hostname ist die Wurzel der Domäne (häufig @ oder der Domänenname selbst), der Wert lautet:

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

Das abschließende -all ist ein Hard Fail: Quellen, die nicht abgedeckt sind, gelten als nicht autorisiert. Das ist die empfohlene Einstellung, sobald DKIM und DMARC ebenfalls aktiv sind. Während einer Testphase kannst du übergangsweise ~all (Soft Fail) nutzen, solltest aber zügig auf -all wechseln.

Government-Clouds nutzen abweichende Includes: spf.protection.office365.us für GCC High/DoD und spf.protection.partner.outlook.cn für die China-Cloud. Für die Standard-Commercial-Cloud bleibt es bei spf.protection.outlook.com.

SPF-Lookup-Limit beachten

SPF erlaubt maximal 10 DNS-Lookups. Dabei zählen include:, a, mx, exists und redirect; ip4/ip6 zählen nicht. Allein include:spf.protection.outlook.com verbraucht 2 bis 3 Lookups. Bindest du weitere Dienste ein, kann das Limit reißen und Nachrichten werden mit einem Permanent Error abgewiesen.

Schritt 2: DKIM-Schlüssel und CNAME-Werte ermitteln

DKIM signiert ausgehende E-Mails kryptografisch. Exchange Online nutzt zwei Selektoren (selector1, selector2), deren öffentliche Schlüssel über zwei CNAME-Records auf deine onmicrosoft.com-Domäne verweisen. Die exakten Zielwerte gibt dir Microsoft vor.

Per Exchange Online PowerShell liest du die benötigten CNAME-Ziele aus:

Connect-ExchangeOnline
Get-DkimSigningConfig -Identity deine-domaene.de | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Existiert für die Domäne noch keine DKIM-Konfiguration, erstellst du sie direkt mit 2048-Bit-Schlüssel:

New-DkimSigningConfig -DomainName deine-domaene.de -KeySize 2048 -Enabled $true

Alternativ im Portal: Defender admin center → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → Tab DKIM → Domäne wählen → Create DKIM keys. Dort werden dir die beiden CNAME-Werte angezeigt.

Schritt 3: DKIM-CNAME-Records beim DNS-Anbieter eintragen

Lege nun beim DNS-Anbieter zwei CNAME-Records an. Der Hostname-Teil ist selector1._domainkey bzw. selector2._domainkey, das Ziel ist der von Microsoft gelieferte Wert auf deiner onmicrosoft.com-Domäne. Schema:

Host:  selector1._domainkey
Typ:   CNAME
Ziel:  selector1-deine-domaene-de._domainkey.deine-domaene.onmicrosoft.com

Host:  selector2._domainkey
Typ:   CNAME
Ziel:  selector2-deine-domaene-de._domainkey.deine-domaene.onmicrosoft.com

Kopiere die Zielwerte exakt aus PowerShell oder dem Portal; der Partitionsteil im Selektor (z. B. ein Suffix wie -3456) muss unverändert übernommen werden. Manche DNS-Oberflächen erwarten beim Host nur selector1._domainkey ohne angehängte Domäne und ergänzen die Domäne automatisch.

Schritt 4: DKIM aktivieren

Erst nachdem beide CNAMEs im DNS sichtbar sind, schaltest du die Signierung scharf. Per PowerShell:

Enable-DkimSigningConfig -Identity deine-domaene.de

Im Portal aktivierst du im selben DKIM-Tab den Schalter Enable DKIM für die Domäne. Nach dem Eintragen der CNAMEs kann die vollständige Aktivierung bis zu 48 Stunden dauern, weil die DNS-Propagation abgeschlossen sein muss. Prüfe die Sichtbarkeit der Records, z. B.:

nslookup -type=cname selector1._domainkey.deine-domaene.de

Schritt 5: DMARC im Monitoring-Modus starten

DMARC verknüpft SPF und DKIM mit einer Richtlinie und liefert dir Reports. Starte bewusst mit p=none: Es ändert nichts an der Zustellung, du sammelst aber Daten darüber, welche Quellen in deinem Namen senden. Lege einen TXT-Record mit Hostname _dmarc an:

Host:  _dmarc
Typ:   TXT
Wert:  v=DMARC1; p=none; pct=100; rua=mailto:reports@deine-domaene.de; ruf=mailto:reports@deine-domaene.de

Über rua erhältst du aggregierte Reports, über ruf forensische Einzelmeldungen. Plane für diese Phase rund 90 Tage ein, damit du auch seltene Sendequellen erkennst, bevor du verschärfst.

Alignment verstehen

DMARC verlangt, dass die Domäne im sichtbaren From-Header mit der SPF- bzw. DKIM-geprüften Domäne zusammenpasst (Alignment). Die Modi aspf und adkim stehen auf r (relaxed, Standard, erlaubt Subdomains) oder s (strict, exakter FQDN-Treffer). Für den Start ist relaxed sinnvoll. Eine Nachricht besteht DMARC, wenn entweder SPF oder DKIM bestanden hat und die jeweilige Domäne ausgerichtet ist; ein einzelnes Pass ohne Alignment reicht nicht.

Beachte außerdem, dass bei einer aktiven Richtlinie p=quarantine oder p=reject DMARC-Fehlschläge automatisch in den High-Risk Delivery Pool geleitet werden. Genau deshalb lohnt sich die ausgiebige Monitoring-Phase mit p=none, bevor du verschärfst.

Schritt 6: DMARC stufenweise verschärfen

Wenn die Reports zeigen, dass alle legitimen Quellen sauber über SPF und DKIM ausgerichtet sind, ziehst du die Richtlinie an. Phase 2 verschiebt verdächtige Nachrichten in die Quarantäne:

v=DMARC1; p=quarantine; pct=100; rua=mailto:reports@deine-domaene.de; ruf=mailto:reports@deine-domaene.de

Nach einer weiteren Beobachtungsphase ohne Fehlalarme setzt du die finale Stufe und weist Fälschungen vollständig ab:

v=DMARC1; p=reject; pct=100; rua=mailto:reports@deine-domaene.de; ruf=mailto:reports@deine-domaene.de

Subdomains erben die Richtlinie der übergeordneten Domäne automatisch; mit einem eigenen _dmarc-Record auf der Subdomain oder dem Tag sp= kannst du das gezielt überschreiben.

Schritt 7: DKIM-Schlüssel rotieren und Status prüfen

Microsoft empfiehlt 2048-Bit-Schlüssel. Bestehende 1024-Bit-Konfigurationen hebst du per Rotation an. Dabei wird zunächst nur ein Selektor erneuert; der zweite folgt nach rund vier Tagen automatisch, damit unterwegs befindliche E-Mails weiterhin verifizierbar bleiben.

Rotate-DkimSigningConfig -Identity deine-domaene.de -KeySize 2048

Den aktuellen Zustand kontrollierst du jederzeit über Get-DkimSigningConfig. Achte auf Enabled und Status: Erst wenn beide Selektoren aktiv und im DNS aufgelöst werden, signiert Exchange Online zuverlässig.

Troubleshooting

Problem: Mehrere SPF-Records. Pro Domäne ist nur ein SPF-TXT-Record erlaubt. Zwei oder mehr führen zu einem Permanent Error und Ablehnungen. Konsolidiere alle Quellen in genau einem Record.
Problem: SPF-Lookup-Limit überschritten. Zu viele include:-Einträge sprengen das 10-Lookup-Limit (Meldung sinngemäß zu viele Lookups). Lagere Drittdienste auf eine Subdomain mit eigenem SPF aus, fasse Dienste zusammen oder ersetze Includes durch konkrete IP-Bereiche.
Problem: SPF-Syntaxfehler. Häufige Ursachen sind ein Punkt hinter der Domäne (include:spf.protection.outlook.com.), ein Gleichheitszeichen statt Doppelpunkt (include=) oder ein Leerzeichen nach dem Doppelpunkt (include: spf...). Schreibe den Wert exakt ohne diese Fehler.
Problem: DKIM nach 48 Stunden nicht aktiv. Der CNAME ist noch nicht vollständig propagiert. Prüfe mit nslookup selector1._domainkey.deine-domaene.de, ob der Record sichtbar ist, und kontrolliere, dass der Zielwert exakt übernommen wurde.
Problem: DMARC schlägt fehl, obwohl SPF/DKIM einzeln passen. Das ist meist ein Alignment-Fehler: Die Domäne in MAIL FROM oder im DKIM-Schlüssel weicht von der Domäne im From-Header ab. Typisch bei Drittdiensten, die mit eigener Domäne senden oder signieren.
Problem: Cross-Domain-Reports kommen nicht an. Zeigen rua/ruf auf eine andere Domäne, braucht diese einen Autorisierungs-Record der Form deine-domaene.de._report._dmarc als TXT mit v=DMARC1; auf der Empfängerdomäne.

Häufige Fragen

Sollte ich SPF mit -all oder ~all betreiben?

Für eine reine Exchange-Online-Domäne ist -all (Hard Fail) die empfohlene Endeinstellung, sobald DKIM und DMARC laufen. ~all (Soft Fail) ist nur für eine kurze Testphase gedacht und sollte nicht dauerhaft bleiben.

Warum zwei DKIM-Selektoren?

Exchange Online nutzt selector1 und selector2 parallel, damit ein Schlüssel rotiert werden kann, während der andere weiter gültig bleibt. So entsteht beim Schlüsselwechsel keine Lücke in der Signierung.

Wie lange dauert es, bis die Records greifen?

SPF und DMARC sind im Rahmen der DNS-TTL praktisch sofort wirksam. DKIM kann bis zu 48 Stunden bis zur vollständigen Aktivierung brauchen. Als TTL für die Records ist mindestens 3600 Sekunden sinnvoll.

Kann ich SPF und DMARC per PowerShell verwalten?

Nein. Für eigene Domänen werden SPF- und DMARC-Records ausschließlich beim DNS-Anbieter gepflegt. Nur DKIM lässt sich teilweise über Exchange Online PowerShell steuern (Get-, New-, Enable-, Rotate-DkimSigningConfig).

Binde sie nicht in den SPF der Hauptdomäne ein, sondern nutze eine eigene Subdomain (z. B. marketing.deine-domaene.de) mit eigenem SPF-Record und lass den Dienst mit dieser Subdomäne DKIM-signieren. Das schont das Lookup-Limit und erhält das DMARC-Alignment.

Was ist mit der onmicrosoft.com-Domäne?

Auch die onmicrosoft.com-Domäne lässt sich mit DMARC schützen. Den TXT-Record legst du dafür im Microsoft 365 admin center unter Einstellungen → Domänen → Domäne wählen → DNS-Einträge als Custom DNS record mit Name _dmarc an.

Fazit

Mit einem einzigen sauberen SPF-Record, zwei DKIM-CNAMEs und einem stufenweise verschärften DMARC-Record sicherst du den E-Mail-Versand deiner Exchange-Online-Domäne wirksam ab. Der Schlüssel liegt in der Reihenfolge: erst SPF und DKIM korrekt eintragen und verifizieren, dann DMARC mit p=none beobachten und kontrolliert über quarantine bis reject nachziehen. So gewinnst du Zustellbarkeit, ohne legitime Mails zu blockieren.

Weiterführende Anleitungen und Quellen

Passend dazu aus unseren Anleitungen:

Phishing-Schutz in Microsoft Defender for Office 365 einrichten
Microsoft 365: MFA und Conditional Access in Entra ID konfigurieren
Mailcow: eigener Mailserver mit Docker – die Selfhosting-Alternative, wenn du E-Mail nicht über Microsoft 365 betreiben willst
Weitere Anleitungen in der Kategorie E-Mail

Quellen: Microsoft-Learn-Dokumentation zu SPF, DKIM und DMARC für Microsoft 365 sowie zur PowerShell-Referenz Rotate-DkimSigningConfig.