DMARC (Domain-based Message Authentication, Reporting and Conformance) Einträge dienen als DNS-basierte Richtlinien, die empfangenden Mail-Servern mitteilen, wie E-Mails von Ihrer Domain behandelt werden sollen. Das Verständnis der präzisen DMARC Record Syntax ist entscheidend für Organisationen, die robuste E-Mail-Authentifizierungsprotokolle im Jahr 2026 implementieren.

Ein DMARC-Eintrag besteht aus Tag-Wert-Paaren, die durch Semikolons getrennt sind und als TXT-Eintrag an der spezifischen DNS-Position _dmarc.ihredomain.com veröffentlicht werden. Jede Komponente erfüllt eine spezifische Funktion in der Authentifizierungskette, von der Richtliniendurchsetzung bis zur forensischen Berichtskonfiguration.

I. DMARC DNS Eintragsstruktur Übersicht

Fünfstufiger Prozess zur Erstellung von DMARC-Records, vom Versions-Tag bis zur DNS-Veröffentlichung.

Grundlegendes Syntax-Format

DMARC-Einträge folgen einem standardisierten Tag=Wert-Format mit spezifischen Reihenfolge-Anforderungen:

v=DMARC1; p=policy; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=subdomain_policy; pct=percentage; adkim=alignment; aspf=alignment; rf=format; ri=interval; fo=options

Erforderliche vs. optionale Tags

Erforderliche Tags:

  • v (Version)
  • p (Richtlinie)

Optionale Tags:

  • rua (Zusammenfassungsberichte)
  • ruf (Forensische Berichte)
  • sp (Subdomain-Richtlinie)
  • pct (Prozentsatz)
  • adkim (DKIM-Ausrichtung)
  • aspf (SPF-Ausrichtung)
  • rf (Berichtsformat)
  • ri (Berichtsintervall)
  • fo (Fehleroptionen)

II. Versions-Tag (v)

Syntax

v=DMARC1

Der Versions-Tag muss immer die erste Komponente in jedem DMARC-Eintrag sein und unterstützt derzeit nur einen Wert: DMARC1. Dies identifiziert den Eintrag als DMARC-Richtlinie für empfangende Mail-Server.

Beispiele

v=DMARC1; p=none
v=DMARC1; p=quarantine; rua=mailto:[email protected]

Grenzfälle

  • Fehlender Versions-Tag macht den gesamten Eintrag ungültig
  • Versions-Tag an anderer Position als der ersten verursacht Parsing-Fehler
  • Jeder andere Wert als DMARC1 führt zur Ablehnung des Eintrags

III. Richtlinien-Tag (p)

Syntax

p=none|quarantine|reject

Der Richtlinien-Tag definiert, wie empfangende Server E-Mails behandeln sollen, die DMARC-Authentifizierungsprüfungen nicht bestehen.

Richtlinienwerte erklärt

none: Überwachungsmodus – keine Maßnahmen bei fehlgeschlagenen Nachrichten

v=DMARC1; p=none; rua=mailto:[email protected]

quarantine: Fehlgeschlagene Nachrichten werden in Spam-/Junk-Ordner zugestellt

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

reject: Fehlgeschlagene Nachrichten werden vollständig auf SMTP-Ebene blockiert

v=DMARC1; p=reject; rua=mailto:[email protected]

Grenzfälle

  • Richtliniendurchsetzung hängt von der Empfängerimplementierung ab
  • Einige Empfänger können Quarantäne aus Reputationsgründen als Ablehnung behandeln
  • Richtlinienausweitung sollte schrittweisen Bereitstellungsmustern folgen (none → quarantine → reject)

IV. Zusammenfassungsberichte URI (rua)

Syntax

rua=mailto:[email protected],mailto:[email protected]

Spezifiziert E-Mail-Adressen zum Empfangen von XML-Zusammenfassungsberichten mit Authentifizierungsstatistiken.

Konfigurationsbeispiele

Einzelner Empfänger:

rua=mailto:[email protected]

Mehrere Empfänger:

rua=mailto:[email protected],mailto:[email protected]

Externe Domain-Berichterstattung:

rua=mailto:[email protected]

Grenzfälle

  • Externe Domain-Empfänger benötigen DNS-Autorisierungseinträge
  • Berichte werden täglich von den meisten Empfängern generiert (24-Stunden-Zyklen)
  • Fehlender rua-Tag eliminiert Sichtbarkeit in DMARC-Performance
  • Einige Empfänger verhängen Größenbeschränkungen für Berichtsziele

V. Forensische Berichte URI (ruf)

Syntax

ruf=mailto:[email protected]

Definiert Empfänger für detaillierte forensische Berichte einzelner Authentifizierungsfehler.

Beispiele

ruf=mailto:[email protected]
v=DMARC1; p=quarantine; ruf=mailto:[email protected],mailto:[email protected]

Grenzfälle

  • Viele Empfänger senden aufgrund von Datenschutzbedenken keine forensischen Berichte mehr
  • Forensische Berichte enthalten vollständige Message-Header und potenziell sensible Daten
  • Externe Domain-Empfänger benötigen explizite DNS-Autorisierung
  • Volumen kann für Domains mit hohem E-Mail-Verkehr überwältigend sein

VI. Subdomain-Richtlinie (sp)

Syntax

sp=none|quarantine|reject

Etabliert Richtlinienvererbung für Subdomains, wenn kein expliziter DMARC-Eintrag auf Subdomain-Ebene existiert.

Konfigurationsbeispiele

Strengere Subdomain-Richtlinie:

v=DMARC1; p=none; sp=quarantine; rua=mailto:[email protected]

Übereinstimmende Richtlinien:

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]

Grenzfälle

  • Subdomain-spezifische DMARC-Einträge überschreiben sp-Einstellungen
  • Standardverhalten wendet Parent-Domain-Richtlinie auf Subdomains an, wenn sp fehlt
  • Organisatorische Subdomains können unterschiedliche Richtlinienansätze erfordern

VII. Prozentsatz-Tag (pct)

Dreiphasige DMARC-Bereitstellung von der Überwachung bis zur vollständigen Durchsetzung mit prozentualen Tests.

Syntax

pct=1-100

Kontrolliert den Prozentsatz fehlgeschlagener Nachrichten, die der DMARC-Richtliniendurchsetzung unterliegen.

Beispiele

Schrittweise Einführung:

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]

Vollständige Durchsetzung (Standard):

v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]

Grenzfälle

  • Standardwert ist 100, wenn pct-Tag weggelassen wird
  • Nützlich für schrittweise Richtlinienbereitstellung und Tests
  • Zufälliges Sampling kann inkonsistente Benutzererfahrungen schaffen
  • Nicht alle Empfänger berücksichtigen Prozentangaben

VIII. DKIM-Ausrichtungsmodus (adkim)

Syntax

adkim=r|s

Definiert Ausrichtungsanforderungen zwischen DKIM-Signatur-Domain und From-Header-Domain.

Ausrichtungsmodi

Entspannt (r) – Standard:

v=DMARC1; p=quarantine; adkim=r; rua=mailto:[email protected]
  • Erlaubt organisatorische Domain-Ausrichtung (subdomain.example.com richtet sich nach example.com aus)

Strikt (s):

v=DMARC1; p=quarantine; adkim=s; rua=mailto:[email protected]
  • Erfordert exakte Domain-Übereinstimmung

Grenzfälle

  • Entspannte Ausrichtung berücksichtigt legitime Subdomain-E-Mail-Dienste
  • Strikte Ausrichtung verhindert Subdomain-Spoofing, kann aber legitime E-Mail-Flows unterbrechen
  • Mehrere DKIM-Signaturen werden unabhängig auf Ausrichtung bewertet

IX. SPF-Ausrichtungsmodus (aspf)

Syntax

aspf=r|s

Spezifiziert Ausrichtungsanforderungen zwischen SPF-Return-Path-Domain und From-Header-Domain.

Beispiele

Entspannte SPF-Ausrichtung:

v=DMARC1; p=none; aspf=r; adkim=s; rua=mailto:[email protected]

Strikte SPF-Ausrichtung:

v=DMARC1; p=quarantine; aspf=s; rua=mailto:[email protected]

Grenzfälle

  • Weiterleitungsszenarien brechen oft SPF-Ausrichtung unabhängig vom Modus
  • Drittanbieter-E-Mail-Dienste erfordern sorgfältige Return-Path-Konfiguration
  • Entspannter Modus berücksichtigt organisatorische Domain-Strukturen

X. Berichtsformat (rf)

Syntax

rf=afrf|iodef

Spezifiziert Formatpräferenz für forensische Berichte.

Formatoptionen

Authentication Failure Report Format (afrf) – Standard:

v=DMARC1; p=none; rf=afrf; ruf=mailto:[email protected]

Incident Object Description Exchange Format (iodef):

v=DMARC1; p=none; rf=iodef; ruf=mailto:[email protected]

Grenzfälle

  • Die meisten Empfänger standardisieren auf afrf unabhängig von rf-Spezifikation
  • iodef-Format selten in der Praxis implementiert
  • Formatpräferenz kann von Berichtssystemen ignoriert werden

XI. Berichtsintervall (ri)

Syntax

ri=seconds

Fordert spezifisches Intervall für Zusammenfassungsberichtsgenerierung an.

Beispiele

Tägliche Berichte (86400 Sekunden):

v=DMARC1; p=none; ri=86400; rua=mailto:[email protected]

Wöchentliche Berichte (604800 Sekunden):

v=DMARC1; p=none; ri=604800; rua=mailto:[email protected]

Grenzfälle

  • Die meisten Empfänger generieren Berichte nach ihren eigenen Zeitplänen unabhängig vom ri-Wert
  • Standardpraxis ist tägliche Berichtsgenerierung
  • Kürzere Intervalle werden selten von großen E-Mail-Anbietern berücksichtigt

XII. Fehleroptionen (fo)

Syntax

fo=0|1|d|s

Kontrolliert Bedingungen, die forensische Berichtsgenerierung auslösen.

Fehleroptionen erklärt

fo=0 (Standard): Berichte generiert, wenn sowohl SPF als auch DKIM fehlschlagen

v=DMARC1; p=none; fo=0; ruf=mailto:[email protected]

fo=1: Berichte generiert, wenn entweder SPF oder DKIM fehlschlägt

v=DMARC1; p=none; fo=1; ruf=mailto:[email protected]

fo=d: Berichte generiert, wenn DKIM fehlschlägt

v=DMARC1; p=none; fo=d; ruf=mailto:[email protected]

fo=s: Berichte generiert, wenn SPF fehlschlägt

v=DMARC1; p=none; fo=s; ruf=mailto:[email protected]

Grenzfälle

  • Mehrere Werte können kombiniert werden: fo=1:d:s
  • Forensische Berichterstattung zunehmend von Empfängern deaktiviert
  • Hochvolumen-Domains sollten fo=0 verwenden, um Berichtsvolumen zu minimieren

XIII. Erweiterte Konfigurationsbeispiele

Unternehmensbereitstellung

v=DMARC1; p=reject; sp=quarantine; adkim=r; aspf=r; pct=100; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]; fo=1; rf=afrf; ri=86400

Schrittweise Implementierung

v=DMARC1; p=none; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

Subdomain-fokussierte Richtlinie

v=DMARC1; p=none; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]

XIV. DNS-Veröffentlichungsanforderungen

DMARC-Einträge müssen als TXT-Einträge bei _dmarc.ihredomain.com mit ordnungsgemäßer DNS-Konfiguration veröffentlicht werden:

TTL-Überlegungen

  • Empfohlene TTL: 300-3600 Sekunden für Richtlinienänderungen
  • Niedrigere TTL-Werte ermöglichen schnellere Richtlinienaktualisierungen
  • Höhere TTL-Werte reduzieren DNS-Query-Last

Eintragsgrenzen

  • Einzelner DMARC-Eintrag pro Domain (mehrere Einträge verursachen Fehler)
  • Maximale Eintragslänge variiert je DNS-Anbieter
  • Lange Einträge können TXT-Eintragsaufteilung erfordern

XV. Häufige Syntax-Fehler

Abstandsprobleme

# Falsch - Leerzeichen in Tag-Namen
v = DMARC1; p = none

# Richtig
v=DMARC1; p=none

Groß-/Kleinschreibung

# Falsch - Groß-/Kleinschreibung wichtig für Werte
v=dmarc1; p=NONE

# Richtig
v=DMARC1; p=none

Trennzeichenprobleme

# Falsch - Komma statt Semikolon
v=DMARC1, p=none

# Richtig
v=DMARC1; p=none

Organisationen, die DMARC-Richtlinien implementieren, profitieren von der Verwendung von Skysnag Protect, um DMARC-Performance zu überwachen, Eintragssyntax zu validieren und detaillierte Authentifizierungsberichte zu erhalten. Die Plattform bietet Echtzeit-Sichtbarkeit in den E-Mail-Authentifizierungsstatus und hilft dabei, Konfigurationsprobleme zu identifizieren, bevor sie die E-Mail-Zustellung beeinträchtigen.

XVI. Wichtige Erkenntnisse

DMARC-Eintragssyntax erfordert präzise Formatierung mit obligatorischen Versions- und Richtlinien-Tags, während optionale Tags Berichts- und Ausrichtungskontrolle bieten. Erfolgreiche Implementierung erfordert das Verständnis der Funktion jeder Komponente, ordnungsgemäße DNS-Veröffentlichung und schrittweise Richtlinienausweitung. Regelmäßige Überwachung durch Zusammenfassungsberichte gewährleistet Authentifizierungseffektivität, während forensische Berichte helfen, spezifische Fehlermuster zu identifizieren.

Ordnungsgemäße DMARC-Konfiguration schützt Domains vor Spoofing-Angriffen und erhält gleichzeitig die legitime E-Mail-Zustellung aufrecht, wenn Syntax-Regeln korrekt befolgt werden. Organisationen sollten mit Überwachungsrichtlinien beginnen, Syntax gründlich validieren und externe Berichtsautorisierung implementieren, wenn Drittanbieter-DMARC-Dienste verwendet werden.