Stand: November 2026
Einleitung: Warum DMARC jetzt unverzichtbar ist
Wie führe ich DMARC sicher ein, ohne legitime Mails zu verlieren? Diese Frage treibt Administratoren seit Februar 2024 um. Google und Yahoo verlangen seitdem von Bulk-Sendern zwingend einen DMARC-Eintrag – mindestens p=none. Wer die Vorgabe ignoriert, riskiert Zustellprobleme bei den größten Postfachanbietern weltweit.
Der Standard selbst schreibt den schrittweisen Pfad vor. RFC 9989 und der kommende DMARCbis-Standard (dmarcbis-15) formulieren die Sequenz p=none → p=quarantine → p=reject als normative Empfehlung (SHOULD). Ein direkter Sprung auf reject führt regelmäßig zum Verlust erwünschter Nachrichten, weil SPF- oder DKIM-Alignment bei einzelnen Versandsystemen fehlt.
DMARC.org fasst das Prinzip zusammen: p=none sammelt nur Reports, blockiert nichts. Erst die Auswertung dieser Aggregate Reports (RUA) offenbart das vollständige Inventar aller sendenden Systeme – inklusive Shadow-IT. Darauf baut der weitere Rollout auf.
Dieser Guide liefert einen praxiserprobten 8-Schritte-Plan. Er deckt Monitoring, Alignment-Prüfung, pct-Ramp-up, Subdomain-Strategie und finales Enforcement ab. Grundlage sind die offiziellen Leitfäden von Microsoft, Google und der IETF-Community sowie deutsche Praxis-Leitfäden, die regulatorische Erwartungen (DSGVO, BSI) einbeziehen.
Bevor du startest: 3 Klärungsfragen
Bevor der erste _dmarc-Eintrag in der Zone landet, müssen drei Punkte stehen. Erstens: Welche Systeme versenden überhaupt im Namen der Domain? Neben dem MTA gehören Marketing-Plattformen, CRM, HR-Tools und Transaktionsdienste dazu – oft auch Shadow-IT, die erst durch p=none-Reports sichtbar wird. Zweitens: Stehen SPF und DKIM für alle legitimierten Quellen sauber inklusive Alignment? Häufige Stolpersteine sind das SPF-Lookup-Limit von 10, fehlende DKIM-Signaturen bei Drittanbietern oder gebrochene Forwarding-Ketten. Drittens: Existiert ein Postfach für Aggregate Reports (RUA) und idealerweise ein Parser, der XML/JSON in lesbare Dashboards überführt? Ohne Auswertetool bleibt die Inventarisierung Blindflug. Der Praxis-Guide von Moin-Inbox empfiehlt, die Monitoring-Phase mindestens zwei bis drei Wochen laufen zu lassen, bevor überhaupt an p=quarantine gedacht wird. Ucar Solutions bestätigt, dass ein stabiler Rollout auf reject typischerweise vier bis acht Wochen benötigt – vorausgesetzt, die Non-Compliance-Rate sinkt über 30 Tage unter ein Prozent.
Beispiel: Ein mittelständisches Unternehmen entdeckte via p=none-Reports 23 Versandquellen statt der angenommenen 7 – darunter ein veraltetes HR-Tool und eine nicht dokumentierte Marketing-Plattform. Zahl: Der DMARCbis-Entwurf fordert mindestens 1 Monat p=none, Praxis-Guides nennen 2–3 Wochen als Minimum.
Schritt 1: Inventur & Monitoring mit p=none
Setze initial den Record v=DMARC1; p=none; rua=mailto:dmarc-reports@deine-domain.de; ruf=mailto:dmarc-forensic@deine-domain.de. In dieser Phase – Praxis-Guides nennen 2 bis 3 Wochen, der DMARCbis-Entwurf fordert mindestens einen Monat – werden keine Mails blockiert oder quarantäniert. Der Modus dient reiner Beobachtung.
Die täglichen Aggregate Reports (RUA) liefern das vollständige Bild aller sendenden Quellen, inklusive Shadow-IT-Systeme, die IT-Abteilungen oft nicht auf dem Schirm haben. Prüfe die XML-Dateien täglich, ordne unbekannte IP-Adressen zu und überführe legitime Absender in eine Inventarliste. Ohne Auswertetool bleibt der Datenberg unübersichtlich; Dienste wie URIports, PowerDMARC oder DMARCFlow automatisieren das Parsen und visualisieren Alignment-Ergebnisse pro Quelle.
Erst wenn SPF und DKIM für alle erfassten Systeme sauber aligned sind, lohnt der nächste Policy-Schritt. Dokumentiere jede Quelle mit Volumen, Alignment-Status und Verantwortlichem – das Inventar wird später zur Checkliste für den Quarantine- und Reject-Rollout.
Beispiel: Ein E-Commerce-Shop sah täglich 12.000 Mails über p=none; 18 % kamen von einem veralteten Newsletter-Dienst ohne DKIM. Zahl: DMARCbis verlangt ≥ 1 Monat Monitoring; deutsche Guides (Moin-Inbox, Ucar) setzen 2–3 Wochen an.
Schritt 2: SPF & DKIM Alignment für alle Quellen herstellen
Bevor die DMARC-Policy schärfer greift, muss jede legitime Versandquelle aligned signieren. Alignment bedeutet: Die Domain im Return-Path (SPF) und die Domain im d=-Tag der DKIM-Signatur stimmen mit der Header-From-Domain überein – oder liegen auf einer Subdomain derselben Organisation. Fehlt das Alignment, zählt die Mail als nicht authentifiziert, auch wenn SPF oder DKIM einzeln pass liefern.
Ein klassischer Stolperstein ist das SPF-Lookup-Limit von 10 DNS-Abfragen. Jeder include-Mechanismus, jedes a– oder mx-Statement verbraucht einen Lookup. Überschreitet die Kette das Limit, verwerfen Empfänger den SPF-Check als permerror. Abhilfe schafft SPF-Flattening: Die aufgelösten IP-Netze werden direkt in den Record geschrieben, sodass nur noch ein Lookup nötig ist. Automatisierte Tools überwachen Änderungen bei den Anbietern und aktualisieren den flattening-Record fortlaufend.
DKIM-Seite: Drittanbieter – Newsletter-Dienste, CRM, Ticket-Systeme – signieren oft mit eigener Domain oder gar nicht. Fordert für jeden Dienst einen dedizierten Selektor an und publiziert den Public Key in eurer Zone. Die empfohlene Schlüssellänge beträgt 2048 Bit RSA; 1024 Bit gelten als angreifbar. Rotiert die Keys mindestens jährlich.
Forwarding bricht SPF, weil der Weiterleitender als neuer Absender auftritt. DKIM überlebt den Transport, sofern der Forwarder die Signatur nicht verändert (kein Re-Encoding, kein Footer-Injekt). Prüft deshalb regelmäßig die DMARC-Aggregate-Reports auf dkim=pass bei weitergeleiteten Mails.
Erst wenn 95 bis 98 % des legitimierten Volumens sowohl SPF- als auch DKIM-aligned durchlaufen, ist der Wechsel auf p=quarantine vertretbar. Ein Monitoring-Dashboard zeigt die Alignment-Quote je Quelle an und deckt Shadow-IT auf, die noch nicht inventarisiert ist.
Beispiel: Ein SaaS-Anbieter reduzierte SPF-Lookups von 14 auf 2 durch Flattening – permerror-Rate fiel von 12 % auf 0 %. Zahl: 95–98 % Alignment-Quote als Schwelle für Quarantine; DKIM-Schlüssel 2048 Bit RSA empfohlen.
Schritt 3: p=quarantine mit pct-Ramp-up einführen
Nach erfolgreichem Monitoring unter p=none folgt der erste Durchsetzungsmodus: p=quarantine. Der pct-Tag begrenzt die Wirkung auf einen Anteil der fehlgeschlagenen Nachrichten – Startwerte von pct=10 oder pct=5 sind üblich. Microsoft und Google empfehlen beide explizit, mit niedrigem Prozentsatz zu beginnen und wöchentlich um 10 bis 20 Prozentpunkte zu steigern, solange die Non-Compliance-Rate stabil unter 1 % bleibt (Microsoft Learn; Google Workspace).
quarantine bedeutet: Mails, die SPF/DKIM-Alignment verfehlen, landen im Spam- oder Junk-Ordner, nicht im Posteingang. Empfänger können sie dort noch retten – ein entscheidender Unterschied zu reject. In den Aggregate Reports (RUA) taucht nun das Disposition-Feld quarantine auf. Dessen Anteil gegenüber none muss fortlaufend überwacht werden; steigt er unerwartet an, deutet das auf eine noch nicht erfasste legitime Quelle hin.
Die Phase dauert mindestens zwei bis drei Wochen. Der kommende DMARCbis-Standard fordert sogar mindestens einen Monat p=quarantine vor dem finalen Sprung auf reject, um Dispositionsergebnisse über einen vollständigen Monatszyklus zu vergleichen. Erst wenn der Quarantäne-Anteil über mehrere Wochen stabil niedrig bleibt und keine neuen legitimen Sender mehr auftauchen, ist der nächste Schritt freigegeben.
Beispiel: Start mit p=quarantine; pct=5, wöchentliche Steigerung um 15 % (5→20→35→50→65→80→100). Zahl: DMARCbis fordert ≥ 1 Monat Quarantine; Microsoft/Google empfehlen 10–20 Prozentpunkte pro Woche.
Schritt 5: Reports analysieren & Non-Compliance unter 1 % drücken
Die tägliche Auswertung der Aggregate Reports (RUA) bleibt die Kernaufgabe. Ziel ist eine Non-Compliance-Rate – also Mails ohne SPF- oder DKIM-Alignment – die über 30 Tage stabil unter 1 % liegt. Parser-Dashboards wie URIports, DMARCFlow, EasyDMARC, Valimail, PowerDMARC, MDaemon oder Siller Consulting zeigen Quellen, Volumen, Disposition und Alignment-Status auf einen Blick. DMARCFlow empfiehlt, unbekannte Absender systematisch zu kontaktieren, fehlende DKIM-Signaturen oder SPF-Einträge nachzuziehen und nicht autorisierte Systeme abzuschalten. Erst wenn das Dashboard über den gesamten Beobachtungszeitraum grün signalisiert, ist der Wechsel auf p=reject verantwortbar. Wer die 1-%-Grenze zu früh für erreicht erklärt, riskiert Zustellverluste bei legitimen Mails – besonders bei Forwarding-Ketten oder veralteten Newsletter-Diensten. Ein 30-Tage-Fenster ohne Ausreißer schafft die nötige Sicherheit für den finalen Policy-Schritt.
Beispiel: Dashboard zeigte 0,8 % Non-Compliance über 30 Tage – Ursache war ein vergessenes Ticket-System ohne DKIM. Nach Nachrüstung sank Rate auf 0,1 %. Zahl: < 1 % Non-Compliance über 30 Tage stabil als Go-Kriterium für Reject.
Schritt 6: p=reject aktivieren – der finale Switch
Setzen Sie den DNS-Record auf p=reject; pct=100 oder erhöhen Sie pct schrittweise. Ab diesem Moment weisen empfangende MTAs nicht-aligned Mails mit SMTP 5xx zurück – sie landen weder im Spam-Ordner noch lassen sie sich durch den Empfänger retten.
Vor dem Umschalten prüfen Sie final: Liefern alle kritischen Quellen (Transactionals, Rechnungen, Passwort-Resets) konsistent aligned SPF und DKIM? Ist ein Rollback-Plan dokumentiert, der per DNS-Änderung sofort auf p=quarantine zurückfällt? Beachten Sie die TTL des Records, bis die Rücknahme global greift.
Praxis-Leitfäden zeigen zwei Tempo-Varianten: Ein aggressiver 30-Tage-Pfad von p=none bis reject skizziert Brew.new, während konservative Rollouts 4 bis 8 Wochen einplanen empfiehlt Ucar Solutions. Beide Ansätze setzen voraus, dass Sie während der p=quarantine-Phase die Dispositionsergebnisse täglich auswerten und keine unbekannten Volumen-Spitzen mehr sehen.
Halten Sie nach der Aktivierung das Monitoring scharf. Ein plötzlicher Anstieg gebounce-transaktionaler Mails signalisiert fehlendes Alignment bei einem Dienst – dann sofort per DNS auf p=quarantine zurückdrehen und die betroffene Quelle nachziehen.
Beispiel: TTL auf 300 s gesetzt; Rollback-Plan getestet – Umschaltung auf Quarantine brauchte 4 Minuten global. Zahl: Aggressiver Pfad 30 Tage; konservativ 4–8 Wochen (Ucar Solutions).
Schritt 7: Laufendes Monitoring, BIMI-Vorbereitung & DMARCbis-Compliance
Wer p=reject erreicht hat, darf die Überwachung nicht einstellen. Wöchentliche Report-Prüfungen bleiben Pflicht, um neue Versandquellen früh zu erkennen. Jeder neue Dienst durchläuft einen Onboarding-Prozess: SPF, DKIM und Alignment müssen vor dem ersten Versand stehen. Ein Policy-Überblick zeigt, dass BIMI (Brand Indicators for Message Identification) p=quarantine oder p=reject plus ein VMC-Zertifikat voraussetzt – ein starker Anreiz für konsequentes Enforcement.
Der kommende Standard DMARCbis (RFC 9989 / dmarcbis-15) verschärft die normative Sprache: Domains, die p=reject anstreben, sollen (SHOULD) zunächst mindestens einen Monat p=none, dann mindestens einen Monat p=quarantine betreiben und die Dispositionsergebnisse vergleichen. Ein Überblick zu DMARCbis fasst die neuen Empfehlungen zusammen. Wer diesen Pfad dokumentiert, schafft Compliance-Nachweise, die auch künftigen Auditoren standhalten.
Beispiel: Nach p=reject tauchte ein neues CRM-Modul auf – DKIM nachgerüstet innerhalb 24 h, keine Bounces. Zahl: DMARCbis: SHOULD ≥ 1 Monat none + ≥ 1 Monat quarantine; BIMI erfordert VMC-Zertifikat + p=quarantine/reject.
Checkliste: Go/No-Go für jeden Policy-Schritt
Bevor Sie die Policy anheben, prüfen Sie jeden Punkt:
- [ ] Alle sendenden Systeme inventarisiert (via
p=noneReports) - [ ] SPF bleibt unter 10 Lookups, DKIM nutzt 2048 Bit, Alignment bei 100 % kritischer Quellen
- [ ] RUA-Postfach plus Parser-Tool läuft
- [ ] Non-Compliance-Rate unter 1 % über 30 Tage stabil
- [ ] Subdomain-Strategie definiert,
sp-Tag gesetzt - [ ] Rollback-Plan dokumentiert (DNS-TTL unter 300 s)
- [ ] Stakeholder (IT, Marketing, Security, Legal) informiert
- [ ] Nächster Review-Termin im Kalender
Für Deep-Dives liefern Moin-Inbox und a7.de praxisnahe deutsche Guides.
Comments are closed, but trackbacks and pingbacks are open.