DMARC rua and ruf reports
dmarc rua · dmarc ruf · aggregate reports
How to publish rua and ruf mailto targets, what reports contain, and why forensic reports are often disabled.
Von DN01 Network Team
rua aggregate reports show which sources send mail claiming your domain, while ruf forensic reports can include message fragments and raise privacy concerns. 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.
Many teams start with rua only, tune SPF and DKIM alignment from the data, and keep ruf disabled unless legal and security approve retention.
Confirm rua addresses in the DMARC Analyzer output, verify the mailbox accepts reports, and document who reviews weekly XML aggregates. 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.