DMARC Report Analysis: Understanding Email Defense

What a DMARC Aggregate Report Actually Contains

A RUA report is a machine-readable XML file per RFC 7489. Every receiving mail server that handles mail in your domain's name collects authentication results over a period (usually 24 hours) and sends them to the address configured in your DMARC record under rua=. Each report contains not individual emails but aggregated rows: a sending source, its volume, and the result.

The key fields are quickly explained: org_name identifies the reporting server (such as Google or Microsoft), source_ip the IP that sent on your behalf, count the message volume from that source, disposition the action actually applied (none, quarantine, or reject), and finally the pass/fail results for spf and dkim. Sounds manageable — but it becomes overwhelming fast: every receiving server sends at least one report per day (RFC 9990), so a medium-traffic domain receives reports from many different receivers daily, each with numerous source records. Manual reading does not scale here.

Germany's BSI explicitly recommends SPF, DKIM, and DMARC as baseline measures against spoofing and phishing (BSI). In practice, however, analysis is the weak point: according to a survey by the Alliance for Cyber Security, only 38% of SMBs in Germany have correctly implemented all three methods (Allianz für Cybersicherheit). Without continuously reading the RUA data, even an existing record remains a blind spot.

It is also important to understand the difference between the reporting period and the time of receipt. A report typically covers a past 24-hour window but often arrives only hours later — and some providers consolidate several days. For a reliable analysis, therefore, never look at a single report in isolation; aggregate across several days or weeks. Only over that span do stable patterns emerge: which sources send continuously, which appear only sporadically, and which unknown IPs recur. This temporal consolidation is exactly what separates a sound analysis from a snapshot that can easily mislead.

Understanding Alignment: The Core of DMARC

SPF and DKIM alone only indicate whether a mail was technically authorized. DMARC adds a crucial condition: alignment. The domain that passed SPF or DKIM must match the visible sender domain in the From: header. Only this match makes authentication effective against spoofing — because an attacker can send SPF-compliant mail from their own domain, but cannot cover your From: address with it.

Important: a DMARC pass requires only one aligned passing mechanism. A mail can break SPF but still pass DMARC thanks to a correct DKIM signature — and vice versa. This explains an apparent discrepancy in the global numbers: the DKIM pass rate was 90.90% in Q1 2026 and the DMARC pass rate 88.99%, while SPF lagged clearly behind at 80.24% (Cloudflare Radar). DKIM survives forwarding better than SPF, which is why DKIM alignment is often the load-bearing pillar in practice.

Classifying Sending Sources: Three Categories

Once the RUA data is processed, every sending source can be placed into one of three categories. This classification is the actual analysis step — and the basis of every decision about the next policy stage.

The biggest value often appears immediately: many organizations discover sending sources they did not know existed within the first few days of enabling RUA analysis — forgotten marketing tools, shadow IT, or actual attackers. This very visibility is the reason not to leave DMARC at p=none but to actively read the reports. Enabling DNS and domain monitoring in parallel also reveals when the underlying DNS records change unexpectedly.

Spotting Spoofing in the Reports

Spoofing shows up in RUA reports as a recurring pattern: unknown source IPs with notable volume where both SPF and DKIM fail and no alignment exists. Such entries are rarely coincidental — they indicate someone actively trying to send in your name. The threat level is real: the spoof rate of inbound messages was 18.11% in Q1 2026 and rose to 31.64% by May 2026 (Cloudflare Radar).

The economic consequences are substantial. According to Verizon, phishing served as the initial access vector in 16% of all data breaches (Verizon 2025 DBIR). 60% of all security incidents involve a human element — usually a phishing email (Verizon 2025 DBIR). The most expensive is Business Email Compromise (BEC): 2.77 billion USD in losses in 2024 alone, with a median loss of around 50,000 USD per incident (FBI IC3). An enforced DMARC policy is the most effective measure to stop domain impersonation at the root.

Particularly insidious is so-called direct domain spoofing, where attackers use your exact domain in the visible sender. This is precisely where DMARC steps in, because without alignment the attempt fails the From: check. As long as your policy remains at p=none, however, the forged mail is still delivered — the receiving server merely logs the fail in the RUA report instead of acting. The reports therefore show you exactly how often your domain is already being abused, even before you actively protect it. This early-warning function has standalone value: it provides the business case for advancing enforcement quickly rather than putting the topic off indefinitely.

Moving Safely From p=none to p=reject

The biggest concern when tightening: will legitimate mail be blocked by accident? This concern is justified — jumping to p=reject too early can send invoices, confirmation mails, or newsletters into the void. That is why the transition happens in controlled stages, backed by the RUA data.

1. Observe with p=none: Start with monitoring-only and collect 2 to 4 weeks of RUA data. The goal is a complete inventory of all legitimate sending sources.
2. Authorize legitimate sources: Add SPF entries for every real source and set up DKIM signatures until the aligned pass rate for your genuine traffic is consistently high.
3. Move to p=quarantine with pct=25: Apply quarantine to only 25% of failing mail at first. This limits the risk if a source was overlooked.
4. Increase the share gradually: Raise pct to 50% and then 100% over several weeks while watching the reports for new legitimate fails.
5. Switch to p=reject: Once no unexpected legitimate fails have appeared for several weeks, move to full enforcement. Spoofing is now rejected.
6. Monitor continuously: New services, changed providers, or a provider switch can change the situation at any time. The analysis never ends.

This caution pays off but is rare: while DMARC adoption among top domains rose from 27.2% to 47.7% between 2023 and 2025 (EasyDMARC), the enforcement gap remains large. For comparison: among Fortune 500 companies, 95% deploy DMARC and 62.7% of those use the strictest policy p=reject (EasyDMARC 2026) — the picture is considerably weaker among SMBs.

_dmarc.your-domain.com.  TXT  "v=DMARC1; p=quarantine; pct=25;
  rua=mailto:dmarc-reports@your-domain.com;
  adkim=s; aspf=s; fo=1;"

# p        = current policy stage (none -> quarantine -> reject)
# pct      = share of mail the policy is applied to
# rua      = destination address for aggregate reports
# adkim/aspf = alignment mode (s=strict, r=relaxed)
# fo=1     = failure reports when a mechanism is not aligned

Avoiding Common Analysis Mistakes

Analyzing RUA reports has its own pitfalls. Knowing them avoids wrong decisions that either cost deliverability or create a false sense of security. That data quality is a real hurdle here is documented explicitly by the IETF DMARC working group: even reports from large senders such as Google or Yahoo frequently deviate from the RFC XML schema — schema deviations, inconsistent timestamps, and validation errors are common, which is why RFC 9990 re-specifies the reporting format (IETF DMARC Working Group, RFC 9990). A robust analysis must absorb these quirks rather than fail on them — otherwise legitimate sources accidentally end up in the wrong category and are overlooked during tightening.

DMARC, Deliverability, and the Provider Requirements

DMARC has long ceased to be merely a security topic; it is now a deliverability prerequisite. Since 2024, Google and Yahoo have required bulk senders with more than 5,000 emails per day to have a DMARC record with at least p=none (Google/Yahoo). Ignoring this risks temporary and permanent rejections.

On top of that comes the spam threshold: Google requires a reported spam rate below 0.10% and begins taking action once 0.30% is reached (Google). RUA reports are doubly useful here: they show not only spoofing but also whether your legitimate sending services authenticate cleanly — a basic requirement for good delivery rates. Keeping an eye on blacklist monitoring of your mail server IPs covers the deliverability side completely.

DMARC as Part of Overall Domain Security

An enforced DMARC policy protects your sender reputation — but it is only one building block. Email authentication interlocks with monitoring of the entire DNS and certificate landscape. If an attacker manipulates your DNS records, they can also rewrite SPF and DKIM records; that is why detecting and defending against DNS hijacking is an essential part of the picture.

• SPF/DKIM/DMARC records: Must be present, correct, and monitored against unnoticed changes — the basis of email authentication.
• Certificate transparency: Through CT log monitoring you detect unauthorized certificates issued for your domain, which are abused for convincing phishing pages.
• Domain expiration: An accidentally expiring domain opens the door wide to spoofing — preventing domain expiration is basic hygiene.
• Social preview integrity: Manipulated preview images harm brand perception — Open Graph monitoring rounds out the picture.
• Look-alike domains: Typo variants of your domain are registered for phishing and should be watched.

Only the interplay turns individual measures into a resilient protection concept. DMARC secures the sending channel, DNS monitoring the foundation, and certificate and domain monitoring the external perception. When deviations are detected, an alert across all relevant channels should fire immediately.

Analyze RUA Reports Continuously, Not Just Once

The core message of any DMARC analysis: it is not a one-time project but an ongoing process. The global DMARC pass rate fluctuates noticeably — from 89.48% in April 2026 it fell to 85.61% in May (Cloudflare Radar). Such movements arise from new services, changed provider infrastructure, or attack waves. Without continuous analysis, you notice a broken DKIM signature or a new spoofing source only when mails bounce or customers complain.

The XICTRAQ Mail-Check checks your DMARC, SPF, and DKIM configuration and makes the authentication situation transparent. Combined with DNS and domain monitoring, you get a continuous picture of your email security — and are notified as soon as a relevant value deteriorates. This keeps the hard-won p=reject stage effective over time instead of quietly breaking after the next tool switch. The decisive shift in perspective: treat the analysis not as a one-off chore but as a fixed part of your operational routine — just like checking server logs or backups. Then DMARC delivers exactly what it was designed for: dependable visibility and demonstrable protection of your domain.

Frequently Asked Questions About DMARC Report Analysis