Microsoft 365: SPF, DKIM und DMARC richtig einrichten

@                    TXT    "v=spf1 include:spf.protection.outlook.com -all"
selector1._domainkey CNAME  selector1-beispiel-at._domainkey.beispiel.onmicrosoft.com.
selector2._domainkey CNAME  selector2-beispiel-at._domainkey.beispiel.onmicrosoft.com.
_dmarc               TXT    "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.at"

Das sind die vier Einträge, die eine eigene Domain beispiel.at in Microsoft 365 braucht, mit der Startdomain beispiel.onmicrosoft.com. Der SPF-Eintrag erlaubt den Servern von Exchange Online, für die Domain zu senden. Die zwei CNAME-Einträge zeigen auf die öffentlichen DKIM-Schlüssel, die Microsoft für die Domain erzeugt. Der DMARC-Eintrag sagt Empfängern, was mit Mails passieren soll, die beides nicht bestehen, und wohin die Berichte gehen.

Microsoft 365 signiert deine eigene Domain nicht von selbst. Die Dokumentation sagt es so: Für ausgehende Mail von eigenen Domains findet „currently, no DKIM signing“ statt, bis man DKIM für die Domain einschaltet. Das Häkchen bei der Domainüberprüfung im Admin Center, das nach MX und SPF fragt, ändert daran nichts. Automatisch signiert wird nur die Startdomain *.onmicrosoft.com, und die steht nicht im From: deiner Mails.

Wie die Einträge bei anderen Anbietern heißen und wo dort der Schalter sitzt, steht im Hoster-Vergleich zu DKIM, SPF und DMARC.

SPF: ein Eintrag, und warum Microsoft -all empfiehlt#

Für eine Domain, die nur über Exchange Online verschickt, empfiehlt Microsoft:

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

Verschickt zusätzlich ein eigener Server, kommen dessen Adressen als ip4: davor, ein Newsletter-Dienst als weiteres include:. Es bleibt ein einziger Eintrag. Zwei Einträge mit v=spf1 führen laut Microsoft zu permerror. Ein Microsoft-365-Portal für SPF gibt es nicht, der Eintrag wird beim DNS-Anbieter gesetzt.

Microsoft empfiehlt für eigene Domains -all statt ~all, mit einer Begründung, die für Empfänger mit Microsoft 365 gilt: DMARC wertet beides als Fehlschlag, aber bei ~all werde die DMARC-Richtlinie „effectively ignored“, wenn die Mail zusätzlich keine DKIM-Signatur trägt. Google empfiehlt für Workspace dagegen ~all (siehe unten). Beides funktioniert, sobald DKIM steht. Ohne DKIM ist -all die ehrlichere Wahl.

Zwei weitere Empfehlungen von Microsoft:

• Massenversand über eine Subdomain, etwa newsletter.beispiel.at. Sie braucht ihren eigenen SPF-Eintrag, und Probleme mit dem Dienst treffen nicht den Ruf der Hauptdomain.
• Domains ohne Mailverkehr bekommen v=spf1 -all, damit niemand mit ihnen Mails fälschen kann.

Wie man einen Eintrag gegen die Grenze von zehn DNS-Abfragen zählt, steht in SPF-Eintrag erstellen. Microsoft rät ausdrücklich davon ab, include:spf.protection.outlook.com durch IP-Adressen zu ersetzen, weil sich die Adressen von Exchange Online häufig ändern.

DKIM einschalten, Schritt für Schritt#

Der Weg dauert zehn Minuten plus Wartezeit. Im Portal sieht er so aus:

1. Im Defender-Portal unter security.microsoft.com zu Email & collaboration > Policies & rules > Threat policies > Email authentication settings gehen, Reiter DKIM.
2. In der Zeile der eigenen Domain den Schalter von Disabled auf Enabled schieben. Es öffnet sich ein Fenster „Client error“, das die benötigten Werte schon enthält. Mit OK schließen. Der Status der Domain steht danach auf CnameMissing.
3. Die Zeile der Domain anklicken, nicht den Schalter. Der Bereich, der sich öffnet, zeigt zwei CNAME-Einträge mit den Hostnamen selector1._domainkey und selector2._domainkey und je einem Ziel.
4. Beide Einträge beim DNS-Anbieter anlegen, als CNAME, genau mit diesen Zielen.
5. Warten. Laut Microsoft dauert es „a few minutes (or possibly longer)“, bis die Einträge erkannt werden.
6. Zurück im Bereich der Domain den Schalter Sign messages for this domain with DKIM signatures umlegen.

Die Hostnamen sind für alle Organisationen gleich, die Ziele nicht. Seit Mai 2025 gibt es für neu hinzugefügte Domains ein zweites Format:

selector1._domainkey CNAME selector1-beispiel-at._domainkey.beispiel.n-v1.dkim.mail.microsoft.

Ältere Domains behalten das Format mit onmicrosoft.com. Der Buchstabe vor -v1 ist laut Microsoft ein „dynamic partition character“ und unterscheidet sich von Mandant zu Mandant. Deshalb die Werte immer aus dem Portal kopieren, nie aus einer Anleitung.

Dasselbe in PowerShell, mit 2048 Bit#

In der Exchange-Online-PowerShell zeigt dieser Befehl den Stand aller Domains samt CNAME-Zielen:

Get-DkimSigningConfig | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Fehlt die eigene Domain dort, legt man die Konfiguration an:

New-DkimSigningConfig -DomainName beispiel.at -Enabled $false -KeySize 2048

Ohne -KeySize erzeugt Microsoft 1024-Bit-Schlüssel, das ist die Voreinstellung. Nach dem Anlegen der CNAME-Einträge schaltet Set-DkimSigningConfig -Identity beispiel.at -Enabled $true die Signatur ein. Einen bestehenden 1024-Bit-Schlüssel ersetzt man mit:

Rotate-DkimSigningConfig -Identity beispiel.at -KeySize 2048

Microsoft verwendet immer nur einen der beiden Selector, der andere springt erst bei der nächsten Rotation ein. Dass unter einem der zwei Namen gerade kein Schlüssel abrufbar ist, ist deshalb kein Fehler. Warum 1024 Bit heute zu kurz sind, steht in DKIM-Selector finden.

DMARC dazu#

Microsoft hat für den DMARC-Eintrag eigener Domains kein Portal, er kommt wie SPF zum DNS-Anbieter. Angefangen wird mit p=none und einer Berichtsadresse:

_dmarc  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.at"

Erst wenn die Berichte zeigen, dass jeder Versandweg besteht, geht es weiter auf quarantine und reject. Wie man den Zeitpunkt erkennt, steht in DMARC-Policy, den Eintrag selbst baut der DMARC-Generator. Für geparkte Domains ohne Mailverkehr empfiehlt Microsoft gleich v=DMARC1; p=reject;.

Nachprüfen#

Eine Mail an ein Gmail-Postfach schicken und dort Original anzeigen. Fertig ist es, wenn dort steht:

dkim=pass header.d=beispiel.at header.s=selector1
spf=pass smtp.mailfrom=beispiel.at
dmarc=pass (p=NONE) header.from=beispiel.at

Steht bei header.d= stattdessen beispiel.onmicrosoft.com, besteht DKIM zwar, passt aber nicht zur Absenderdomain. Microsoft nennt genau diesen Fall in der Fehlertabelle: „DKIM passes but DMARC still fails“, Ursache ist die Domain in d=. Von außen zeigt der E-Mail-Check, ob die vier Einträge stimmen. Kommt dabei ein Rückläufer statt einer Mail, hilft 550 5.4.1 und die anderen Microsoft-Codes beim Einordnen.

Anhang: Google Workspace#

Bei Google Workspace ist der Ablauf derselbe, nur heißen die Stellen anders:

• SPF: Google empfiehlt v=spf1 include:_spf.google.com ~all. Ein Eintrag darf laut Google bis zu zehn include: enthalten, mehr Abfragen erlaubt RFC 7208 auch insgesamt nicht.
• DKIM: In der Admin-Konsole unter Menü > Apps > Google Workspace > Gmail > E-Mail authentifizieren die Domain wählen und Neuen Eintrag generieren. Der Standard-Selector ist google, der TXT-Eintrag liegt also unter google._domainkey. Google bietet 2048 Bit an und 1024 Bit für DNS-Anbieter, die keine langen Einträge annehmen. Nach dem Eintragen Authentifizierung starten. Bis DKIM greift, kann es laut Google bis zu 48 Stunden dauern.
• DMARC: Google rät, nach SPF und DKIM 48 Stunden zu warten, bevor man DMARC veröffentlicht. Googles Beispiel enthält adkim=s; aspf=s, also strenge Ausrichtung. Wer Newsletter oder Rechnungen über eine Subdomain oder einen Dienst mit eigener Subdomain verschickt, lässt beide Tags weg. Dann gilt die lockere Ausrichtung, und news.beispiel.at passt zu beispiel.at.

Messung: Microsoft 365 bei 146 Tiroler Domains#

In eigener Sache: Am 05.10.2026 um 08:13 UTC habe ich die MX-, SPF-, DKIM- und DMARC-Einträge von 149 Tiroler Domains abgefragt, 34 Tourismusverbände und 115 Betriebe aus meiner Akquise-Liste, passiv per DNS-over-HTTPS. Drei gibt es nicht mehr, bleiben 146. 67 davon nehmen ihre Post bei Microsoft 365 an. Bei ihnen habe ich nachgesehen, wie viel von den vier Einträgen oben steht.

• SPF ist erledigt. 65 der 67 haben include:spf.protection.outlook.com im SPF-Eintrag, 54 enden auf -all, wie Microsoft es empfiehlt. Den Eintrag verlangt schon die Domainüberprüfung beim Einrichten.
• DKIM von Microsoft fehlt bei 38 der 67. Nur 29 veröffentlichen unter selector1 oder selector2 einen Schlüssel von Microsoft, 25 davon im alten Format mit onmicrosoft.com, 4 im neuen mit dkim.mail.microsoft. Ob die 29 den Schalter auch umgelegt haben, sieht man von außen nicht, der Schlüssel ist nur die Voraussetzung.
• DMARC fehlt bei 27, und nur 5 haben eine wirksame Richtlinie. 35 stehen auf p=none, 17 aller 67 haben eine Berichtsadresse.

Eine Domain steht auf p=reject, ohne dass ich einen DKIM-Schlüssel von Microsoft finde. Ihre Mails bestehen DMARC dann nur über SPF, und das scheitert bei jeder automatischen Weiterleitung. 16 weitere Domains erlauben Microsoft 365 im SPF-Eintrag, nehmen ihre Post aber über einen Filterdienst an. Bei Google Workspace ist es eine einzige Domain, ohne Schlüssel unter google. Namen veröffentliche ich nicht.

Was nicht hilft#

Die CNAME-Ziele aus einer Anleitung abschreiben. Das Präfix der Startdomain und der Buchstabe vor -v1 sind für jeden Mandanten anders.

include:spf.protection.outlook.com durch IP-Adressen ersetzen, um Abfragen zu sparen. Microsoft schreibt, dass sich die Adressen häufig ändern.

Mit der onmicrosoft.com-Adresse nach außen schreiben. Microsoft begrenzt sie auf 100 externe Empfänger in 24 Stunden, darüber kommt 5.7.236.

Häufige Fragen#

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Das Paket E-Mail-Schutz schaltet DKIM in Microsoft 365 mit 2048 Bit ein, bringt SPF auf einen Eintrag, setzt DMARC mit Berichtsadresse und stellt die Richtlinie anhand der Berichte um. Den Stand der Domain zeigt vorher kostenlos der E-Mail-Check.

Stand 05.10.2026. Quellen an diesem Tag abgerufen, DNS-Messung am 05.10.2026 um 08:13 UTC.