Warum DMARC-Berichte überwachen?
DMARC-Überwachung zeigt, wer in Ihrem Namen E-Mails versendet und welche dieser Sendungen die Authentifizierung bestehen. Anders erfahren Sie es nicht.
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) vereint SPF und DKIM, um Ihre Domain gegen Phishing und E-Mail-Spoofing zu verschließen. Den Eintrag zu veröffentlichen ist Schritt eins. Ohne Berichte bleibt der Rest blind. Sie wissen nicht, welche Quellen in Ihrem Namen senden, ob sich Ihre legitimen Flüsse wirklich auf SPF und DKIM ausrichten und ob ein Dritter Ihre Domain für Spam ausnutzt.
Vier Probleme tauchen in fast jeder Prüfung von DMARC-Berichten auf.
Ein CRM, eine Newsletter-Plattform oder ein Abrechnungssystem versendet für Ihre Domain, ohne SPF und DKIM korrekt auszurichten. Folge: Spam oder Ablehnung. Das ist der häufigste Fall.
Dann das Spoofing. Angreifer fälschen Ihre From-Adresse für Phishing. Ohne Aggregatberichte bleiben diese Kampagnen unsichtbar, bis sich ein Kunde beschwert.
Eine schlecht ausgeführte E-Mail-Migration lässt den alten Anbieter wochenlang nicht-alignierte Nachrichten versenden. Ihre Compliance-Rate sinkt, und niemand versteht warum.
Schließlich die Schatten-IT: eine interne Abteilung versendet ohne Genehmigung. DMARC-Berichte holen diese unbekannten Absender aus dem Dunkeln.
Wie DMARC-Authentifizierung funktioniert
DMARC prüft, dass mindestens SPF oder DKIM besteht und sich auf die Domain des From-Headers ausrichtet. Zwei Protokolle darunter, eine einzige Entscheidung darüber.
SPF (RFC 7208) und DKIM (RFC 6376) authentifizieren jeweils einen anderen Aspekt der Nachricht. SPF prüft den sendenden Server. DKIM prüft eine Signatur. DMARC entscheidet.
| Protokoll | Was geprüft wird | Funktionsweise |
|---|---|---|
| SPF | IP des Envelope-Absenders | Der empfangende Server prüft, ob die IP des Absenders im SPF-DNS-Eintrag der Domain aufgeführt ist |
| DKIM | Nachrichtenintegrität | Eine kryptografische Signatur im E-Mail-Header wird gegen einen öffentlichen Schlüssel im DNS verifiziert |
| DMARC | Identifier-Alignment | Verifiziert, dass mindestens SPF oder DKIM besteht und mit der From-Header-Domain übereinstimmt |
Alles hängt am Alignment. SPF und DKIM bestehen beide, und DMARC scheitert trotzdem, wenn sich keines auf die From-Domain ausrichtet. Seltsam? Nicht wirklich: genau diese Lücke nutzen Spoofer aus, und sie ist die erste Fehlerursache, die die Berichte aufdecken.
DMARC bestimmt auch das Schicksal nicht authentifizierter Nachrichten: durchlassen (p=none), unter Quarantäne stellen (p=quarantine) oder ablehnen (p=reject).
DMARC-Monitoring in 3 Schritten einrichten
Schritt 1: Domain hinzufügen und Inhaberschaft verifizieren
Melden Sie sich an und registrieren Sie die zu überwachende Domain. Fügen Sie den CaptainDNS-Verifizierungs-TXT-Eintrag in Ihrem DNS hinzu. Dieses Verifizierungssystem wird von allen CaptainDNS-Diensten geteilt (MTA-STS-Hosting, TLS-RPT-Monitoring, BIMI-Hosting).
Schritt 2: Ihren DMARC-DNS-Eintrag konfigurieren
Der Einrichtungsassistent analysiert Ihren aktuellen DNS-Status und schlägt den exakten Eintrag zum Veröffentlichen vor:
- Kein vorhandener DMARC-Eintrag: Ein vollständiger Eintrag wird mit
p=noneund unsererrua=-Adresse generiert - Vorhandener DMARC-Eintrag: Ihre Richtlinie, Alignment-Einstellungen und vorhandene
rua=-Adressen werden beibehalten; unsere Adresse wird automatisch hinzugefügt - Ungültiger vorhandener Eintrag: Das Problem wird angezeigt und ein sauberer Ersatz vorgeschlagen
Kopieren Sie einfach den Host (_dmarc.yourdomain.com) und den Wert und fügen Sie sie bei Ihrem DNS-Anbieter ein.
Schritt 3: Berichte werden automatisch empfangen und analysiert
E-Mail-Anbieter beginnen innerhalb von 24 bis 48 Stunden mit dem Versand ihrer Aggregatberichte. CaptainDNS empfängt sie, dekomprimiert das XML, analysiert die Authentifizierungsergebnisse und zeigt die Ergebnisse in Ihrem Dashboard an: Compliance-Scores, Quell-IPs, Erfolgs-/Fehlerquoten und angewandte Dispositionen.
DMARC-Aggregatberichte verstehen
Ein DMARC-Aggregatbericht ist eine XML-Datei, die pro Quell-IP alle Authentifizierungsergebnisse für Ihre Domain während eines bestimmten Fensters zusammenfasst.
Google, Microsoft, Yahoo und Apple senden sie an die Adresse Ihres rua=-Tags, in der Regel alle 24 Stunden. Jeder Bericht deckt einen Zeitraum ab, und jede Zeile beschreibt eine Quelle, die unter Verwendung Ihrer Domain versendet hat.
RUA vs. RUF: Aggregatberichte vs. Fehlerberichte
DMARC definiert zwei Berichtstypen:
| Berichtstyp | Tag | Häufigkeit | Inhalt | Anbieterunterstützung |
|---|---|---|---|---|
| Aggregat (RUA) | rua= | Täglich (in der Regel alle 24h) | Zusammengefasste Authentifizierungsdaten pro Quell-IP | Weitgehend von allen großen Anbietern unterstützt |
| Forensisch (RUF) | ruf= | Pro Fehler | Einzelne Nachrichtendetails einschließlich Headern | Sehr eingeschränkt (die meisten Anbieter senden aus Datenschutzgründen keine RUF-Berichte) |
CaptainDNS konzentriert sich auf Aggregatberichte (RUA), die die für Compliance-Tracking und Quellenidentifikation benötigten Daten liefern. Forensische Berichte sind in der Praxis selten verfügbar.
Was enthält ein DMARC-Aggregatbericht?
| Feld | Beschreibung |
|---|---|
| Berichtende Organisation | Der E-Mail-Anbieter, der den Bericht erstellt hat (Google, Microsoft, Yahoo usw.) |
| Zeitraum | Start- und End-Zeitstempel des Berichtsfensters |
| Veröffentlichte Richtlinie | Ihre DMARC-Richtlinie (none, quarantine, reject) und angewandte Prozentsätze |
| Ergebnisse pro Quell-IP | Für jede sendende IP: Nachrichtenanzahl, SPF-Ergebnis, DKIM-Ergebnis, Alignment-Status, angewandte Disposition |
| Header-Identifikatoren | From-Header-Domain und für die SPF- und DKIM-Auswertung verwendete Domains |
Beispiel eines DMARC-Aggregatberichts
Hier ist ein vereinfachter Auszug aus einem DMARC-Aggregatbericht im XML-Format:
<?xml version="1.0" encoding="UTF-8"?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<date_range>
<begin>1710201600</begin>
<end>1710288000</end>
</date_range>
</report_metadata>
<policy_published>
<domain>captaindns.com</domain>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>203.0.113.1</source_ip>
<count>1547</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<row>
<source_ip>198.51.100.42</source_ip>
<count>23</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
</record>
</feedback>
Die erste Zeile zeigt 1.547 Nachrichten von einer legitimen Quelle, die beide Prüfungen bestehen. Die zweite Zeile enthüllt 23 Nachrichten von einer unbekannten IP, die sowohl an SPF als auch an DKIM scheitern, ein potenzieller Spoofing-Versuch. CaptainDNS analysiert diese Berichte automatisch und präsentiert die Daten in Ihrem Dashboard. Um einen einzelnen erhaltenen XML-Bericht zu entschlüsseln, gibt unser DMARC-Berichtsleser dessen Inhalt lesbar wieder.
DMARC-Eintrag-Tag-Referenz
Ein DMARC-TXT-Eintrag wird unter _dmarc.yourdomain.com veröffentlicht. Hier sind die verfügbaren Tags:
| Tag | Erforderlich | Beispiel | Beschreibung |
|---|---|---|---|
v | Ja | v=DMARC1 | Protokollversion (immer DMARC1) |
p | Ja | p=none | Richtlinie für die Domain: none, quarantine oder reject |
sp | Nein | sp=reject | Richtlinie für Subdomains (erbt von p, wenn nicht gesetzt) |
rua | Nein | rua=mailto:reports@captaindns.com | Wohin Aggregatberichte gesendet werden |
ruf | Nein | ruf=mailto:forensics@captaindns.com | Wohin Fehlerberichte gesendet werden |
adkim | Nein | adkim=s | DKIM-Alignment-Modus: r (relaxed, Standard) oder s (strict) |
aspf | Nein | aspf=r | SPF-Alignment-Modus: r (relaxed, Standard) oder s (strict) |
pct | Nein | pct=50 | Prozentsatz der Nachrichten, die der Richtlinie unterliegen (Standard 100) |
fo | Nein | fo=1 | Optionen für forensische Berichte: 0 (Standard), 1, d, s |
ri | Nein | ri=86400 | Berichtsintervall in Sekunden (Standard 86400 = 24h) |
Nutzen Sie unseren DMARC-Generator, um einen gültigen Eintrag zu erstellen, oder die DMARC-Syntaxprüfung, um einen bestehenden zu validieren.
Vom Monitoring zur Durchsetzung: der Weg zu p=reject
DMARC blockiert Spoofing erst mit p=reject endgültig. Jede gefälschte Nachricht wird dann an der Tür abgewiesen. Direkt auf reject zu springen, ohne Berichte, heißt Roulette spielen: Ihre legitimen, schlecht ausgerichteten Absender fallen mit, und ihre Post verschwindet.
Empfohlene Vorgehensweise:
-
p=none(nur Monitoring): sammeln Sie Berichte für 2 bis 4 Wochen. Identifizieren Sie alle legitimen Quellen und beheben Sie SPF/DKIM-Alignment-Probleme. Ziel: 95%+ Compliance-Rate. -
p=quarantine(teilweise Durchsetzung): fehlgeschlagene Nachrichten werden in den Spam-Ordner statt in den Posteingang verschoben. Beginnen Sie mitpct=25, erhöhen Sie dann auf 50% und 100% über 2 bis 4 Wochen. Überwachen Sie, ob legitime E-Mails in Quarantäne landen. -
p=reject(vollständige Durchsetzung): fehlgeschlagene Nachrichten werden verworfen. Domain-Spoofing wird vollständig blockiert. Beginnen Sie mitpct=25, steigern Sie dann auf 100%.
Zeitrahmen: Die meisten Organisationen durchlaufen diesen Prozess in 4 bis 8 Wochen. Überstürzen Sie nichts. Jede Stufe sollte bestätigen, dass kein legitimer E-Mail-Fluss beeinträchtigt wird.
Das Erreichen von p=reject schaltet auch BIMI frei (Brand Indicators for Message Identification), das Ihr Markenlogo neben Ihren E-Mails in unterstützten Postfächern anzeigt.
DMARC-Anforderungen von Google und Yahoo
Seit Februar 2024 verweigern Google und Yahoo die Post von Massenversendern ohne veröffentlichtes DMARC. Die Schwelle: 5.000 Nachrichten pro Tag an Gmail oder Yahoo.
Vier Pflichten gelten für diese großen Volumen. Es braucht einen DMARC-Eintrag mit mindestens p=none. SPF und DKIM müssen beide konfiguriert sein, nicht das eine oder das andere. Die From-Domain muss sich auf eines von beiden ausrichten. Und Marketing-E-Mails müssen die Ein-Klick-Abmeldung der RFC 8058 tragen.
Ohne Überwachung der Berichte lässt sich weder nachweisen, dass Ihre Quellen diese Prüfungen bestehen, noch die Compliance-Rate auf Dauer halten. Nicht konforme Absender sehen ihre Post durch 4xx-Fehler verzögert und dann abgelehnt. Genau das geschah im großen Stil im Frühjahr 2024.
Häufige DMARC-Fehler und deren Behebung
Die meisten DMARC-Fehler gehen auf sechs Ursachen zurück: gebrochenes SPF-Alignment, gebrochenes DKIM-Alignment, SPF über 10 DNS-Lookups, Dritte ganz ohne Authentifizierung, nicht abgedeckte Subdomain, Weiterleitung, die SPF bricht. Jede hat eine genaue Lösung.
| Fehler | Ursache | Lösung |
|---|---|---|
| SPF-Alignment schlägt fehl | Envelope-Absender-Domain weicht von der From-Header-Domain ab | Konfigurieren Sie den Drittanbieter-Dienst so, dass er Ihre Domain als Envelope-Absender verwendet, oder fügen Sie dessen Sende-IPs zu Ihrem SPF-Eintrag hinzu |
| DKIM-Alignment schlägt fehl | DKIM-Signatur verwendet eine andere Domain als den From-Header | Konfigurieren Sie die DKIM-Signierung mit Ihrer Domain (nicht der Standard-Domain des Anbieters) |
| SPF überschreitet das DNS-Lookup-Limit | SPF-Eintrag hat mehr als 10 DNS-Lookups | Vereinfachen Sie Ihren SPF-Eintrag oder entfernen Sie nicht verwendete Includes. Nutzen Sie unsere SPF-Syntaxprüfung |
| Drittanbieter-Absender scheitert an beidem | Dienst versendet in Ihrem Namen ohne SPF oder DKIM | Fügen Sie die IPs des Dienstes zu Ihrem SPF-Eintrag hinzu und konfigurieren Sie die DKIM-Signierung |
| Subdomain-Spoofing | Angreifer nutzen Subdomains, die Sie nicht geschützt haben | Fügen Sie sp=reject zu Ihrem DMARC-Eintrag hinzu, um die Reject-Richtlinie auf alle Subdomains anzuwenden |
| Weitergeleitete E-Mails scheitern | E-Mail-Weiterleitung bricht SPF; DKIM überlebt, wenn der Nachrichtentext unverändert ist | Stellen Sie sicher, dass DKIM konfiguriert ist, es überlebt Weiterleitungen. Erwägen Sie ARC-Unterstützung (Authenticated Received Chain) |
Praxisbeispiele
Fall 1: Falsch konfigurierten Drittanbieter-Dienst identifizieren
Symptom: Die DMARC-Compliance-Rate fällt innerhalb einer Woche von 98% auf 72%.
Diagnose: Das Dashboard zeigt eine neue Quell-IP, die erhebliches Volumen ohne DKIM-Alignment versendet. Es handelt sich um das neue Marketing-CRM, das ohne DKIM-Signatur für Ihre Domain konfiguriert wurde.
Maßnahme: DKIM-Signierung im CRM konfigurieren. Die Compliance-Rate erholt sich in den folgenden Berichten.
Fall 2: Domain-Spoofing erkennen
Symptom: Unbekannte Quell-IPs erscheinen in den Berichten und versenden E-Mails im Namen Ihrer Domain mit vollständigem SPF- und DKIM-Fehler.
Diagnose: DMARC-Berichte offenbaren Phishing-Versuche von Servern in verdächtigen Jurisdiktionen. Ihre p=none-Richtlinie lässt diese Nachrichten durch.
Maßnahme: Schrittweise Ihre Richtlinie von p=none auf p=quarantine und dann auf p=reject umstellen. Folgende Berichte bestätigen, dass betrügerische Nachrichten abgelehnt werden.
Fall 3: Google-Massenversender-Anforderungen erfüllen
Symptom: Gmail beginnt, Ihre Marketing-E-Mails mit temporären 4xx-Fehlern zurückzustellen. Die Zustellraten sinken.
Diagnose: DMARC-Monitoring zeigt, dass Ihre Newsletter-Plattform E-Mails ohne DKIM-Alignment zur From-Header-Domain versendet. Googles Massenversender-Richtlinie erfordert Authentifizierungs-Compliance.
Maßnahme: DKIM-Signierung für Ihre Domain in der Newsletter-Plattform konfigurieren und das Alignment über DMARC-Berichte verifizieren. Die Zustellraten normalisieren sich innerhalb weniger Tage.
FAQ - Häufig gestellte Fragen
F: Was ist DMARC-Monitoring?
A: DMARC-Monitoring bedeutet, die von E-Mail-Anbietern gesendeten Aggregatberichte (rua) zu empfangen und zu analysieren. Diese Berichte zeigen, welche Quellen E-Mails im Namen Ihrer Domain versenden und ob sie die SPF- und DKIM-Prüfungen mit korrektem Alignment bestehen.
F: Was ist der Unterschied zwischen DMARC-Aggregatberichten (RUA) und Fehlerberichten (RUF)?
A: Aggregatberichte (rua) werden täglich gesendet und enthalten zusammengefasste Authentifizierungsdaten pro Quell-IP. Fehlerberichte (ruf) werden bei einzelnen Nachrichtenfehlern gesendet und enthalten mehr Details einschließlich Nachrichtenheadern. Die meisten Anbieter senden nur Aggregatberichte. CaptainDNS konzentriert sich auf die Analyse von Aggregatberichten.
F: Wie funktioniert DMARC mit SPF und DKIM?
A: DMARC baut auf SPF und DKIM auf, indem es Identifier-Alignment hinzufügt. SPF validiert die IP des Envelope-Absenders, DKIM validiert eine kryptografische Signatur, und DMARC prüft, ob mindestens eines mit Alignment zur From-Header-Domain besteht. Monitoring zeigt auf, wenn das Alignment fehlschlägt.
F: Mit welcher DMARC-Richtlinie sollte ich beginnen?
A: Beginnen Sie mit p=none, um zu überwachen, ohne die E-Mail-Zustellung zu beeinflussen. Sobald Ihre DMARC-Compliance-Rate konstant über 95% liegt, wechseln Sie zu p=quarantine. Nachdem Sie bestätigt haben, dass keine legitime E-Mail betroffen ist, setzen Sie p=reject für vollständigen Spoofing-Schutz.
F: Wie richte ich DMARC-Monitoring ein?
A: Fügen Sie Ihre Domain in CaptainDNS hinzu, verifizieren Sie die Inhaberschaft über den TXT-Eintrag und folgen Sie dann dem Einrichtungsassistenten, der Ihren aktuellen DMARC-Eintrag erkennt und die exakte Aktualisierung vorschlägt. Berichte treffen innerhalb von 24 bis 48 Stunden ein.
F: Ist DMARC-Monitoring mit CaptainDNS kostenlos?
A: Ja, vollständig kostenlos für 1 Domain (Upgrade auf Starter für 25). Keine versteckten Gebühren, keine Testphase. Jede Domain sollte ihre DMARC-Aggregatberichte unabhängig vom Budget überwachen können.
F: Verlangen Google und Yahoo DMARC?
A: Ja. Seit Februar 2024 verlangen Google und Yahoo von Massenversendern (5.000+ Nachrichten pro Tag), einen DMARC-Eintrag zu veröffentlichen. Monitoring hilft Ihnen, diese Anforderungen zu erfüllen und einzuhalten, indem es die Authentifizierungs-Compliance verfolgt.
F: Was passiert, wenn ich meine DMARC-Richtlinie auf reject setze?
A: Mit p=reject verwerfen empfangende Server Nachrichten, die sowohl am SPF- als auch am DKIM-Alignment scheitern. Dies verhindert Domain-Spoofing vollständig, kann aber legitime E-Mails blockieren, wenn Drittanbieter-Absender nicht korrekt konfiguriert sind. Überwachen Sie immer zuerst mit p=none.
F: Wie lange dauert es, DMARC-Berichte zu empfangen?
A: Die meisten E-Mail-Anbieter senden Aggregatberichte alle 24 Stunden. Nach der Veröffentlichung Ihrer rua=-Adresse können Sie die ersten Berichte innerhalb von 24 bis 48 Stunden erwarten, abhängig von Ihrem E-Mail-Volumen.
F: Welcher Zusammenhang besteht zwischen DMARC-Monitoring und einem DMARC-Eintrag?
A: Der DMARC-Eintrag definiert Ihre Authentifizierungsrichtlinie (none, quarantine, reject) und das rua=-Tag gibt an, wohin Berichte gesendet werden. DMARC-Monitoring analysiert diese Berichte, um Ihnen zu zeigen, wer Ihre Domain nutzt und ob die Authentifizierung korrekt funktioniert.
Ergänzende Tools
| Tool | Nutzen |
|---|---|
| DMARC-Eintragsprüfung | Den DMARC-DNS-Eintrag Ihrer Domain prüfen |
| DMARC-Generator | Einen DMARC-DNS-Eintrag generieren |
| DMARC-Syntaxprüfung | Die Syntax eines DMARC-Eintrags validieren |
| DMARC-Berichtsleser | Erhaltene aggregierte XML-Berichte dekodieren |
| SPF-Eintragsprüfung | Ihren SPF-DNS-Eintrag prüfen |
| DKIM-Eintragsprüfung | Ihren DKIM-DNS-Eintrag prüfen |
| MTA-STS-Hosting | Ihre MTA-STS-Richtlinie kostenlos hosten |
| TLS-RPT-Monitoring | SMTP-TLS-Berichte überwachen |
| BIMI-Hosting | Ihr BIMI-Logo und -Zertifikat kostenlos hosten |
Nützliche Ressourcen
- RFC 7489: DMARC, offizielle DMARC-Spezifikation
- RFC 7208: SPF, Sender Policy Framework
- RFC 6376: DKIM, DomainKeys Identified Mail
- Google: E-Mail-Absenderrichtlinien, Anforderungen für Massenversender
- Yahoo: Best Practices für Absender, Yahoo-Authentifizierungsanforderungen
- M3AAWG Best Practices, Empfehlungen der Messaging Anti-Abuse Working Group