How to interpret DMARC reports, including sender identification and failure types?
Updated on 22 Oct 2026: We expanded report coverage checks and clarified authentication failures, sender identification, and DMARC policy testing.
To interpret DMARC reports, start with the DMARC result, not the raw SPF or DKIM fail rate. A message passes DMARC when either SPF or DKIM passes and the authenticated domain meets the visible From domain's alignment requirements under the mode in the DMARC record. That is why a report can show a low DMARC fail rate alongside a high DKIM fail rate. DKIM can fail on messages that still pass DMARC through aligned SPF.
The practical reading order is: total volume, sender source, DMARC pass or fail, SPF result, DKIM result, alignment, reported disposition, and any policy override reason. In DMARC monitoring, the goal is not to make every raw SPF and DKIM number look perfect. The goal is to know which systems send mail for your domain, which ones need configuration work, and which failures are spoofing, forwarding, or noise.
A 74% raw DKIM fail rate does not mean 74% of messages fail DMARC. If aligned SPF carries those messages, the DMARC fail rate can still be 4%. Investigate the failing sources and their business impact before deciding which percentage needs action.
Read the report in this order
Read a DMARC report like a triage queue. First identify what moved mail, whether that source is authorized, and whether the receiver reported pass, no action, quarantine, or reject, with any policy override reason. Raw authentication rates are useful, but they are not the DMARC decision layer.
- Volume: Sort by message count before reacting to percentages, but check business importance too. Ten failures out of ten messages is a 100% fail rate; ten failed password-reset messages still need investigation even beside a platform with 40,000 failures.
- Source: Map the source IP, reverse DNS, and reporting label to a real service owner. Google Workspace and Microsoft 365 can indicate employee mail or a forwarding path; ESPs can indicate marketing or transactional mail. Confirm ownership before authorizing a source.
- DMARC result: Treat this as the main authentication outcome. A DMARC fail means neither SPF nor DKIM produced a passing authenticated identifier aligned with the visible From domain.
- Failure reason: Separate raw SPF or DKIM errors from alignment failures, forwarding, mailing list changes, temporary errors, and unauthorized traffic. Each has a different fix.
- Disposition and override: Compare the reported disposition with the published policy. A difference can reflect test mode, a trusted forwarder, a mailing list, or the receiver's local policy.
Example DMARC record for aggregate reportsDNS
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
The rua tag requests aggregate reports. The fo tag controls when per-message failure reports are requested through ruf, so it is not needed to collect aggregate XML. If you are still checking the record itself, use a DMARC checker before interpreting the reports. A malformed record can produce confusing patterns when reporting addresses, policies, or subdomain tags are wrong.
|
|
|
|---|---|---|
Source IP | The server IP that connected to the reporting receiver | Map it to a sending service |
Count | How many messages share this row | Prioritize real volume |
Header From | The visible From domain | Compare it with authenticated domains |
auth_results | Raw DKIM and SPF validation results | Inspect domains, selectors, and errors |
policy_evaluated | Alignment-aware SPF and DKIM outcomes | Read the DMARC decision |
Disposition and reason | Reported handling and policy override | Explain policy differences |
The most useful fields in an aggregate DMARC report.
Understand report scope and policy overrides
Files sent to a rua address are aggregate reports: compressed XML summaries grouped by receiver, reporting period, source, and authentication outcome. They contain message counts rather than message bodies. Extract .xml.gz or legacy .zip attachments and open the resulting XML in a text editor. Failure reports requested through ruf describe individual DMARC failures and can include message-specific data. Receiver support is limited because those reports raise privacy and data-handling concerns.
RFC 9990 defines current aggregate reporting. Reports contain metadata, the policy observed by the receiver, and one or more grouped records. During implementation transitions, report consumers also encounter older report shapes, so process fields defensively and do not treat every missing optional element as an authentication error.
|
|
|
|---|---|---|
report_metadata | Reporter, report ID, and date range | Duplicate IDs or an unexpected time window |
policy_published | The policy and alignment settings observed | Stale policy, test mode, or subdomain differences |
record and row | Source IP, count, and evaluated outcome | High-volume rows that need owner mapping |
identifiers | Header From and envelope-from domains | A bounce domain that fails alignment |
auth_results | Raw SPF and DKIM checks | A raw pass that fails DMARC alignment |
policy_evaluated reason | Why reported handling differed from policy | Local policy, mailing list, or trusted forwarder |
How to read the main XML branches.
RFC 9990 adds disposition=pass for a DMARC pass under an enforcement policy. Legacy reports use none for no DMARC action, including passes. A failing row with none can reflect p=none or an override; check both evaluated authentication results.
Do not infer inbox placement from disposition alone. Aggregate reports describe authentication and reported DMARC handling, not whether a passing message reached the inbox. Receivers can accept a DMARC failure under local policy or filter a DMARC pass for unrelated abuse signals.
Check report coverage before comparing failure rates
Aggregate reports usually arrive daily, after the reporting window closes. They are not real-time alerts or a complete record of outbound mail: some receivers do not report. A missing reporter can change the apparent DMARC pass rate without any sender configuration changing.
- Check date_range: begin and end are Unix timestamps in seconds, expressed in UTC. Compare the reporting window with the time of a DNS change, rather than the report email's arrival time.
- Remove duplicate report deliveries before summing count. Use the reporting organization, report ID, policy domain, and reporting window together to identify repeats.
- Calculate the failure rate with message counts: sum count for rows where both policy_evaluated SPF and DKIM are fail, divide by total reported count, then multiply by 100. Do not average row percentages.
- Compare the same reporting receivers and completed windows. Track approved senders separately, because a spoofing spike can lower the overall pass rate while legitimate mail stays healthy.
If expected reports are absent, check rua spelling and mailbox delivery. For a destination on another organizational domain, confirm the required external reporting authorization with the report recipient.
Identify senders before fixing failures
Sender identification is where DMARC reports become useful. The "sender" shown in a reporting platform is usually an interpretation of source IP, reverse DNS, SPF domain, DKIM domain, selector, and known network ownership. It is not always the same thing as the software your team recognizes. A shared platform or forwarder can own the connecting IP; a familiar network name alone does not prove that your team authorized the mail.
Google Admin Console screenshot showing Gmail authentication settings and domain status.
Some unrecognized senders are legitimate billing systems or applications running on a cloud host. Other unrecognized senders are spoofing attempts, broken forwarding, old tools, or vendors that were never authorized properly.
|
|
|
|---|---|---|
Employee mail | DKIM signing | |
Employee mail | Custom domain setup | |
Marketing mail | Bounce domain | |
Transactional mail | DKIM keys | |
App server mail | Owner and purpose | |
Unknown | Unmapped service, forwarding, or spoofing | Volume and pattern |
Examples of sender labels and what to verify.
Do not treat all senders equally. High-volume senders and systems handling account access or payments deserve owner mapping and configuration checks, even when their daily counts are small. Low-volume unknowns deserve monitoring unless they cluster around a sensitive domain, target one receiver, or grow suddenly. A one-message source can be noise. A one-message source that repeats every day across different networks can be a spoofing pattern.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A broader domain health checker helps confirm whether the domain has the expected DMARC, SPF, and DKIM foundation before you spend time resolving individual report rows.
Separate SPF, DKIM, and DMARC failures
The biggest interpretation mistake is treating SPF fail, DKIM fail, and DMARC fail as the same problem. Raw results in auth_results describe protocol checks. The SPF and DKIM values in policy_evaluated describe whether those checks passed DMARC alignment.
Compare the DKIM d= signing domain and SPF MAIL FROM domain, usually shown as Return-Path, with header_from. The DKIM s= selector locates the public key; it is not the domain used for alignment. Relaxed alignment, the default, accepts domains with the same organizational domain, such as mail.example.com and example.com. Strict alignment requires an exact match. Check adkim for DKIM and aspf for SPF. One passing signature with the required alignment is enough, even if another signature fails.
Raw authentication results
- SPF pass or fail: The evaluated IP was authorized, or not authorized, for the SPF identity shown in auth_results.
- DKIM pass or fail: A signature validated, or an evaluated signature failed because of its key, signature data, or message changes.
- None: No SPF record was found for the evaluated identity, or the message had no DKIM signature. Check the protocol before choosing a fix.
- Neutral or softfail: SPF neutral makes no authorization assertion; softfail weakly indicates that the IP is unauthorized. DKIM neutral indicates an unprocessable signature. None of these results is a pass.
- Temperror: A temporary DNS or validation problem prevented a result. Recheck later and investigate DNS reliability if the error repeats.
- Permerror: A persistent configuration or validation error needs correction. For SPF, check syntax, multiple SPF records, and the limit of 10 DNS-querying terms. For DKIM, inspect the reported error and selector key.
DMARC-evaluated outcomes
- Aligned SPF pass: SPF passed and its authenticated domain aligned with the visible From domain.
- Aligned DKIM pass: At least one DKIM signature passed with a signing domain aligned to the visible From domain.
- DMARC fail: Neither mechanism produced an aligned pass.
- Disposition or override: The receiver reports its DMARC handling and any reason it differed from the published policy.
A raw DKIM fail spike usually points to invalid signatures, incorrect keys, or changes to signed content. A DKIM fail in policy_evaluated can instead mean that a valid signature uses a domain outside DMARC alignment requirements. Unsigned mail produces no DKIM pass. SPF fail spikes usually mean forwarding, missing authorization, or unauthorized mail; a raw SPF pass can still fail DMARC when the return-path domain does not meet alignment requirements.
A simplified RFC 9990 aggregate report recordXML
<record> <row> <source_ip>203.0.113.25</source_ip> <count>127</count> <policy_evaluated> <disposition>pass</disposition> <dkim>fail</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <envelope_from>example.com</envelope_from> <header_from>example.com</header_from> </identifiers> <auth_results> <dkim><domain>mail.example.com</domain><selector>s1</selector><result>fail</result></dkim> <spf><domain>example.com</domain><scope>mfrom</scope><result>pass</result></spf> </auth_results> </record>
In that example, DKIM failed but SPF passed with example.com as both the authenticated SPF domain and the visible From domain. The 127 messages therefore pass DMARC through aligned SPF; pass is the RFC 9990 disposition for this outcome under an enforcement policy. This is the pattern behind many "high DKIM fail, low DMARC fail" dashboards.
DMARC failure rate triage
These are operational review bands, not DMARC protocol thresholds. Use percentages with volume and source identity.
Normal watch
0-1%
Low volume, known forwarding, or isolated receiver behavior.
Investigate
1-5%
A recurring sender or one-day spike needs source mapping.
Fix before enforcement
5%+
A high failure share from legitimate mail risks user impact.
Treat the percentage bands as review prompts, not enforcement gates. Even one failed password-reset message warrants investigation, and a low overall failure rate does not establish that every approved sender is ready for reject.
Turn report rows into fixes
Once senders are classified, the fix path becomes much clearer. Prioritize legitimate high-volume mail and business-critical systems, including low-volume account-access mail. Document other approved sources and investigate recurring unknown sources before changing policy.
Flowchart showing DMARC report triage from report row to sender mapping, fixes, and monitoring.
- Known work mail: Confirm that Google Workspace or Microsoft 365 signs with the organization's domain and that SPF covers expected outbound paths.
- Known ESP mail: Check the platform's authenticated sending domain, bounce domain, DKIM keys, and return-path domain.
- Unknown cloud mail: Ask engineering or IT whether the IP belongs to a server, application, helpdesk, billing system, or abandoned tool. Do not add an unknown IP to SPF just because it appears in a report.
- Forwarded mail: SPF often fails after forwarding. Rewriting the envelope sender can produce a raw SPF pass for the forwarder's domain without meeting DMARC alignment requirements. DKIM should survive unless the intermediary changes signed content.
- Spoofing: Look for failed aligned SPF and DKIM, no known service owner, scattered networks, and repeated attempts against the same visible From domain.
Do not move straight to reject while approved business-critical sources still fail DMARC. Stage policy changes after verifying approved senders, including low-volume systems, then check each change across recent reporting windows. Test known forwarding and mailing-list paths before enforcement.
Successive policy values, publish only one DMARC record at a timeDNS
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; t=y v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com
RFC 9989 marks pct historic. Its t=y mode requests one level less enforcement: quarantine becomes none, and reject becomes quarantine. Testing mode does not change report generation. Older receivers that ignore t=y can enforce the published policy, so retain p=none until approved senders are ready for enforcement. For teams that do not want every change to require DNS edits, Hosted DMARC can make policy staging easier. Suped's product uses this workflow to adjust policy while report data continues to identify sources, failures, and overrides.
Where Suped fits in the workflow
Raw XML is useful when debugging one row; a DMARC report analyzer groups results for routine review. Suped's product turns DMARC aggregate data into a sender inventory, groups related authentication issues, and attaches steps to fix them. Teams can use those details to identify the responsible owner, make the change, and verify the outcome in later report windows without repeatedly parsing XML.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Manual report reading
- Parsing: Someone must read XML or exported rows and group the same sender repeatedly.
- Ownership: Sender owner mapping often lives in notes, spreadsheets, or one person's memory.
- Alerting: A daily review requires checking report arrivals and comparing equivalent windows.
Suped workflow
- Detection: Issues are grouped by source and authentication behavior, then translated into fix steps.
- Report context: Source, message count, and SPF and DKIM results are visible together for review.
- Scale: MSPs and agencies can manage multiple domains and clients without switching reporting processes.
Views from the trenches
Best practices
Prioritize business-critical senders alongside volume before changing the DMARC policy.
Keep a service owner list so Google Workspace, Microsoft 365, and ESP traffic is known.
Review one-day spikes against message count, because small samples can distort percentages.
Common pitfalls
Treating every DKIM fail as a DMARC fail creates unnecessary sender investigations for teams.
Ignoring low-volume unknown sources leaves spoofing and forgotten systems mixed together too long.
Changing to reject before sender mapping is complete can block legitimate business mail.
Expert tips
Tag each sender as approved, unknown, forwarding, or abusive before changing policy stage.
Check both the DKIM domain and SPF return path before calling a platform broken internally.
Use alerts for sudden source changes, not only for aggregate pass rates at month end.
Marketer view
Marketer from Email Geeks says raw DKIM and SPF fail rates need context, because DMARC can still pass when one valid authentication path works.
2024-09-24 - Email Geeks
Expert view
Expert from Email Geeks says sender labels can include approved platforms, unapproved systems, spoofing, and forwarding outside the sender's control.
2024-09-25 - Email Geeks
Classify senders before changing DMARC policy
Interpret DMARC reports by sender and DMARC outcome first, then use raw SPF and DKIM results, authenticated domains, and alignment to explain why that outcome happened. A known sender with high volume or business-critical mail and DMARC failure needs a fix. A known sender with DKIM failure but DMARC pass needs a configuration review, not panic. An unknown sender needs ownership checks and monitoring, with faster investigation when the pattern repeats or affects a sensitive domain.
Turn every row into one of four labels: approved and healthy, approved but misconfigured, unknown and under investigation, or unauthorized. Record the report window and receiver when investigating a spike. Once the senders are classified, policy decisions become simpler and safer.
Frequently asked questions
Yes. DMARC can pass through SPF if SPF passes and the SPF-authenticated domain meets the visible From domain's alignment requirements under the mode in the DMARC record.
Because DKIM failure is only one signal. If the same messages pass SPF with the right alignment, DMARC can still pass. Compare the DKIM fail rate with the DMARC fail rate, source, and message volume.
auth_results records raw protocol validation. policy_evaluated applies DMARC alignment. SPF or DKIM can pass for a domain that is not aligned with the visible From domain, so the corresponding DMARC-evaluated result is fail.
No. Unknown senders can be legitimate vendors, app servers, ticketing systems, forwarding paths, or spoofing. Classify them by volume, source IP, domain behavior, and business owner before deciding.
Prioritize high-volume legitimate senders and systems tied to revenue or account access, even when their message counts are low. Check the business impact of a failure before ranking it by percentage or volume alone.
Move to reject after approved senders are mapped and their DMARC failures are resolved across normal sending cycles. Test known forwarding and mailing-list paths and assess any remaining failures. Low volume or a forwarding label alone does not establish that legitimate mail will survive enforcement.
