Why Exchange Online Sender-Domain Connectors Make Your Email Security Look Better Than It Is

Your DMARC aggregate reports show strong alignment pass rates. Your Exchange Online admin center shows clean connector configuration. Your team concludes email authentication is working well.

Then a spoofing incident happens anyway.

The gap between what DMARC reports show and what is actually happening is often created by a single, underappreciated Exchange Online feature: the sender-domain connector.

What the DMARC report actually shows when a connector is involved

When Exchange Online routes outgoing mail through a sender-domain connector, the From header passes DMARC alignment checks. This is technically correct. Microsoft is sending the message, and Microsoft controls the infrastructure, so the DKIM signature that Microsoft adds to the message signs a domain that aligns with your From address.

The aggregate report will show DKIM pass, alignment pass, and no failures for that traffic. Everything looks healthy.

The problem is not a misconfiguration. The problem is what that pass means.

Why alignment passing through a connector is not the same as your own infrastructure passing

When you send mail directly from your own mail server with your own DKIM key, DMARC alignment tells you something meaningful: the message was signed by your domain, using your key, from your infrastructure.

When Exchange Online sends the same message through a sender-domain connector, DMARC alignment still passes, but the meaning is different. Microsoft is the sending party. Microsoft holds the DKIM key. Microsoft controls whether the signature is applied, which selector is used, and when it is removed.

Your From header says yourdomain.com. The DKIM signature is controlled by Microsoft Online Services. The SPF result is for Microsoft's sending infrastructure, not yours.

This is not a failure. It is working as designed. But most practitioners read "DMARC alignment pass" as "our email authentication is functioning correctly," and that reading is incomplete when connector traffic is involved.

A quote worth keeping: "DMARC alignment passing through a connector tells you Microsoft controls the sending infrastructure. It does not tell you your own email security hygiene is sound."

What practitioners miss when they see DMARC green across the board

When connector traffic makes up a large share of outbound mail, aggregate reports show high alignment pass rates that feel reassuring. The numbers look good. The trend lines move in the right direction.

What they do not show is the difference between:

• Mail your organization sent directly, using your own DKIM key, from your own infrastructure
• Mail Exchange Online sent on your behalf, using Microsoft's DKIM key, through Microsoft's infrastructure

Both produce the same "pass" result in the report. Only one tells you your own authentication hygiene is working.

Practitioners who do not make this distinction often conclude they are ready to move to p=reject based on high pass rates, not realizing that the pass rate is inflated by connector traffic that tells them little about their own configuration quality.

Another gap: connector traffic can mask new sending relationships. If someone configures a new connector that routes mail through a third-party platform, that traffic also passes alignment. It will not appear as anomalous in aggregate reports unless you are specifically looking for it.

How to identify connector-mediated traffic in your DMARC aggregate reports

The key fields are the source IP and the DKIM selector domain. Connector traffic from Exchange Online will show Microsoft-owned IP ranges, and the DKIM selector will be controlled by Microsoft rather than your own domain.

The practical problem is that raw aggregate reports do not segment these two categories for you. Manually filtering XML to separate Microsoft-owned IPs from your own infrastructure is time-consuming and error-prone, especially across large report volumes.

This is where structured monitoring changes what you can see. DMARCFlow parses aggregate reports and groups sending sources by IP range and DKIM domain. Rather than scanning raw XML, you can view connector traffic and direct sends as separate categories. The pass rate for your own infrastructure becomes the metric that actually tells you whether your own configuration is working. The connector pass rate becomes context.

If the majority of your aligned passes come from IPs you do not recognize as your own sending infrastructure, the overall pass rate is not a reliable readiness signal for moving to p=reject.

This segmentation matters because the goal of monitoring is to know what your own infrastructure is doing. Connector traffic that Microsoft controls does not tell you whether your own DKIM keys are rotating correctly, whether your SPF record is complete, or whether a new unauthorized sender has started using your From domain through a connector nobody documented.

When connector traffic is expected versus when it is masking an unknown sending relationship

Not all connector traffic is a problem. If your organization legitimately uses Exchange Online to route all outbound mail, connector-mediated passes are expected and healthy.

The red flag is new connector traffic that you did not configure. If you see aligned passes from IPs in Microsoft's ranges that correspond to a connector you do not recognize, that is worth investigating. It may be a legitimate configuration you forgot to document, or it may be a sign that someone set up a sending channel you should know about.

Undocumented sending relationships are common in growing organizations. A team adopts a new SaaS platform that sends on behalf of your domain. The platform uses a connector. Alignment passes. Nobody adds it to the sender inventory. The security team does not see it in DMARC reports as an anomaly because it looks like normal Exchange Online traffic.

This is where the false sense of security becomes a real risk. The sending relationship exists, but it is invisible in the reports because it produces the same results as every other connector send.

DMARCFlow flags new sending sources that appear with your From domain. A new source IP that was not there yesterday is worth investigating regardless of whether it produces alignment passes. That is how you find the connector you did not know about.

Quick-reference summary

• Sender-domain connectors in Exchange Online pass DMARC alignment because Microsoft controls the sending infrastructure
• A DMARC alignment pass from connector traffic does not tell you your own authentication is working correctly
• High overall pass rates can be inflated by connector traffic, making them misleading as a readiness signal for p=reject
• The source IP and DKIM selector domain in aggregate reports tell you whether passes come from your infrastructure or Microsoft's
• New connector traffic that was not intentionally configured is a common blind spot that connector-mediated alignment passes can hide
• DMARCFlow separates connector passes from direct infrastructure passes so the meaningful metric is visible

Frequently asked questions

Does a DMARC alignment pass through a connector mean my email authentication is working correctly?

It means Exchange Online is sending mail that passes alignment. It does not tell you whether your own DKIM keys are valid, whether your SPF record is complete, or whether unauthorized senders are using your From domain through undocumented connectors.

Why do connector passes inflate my overall DMARC pass rate?

Connector traffic produces the same aligned pass result as direct sends, but the mechanism is different. Microsoft, not your organization, controls the DKIM signature. If connector traffic makes up a large share of outbound volume, it can drive overall pass rates up without reflecting your own configuration quality.

How do I separate connector traffic from direct sends in my DMARC reports?

Filter by source IP. Connector traffic from Exchange Online will come from Microsoft-owned IP ranges. Also check the DKIM domain in the auth result. Microsoft-controlled selectors typically show an onmicrosoft.com domain rather than your own selector.

Can connector traffic hide unauthorized sending activity?

Yes. If a new sending relationship is established through a connector, it produces aligned passes that look identical to your existing connector traffic. Without segmenting by IP and DKIM domain, new undocumented connectors are difficult to detect from aggregate reports alone.

Is connector traffic something to block or restrict?

Not necessarily. Connector traffic is a legitimate Exchange Online feature. The issue is not the connector itself but the blind spot it creates in DMARC monitoring. The goal is visibility, not restriction.