DMARC p=reject einführen ohne Mailverlust

Warum DMARC p=reject sein muss — und warum die meisten Domains es nicht sind

DMARC ist keine neue Technologie. Der Standard ist seit 2012 dokumentiert, und seit 2024 verlangen Google und Yahoo bei größeren Versendern explizit funktionierende DMARC-Authentifizierung als Voraussetzung für die Zustellung. Trotzdem stehen geschätzt 70 % aller deutschen Unternehmens-Domains noch auf p=none oder haben gar keinen DMARC-Record. Der Grund ist fast immer derselbe: Niemand traut sich, den Sprung auf p=reject zu machen, weil die Sorge groß ist, legitime Mails zu verlieren.

Diese Sorge ist berechtigt — wenn man unstrukturiert vorgeht. Mit dem richtigen Vorgehen ist p=reject für jede Domain in 3–4 Monaten erreichbar.

Dieser Beitrag beschreibt den Weg in drei Phasen, mit den häufigsten Stolperfallen und konkreten DNS-Beispielen.

Phase 1: p=none — die Beobachtungs-Phase

Der erste DMARC-Record für eine bisher ungeschützte Domain sieht typischerweise so aus:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:reports@example.com; ruf=mailto:forensic@example.com; fo=1; adkim=r; aspf=r; pct=100"

Was diese Konfiguration tut: Empfänger-Server (Gmail, Microsoft 365, Cisco ESA, Proofpoint etc.) prüfen jede eingehende Mail, die Ihre Domain als Absender angibt, gegen SPF und DKIM. Sie weisen die Mail nicht ab, auch wenn sie fehlschlägt — schicken aber Reports an die rua- und ruf-Adressen mit den Auswertungs-Daten.

Was Sie in dieser Phase tun: Die Reports auswerten, idealerweise über einen Aggregator wie dmarcian, EasyDMARC oder PowerDMARC. Die kostenlosen Tier-Pläne reichen für eine durchschnittliche KMU-Domain völlig aus. Manuelle Auswertung der XML-Reports ist theoretisch möglich, in der Praxis verschwendete Zeit.

Was Sie suchen: Alle legitimen Versender, die für Ihre Domain Mails verschicken. Die Liste ist immer länger, als die IT-Verantwortlichen vermuten. Typische Treffer:

• Marketing-Tools (Mailchimp, ActiveCampaign, HubSpot)
• CRM-Systeme mit Mail-Versand (Salesforce, Pipedrive)
• Buchhaltungs- und Rechnungs-Tools (Lexware, sevDesk, Stripe)
• Helpdesk- und Support-Systeme (Zendesk, Freshdesk)
• HR- und Recruiting-Plattformen (Personio, BambooHR)
• Vergessene Test- und Staging-Server, die Cron-Mails verschicken
• Drittanbieter-Apps mit „im Auftrag von"-Versand

Phase-1-Dauer: 4–6 Wochen. Kürzer geht nur, wenn die Domain nachweislich extrem niedriges Mail-Volumen hat.

Phase 2: SPF und DKIM für alle legitimen Quellen — das eigentliche Projekt

Phase 2 ist nicht eine DMARC-Phase, sondern die SPF- und DKIM-Aufräum-Phase. Hier wird klar, dass die meisten DMARC-Probleme keine DMARC-Probleme sind, sondern SPF- oder DKIM-Lücken.

Typische Maßnahmen:

1. SPF-Record konsolidieren: Pro Domain darf der SPF-Record maximal 10 DNS-Lookups verursachen. Mit Tools wie SPF-Macro-Resolvern oder Diensten wie EasyDMARC SPF-Checker finden Sie heraus, ob Ihre aktuelle Konfiguration drüber liegt. Lösung: Konsolidierung über Flattening-Services oder bewusst ausgewählte include:-Statements.
2. DKIM für jede legitime Quelle einrichten: Jeder Marketing-Tool-Anbieter hat dafür eine eigene Anleitung. Bei einer Bank-Domain mit drei Marketing-Tools, einem CRM, einem Helpdesk und einem Buchhaltungs-System sind das schon sechs verschiedene DKIM-Selectors.
3. DKIM-Selectors bewusst benennen: Statt default._domainkey lieber 2026q2-mailchimp._domainkey — das ermöglicht später saubere Schlüsselrotation und Audit-Nachvollziehbarkeit.

Erst wenn alle legitimen Versender SPF- oder DKIM-Pass haben, ist die Domain bereit für Phase 3. Häufiger Fehler: Phase 2 abkürzen, weil der Druck wächst, schon auf p=quarantine zu gehen. Das rächt sich.

Phase-2-Dauer: 4–8 Wochen für eine durchschnittliche Domain mit moderatem Tool-Stack.

Phase 3: p=quarantine als Brücke, dann p=reject

Sobald die Aggregate-Reports keine legitimen Versender mehr ohne Pass anzeigen, beginnt der Übergang. Statt direkt auf p=reject zu springen, gehen Sie über p=quarantine:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:..."

Mit pct=10 weisen Sie Empfänger-Server an, nur 10 % der nicht-bestandenen Mails in den Spam-Ordner zu legen. Wenn nach 1–2 Wochen keine Beschwerden über fehlgeleitete Mails kommen, erhöhen Sie auf pct=50, dann auf pct=100.

Der finale Sprung sieht so aus:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:...; ruf=mailto:...; fo=1; adkim=s; aspf=s; sp=reject"

Wichtige Details:

• adkim=s und aspf=s (statt r für relaxed) erzwingen Strict-Alignment — das ist der eigentliche Anti-Spoofing-Schutz.
• sp=reject setzt die Subdomain-Policy explizit, damit kein Angreifer über mail.example.com spoofen kann.
• fo=1 aktiviert Forensic-Reports auch dann, wenn nur eine der Authentifizierungen (SPF oder DKIM) fehlschlägt — wichtig für das Erkennen von Spoofing-Versuchen.

Die Forwarding-Edge-Cases — der eigentliche Stolperstein

DMARC scheitert strukturell an manchen Mailfluss-Pfaden. Die wichtigsten:

Mailing-Listen

Klassische Mailing-Listen (Mailman, ezmlm) ändern den Subject-Header („[Liste] ...") und den Body, was DKIM-Signaturen invalidiert. Lösung: ARC-Headers (Authenticated Received Chain), die moderne Mailing-Listen-Software unterstützt. Wenn Sie eigene Listen betreiben, prüfen Sie, ob ARC aktiviert ist.

Outlook-Auto-Forwarding

Wenn ein Empfänger seine Mails per Outlook-Regel an eine andere Adresse weiterleitet, verändern manche Forward-Setups Header so, dass DKIM bricht und SPF gegen die falsche IP prüft. Lösung: Empfänger sollten "Forward as attachment" oder Server-seitige Weiterleitungen mit Sender Rewriting Scheme (SRS) verwenden — was selten passiert.

Cisco-ESA-spezifisch: DKIM Forwarding

In Cisco-ESA-Umgebungen muss explizit konfiguriert werden, dass die ESA bei eingehenden Mails die DKIM-Signaturen nicht durch eigene Header-Manipulation invalidiert. Insbesondere die Anti-Spam-Fußzeilen-Funktion (Footer Stamping) bricht DKIM, wenn sie nach der Signatur-Prüfung aktiviert wird.

Was tun bei Anti-Phishing-Filtern, die DMARC ignorieren

Manche interne Mail-Server oder ältere Cisco-ESA-Konfigurationen ignorieren DMARC-Policy-Anweisungen, weil eigene Anti-Spam- oder Anti-Phishing-Regeln vorgehen. Das ist meist durch eine Mail-Flow-Policy in der ESA-Konfiguration verursacht. Im Cisco-ESA-Kontext setzen Sie unter Mail Policies → DMARC Verification Profile die DMARC-Aktion explizit auf „No Action" für eingehende Mails (wenn die Policy global gelten soll) oder auf „Reject" pro DMARC-Policy.

Fazit

p=reject ist mit einem strukturierten 3-Monats-Plan und einem Aggregate-Report-Tool für jede KMU-Domain erreichbar. Der schwierigste Teil ist nicht die DNS-Konfiguration, sondern die SPF- und DKIM-Konsolidierung in Phase 2 — und die ehrliche Dokumentation aller legitimen Versender, die in einem mittelständischen Unternehmen verstreut sind.

Wenn Sie die Aggregate-Reports nicht selbst auswerten wollen oder ein DMARC-Rollout für eine größere Domain mit Banking-, Versicherungs- oder Compliance-Hintergrund ansteht, übernehme ich das gerne als Festpreis-Engagement. Schreiben Sie kurz, wie Ihr Setup aussieht.