DMARC policy explained
dmarc policy · p=reject · email authentication
Understand p=, sp=, pct=, and how policy changes affect spoofed mail before you move from monitoring to enforcement.
Von DN01 Network Team
DMARC policy tells receivers what to do when SPF and DKIM alignment fail for the visible From domain. Der DN01 DMARC-Analyzer holt den _dmarc-TXT, parst Tags und hebt Policy sowie Alignment vor Enforcement hervor. Operatoren nutzen ihn bei Migrationen, Incident-Triage und Vendor-Onboarding, wenn wiederholbare Belege statt Einzelscreenshots gebraucht werden.
A published TXT record at _dmarc.example.com is useless without aligned SPF or DKIM success paths for legitimate senders.
Run the DMARC Analyzer on your domain, read p= and pct= separately, and only tighten policy after aggregate reports look stable. Kombinieren Sie DMARC-Ausgabe mit SPF- und DKIM-Validatoren derselben Domain für gemeinsame Auth-Fixes. Speichern Sie den Ergebnis-Permalink im Ticket, notieren Sie den Prüfzeitpunkt und vergleichen Sie die Ausgabe vor und nach Konfigurationsänderungen oder Client-Updates.
Wiederholen Sie die Prüfung nach jeder wesentlichen Änderung und bewahren Sie den Guide-Link im Team-Runbook, damit neue Operatoren dieselbe Diagnose-Reihenfolge einhalten.
Tags, die DN01 hervorhebt
Policy p= und Subdomain sp= definieren Empfängeraktionen; pct= begrenzt den Mail-Anteil während des Rollouts.
Alignment-Modi aspf und adkim steuern relaxed oder strict Matching zwischen authentifizierten Domains und sichtbarem From-Header.
Rollout-Fehler
Reject veröffentlichen, während Marketing oder Ticketing mit Vendor-DKIM senden, bricht legitime Mail in Spam-Ordnern.
Aggregate Reports ignorieren bedeutet, misaligned Quellen erst nach Beschwerden über fehlende Belege zu entdecken.
Sicherer Enforcement-Pfad
Starten Sie mit p=none und rua, fixen Sie Alignment für jeden genehmigten Sender, dann quarantine vor reject.
Nutzen Sie pct<100 nur als temporäre Brücke; dokumentieren Sie das Zieldatum für vollständiges Enforcement im Mail-Runbook.
Dokumentation und nächste Schritte
Archivieren Sie Checker-Ausgaben in Change-Tickets, Vendor-Reviews und Incident-Records, damit der nächste Operator dieselben geparsten Belege sieht.
Verlinken Sie diesen Leitfaden und die Tool-Landingpage in Team-Wikis und kombinieren Sie Ergebnisse mit anderen DN01-Diensten, wenn DNS, Mail, TLS oder Security betroffen sind. Notieren Sie Prüfer, verwendete Eingabe und ob der Ergebnis-Permalink mit dem Anfragenden geteilt wurde.
Wann eskalieren oder Checks kombinieren
Wenn die Ausgabe von DMARC-Analyzer nach Neustart oder Cache-Leerung weiter vom Nutzerbericht abweicht, erfassen Sie Zeitstempel, Roheingaben und den DN01-Permalink, bevor Sie Production-DNS, Mail, TLS oder Auth ändern.
Eskalieren Sie an Plattform- oder Identity-Owner, wenn Enterprise-Policy den Fix blockiert; andernfalls kombinieren Sie diesen Leitfaden mit angrenzenden DN01-DNS-, Mail-, TLS- oder Security-Tools, um den Loop in einem Ticket zu schließen.
| Policy | Typische Nutzung |
|---|---|
| p=none | Monitoring und rua sammeln |
| p=quarantine | Fehler in Spam abmildern |
| p=reject | Spoof blocken nach sauberem Alignment |
| pct<100 | Nur schrittweises Enforcement |
Häufig gestellte Fragen
- Ersetzt DMARC SPF oder DKIM?
Nein. DMARC hängt von SPF und DKIM plus Alignment mit der From-Domain ab.
- Soll jede Domain p=reject nutzen?
Viele sendende Domains sollten es, aber erst nach Reports mit aligned legitimer Mail ohne Überraschungsquellen.
- Warum pct separat zeigen?
reject mit pct=20 ist kein volles Enforcement. DN01 zeigt pct, damit Operatoren den Schutz nicht überschätzen.
- Kann ich Ergebnisse mit dem Team teilen?
Ja. Kopieren Sie die DN01-Ausgabe oder den Permalink in Tickets, damit alle dieselbe geparste Evidenz statt einzelner Screenshots sehen.