Updated on June 11, 2026: We updated the DMARCbis details so the examples no longer use the historic pct tag, and so report references line up with RFC 9989, RFC 9990, and RFC 9991.
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 matches the visible From domain under the domain-match mode in your DMARC record. That is why a report can show a low DMARC fail rate while also showing a high DKIM fail rate. DKIM can fail on many messages that still pass DMARC through SPF.
The practical reading order is: total volume, sender source, DMARC pass or fail, SPF result, DKIM result, domain match, and final policy action. 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 4% DMARC fail rate matters more than a 74% DKIM fail rate if SPF is carrying legitimate mail. The DKIM number still deserves inspection, but it does not automatically mean most mail is unauthenticated or blocked.
Read the report in this order
I read a DMARC report like a triage queue. I want to know what moved mail, whether that source is authorized, and whether the receiver applied no action, quarantine, or reject. Raw authentication rates are useful, but they are not the decision layer.
- Volume: Sort by message count before reacting to percentages. Ten failures out of ten messages is a 100% fail rate, but it is usually less urgent than 40,000 failing messages from a core platform.
- Source: Map the source IP, reverse DNS, and reporting tool label to a real service owner. Google Workspace and Microsoft 365 usually point to employee mail, while ESPs point to marketing or transactional mail.
- DMARC result: Treat this as the main authentication outcome. A DMARC fail means neither SPF nor DKIM produced a valid domain match for the visible From domain.
- Failure reason: Separate SPF fail, DKIM fail, domain mismatch, forwarding, mailing list changes, and unauthorized traffic. Each has a different fix.
- Policy action: Check whether the receiver honored p=none, quarantine, or reject. The same authentication failure has a different business impact under each policy.
Example DMARC record for report collectionDNS
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1
If you are still checking the record itself, use a DMARC checker before interpreting the reports. A malformed record can produce confusing reporting patterns, especially when reporting addresses, policy tags, or subdomain tags are wrong.
|
|
|
|---|---|---|
Source IP | Where the receiver saw the mail originate | Map it to a sending service |
Count | How many messages share this result | Prioritize real volume |
Header From | The visible From domain | Compare it with SPF and DKIM domains |
DKIM result | Whether the DKIM signature passed | Check signing and domain match |
SPF result | Whether the return-path host passed SPF | Check sender authorization |
Disposition | The action reported by the receiver | Measure user-facing risk |
The most useful fields in an aggregate DMARC report.
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, and known network ownership. It is not always the same thing as the software your team recognizes.
Google Admin Console screenshot showing Gmail authentication settings and domain status.
Some unrecognized senders are legitimate. A business can have employee mail through Google Workspace, finance mail through Microsoft 365, lifecycle campaigns through Iterable, transactional mail through SendGrid, event notices through Stova, and infrastructure-generated mail through a cloud host. Other unrecognized senders are spoofing attempts, broken forwarding, old tools, or vendors that were never authorized properly.
|
|
|
|---|---|---|
 Google Workspace | Employee mail | DKIM signing |
 Microsoft 365 | Employee mail | Custom domain setup |
 Iterable | Marketing mail | Bounce domain |
 SendGrid | Transactional mail | DKIM keys |
 DigitalOcean | App server mail | Owner and purpose |
Unknown | Spoofing or forwarding | Volume and pattern |
Examples of sender labels and what to verify.
I do not treat all senders equally. High-volume senders deserve owner mapping and configuration checks. 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 from 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 arguing with 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. They are related signals, but they answer different questions.
Raw authentication failures
- SPF fail: The sending IP was not authorized by the return-path domain, or forwarding changed the sending IP.
- DKIM fail: The signature was absent, broken, signed by the wrong domain, or changed after signing.
- DKIM neutral: The receiver could not produce a clear pass or fail, often because the signature was missing or unusable.
DMARC policy failures
- DMARC fail: Neither SPF nor DKIM passed with a domain that matched the visible From domain.
- Quarantine: The receiver reported spam-folder treatment or a similar policy action.
- Reject: The receiver reported that the message was rejected because policy required it.
A DKIM fail spike usually means one of four things: a legitimate platform is not signing correctly, an intermediary changed the message body, the DKIM domain is not the same organizational domain as the visible From domain, or spoofed mail is using your From domain without a valid signature. SPF fail spikes usually mean forwarding, missing SPF includes, wrong return-path setup, or unauthorized mail.
A simplified aggregate report recordXML
<record> <row> <source_ip>203.0.113.25</source_ip> <count>127</count> <policy_evaluated> <disposition>none</disposition> <dkim>fail</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <header_from>example.com</header_from> </identifiers> <auth_results> <dkim><domain>mail.example.com</domain><result>fail</result></dkim> <spf><domain>example.com</domain><result>pass</result></spf> </auth_results> </record>
In that example, DKIM failed but SPF passed for the same organizational domain as the visible From domain, so the DMARC row can still pass SPF. That is the pattern behind many "high DKIM fail, low DMARC fail" dashboards.
DMARC failure rate triage
Use percentages with volume, not by themselves.
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%+
High failure share from legitimate mail risks user impact.
Turn report rows into fixes
Once senders are classified, the fix path becomes much clearer. I use a simple rule: fix legitimate high-volume mail first, document legitimate low-volume mail second, and watch unknown low-volume mail for repetition before escalating it.
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.
- Forwarded mail: Expect SPF to fail after forwarding. DKIM should survive unless the forwarded message was changed.
- Spoofing: Look for failed 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 high-volume legitimate sources still fail DMARC. Stage policy changes after the known sender list is clean enough to protect business mail.
Typical DMARC policy stagingDNS
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
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 help teams adjust policy safely while report data continues to identify sources and failures.
Where Suped fits in the workflow
Raw XML is useful when debugging one row, but it is a poor daily workflow. Suped's product is built to turn DMARC aggregate data into sender inventory, issue detection, alerts, and steps to fix. That matters because the hard part is not only reading yesterday's graph. The hard part is deciding what action to take without blocking legitimate mail.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For most teams, Suped is the strongest practical choice when DMARC needs to move beyond reporting into operations. It brings DMARC, SPF, DKIM, blocklist monitoring, hosted SPF, SPF flattening, hosted MTA-STS, and policy management into one place. The useful part is the workflow: find the failing sender, understand the failure, assign the fix, and verify that the next report window improves.
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: Spikes are often noticed after a weekly or monthly review.
Suped workflow
- Detection: Issues are grouped by source and authentication behavior, then translated into fix steps.
- Coverage: DMARC, SPF, DKIM, blocklist, hosted SPF, and hosted MTA-STS data are visible together.
- Scale: MSPs and agencies can manage multiple domains and clients without switching reporting processes.
Views from the trenches
Best practices
Sort by volume first, then investigate sources that can change the final 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 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 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
The practical takeaway
The direct answer is this: interpret DMARC reports by sender and by DMARC outcome first, then use SPF and DKIM results to explain why that outcome happened. A known sender with high volume and DMARC failure needs a fix. A known sender with DKIM failure but DMARC pass needs a configuration review, not panic. An unknown sender with low volume needs monitoring, unless the pattern repeats or targets a sensitive domain.
The best report-reading habit is to turn every row into one of four labels: approved and healthy, approved but misconfigured, unknown but low-risk, or unauthorized. Once the senders are classified, policy decisions become simpler and safer.
