Ein DMARC-Record ist der zentrale Steuermechanismus moderner E-Mail-Authentifizierung. Während SPF und DKIM jeweils nur Teilaspekte prüfen, legt DMARC fest, wie empfangende Mailserver diese Ergebnisse bewerten sollen und was mit Nachrichten passiert, die die Anforderungen nicht erfüllen. Für Domains, die professionell E-Mails versenden, ist DMARC deshalb nicht nur ein Sicherheitsfeature, sondern die entscheidende Instanz für Schutz vor Domain-Spoofing, kontrollierte Zustellbarkeit und belastbare Transparenz über Missbrauch.
Im folgenden Beitrag wird Schritt für Schritt erklärt, wie ein DMARC-Record aufgebaut ist, wie die Auswertung funktioniert, welche Parameter wirklich wichtig sind und wie sich ein sauberer DMARC-Eintrag fachlich korrekt entwickeln lässt.
DMARC-Record-Generator: Eintrag direkt erstellen oder anpassen
Mit dem kostenfreien DMARC-Tool lässt sich der passende Record direkt zusammenstellen – inklusive Policy, Reporting-Adressen, Alignment-Einstellungen und optionaler Quarantäne- oder Reject-Strategie für einzelne Umgebungen.
DMARC-Record erstellen: Leitfaden für Aufbau, Funktionsweise und die richtige Policy
Ein DMARC-Record ist schnell eingetragen, aber selten von Anfang an richtig durchdacht. Genau das ist in der Praxis ein Problem. Viele Domains besitzen zwar einen DMARC-Eintrag, doch häufig ist er entweder auf p=none stehen geblieben, falsch mit SPF und DKIM verzahnt oder ohne sauberes Verständnis von Alignment, Reporting und Policy entwickelt worden. Solange keine sichtbaren Zustellprobleme auftreten, bleibt das oft unbemerkt. Erst wenn Phishing-Wellen, Spoofing-Versuche oder unerklärliche Ablehnungen auftauchen, zeigt sich, ob der DMARC-Record nur formal existiert oder ob er als belastbares Steuerungsinstrument aufgebaut wurde.
Wer DMARC professionell einsetzen will, muss deshalb vor allem eines verstehen: DMARC ist nicht einfach ein weiterer DNS-Eintrag neben SPF und DKIM. DMARC ist die Regelinstanz, die definiert, welche Identität im sichtbaren Absender geschützt werden soll, wie SPF und DKIM darauf ausgerichtet sein müssen und wie empfangende Systeme mit Verstößen umgehen sollen. Genau darin liegt seine Bedeutung. Erst DMARC macht aus SPF und DKIM ein zusammenhängendes Schutzsystem für die Domain im From-Header.
Ein guter DMARC-Record schützt nicht nur gegen Missbrauch, sondern schafft auch Transparenz. Über Reporting wird sichtbar, welche Systeme tatsächlich im Namen einer Domain senden, wo Fehlausrichtungen bestehen und ob fremde Quellen versuchen, die Domain als Absender zu missbrauchen. Genau deshalb ist DMARC nicht nur ein Abwehrmechanismus, sondern auch ein Analysewerkzeug für die eigene Maillandschaft.
Was ein DMARC-Record technisch prüft
DMARC steht für Domain-based Message Authentication, Reporting and Conformance. Der DMARC-Record ist ein DNS-TXT-Eintrag unter der Subdomain _dmarc einer Domain, also zum Beispiel:
_dmarc.example.deDMARC beantwortet eine andere Frage als SPF oder DKIM. Während SPF prüft, ob ein sendender Server für eine bestimmte technische Absenderdomain autorisiert ist, und DKIM prüft, ob eine Nachricht kryptografisch gültig signiert wurde, bewertet DMARC zusätzlich, ob mindestens eines dieser Verfahren zur sichtbaren Absenderdomain im From-Header passt. Dieser Zusammenhang heißt Alignment.
Damit ist DMARC die erste Ebene, die nicht nur technische Teilprüfungen betrachtet, sondern die sichtbare Marken- oder Unternehmensidentität in der E-Mail schützt. Genau deshalb ist DMARC für Schutz vor Absenderfälschung so viel wirksamer als SPF allein.
Wie DMARC in der Praxis funktioniert
Die DMARC-Prüfung lässt sich auf vier Kernschritte reduzieren:
- Der empfangende Mailserver liest die sichtbare Absenderdomain aus dem From-Header.
- Er prüft, ob für diese Domain ein DMARC-Record unter _dmarc vorhanden ist.
- Dann bewertet er SPF und DKIM nicht nur isoliert, sondern daraufhin, ob mindestens eines der beiden Verfahren aligned ist, also zur sichtbaren From-Domain passt.
- Abschließend wendet er die im DMARC-Record definierte Policy an: keine Maßnahme, Quarantäne oder Ablehnung.
Der zentrale Punkt ist: DMARC verlangt nicht, dass SPF und DKIM beide gleichzeitig bestehen. Es reicht aus, wenn mindestens eines der beiden Verfahren erfolgreich ist und gleichzeitig korrekt zur sichtbaren Absenderdomain ausgerichtet ist. Genau dadurch entsteht Flexibilität, ohne den Schutzgedanken aufzugeben.
Warum DMARC ohne Alignment nicht zu verstehen ist
Alignment ist der fachliche Kern von DMARC. Ohne Alignment wäre DMARC kaum mehr als ein zusätzlicher Schalter. Mit Alignment prüft DMARC dagegen, ob die Identität, die der Empfänger im Postfach sieht, tatsächlich mit der Identität zusammenpasst, die durch SPF oder DKIM authentifiziert wurde.
Das lässt sich am einfachsten so verstehen:
- SPF authentifiziert die Envelope-From-Domain beziehungsweise Return-Path-Domain.
- DKIM authentifiziert die Domain in der kryptografischen Signatur.
- DMARC prüft, ob diese authentifizierte Domain zur sichtbaren From-Domain passt.
Dadurch wird ein klassisches Problem gelöst: Ein Angreifer kann versuchen, im sichtbaren Absender example.de zu setzen, während SPF technisch nur für irgendeine andere Domain besteht. Ohne DMARC könnte ein Teil dieser Konstellationen irreführend wirken. Mit DMARC wird verlangt, dass die erfolgreiche Authentifizierung zur sichtbaren Absenderidentität gehört.
Der typische Aufbau eines DMARC-Records
Ein DMARC-Record ist ein TXT-Record und beginnt immer mit der Versionsangabe v=DMARC1. Danach folgen Parameter, die das Verhalten definieren.
v=DMARC1; p=none; rua=mailto:dmarc@example.deDieser Record bedeutet: Die Domain veröffentlicht DMARC, wendet aber zunächst noch keine Quarantäne- oder Reject-Maßnahme an. Stattdessen werden aggregierte Reports an die angegebene Adresse gesendet.
Ein strengerer DMARC-Record kann zum Beispiel so aussehen:
v=DMARC1; p=reject; rua=mailto:dmarc@example.de; adkim=s; aspf=sDann fordert die Domain, dass nicht konforme Nachrichten abgelehnt werden und dass sowohl für DKIM als auch für SPF striktes Alignment gelten soll.
Die wichtigsten DMARC-Parameter und was sie wirklich bedeuten
| Parameter | Bedeutung | Pflicht oder optional | Praxisrelevanz |
|---|---|---|---|
| v | DMARC-Version, immer DMARC1 | Pflicht | Ohne diesen Startwert ist der Record kein gültiger DMARC-Eintrag. |
| p | Policy für die Hauptdomain | Pflicht | Legt fest, ob keine Maßnahme, Quarantäne oder Reject gelten soll. |
| rua | Adresse für aggregierte Reports | Optional | Sehr wichtig für Analyse, Monitoring und kontrollierte Einführung. |
| ruf | Adresse für forensische Fehlermeldungen | Optional | Wird deutlich seltener zuverlässig versendet und kann Datenschutzfragen berühren. |
| pct | Prozentualer Anteil, auf den die Policy angewendet wird | Optional | Nützlich für gestufte Einführung, aber häufig überschätzt. |
| adkim | Alignment-Modus für DKIM | Optional | Steuert, ob DKIM relaxed oder strict zur From-Domain passen muss. |
| aspf | Alignment-Modus für SPF | Optional | Steuert, ob SPF relaxed oder strict zur From-Domain passen muss. |
| sp | Policy für Subdomains | Optional | Wichtig, wenn Subdomains gesondert behandelt werden sollen. |
| fo | Optionen für Fehlermeldungs-Trigger | Optional | Feinsteuerung für Failure Reporting, meist nur in spezialisierten Setups relevant. |
v=DMARC1: die Pflichtkennung
Jeder DMARC-Record beginnt mit v=DMARC1. Diese Angabe steht immer am Anfang und kennzeichnet den TXT-Record eindeutig als DMARC-Regelwerk. Ohne diesen Startwert ist der Eintrag fachlich kein gültiger DMARC-Record.
p: die eigentliche Policy
Der Parameter p ist das Herzstück des DMARC-Records. Er bestimmt, was empfangende Systeme mit Nachrichten tun sollen, die DMARC nicht bestehen.
| Wert | Bedeutung | Praxis |
|---|---|---|
| none | Nur überwachen, keine aktive Schutzmaßnahme anfordern | Geeignet für Einführung, Analyse und Fehlerbehebung |
| quarantine | Nicht konforme Nachrichten sollen misstrauisch behandelt werden | Oft Übergangsstufe vor reject |
| reject | Nicht konforme Nachrichten sollen abgewiesen werden | Sauberste Zielkonfiguration bei reifer Maillandschaft |
Die drei Policy-Stufen unterscheiden sich nicht nur technisch, sondern auch strategisch. p=none ist keine Schutzmaßnahme, sondern ein Beobachtungsmodus. p=quarantine signalisiert, dass nicht konforme Nachrichten verdächtig sind. p=reject ist die konsequenteste Form, weil damit klar verlangt wird, dass nicht autorisierte Nachrichten nicht angenommen werden sollen.
rua: aggregierte Reports für die operative Kontrolle
Der Parameter rua definiert, an welche Adresse aggregierte DMARC-Reports geschickt werden sollen. Diese Berichte enthalten keine einzelnen vollständigen E-Mails, sondern zusammengefasste Informationen darüber, welche Quellen Nachrichten im Namen der Domain versendet haben, ob SPF und DKIM bestanden wurden und wie die Ausrichtung zur From-Domain aussah.
Gerade für die Einführung von DMARC ist rua der wichtigste operative Parameter. Ohne Reporting bleibt unsichtbar, welche legitimen Systeme vielleicht noch falsch konfiguriert sind und welche fremden Quellen die Domain missbrauchen wollen.
rua=mailto:dmarc@example.deruf: forensische Reports mit begrenzter Praxisrelevanz
Der Parameter ruf steht für Failure Reports beziehungsweise forensische Berichte. Diese sollen bei bestimmten Fehlersituationen detailliertere Informationen liefern. In der Praxis werden solche Reports jedoch deutlich uneinheitlicher versendet als aggregierte Reports. Zusätzlich können Datenschutz- und Vertraulichkeitsfragen entstehen, weil hier unter Umständen mehr Nachrichtenkontext transportiert wird.
Für viele produktive Setups ist rua daher deutlich wichtiger als ruf. Wer ruf einsetzt, sollte dies bewusst und mit Blick auf Datenschutz, Datenmenge und tatsächlichen Mehrwert tun.
adkim und aspf: relaxed oder strict?
Mit adkim und aspf wird festgelegt, wie streng das Alignment für DKIM und SPF sein soll. Es gibt jeweils zwei Modi:
| Parameter | Wert | Bedeutung |
|---|---|---|
| adkim oder aspf | r | Relaxed Alignment: Subdomains können als passend gelten. |
| adkim oder aspf | s | Strict Alignment: Die Domain muss exakt übereinstimmen. |
Standardmäßig gilt relaxed, wenn kein anderer Wert gesetzt wird. Das ist in vielen realen Infrastrukturen sinnvoll, weil Dienste oft mit Subdomains arbeiten. Strict erhöht die Präzision, kann aber in komplexen Systemlandschaften schneller zu ungewollten Fehlschlägen führen. Striktes Alignment ist deshalb kein pauschales Qualitätsmerkmal, sondern eine bewusste Architekturentscheidung.
sp: gesonderte Policy für Subdomains
Mit sp lässt sich festlegen, wie Subdomains behandelt werden sollen, wenn sie keinen eigenen DMARC-Record besitzen. Das ist besonders relevant, wenn die Hauptdomain streng geschützt werden soll, einzelne Subdomains aber andere Anforderungen haben.
sp=quarantineDamit kann die Hauptdomain beispielsweise bereits auf reject stehen, während Subdomains zunächst noch mit quarantine behandelt werden.
pct: gestufte Einführung mit Augenmaß
Der Parameter pct gibt an, auf wie viel Prozent der nicht konformen Nachrichten die Policy angewendet werden soll. Ein Eintrag wie pct=25 bedeutet, dass die Policy rechnerisch nur auf einen Teil der betroffenen Nachrichten angewendet werden soll.
In der Praxis ist pct vor allem für kontrollierte Rollouts interessant. Gleichzeitig sollte der Parameter nicht überschätzt werden. Er ist kein Ersatz für saubere Vorbereitung. Wer legitime Versandquellen nicht kennt oder SPF und DKIM nicht korrekt aufgesetzt hat, löst das Problem nicht durch eine Prozentsteuerung, sondern nur durch technische Bereinigung.
Der Unterschied zwischen SPF, DKIM und DMARC
| Verfahren | Was geprüft wird | Typische Schwäche ohne DMARC | Rolle im Gesamtsystem |
|---|---|---|---|
| SPF | Ob der sendende Server für eine technische Absenderdomain autorisiert ist | Schützt nicht automatisch die sichtbare From-Domain | Serverautorisierung |
| DKIM | Ob die Nachricht kryptografisch mit einer Domain signiert wurde | Eine gültige Signatur allein schützt nicht automatisch die sichtbare Absenderidentität | Nachrichtenintegrität und Signatur |
| DMARC | Ob SPF oder DKIM erfolgreich und zur sichtbaren From-Domain ausgerichtet sind | Ohne korrektes SPF und DKIM keine belastbare Grundlage | Policy, Alignment und Reporting |
Diese Trennung ist entscheidend. SPF und DKIM liefern Authentifizierungssignale. DMARC macht daraus eine durchsetzbare Regel für die Domainidentität, die der Empfänger tatsächlich sieht.
So wird ein DMARC-Record fachlich sauber eingeführt
Der größte Fehler bei DMARC ist nicht eine falsche Syntax, sondern ein zu schneller Wechsel auf eine harte Policy ohne vollständige Transparenz über die tatsächliche Versandlandschaft. DMARC sollte in reifen Umgebungen zwar auf reject hinauslaufen, aber nicht blind.
Schritt 1: Alle legitimen Versandquellen kennen
Vor einem strengen DMARC müssen alle realen Sender bekannt sein. Dazu gehören nicht nur das zentrale Mailsystem, sondern auch Webserver, Shops, CRM-Plattformen, Helpdesk-Systeme, Newsletter-Dienste, ERP-Lösungen, Scanner oder Monitoring-Tools. Jede nicht berücksichtigte Versandquelle kann später zu ungewollten DMARC-Fehlschlägen führen.
Schritt 2: SPF und DKIM technisch bereinigen
DMARC funktioniert nur dann sauber, wenn SPF und oder DKIM korrekt eingerichtet sind. Das bedeutet: legitime Quellen müssen entweder über SPF passend autorisiert oder über DKIM korrekt signiert sein – idealerweise beides. Vor allem aber muss mindestens eines der beiden Verfahren aligned zur sichtbaren From-Domain sein.
Schritt 3: Mit p=none und Reporting starten
Ein typischer Startpunkt ist ein beobachtender Record wie:
v=DMARC1; p=none; rua=mailto:dmarc@example.deDamit werden noch keine Nachrichten aktiv sanktioniert, aber die Domain erhält Einblick in die reale Lage. Genau diese Phase ist entscheidend, um Fehlkonfigurationen zu erkennen, Drittanbieter zu identifizieren und Missbrauch sichtbar zu machen.
Schritt 4: Auf quarantine erhöhen
Wenn die Reports zeigen, dass die legitime Infrastruktur sauber funktioniert, kann die Policy auf quarantine angehoben werden. Das ist der Übergang von Beobachtung zu echter Schutzwirkung. Nicht konforme Nachrichten sollen nun misstrauisch behandelt werden, landen also typischerweise eher im Spam oder in Quarantäne.
Schritt 5: Auf reject gehen
Die fachlich sauberste Zielkonfiguration ist für viele produktive Hauptdomains p=reject. Damit signalisiert die Domain eindeutig, dass nicht konforme Nachrichten nicht akzeptiert werden sollen. Dieser Schritt ist dann sinnvoll, wenn die legitimen Versandquellen stabil, SPF und DKIM korrekt ausgerichtet und die Reports über einen ausreichenden Zeitraum sauber ausgewertet wurden.
Beispiele für sinnvolle DMARC-Records
Nur beobachten
v=DMARC1; p=none; rua=mailto:dmarc@example.deGeeignet für die Einführungsphase, wenn zunächst Transparenz geschaffen werden soll.
Kontrollierter Schutz mit Quarantäne
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.de; pct=100Geeignet für Domains, deren legitime Versandquellen weitgehend bereinigt sind, bei denen aber noch eine Übergangsphase gewünscht ist.
Strenge Zielkonfiguration
v=DMARC1; p=reject; rua=mailto:dmarc@example.de; adkim=s; aspf=sGeeignet für reife, technisch sauber kontrollierte Umgebungen mit strengem Marken- und Identitätsschutz.
Typische Fehler in der Praxis
- DMARC ohne sauberes SPF oder DKIM: Die Policy ist hart, aber die technische Grundlage nicht belastbar.
- Zu schneller Wechsel auf reject: Legitimer Mailverkehr wird beschädigt, weil noch nicht alle Quellen bereinigt sind.
- Fehlendes Reporting: Es fehlt die operative Transparenz, um Probleme systematisch zu erkennen.
- Alignment wird übersehen: SPF oder DKIM bestehen zwar, passen aber nicht zur sichtbaren From-Domain.
- Subdomains werden nicht mitgedacht: Ohne klare Regelung entstehen Schutzlücken oder unerwartete Effekte.
- DMARC wird als Ersatz für SPF und DKIM missverstanden: DMARC steuert und bewertet, ersetzt aber keine saubere Authentifizierung.
Best Practices für einen professionellen DMARC-Record
- DMARC nie isoliert betrachten, sondern immer gemeinsam mit SPF und DKIM planen.
- Mit Reporting starten und erst danach die Policy schrittweise verschärfen.
- Die sichtbare From-Domain als schützenswerte Identität verstehen.
- Alignment bewusst konfigurieren statt Standardwerte unreflektiert zu übernehmen.
- Subdomains ausdrücklich einbeziehen, wenn sie Teil der Versandarchitektur sind.
- Die Reports operativ auswerten und nicht nur sammeln.
FAQ zum DMARC-Record
Was ist ein DMARC-Record?
Ein DMARC-Record ist ein DNS-TXT-Eintrag, der festlegt, wie empfangende Mailserver Nachrichten bewerten sollen, wenn SPF und DKIM die sichtbare Absenderdomain nicht korrekt authentifizieren.
Wozu dient DMARC?
DMARC schützt die sichtbare Absenderdomain vor Missbrauch, verlangt Alignment zwischen From-Domain und SPF oder DKIM und ermöglicht Reporting über legitime und missbräuchliche Versandquellen.
Was ist der Unterschied zwischen SPF, DKIM und DMARC?
SPF autorisiert Versandserver, DKIM signiert Nachrichten kryptografisch, und DMARC bewertet, ob mindestens eines dieser Verfahren erfolgreich und korrekt zur sichtbaren From-Domain ausgerichtet ist.
Was bedeutet p=none?
p=none bedeutet, dass noch keine aktive Schutzmaßnahme angefordert wird. Die Domain beobachtet zunächst nur und sammelt Reports.
Was bedeutet p=quarantine?
p=quarantine bedeutet, dass nicht konforme Nachrichten als verdächtig behandelt werden sollen, zum Beispiel durch Zustellung in Spam oder Quarantäne.
Was bedeutet p=reject?
p=reject bedeutet, dass nicht konforme Nachrichten abgewiesen werden sollen. Das ist die strengste und wirksamste DMARC-Policy.
Was ist Alignment bei DMARC?
Alignment bedeutet, dass die durch SPF oder DKIM authentifizierte Domain zur sichtbaren Absenderdomain im From-Header passen muss. Erst dadurch schützt DMARC die tatsächliche Absenderidentität.
Wofür steht rua im DMARC-Record?
rua definiert die Adresse für aggregierte DMARC-Reports. Diese Berichte sind die wichtigste Grundlage für Monitoring und kontrollierte Einführung.
Braucht jede Domain einen DMARC-Record?
Für jede Domain, die sichtbar als E-Mail-Absender auftritt oder vor Missbrauch geschützt werden soll, ist ein DMARC-Record fachlich sehr sinnvoll. Für professionelle Mailkommunikation gehört er heute zur Grundausstattung.
Kann DMARC ohne SPF und DKIM funktionieren?
Nein. DMARC bewertet die Ergebnisse von SPF und DKIM. Ohne diese Verfahren fehlt die technische Grundlage, auf der DMARC Entscheidungen treffen kann.
Meroth IT-Service ist Ihr lokaler IT-Dienstleister in Frankfurt am Main für kleine Unternehmen, Selbstständige und Privatkunden
Kostenfreie Ersteinschätzung Ihres Anliegens?
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten