Glossary term
DMARC forensic reports: per-message failure samples, rarely sent
What DMARC forensic reports are
DMARC forensic reports, also called failure reports, are per-message notifications that a receiving server can send when an individual message fails DMARC evaluation for your domain. Where the aggregate report is a daily statistical summary, the forensic report is a sample of the actual failing message: its headers, sometimes part of its body, wrapped in a structured format and mailed to you at failure time.
You request them with the ruf tag in your DMARC record:
_dmarc.yourbrand.com. TXT "v=DMARC1; p=quarantine; rua=mailto:agg@yourbrand.com; ruf=mailto:fail@yourbrand.com"
RFC 7489 defines the tag; the report body follows the Abuse Reporting Format family (AFRF, per RFC 6591), carrying the failed message or its headers as an attachment together with metadata about which check failed and where.
The honest status in 2026: forensic reporting is a minority practice.
Most large mailbox providers, Google among them, do not send ruf
reports at all, primarily for privacy reasons — a forwarded copy of a
real message can contain personal data belonging to people who never
consented to your receiving it. Publish the tag if you have a process for
the reports; expect a trickle, not a stream.
How forensic reports differ from aggregate reports
The two report types split cleanly across four dimensions.
Granularity. Aggregate reports count traffic in groups: this IP, this many messages, these verdicts. Forensic reports are one report per failing message, with the message itself attached.
Trigger. Aggregate reports cover everything observed for your domain, passes included, on a fixed interval. Forensic reports fire only on failure, immediately.
Privacy surface. Aggregate reports carry no content and no recipient addresses. Forensic reports can carry both, which is exactly why providers hesitate: RFC 7489 itself flags the exposure, and receivers that do send apply redaction of varying aggressiveness.
Support. Aggregate reporting is near-universal among DMARC-checking receivers. Forensic reporting is sparse and shrinking, dominated by a handful of smaller and regional providers.
The planning consequence: aggregate reports are load-bearing
infrastructure for a DMARC rollout, forensic reports are opportunistic
extra detail. Any monitoring design that requires ruf data to
function is built on a source most of your traffic will never generate.
How DMARC forensic reports work
Requesting. Add ruf=mailto: URIs to the DMARC record. The same
external-destination rule as rua applies: reports crossing domains
require the destination's consent record. Verify the record's syntax
with a DMARC checker.
The fo tag. RFC 7489's fo tag tunes when a participating receiver
should generate a failure report:
fo=0(default): only when both aligned mechanisms fail — the message failed DMARC outright.fo=1: when any mechanism fails, even if the other passed and DMARC as a whole succeeded.fo=d: on any DKIM signature failure, regardless of alignment.fo=s: on any SPF failure, regardless of alignment.
fo=1 is the debugging setting — it surfaces the partial failures that
fo=0 hides, useful while chasing an alignment problem on one mechanism.
Delivery and contents. A participating receiver mails each report as it happens: metadata identifying the reporter, the source IP, the failed check, plus the sampled message — full or headers-only, redacted at the receiver's discretion. Recipient addresses are commonly masked.
Handling. Because reports contain message material, the receiving
mailbox is sensitive by construction. Route ruf to a restricted
address, not a shared team inbox, and fold anything useful into the same
investigation workflow your aggregate data feeds.
Forensic reports and your deliverability
Used within their limits, failure reports answer one question aggregate data cannot: what did the failing message actually look like?
During an alignment investigation, a single forensic sample can collapse
hours of guesswork — the report shows the exact
From: header, the envelope domain, the
DKIM selector that signed, and which link in
the chain broke. When aggregate reports
show a mystery source failing, a forensic sample from a smaller receiver
sometimes names the tool outright, via a header fingerprint or a
signature domain you recognize.
For spoofing response, samples show the payload: what the phish claims,
which brand assets it steals, where its links point. Security teams value
ruf for exactly this, subject to the coverage caveat — the campaigns
you most want samples of are aimed at providers that do not send them.
What forensic reports do not do is move placement. They are diagnostic
exhaust, not a signal receivers score. The deliverability work they support (closing alignment gaps, reaching enforcement, protecting domain reputation) runs on the aggregate
stream, with ruf as occasional magnification. If a failing source needs
live inspection today, sending a test through the
email authentication checker or
reading a delivered message's headers in the
email header analyzer is faster than
waiting for a report that may never come.
Limitations and failure modes
Expecting coverage. The defining failure: treating ruf as a
reliable feed. Google does not send failure reports; several other
majors likewise. Silence in your forensic mailbox is the default state,
not evidence of clean traffic — the aggregate stream is where absence
of failures means something.
Privacy handling as an afterthought. Forensic reports can contain
personal data of your recipients and of spoofing victims. Piping them
into a ticketing system, a shared inbox or a third-party parser without
a data-protection review creates exposure that the reports' modest value
rarely justifies. This is also why several report-processing vendors
refuse ruf entirely.
The fo=1 firehose misread. Setting fo=1 during debugging and
forgetting it: every forwarded message that breaks SPF now generates
reports from participating receivers, and the mailbox fills with routine
indirect-flow noise that looks alarming. RFC 7960's catalog of benign
breakage applies here in per-message form.
Redaction surprises. Receivers redact differently — some strip bodies, some mask addresses, some send headers only. Tooling that assumes one shape breaks on the next reporter.
Unmonitored sensitive mailbox. The ruf address gathering samples
for years, unread, holding message content nobody remembers requesting.
If there is no process consuming the reports, the cleaner configuration
is no ruf tag at all.
Confusing report volume with attack volume. Forensic report counts reflect which receivers participate, not how much spoofing exists. Volume questions belong to aggregate data; forensic data answers only "show me one."
Related terms
DMARC, DMARC aggregate reports, SPF alignment, DKIM alignment, DKIM selector, return-path, domain reputation, ARC.
Frequently asked questions
Should I add a ruf tag to my DMARC record?
Only if a defined process will consume the reports — a security workflow
with appropriate data handling. For pure deliverability monitoring,
rua alone is the standard configuration and loses you very little.
Why am I receiving no forensic reports?
Because most receivers do not send them. Google and several other major
providers generate aggregate reports only. A quiet ruf mailbox is
expected even for a heavily spoofed domain.
What is the difference between ruf and rua?
rua requests periodic aggregate summaries of all traffic; ruf
requests per-message samples of failures. Aggregate reports are broadly
supported and content-free; forensic reports are sparse and carry
message material.
What does the fo tag do?
It sets the failure-report trigger: 0 for full DMARC failure only
(default), 1 for any single mechanism failing, d and s for DKIM-
or SPF-specific failures. fo=1 is useful temporarily while debugging
one mechanism's alignment.
Are forensic reports a GDPR problem? They can contain personal data, so they enter data-protection scope the moment you receive them. Redaction practices vary by reporter. Restrict the destination mailbox, define retention, and involve whoever owns privacy compliance before wiring them into third-party tools.
Can I use forensic reports to measure spoofing volume? No — their volume measures reporter participation, not attack size. Use aggregate reports for volume and sources; use any forensic samples that arrive as qualitative illustrations.
If your DMARC record carries a ruf tag today, check two things this
week: that a real process reads the mailbox, and that whatever lands
there is handled as sensitive data. If either check fails, drop the tag
and put the attention into your
aggregate reports — that is where
the rollout actually lives.