How to Use DMARC Aggregate Reports to Find Compromised Senders
DMARC aggregate reports give domain owners a broad view of how their domains are used in email. Sent by mailbox providers and reporting services, these XML reports show sending IP addresses, message volumes, SPF and DKIM results, and the policies applied to unauthenticated messages.
This data is especially useful when a trusted marketing platform, help desk, payroll provider, or other third-party sender becomes compromised. A stolen account, misconfigured integration, or abused API key can cause messages to pass through an approved provider while carrying malicious content or failing alignment checks.
Using DMARC aggregate reports to identify compromised third-party senders requires pattern recognition rather than a single alarming result. The goal is to separate authorized changes from suspicious activity, then contain the risk without disrupting legitimate business mail.
Understand What Aggregate Reports Show
Aggregate reports, often called RUA reports, summarize authentication activity for a domain over a reporting period. They commonly include the source IP, receiving organization, message count, SPF result, DKIM result, DMARC disposition, and the domain observed in the From header.
These reports generally do not include message bodies, URLs, or personal content. Their value comes from the operational picture they create. By comparing current records with an established baseline, security teams can see when a familiar sender changes behavior or when an unknown infrastructure begins using the organization’s identity.
The free tools and educational resources from Trusted Sender Score can complement this review by helping domain owners examine reputation and authentication signals alongside their DMARC data.
Build an Authorized Sender Baseline
Start by listing every approved service that sends mail for the domain. Include email service providers, customer relationship platforms, ticketing systems, accounting tools, recruitment systems, transactional mail services, and internally managed infrastructure. Record each vendor’s sending domains, DKIM selectors, SPF mechanisms, and expected message types.
Next, group report entries by source IP, organizational domain, DKIM signing domain, and SPF-authenticated domain. A known vendor may use many IP addresses, so the vendor’s documentation and authentication domains are often more reliable identifiers than a fixed address alone.
Pay attention to volume and timing. A newsletter platform that normally sends 5,000 messages on weekdays may be legitimate, while the same platform suddenly sending 200,000 messages overnight deserves investigation. A new sender that appears during a software rollout may be expected, but it should still be documented and verified.
Recognize Indicators of Third-Party Abuse
A compromised third-party sender often leaves several clues. The provider may remain familiar, but the message volume, geographic source, DKIM selector, or sending subdomain can change. Authentication may pass at the provider level while DMARC alignment fails because the visible From domain is not aligned with the authenticated identity.
Another warning sign is a sudden increase in messages marked as quarantined or rejected. This can indicate that an attacker is using a vendor’s infrastructure with a forged From address, or that a legitimate integration has been altered. Repeated SPF failures from unfamiliar networks, new selectors, and bursts from hosting providers also merit attention.
| Report signal | Likely interpretation | Practical next step |
|---|---|---|
| Known vendor, new DKIM selector | New configuration or unauthorized key | Confirm the selector with the vendor |
| Sharp volume increase | Campaign change, automation error, or abuse | Review account activity and sending logs |
| SPF pass but DMARC fail | Identifier alignment problem | Check the visible From and Return-Path domains |
| Unknown IP with repeated failures | Spoofing or unauthorized infrastructure | Investigate ownership and block unapproved use |
| Messages marked rejected | DMARC policy is stopping suspicious mail | Preserve evidence and contact the provider |
Validate Suspicious Activity
DMARC data is an indicator, not definitive proof of a breach. Confirm the finding through the third party’s administrative console, audit logs, API activity, user sign-in history, and support team. Look for newly created templates, unusual OAuth grants, changed forwarding rules, unfamiliar administrators, or a sudden rise in bounce complaints.
Check whether the source IP belongs to the vendor or an approved subcontractor. WHOIS data, passive DNS, threat intelligence, and the provider’s published SPF records can help, but vendor confirmation should carry the most weight. Attackers may imitate infrastructure details, and cloud providers can host both legitimate and malicious tenants.
Preserve report files, timestamps, headers from sample messages, authentication results, and relevant vendor responses. This evidence supports incident response and makes it easier to distinguish an isolated configuration error from an active account takeover.
Prioritize Containment and Recovery
Use the following actions to reduce exposure while keeping legitimate email flowing:
- Suspend or rotate compromised vendor credentials, API keys, and OAuth tokens.
- Ask the provider to review administrator access, sending logs, templates, and authentication events.
- Remove unauthorized DKIM selectors, SPF entries, integrations, or delegated subdomains.
- Place a narrowly scoped vendor stream under quarantine while the investigation continues.
- Notify internal teams and affected recipients when malicious messages may have been delivered.
Avoid weakening DMARC globally to solve a problem tied to one provider. A targeted change, such as disabling a compromised integration or isolating a subdomain, is safer than moving the entire domain to a less protective policy. If the incident affects broader domain trust, follow practical sender reputation guidance while remediation is underway.
Make Reporting Part of Ongoing Monitoring
Review aggregate reports on a regular schedule rather than waiting for user complaints. Automated processing can flag new source IPs, unexpected authentication failures, volume anomalies, and changes in DKIM or SPF alignment. Route those alerts to the team responsible for email security and vendor management.
After containment, verify that suspicious traffic has stopped and that legitimate mail still passes DMARC. Compare post-incident reports with the previous baseline, confirm that vendor controls were restored, and document the approved sending inventory. A recurring review also exposes dormant services that should be removed before they become an attack path.
Bring your DMARC reporting into a broader sender-trust workflow with domain reputation checks, authentication validation, and clear ownership for every external sender. Start reviewing your aggregate reports today, investigate unfamiliar patterns, and use the findings to close third-party access gaps before they become a larger phishing incident.