You publish a DMARC record with a valid rua address. Mail still reaches Microsoft 365, but the aggregate reports never arrive. Then you move the MX record back to Microsoft 365 and reports begin appearing again.
That behavior is usually not caused by a malformed DMARC record or a broken report mailbox. It is a consequence of which system receives the message from the internet.
Microsoft 365 sends DMARC aggregate reports for a domain when the domain's MX record points directly to Microsoft 365. If internet mail first goes to a third-party filtering service, appliance, or on-premises server, Microsoft 365 is no longer the first receiving system for that message flow. Microsoft documents that it does not send aggregate reports in this topology.
The rua tag tells a DMARC receiver where to send reports. It does not make every downstream mail system generate a report, and it does not make Microsoft 365 act as though it received the original SMTP connection.
This is separate from whether the message passes DMARC. Microsoft 365 can still evaluate and deliver the message, and it can still add authentication results, without producing the aggregate reports you expected.
Consider the direct path:
Internet sender -> Microsoft 365 -> recipient mailboxMicrosoft 365 sees the internet connection, evaluates the message, collects aggregate statistics, and sends a report to the rua destination published by the author domain.
Now compare it with a gateway path:
Internet sender -> third-party gateway -> Microsoft 365 -> recipient mailboxIn the second path, the gateway is the receiver at the public MX. Microsoft 365 receives a later SMTP hop from the gateway through an inbound connector. From Microsoft 365's perspective, the gateway is the system delivering the message into the tenant, not the original internet sender.
Microsoft's DMARC configuration guidance states that Microsoft 365 sends aggregate reports when the MX record points directly to Microsoft 365. It specifically excludes mail routed through a non-Microsoft service or device first, including hybrid flows where mail reaches on-premises infrastructure before Microsoft 365.
The result is easy to misread: Microsoft 365 is still the mailbox platform, but it is not the DMARC reporting receiver for that inbound flow.
rua is not a request to Microsoft 365 aloneA DMARC record such as this one requests aggregate reports:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.orgDMARC reports are generated by receiving organizations that process messages claiming to use the domain. The report destination is a request addressed to those receivers. It is not a central reporting service that follows the message through every hop.
That distinction matters when a gateway is the public receiver. There are now two possible reporting systems:
Ask the gateway provider whether it evaluates DMARC, retains results by author domain, and can deliver RFC-compatible aggregate reports to the rua address. Do not assume that forwarding a message to Microsoft 365 also forwards the gateway's reporting responsibility.
Start with DNS, not with the report mailbox.
Query the MX record for the domain whose reports are missing:
example.org. MX 10 mx1.example-filter.exampleIf the public MX names the gateway rather than a Microsoft 365 protection endpoint, Microsoft 365's direct-MX reporting condition is not met. Use a real domain only in production. The example.org name above is reserved for documentation.
Also check for multiple MX records and lower-priority fallback paths. A partial migration can produce inconsistent behavior: some senders may reach Microsoft 365 directly while others use the gateway.
Inspect a delivered message and identify:
Received header showing the original sending connectionAuthentication-Results headers added by the gateway and Microsoft 365ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal fieldsThe last connecting IP is often the gateway. That is normal SMTP behavior, but it means a receiver needs an explicit way to recover the original source context if it is expected to evaluate the message accurately.
Confirm that the record exists at the correct name and contains one valid DMARC TXT record:
_dmarc.example.org. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.org"Check that the report mailbox exists, accepts large compressed attachments, and is not silently filtering messages from report generators. These checks are worthwhile, but they will not make Microsoft 365 generate reports when the mail path fails its direct-MX condition.
Look for settings named DMARC reporting, aggregate reports, RUA, or similar. Confirm:
rua destination needs authorizationThe gateway may report only after it has observed enough traffic, or it may use a separate reporting address configured in its own control plane.
When mail must pass through a non-Microsoft service before Microsoft 365, configure an inbound connector and consider Enhanced Filtering for Connectors, also known as skip listing. Microsoft's Enhanced Filtering documentation describes this feature for exactly these routing scenarios.
Enhanced Filtering helps Microsoft 365 preserve the original source IP and sender context. It can improve SPF, DKIM, DMARC, spoof, and anti-phishing evaluation when the connector would otherwise make every message appear to come from the gateway. It is particularly useful when the intermediary modifies messages or does not provide usable ARC evidence.
It does not change the public MX topology. It does not turn Microsoft 365 into the direct internet receiver, and it does not guarantee that Microsoft 365 will start generating aggregate reports for the gateway-fronted flow.
That distinction prevents a common troubleshooting loop:
Use Enhanced Filtering to improve message evaluation. Use the gateway's reporting feature, a direct-MX design, or another receiving system for aggregate reporting.
Enhanced Filtering repairs source attribution for connector-based mail flow. It is not a DMARC report relay and does not remove Microsoft's direct-MX reporting condition.
There are three practical designs.
This is often the desired security architecture. In that case:
This design gives the gateway the best view of the original internet connection. Microsoft 365 remains the downstream delivery system.
If Microsoft 365 should be the system generating aggregate reports, the domain's inbound MX must point directly to Microsoft 365. Remove or redesign the gateway's position in front of the tenant, then verify the connector and routing changes carefully.
This is not a change to make solely to obtain reports. A gateway may provide important malware, impersonation, continuity, or compliance controls. Decide which system should be the primary inbound receiver before changing DNS.
Some organizations put different mail domains or subdomains on different inbound paths. For example, a low-risk subdomain can be tested with direct Microsoft 365 delivery while the main domain remains behind the gateway.
Document the MX, DMARC record, report owner, and authentication expectations for each domain. Do not infer the reporting behavior of one subdomain from another. A subdomain can inherit DMARC policy while still having a completely different MX and receiver topology.
rua addressChanging rua=mailto:dmarc-reports@example.org to another mailbox can fix a delivery or authorization problem, but it cannot make Microsoft 365 report a message it did not receive as the direct internet receiver.
Adding the gateway's IP to the domain's SPF record may be correct for a sender that sends outbound mail through that gateway. It does not fix inbound DMARC aggregate reporting. SPF authorization and report generation are different concerns.
Without Enhanced Filtering, Microsoft 365 may see the gateway's IP as the message source. Treating that connector IP as proof that every upstream sender is legitimate creates an authentication blind spot. Configure source preservation rather than broad filtering bypasses.
ARC preserves authentication evidence across an indirect path. A trusted ARC sealer can help Microsoft 365 handle legitimate modified or forwarded mail, but ARC does not define a replacement for aggregate reporting. The receiver that evaluates the message still owns the decision to report.
A missing report is not proof that DMARC is disabled. Check delivered headers, gateway logs, Microsoft 365 message trace, and the actual MX path. Reporting and filtering are related features, but they are not the same signal.
When Microsoft 365 reports disappear after introducing a gateway, record these facts:
rua value and any external-destination authorization record.Received, Authentication-Results, and ARC headers.The last point matters because an aggregate report can reflect a previous path for a while. Do not treat the first missing report after a DNS change as proof of a permanent failure, but do expect the new receiver to own reporting after the transition.
DMARC aggregate reports do not follow mail through the delivery chain. They are feedback from a receiver about the messages that receiver processed. When a third-party gateway sits in front of Microsoft 365, the gateway becomes the natural source of reports for that inbound path, while Microsoft 365 becomes a downstream receiver with a documented limitation on aggregate reporting.
The practical fix is to choose the reporting receiver intentionally: configure the gateway to report, route mail directly to Microsoft 365, or separate the domains and paths. Use Enhanced Filtering and ARC to improve authentication decisions, but do not confuse those controls with a way to make downstream Microsoft 365 reports reappear.