DMARC im Detail
Vollständiger DMARC-Leitfaden: Policies, Alignment-Modi, Subdomain-Behandlung und der Weg von Monitoring zu Enforcement.
Was ist DMARC?
DMARC (Domain-based Message Authentication, Reporting & Conformance) ist das zentrale Protokoll, das SPF und DKIM mit einer domainweiten Policy verbindet. Definiert in RFC 7489, schließt DMARC eine kritische Lücke: SPF und DKIM allein schützen nicht die sichtbare „From:"-Adresse, die Nutzer sehen.
DMARC fügt drei essentielle Fähigkeiten hinzu:
- Alignment: Stellt sicher, dass die Domain im sichtbaren From:-Header mit der durch SPF und/oder DKIM authentifizierten Domain übereinstimmt.
- Policy: Teilt empfangenden Servern mit, was mit E-Mails geschehen soll, die die Authentifizierung nicht bestehen (none/quarantine/reject).
- Reporting: Bietet Transparenz darüber, wer E-Mails unter Verwendung Ihrer Domain versendet, über Aggregate und Forensic Reports.
DMARC Record Syntax
DMARC wird als DNS TXT Record unter _dmarc.example.com veröffentlicht.
Vollständige Tag-Referenz
| Tag | Erforderlich | Beschreibung | Werte | Standard |
|---|---|---|---|---|
v | Ja | Version | DMARC1 | — |
p | Ja | Policy für die Domain | none, quarantine, reject | — |
sp | Nein | Policy für Subdomains | none, quarantine, reject | Wie p |
rua | Nein* | Aggregate Report Empfänger | mailto:dmarc@example.com | Keiner |
ruf | Nein | Forensic Report Empfänger | mailto:forensic@example.com | Keiner |
adkim | Nein | DKIM Alignment Modus | r (relaxed), s (strict) | r |
aspf | Nein | SPF Alignment Modus | r (relaxed), s (strict) | r |
pct | Nein | Prozentsatz der E-Mails, auf die die Policy angewendet wird | 0-100 | 100 |
ri | Nein | Reporting-Intervall (Sekunden) | z.B. 86400 | 86400 (24h) |
fo | Nein | Forensic Report Optionen | 0, 1, d, s | 0 |
* rua ist technisch optional, aber dringend empfohlen — ohne rua erhalten Sie keine Einblicke.
Beispiel-Records
# Monitoring-Modus (hier starten)
v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com
# Quarantine-Modus (nächster Schritt)
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; adkim=r; aspf=r
# Vollständiges Enforcement
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100DMARC Alignment erklärt
Alignment ist das wichtigste Konzept von DMARC. Es stellt sicher, dass die durch SPF oder DKIM authentifizierte Domain mit der Domain im sichtbaren „From:"-Header übereinstimmt.
Relaxed vs. Strict Alignment
| Modus | SPF Alignment | DKIM Alignment |
|---|---|---|
Relaxed (Standard, adkim=r/aspf=r) |
Return-Path-Domain und From:-Domain müssen dieselbe Organizational Domain teilen.bounce.example.com aligned mit example.com ✅ |
DKIM d=-Domain und From:-Domain müssen dieselbe Organizational Domain teilen.d=mail.example.com aligned mit from@example.com ✅ |
Strict (adkim=s/aspf=s) |
Return-Path-Domain muss exakt übereinstimmen mit der From:-Domain.bounce.example.com aligned NICHT mit example.com ❌ |
DKIM d=-Domain muss exakt übereinstimmen mit der From:-Domain.d=mail.example.com aligned NICHT mit from@example.com ❌ |
Empfehlung: Beginnen Sie mit Relaxed Alignment während der Monitoring-Phase. Wechseln Sie erst zu Strict Alignment, wenn Sie sicher sind, dass alle legitimen Absender korrekt konfiguriert sind.
Alignment-Beispiele
# E-Mail From: user@example.com
# SPF Relaxed Alignment
Return-Path: bounce@example.com → Aligned ✅ (gleiche Organizational Domain)
Return-Path: bounce@mail.example.com → Aligned ✅ (gleiche Organizational Domain)
Return-Path: bounce@other.com → NICHT Aligned ❌
# DKIM Relaxed Alignment
DKIM d=example.com → Aligned ✅
DKIM d=mx.example.com → Aligned ✅ (gleiche Organizational Domain)
DKIM d=google.com → NICHT Aligned ❌
# Damit DMARC BESTEHT: Mindestens EINS von SPF oder DKIM muss BESTEHEN und ALIGNED seinDMARC Policies: Der Weg zum Enforcement
Die DMARC Policy (p=) teilt empfangenden Servern mit, was mit E-Mails geschehen soll, die die Authentifizierung nicht bestehen. Der empfohlene Ansatz ist ein schrittweiser Rollout:
Phase 1: Monitoring (p=none)
- Keine E-Mails werden blockiert oder in Quarantäne gestellt
- Aggregate Reports werden gesammelt, um Ihr E-Mail-Ökosystem zu verstehen
- Nutzen Sie diese Phase, um alle legitimen Absender zu identifizieren und Authentifizierungsprobleme zu beheben
- Dauer: Mindestens 2-4 Wochen, bei komplexen Organisationen oft 2-3 Monate
Phase 2: Quarantine (p=quarantine)
- Fehlschlagende E-Mails werden als verdächtig markiert (typischerweise in den Spam-/Junk-Ordner verschoben)
- Beginnen Sie mit
pct=10, um die Policy nur auf 10 % der fehlschlagenden E-Mails anzuwenden - Schrittweise erhöhen: 10 % → 25 % → 50 % → 75 % → 100 %
- Überwachen Sie Reports in jeder Phase auf betroffene legitime E-Mails
Phase 3: Reject (p=reject)
- Fehlschlagende E-Mails werden lautlos verworfen — sie erreichen den Empfänger nie
- Dies ist der stärkste Schutz gegen Spoofing
- Auch hier mit einem niedrigen
pctstarten und schrittweise erhöhen - Stellen Sie sicher, dass ALLE legitimen Absender korrekt authentifiziert sind, bevor Sie auf 100 % gehen
Kritisch: Ein direkter Sprung zu
p=reject ohne ordnungsgemäße Vorbereitung kann dazu führen, dass legitime E-Mails lautlos verworfen werden. Befolgen Sie immer den phasenweisen Ansatz und überwachen Sie Reports sorgfältig.