Was ist DMARC?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ist ein in RFC 7489 definiertes E-Mail-Authentifizierungsprotokoll, das auf SPF und DKIM aufbaut. Es ermöglicht Domain-Inhabern, eine Richtlinie zu veröffentlichen, die empfangenden Mailservern mitteilt, was mit Nachrichten zu tun ist, die die SPF- und DKIM-Authentifizierung nicht bestehen – entweder überwachen (p=none), in Quarantäne verschieben (p=quarantine) oder ablehnen (p=reject). DMARC führt zudem das Konzept des Alignments ein und verlangt, dass die von SPF oder DKIM authentifizierte Domain mit der Domain im sichtbaren From-Header übereinstimmt. Darüber hinaus ermöglicht DMARC aggregierte und forensische Berichte und gibt Domain-Inhabern Einblick darüber, wer in ihrem Namen E-Mails versendet.
Dieser Leitfaden ist Teil unseres vollständigen Leitfadens zu DMARC. Verwandt: der DMARC-Record und die DMARC-Richtlinie.
DMARC – Domain-based Message Authentication, Reporting, and Conformance – ist das Protokoll, das SPF und DKIM zu einem einheitlichen E-Mail-Authentifizierungs-Framework verbindet. Ohne DMARC arbeiten SPF und DKIM unabhängig voneinander, und es gibt keine standardisierte Möglichkeit, empfangenden Servern mitzuteilen, was bei einer fehlgeschlagenen Authentifizierung zu tun ist, oder Berichte über die Authentifizierungsergebnisse aus dem gesamten Internet zu erhalten.
RFC 7489 definiert DMARC als skalierbaren Mechanismus, mit dem eine mail-versendende Organisation Richtlinien und Präferenzen auf Domain-Ebene für die Validierung, Behandlung und Berichterstattung von Nachrichten ausdrücken kann. Empfangende Mailserver können diese Richtlinien nutzen, um Entscheidungen über die Mail-Behandlung zu verbessern.
DMARC löst drei Probleme, die SPF und DKIM allein nicht lösen können:
- Richtliniendurchsetzung – Es teilt empfangenden Servern mit, ob Nachrichten, die die Authentifizierung nicht bestehen, abgelehnt, in Quarantäne verschoben oder akzeptiert werden sollen
- Alignment – Es verlangt, dass die von SPF oder DKIM authentifizierte Domain mit der Domain im sichtbaren From-Header übereinstimmt, und schließt so die Lücke, in der SPF oder DKIM auf einer anderen Domain bestehen könnten als der, die der Empfänger sieht
- Berichterstattung – Es stellt einen standardisierten Berichtsmechanismus bereit, damit Domain-Inhaber genau sehen können, wer mit ihrer Domain E-Mails versendet – und ob diese Nachrichten die Authentifizierung bestehen oder nicht
Wie DMARC funktioniert
Die DMARC-Auswertung erfolgt, nachdem SPF und DKIM bereits geprüft wurden. Der Ablauf ist:
- Der empfangende Server prüft SPF (ist die sendende IP durch den SPF-Record der Domain autorisiert?)
- Der empfangende Server prüft DKIM (trägt die Nachricht eine gültige DKIM-Signatur?)
- Der empfangende Server prüft das DMARC-Alignment (stimmt die von SPF oder DKIM authentifizierte Domain mit der From-Header-Domain überein?)
- Wenn weder SPF noch DKIM mit Alignment bestehen, wendet der empfangende Server die DMARC-Richtlinie an
Die zentrale Erkenntnis ist, dass DMARC keine eigene Authentifizierungsprüfung durchführt. Es wertet die Ergebnisse von SPF und DKIM aus und fügt darüber hinaus die Alignment-Verifizierung und die Richtliniendurchsetzung hinzu.
Der DMARC-DNS-Record
Ein DMARC-Record ist ein DNS-TXT-Record, der unter _dmarc.yourdomain.com veröffentlicht wird. Hier ein typisches Beispiel:
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=r; aspf=r; pct=100"
| Tag | Bedeutung | Werte |
|---|---|---|
v=DMARC1 | Version (erforderlich) | Immer DMARC1 |
p= | Richtlinie (erforderlich) | none, quarantine, reject |
rua= | Empfänger aggregierter Berichte | mailto: URI |
ruf= | Empfänger forensischer Berichte | mailto: URI |
adkim= | DKIM-Alignment-Modus | r (relaxed) oder s (strict) |
aspf= | SPF-Alignment-Modus | r (relaxed) oder s (strict) |
pct= | Prozentsatz der Nachrichten, auf die die Richtlinie angewendet wird | 1-100 (Standard 100) |
sp= | Subdomain-Richtlinie | none, quarantine, reject |
fo= | Optionen für forensische Berichte | 0, 1, d, s |
Sie können den DMARC-Record jeder Domain mit dem DMARC Checker überprüfen.
DMARC-Richtlinien: none, quarantine, reject
Das p=-Tag ist das wichtigste Element eines DMARC-Records. Es teilt empfangenden Servern mit, was mit Nachrichten zu tun ist, die sowohl das SPF- als auch das DKIM-Alignment nicht bestehen.
p=none (nur Überwachung)
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Dies ist der Ausgangspunkt für eine DMARC-Bereitstellung. Es weist empfangende Server an, bei fehlgeschlagenen Nachrichten keine Maßnahmen zu ergreifen – sie werden normal zugestellt. Der Zweck von p=none besteht darin, aggregierte Berichte zu sammeln, damit Sie sehen können:
- Welche Dienste in Ihrem Namen E-Mails versenden
- Ob diese Dienste SPF und DKIM bestehen
- Ob das Alignment korrekt konfiguriert ist
- Ob unautorisierte Absender Ihre Domain verwenden
Verwenden Sie p=none mindestens 2–4 Wochen lang, bevor Sie zu einer strengeren Richtlinie übergehen. So haben Sie Zeit, legitime Versandquellen zu identifizieren und zu korrigieren, die nicht ordnungsgemäß authentifiziert sind.
p=quarantine
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=25
Quarantine weist empfangende Server an, fehlgeschlagene Nachrichten als verdächtig zu behandeln. In der Praxis bedeutet dies in der Regel, sie in den Spam- oder Junk-Ordner zu leiten. Das pct=-Tag ermöglicht es Ihnen, die Quarantine-Richtlinie nur auf einen Prozentsatz der fehlgeschlagenen Nachrichten anzuwenden, was eine schrittweise Einführung erlaubt.
Eine gängige Bereitstellungsstrategie lautet:
- Beginnen Sie mit
p=quarantine; pct=10– Wenden Sie Quarantine auf 10 % der fehlgeschlagenen Nachrichten an - Überwachen Sie die Berichte auf Fehlalarme
- Erhöhen Sie auf
pct=25, dannpct=50, dannpct=100 - Wechseln Sie zu
p=reject, sobald Sie sicher sind
p=reject
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
Reject weist empfangende Server an, Nachrichten, die sowohl das SPF- als auch das DKIM-Alignment nicht bestehen, vollständig zu blockieren. Die Nachricht wird überhaupt nicht zugestellt – der Absender erhält eine Bounce-Nachricht.
p=reject bietet den stärksten Schutz gegen Domain-Spoofing, muss aber sorgfältig eingesetzt werden. Wenn eine legitime Versandquelle nicht ordnungsgemäß authentifiziert ist, werden ihre Nachrichten abgelehnt. Eine starke Durchsetzung wird zunehmend wichtiger, da KI-Phishing-Bedrohungen immer raffinierter werden.
Ausführlicher Leitfaden: From Monitoring to Enforcement: Building a Scalable DMARC Strategy
DMARC-Alignment: Das fehlende Puzzleteil
Alignment ist es, was DMARC grundlegend von der unabhängigen Ausführung von SPF und DKIM unterscheidet. Ohne Alignment könnte ein Angreifer SPF und DKIM für seine eigene Domain einrichten und diese Domain dann im Return-Path oder in der DKIM-Signatur verwenden, während er Ihre Domain im sichtbaren From-Header spooft. Der Empfänger würde Ihre Domain sehen, aber die Authentifizierung würde tatsächlich die Domain des Angreifers prüfen.
DMARC schließt diese Lücke, indem es verlangt, dass mindestens eine der folgenden Bedingungen erfüllt ist:
- SPF-Alignment – Die Domain im Return-Path (Envelope-Absender) stimmt mit der Domain im From-Header überein
- DKIM-Alignment – Die Domain in der DKIM-Signatur (
d=-Wert) stimmt mit der Domain im From-Header überein
Relaxed vs. Strict Alignment
DMARC unterstützt für jedes Protokoll zwei Alignment-Modi:
Relaxed Alignment (Standard): Die organisatorische Domain muss übereinstimmen, aber Subdomains sind erlaubt.
- From:
user@example.commit Return-Path:bounce@mail.example.com– Besteht Relaxed-SPF-Alignment - From:
user@example.commitd=mail.example.com– Besteht Relaxed-DKIM-Alignment
Strict Alignment: Die Domains müssen exakt übereinstimmen.
- From:
user@example.commit Return-Path:bounce@mail.example.com– Besteht Strict-SPF-Alignment nicht - From:
user@example.commitd=example.com– Besteht Strict-DKIM-Alignment
Die meisten Organisationen sollten mit Relaxed Alignment beginnen. Strict Alignment ist für Umgebungen mit hohen Sicherheitsanforderungen geeignet, in denen die Kontrolle über Subdomains entscheidend ist.
Ausführliche Leitfäden:
- Are Your SPF and DKIM Identifiers Aligned?
- A Simple Explanation of DMARC Compliance Laws
- Fixing the SPF Alignment Failed Error
DMARC-Berichterstattung: Einblick in Ihr E-Mail-Ökosystem
Eine der wertvollsten Funktionen von DMARC ist sein Berichtsmechanismus. DMARC-Berichte geben Ihnen Einblick in jede E-Mail, die mit Ihrer Domain versendet wird – ob Sie sie autorisiert haben oder nicht.
Aggregierte Berichte (rua)
Aggregierte Berichte sind XML-Dokumente, die von empfangenden Mailservern (in der Regel täglich) gesendet werden und die Authentifizierungsergebnisse für Ihre Domain zusammenfassen. Sie enthalten:
- Quell-IP-Adressen, die E-Mails mit Ihrer Domain versendet haben
- Die Anzahl der Nachrichten von jeder Quelle
- SPF- und DKIM-Pass/Fail-Ergebnisse für jede Quelle
- DMARC-Alignment-Ergebnisse
- Die auf fehlgeschlagene Nachrichten angewendete DMARC-Richtlinie
Aggregierte Berichte sind das wichtigste Werkzeug für:
- Das Aufdecken unautorisierter Absender, die Ihre Domain verwenden
- Das Identifizieren legitimer Dienste, die nicht ordnungsgemäß authentifiziert sind
- Das Überwachen der Wirksamkeit Ihrer DMARC-Richtlinie im Zeitverlauf
- Das Vorbereiten von Richtlinien-Upgrades (von
nonezuquarantinezureject)
Rohe aggregierte Berichte liegen als XML vor und sind manuell schwer zu lesen. Ein speziell entwickeltes DMARC-Reporting-Tool wie DMARC Report analysiert diese Berichte in menschenlesbare Dashboards und zeigt Ihnen genau, welche Quellen die Authentifizierung bestehen oder nicht. DMARC Report ist DuoCircles ergänzendes Produkt, das speziell für diesen Zweck entwickelt wurde – es verarbeitet Ihre aggregierten Berichte und liefert umsetzbare Erkenntnisse, Trendanalysen und Benachrichtigungen.
Ausführlicher Leitfaden: How to Utilize DMARC Reports to Resolve SPF Errors
Forensische Berichte (ruf)
Forensische Berichte (auch Failure-Reports genannt) werden nahezu in Echtzeit für einzelne Nachrichten gesendet, die DMARC nicht bestehen. Sie enthalten detaillierte Informationen über die konkrete Nachricht, einschließlich Header und manchmal Teile des Nachrichteninhalts.
Forensische Berichte sind nützlich für:
- Das Untersuchen konkreter Spoofing-Vorfälle
- Das Debuggen von Authentifizierungsfehlern für einzelne Nachrichten
- Das Identifizieren des genauen Fehlerpunkts in der Authentifizierungskette
Datenschutzhinweis: Viele empfangende Server senden aus Datenschutzgründen keine forensischen Berichte, und einige schwärzen personenbezogene Informationen aus den Berichten, die sie senden. Verlassen Sie sich nicht auf forensische Berichte als einzige Quelle für DMARC-Daten.
Das fo=-Tag steuert, wann forensische Berichte erzeugt werden:
| Wert | Bedeutung |
|---|---|
fo=0 | Bericht, wenn sowohl SPF als auch DKIM fehlschlagen (Standard) |
fo=1 | Bericht, wenn entweder SPF oder DKIM fehlschlägt |
fo=d | Bericht, wenn DKIM fehlschlägt |
fo=s | Bericht, wenn SPF fehlschlägt |
DMARC und Anti-Spam: Unterschiedliche Probleme
Ein weit verbreitetes Missverständnis ist, dass DMARC ein Anti-Spam-Tool sei. Das ist es nicht. DMARC authentifiziert die Domain-Identität – es sagt Ihnen, ob der Absender derjenige ist, der er vorgibt zu sein. Es bewertet den Nachrichteninhalt nicht auf Spam-Merkmale.
Eine E-Mail kann DMARC bestehen und trotzdem Spam sein (wenn der Absender authentifiziert ist, aber unerwünschte Inhalte sendet). Umgekehrt kann eine legitime E-Mail DMARC nicht bestehen (wenn die Authentifizierung falsch konfiguriert ist). DMARC und Anti-Spam-Filter arbeiten auf unterschiedlichen Ebenen und ergänzen sich.
Ausführlicher Leitfaden: DMARC and Anti-Spam Aren’t the Same!
DMARC bereitstellen: Eine Schritt-für-Schritt-Strategie
Die DMARC-Bereitstellung sollte einem phasenweisen Ansatz folgen, um die Zustellung legitimer E-Mails nicht zu stören.
Phase 1: Vorbereitung
- Prüfen Sie Ihre Versandquellen – Dokumentieren Sie jeden Dienst, Server und jede Plattform, die E-Mails mit Ihrer Domain versendet
- Konfigurieren Sie SPF – Stellen Sie sicher, dass Ihr SPF-Record alle autorisierten Absender enthält
- Konfigurieren Sie DKIM – Richten Sie DKIM-Signierung für alle Versandplattformen ein
- Verifizieren Sie das Alignment – Bestätigen Sie, dass die SPF- und DKIM-Domains mit Ihrer From-Header-Domain übereinstimmen
Phase 2: Überwachen (p=none)
- Veröffentlichen Sie einen DMARC-Record mit
p=noneund einerrua=-Adresse für aggregierte Berichte - Richten Sie einen DMARC-Report-Prozessor (wie DMARC Report) ein, um eingehende Berichte zu analysieren
- Überwachen Sie die Berichte 2–4 Wochen lang
- Identifizieren und korrigieren Sie legitime Quellen, die die Authentifizierung oder das Alignment nicht bestehen
Phase 3: Quarantine
- Aktualisieren Sie auf
p=quarantine; pct=10, um einen kleinen Prozentsatz fehlgeschlagener Nachrichten in den Spam zu leiten - Überwachen Sie die Berichte auf Fehlalarme (legitime Mail, die in Quarantäne verschoben wird)
- Erhöhen Sie den
pct=-Wert schrittweise, während das Vertrauen wächst - Sobald Sie bei
pct=100ohne Fehlalarme sind, gehen Sie zu Phase 4 über
Phase 4: Reject
- Aktualisieren Sie auf
p=reject, um nicht authentifizierte Nachrichten vollständig zu blockieren - Überwachen Sie weiterhin die aggregierten Berichte auf neue Dienste oder Fehlkonfigurationen
- Pflegen Sie Ihre SPF- und DKIM-Konfigurationen, wenn sich Dienste im Laufe der Zeit ändern
Ausführliche Leitfäden:
- From Monitoring to Enforcement: Building a Scalable DMARC Strategy
- How Should You Implement DMARC as an MSP or Enterprise?
- Spotting Spoofed Emails with DMARC: A Guide
DMARC-Compliance-Anforderungen
DMARC wird zunehmend zu einer regulatorischen und branchenüblichen Anforderung, nicht nur zu einer Best Practice. Dasselbe gilt für SPF-Compliance, die der DMARC-Durchsetzung zugrunde liegt.
Anforderungen von Google und Yahoo (2024+)
Seit Februar 2024 verlangen Google und Yahoo DMARC-Authentifizierung für Massenversender (die mehr als 5.000 Nachrichten pro Tag an Gmail- oder Yahoo-Adressen senden). Domains ohne DMARC können eine verringerte Zustellbarkeit erfahren.
Ausführlicher Leitfaden: Major Email Service Providers Emphasize DMARC Deployment
PCI DSS 4.0
Der Payment Card Industry Data Security Standard (PCI DSS) Version 4.0 macht DMARC für Organisationen, die Zahlungskartendaten verarbeiten, verpflichtend, mit vollständiger Durchsetzung ab 2025.
Ausführlicher Leitfaden: DMARC to be Mandatory for PCI DSS Compliance by 2025
DSGVO und Datenschutz
DMARC-Aggregatberichte bieten Einblick in den E-Mail-Verkehr, der Organisationen helfen kann, die DSGVO-Anforderungen für Datenschutz und die Meldung von Datenschutzverletzungen zu erfüllen.
Ausführlicher Leitfaden: Implementing DMARC to Gain Visibility and Maintain GDPR Compliance
Regierungsanforderungen
Mehrere Regierungen haben DMARC für Regierungsdomains vorgeschrieben oder nachdrücklich empfohlen, darunter das Vereinigte Königreich (über das NCSC), Neuseeland und die Vereinigten Staaten (über BOD 18-01).
Ausführliche Leitfäden:
- The New Zealand Government’s New DMARC Requirements
- Efficient DMARC Tools Needed After UK NCSC Changes
DORA (Digital Operational Resilience Act)
Die DORA-Verordnung der EU überschneidet sich mit DMARC-Anforderungen für Finanzinstitute.
Ausführlicher Leitfaden: The Point Where DORA and DMARC Intersect
Häufige DMARC-Fehler und Fehlerbehebung
554 5.7.5 Permanent Error in DMARC
Dieser Fehler zeigt an, dass ein empfangender Server eine Nachricht aufgrund der DMARC-Richtlinie abgelehnt hat. Er bedeutet in der Regel, dass sowohl SPF als auch DKIM das Alignment mit der From-Header-Domain nicht bestanden haben.
Ausführlicher Leitfaden: What is the 554 5.7.5 Permanent Error in DMARC and How to Fix It?
SPF besteht, aber DMARC schlägt fehl
Dies geschieht, wenn SPF die Envelope-Absender-Domain authentifiziert, diese Domain aber nicht mit der From-Header-Domain übereinstimmt (Alignment-Fehler). Die Lösung besteht darin, den Envelope-Absender so zu konfigurieren, dass er Ihre Domain verwendet, oder DKIM mit einer passenden d=-Domain einzurichten.
Ausführliche Leitfäden:
- How SPF, DKIM, and DMARC Work Together During Authentication Failures
- How SPF and DMARC Work Together to Improve Email Security
Weitergeleitete Mail besteht DMARC nicht
Das Weiterleiten von E-Mails bricht SPF (die IP des weiterleitenden Servers ist nicht im SPF-Record der ursprünglichen Domain enthalten). Wenn DKIM nicht konfiguriert ist oder der weiterleitende Server die Nachricht verändert (und damit die DKIM-Signatur bricht), schlägt DMARC fehl. Die Lösung besteht darin, sicherzustellen, dass DKIM ordnungsgemäß konfiguriert ist, da DKIM-Signaturen das Weiterleiten überstehen, sofern der Nachrichteninhalt nicht verändert wird.
Die Beziehung zwischen DMARC und SPF
DMARC hängt stark davon ab, dass SPF korrekt konfiguriert ist. Wenn Ihr SPF-Record Fehler aufweist – sei es, dass er das Limit von 10 DNS-Lookups überschreitet, Syntaxfehler enthält oder autorisierte Absender fehlen – führt die DMARC-Durchsetzung dazu, dass diese Authentifizierungsfehler zu in Quarantäne verschobener oder abgelehnter Mail führen. Erfahren Sie, wie Sie SPF too many DNS lookups beheben, bevor es DMARC bricht. Konsolidieren Sie Ihre Includes mit einem SPF-Flattening-Dienst, um unter dem Limit von 10 Lookups zu bleiben.
Bevor Sie DMARC im Durchsetzungsmodus bereitstellen, verifizieren Sie Ihren SPF-Record mit dem SPF Checker und stellen Sie mit dem SPF Validator sicher, dass Ihre DNS-Lookup-Anzahl innerhalb der Grenzen liegt.
Für Domains mit komplexen SPF-Records, die sich dem Lookup-Limit nähern, bietet AutoSPF dynamisches SPF-Flattening, das Ihren Record automatisch innerhalb der Grenzen hält – eine kritische Grundlage für eine zuverlässige DMARC-Durchsetzung.
DMARC Report – DuoCircles ergänzendes Produkt
DMARC Report ist DuoCircles dedizierte Plattform für DMARC-Reporting und -Analytik. Sie ist darauf ausgelegt, gemeinsam mit AutoSPF zu arbeiten, um ein vollständiges Management der E-Mail-Authentifizierung zu bieten:
- AutoSPF übernimmt die SPF-Seite – dynamisches Flattening, DNS-Lookup-Management und SPF-Record-Optimierung
- DMARC Report übernimmt die Sichtbarkeitsseite – das Analysieren aggregierter Berichte, das Identifizieren von Authentifizierungsfehlern, das Verfolgen von Compliance-Trends und das Benachrichtigen bei Problemen
Gemeinsam geben sie Ihnen die volle Kontrolle über Ihre E-Mail-Authentifizierung. DMARC Report verarbeitet Ihre rua=-Aggregatberichte, normalisiert die Daten und präsentiert umsetzbare Dashboards, die Ihnen genau zeigen, welche Absender die Authentifizierung für Ihre Domain bestehen oder nicht.
Diagnose-Tools
- DMARC Checker – Validieren Sie Ihren DMARC-Record und prüfen Sie auf häufige Konfigurationsprobleme
- Domain Auth Checker – Kombinierte SPF-, DKIM- und DMARC-Prüfung in einem Lookup
- SPF Checker – Verifizieren Sie, dass SPF korrekt ist, bevor Sie DMARC durchsetzen
- DKIM Lookup – Verifizieren Sie, dass DKIM-Schlüssel veröffentlicht und gültig sind
- SPF Validator – Vollständige SPF-Auswertung mit Lookup-Zählung
Nächste Schritte
- Prüfen Sie Ihren aktuellen DMARC-Status – Verwenden Sie den DMARC Checker, um zu sehen, ob Sie einen DMARC-Record haben und welche Richtlinie er festlegt
- Beginnen Sie mit p=none – Wenn Sie DMARC noch nicht bereitgestellt haben, beginnen Sie im Überwachungsmodus, um Daten zu sammeln
- Richten Sie die Report-Verarbeitung ein – Leiten Sie Ihre
rua=-Adresse an DMARC Report für menschenlesbare Dashboards - Beheben Sie Authentifizierungslücken – Nutzen Sie aggregierte Berichte, um Dienste zu identifizieren und zu korrigieren, die SPF oder DKIM nicht bestehen
- Gehen Sie zur Durchsetzung über – Bewegen Sie sich von Quarantine zu Reject, während Ihre Authentifizierungsabdeckung reift
- Kontinuierliche Pflege – Die E-Mail-Infrastruktur ändert sich ständig. Überwachen Sie Berichte und aktualisieren Sie SPF/DKIM-Konfigurationen nach Bedarf
Für einen vollständigen Vergleich der SPF-Management-Tools siehe PowerDMARC Alternatives, EasyDMARC Alternatives und DMARCLY Alternatives.