Why DMARC reports matter
DMARC helps receiving mail systems make consistent decisions about messages that claim to come from your domain. It builds on SPF and DKIM by adding alignment rules and policy guidance. The most useful part in day-to-day operations is reporting: DMARC can show you which systems are sending mail using your domain, whether those messages pass SPF or DKIM, and whether they achieve DMARC alignment.
This guide explains how rua (aggregate) and ruf (forensic) reporting works, what to look for in the data, how to identify legitimate and illegitimate sending sources, and how to turn findings into a practical remediation plan.
DMARC reporting types: rua vs ruf
rua: Aggregate reports
rua reports are typically delivered as XML files and summarize results over a period of time (often daily). They do not include full message content. Instead, they provide counts by source IP, the identities used (header-from, envelope-from, DKIM d=), and authentication outcomes (SPF/DKIM/DMARC pass or fail). For most organizations, rua is the primary signal for improving authentication hygiene.
ruf: Forensic (failure) reports
ruf reports are intended to provide message-level failure details. In practice, many receivers limit or disable forensic reporting due to privacy and data-sharing concerns, and the information you receive may be partial or redacted. Because ruf can carry sensitive data depending on the receiver’s behavior, it should be enabled only when you have an internal process to handle it appropriately.
How DMARC DNS reporting fields influence what you receive
To interpret reports correctly, you need to understand what your DMARC record is asking receivers to do. Common tags include rua, ruf, fo, adkim, aspf, and pct.
- rua: Where aggregate reports should be sent (one or multiple addresses).
- ruf: Where forensic reports should be sent (not universally supported).
- fo: Conditions under which a receiver may generate a forensic report.
- adkim/aspf: DKIM and SPF alignment mode (relaxed vs strict).
- pct: Percentage of mail the receiver should apply the policy to (useful for staged rollouts).
How to read a rua report: the fields that actually drive action
You might view aggregate XML through a DMARC analysis tool, a SIEM pipeline, or an internal parser. Regardless of presentation, the same core elements appear and the same logic applies.
1) Report metadata: who is reporting and for what time window?
At the top you’ll find the reporting organization and the begin/end timestamps. Use this to confirm report continuity and understand coverage. Not all receivers send reports, and reporting cadence can vary, so treat it as helpful telemetry rather than a perfect census.
2) Policy evaluation: requested policy and applied disposition
Aggregate reports show your published policy (p=none/quarantine/reject) and the receiver’s applied disposition. For example, with p=none you’ll usually see disposition “none”. With p=quarantine you might still see “none” in some cases due to local receiver logic. This section helps you validate that your rollout is being interpreted as expected.
3) Source IP and volume: start where impact is highest
Each record usually includes a source IP and a count. The fastest wins come from sorting by volume and mapping the top IPs to known systems. Common “forgotten senders” include website contact forms, application servers, invoicing systems, CRM platforms, helpdesk tools, and marketing automation services.
4) Identities: header-from, envelope-from, and DKIM d=
DMARC is anchored on the Header From domain (what users see). Reports often show the domain used for SPF evaluation (envelope-from/return-path) and the domain that signed the message with DKIM (d=). Your goal is to determine whether SPF and/or DKIM is aligned with the Header From domain.
5) Results: SPF pass/fail, DKIM pass/fail, and DMARC pass/fail
A message passes DMARC when at least one of SPF or DKIM passes and aligns with Header From. That means you can see “SPF pass” and still have “DMARC fail” if SPF is authenticated for a different domain than the one shown in Header From. The same is true for DKIM if d= is not aligned.
Using reports to answer: “Who is sending on behalf of my domain?”
In real environments, DMARC reporting is as much about inventory as it is about security. A structured approach prevents you from chasing noise and missing high-impact issues.
- Classify by sender type: corporate mail servers, application servers, office networks/VPN egress, and third-party SaaS providers.
- Prioritize unknown high-volume sources: they are either critical business mail that will break when you enforce, or a sign of misuse.
- Look at identity combinations: if Header From is your domain but return-path or DKIM d= is different, it often indicates a misconfigured third-party integration.
- Define a target state per source: “SPF aligned + DKIM aligned”, “at least one aligned”, or “should never send using our domain”.
Most common findings in DMARC reports and what causes them
1) SPF fail, or SPF pass but alignment fail
SPF fail typically means the sending IP is not authorized in your SPF record. SPF pass with alignment fail usually happens when the return-path domain is not the same as your Header From domain (and especially when strict alignment is used).
Remediation approach: identify the sending system. If it must send as your domain, authorize it correctly or follow the provider’s recommended SPF setup. If the provider cannot use an aligned return-path for your domain, focusing on DKIM alignment is often more reliable.
2) DKIM fail, or DKIM pass but alignment fail
DKIM fail can be caused by missing signatures, incorrect DNS records, selector mistakes, key rotation timing issues, or message modification in transit. DKIM pass with alignment fail means the d= domain is not aligned with Header From.
Remediation approach: confirm DKIM signing is enabled at the source. Publish the correct selector record. For third-party senders, evaluate whether they support signing with your domain (often called custom DKIM or domain alignment options).
3) Unexpected sources attempting to send
You may see low-volume attempts from unfamiliar hosting networks or geographies. This is often spoofing activity rather than a legitimate system.
Remediation approach: if you are still at p=none, use the observation period to confirm all legitimate sources are aligned, then plan a move to quarantine/reject. Enforcing too early can block valid business mail if authentication is incomplete.
A practical action plan driven by DMARC reporting
Phase 1 (1–2 weeks): inventory and quick fixes
- List all systems that send mail using your domain (human mail and automated mail).
- For each system, decide whether SPF alignment, DKIM alignment, or both will be the long-term method.
- Fix authentication for the highest-volume sources first to reduce risk quickly.
Phase 2 (2–4 weeks): prove stability before enforcement
- Stay on p=none while you stabilize reporting and close gaps.
- Confirm that no critical sender is still failing DMARC.
- If you use pct, plan a controlled increase and watch for regressions.
Phase 3 (1–3 months): move to quarantine, then reject
- Start with p=quarantine and monitor aggregate trends daily.
- When false positives are resolved, transition to p=reject.
- After go-live, treat DMARC reports as ongoing monitoring, especially when new tools are introduced.
Operational tips to keep DMARC reporting sustainable
- Assign ownership: decide who reviews reports and who is responsible for remediation (email admin, security, or IT ops).
- Use change management: track SPF/DKIM/DMARC changes; small DNS edits can have wide blast radius.
- Build a “new sender” checklist: when a new SaaS app starts sending as your domain, validate alignment immediately rather than waiting for deliverability issues.
Conclusion: DMARC reports are visibility, not just enforcement
When read consistently, DMARC reports do more than reduce spoofing: they reveal your real sending landscape, help you improve deliverability, and catch unauthorized use early. The organizations that get the most value treat aggregate reporting as a continuous operational signal, not a one-time project.
If you’re planning to authenticate your domain or tighten policies while operating business email on MX1Mail, incorporating rua report findings into your rollout checklist can make policy enforcement safer and far more predictable.