Which ISPs deliver DMARC reports and what configuration is needed?
Google, Yahoo, Microsoft 365, Zoho, Seznam, Mail.ru, Rackspace's emailsrvr.com platform, and many regional or corporate mailbox providers send DMARC aggregate reports when they receive mail using your domain. The configuration needed is a valid DMARC TXT record with a rua destination. If the reporting address is outside the protected domain, the destination domain also needs external reporting authorization, often called EDV.
If Google is the only reporter after a week, I do not treat that as proof that nobody else supports DMARC reporting. It usually means one of four things: your mail mostly went to Google recipients, another receiver did not get enough mail to produce a report, the DMARC record has a syntax or delivery issue, or the external destination verification record is missing at the report receiver domain.
Microsoft needs a current caveat. Older operational advice often said Microsoft did not send aggregate reports. Microsoft 365 now documents aggregate report delivery for domains with a valid rua value, provided the recipient domain routes inbound mail directly to Microsoft 365. Microsoft still does not send DMARC forensic reports.
Short answer
The practical answer is: expect reports from the big mailbox providers, but do not expect a complete report from every ISP. DMARC reporting is receiver-side behavior. The receiver has to support report generation, receive mail using your domain during the report window, accept your rua destination, and successfully deliver the compressed XML report email.
- Common reporters: Google, Yahoo, AOL-managed mail, Microsoft 365, Zoho, Seznam, Mail.ru, and Rackspace commonly appear in RUA data.
- Mixed reporters: Corporate gateways, regional ISPs, universities, and security appliances vary by implementation and policy.
- Rare reporters: Forensic reports are uncommon because they can expose message-level data and create privacy risk.
- Best signal: Report diversity follows recipient diversity. A domain that sends mostly to Gmail gets mostly Google reports.
The key rule
A DMARC report is not sent by your email platform. It is sent by the receiving side after that receiver evaluates messages claiming to be from your domain. That is why one domain can see Google, Yahoo, and Microsoft reports while another domain sees only Google during the same week.
Which providers usually send reports
I separate provider support into two practical categories: aggregate reporting and forensic reporting. Aggregate reporting is the normal RUA feed that most DMARC monitoring workflows depend on. Forensic reporting is the RUF feed, and it is far less dependable. For most domains, RUA is the feed worth designing around.
|
|
|
|
|---|---|---|---|
Google / Gmail | Yes | Limited | Needs valid RUA and EDV |
Yahoo / AOL | Yes | Limited | Daily reports with traffic |
Microsoft 365 | Yes | No | Direct MX required |
Zoho | Yes | Limited | Depends on traffic |
Seznam | Yes | Limited | Regional signal |
Mail.ru | Yes | Limited | Regional signal |
Other ISPs | Mixed | Rare | Receiver-specific |
Typical DMARC report behavior by receiver type.
This table is a working expectation, not a guarantee. The only report you can rely on is the one you actually receive and parse. That is why a proper DMARC monitoring workflow should show reporting organizations, source IPs, authentication alignment, and policy disposition together.
Microsoft 365 admin center showing a DMARC TXT record in domain DNS settings.
Configuration that enables reports
The minimum setup is a DMARC TXT record at the protected domain. The record must start with v=DMARC1, include a policy tag, and include a rua tag when you want aggregate reports. I usually start monitoring with p=none, confirm the legitimate senders, then move toward quarantine or reject after the reporting data is clean.
Basic DMARC record with aggregate reportingDNS
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@reports.example.net; pct=100
Before changing policy, check the record syntax with a DMARC checker. A small typo in the tag order, missing mailto prefix, duplicated TXT record, or malformed destination can stop some receivers from sending reports even when Google still sends one.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A report destination also has to accept the volume. If you send to many domains, you receive many compressed XML files, usually daily. A personal mailbox is the wrong place for this. A parser or monitoring platform should deduplicate reports, normalize provider naming, and keep history long enough to spot sender changes.
How EDV works
EDV matters when the rua address points outside the protected domain. If example.com sends DMARC aggregate reports to dmarc@reports.example.net, the reports.example.net DNS zone needs to prove that it accepts reports for example.com. Without that proof, standards-compliant receivers are allowed to skip sending reports to that external address.
External reporting authorization recordDNS
Host: example.com._report._dmarc.reports.example.net Type: TXT Value: v=DMARC1
This is the record people often miss. It is not published at the sender's DNS zone. It is published at the domain that receives the DMARC reports. That is why a company using a third-party report address cannot fully fix EDV from only the sender domain DNS panel.
Do not use Google as the EDV test
Some receivers have historically sent reports even when the external authorization record was missing. That behavior does not prove your EDV is correct. I test EDV directly in DNS and then wait for reports from more than one receiver.
For a deeper look at the exact DNS name format, use the external reporting reference. It is the quickest way to confirm whether the record belongs under the sender domain or the reporting destination domain.
Why only Google appears first
Seeing only Google in the first week is common because Google is often the largest recipient base, it processes high volumes quickly, and its reports are easy to recognize. That does not mean Microsoft, Yahoo, or regional providers failed. It means the early sample is narrow.
First-week report coverage
Use these bands as operational signals, not hard pass or fail rules.
Healthy
5+ reporters
Several reporting organizations appear after broad recipient traffic.
Investigate
1 reporter
Only one large provider appears despite diverse outbound mail.
Broken
0 reports
No RUA reports arrive after real mail and a valid DNS window.
Normal reasons
- Recipient mix: Your recent mail mostly reached Gmail or Google Workspace users.
- Low volume: A provider received too little mail to create a useful daily file.
- Timing: Different receivers batch and deliver reports on their own schedules.
Configuration problems
- Missing EDV: External RUA delivery is not authorized at the destination domain.
- Bad syntax: The DMARC record has malformed tags, spaces, or destinations.
- Mail routing: A security gateway in front of Microsoft 365 prevents Microsoft reports.
When Google and Yahoo behavior needs separate troubleshooting, compare the raw XML metadata and receiver names with Google and Yahoo reports. The report source name, date range, and policy evaluation fields usually show whether the issue is missing traffic or broken configuration.
How I troubleshoot missing reports
I use a simple sequence because report gaps are easy to overthink. Start with DNS, then confirm traffic, then inspect the mailbox or parser, then compare receiving providers.
- Validate DMARC: Confirm there is exactly one DMARC TXT record at the protected domain.
- Check RUA: Confirm every aggregate destination uses mailto and accepts inbound report email.
- Check EDV: Publish the authorization TXT record at the external reporting domain.
- Send traffic: Send real mail to recipients across Google, Yahoo, Microsoft 365, and regional providers.
- Wait daily: Allow at least one full reporting cycle after DNS propagation.
- Review parsing: Check rejected attachments, compressed XML handling, and duplicate report grouping.
Flowchart showing DMARC report troubleshooting steps.
For broader checks across DMARC, SPF, and DKIM, run a domain health check. That catches related issues, such as SPF lookup problems or DKIM records that exist but do not align with the visible From domain.
Where Suped fits
Suped is relevant when the question moves past "who sent me XML files" and becomes "which senders are legitimate, what is broken, and what should I change next." Suped ingests aggregate reports, groups providers and source IPs, detects authentication issues, and turns the report feed into steps to fix.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For most teams, Suped is the best overall fit when DMARC reporting has to sit beside SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist (blacklist) monitoring, real-time alerts, and multi-domain management. That matters because report delivery issues are rarely isolated to the RUA tag. They often involve sender inventory, DNS control, alignment, and reputation checks at the same time.
A practical Suped workflow
- Add domain: Monitor the DMARC record and confirm reports are arriving.
- Verify sources: Separate approved senders from unknown or spoofed traffic.
- Fix DNS: Use diagnostics to correct SPF, DKIM, DMARC, and EDV problems.
- Stage policy: Move from monitoring toward enforcement when the data is stable.
Views from the trenches
Best practices
Publish the external reporting TXT record before expecting full provider coverage.
Use a dedicated RUA mailbox or platform so raw XML files do not bury personal inboxes.
Compare report volume against real recipient traffic, not against a fixed provider list.
Keep RUA reporting active through policy changes so failures stay visible during rollout.
Common pitfalls
Assuming Microsoft is silent can hide MX routing limits in front of Microsoft 365 tenants.
Missing EDV records cause some receivers to skip external RUA destinations without notice.
Using one personal inbox for reports creates noisy storage and weak operational ownership.
Treating Google as the only signal misses regional providers and hosted mailbox traffic.
Expert tips
Check DNS at the report destination, because the protected domain is only half the setup.
Expect RUA reports only from receivers that actually accepted mail using the domain that day.
Use relaxed alignment first unless a strict policy has a defined sender inventory ready.
Validate reports after each DNS edit, because old cached records can delay results for hours.
Marketer from Email Geeks says Microsoft reporting behavior should be checked against current tenant routing, because old assumptions about no aggregate reports are out of date.
2024-10-09 - Email Geeks
Marketer from Email Geeks says a missing external reporting authorization record can explain why some providers ignore a RUA destination while Google still sends files.
2024-10-09 - Email Geeks
Practical closing position
Yes, many ISPs and mailbox providers deliver DMARC aggregate reports. Google is usually the first one people notice, but Yahoo, Microsoft 365, Zoho, Seznam, Mail.ru, emailsrvr.com, and other receivers also show up when they process enough mail and the reporting path is valid.
The required configuration is not complicated, but it has to be exact: one valid DMARC record, a working rua mailbox or platform address, and EDV when reports go to another domain. Once those records are right, report coverage depends on where your mail actually lands.
The best operational move is to treat DMARC reports as a data feed, not as inbox messages. Parse them, monitor trends, fix alignment issues, and keep the reporting destination stable while you move policy toward enforcement.
