DMARC, DKIM & SPF in Microsoft 365 einrichten: Der Praxis-Guide

Spätestens seit Google und Yahoo 2024 ihre Anforderungen an Absender verschärft haben — und Microsoft 2025 für Outlook.com nachzog —, ist E-Mail-Authentifizierung keine Kür mehr, sondern Pflicht: Wer SPF, DKIM und DMARC nicht sauber konfiguriert hat, landet zunehmend im Spam — oder wird gar nicht erst zugestellt. Gleichzeitig ist eine fehlende oder halb fertige DMARC-Policy die offene Tür, durch die Angreifer Deine Domain für Phishing und Rechnungsbetrug missbrauchen.

Die gute Nachricht: In Microsoft 365 lassen sich alle drei Standards mit überschaubarem Aufwand einrichten. Die schlechte: Die meisten Tenants bleiben auf halbem Weg stehen — DKIM nicht aktiviert, DMARC auf p=none, der SPF-Eintrag mit zu vielen Lookups. In diesem Guide zeige ich Dir, wie Du DMARC in Microsoft 365 einrichtest, wie SPF und DKIM dafür die Grundlage legen und wie Du Schritt für Schritt bis zur scharfen p=reject-Policy kommst, ohne Deinen legitimen Mailversand abzuschießen. Das ergänzt die 7 wichtigen Schritte für Exchange-Online-Sicherheit um die Authentifizierungsschicht.

Alles Wichtige auf einen Blick

Was SPF, DKIM und DMARC unterscheidet

SPF, DKIM und DMARC sind drei aufeinander aufbauende E-Mail-Authentifizierungsstandards: SPF legt fest, welche Server für eine Domain senden dürfen, DKIM signiert Nachrichten kryptografisch, und DMARC bestimmt, was ein empfangender Server mit Mails tun soll, die SPF oder DKIM nicht bestehen. Alle drei werden als DNS-Einträge Deiner Domain veröffentlicht — empfangende Mailserver lesen sie aus und entscheiden anhand der Regeln über die Echtheit einer Nachricht.

Der entscheidende Punkt: Die drei greifen ineinander, und keiner funktioniert allein vollständig. SPF bricht, sobald eine Mail weitergeleitet wird. DKIM überlebt Weiterleitungen, sagt aber nichts darüber aus, was bei einem Fehlschlag passieren soll. Erst DMARC verbindet beide über den sogenannten Alignment — den Abgleich, ob die im SPF/DKIM geprüfte Domain zur sichtbaren Absenderadresse passt — und gibt dem empfangenden Server eine klare Handlungsanweisung. Ohne DMARC sind SPF und DKIM zahnlos: Sie prüfen, aber niemand zieht Konsequenzen.

Für die Praxis heißt das: Du richtest sie in genau dieser Reihenfolge ein. SPF und DKIM müssen sauber stehen und „alignen", bevor DMARC auf Durchsetzung gehen darf — sonst blockierst Du Deine eigenen legitimen Mails.

SPF-Record in Microsoft 365 konfigurieren

SPF (Sender Policy Framework) ist der einfachste der drei Standards und meist schon teilweise vorhanden. Er ist die erste Schicht der Mailversand-Absicherung — wie sie in Exchange Online Protection insgesamt zusammenspielt, zeigt der verlinkte Beitrag. Du veröffentlichst genau einen SPF-Eintrag als DNS-TXT-Record auf Deiner Domain. Für eine reine Microsoft-365-Domain sieht er so aus:

Versendest Du zusätzlich über andere Dienste — etwa ein Newsletter-Tool, ein CRM oder einen Drucker-Relay —, musst Du deren include mit aufnehmen, zum Beispiel:

Drei Dinge sind hier entscheidend. Erstens: Es darf nur einen einzigen SPF-Record pro Domain geben — zwei TXT-Einträge mit v=spf1 machen SPF ungültig. Zweitens: Schließe den Eintrag mit -all (hard fail) ab, nicht mit ~all (soft fail); nur -all weist nicht autorisierte Sender wirklich zurück. Drittens: SPF erlaubt maximal zehn DNS-Lookups. Jedes include zählt — wer zu viele Dienste verkettet, überschreitet das Limit, und SPF schlägt mit einem permerror fehl. Halte die Liste schlank und prüfe sie regelmäßig.

Die offizielle Anleitung steht unter SPF für Microsoft 365 konfigurieren.

DKIM in Microsoft 365 aktivieren

DKIM (DomainKeys Identified Mail) versieht jede ausgehende Mail mit einer kryptografischen Signatur, die der empfangende Server gegen einen öffentlichen Schlüssel in Deinem DNS prüft. Anders als SPF überlebt DKIM auch Weiterleitungen — deshalb ist es die robustere Säule für DMARC-Alignment.

Für Deine onmicrosoft.com-Domain signiert Microsoft 365 bereits automatisch. Für jede eigene (Custom-)Domain musst Du DKIM aktiv einschalten. Der Ablauf:

Wichtig: Microsoft hat das Zielformat umgestellt (neu auf dkim.mail.microsoft mit Partitions-Zeichen <X>, Domain-Teil mit Bindestrichen statt Punkten). Konstruiere die Werte nicht selbst — übernimm die im Portal angezeigten Ziele exakt 1:1, sonst wird die Konfiguration ungültig. Altes und neues Format dürfen für denselben Selector nicht gemischt werden.

Aktiviere DKIM für jede sendende Domain. Und denk an Deine Parked-Domains (Domains, die gar keine Mails verschicken sollen): Auch für die gehört eine restriktive Authentifizierung ins DNS, damit niemand sie für Spoofing missbraucht. Die Details beschreibt Microsoft unter DKIM für Microsoft 365 konfigurieren.

DMARC in Microsoft 365 einrichten und scharfschalten

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist eine DNS-Policy, die empfangenden Servern vorgibt, was mit Mails geschehen soll, die SPF und DKIM nicht bestehen — und die über Reports sichtbar macht, wer in Deinem Namen sendet. Es ist die Schicht, die SPF und DKIM erst durchsetzt, und genau das Stück, an dem die meisten Tenants scheitern. Du legst DMARC als einen DNS-TXT-Eintrag auf dem Host _dmarc.deinedomain.de an. Der entscheidende Parameter ist p — die Policy, was mit nicht authentifizierten Mails passieren soll.

Der Fahrplan zur scharfen Policy läuft in drei Stufen, damit Du keine legitimen Mails verlierst:

Stufe 1 — Überwachen (p=none). Starte im reinen Beobachtungsmodus. Die Policy blockiert noch nichts, sammelt aber über die rua-Adresse Berichte darüber, wer in Deinem Namen sendet:

Lass diese Stufe zwei bis vier Wochen laufen und werte die Reports aus (siehe nächster Abschnitt). Ziel: Alle legitimen Sendequellen identifizieren und sauber über SPF/DKIM authentifizieren.

Stufe 2 — Quarantäne (p=quarantine). Sobald Deine legitimen Quellen sauber „alignen", stufst Du hoch. Nicht authentifizierte Mails landen jetzt im Spam. Mit pct rollst Du das schrittweise aus — erst für einen Teil des Verkehrs:

Steigere pct über die Wochen auf 100, während Du die Reports im Blick behältst.

Stufe 3 — Zurückweisen (p=reject). Das Ziel. Gefälschte Mails von Deiner Domain werden jetzt hart abgewiesen, bevor sie ein Postfach erreichen. Der Eintrag im Endzustand:

Die wichtigsten Felder: p=reject ist die Durchsetzung, rua die Adresse für die aggregierten Berichte, pct=100 wendet die Regel auf den gesamten Verkehr an, und adkim=s/aspf=s schalten den strengen Alignment-Modus scharf (exakter Domain-Abgleich statt nur Subdomain-Match). Erst mit p=reject schützt DMARC Deine Domain wirklich vor Missbrauch.

Zwei Praxis-Hinweise zu den Feldern: Der strenge Modus (s) ist die schärfste Stufe — wenn viele Drittsysteme über Subdomains oder eigene Bounce-Adressen in Deinem Namen senden, prüfe vorher in den Reports, ob der standardmäßige relaxed-Abgleich (r) Deine legitimen Quellen nicht ohnehin sauber abdeckt; sonst riskierst Du, eigene Sender abzuschießen. Und das pct-Tag gilt als Auslaufmodell: Der kommende DMARC-Standard ersetzt es, für den schrittweisen Rollout heute ist es aber weiterhin nutzbar.

Ein Hinweis speziell für Microsoft 365: Wie der Tenant eingehende Mails behandelt, die die DMARC-Prüfung des Absenders nicht bestehen, steuerst Du in der Anti-Phishing-Richtlinie in Defender for Office 365. Diese Durchsetzung ist standardmäßig aktiv — Microsoft ehrt bei direkt zugestellten Mails die p=quarantine- und p=reject-Policy des Absenders bereits ohne Zutun. Anpassen musst Du sie nur in Sonderfällen, etwa wenn ein vorgelagertes Gateway vor Exchange Online sitzt (dann greift die DMARC-Durchsetzung nur mit aktivierter erweiterter Filterung für Connectors). So wirkt DMARC in beide Richtungen: schützt Deine Domain nach außen und Deine Postfächer nach innen. Microsofts vollständige Anleitung steht unter DMARC für Microsoft 365 konfigurieren.

DMARC-Reports auswerten

DMARC ohne Report-Auswertung ist wie eine Alarmanlage, deren Meldungen niemand liest. Die rua-Adresse in Deinem Eintrag erhält von empfangenden Servern aggregierte XML-Berichte — wer hat in Deinem Namen gesendet, von welchen IPs, und ob SPF/DKIM bestanden haben.

Das Problem: Diese XML-Berichte sind im Rohformat unlesbar. In der Praxis nutzt Du einen DMARC-Auswertungsdienst, der die Reports einsammelt und in ein verständliches Dashboard übersetzt. So siehst Du auf einen Blick, welche legitimen Quellen noch nicht sauber authentifiziert sind — der entscheidende Schritt, bevor Du von p=none auf quarantine und reject hochstufst. Genau hier wird der kontrollierte Rollout möglich: Du stufst erst hoch, wenn die Reports zeigen, dass alle Deine echten Sender sauber durchlaufen.

Den Authentication-Results-Header einer einzelnen Mail kannst Du übrigens jederzeit selbst prüfen (in Outlook über „Nachrichtenoptionen → Internetkopfzeilen"). Steht dort dmarc=pass, hat die Kette gegriffen; ein dmarc=fail bei einer angeblich internen Adresse entlarvt Spoofing sofort. Wie sich diese Authentifizierung in den Schutz gegen E-Mail-Betrug einfügt, vertieft unser Guide zu CEO-Fraud und Business Email Compromise.

Häufige Fehler bei SPF, DKIM und DMARC

Aus realen Tenant-Analysen sehe ich immer wieder dieselben Stolperfallen:

Vermeidest Du diese Punkte, hast Du eine saubere, durchgesetzte Authentifizierung, die sowohl Deine Zustellbarkeit als auch Deine Reputation schützt. Wie gut Dein Tenant insgesamt aufgestellt ist, zeigt auch der Microsoft Secure Score.

Häufige Fragen zu DMARC in Microsoft 365

Brauche ich SPF, DKIM und DMARC alle drei?

Ja. Sie bauen aufeinander auf: SPF und DKIM liefern die Authentifizierungs-Signale, DMARC setzt sie durch und sorgt über das Alignment dafür, dass sie zusammenpassen. Nur alle drei zusammen schützen Deine Domain wirksam und erfüllen die Anforderungen großer Mailprovider an Absender.

Warum landen meine Mails trotz Microsoft 365 im Spam?

Häufigste Ursache ist eine unvollständige Authentifizierung — fehlendes DKIM für die Custom-Domain, ein fehlerhafter SPF-Eintrag oder eine nicht durchgesetzte DMARC-Policy. Seit 2024 verlangen Google, Yahoo und Microsoft von Massenversendern eine saubere SPF/DKIM/DMARC-Konfiguration; fehlt sie, sinkt die Zustellbarkeit spürbar.

Ist p=reject nicht zu riskant?

Nur, wenn Du ohne Vorbereitung scharfstellst. Mit der Stufenfolge none → quarantine → reject und einer Report-Auswertung dazwischen identifizierst Du alle legitimen Sendequellen, bevor Du blockierst. Richtig gemacht, verlierst Du keine legitime Mail — und genau p=reject ist das Ziel, das Deine Domain wirklich schützt.

Wie lange dauert die Einrichtung bis p=reject?

Rechne mit vier bis acht Wochen. SPF und DKIM sind an einem Tag eingerichtet, aber die kontrollierte DMARC-Hochstufung über die Report-Phasen braucht Zeit — gerade wenn viele Drittsysteme in Deinem Namen senden. Diese Zeit ist gut investiert: Sie verhindert, dass Du legitime Kommunikation abschießt.

Bereit, Deine Domain wirklich gegen Spoofing zu schützen?

Ich bin Aaron Siller, Microsoft MVP für Security und Gründer von siller.consulting. In meinen Projekten steht DMARC bei der Erstanalyse fast immer auf p=none oder fehlt ganz — die Domain ist damit offen für Missbrauch, und niemand hat es bemerkt. Die Einrichtung ist kein Hexenwerk, aber der kontrollierte Weg bis p=reject braucht Erfahrung, damit unterwegs keine legitime Mail verloren geht.

Unser Microsoft 365 Hardening Check prüft Deine E-Mail-Authentifizierung als Teil der Gesamtanalyse: SPF-Syntax und Lookups, DKIM-Status je Domain, DMARC-Policy und Alignment — und zeigt Dir konkret, wo Deine Domain noch fälschbar ist. Keine generische Checkliste, sondern eine Analyse Deines echten Tenants.

In einem persönlichen Workshop richten wir SPF, DKIM und DMARC gemeinsam ein und gehen den Weg bis zur scharfen p=reject-Policy. Hands-on, an Deinem System. Als Einstieg hol Dir vorab unsere Microsoft 365 Hardening-Checkliste. Melde Dich bei mir — bevor jemand anderes Deine Domain für seine Mails benutzt.