Add ruf=mailto:forensic@yourdomain.com to your DMARC record to request per-failure reports in Abuse Reporting Format (ARF/AFRF); keep it separate from rua= to simplify triage.
Understand that forensic reports may include message headers, subject lines, and partial body content—treat all ruf data as potentially containing personal data subject to GDPR/CCPA.
Major providers including Google and Microsoft do not send forensic reports; expect ruf reports mainly from smaller or self-hosted mail servers, so coverage is partial at best.
Parse ARF-format reports: each report is a multipart MIME message; the first part is human-readable, the second part (message/feedback-report) contains machine-readable fields like Feedback-Type and Source-IP.
Use ruf data for short-term incident response (identifying a specific phishing wave) rather than ongoing monitoring; delete raw reports after 30 to 90 days to limit PII retention.
If forensic reports are not needed operationally, omit the ruf= tag entirely; many security teams disable it to reduce PII handling obligations.
Known gotchas
Because Google (Gmail) has never sent RUF reports for privacy reasons, ruf= data gives a misleading picture of your attack surface—the absence of reports does not mean no spoofing is occurring.
Some receivers redact subject lines and recipient addresses before sending; [REDACTED] strings in forensic reports are expected and do not indicate a parsing error.
Publishing ruf= creates a legal obligation to handle any PII that arrives; document your retention policy and encryption-at-rest posture before enabling it.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp