DMARC (Domain-based Message Authentication, Reporting and Conformance) Records bilden das Fundament der E-Mail-Authentifizierung und schützen Organisationen vor ausgeklügelten Phishing- und Spoofing-Angriffen, die Unternehmen jährlich über 12 Milliarden Dollar kosten. Das Verständnis der präzisen Syntax und Konfigurationsoptionen ist essentiell für die Implementierung effektiver E-Mail-Sicherheitsrichtlinien, die Ihre Domain-Reputation schützen.

Ein ordnungsgemäß konfigurierter DMARC-Record fungiert als Richtlinien-Anweisungssatz, der in Ihrem DNS veröffentlicht wird und empfangenden Mail-Servern mitteilt, wie sie mit E-Mails umgehen sollen, die Authentifizierungsprüfungen nicht bestehen. Diese umfassende Anleitung erläutert jeden Bestandteil der DMARC-Syntax und bietet die technische Tiefe, die für die Konfiguration robuster E-Mail-Sicherheit erforderlich ist.

Verständnis der DMARC-Record-Struktur

DMARC-Records folgen einem spezifischen Tag-Wert-Format, das als TXT-Records im DNS veröffentlicht wird. Der Record muss in der Subdomain _dmarc unter Ihrer primären Domain platziert werden, wodurch der vollständige DNS-Eintrag _dmarc.ihredomain.com entsteht.

Grundlegendes DMARC-Record-Format

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

Jeder DMARC-Record beginnt mit dem Versions-Tag und enthält Richtlinien-Anweisungen. Das Semikolon trennt jedes Tag-Wert-Paar, und Leerzeichen nach Semikola sind optional, aber zur besseren Lesbarkeit empfohlen.

Erforderliche vs. optionale Tags

DMARC-Records enthalten sowohl obligatorische als auch optionale Tags:

Erforderliche Tags:

• v (Version)
• p (Richtlinie)

Optionale Tags:

• rua (Aggregierte Berichte URI)
• ruf (Forensische Berichte URI)
• fo (Forensische Optionen)
• aspf (ASPF-Alignment-Modus)
• adkim (ADKIM-Alignment-Modus)
• pct (Prozentsatz)
• rf (Berichtsformat)
• ri (Berichtsintervall)
• sp (Subdomain-Richtlinie)

Vollständige DMARC-Tag-Referenz

Versions-Tag (v)

Syntax: v=DMARC1

Das Versions-Tag identifiziert die DMARC-Spezifikationsversion und muss immer das erste Tag im Record sein. Derzeit ist DMARC1 der einzige gültige Wert.

Beispiel:

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

Validierung: Das Versions-Tag ist groß-/kleinschreibungsempfindlich und muss genau wie gezeigt erscheinen. Jede Abweichung führt dazu, dass der gesamte DMARC-Record ungültig wird.

Richtlinien-Tag (p)

Syntax: p=none|quarantine|reject

Das Richtlinien-Tag spezifiziert die Aktion, die empfangende Mail-Server durchführen sollen, wenn Nachrichten DMARC-Alignment-Prüfungen nicht bestehen.

Richtlinien-Optionen:

• none: Überwachungsmodus, keine Aktion bei fehlgeschlagenen Nachrichten
• quarantine: Fehlgeschlagene Nachrichten werden in Spam-/Junk-Ordner zugestellt
• reject: Fehlgeschlagene Nachrichten werden auf SMTP-Ebene abgelehnt

Beispiele:

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

Best Practice: Beginnen Sie mit p=none zur Überwachung der Traffic-Muster, wechseln Sie dann schrittweise zu p=quarantine und schließlich zu p=reject für maximalen Schutz.

Aggregierte Berichte URI (rua)

Syntax: rua=mailto:[email protected] oder rua=https://example.com/dmarc

Die aggregierten Berichte URI spezifiziert, wohin XML-Aggregatberichte gesendet werden sollen. Diese Berichte enthalten statistische Daten über Nachrichten-Authentifizierungsergebnisse.

Beispiele:

rua=mailto:[email protected]
rua=mailto:[email protected],mailto:[email protected]
rua=https://dmarc-collector.example.com/reports

Mehrere Empfänger: Trennen Sie mehrere URIs mit Kommas. Jeder Empfänger erhält Kopien der Aggregatberichte.

Externe Empfänger: Beim Senden von Berichten an externe Domains muss die empfangende Domain einen DMARC-Record veröffentlichen, der die Annahme von Berichten autorisiert.

Forensische Berichte URI (ruf)

Syntax: ruf=mailto:[email protected]

Forensische Berichte liefern detaillierte Informationen über individuelle Nachrichtenfehler, einschließlich Nachrichten-Headers und Authentifizierungsergebnissen.

Beispiele:

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

Datenschutzaspekte: Forensische Berichte enthalten sensible Nachrichteninhalte. Stellen Sie ordnungsgemäße Datenbehandlung und Datenschutz-Compliance sicher, wenn Sie dieses Tag konfigurieren.

Forensische Optionen (fo)

Syntax: fo=0|1|d|s

Das forensische Optionen-Tag kontrolliert, wann forensische Berichte für fehlgeschlagene Nachrichten generiert werden.

Optionen:

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

Beispiele:

fo=1; ruf=mailto:[email protected]
fo=d:s; ruf=mailto:[email protected]

Alignment-Modus-Tags

SPF-Alignment-Modus (aspf)

Syntax: aspf=r|s

Kontrolliert die SPF-Alignment-Prüfungsstrenge:

• r: Relaxed-Modus (Standard) – erlaubt Subdomain-Alignment
• s: Strict-Modus – erfordert exakte Domain-Übereinstimmung

DKIM-Alignment-Modus (adkim)

Syntax: adkim=r|s

Kontrolliert die DKIM-Alignment-Prüfungsstrenge:

• r: Relaxed-Modus (Standard) – erlaubt Subdomain-Alignment
• s: Strict-Modus – erfordert exakte Domain-Übereinstimmung

Beispiele:

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

Prozentsatz-Tag (pct)

Syntax: pct=1-100

Spezifiziert den Prozentsatz der Nachrichten, die der Richtliniendurchsetzung unterliegen. Nützlich für schrittweise Richtlinien-Bereitstellung.

Beispiele:

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

Standard: Wenn weggelassen, standardmäßig 100 (alle Nachrichten unterliegen der Richtlinie).

Berichtsformat (rf)

Syntax: rf=afrf|iodef

Spezifiziert das Format für forensische Berichte:

• afrf: Authentication Failure Reporting Format (Standard)
• iodef: Incident Object Description Exchange Format

Berichtsintervall (ri)

Syntax: ri=sekunden

Spezifiziert das Intervall zwischen Aggregatberichten in Sekunden. Die meisten empfangenden Systeme ignorieren dieses Tag und senden tägliche Berichte.

Beispiel:

ri=86400  // 24 Stunden in Sekunden

Subdomain-Richtlinie (sp)

Syntax: sp=none|quarantine|reject

Definiert die Richtlinie für Subdomains, wenn kein expliziter DMARC-Record für die Subdomain existiert.

Beispiele:

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

Erweiterte Konfigurationsbeispiele

Grundlegende Überwachungskonfiguration

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

Strikte Richtlinie mit schrittweiser Einführung

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

Maximale Schutzkonfiguration

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

Unternehmens-Multi-Empfänger-Setup

v=DMARC1; p=quarantine; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]; pct=50; fo=1

Validierungs- und Test-Tools

DNS-Abfrage-Validierung

Verwenden Sie diese Befehle, um die DMARC-Record-Veröffentlichung zu überprüfen:

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

Syntax-Validierung

Tools wie Skysnag Protect bieten umfassende DMARC-Record-Validierung, prüfen Syntax-Fehler, Richtlinien-Konflikte und Konfigurationsempfehlungen.

Häufige Validierungsfehler

1. Fehlendes Versions-Tag: Record muss mit v=DMARC1 beginnen
2. Ungültige Richtlinien-Werte: Nur none, quarantine und reject sind gültig
3. Fehlerhaft formatierte E-Mail-Adressen: URIs müssen dem korrekten mailto:-Format folgen
4. Widersprüchliche Alignment-Modi: Stellen Sie Konsistenz zwischen strict- und relaxed-Modi sicher
5. Ungültige Prozentsatz-Werte: Müssen ganze Zahlen zwischen 1-100 sein

Sonderfälle und Fehlerbehebung

Mehrere DMARC-Records

Nur ein DMARC-Record pro Domain ist erlaubt. Mehrere Records führen zu DMARC-Fehlschlag für alle Nachrichten.

Subdomain-Vererbung

Subdomains ohne explizite DMARC-Records erben die Richtlinie der Organisations-Domain oder den sp-Tag-Wert, falls spezifiziert.

Record-Längenbeschränkungen

DNS-TXT-Records haben eine 255-Zeichen-Grenze pro String. Lange DMARC-Records können String-Verkettung erfordern:

"v=DMARC1; p=quarantine; rua=mailto:sehr-lange-email-adresse@" "beispiel-domain-mit-langem-namen.com; fo=1"

Berichtszustellungsprobleme

Externe Berichtsziele erfordern ordnungsgemäße DNS-Autorisierung. Überprüfen Sie, ob die empfangende Domain Berichte von Ihrer Domain akzeptiert.

Implementierungs-Best-Practices

Schrittweise Bereitstellungsstrategie

1. Phase 1: Bereitstellung von p=none mit Berichterstattung zur Baseline-Erstellung
2. Phase 2: Wechsel zu p=quarantine mit niedrigem Prozentsatz
3. Phase 3: Schrittweise Prozentsatz-Erhöhung während der Berichtsüberwachung
4. Phase 4: Implementierung von p=reject für vollständigen Schutz

Überwachung und Wartung

Regelmäßige DMARC-Berichtsanalyse deckt Authentifizierungsprobleme, unbefugte Sendequellen und potenzielle Sicherheitsbedrohungen auf. Tools wie Skysnag Protect automatisieren die Berichtsverarbeitung und bieten umsetzbare Erkenntnisse für Richtlinienoptimierung.

Integration mit SPF und DKIM

DMARC erfordert, dass entweder SPF oder DKIM-Authentifizierung mit ordnungsgemäßem Alignment bestanden wird. Stellen Sie sicher, dass beide Protokolle korrekt konfiguriert sind, bevor Sie strikte DMARC-Richtlinien implementieren.

Wichtige Erkenntnisse

Die DMARC-Record-Syntax folgt einem präzisen Tag-Wert-Format mit spezifischen Validierungsanforderungen. Beginnen Sie mit Überwachungsrichtlinien und erhöhen Sie schrittweise die Schutzstufen, während Sie aggregierte Berichte analysieren. Eine korrekte Konfiguration des Alignment-Modus sowie prozentbasierte Rollouts gewährleisten eine reibungslose Implementierung ohne Störung legitimer E-Mails.

Das Verständnis jedes DMARC-Tags ermöglicht es Organisationen, ausgefeilte E-Mail-Authentifizierungsrichtlinien zu implementieren, die auf ihre spezifischen Sicherheitsanforderungen zugeschnitten sind. Regelmäßige Validierung und Überwachung stellen einen kontinuierlichen Schutz vor sich entwickelnden E-Mail-Bedrohungen sicher.

Für ein umfassendes DMARC-Management und eine automatisierte Richtlinienoptimierung entdecken Sie Skysnag Protect, um die Implementierung Ihrer E-Mail-Authentifizierung zu vereinfachen.