Was ist DMARC? Der Leitfaden zu E-Mail-Authentifizierung

Warum es DMARC überhaupt gibt

Das SMTP-Protokoll, auf dem alle E-Mail der Welt läuft, stammt aus dem Jahr 1982. Es wurde in einer Zeit entworfen, in der sich die wenigen Mailserver im Netz gegenseitig vertrauten. Eine zentrale Konsequenz dieses Designs hat überdauert: Jeder darf in das From:-Feld einer E-Mail schreiben, was er will. Das ist kein Bug. Das ist das Protokoll.

Genau diese Lücke nutzen Phishing- und Spoofing-Angriffe seit Jahrzehnten. Ein Angreifer setzt deine Domain in den Absender, und ohne weitere Maßnahme landet die E-Mail im Posteingang deiner Kunden, Mitarbeiter oder Lieferanten — mit deinem Markennamen.

DMARC (Domain-based Message Authentication, Reporting & Conformance, RFC 7489) ist die Antwort auf dieses Problem. Es ist die DNS-Richtlinie, mit der du als Domain-Inhaber empfangenden Mailservern sagst: „Diese Domain authentifiziert ihre E-Mails. Wenn etwas nicht passt, mach Folgendes — und schick mir einen Report darüber.”

DMARC erfindet dabei keine neue Authentifizierung. Es kombiniert zwei bereits existierende Standards — SPF und DKIM — und ergänzt sie um zwei entscheidende Bausteine: Alignment und Reporting.

Die drei Schichten: SPF, DKIM, DMARC

SPF (Sender Policy Framework)

SPF ist ein TXT-Record im DNS deiner Domain, der auflistet, welche Server E-Mails in deinem Namen versenden dürfen:

example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Wenn ein Mailserver eine E-Mail von IP 1.2.3.4 mit der Absenderdomain example.com empfängt, fragt er den SPF-Record ab und prüft, ob 1.2.3.4 autorisiert ist. SPF prüft dabei den Envelope-From (auch Return-Path genannt), nicht den From:-Header, den der Empfänger sieht.

DKIM (DomainKeys Identified Mail)

DKIM signiert ausgehende E-Mails kryptografisch. Der öffentliche Schlüssel liegt im DNS, der private Schlüssel beim sendenden Mailserver. Empfangende Server prüfen die Signatur und können so verifizieren, dass die Nachricht unterwegs nicht verändert wurde und tatsächlich von einem autorisierten Absender stammt.

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQE..."

DMARC verbindet beide — und fügt Alignment hinzu

Hier kommt der entscheidende Punkt: SPF und DKIM allein reichen nicht. Ein Angreifer kann eine Domain mit gültigem SPF-Record (z.B. attacker.com) registrieren, von dort eine E-Mail mit From: [email protected] versenden, und SPF besteht — denn SPF prüft nur die Versanddomain, nicht das, was der Empfänger sieht.

DMARC schließt diese Lücke durch Identifier Alignment: Die Domain im sichtbaren From:-Header muss mit der von SPF oder DKIM authentifizierten Domain übereinstimmen.

Eine E-Mail besteht DMARC, wenn:

1. SPF passt UND der SPF-Domainname zum From:-Header passt (SPF Alignment), ODER
2. DKIM-Signatur ist gültig UND die DKIM-Domain passt zum From:-Header (DKIM Alignment).

Es muss nur eine der beiden Bedingungen erfüllt sein. Genau das macht DMARC robust gegen Forwarding und Mailing-Listen, die SPF brechen, DKIM aber meist erhalten.

Wie eine DMARC-Prüfung tatsächlich abläuft

Wenn ein empfangender Mailserver (z.B. Google, Microsoft, Yahoo) eine E-Mail bekommt:

1. Er extrahiert die Domain aus dem From:-Header — sagen wir example.com.
2. Er fragt _dmarc.example.com per DNS ab und liest den DMARC-Record.
3. Er führt SPF- und DKIM-Prüfungen durch.
4. Er prüft Alignment: Stimmt eine der authentifizierten Domains mit example.com überein?
5. Wenn keine Alignment-Bedingung erfüllt ist, wendet er die Policy an, die im DMARC-Record steht (none, quarantine oder reject).
6. Er generiert einen Aggregate-Report und sendet ihn an die Adresse, die du im rua=-Tag angegeben hast.

Schritt 6 ist der Grund, warum du überhaupt jemals etwas über deine eigene Domain erfährst.

Anatomie eines DMARC-Records

Ein typischer DMARC-Record sieht so aus:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s; pct=100; sp=reject"

Hier sind die wichtigsten Tags:

Tag	Bedeutung	Werte
v	Version (Pflicht, immer DMARC1)	DMARC1
p	Policy für die Hauptdomain (Pflicht)	none, quarantine, reject
sp	Policy für Subdomains	none, quarantine, reject
rua	Adresse(n) für Aggregate-Reports	mailto:[email protected]
ruf	Adresse(n) für Forensic-Reports	mailto:[email protected]
adkim	DKIM-Alignment-Modus	r (relaxed, Default) oder s (strict)
aspf	SPF-Alignment-Modus	r (relaxed, Default) oder s (strict)
pct	Prozentanteil, auf den die Policy angewendet wird	0–100
fo	Bedingungen für Forensic-Reports	0, 1, d, s
ri	Report-Intervall in Sekunden	Standard: 86400 (24h)
rf	Format der Forensic-Reports	afrf

Ein paar Punkte, die in der Praxis oft falsch verstanden werden:

• pct ist ein Migrations-Werkzeug, kein Schutzlevel. Wenn du p=reject; pct=10 setzt, werden nur 10 % der fehlschlagenden E-Mails abgelehnt — der Rest fällt auf die nächst-schwächere Policy zurück. Sinnvoll während einer schrittweisen Migration, aber als Endzustand kein vollständiger Schutz.
• sp braucht es nur, wenn es von p abweicht. Fehlt sp, übernehmen Subdomains automatisch die Policy von p. Eine Empfehlung wie „setze zusätzlich sp=reject”, obwohl du schon p=reject hast, ist redundant.
• adkim=s/aspf=s verlangt exakte Domain-Übereinstimmung. Im Default (r, relaxed) zählt eine passende Organisationsdomain — also etwa mail.example.com und example.com als ausgerichtet.
• ruf (Forensic-Reports) wird kaum noch unterstützt. Aus Datenschutzgründen senden die meisten großen Provider keine forensischen Reports mehr. Konzentriere dich auf rua.

Was ist mit „DMARC v2”?

Die IETF-DMARC-Working-Group arbeitet seit einigen Jahren an einer Revision von RFC 7489, allgemein DMARCbis genannt (gelegentlich umgangssprachlich „DMARC v2”). Eine wichtige Klarstellung vorweg: die Version im Record bleibt v=DMARC1 — und das ist eine bewusste Designentscheidung. Bestehende Records sollen ohne Änderung weitergültig bleiben, und Empfänger sollen DMARCbis-Records nicht versehentlich verwerfen, weil sie eine unbekannte Version sehen.

Die wichtigsten Neuerungen, soweit derzeit absehbar:

• Ein neuer Tag np= für „non-existent subdomain policy” — eine eigene Policy für Subdomains, die im DNS gar nicht existieren. Bisher fielen diese unter sp= (oder p=, wenn sp fehlte), was bei Subdomain-Spoofing zu unerwartetem Verhalten führen konnte. Mit np=reject schließt du nicht-existente Subdomains gezielt aus, ohne die sp=-Policy für reale Subdomains zu verschärfen.
• Ablösung der Public Suffix List (PSL) zugunsten eines DNS-basierten Tree-Walk-Verfahrens zur Bestimmung der organisatorischen Domain. Das schließt eine bekannte Schwäche, weil die PSL nicht garantiert aktuell ist und nicht jede TLD abdeckt.
• Ein psd=-Tag für Betreiber öffentlicher Suffix-Domains, mit dem PSDs (z. B. .gov.uk) explizit angeben können, ob unter ihnen liegende Domains der DMARC-Auswertung unterliegen.
• Wegfall von pct=. Der Tag galt schon länger als problematisch, weil er das tatsächliche Enforcement-Verhalten schwer berechenbar macht und Empfänger ihn unterschiedlich interpretieren. Migration soll künftig über schrittweise Policy-Anpassungen und np= laufen.

Solange DMARCbis noch nicht als finaler RFC veröffentlicht ist, gilt für die Praxis: bei v=DMARC1 bleiben, pct= für die Migration weiter nutzen, und np= lässt sich optional schon einsetzen — einige große Mailbox-Provider berücksichtigen es bereits.

Aggregate-Reports: Die Goldgrube, die kaum jemand liest

Wenn du rua= setzt, schickt dir jeder größere Mailserver der Welt täglich eine XML-Datei. Diese Datei enthält:

• Welche IP-Adressen E-Mails in deinem Namen versendet haben
• Wie viele Nachrichten von jeder Quelle kamen
• Ob SPF und DKIM jeweils bestanden oder versagt haben
• Welche Policy angewendet wurde (delivered, quarantined, rejected)
• Welche From:-Domain im Header stand

Das ist genau die Information, die du brauchst, um zu sehen, wer wirklich in deinem Namen E-Mails versendet — sowohl legitime Dienste, die du vergessen hast zu autorisieren, als auch Spoofer, die deine Domain missbrauchen.

Das Problem: Diese Reports manuell zu lesen ist unrealistisch. Eine mittelgroße Domain bekommt täglich hunderte XML-Dateien von dutzenden Empfängern. Ohne Tooling sind das nur Daten, keine Erkenntnisse — und genau hier setzen DMARC-Auswertungstools wie DMARCPulse an.

Die drei Policies — und welche du wirklich brauchst

p=none (Monitoring)

Empfangende Server tun nichts mit fehlschlagenden E-Mails — sie senden nur Reports. Sinnvoll als Startpunkt, um zu sehen, was deine Domain überhaupt versendet, ohne legitime Mails zu blockieren. Aber: kein Schutz.

p=quarantine (Spam-Ordner)

Fehlschlagende E-Mails landen im Spam-Ordner des Empfängers. Bietet Schutz, ist aber nicht endgültig — Empfänger können die Mail trotzdem aus dem Spam holen.

p=reject (Vollschutz)

Fehlschlagende E-Mails werden komplett abgewiesen und kommen nicht zu, etwa über einen 550 5.7.1-Fehler. Das ist der einzige Zustand, in dem deine Domain wirklich gegen Spoofing geschützt ist.

Der Weg von p=none zu p=reject ist methodisch, nicht schnell — und der häufigste Grund für Stillstand ist die Angst, legitime Mails zu blockieren. Wir haben dazu einen eigenen Artikel: DMARC-Enforcement: Warum p=none nicht reicht.

Häufige Fallstricke

In der Praxis tauchen immer wieder dieselben Probleme auf:

• SPF-10-Lookup-Limit. SPF erlaubt maximal 10 DNS-Lookups pro Auswertung. Jeder include: zählt — und große Anbieter wie Microsoft 365 verbrauchen mehrere allein für sich. Wer naiv jeden neuen Dienst per include: hinzufügt, läuft irgendwann in PermError, und SPF schlägt still fehl. SPF-Flatten oder Aufräumen wird dann unvermeidbar.
• Roher IP-Eintrag im SPF. ip4:1.2.3.4 ist kurzfristig praktisch, langfristig brüchig: Wenn der Provider die IP ändert, brichst du Mailfluss. Bevorzuge include: von Provider-Domains.
• DKIM mit gewidertem Schlüssel. Ein DKIM-Record mit leerem p= ist eine ausdrückliche Widerrufung. Manche Tools setzen das versehentlich beim Rotieren.
• Schwacher DKIM-Schlüssel. RSA mit weniger als 1024 Bit gilt als unsicher; aktuelle Empfehlung sind 2048 Bit.
• Vergessene Mail-Dienste. Marketingtool, Ticketsystem, Buchhaltungssoftware — jeder Dienst, der in deinem Namen mailt, muss in SPF (oder DKIM) aufgenommen werden, sonst scheitern legitime Mails an DMARC.
• ruf-Adresse ohne Empfänger-Authorisierung. Wenn du in ruf= eine fremde Domain einträgst, brauchst du dort einen _report._dmarc.{deine-domain}-Eintrag, der das autorisiert. Dasselbe gilt für rua= an externe Dienste.

Was nach DMARC kommt

DMARC ist die Grundlage. Aber moderne E-Mail-Sicherheit besteht aus mehreren Schichten:

• BIMI (Brand Indicators for Message Identification) — zeigt dein Markenlogo neben authentifizierten E-Mails im Posteingang. Setzt p=quarantine oder p=reject voraus.
• MTA-STS — erzwingt TLS-Verschlüsselung für eingehende E-Mails an deine Domain. Schützt gegen Downgrade-Angriffe, die DMARC nicht abdeckt.
• TLS-RPT — gibt dir Reports darüber, wann TLS-Verbindungen zu deinem Mailserver fehlschlagen.
• Domain Connect — erlaubt unterstützten DNS-Providern, DMARC-, SPF- und DKIM-Records mit einem Klick zu setzen.

Die meisten Domains kämpfen aber gar nicht mit der Frage „was kommt nach DMARC?”, sondern mit der Frage „wie kommen wir überhaupt zu p=reject?”. Laut Cloudflares Threat Report 2026 scheitern 46 % aller E-Mails weltweit an der DMARC-Validierung — wir haben das hier auseinander genommen: Warum 46 % aller E-Mails an DMARC scheitern.

Vom Record zur Praxis

Einen DMARC-Record zu veröffentlichen ist trivial. Das ist nicht das Problem. Das Problem ist, was danach kommt:

1. Reports sammeln und parsen. XML täglich, von dutzenden Quellen.
2. Sendequellen identifizieren. Welche IPs gehören zu welchem Dienst? Welche sind legitim, welche nicht?
3. SPF und DKIM für jede legitime Quelle korrigieren. Mit konkreten DNS-Werten — nicht nur „füge das hinzu”.
4. Schrittweise migrieren. p=none → p=quarantine → p=reject, mit konstant hohen Passraten (>95 %) als Bedingung für jeden Schritt.
5. Drift vermeiden. Neue Dienste kommen, Schlüssel rotieren, IPs ändern sich. DMARC ist kein Projekt, sondern ein Betriebsprozess.

DMARCPulse ist dafür gebaut: Reports werden automatisch eingelesen und ausgewertet, Sendequellen klassifiziert, und konkrete Empfehlungen mit copy-paste-fertigen DNS-Werten generiert. Statt „SPF schlägt fehl für Quelle X” bekommst du den exakten include:-Eintrag oder DKIM-Selektor, der fehlt. 14 Tage kostenlos testen.

Zusammenfassung

• DMARC kombiniert SPF und DKIM mit Alignment und Reporting und schließt die Lücke, die SMTP von Hause aus offenlässt.
• Eine E-Mail besteht DMARC, wenn entweder SPF oder DKIM passt und die zugehörige Domain mit dem From:-Header ausgerichtet ist.
• Ein DMARC-Record besteht aus Tags wie p, rua, adkim, aspf, pct — die wichtigsten sind p (Policy) und rua (Report-Adresse).
• Die drei Policies sind none (Monitoring), quarantine (Spam) und reject (Vollschutz). Nur p=reject schützt wirklich.
• Aggregate-Reports sind die Goldgrube — aber nur, wenn du sie auswertest.
• DMARC ist die Foundation; BIMI, MTA-STS und TLS-RPT bauen darauf auf.