DMARC: SPF und DKIM zusammenführen — Policy, Alignment und Reporting
DMARC bestimmt, was mit E-Mails passiert, die SPF oder DKIM nicht bestehen. Mit 35 von 165 Punkten ist DMARC der einflussreichste Faktor im Wolf-Agents Email Security Check — ohne DMARC ist Ihre maximale Note D. Dieser Guide erklärt Alignment, Reporting und den Weg von p=none zu p=reject.
Warum DMARC der wichtigste E-Mail-Security-Standard ist
DMARC (Domain-based Message Authentication, Reporting & Conformance, RFC 7489) ist die Sicherheitsrichtlinie, die empfangenden Mailservern mitteilt, was mit E-Mails passieren soll, wenn SPF oder DKIM fehlschlagen — und damit der einzige Standard, der Domain-Spoofing aktiv verhindert statt nur zu erkennen. Ohne DMARC liefern SPF und DKIM nur Prüfergebnisse ohne Konsequenzen: Gefälschte E-Mails werden trotzdem zugestellt, direkt ins Postfach des Empfängers.
DMARC ist mit 35 von 165 Punkten der gewichtigste Einzelfaktor im Wolf-Agents Email Security Check — mehr als SPF und DKIM zusammen. Die Implementierung dauert wenige Minuten: ein DNS-TXT-Record genügt. Trotzdem haben nur 26% der Top-250-Unternehmen in Deutschland DMARC mit p=reject konfiguriert. 75-80% aller Domains mit DMARC-Record verharren bei p=none — ohne jeglichen Schutz.
Dieser Wolf-Agents DMARC-Guide erklärt Alignment, Reporting und den sicheren Weg zur Enforcement-Policy — mit Provider-spezifischen Anleitungen für Microsoft 365, Google Workspace und 7 weitere Provider.
Wie DMARC funktioniert: Alignment verbindet SPF, DKIM und die sichtbare Absenderadresse
DMARC prüft nicht nur, ob SPF oder DKIM bestehen — es prüft Alignment: Stimmt die Domain der SPF- oder DKIM-Authentifizierung mit der sichtbaren Absenderdomain im From-Header überein? Ohne Alignment könnte ein Angreifer SPF und DKIM unter seiner eigenen Domain bestehen lassen, aber die From-Adresse Ihres Unternehmens fälschen. Alignment schließt genau diese Lücke.
Ohne DMARC
- SPF und DKIM liefern Prüfergebnisse — aber niemand handelt bei Fehlschlag
- Gefälschte E-Mails werden trotzdem zugestellt — direkt ins Postfach
- Kein Reporting — Sie wissen nicht, wer in Ihrem Namen sendet
- Maximale Note D im Wolf-Agents Scanner — unabhängig von allen anderen Checks
Mit DMARC
- Policy definiert Konsequenzen: quarantine verschiebt in Spam, reject lehnt ab
- Alignment prüft: Authentifizierte Domain = sichtbare Absenderdomain
- Tägliche Aggregate Reports zeigen jeden Sendeversuch in Ihrem Namen
- Voraussetzung für BIMI — Ihr Markenlogo direkt im Posteingang des Empfängers
- Robust bei Weiterleitung mit ARC (Authenticated Received Chain) — legitime Mailinglisten-Mail wird trotz
p=rejectzugestellt - Service-Aliasen pro Dienst mit Alias-Strategie — sofortige Leak-Quellen-Identifikation und gezielte Deaktivierung kompromittierter Adressen
Alignment-Typen: SPF und DKIM
SPF-Alignment
Prüft: Stimmt die Domain im Return-Path (Envelope-From) mit der Domain im From:-Header überein?
From: info@example.com Return-Path: bounce@example.com From: info@example.com Return-Path: bounce@mailservice.com DKIM-Alignment
Prüft: Stimmt die Domain im d=-Tag der DKIM-Signatur mit der Domain im From:-Header überein?
From: info@example.com DKIM-Signature: d=example.com From: info@example.com DKIM-Signature: d=sendgrid.net Relaxed vs. Strict Alignment
aspf=r / adkim=r — Subdomain erlaubt. mail.example.com passt zu example.com.
aspf=s / adkim=s — Exakte Übereinstimmung. mail.example.com passt nicht zu example.com.
DMARC-Entscheidungslogik
DMARC besteht, wenn mindestens eine Bedingung erfüllt ist:
DMARC PASS = (SPF pass + SPF-Alignment pass) ODER (DKIM pass + DKIM-Alignment pass) Eine E-Mail kann DMARC bestehen, auch wenn SPF fehlschlägt — solange DKIM mit korrektem Alignment besteht. Deshalb ist DKIM-Alignment der Goldstandard: DKIM überlebt Weiterleitungen, SPF nicht.
DMARC-Record Syntax: Alle Tags im Detail
Ein DMARC-Record ist ein DNS-TXT-Eintrag unter der Subdomain _dmarc Ihrer Domain. Er besteht aus der Versionskennung v=DMARC1, der Policy p= und optionalen Tags für Reporting, Alignment und graduelles Rollout. Für einen funktionalen Start genügen drei Tags: v=DMARC1, p=none und rua= für Aggregate Reports.
Alle DMARC-Tags
| Tag | Pflicht | Werte | Beschreibung |
|---|---|---|---|
v=DMARC1 | Ja | Fest: DMARC1 | Protokollversion — muss immer der erste Tag sein |
p= | Ja | none | quarantine | reject | Die Policy — was mit fehlgeschlagenen E-Mails passiert |
sp= | Nein | none | quarantine | reject | Subdomain-Policy — erbt von p= wenn nicht gesetzt |
rua= | Empfohlen | mailto:adresse@example.com | Aggregate Reports — tägliche XML-Zusammenfassungen |
ruf= | Nein | mailto:adresse@example.com | Forensic Reports — Details zu einzelnen Fehlschlägen |
aspf= | Nein | r (relaxed) | s (strict) | SPF-Alignment-Modus — Default: relaxed |
adkim= | Nein | r (relaxed) | s (strict) | DKIM-Alignment-Modus — Default: relaxed |
pct= | Nein | 0–100 | Prozentsatz der E-Mails für die Policy — Default: 100 |
fo= | Nein | 0 | 1 | d | s | Failure-Reporting — 1 empfohlen (bei jedem Fehlschlag) |
ri= | Nein | Sekunden | Reporting-Intervall — Default: 86400 (24 Stunden) |
Die drei Policy-Stufen
Monitoring
Keine Auswirkung auf Zustellung. Empfangende Server senden nur Berichte. Ideal für die Anfangsphase — deckt vergessene Dienste auf.
Grade Cap: CSpam-Ordner
Fehlgeschlagene E-Mails in den Spam-Ordner. Guter Kompromiss — Empfänger können E-Mails noch finden, falls nötig.
Höhere Noten möglichMaximaler Schutz
Fehlgeschlagene E-Mails werden vollständig abgelehnt (SMTP 550). Die E-Mail erreicht den Empfänger nicht — weder Posteingang noch Spam.
35/35 Punkte möglichParked Domains absichern
Jede Domain, die Sie nicht für E-Mail-Versand nutzen, muss trotzdem gegen Spoofing geschützt werden. Angreifer suchen gezielt nach ungeschützten Parked Domains.
_dmarc.parked-domain.de TXT "v=DMARC1; p=reject; sp=reject"
parked-domain.de TXT "v=spf1 -all"
parked-domain.de MX 0 .DMARC-Reporting: Aggregate Reports und Forensic Reports
DMARC-Reporting ist der Schlüssel zur sicheren Enforcement-Umstellung. Aggregate Reports (rua=) liefern tägliche XML-Zusammenfassungen, die zeigen, welche Server E-Mails in Ihrem Namen senden, ob SPF und DKIM bestehen und welche Policy angewendet wurde. Ohne Reporting fliegen Sie blind — ein DMARC-Record ohne rua= ist nahezu wertlos.
Aggregate Reports (rua=)
Tägliche XML-Zusammenfassungen von empfangenden Mailservern. Enthalten: Quell-IPs, E-Mail-Anzahl, SPF/DKIM-Ergebnisse, Alignment-Status und angewendete Policy.
<record>
<row>
<source_ip>203.0.113.1</source_ip>
<count>1524</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>3</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
</record>Die erste Zeile zeigt Ihren legitimen Mailserver (1.524 E-Mails, alles bestanden). Die zweite Zeile zeigt einen verdächtigen Absender (3 E-Mails, SPF und DKIM fehlgeschlagen) — möglicherweise ein Spoofing-Versuch.
Forensic Reports (ruf=)
Details zu einzelnen fehlgeschlagenen E-Mails: Subject, From, To, empfangene Header und Fehlergründe. Deutlich detaillierter als Aggregate Reports.
Forensic Reports enthalten personenbezogene Daten (E-Mail-Adressen, Betreffzeilen). Das ECO-Gutachten kommt zum Schluss: Forensic Reports an externe Drittanbieter verstoßen gegen TTDSG §3. Nutzen Sie ruf= nur für interne Analyse, nicht an externe Monitoring-Dienste.
Monitoring-Tools für DMARC-Reports
Enforcement-Roadmap: Von p=none zu p=reject in 4 Phasen
Der Weg von p=none zu p=reject ist ein mehrstufiger Prozess, der 6-12 Wochen dauert. Gehen Sie niemals direkt von keinem DMARC zu p=reject — Sie werden legitime E-Mails verlieren. Der pct-Tag ermöglicht graduelles Rollout: Erst 10% der fehlgeschlagenen E-Mails betreffen, dann schrittweise auf 100% erhöhen.
Monitoring (p=none) — 2-4 Wochen
v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1 Alle Absender identifizieren. SPF und DKIM für alle legitimen Dienste korrekt konfigurieren. Berichte täglich auswerten.
Quarantine mit Rollout — 2-4 Wochen
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com; fo=1 Schrittweise erhöhen: pct=10 → 25 → 50 → 100. Nicht betroffene E-Mails fallen auf quarantine zurück, nicht auf none.
Reject mit Rollout — 1-2 Wochen
v=DMARC1; p=reject; pct=10; rua=mailto:dmarc@example.com; fo=1 Schrittweise erhöhen: pct=10 → 25 → 50 → 100. Bei Problemen auf quarantine zurückfallen.
Finaler Record — Maximaler Schutz
v=DMARC1; p=reject; sp=reject; aspf=s; adkim=s; rua=mailto:dmarc@example.com; fo=1 p=reject, sp=reject, striktes Alignment. Die vollständige 4-Phasen-Roadmap mit Troubleshooting behandelt Kapitel 05: DMARC Enforcement.
Häufige DMARC-Fehler — und wie Sie sie vermeiden
Die folgenden sechs Fehler treten bei DMARC-Konfigurationen am häufigsten auf. Jeder einzelne kann dazu führen, dass DMARC unwirksam ist oder legitime E-Mails verloren gehen. Der Wolf-Agents Email Security Check erkennt alle diese Fehlkonfigurationen automatisch.
Fehlendes rua= — Blind fliegen
Ein DMARC-Record ohne rua= liefert keine Berichte. Sie wissen nicht, wer in Ihrem Namen sendet, und können die Policy nicht sicher verschärfen. Ohne Reporting ist DMARC nahezu wertlos — immer rua=mailto:... konfigurieren.
Direkt zu p=reject — E-Mails verlieren
Ohne vorherige Monitoring-Phase werden Sie mit hoher Wahrscheinlichkeit legitime E-Mails blockieren: Newsletter-Tools, CRM-Systeme, Ticketsysteme — jeder Dienst, der noch nicht korrekt authentifiziert ist. Immer mit p=none starten und 2-4 Wochen Reports auswerten.
Vergessenes sp= — Subdomain-Lücke
Ohne explizites sp=reject können Angreifer nicht existierende Subdomains wie secure-login.ihre-domain.de für Spoofing nutzen. Setzen Sie sp=reject immer explizit — besonders wenn Ihre Hauptdomain auf p=reject steht.
Mehrere DMARC-Records — Invalidierung
RFC 7489 erlaubt nur einen DMARC-Record pro Domain. Bei mehreren Records ist das Verhalten undefiniert — die meisten Mailserver ignorieren DMARC dann komplett. Prüfen Sie nach Migrationen, ob alte Records noch existieren.
Alignment nicht beachtet — Drittanbieter-Problem
SPF und DKIM können technisch bestehen, während das Alignment fehlschlägt — weil die authentifizierte Domain nicht mit der From-Domain übereinstimmt. Aktivieren Sie bei jedem Drittanbieter Custom-DKIM-Signierung mit Ihrer Domain (d=ihre-domain.de).
Falsche Subdomain — _dmarc vergessen
Der DMARC-Record muss unter _dmarc.ihre-domain.de liegen — nicht unter dmarc.ihre-domain.de (Unterstrich fehlt) oder _dmarc_.ihre-domain.de. Ein falsch platzierter Record wird von keinem Mailserver gefunden.
DMARC als Compliance-Nachweis: NIS2, BSI und DSGVO
DMARC mit p=reject ist der prüfbare Nachweis, dass Ihre Organisation E-Mail-Spoofing aktiv verhindert. Die BSI TR-03108 schreibt DMARC explizit vor, NIS2 Art. 21 fordert Maßnahmen zur Kommunikationssicherheit mit persönlicher Geschäftsführerhaftung nach §38 BSIG, und die DSGVO Art. 32 verlangt technische Maßnahmen zum Schutz personenbezogener Daten.
NIS2 Art. 21
DMARC ist eine direkte technische Maßnahme gegen E-Mail-Spoofing im Sinne der Kommunikationssicherheit. Die Geschäftsleitung haftet persönlich nach §38 BSIG — das Fehlen von DMARC kann im Schadensfall als grobe Fahrlässigkeit gewertet werden.
BSI TR-03108
Die BSI Technische Richtlinie für sicheren E-Mail-Transport schreibt DMARC explizit vor. BSI TR-03182 konkretisiert: Sendende Domains müssen DMARC-Records veröffentlichen, die Policy muss eine rua-Adresse enthalten, Reports müssen regelmäßig ausgewertet werden.
DSGVO Art. 32
DMARC schützt die Integrität und Vertraulichkeit der E-Mail-Kommunikation — eine direkte Anforderung aus Art. 32 Abs. 1 lit. b DSGVO. Domain-Spoofing ermöglicht den Abgriff personenbezogener Daten; DMARC mit p=reject verhindert diesen Angriffsvektor.
DMARC adressiert konkrete Bedrohungen: Email-Spoofing, Business Email Compromise (BEC) (FBI IC3 2024: 2,77 Mrd. USD Schaden, 21.442 Beschwerden) und Phishing (APWG Q2 2025: 1.130.393 Angriffe, höchster Quartalswert seit Q2 2023). Vertiefung im Bedrohungs-Cluster.
Der Wolf-Agents Email Security Check prüft alle 165 Kriterien inklusive der 35 DMARC-Punkte — kostenlos und ohne Registrierung. Das Monitoring überwacht Ihre DMARC-Konfiguration alle 6 Stunden und alarmiert bei Änderungen. Ergänzend erkennt die Stack Detection Provider-Wechsel beim Lieferanten oder bei eigenen Sub-Diensten (z.B. neuer Mail-Versender ohne SPF-/DKIM-Update) — eine zentrale Drift-Erkennung gegen VEC und SubdoMailing.
DMARC-Anleitung für Ihren Provider:
Wie steht Ihre Domain bei DMARC?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.
Häufig gestellte Fragen
Was ist DMARC und wozu brauche ich es?
DMARC (Domain-based Message Authentication, Reporting & Conformance) ist ein DNS-basiertes Protokoll nach RFC 7489, das empfangenden Mailservern mitteilt, was mit E-Mails passieren soll, wenn SPF oder DKIM fehlschlagen. Ohne DMARC liefern SPF und DKIM nur Prüfergebnisse ohne Konsequenzen — gefälschte E-Mails werden trotzdem zugestellt. DMARC definiert die Policy: p=none (nur Monitoring), p=quarantine (in Spam verschieben) oder p=reject (vollständig ablehnen). Im Wolf-Agents Email Security Check ist DMARC mit 35 von 165 Punkten der gewichtigste Einzelfaktor.
Was ist DMARC-Alignment und warum ist es wichtig?
Alignment prüft, ob die Domain der SPF- oder DKIM-Authentifizierung mit der sichtbaren Absenderdomain im From-Header übereinstimmt. Ohne Alignment könnte ein Angreifer SPF und DKIM unter seiner eigenen Domain bestehen lassen, aber die From-Adresse Ihrer Domain fälschen. DMARC verlangt, dass mindestens SPF-Alignment oder DKIM-Alignment besteht. Relaxed Alignment erlaubt Subdomains, Strict Alignment fordert exakte Übereinstimmung.
Was ist der Unterschied zwischen p=none, p=quarantine und p=reject?
p=none ist der Monitoring-Modus: E-Mails werden zugestellt, Sie erhalten nur Berichte. p=quarantine verschiebt fehlgeschlagene E-Mails in den Spam-Ordner. p=reject lehnt fehlgeschlagene E-Mails vollständig ab — maximaler Schutz. Im Wolf-Agents Scanner ist Ihr Grade Cap ohne DMARC D, mit p=none C, erst ab p=quarantine oder p=reject sind höhere Noten möglich.
Wie lange sollte ich im Monitoring-Modus (p=none) bleiben?
Mindestens 2-4 Wochen, bei komplexen E-Mail-Infrastrukturen bis zu 8 Wochen. In dieser Zeit sammeln Sie Aggregate Reports, die zeigen, welche Server E-Mails in Ihrem Namen senden. Identifizieren Sie alle legitimen Dienste (Newsletter, CRM, Ticketsystem) und stellen Sie sicher, dass SPF und DKIM korrekt konfiguriert sind, bevor Sie die Policy verschärfen.
Was sind DMARC Aggregate Reports und wie lese ich sie?
Aggregate Reports sind tägliche XML-Zusammenfassungen von empfangenden Mailservern, konfiguriert über den rua-Tag im DMARC-Record. Sie enthalten: welche IPs E-Mails für Ihre Domain senden, SPF/DKIM-Ergebnisse und Alignment-Status. Die komprimierten XML-Dateien können mit Tools wie dmarcian, Postmark DMARC oder EasyDMARC ausgewertet werden — oder manuell per Kommandozeile mit zcat und xmllint.
Wie funktioniert DMARC mit Drittanbietern wie Mailchimp oder HubSpot?
Drittanbieter senden E-Mails in Ihrem Namen, nutzen aber eigene Infrastruktur. DKIM-Alignment ist der Goldstandard: Konfigurieren Sie beim Drittanbieter Custom-DKIM-Signierung mit Ihrer Domain (d=ihre-domain.de). SPF-Alignment funktioniert nur, wenn der Return-Path Ihre Domain verwendet — bei vielen Diensten wie Salesforce ist das konstruktionsbedingt nicht möglich. Prüfen Sie jeden Dienst einzeln in Ihren DMARC-Reports.
Brauche ich zuerst SPF und DKIM, bevor ich DMARC aktiviere?
DMARC setzt technisch voraus, dass mindestens SPF oder DKIM konfiguriert ist — idealerweise beides. DMARC prüft Alignment gegen SPF und DKIM: Ohne beide Protokolle kann DMARC keine sinnvolle Authentifizierung durchführen. Konfigurieren Sie zuerst SPF (Kapitel 02) und DKIM (Kapitel 03), testen Sie beide per dig-Befehl und Gmail-Header-Analyse, dann aktivieren Sie DMARC mit p=none.