DMARC aggregate reports (RUA) tell you volumes and pass rates. Forensic reports (RUF) tell you exactly who sent a specific failing email — the sender IP, the exact headers, the subject line, the recipient address, and the reason each authentication check failed. Migomail processes RUF reports into a searchable intelligence feed.
DMARC aggregate reports show that 1,730 emails failed authentication last month. Forensic reports show you that one specific attacker sent 847 of those from a VPS in Eastern Europe targeting your CFO. The difference between aggregate and forensic data is the difference between statistics and intelligence.
Where a DMARC aggregate report tells you that 1,200 emails from IP 185.x.x.x failed DMARC last month, a forensic report gives you the complete data for each individual failing message — the exact timestamp, the sender address used, the recipient address targeted, every email header, the subject line, the DKIM failure reason, the SPF failure reason, and what the receiving server did with the message.
Every forensic report includes the IP address that sent the failing email. Migomail enriches this with: the geographic location (country, city), the Autonomous System (AS) name and number, the internet service provider, and whether the IP is a known VPS provider, proxy, or Tor exit node — giving you immediate context about the likely nature of the sender.
When DKIM fails in a forensic report, Migomail analyses the failure reason: was the signature missing (the sender did not sign at all), was the signature invalid (modified in transit or wrong key), was the selector not found (the DNS record was removed), or was the domain in the signature misaligned with the From: address? Each failure type has a different implication — missing DKIM usually means a spoofing attempt, invalid DKIM usually means message tampering.
SPF failure in a forensic report can mean different things. Migomail classifies each SPF failure by type: hardfail (-all match — the IP is explicitly not authorised), softfail (~all — the IP is not authorised but the domain is lenient), neutral (?all — the domain does not make a claim), or none (no SPF record at all). An attacker using your domain from a completely unrelated IP will generate a hardfail — the most dangerous and clearest spoofing signal.
Migomail stores and indexes every processed forensic report, making them searchable by sender IP, recipient address, subject line pattern, DKIM failure reason, date range, or any combination. This lets you investigate a specific suspected phishing campaign by searching for all forensic reports from a specific IP range, or all reports targeting a specific executive's email address.
Migomail analyses your forensic report stream for patterns that indicate active threat activity — sudden volume spikes from a new IP, repeated targeting of specific executive addresses (CEO, CFO, finance team), use of typosquatted domains in the From: address, or high-volume phishing campaign signatures. Alerts fire in real time with the specific threat pattern and recommended action.
DMARC forensic reports can contain personal data — recipient email addresses, message content. Many domains restrict RUF reporting or disable it entirely for privacy reasons. Migomail's forensic processing is GDPR-compliant: recipient addresses are pseudonymised by default, message body content is not stored, and retention periods are configurable. A separate privacy-preserving mode strips all personal identifiers before storage.
Forensic and aggregate report data are displayed in a combined dashboard — so when you see a spike in your aggregate DMARC pass rate, you can click through directly to the forensic reports for that time period and IP cluster to understand exactly what was happening. The combined view correlates aggregate statistics with individual failure evidence.
A DMARC forensic report is delivered as an email attachment (ARF format). Migomail decodes it automatically and presents every field in a structured, searchable format. This is what a real forensic report from a phishing attempt looks like.
The exact timestamp, the receiving provider, the targeted recipient address, and what the provider did with the message — delivered, quarantined, or rejected. Without forensic reports, you never know which specific addresses are being targeted.
The raw IP from the report, enriched by Migomail with geolocation, ASN data, and IP classification. A Tor exit node sending email as your CEO is a high-confidence BEC signal. A misconfigured AWS Lambda function sending as your domain is a completely different problem requiring a different response.
DKIM fail with no signature present means the attacker did not attempt to sign — they simply used your domain in the From: header without any authentication. SPF hardfail means the sending IP is explicitly not in your SPF record. Both failing together with no alignment = certain spoofing attempt.
The actual From: header, subject line, and Reply-To address from the spoofed email. This is what your customers or employees saw. The typosquatted reply-to domain (yourbrand-secure.net) is where the attacker wanted replies to go — now you know to register and block that domain.
Not every DMARC failure in a forensic report is a phishing attack. Migomail classifies each failure by type — so you respond to the right problem with the right action, and do not raise alarms about configuration issues.
Migomail structures forensic report data into an actionable investigation workflow — so your security team spends time responding to threats, not decoding XML.
The forensic report data revealed something our aggregate reports completely missed: all 1,200 of the failing emails from that IP range in the previous month were targeting the same 3 people — our CEO, CFO, and Head of Finance. The RUA report showed us a volume and a source. The RUF report showed us it was a coordinated BEC campaign targeting our wire transfer approval chain. That is operationally critical intelligence that changes how we respond. We immediately briefed those three executives on phishing awareness and escalated our DMARC to p=reject within the week.
A customer called us to say they had received an email from our CEO asking them to urgently process a payment to a new vendor. The email looked exactly like ours — our company name, our CEO's name, our email domain. We had DMARC at p=quarantine at the time, which meant the email went to their spam folder. They nearly missed it but checked spam before acting. After the incident, I looked at the forensic reports from that day and found 47 forensic reports targeting 23 different customers over a 4-hour window, all from the same IP block, all impersonating our CEO, all with the same reply-to domain. Migomail had the complete picture of the attack scope within 20 minutes of the campaign starting. We escalated to p=reject immediately. The next morning, zero forensic reports from that IP block. They gave up because every email was being rejected at the SMTP level.
We had been getting DMARC failures in our aggregate reports for weeks from what looked like a block of IPs in Southeast Asia. The volume was low enough that it was not triggering any alerts — maybe 40–50 failures a day. When we finally pulled the forensic reports, we saw that all 40–50 failures were targeting the same person: our Head of Procurement. Same subject line pattern ("PO approval required"), same reply-to domain (a typosquat). Low and slow BEC campaign designed to stay below volume thresholds. The forensic data caught what volume monitoring missed. That specific type of campaign — low volume, precise targeting — is invisible in aggregate reports and very visible in forensic reports.
“Rackwave Technologies has significantly improved our marketing performance while providing reliable cloud services. We’ve been using their solutions for a while now, and the experience has been seamless, scalable, and results-driven.”
David Larry
Founder & CEO
Common questions about DMARC forensic reports (RUF).
DMARC aggregate reports (RUA) are daily statistical summaries — they tell you the total volume of emails that passed or failed authentication from each source IP, but they do not contain any individual message data. Forensic reports (RUF) are per-email failure reports — sent near-instantly after a DMARC-failing message is processed, they contain the full headers of the specific failing message, the source IP, the DKIM and SPF failure reasons, and the recipient address. Aggregate reports tell you how many emails failed. Forensic reports tell you exactly what each failing email said and who it targeted.
No. Forensic reporting requires a separate ruf= tag in your DMARC record, pointing to a reporting address that can receive ARF (Abuse Reporting Format) emails. Without a ruf= tag, your DMARC record generates aggregate reports only. Not all mailbox providers send forensic reports — Gmail does not send them at all for privacy reasons. Yahoo, Fastmail, and several others do. Migomail's forensic data therefore comes from the providers that participate in RUF reporting.
No. Gmail does not send DMARC forensic reports (RUF) — only aggregate reports (RUA). This is a deliberate privacy decision by Google. However, forensic reports from Yahoo, Fastmail, and other participating providers still provide substantial visibility into attack patterns — since many phishing campaigns send to multiple providers simultaneously, attacks visible in Yahoo RUF reports often indicate campaigns also targeting Gmail users.
Yes, potentially — forensic reports can contain the recipient email address and, depending on configuration, a copy of the email body. For this reason, many privacy-conscious organisations disable forensic reporting or restrict it. Migomail addresses this with a privacy-preserving mode that pseudonymises recipient addresses before storage, does not store email body content, and applies configurable retention limits. You can also configure your ruf= tag with rf=afrf to limit report content to headers only (no body), which most providers already do by default.
Yes — this is one of the most operationally valuable uses of forensic data. The recipient address in each forensic report shows which of your contacts or customers received the spoofed email. If you see 47 forensic reports all targeting cfo@yourdomain.com, that is a specific, targeted BEC campaign aimed at a specific executive. Aggregate reports would show only that 47 emails failed — not who they were targeting. This distinction is critical for prioritising the human response (briefing the targeted individuals) alongside the technical response.
Business Email Compromise (BEC) is a type of social engineering attack where an attacker impersonates a trusted person (typically a CEO, CFO, or financial controller) to trick employees or partners into transferring money, sharing credentials, or taking other harmful actions. BEC attackers commonly spoof the victim company's email domain in the From: header. DMARC forensic reports expose BEC attempts in detail — the spoofed From: address, the target recipient, the subject line content ("Wire transfer approval needed"), and the attacker-controlled Reply-To address where responses would be directed.