Das Verständnis der DMARC-Datensatz-Syntax ist grundlegend für die Implementierung einer effektiven E-Mail-Authentifizierung. Ein DMARC-Datensatz (Domain-based Message Authentication, Reporting and Conformance) besteht aus spezifischen Tags und Werten, die empfangenden Mail-Servern anweisen, wie mit E-Mails umzugehen ist, die die SPF- oder DKIM-Authentifizierung nicht bestehen. Dieser umfassende Leitfaden schlüsselt jedes DMARC-Tag mit praktischen Beispielen und Validierungstechniken auf, um Ihnen beim Erstellen sicherer DMARC-Richtlinien zu helfen.

I. Grundlegende DMARC-Datensatz-Struktur

Vierstufige DMARC-Record-Struktur mit Darstellung der Version-, Policy-, Reporting- und Alignment-Tags.

DMARC-Datensätze werden als DNS-TXT-Datensätze in der Subdomain _dmarc.ihredomain.com veröffentlicht. Die grundlegende Syntax folgt einem Tag-Wert-Paar-Format, das durch Semikolons getrennt ist:

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

Jedes Tag erfüllt eine spezifische Funktion bei der Definition Ihrer Domain-E-Mail-Authentifizierungsrichtlinie. Schauen wir uns jedes Tag im Detail an.

II. Erforderliche DMARC-Tags

Vergleichstabelle der drei DMARC-Richtlinienstufen: none, quarantine und reject, mit ihren Aktionen und Anwendungsfällen.

v (Version)

Syntax: v=DMARC1
Zweck: Gibt die DMARC-Version an
Erforderlich: Ja (muss das erste Tag sein)

Das Versions-Tag muss immer DMARC1 sein und als erstes Tag in Ihrem Datensatz erscheinen. Es existieren keine anderen Versionen.

Beispiel:

v=DMARC1

Häufiger Fehler: Die Verwendung von etwas anderem als DMARC1 führt dazu, dass der Datensatz ignoriert wird.

p (Policy/Richtlinie)

Syntax: p=none|quarantine|reject
Zweck: Definiert die Aktion bei Domain-Alignment-Fehler
Erforderlich: Ja

Das Richtlinien-Tag bestimmt, was empfangende Server mit E-Mails tun sollen, die die DMARC-Authentifizierung nicht bestehen:

  • p=none: Nur Überwachung, keine Durchsetzungsmaßnahme
  • p=quarantine: Fehlgeschlagene E-Mails in Spam-/Junk-Ordner verschieben
  • p=reject: Fehlgeschlagene E-Mails vollständig ablehnen

Beispiele:

p=none         # Überwachungsphase
p=quarantine   # Sanfte Durchsetzung
p=reject       # Vollständige Durchsetzung

Best Practice: Beginnen Sie mit p=none zur Überwachung, gehen Sie schrittweise zu p=quarantine über und dann zu p=reject basierend auf der Analyse des legitimen Datenverkehrs.

III. Optionale Richtlinien-Tags

sp (Subdomain Policy/Subdomain-Richtlinie)

Syntax: sp=none|quarantine|reject
Zweck: Richtlinie für Subdomain-Nachrichten
Standard: Erbt den Wert der Hauptrichtlinie

Die Subdomain-Richtlinie ermöglicht eine unterschiedliche Behandlung von Nachrichten von Subdomains.

Beispiel:

v=DMARC1; p=quarantine; sp=reject

Diese Konfiguration verschiebt fehlgeschlagene Haupt-Domain-E-Mails in Quarantäne, lehnt jedoch fehlgeschlagene Subdomain-E-Mails ab.

pct (Percentage/Prozentsatz)

Syntax: pct=1-100
Zweck: Prozentsatz der Nachrichten, auf die die Richtlinie angewendet werden soll
Standard: 100

Ermöglicht eine schrittweise Richtlinieneinführung durch Angabe, auf welchen Prozentsatz fehlgeschlagener Nachrichten die Richtlinie angewendet werden soll.

Beispiele:

pct=25    # Richtlinie auf 25% der fehlgeschlagenen Nachrichten anwenden
pct=50    # Richtlinie auf 50% der fehlgeschlagenen Nachrichten anwenden
pct=100   # Richtlinie auf alle fehlgeschlagenen Nachrichten anwenden (Standard)

Anwendungsfall: Beim Übergang von p=none zu p=quarantine beginnen Sie mit pct=10 und erhöhen Sie schrittweise.

IV. Alignment-Tags

Vergleich der lockeren und strikten Ausrichtungsmodi für die DKIM- und SPF-Authentifizierung.

adkim (DKIM Alignment/DKIM-Ausrichtung)

Syntax: adkim=r|s
Zweck: DKIM-Identifier-Alignment-Modus
Standard: r (relaxed/locker)

  • adkim=r: Lockere Ausrichtung (Subdomain-Übereinstimmung erlaubt)
  • adkim=s: Strikte Ausrichtung (exakte Domain-Übereinstimmung erforderlich)

Beispiele:

adkim=r    # mail.example.com kann für example.com signieren
adkim=s    # Nur example.com kann für example.com signieren

aspf (SPF Alignment/SPF-Ausrichtung)

Syntax: aspf=r|s
Zweck: SPF-Identifier-Alignment-Modus
Standard: r (relaxed/locker)

  • aspf=r: Lockere Ausrichtung (Subdomain-Übereinstimmung erlaubt)
  • aspf=s: Strikte Ausrichtung (exakte Domain-Übereinstimmung erforderlich)

Beispiele:

aspf=r    # Return-Path: [email protected] besteht für From: [email protected]
aspf=s    # Return-Path muss exakt mit From-Domain übereinstimmen

V. Reporting-Tags

rua (Aggregate Reports/Aggregierte Berichte)

Syntax: rua=mailto:[email protected]
Zweck: E-Mail-Adresse für aggregierte Berichte
Format: Tägliche XML-Berichte mit Authentifizierungsstatistiken

Beispiele:

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

Mehrere Adressen: Trennen Sie mit Kommas für Redundanz.

ruf (Forensic Reports/Forensische Berichte)

Syntax: ruf=mailto:[email protected]
Zweck: E-Mail-Adresse für Fehlerberichte
Format: Einzelne Fehlermeldungen mit Nachrichtenbeispielen

Beispiele:

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

Datenschutzhinweis: Forensische Berichte enthalten Nachrichteninhalte und können Datenschutzimplikationen haben.

ri (Report Interval/Berichtsintervall)

Syntax: ri=sekunden
Zweck: Intervall für aggregierte Berichte
Standard: 86400 (24 Stunden)

Beispiele:

ri=3600     # Stündliche Berichte (nicht empfohlen)
ri=86400    # Tägliche Berichte (Standard)
ri=604800   # Wöchentliche Berichte

Einschränkung: Die meisten Empfänger ignorieren dieses Tag und senden unabhängig davon täglich Berichte.

fo (Forensic Options/Forensische Optionen)

Syntax: fo=0|1|d|s
Zweck: Bedingungen für die Generierung forensischer Berichte
Standard: 0

  • fo=0: Berichte generieren, wenn sowohl SPF als auch DKIM fehlschlagen
  • fo=1: Berichte generieren, wenn entweder SPF oder DKIM fehlschlägt
  • fo=d: Berichte generieren, wenn DKIM fehlschlägt
  • fo=s: Berichte generieren, wenn SPF fehlschlägt

Beispiele:

fo=1    # Jeden Authentifizierungsfehler melden
fo=d    # Nur DKIM-Fehler melden
fo=s    # Nur SPF-Fehler melden

VI. Erweiterte DMARC-Datensatz-Beispiele

Überwachungskonfiguration

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

Dieser Datensatz überwacht den gesamten Datenverkehr ohne Durchsetzung und generiert sowohl aggregierte als auch forensische Berichte.

Schrittweise Durchsetzung

v=DMARC1; p=quarantine; pct=25; sp=none; rua=mailto:[email protected]; adkim=r; aspf=r

Wendet Quarantäne-Richtlinie auf 25% der fehlgeschlagenen Haupt-Domain-Nachrichten an, während Subdomains überwacht werden.

Strikte Durchsetzung

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

Vollständige Durchsetzung mit strikter Ausrichtung für sowohl Hauptdomain als auch Subdomains.

Unternehmenskonfiguration

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

Vollständige Unternehmenseinrichtung mit mehreren Berichtzielen und gemischten Ausrichtungsrichtlinien.

VII. Häufige Syntaxfehler und Validierung

Formatierungsfehler

Fehlende Semikolons:

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

Falsche Tag-Reihenfolge (v muss zuerst stehen):

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

Ungültige Richtlinienwerte:

❌ p=block
✅ p=reject

❌ p=spam
✅ p=quarantine

E-Mail-Adress-Validierung

Fehlerhafte Adressen:

❌ [email protected]          # Fehlendes mailto:
✅ rua=mailto:[email protected]

❌ rua=mailto:test@domain         # Ungültige Domain
✅ rua=mailto:[email protected]

Prozentwerte

Außerhalb des Bereichs:

❌ pct=150    # Über 100
✅ pct=100

❌ pct=0      # Null nicht erlaubt
✅ pct=1

VIII. DMARC-Datensatz-Validierungstechniken

DNS-Lookup-Verifizierung

dig TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Online-Validierungstools

Verwenden Sie DMARC-Datensatz-Checker zur Validierung der Syntax und Erkennung häufiger Fehler. Diese Tools überprüfen:

  • Ordnungsgemäße Tag-Formatierung
  • Gültige Richtlinienwerte
  • E-Mail-Adress-Syntax
  • DNS-Propagierungsstatus

Manuelle Validierungscheckliste

  1. Versions-Tag: Überprüfen Sie, dass v=DMARC1 zuerst steht
  2. Richtlinien-Tag: Bestätigen Sie, dass p= einen gültigen Wert hat
  3. Semikolons: Prüfen Sie, dass alle Tags durch Semikolons getrennt sind
  4. E-Mail-Format: Validieren Sie das mailto:-Präfix in Berichtsadressen
  5. Zahlenbereiche: Überprüfen Sie, dass pct= zwischen 1-100 liegt, ri= eine positive Ganzzahl ist
  6. Ausrichtungswerte: Bestätigen Sie, dass adkim= und aspf= nur r oder s verwenden

Testen der DMARC-Implementierung

Nach Veröffentlichung Ihres Datensatzes überwachen Sie die Authentifizierungsergebnisse durch:

  • DMARC-Aggregationsberichte
  • E-Mail-Zustellungsprotokolle
  • Drittanbieter-Überwachungsdienste

Skysnag Protect vereinfacht die DMARC-Implementierung durch automatisierte Datensatzgenerierung, Validierung und kontinuierliche Überwachung, um sicherzustellen, dass Ihre E-Mail-Authentifizierungsrichtlinien korrekt funktionieren.

IX. Erweiterte Konfigurationsüberlegungen

Multi-Domain-Organisationen

Für Organisationen, die mehrere Domains verwalten, berücksichtigen Sie:

  • Zentralisierte Berichtsadressen
  • Konsistente Richtliniendurchsetzungsstufen
  • Subdomain-Richtlinienvererbung

E-Mail-Service-Provider-Integration

Bei Verwendung von Drittanbieter-E-Mail-Diensten:

  • Überprüfen Sie die DKIM-Signierungsausrichtung
  • Koordinieren Sie SPF-Datensatz-Includes
  • Testen Sie die Auswirkungen der Richtliniendurchsetzung

Planung der Vorfallreaktion

Bereiten Sie sich auf DMARC-bezogene Zustellungsprobleme vor:

  • Überwachen Sie Trends in Aggregationsberichten
  • Etablieren Sie Verfahren für Richtlinien-Rollbacks
  • Pflegen Sie ein Inventar legitimer Absender

X. Wichtigste Erkenntnisse

Die DMARC-Datensatz-Syntax erfordert präzise Formatierung und sorgfältige Berücksichtigung der Auswirkungen jedes Tags auf die E-Mail-Zustellung. Beginnen Sie mit Überwachungsrichtlinien mit p=none, setzen Sie schrittweise mit p=quarantine und p=reject durch, während Sie Aggregationsberichte analysieren. Konfigurieren Sie geeignete Ausrichtungsmodi basierend auf Ihrer E-Mail-Infrastruktur und validieren Sie Datensätze immer vor der Bereitstellung. Denken Sie daran, dass die DMARC-Effektivität von der ordnungsgemäßen SPF- und DKIM-Implementierung sowie der genauen Richtlinienkonfiguration abhängt.

Das Verständnis dieser Syntaxregeln und Validierungstechniken ermöglicht es Organisationen, robuste E-Mail-Authentifizierung zu implementieren, die vor Spoofing schützt und gleichzeitig die Zustellung legitimer E-Mails aufrechterhält. Regelmäßige Überwachung und Richtlinienverfeinerung gewährleisten fortlaufende Effektivität, während sich die E-Mail-Infrastruktur weiterentwickelt.