Why M365 Defender Is Not Showing DMARC Aggregate Report

If you expected to see DMARC aggregate reports in Microsoft 365 Defender and found a blank screen, you are not alone. This is one of the most common DMARC configuration questions from IT admins running Microsoft 365.

The short answer is that M365 Defender does not automatically pull in DMARC data for your domain. It only shows reports that are routed to a Microsoft-controlled address. If that routing is not set up, Defender has nothing to display.

This article explains the reporting chain, the specific configuration step that makes reports visible in Defender, and what to do when Microsoft tooling cannot give you the visibility you need.

How M365 Defender Obtains DMARC Aggregate Reports

DMARC aggregate reports are generated by receiving mail servers and delivered to the RUA address listed in your domain's DMARC DNS record. The report flows from the receiver to whatever address is configured as your RUA destination.

To make Defender show your DMARC data, you configure your DNS to send reports to Microsoft. The typical pattern looks like this in your DMARC record:


rua=mailto:reporting@your-tenant.microsoft.com

Microsoft's DMARC reporting infrastructure collects these reports and makes them available inside Defender for Office 365 under Email > DMARC.

If your DMARC record does not route reports to Microsoft, Defender has nothing to surface. That is the root cause in the majority of cases.

Why Your Reports Are Not Showing

1. No RUA address, or it points somewhere else

Many DMARC records start with p=none and omit the rua= tag entirely. Others have an rua= pointing at a third-party DMARC monitoring service rather than at Microsoft. If Microsoft is not in the report delivery path, the Defender dashboard stays empty.

Check your current DMARC record with a lookup tool or query DNS directly:


dig txt _dmarc.yourdomain.com

Look for the rua= line. If it is missing or points to a non-Microsoft address, that explains the blank Defender screen.

2. Third-party senders are not DMARC-aligned

Even with a correct RUA address, aggregate reports are only generated for messages that pass SPF or DKIM alignment. A third-party platform sending on your behalf without proper DKIM signing or SPF inclusion will cause those messages to fail DMARC alignment at receiving servers. Receivers then generate failure reports (RUF) for those messages, not aggregate reports (RUA).

The practical result: your Defender dashboard shows aggregate data only for senders that are fully DMARC-aligned. Misaligned third-party relays silently vanish from your visibility.

3. DNS propagation has not completed

A newly added or changed DMARC record can take up to 48 hours to fully propagate. During this window, some receiving servers use the old record or no record. Reports sent before propagation completes may not reach Microsoft's reporting infrastructure.

4. Defender is designed for receiving organizations

M365 Defender DMARC reporting works from the receiving side. It is built for organizations that want visibility into email their Microsoft 365 tenant receives. If your goal is to monitor DMARC for domains you send from, that is a fundamentally different use case and Defender is not designed for it.

If your role involves managing sending domains for your organization or for clients, Defender cannot give you the data you need. You need a sending-side monitoring tool.

How to Troubleshoot Step by Step

Work through these checks in order.

Step 1: Query your DMARC record


dig txt _dmarc.yourdomain.com +short

Confirm rua= is present and points to the address Microsoft provided for your tenant. If you are unsure of the exact address, check the Microsoft 365 Defender documentation for your tenant's specific DMARC reporting endpoint.

Step 2: Check the Defender DMARC dashboard

Open Defender for Office 365, go to Email > DMARC. A blank dashboard after 48 hours of correct DNS configuration means either the reports have not arrived yet or the RUA address is not correct.

Step 3: Confirm report delivery

If the dashboard is still empty beyond 48 hours, verify that Microsoft is actually receiving reports. Contact Microsoft support with your tenant ID and domain to confirm report delivery on their end.

Step 4: Audit third-party sender alignment

List every service that sends email on behalf of your domain: marketing platforms, SaaS tools, support systems. For each one, confirm either:

It sends from IPs or hostnames covered by your SPF record, or

It DKIM-signs messages with a key aligned to your organizational domain

Unaligned senders will not appear in your aggregate reports, no matter what you configure in Defender.

Getting DMARC Visibility That Actually Works

There is a category of problem where M365 Defender fundamentally cannot help:

You manage DMARC for multiple sending domains
You need aggregate data from all receivers, not just one
You want historical trends and alerting across your full sender landscape
Third-party platforms are generating enough misalignment that your Defender aggregate data is incomplete

For these scenarios, a dedicated DMARC monitoring service is the right tool. DMARCFlow collects reports from all receivers into a single view, independent of Microsoft's reporting address configuration. You can monitor any sending domain, regardless of how many third-party platforms send on its behalf.

This matters because most organizations today send email through a combination of Microsoft 365, marketing automation platforms, support tools, and transactional email services. A single misaligned third-party sender can silently degrade your DMARC aggregate visibility without triggering any alert from Defender.

DMARCFlow is built for exactly this scenario: ongoing, sending-side DMARC monitoring across multiple domains and third-party platforms, with alert routing and historical analysis. It works alongside Microsoft tooling rather than replacing it.

A Practical Path Forward

If M365 Defender is not showing your DMARC reports:

1. Confirm your DMARC record has rua= pointing at the correct Microsoft reporting address
2. Wait 48 hours for propagation and report delivery
3. Audit third-party senders for DMARC alignment
4. If Defender remains blank or does not support your use case, use a dedicated DMARC monitoring service for sending-side visibility

For most organizations, the answer is either a configuration fix or a different tool. The second option is not a failure. It is just recognizing that M365 Defender was built for inbound security, not for send-side DMARC operations.

FAQ

Can M365 Defender show me DMARC reports for domains I send email from?
No. Defender for Office 365 is designed for receiving organizations. It shows DMARC data for messages your Microsoft 365 tenant receives, not for messages your organization sends from its own domains.

How long does it take for DMARC reports to appear in Defender after configuring the RUA address?
Typically 24 to 48 hours for DNS propagation, plus up to another 24 hours for receiving mail servers to generate and deliver their first aggregate report after seeing your updated DMARC record.

Why do SPF and DKIM pass but DMARC still fails?
SPF and DKIM are independent authentication checks. DMARC requires alignment: the domain in the RFC5321.MailFrom address must match the domain in the RFC5322.From address (or the DKIM signature must align to that domain). You can have SPF and DKIM both passing and still fail DMARC if the domains do not align.

Does DMARCFlow work alongside Microsoft Defender?
Yes. DMARCFlow complements Defender by handling sending-side DMARC monitoring. If you manage multiple sending domains or need cross-receiver aggregate data in one place, DMARCFlow collects reports independently of Microsoft's reporting address configuration and works alongside Defender rather than replacing it.