DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC ist ein E-Mail-Authentifizierungsprotokoll, das auf SPF und DKIM aufbaut und Domaininhabern Kontrolle über den Umgang mit nicht-authentifizierten E-Mails gibt.
DMARC (Domain-based Message Authentication, Reporting and Conformance) ist ein E-Mail-Authentifizierungsprotokoll (RFC 7489), das SPF und DKIM zu einem durchsetzbaren Schutzmechanismus verbindet. DMARC gibt Domain-Inhabern erstmals die Kontrolle darüber, was mit E-Mails passiert, die im Namen ihrer Domain versendet werden, aber die Authentifizierungsprüfungen nicht bestehen - und liefert gleichzeitig detaillierte Berichte über alle Authentifizierungsversuche weltweit.
Wie funktioniert DMARC
DMARC fügt eine entscheidende Schicht hinzu, die SPF und DKIM allein nicht bieten: einen Policy-Mechanismus. Ohne DMARC hat ein SPF- oder DKIM-Fail keine automatische Konsequenz; der Mailserver des Empfängers entscheidet selbst. Mit DMARC gibt der Domain-Inhaber explizite Anweisungen.
DMARC-Prüfablauf:
1. E-Mail trifft beim empfangenden Server ein
From: absender@beispiel.de
2. Server prüft SPF:
Ist der sendende Server für den Envelope-From autorisiert?
→ SPF-Ergebnis: pass oder fail
3. Server prüft DKIM:
Ist eine gültige DKIM-Signatur vorhanden?
→ DKIM-Ergebnis: pass oder fail
4. DMARC-Alignment-Check:
Stimmt die Domain aus SPF (Return-Path) mit From: überein?
Stimmt die Domain aus DKIM (d=) mit From: überein?
→ Mindestens EINE Prüfung muss bestehen UND aligned sein
5. DNS-Lookup DMARC-Record:
_dmarc.beispiel.de IN TXT "v=DMARC1; p=reject; ..."
6. Policy anwenden:
DMARC pass → E-Mail zustellen
DMARC fail → Policy aus Record: none / quarantine / reject
7. Bericht generieren:
Empfangender Server sendet aggregierten Report an rua=-AdresseDMARC-Alignment im Detail
Das Alignment ist das Herzstück von DMARC. Es verhindert, dass Angreifer eine technisch korrekte SPF/DKIM-Prüfung bestehen, aber einen gefälschten From:-Header verwenden.
Alignment-Prüfung (relaxed, Standard):
SPF-Alignment:
From: absender@beispiel.de
Return-Path (Envelope-From): bounce@mail.beispiel.de
→ Org-Domain beider: beispiel.de → SPF-Alignment PASS
DKIM-Alignment:
From: absender@beispiel.de
DKIM-Signature d=mail.beispiel.de
→ Org-Domain beider: beispiel.de → DKIM-Alignment PASS
DMARC-Ergebnis:
Mindestens eine Prüfung (SPF oder DKIM) muss aligned sein
→ Beide fail → DMARC fail → Policy anwenden
Strict Alignment (aspf=s oder adkim=s im DMARC-Record):
From: absender@beispiel.de
Return-Path: bounce@mail.beispiel.de → FAIL (Subdomain ≠ Domain)
DKIM d=mail.beispiel.de → FAIL (Subdomain ≠ Domain)
Nur bei exakter Übereinstimmung: PASSDMARC-Policies
p=none (Beobachtungsmodus):
→ E-Mail wird normal zugestellt, unabhängig vom Ergebnis
→ Keine Ablehnung, keine Quarantäne
→ Zweck: Einstieg, Monitoring, Reports sammeln
→ Empfehlung: Startphase, bis Reports ausgewertet sind
p=quarantine (Quarantäne):
→ DMARC-fail → E-Mail landet im Spam/Junk-Ordner
→ E-Mail wird zugestellt, aber als verdächtig markiert
→ Zweck: Übergangsphase, nachdem p=none analysiert wurde
p=reject (Ablehnung):
→ DMARC-fail → E-Mail wird vom empfangenden Server abgelehnt
→ Absender erhält bounce (5xx SMTP-Fehler)
→ Stärkstmöglicher Schutz: verhindert Domain-Spoofing vollständig
→ Empfehlung: Ziel jeder Domain nach abgeschlossener Implementierung
pct= (Prozentsatz):
→ Policy gilt nur für X% aller DMARC-fail E-Mails
→ Ermöglicht schrittweises Rollout: pct=10, dann pct=50, dann pct=100
→ Standard: pct=100 (gilt für alle)
→ Beispiel: p=reject; pct=10 (zunächst nur 10% abgelehnt)DMARC-Record Aufbau
Minimaler DMARC-Record:
_dmarc.beispiel.de IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de"
Vollständiger DMARC-Record mit allen Parametern:
_dmarc.beispiel.de IN TXT "v=DMARC1; p=reject; pct=100; \
rua=mailto:dmarc-agg@beispiel.de; \
ruf=mailto:dmarc-forensic@beispiel.de; \
aspf=r; adkim=r; fo=1; rf=afrf; ri=86400"Parameter-Referenz:
v=DMARC1 Protokollversion (zwingend, immer "DMARC1")
p= Policy für die Domain (none/quarantine/reject)
sp= Policy für Subdomains (falls abweichend von p=)
Standard: sp= erbt Wert von p=
pct= Prozentualer Anteil (1-100), Standard: 100
Reporting:
rua= Aggregated Reports (XML-Berichte, täglich)
Format: mailto:adresse@domain.de
Mehrere: rua=mailto:a@domain.de,mailto:b@domain.de
ruf= Forensic Reports (Einzel-E-Mail-Reports bei Fail)
Datenschutz beachten: enthalten E-Mail-Inhalte!
fo= Failure Reporting Options:
fo=0 Bericht nur wenn SPF UND DKIM fail (Standard)
fo=1 Bericht wenn SPF ODER DKIM fail
fo=d Bericht wenn DKIM fail
fo=s Bericht wenn SPF fail
rf=afrf Report-Format: afrf (Authentication Failure Reporting Format)
ri=86400 Report-Interval in Sekunden (Standard: 86400 = 24h)
Alignment:
aspf=r SPF-Alignment: r=relaxed (Standard), s=strict
adkim=r DKIM-Alignment: r=relaxed (Standard), s=strictDMARC-Reports verstehen
DMARC generiert zwei Berichtstypen, die wertvolle Einblicke in den E-Mail-Versand der eigenen Domain geben.
Aggregated Reports (rua=):
Format: XML, wird täglich von jedem großen Mailprovider gesendet
Inhalt:
- Absender-IP-Adresse
- Anzahl E-Mails von dieser IP
- SPF-Ergebnis + Alignment
- DKIM-Ergebnis + Alignment
- Angewendete DMARC-Policy
- Verwendete Header-From-Domain
Typische Quellen:
→ Google (gmail.com) sendet Berichte für alle Gmail-empfangenen Mails
→ Microsoft (outlook.com, hotmail.com)
→ Yahoo, Apple iCloud, weitere große Provider
Nutzen:
→ Nicht-autorisierte Sender entdecken (Phishing auf eigene Domain!)
→ Fehlkonfigurierte eigene Dienste finden
→ Vollständigkeit der DKIM/SPF-Konfiguration prüfen
Forensic Reports (ruf=):
Format: AFRF (Application/delivery-status), enthält E-Mail-Header
Inhalt: Reduzierte Kopie der fehlgeschlagenen E-Mail
Datenschutz: Können personenbezogene Daten enthalten!
Viele Provider senden keine ruf= (Datenschutzbedenken)
Empfehlung: Nur für gezielte Fehlersuche aktivierenImplementierungs-Schritte
Eine DMARC-Implementierung sollte schrittweise erfolgen, um legitimen E-Mail-Versand nicht zu unterbrechen.
Phase 1 - Inventarisierung (Woche 1-2):
Alle E-Mail-Quellen identifizieren:
→ Haupt-Mailserver (Exchange, Postfix, o365)
→ CRM-Systeme (Salesforce, HubSpot)
→ E-Mail-Marketing (Mailchimp, Brevo, CleverReach)
→ Ticketsysteme (Zendesk, Freshdesk)
→ Monitoring-Systeme, Webserver-Kontaktformulare
→ Rechnungsstellungs-Software
Phase 2 - SPF einrichten:
→ SPF-Record erstellen (alle Quellen aus Phase 1)
→ Lookup-Count prüfen (max. 10)
→ Mit -all oder ~all starten
→ Testen: mxtoolbox.com/spf
Phase 3 - DKIM aktivieren:
→ Auf allen sendenden Systemen DKIM-Signierung einrichten
→ DNS TXT-Records veröffentlichen
→ Bei Drittanbietern: Custom Domain Signing konfigurieren
→ Testen: mail-tester.com, mxtoolbox.com/dkim
Phase 4 - DMARC im Monitoring-Modus:
→ DMARC-Record mit p=none + rua= veröffentlichen
_dmarc.beispiel.de TXT "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de"
→ 2-4 Wochen Reports sammeln und auswerten
→ DMARC-Analysetools nutzen (dmarcian, Mimecast DMARC Analyzer, Google Postmaster)
Phase 5 - Schrittweise Verschärfung:
→ Alle nicht-authentifizierten Quellen bereinigt?
p=quarantine; pct=25 (25% in Quarantäne)
p=quarantine; pct=100
p=reject; pct=25
p=reject; pct=100
Phase 6 - Enforcement (Ziel):
→ p=reject; pct=100
→ Domain ist vollständig gegen Spoofing geschützt
→ Subdomains prüfen: sp=reject für Subdomains ohne E-Mail-VersandHäufige Fehler bei der DMARC-Implementierung
Fehler 1: Zu schnell zu p=reject
Problem: Nicht alle E-Mail-Quellen waren im SPF/DKIM erfasst
Folge: Legitime E-Mails (z.B. vom CRM) werden abgelehnt
Lösung: p=none Phase nicht überspringen, Reports auswerten
Fehler 2: rua= zeigt auf nicht existierende Adresse
Problem: Reports kommen an, niemand liest sie
Folge: Konfigurationsprobleme werden nicht entdeckt
Lösung: Dedizierte Mailbox oder DMARC-Analyse-Tool nutzen
Fehler 3: SPF-Lookup-Limit überschritten
Problem: SPF gibt permerror zurück
Folge: DMARC-SPF-Alignment immer fail, obwohl Absender autorisiert
Lösung: SPF-Record flattening oder Lookup-Count reduzieren
Fehler 4: Drittanbieter ohne Alignment
Problem: Newsletter-Provider signiert mit eigener Domain (d=newsletter.com)
Folge: DKIM-Alignment fail für DMARC, selbst bei DKIM-pass
Lösung: Custom Domain Signing beim Anbieter einrichten (meist CNAME-Eintrag)
Fehler 5: Subdomains vergessen
Problem: p=reject gilt für hauptdomain.de, aber nicht für *.hauptdomain.de
Folge: Angreifer können mail@subdomain.hauptdomain.de spoofed senden
Lösung: sp=reject im DMARC-Record, oder eigene DMARC-Records für SubdomainsDMARC und BIMI
DMARC mit p=reject ist die Voraussetzung für BIMI (Brand Indicators for Message Identification) - ein neuerer Standard, der es ermöglicht, das eigene Unternehmenslogo direkt im Posteingang des Empfängers anzuzeigen.
BIMI-Anforderungen:
1. DMARC mit p=quarantine oder p=reject (pct=100)
2. BIMI-Record im DNS:
default._bimi.beispiel.de IN TXT "v=BIMI1; l=https://beispiel.de/logo.svg"
3. Logo: SVG-Format (Tiny PS Profil), quadratisch, HTTPS
4. Optional: VMC (Verified Mark Certificate) von DigiCert oder Entrust
→ Nur mit VMC wird Logo in Gmail, Apple Mail angezeigt
→ Kosten: ~1.000-1.500 EUR/Jahr
BIMI-Nutzen:
→ Vertrauenswürdigkeit beim Empfänger steigt
→ Höhere Öffnungsraten (Studien: +10% bei verifizierten Logos)
→ Brand-Protection: erschwert Imitatoren
Provider-Support (Stand 2025):
Gmail, Apple Mail, Yahoo Mail: BIMI mit VMC wird angezeigt
Outlook/Hotmail: BIMI noch nicht unterstütztDMARC ist heute kein optionales “Nice-to-have” mehr, sondern eine Mindestanforderung professioneller E-Mail-Infrastruktur. Google und Yahoo haben seit Februar 2024 für alle Absender mit mehr als 5.000 E-Mails täglich eine DMARC-Policy als Pflicht eingeführt - ohne DMARC-Record werden Massen-E-Mails an Gmail und Yahoo abgelehnt oder landen zuverlässig im Spam. Unternehmen, die ihre Domain noch nicht mit DMARC schützen, riskieren sowohl die Zustellbarkeit legitimer E-Mails als auch den Missbrauch ihrer Domain für Phishing-Kampagnen gegen ihre eigenen Kunden und Partner.
