How to Analyze DMARC Failure Reports for Compromised Accounts
DMARC failure reports can reveal that messages claiming to come from your domain are being sent through unauthorized systems. They are valuable for detecting spoofing, phishing campaigns, misconfigured mail services, and signs that a legitimate mailbox may have been taken over.
A report does not automatically prove that an account is compromised. A failed message may result from forwarding, broken SPF alignment, an incorrect DKIM selector, or a third-party sender that was never configured properly. The goal is to connect authentication results with sending behavior, account activity, and infrastructure ownership.
The most useful investigations combine DMARC aggregate reports with forensic reports, mail server logs, identity-provider records, and domain reputation data. This creates a clearer distinction between external impersonation and abuse originating inside an authorized environment.
Understand What Each Report Shows
Aggregate reports, commonly delivered as XML files, summarize authentication activity for a reporting period. Important fields include the sending IP address, message count, header-from domain, SPF result, DKIM result, and the applied DMARC policy. They help identify patterns across thousands of messages without exposing message content.
Forensic or failure reports contain more detail about individual messages, although availability depends on the receiving provider and its privacy rules. They may include selected headers, timestamps, recipient information, and authentication results. Review the platform’s legal notices before storing or sharing these records, particularly when reports contain personal or sensitive data.
Separate Spoofing From Account Abuse
Start by checking whether the source IP belongs to your organization, a known email service, or an unfamiliar network. An external IP that sends messages with your domain in the visible From field often indicates spoofing. If SPF and DKIM both fail and the IP has no relationship to your business, the event is usually an impersonation attempt rather than a stolen mailbox.
An account compromise may look different. The attacker could use a valid cloud mailbox, an authorized SMTP relay, or a trusted third-party platform. In that case, authentication might pass, making DMARC reports alone insufficient. Look for unusual sender addresses, abnormal sending volume, unfamiliar geographic locations, suspicious login sessions, and messages sent outside the user’s normal schedule.
Read Authentication Results in Context
DMARC passes when either SPF or DKIM passes with domain alignment. A sender can therefore pass DMARC even when the other mechanism fails. Examine the authenticated domain as well as the result: an unrelated domain may technically pass SPF but fail alignment with the visible From domain.
Use the following interpretation as a starting point:
| Report pattern | Likely explanation | Investigation focus |
|---|---|---|
| SPF fail, DKIM fail, unknown IP | Direct spoofing or phishing | Block source, inspect campaign volume |
| SPF pass, alignment fail | Unauthorized relay or vendor setup | Review SPF include and return-path domain |
| DKIM fail, SPF pass | Modified message or selector issue | Check forwarding, signing keys, and gateways |
| DKIM pass, unfamiliar selector | Unapproved sender or key exposure | Identify selector owner and rotate if needed |
| DMARC pass from unusual user activity | Possible compromised account | Correlate with identity and mailbox logs |
A single failed message is less informative than a repeated pattern. Group events by source IP, selector, envelope-from domain, recipient domain, and time window. A sudden increase from one provider, especially with a new DKIM selector or unfamiliar ASN, deserves priority review.
Trace the Sending Infrastructure
Resolve suspicious IP addresses to their autonomous system, hosting provider, and approximate region. Compare those details with your approved vendors and documented mail flows. Reputation services can help determine whether an address is associated with malware, botnets, disposable hosting, or prior abuse, but reputation should support—not replace—internal evidence.
Check whether the source appears in your SPF record, whether the DKIM selector exists in DNS, and whether the sending service is authorized by your organization. A legitimate vendor may be misconfigured, while an attacker may exploit an old service that remains authorized. Remove obsolete SPF entries and unused DKIM selectors after confirming that no business process depends on them.
Correlate Reports With Security Logs
Export suspicious report records into a case-management or security information and event management system. Match timestamps and sender addresses against identity-provider sign-ins, mailbox audit events, OAuth application grants, forwarding rules, and password-reset activity. Evidence of impossible travel, unfamiliar devices, mass forwarding, or newly created inbox rules strengthens the compromise hypothesis.
Trusted Sender Score provides domain trust tools that can complement this process by checking authentication posture and sender reputation. Use these checks to validate whether a reported source is part of an approved mail path or an unexpected infrastructure change.
Contain and Confirm the Incident
If a mailbox appears compromised, revoke active sessions, reset credentials, require multifactor authentication, remove suspicious OAuth grants, and inspect forwarding or delegation settings. Search sent items and message-trace logs for malicious content, then notify recipients who may have received fraudulent messages.
For external spoofing, enforce an appropriate DMARC policy gradually after legitimate senders are inventoried. Start with monitoring, correct SPF and DKIM alignment problems, and then consider quarantine or rejection. Keep reviewing reports after every DNS or mail-flow change to confirm that legitimate traffic remains authenticated.
Build a Repeatable Review Process
A consistent review process prevents isolated alerts from being overlooked:
- Collect aggregate reports daily and preserve the original XML files.
- Group failures by source IP, domain, selector, provider, and time period.
- Compare suspicious activity with mailbox, identity, and mail-flow logs.
- Escalate unusual authenticated activity as a possible account compromise.
- Track remediation results and verify them in later reports.
Assign ownership for report analysis to a security or messaging team, and define thresholds for investigation. For example, a sudden tenfold increase in failed messages, a new country of origin, or repeated activity from an unknown relay can trigger an incident review.
DMARC reporting becomes most effective when treated as an early-warning data source rather than a standalone verdict. Analyze authentication alignment, infrastructure, user behavior, and account telemetry together, then use the findings to tighten sender authorization and protect identities. Begin by reviewing your latest reports and documenting every unfamiliar sender path before changing enforcement policies.