DMARC Implementierung: Schritt-für-Schritt von p=none zu p=reject

E-Mail-Spoofing - das Versenden von E-Mails mit gefälschtem Absender - ist eine der häufigsten Techniken bei Phishing-Angriffen und CEO-Fraud. DMARC (Domain-based Message Authentication, Reporting and Conformance) schließt diese Lücke, indem es E-Mail-Empfängern mitteilt, wie mit Nachrichten umzugehen ist, die die Authentifizierung nicht bestehen. Die Implementierung erfordert Sorgfalt - ein falsch konfiguriertes DMARC-Record mit p=reject kann legitime E-Mails blockieren.

Warum DMARC unverzichtbar ist

Ohne DMARC kann jeder Angreifer eine E-Mail mit dem Absender ceo@unternehmen.de versenden. Da kein SPF und kein DKIM erzwungen wird, akzeptieren empfangende Server die Nachricht - der Mitarbeiter sieht einen legitimen Absender und klickt auf den Link.

Die Zahlen belegen die Relevanz: Täglich werden rund 3,4 Milliarden Phishing-E-Mails versendet, 94 % aller Malware-Angriffe starten mit einer E-Mail, und CEO-Fraud-Schäden summieren sich weltweit auf über 26 Milliarden USD (seit 2013).

Mit p=reject wird jede E-Mail, die SPF und DKIM nicht besteht, sofort abgelehnt. Ein Angreifer kann die Domain technisch nicht mehr für glaubwürdiges Spoofing missbrauchen.

Voraussetzung: DMARC funktioniert nur, wenn SPF oder DKIM bereits konfiguriert ist. Beide sollten vor dem DMARC-Rollout in Betrieb sein.

Schritt 1: SPF korrekt konfigurieren

SPF (Sender Policy Framework) legt als DNS-TXT-Record fest, welche IP-Adressen E-Mails im Namen einer Domain versenden dürfen. Die Grundstruktur lautet v=spf1 [mechanisms] [qualifier].

Qualifier steuern, wie mit nicht autorisierten Sendern umgegangen wird:

Qualifier	Bedeutung
+ (Pass, Standard)	IP ist autorisiert
- (Fail)	IP ist nicht autorisiert - ablehnen
~ (SoftFail)	Nicht autorisiert, aber nur markieren (für Migrationen)
? (Neutral)	Keine Aussage

Mechanisms definieren die erlaubten Quellen: include: bindet den SPF einer anderen Domain ein, ip4: und ip6: erlauben konkrete IP-Ranges, mx erlaubt den MX-Server der Domain, all greift als letztes Element auf alles Weitere.

Typische SPF-Records für gängige Szenarien:

# Nur Google Workspace + eigene IP:
v=spf1 include:_spf.google.com ip4:203.0.113.1 -all

# Microsoft 365 + Mailchimp + eigene IP:
v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:203.0.113.1 -all

Der wichtigste Fallstrick: SPF erlaubt maximal 10 DNS-Lookups. Jedes include: zählt. Mehr als 10 führen zu einem PermError - DMARC schlägt dann fehl. Bei vielen E-Mail-Diensten helfen SPF-Flattening-Dienste, die alle include:-Werte in direkte IP-Listen auflösen. Testen lässt sich der Record mit dig TXT example.com | grep spf oder MXToolbox.

Schritt 2: DKIM konfigurieren

DKIM (DomainKeys Identified Mail) signiert ausgehende E-Mails mit einem privaten Schlüssel. Der Empfänger prüft die Signatur anhand des öffentlichen Schlüssels, der als DNS-TXT-Record veröffentlicht ist:

mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

mail ist der Selektor - er kann variieren (z. B. google für Google Workspace, mg für Mailgun).

DKIM bei managed Diensten: Google Workspace aktiviert DKIM über die Admin Console unter Apps > Gmail > Authentifizierung. Microsoft 365 verwendet zwei rotierende Selektoren (selector1, selector2) und stellt CNAME-Records bereit. Bei beiden Diensten wird der öffentliche DNS-Record direkt aus der Verwaltungskonsole kopiert.

DKIM auf eigenem Mailserver (Postfix):

apt install opendkim opendkim-tools
mkdir -p /etc/opendkim/keys/example.com
opendkim-genkey -s mail -d example.com
# Öffentlichen Schlüssel aus mail.txt in DNS eintragen

In /etc/opendkim.conf werden Domain, Schlüsselpfad und Selektor konfiguriert.

Key-Rotation: 1024-Bit-RSA-Schlüssel gelten als veraltet - der Wechsel auf 2048 Bit ist dringend empfohlen. Eine jährliche Rotation ist Best Practice. Dabei werden beide Selektoren kurzzeitig aktiv gehalten: Neuen aktivieren, alten abmelden, dann alten deaktivieren. DKIM verifizieren: dig TXT mail._domainkey.example.com.

Schritt 3: DMARC-Record erstellen

Der DMARC-Record wird als TXT-Record für _dmarc.example.com veröffentlicht. Der minimale Einstieg im Monitoring-Modus:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Ein vollständiger Record mit allen Parametern:

v=DMARC1;
p=quarantine;
pct=25;
sp=none;
adkim=r;
aspf=r;
rua=mailto:dmarc@example.com;
ruf=mailto:forensic@example.com;
fo=1;

Parameter im Überblick:

Parameter	Bedeutung
p=	Policy: none (nur Monitoring), quarantine (Spam-Ordner), reject (ablehnen)
pct=	Prozent der Mails, auf die die Policy angewendet wird
sp=	Subdomain-Policy (Standard: Wert von p=)
adkim= / aspf=	Alignment: r = relaxed (Org-Domain reicht), s = strict (exakte Domain)
rua=	Empfänger für Aggregate Reports (täglich, XML)
ruf=	Empfänger für Forensic Reports (optional, pro Fehler)
fo=	Forensic-Trigger: 0 = beide schlagen fehl, 1 = eines schlägt fehl

Relaxed vs. Strict Alignment: Im relaxed-Modus reicht es, wenn die Organisationsdomain übereinstimmt (mail.example.com passt zu example.com). Im strict-Modus muss die Domain exakt übereinstimmen - mail.example.com würde example.com nicht mehr abdecken.

Schritt 4: DMARC-Reports analysieren

Empfangende Mailserver wie Google, Microsoft und Yahoo senden täglich Aggregate Reports im XML-Format. Diese berichten für jede Quell-IP, wie viele E-Mails gesendet wurden und ob SPF und DKIM bestanden haben.

Beispiel-Interpretation eines XML-Reports: 450 Mails von einer bekannten Google-IP mit SPF- und DKIM-Pass sind legitimer Versand. 3 Mails von einer unbekannten IP mit DKIM- und SPF-Fail sind ein Hinweis auf Spoofing-Versuche oder einen vergessenen Mailsender, der noch nicht im SPF eingetragen ist.

Die rohen XML-Dateien sind schwer lesbar. Zur Auswertung empfehlen sich:

• Self-Hosted: parsedmarc + Elasticsearch/Kibana
• Kostenlos: Postmark DMARC (dmarcdigests.com), Google Postmaster Tools
• Günstig (SaaS): DMARC Analyzer / Mailhardener (ab 25 €/Monat), EasyDMARC (Freemium), Valimail Monitor (Freemium)
• Enterprise: Agari, Red Sift OnDMARC

pip install parsedmarc
parsedmarc -c parsedmarc.ini [email.xml]

Schritt 5: Rollout-Strategie

Der DMARC-Rollout erfolgt immer stufenweise. Zu schnelles Eskalieren auf p=reject führt dazu, dass legitime E-Mails abgelehnt werden, sobald ein Mailsender vergessen wurde.

Woche 1-4 - Monitoring-Phase (p=none): Alle Aggregate Reports sammeln. Alle sendenden Systeme identifizieren: E-Mail-Marketing (Mailchimp, HubSpot), CRM, Monitoring-Alerts, interne Formulare. SPF und DKIM für alle Sender korrekt eintragen. Ziel: 100 % DMARC-Pass für legitimen Versand.

Woche 5-8 - Quarantine 25%: p=quarantine; pct=25 - 25 % der DMARC-Fail-Mails landen im Spam-Ordner. Reports weiter analysieren: Kommen noch legitime Fails vor?

Woche 9-12 - Quarantine 75%: p=quarantine; pct=75 - Druck auf Angreifer steigt, letzte Problemquellen korrigieren.

Woche 13-16 - Quarantine 100%: Alle DMARC-Fails landen im Spam. Keine ungeplanten Ausfälle legitimer Mails mehr?

Woche 17+ - Reject (Vollschutz): p=reject - DMARC-Fail führt zur sofortigen Ablehnung. Spoofing der Domain ist technisch nicht mehr möglich.

Häufige Fehler beim Rollout:

• Zu schnell zu p=reject: ein vergessener Sender blockiert legitime E-Mails
• SPF-Lookup-Limit überschritten (mehr als 10 DNS-Lookups)
• Mailing-Listen brechen DKIM: Listen-Server schreiben Header um, die Signatur stimmt nicht mehr
• Subdomains vergessen: marketing.example.com sendet ohne DMARC-Alignment

Subdomains und Multi-Domain-Szenarien

Ein DMARC-Record für example.com gilt standardmäßig für diese Domain. Subdomains erben die Policy, können aber mit einem expliziten sp=-Parameter separat gesteuert werden:

v=DMARC1; p=reject; sp=none;

Hier gilt für die Hauptdomain reject, für Subdomains aber none - sinnvoll, wenn Subdomains noch konfiguriert werden. Eigene DMARC-Records für Subdomains (_dmarc.mail.example.com) überschreiben die geerbte Policy.

Multi-Domain-Umgebungen: Jede Domain braucht einen eigenen DMARC-Record. Auch die Deutschland-Domain example.de, Testdomains und Partnerdomains. Für inaktive ("geparkte") Domains, die nie E-Mails versenden, empfiehlt sich sofort p=reject mit einem SPF-Record ohne autorisierte IPs:

_dmarc.oldomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
oldomain.com TXT "v=spf1 -all"

So kann niemand im Namen der ungenutzten Domain versenden.

DMARC-Monitoring-Tools

KPIs für das laufende Monitoring:

• DMARC-Pass-Rate: Ziel >98 % für alle legitimen Sender
• Fail-Rate: senkt sich nach dem Rollout (abnehmender Spoofing-Traffic)
• Sources: alle bekannten Sender mit 100 % Pass-Rate?
• Forensic Reports (ruf): welche IPs spoofen die Domain aktiv?

Tool	Typ	Kosten
parsedmarc + Kibana	Self-Hosted, Open Source	Infrastrukturkosten
Google Postmaster Tools	SaaS, nur Google-Traffic	kostenlos
MXToolbox DMARC	Einzelprüfung	kostenlos
EasyDMARC	SaaS	Freemium
Valimail Monitor	SaaS	Freemium
DMARC Analyzer (Mailhardener)	SaaS	ab 25 €/Monat
dmarcian	SaaS	ab 249 $/Jahr
Agari / Red Sift OnDMARC	Enterprise SaaS	auf Anfrage