Mit SPF, DKIM und DMARC stellen Sie sicher, dass E-Mails aus Ihrer Exchange-Online-Domäne von empfangenden Mailservern als echt erkannt werden und Fälschungen abgewiesen oder in Quarantäne verschoben werden. Die Anleitung richtet sich an Admins im Mittelstand mit einer reinen Microsoft-365-Domäne. Sie legen die DNS-Records beim DNS-Anbieter an, aktivieren DKIM im Microsoft Defender-Portal und schalten DMARC kontrolliert von Monitoring auf Durchsetzung. DMARC-Records folgen RFC 9989 (Mai 2026), das RFC 7489 ablöst.

Voraussetzungen

Eine in Microsoft 365 verifizierte eigene Domäne (z. B. ihre-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 Ihres 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@ihre-domaene.de).

Vorausgesetzt wird eine Microsoft-365-Lizenz mit Exchange Online; weitere Lizenzen sind nicht nötig.

Schritt 1: SPF-Record als TXT anlegen

SPF legt fest, welche Server im Namen Ihrer 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.

Legen Sie 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. In einer kurzen Testphase ist ~all (Soft Fail) möglich; wechseln Sie danach auf -all.

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. Binden Sie weitere Dienste ein, kann das Limit reißen; Empfänger werten SPF dann als Permanent Error.

Verifizieren: nslookup -type=txt ihre-domaene.de liefert genau einen Eintrag, der mit v=spf1 beginnt und include:spf.protection.outlook.com enthält.

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 bei Microsoft liegen. Die exakten Zielwerte gibt Microsoft je Domäne vor.

Lesen Sie die CNAME-Ziele per Exchange Online PowerShell aus:

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

Existiert für die Domäne noch keine DKIM-Konfiguration, erstellen Sie sie zunächst deaktiviert mit 2048-Bit-Schlüssel; aktiviert wird erst nach dem DNS-Eintrag (Schritt 4):

New-DkimSigningConfig -DomainName ihre-domaene.de -KeySize 2048 -Enabled $false

Alternativ im Portal: Microsoft Defender-Portal (security.microsoft.com) → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → Tab DKIM → Domäne wählen → Create DKIM keys. Dort erscheinen die beiden CNAME-Werte.

Verifizieren: Get-DkimSigningConfig zeigt für die Domäne Werte in Selector1CNAME und Selector2CNAME, Status steht auf CnameMissing oder NoDKIMKeys.

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

Legen Sie beim DNS-Anbieter zwei CNAME-Records an. Der Hostname ist selector1._domainkey bzw. selector2._domainkey, das Ziel der von Microsoft gelieferte Wert. Schema für neu erstellte Schlüssel (ältere Konfigurationen zeigen noch auf …onmicrosoft.com):

Host:  selector1._domainkey
Typ:   CNAME
Ziel:  selector1-ihre-domaene-de._domainkey.<tenant>.<x>-v1.dkim.mail.microsoft

Host:  selector2._domainkey
Typ:   CNAME
Ziel:  selector2-ihre-domaene-de._domainkey.<tenant>.<x>-v1.dkim.mail.microsoft

Kopieren Sie die Zielwerte exakt aus PowerShell oder dem Portal; der dynamische Partitionsteil (<x>-v1, z. B. n-v1) 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.

Verifizieren: nslookup -type=cname selector1._domainkey.ihre-domaene.de und dasselbe für selector2 liefern exakt die Zielwerte aus Get-DkimSigningConfig.

Schritt 4: DKIM aktivieren

Sind beide CNAMEs im DNS sichtbar, schalten Sie die Signierung ein. Per PowerShell:

Enable-DkimSigningConfig -Identity ihre-domaene.de

Im Portal aktivieren Sie im selben DKIM-Tab den Schalter Sign messages for this domain with DKIM signatures. Ist die DNS-Propagation noch nicht abgeschlossen, meldet Microsoft einen Fehler; warten Sie dann einige Stunden (bis zu 48 Stunden).

Get-DkimSigningConfig -Identity ihre-domaene.de | Format-List Enabled,Status

Verifizieren: Die Ausgabe zeigt Enabled : True und Status : Valid. Im Header einer Test-E-Mail an ein externes Postfach steht dkim=pass header.d=ihre-domaene.de.

Schritt 5: DMARC im Monitoring-Modus starten

DMARC verknüpft SPF und DKIM mit einer Richtlinie und liefert Reports. Starten Sie mit p=none: Die Zustellung ändert sich nicht, Sie sehen aber, welche Quellen in Ihrem Namen senden. Legen Sie einen TXT-Record mit Hostname _dmarc an:

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

Über rua erhalten Sie aggregierte Reports. Einzelberichte über ruf sind optional und enthalten personenbezogene Daten aus den Nachrichten; viele große Anbieter versenden sie nicht. Das früher übliche pct=100 lassen Sie weg: RFC 9989 führt pct nur noch als historisches Tag. Planen Sie für diese Phase rund 90 Tage ein, um auch seltene Sendequellen zu erkennen.

Verifizieren: nslookup -type=txt _dmarc.ihre-domaene.de liefert genau einen Eintrag mit v=DMARC1; p=none; nach ein bis zwei Tagen treffen die ersten Aggregate-Reports im Report-Postfach ein.

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.

Ausgehende Nachrichten, die DMARC mit p=quarantine oder p=reject nicht bestehen, leitet Microsoft über den High-Risk Delivery Pool. Auch deshalb lohnt die Monitoring-Phase mit p=none.

Schritt 6: DMARC stufenweise verschärfen

Zeigen die Reports, dass alle legitimen Quellen über SPF oder DKIM ausgerichtet sind, verschärfen Sie die Richtlinie. RFC 9989 ersetzt die frühere schrittweise Erhöhung von pct durch den Testmodus t=y: Empfänger wenden dann die nächstniedrigere Stufe an, die Reports zeigen aber bereits die neue Richtlinie. Phase 2a:

v=DMARC1; p=quarantine; t=y; rua=mailto:reports@ihre-domaene.de

Bleiben die Reports unauffällig, entfernen Sie t=y (Phase 2b, Quarantäne greift):

v=DMARC1; p=quarantine; rua=mailto:reports@ihre-domaene.de

Nach einer weiteren Beobachtungsphase ohne Fehlalarme setzen Sie die finale Stufe. np=reject weist zusätzlich Mails von nicht existierenden Subdomains ab:

v=DMARC1; p=reject; np=reject; rua=mailto:reports@ihre-domaene.de

Subdomains erben die Richtlinie der übergeordneten Domäne automatisch; mit einem eigenen _dmarc-Record auf der Subdomain, dem Tag sp= (bestehende Subdomains) oder np= (nicht existierende Subdomains) überschreiben Sie das gezielt.

Verifizieren: nslookup -type=txt _dmarc.ihre-domaene.de zeigt die neue Richtlinie; im Header einer Test-E-Mail an ein externes Postfach steht dmarc=pass, und die Aggregate-Reports weisen keine legitime Quelle mit fail aus.

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

Microsoft empfiehlt 2048-Bit-Schlüssel. Bestehende 1024-Bit-Konfigurationen heben Sie per Rotation an. Der neue Schlüssel signiert erst nach vier Tagen (96 Stunden); bis dahin signiert der bisherige Selektor weiter, damit unterwegs befindliche E-Mails verifizierbar bleiben.

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

Verifizieren: Get-DkimSigningConfig -Identity ihre-domaene.de | Format-List Enabled,Status,Selector1KeySize,Selector2KeySize,RotateOnDate zeigt Enabled : True, Status : Valid, die Schlüssellänge 2048 und das Datum, ab dem der neue Schlüssel signiert.

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. Führen Sie alle Quellen in genau einem Record zusammen.
Problem: SPF-Lookup-Limit überschritten. Zu viele include:-Einträge sprengen das 10-Lookup-Limit (Meldung sinngemäß zu viele Lookups). Lagern Sie Drittdienste auf eine Subdomain mit eigenem SPF aus, fassen Sie Dienste zusammen oder ersetzen Sie 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...).
Problem: DKIM nach 48 Stunden nicht aktiv. Prüfen Sie mit nslookup -type=cname selector1._domainkey.ihre-domaene.de, ob der Record sichtbar ist und 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. Zeigt rua auf eine andere Domäne, braucht diese einen Autorisierungs-Record ihre-domaene.de._report._dmarc.empfaenger-domaene.de als TXT mit v=DMARC1;.

Häufige Fragen

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.

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 steuern Sie über Exchange Online PowerShell (Get-, New-, Enable-, Rotate-DkimSigningConfig).

Binden Sie sie nicht in den SPF der Hauptdomäne ein, sondern nutzen Sie eine eigene Subdomain (z. B. marketing.ihre-domaene.de) mit eigenem SPF-Record und lassen Sie den Dienst mit dieser Subdomain 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 legen Sie 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 SPF-Record, zwei DKIM-CNAMEs und einem stufenweise verschärften DMARC-Record sichern Sie den E-Mail-Versand Ihrer Exchange-Online-Domäne ab. Entscheidend ist die Reihenfolge: erst SPF und DKIM korrekt eintragen und verifizieren, dann DMARC mit p=none beobachten und kontrolliert über quarantine (mit t=y) bis reject nachziehen. So verbessern Sie die 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 ohne Microsoft 365
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; Microsoft Learn: DKIM konfigurieren; RFC 9989 (DMARC).