DMARC in der Praxis — Lehren der ersten DACH-Anwender

DMARC ist seit 2012 als Standard etabliert, aber die breite Implementierung in der DACH-Region ist erst in den letzten Jahren wirklich angekommen — getrieben durch die Gmail/Yahoo-Anforderungen seit Februar 2024 und die wachsende Besorgnis über Phishing-Attacken in deutschen Unternehmen. Dieser Beitrag fasst die operativen Lehren der ersten Adopter-Welle zusammen.

Was DMARC tut — und was nicht

DMARC ist eine Authentifizierungs-Policy, die auf SPF und DKIM aufbaut. Es teilt Empfänger-Servern mit, was sie tun sollen, wenn eine Nachricht von Ihrer Domain weder SPF- noch DKIM-Alignment besteht: p=none (nichts tun, nur reporten), p=quarantine (in Spam-Ordner), p=reject (komplett ablehnen).

Wichtig zu verstehen: DMARC bewertet die Domain im From-Header, nicht im Envelope-From. Ein Angreifer, der sich als vorstand@ihr-unternehmen.de ausgibt, wird durch DMARC blockiert — sofern Ihre Policy auf p=reject steht und Sie SPF/DKIM korrekt konfiguriert haben.

Der typische DMARC-Pfad in DACH-Unternehmen

Phase 1 (Wochen 1-2): Inventarisierung

Bevor Sie DMARC publizieren, müssen Sie alle Versand-Quellen für Ihre Domain identifizieren. Klassische Quellen: ERP-System, CRM, Marketing-Plattform, interner Mailserver, Hosting-Provider, externe Dienstleister (Steuerberater). Das Inventar wird oft länger als erwartet — typisch 8-15 Quellen für mittelständische Unternehmen.

Phase 2 (Wochen 3-4): DMARC mit p=none publizieren

Erste Policy: v=DMARC1; p=none; rua=mailto:dmarc@ihr-unternehmen.de; fo=1. Der entscheidende Teil ist rua — die Aggregat-Reports von Empfänger-Servern.

Phase 3 (Wochen 5-12): Reports auswerten und Lücken schließen

Tools wie dmarcian, Postmark DMARC Digests, oder Open-Source-Lösungen wie parsedmarc helfen bei der Auswertung. Typische Lücken: SPF-Eintrag enthält nicht alle Quellen, DKIM signiert mit Anbieter-Domain statt eigener.

Phase 4 (Wochen 12-16): Übergang zu p=quarantine

Sobald die Reports zeigen, dass alle legitimen Quellen authentifiziert sind, kann auf p=quarantine; pct=10 umgestellt werden — 10% der nicht-authentifizierten Mails landen im Spam. Über Wochen wird pct auf 25, 50, 100 erhöht.

Phase 5 (Wochen 16-20+): Übergang zu p=reject

Endgültiges Ziel: p=reject. Falls eine legitime Versand-Quelle vergessen wurde, gehen ihre Mails verloren. Daher die langen vorherigen Phasen mit Reports.

Häufige Fehler in der DACH-Praxis

Fehler 1: SPF mit zu vielen Includes. SPF erlaubt maximal 10 DNS-Lookups. Bei vielen Versand-Quellen wird dieses Limit schnell erreicht. Lösung: SPF-Flattening.

Fehler 2: DKIM mit Anbieter-Domain. Wenn Mailchimp standardmäßig konfiguriert ist, signiert es mit d=mcsv.net statt mit Ihrer Domain. Custom DKIM mit Ihrer Domain ist Pflicht für DMARC-Erfolg.

Fehler 3: Subdomain-DMARC vergessen. Lösung: sp=reject in der Hauptdomain-Policy explizit setzen.

Fehler 4: Forwarding zerstört SPF-Alignment. DKIM überlebt typisch das Forwarding. Daher ist Custom DKIM mit Alignment kritisch.

DMARC und die Februar-2024-Regel

Seit Februar 2024 verlangen Gmail und Yahoo für Bulk-Sender (5.000+ Nachrichten/Tag) eine veröffentlichte DMARC-Policy mit mindestens p=none. Plus: Beschwerde-Quote unter 0,3% und funktionierender Opt-Out via List-Unsubscribe-Post (RFC 8058).

DMARC und DSGVO-Aspekte

DMARC-Aggregat-Reports enthalten IP-Adressen — also potenziell personenbezogene Daten. Verarbeitung gestützt auf Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse). Aufnahme in das Verarbeitungsverzeichnis ist notwendig. Bei externen DMARC-Verarbeitern ist ein AVV nach Art. 28 DSGVO Pflicht. Bei US-Anbietern zusätzlich Schrems-II-Aspekte.

Was wir gelernt haben

Die DACH-Unternehmen, die DMARC erfolgreich auf p=reject bringen konnten, haben gemeinsame Charakteristika: ein zentralisiertes Inventory aller Versand-Quellen, klare Verantwortlichkeit, und Geduld bei der Phase-by-Phase-Umstellung. Versuche, DMARC schnell auf p=reject zu setzen, haben fast immer zu verlorenen Mails geführt. Empfehlung: 4-6 Monate budgetieren.