DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist ein Verfahren zur E-Mail-Authentifizierung, mit dem der Inhaber einer Domain festlegt, was Empfänger mit Mails tun sollen, die seine Domain als Absender tragen, aber weder durch SPF noch durch DKIM passend bestätigt sind. Die Vorgabe steht als TXT-Eintrag im DNS unter _dmarc.beispiel.de und regelt auch, wohin Empfänger Berichte senden.

Was ist DMARC?

Eine E-Mail hat zwei Absender: die Umschlagadresse (MAIL FROM, im Kopfbereich der Mail als Return-Path zu sehen) für den Transport zwischen Servern und die From-Adresse, die der Empfänger in Outlook sieht. SPF prüft nur, ob der sendende Server für die Domain der Umschlagadresse zugelassen ist, DKIM nur die Signatur der Domain, die die Mail signiert hat. Ob die sichtbare From-Adresse echt ist, sagt keines der beiden Verfahren. Genau diese Lücke nutzt E-Mail-Spoofing.

DMARC schließt sie. Eine Mail besteht DMARC, wenn mindestens eine Bedingung erfüllt ist:

• SPF besteht, und die Domain der Umschlagadresse passt zur From-Domain.
• DKIM besteht, und die signierende Domain passt zur From-Domain.

Dieses Passen heißt Ausrichtung (englisch Alignment). Im Standardmodus „relaxed“ genügt dieselbe registrierte Domain: news.beispiel.de passt zu beispiel.de. Im Modus „strict“ müssen beide Domains exakt gleich sein. Scheitern beide Bedingungen, bezieht der Empfänger die Richtlinie (englisch Policy) aus dem DMARC-Eintrag in seine Entscheidung ein. Maßgeblich ist seit Mai 2026 RFC 9989 (RFCs sind die Dokumente, in denen Internetstandards festgelegt werden), der den bisherigen RFC 7489 ablöst.

Aufbau des DMARC-Eintrags

Der DMARC-Record ist ein einzelner TXT-Eintrag mit dem Hostnamen _dmarc. Er besteht aus Tags, also Schlüssel-Wert-Paaren, getrennt durch Semikolons.

Tag	Bedeutung
v=DMARC1	Kennung, Pflicht und immer das erste Tag.
p=	Richtlinie: none, quarantine oder reject. Fehlt sie, gilt none.
sp=	Abweichende Richtlinie für bestehende Subdomains.
np=	Richtlinie für Subdomains, die es gar nicht gibt.
rua=	Adresse für Sammelberichte, z. B. mailto:dmarc@beispiel.de.
ruf=	Adresse für Einzelberichte zu fehlgeschlagenen Mails.
adkim=	Ausrichtung für DKIM: r (relaxed, Standard) oder s (strict).
aspf=	Ausrichtung für SPF, gleiche Werte wie bei adkim.
pct=	Anteil der fehlgeschlagenen Mails, auf den die Richtlinie wirkt. Veraltet: im neuen Standard entfallen, von Microsoft aber noch verwendet.

Die drei Richtlinien bedeuten:

• p=none: Der Empfänger ergreift keine DMARC-Maßnahme, schickt aber Berichte, sofern eine rua-Adresse angegeben ist. Das ist die Beobachtungsphase.
• p=quarantine: Nicht bestätigte Mails gelten als verdächtig. Der Empfänger verschiebt sie etwa in den Junk-Ordner oder in die Quarantäne, einen gesonderten Bereich außerhalb des Postfachs.
• p=reject: Der Domaininhaber wertet jeden Fehlschlag als Missbrauch seiner Domain. Der Empfänger kann solche Mails schon bei der Annahme ablehnen.

Die letzte Entscheidung trifft der Empfänger. Nach RFC 9989 darf er eine Mail nicht allein wegen p=reject ablehnen, sondern muss weitere Prüfungen einbeziehen.

DMARC in Microsoft 365

Der Domain-Assistent im Microsoft 365 Admin Center legt keinen DMARC-Eintrag an, Sie setzen ihn bei Ihrem DNS-Anbieter. Microsoft nennt p=reject als Ziel für alle Domains und empfiehlt drei Stufen:

_dmarc   TXT   v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de
_dmarc   TXT   v=DMARC1; p=quarantine; rua=mailto:dmarc@beispiel.de
_dmarc   TXT   v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de

Es gilt immer nur eine Zeile. Zwischen den Stufen werten Sie die Berichte aus, bis alle legitimen Versender SPF oder DKIM passend bestehen. Voraussetzung ist, dass SPF und DKIM für alle sendenden Domains und Subdomains eingerichtet sind. Für p=reject verlangt RFC 9989 ausdrücklich eine gültige DKIM-Signatur, weil SPF bei Weiterleitungen in der Regel scheitert. Subdomains mit wenig Mailaufkommen stellen Sie zuerst um, die Hauptdomain zuletzt.

Jeder Tenant, also jede Microsoft-365-Umgebung, bringt eine Domain wie beispiel.onmicrosoft.com mit. Wird sie nicht zum Versand genutzt, empfiehlt Microsoft dafür v=DMARC1; p=reject. Den TXT-Eintrag _dmarc legen Sie im Admin Center unter Settings > Domains > onmicrosoft.com-Domain > DNS records an.

Wie Microsoft 365 eingehende Mails nach DMARC behandelt

In der Anti-Phishing-Richtlinie im Microsoft Defender-Portal, der Sicherheitsoberfläche von Microsoft 365, ist „Honor DMARC record policy when the message is detected as spoof“ standardmäßig aktiv. Scheitert eine eingehende Mail an DMARC, folgt Microsoft 365 der Richtlinie des Absenders:

• p=reject: Die Mail wird abgelehnt (Fehlercode 550 5.7.1), alternativ lässt sich Quarantäne einstellen.
• p=quarantine: Nach den dokumentierten Standardwerten kommt die Mail in die Quarantäne, alternativ in den Junk-Ordner.
• p=none: keine DMARC-Aktion, die übrigen Filter wirken weiter.

Zeigt der MX-Eintrag auf einen vorgeschalteten Spamfilter, greift das nur mit „Enhanced Filtering for Connectors“. Mit dieser Einstellung erkennt Microsoft 365 trotz des Umwegs die eigentliche Quelle der Mail.

Subdomains und Parkdomains schützen

Der DMARC-Eintrag der Hauptdomain gilt für alle Subdomains, auch für nicht existierende, solange eine Subdomain keinen eigenen _dmarc-Eintrag hat. Mit sp= und np= setzen Sie abweichende Richtlinien. SPF und DKIM werden dagegen nicht vererbt: Jede sendende Subdomain, etwa newsletter.beispiel.de, braucht eigene Einträge.

Parkdomains, also Domains, die nie Mails versenden, etwa reservierte Marken- oder Tippfehlerdomains, sichern Sie so ab:

@        TXT   v=spf1 -all
_dmarc   TXT   v=DMARC1; p=reject;
@        MX    0 .

Die letzte Zeile ist optional: Dieser Null MX nach RFC 7505 zeigt an, dass die Domain keine Mails annimmt. DKIM-Einträge veröffentlichen Sie für solche Domains nicht.

Anforderungen großer Postfachanbieter

Google, Yahoo und Microsoft für Outlook.com verlangen von Massenversendern (englisch Bulk Sender) dasselbe Grundpaket: SPF und DKIM, einen DMARC-Eintrag mit mindestens p=none und eine From-Domain, die zu SPF oder DKIM passt.

Anbieter	Seit	Für wen
Google (Gmail)	1. Februar 2024	rund 5.000 oder mehr Mails an private Gmail-Konten in 24 Stunden; der Status gilt dauerhaft
Yahoo	Februar 2024	Massenversender, ohne genannten Schwellenwert
Microsoft Outlook.com	5. Mai 2025	mehr als 5.000 Mails pro Tag an outlook.com, hotmail.com und live.com

Outlook.com lehnt Mails, die das verfehlen, mit 550 5.7.515 ab. Google setzt die Regeln seit November 2025 strenger durch, bis hin zur Ablehnung. Die Outlook.com-Regel gilt für Endkundenpostfächer, nicht für Microsoft-365-Tenants von Unternehmen.

DMARC-Berichte

Über rua kommen Sammelberichte, meist einmal täglich als XML-Datei. Sie zeigen, welche Server im Namen Ihrer Domain senden und ob sie die Prüfungen bestehen. Einzelberichte über ruf verschickt Microsoft 365 nicht; Microsoft empfiehlt, zunächst nur rua zu setzen. Aufbau und Auswertung erklärt der Eintrag DMARC-Report.

Typische Fehler bei DMARC

• Zwei Einträge: Nach einem Anbieterwechsel steht ein alter DMARC-Eintrag neben dem neuen. Dann werden beide verworfen, und die Domain hat faktisch keine Richtlinie.
• Zu früh auf reject: Newsletter-Dienst, Buchhaltungssoftware, Scanner oder Kontaktformular senden mit Ihrer Domain, sind aber nicht erfasst. Deren Mails können dann abgelehnt werden.
• Dienstleister ohne Ausrichtung: Ein externer Dienst besteht SPF und DKIM nur mit seiner eigenen Domain. Abhilfe: Der Dienst signiert per DKIM mit Ihrer Domain oder einer Subdomain davon oder verwendet sie als Umschlagadresse.
• Weiterleitungen: Über Verteiler und Weiterleitungen kann auch echte Post DMARC verfehlen, weil SPF am neuen Server scheitert oder Änderungen die DKIM-Signatur brechen. ARC (Authenticated Received Chain) bewahrt die ursprünglichen Prüfergebnisse, wenn der Empfänger dem weiterleitenden System vertraut.

Praxis-Tipp: Schicken Sie vor jeder Verschärfung von jedem bekannten Versender eine Testmail an ein Postfach außerhalb Ihrer Organisation und öffnen Sie die Kopfzeilen der Nachricht. In der Zeile Authentication-Results muss dmarc=pass stehen. Steht dort dmarc=fail, zeigen die Angaben zu SPF und DKIM in derselben Zeile, welche Domain statt Ihrer geprüft wurde.

Typische Fragen zu DMARC

Was ist der Unterschied zwischen SPF, DKIM und DMARC?

SPF nennt die Server, die für eine Domain senden dürfen. DKIM signiert Mails. DMARC verknüpft beide Ergebnisse mit der sichtbaren Absenderadresse, legt fest, was bei einem Fehlschlag passiert, und regelt die Berichte.

Reicht p=none?

Für die DMARC-Vorgabe der großen Postfachanbieter an Massenversender ja, als Schutz nein. Mit p=none und rua-Adresse erhalten Sie Berichte, aber Empfänger wie Microsoft 365 ergreifen bei gefälschten Mails keine DMARC-Maßnahme.

Schützt DMARC vor jeder Phishing-Mail?

Nein. DMARC schützt nur die exakte From-Domain und ihre Subdomains. Ähnlich aussehende Domains wie beispie1.de, gefälschte Anzeigenamen und Mails aus gekaperten Postfächern von Geschäftspartnern erfasst es nicht. Welche Maßnahmen zusätzlich helfen, zeigt der Beitrag Microsoft 365 trotz MFA vor Phishing schützen.

DMARC mit CodeKlar einrichten

Ob Ihre Domain einen DMARC-Eintrag hat und welche Richtlinie er setzt, zeigt der kostenlose Microsoft 365 DNS-Checker. Die Einrichtung übernehmen wir: Wir erfassen alle Dienste und Systeme, die mit Ihrer Domain Mails versenden, bereinigen SPF, aktivieren DKIM und führen DMARC stufenweise bis p=reject ein.

Danach übernehmen wir das DMARC-Tracking: Wir werten die Berichte laufend aus, finden vergessene Versender und melden Ihnen Auffälligkeiten. Mehr dazu auf den Seiten Exchange Online für sichere E-Mail-Kommunikation und Microsoft 365 Security und Compliance.