Forensic reports (also called RUF reports, after the ruf= tag in a DMARC record) are samples of individual emails that failed authentication. When a receiving mail server sees a message that claims to come from one of your domains but does not pass the checks, some receivers send back a copy of that one message. Unlike aggregate (RUA) reports, which give you the numbers and trends, a forensic report is about a single message and can include the recipient address, the original subject and the raw headers. DMARCER gathers these, lists them by domain, and helps you work out whether each one is a false alarm, a genuine sender that has not been set up correctly, or someone spoofing your domain.
What the Forensic Reports page shows
Open Forensic (RUF) Reports from the navigation. The table lists one row per domain that has received at least one forensic report, with these columns:
- Domain: the domain the reports relate to.
- Reports: the total number of forensic reports received for that domain.
- Unreviewed: how many still need a look. This shows as an amber badge when there are any, and a green zero once you are all caught up.
- Latest: when the most recent report arrived.
Click a row, or the View button, to open the detail window for that domain. Because forensic reports contain other people's personal data, you need a dedicated Forensic.View permission to see them, which Tenant Admins have by default. Every time someone opens an individual report, DMARCER keeps a record of it, so there is always a clear trail of who viewed which report.
Reading a single report
At the top of the detail window is a Report dropdown. Each entry shows the arrival time, the source IP and a snippet of the subject, with a tick next to reports you have already reviewed. Pick one to load it. The report is laid out in clear sections:
- Failure analysis: an instant verdict worked out by DMARCER's own built-in checks (labelled Deterministic, which simply means it follows fixed rules and does not use AI). It gives a headline verdict, a one-line summary, a breakdown of SPF, DKIM and DMARC, and recommended next steps.
- Summary: arrival time, the date the report is scheduled to be deleted, the reported domain, the source IP, and extra detail we add about that IP (country, city, network and ASN). Details we have added carry a small DMARCER chip and a faint blue tint, so you can tell at a glance which came from us rather than from the receiver's report.
- Original message: the subject, the From and Envelope From addresses, the recipient (To) and the Message-Id, plus a collapsible Original headers (raw) panel when the receiver included the headers.
- Authentication results: a table of each method (SPF, DKIM, DMARC and sometimes reverse DNS) with the domain checked and the pass or fail result the receiver recorded.
[Screenshot: a forensic report open in the detail window, showing the AI analysis card, the Failure analysis card and the authentication results table]
What the verdict means
The Failure analysis card turns the authentication results into one of four verdicts. DMARCER works out alignment (whether the domain that passed actually matches your From address) for itself, so its verdict can sometimes differ from what the receiver reported, as receivers often record a broad label rather than the true outcome:
- Likely a false-positive forensic report (green): DMARCER's checks say the message would actually pass DMARC. Some receivers send a forensic sample even for messages they go on to deliver.
- Failing but likely legitimate, alignment broken (amber): SPF or DKIM passed, but the domain that passed does not match your From address. This is the classic sign of a forwarder, mailing list or third-party sender (such as a marketing or SaaS tool) that has not yet been set up to send using your domain.
- Likely spoofing (red): neither SPF nor DKIM passed. The sending IP is not authorised and there is no valid signature. This is exactly what DMARC is designed to block.
- Inconclusive (grey): the results do not fit a clear pattern. Review the individual checks and the original headers to decide whether anything needs doing.
Optional AI analysis
Above the rule-based card sits an AI analysis card, powered by Claude (it carries a small Claude badge). The built-in verdict is always on and free; the AI analysis is an optional extra that adds a plain-English explanation written for a person to read. To run it, select Run AI analysis (1 credit). If you have run it before, the button reads Run again. Each successful run costs one AI credit, and your remaining balance for the period is shown next to the button. Before it runs you will see a short data-protection confirmation, because the message content is sent to the AI provider for analysis.
Every AI run is kept in the card's history, newest first, recording who ran it, when, which model was used and the credits charged. That means re-opening a report shows you past answers without spending another credit. Runs that fail are noted too, along with the error, and you are not charged for them.
Marking reports as reviewed
Once you have looked into a report, select Mark as reviewed in the footer. The report gains a Reviewed badge, a tick appears next to it in the dropdown, and the Unreviewed count for that domain goes down. This helps a team work through a backlog without losing track of what has been checked. If a report pre-dates your taking ownership of the domain (for example, after a domain transfer), you can still mark it, and DMARCER notes that it related to a previous owner.
Retention and auto-deletion
Because forensic reports hold other people's personal data, how long they are kept is set once for your whole account rather than report by report. Tenant Admins set it under Company settings on the Forensic reports tab. Once a day, DMARCER automatically deletes any report older than the window you choose, and each report's detail view shows its scheduled Auto-delete date with the days remaining. If you set retention to Forever, nothing is deleted automatically and the report shows Forever (no auto-deletion). Choosing a shorter window is the simplest way to limit how long this sensitive data is kept.
Common pitfalls
- No reports at all: forensic reports only arrive when your DMARC record includes an
fo=tag and the receiver spots a failure. In practice very few major mailbox providers send forensic samples at all, so an empty list is perfectly normal and does not mean DMARC is failing. - Cannot see the page or open a report: you need the Forensic.View permission. Ask a Tenant Admin to grant it. It is kept separate from ordinary report viewing because of the personal data involved.
- AI analysis button is greyed out: AI analysis needs to be included on your plan, switched on for the platform, switched on for your own user account, and you need AI credits remaining. When you select the button, its text explains which of these is missing.
- Verdict differs from the receiver's result: this is expected. DMARCER re-checks SPF and DKIM alignment for itself, so it can flag a message as a likely false positive even when the receiver reported a DMARC failure.
- A report disappeared: it was almost certainly removed by your retention policy. Check the Auto-delete date before relying on a report still being there later, and lengthen the retention window in Company settings if you need to keep reports for longer.