Exchange Online Connectors: Hidden Domain Spoofing Risk

The connector screen looks reassuring. It is not.

You log into the Exchange Admin Center, create an inbound connector, set the sending domain to your own domain, and click Validate. The checkmarks come back green. Your mail flow is working.

What the screen does not show is that you have told Exchange Online to accept, from any Microsoft 365 tenant worldwide, any email that claims to be from your domain. The validation only checks that the DNS records are reachable. It says nothing about who is authorized to send.

The result is a gap between what administrators think their connectors do and what they actually do. DMARC aggregate report monitoring is the only reliable way to see whether your connectors are being used by parties you did not authorize. Tools like DMARCFlow are built specifically for this: parsing RUA reports and flagging aligned DKIM passes from IP addresses outside your known sending infrastructure.

What domain-scoped connectors actually do

When you scope an inbound connector to a domain, Exchange Online treats that scope as a routing instruction, not a security boundary. Any tenant that configures an outbound connector targeting your tenant can send mail with your domain in the From header, and your inbound connector will accept it.

Microsoft's partner routing scenario describes this as intended behavior: Company A routes mail through Company B's Microsoft 365 tenant. Company B sets a connector accepting domain-a.com. In practice, the same mechanism works in reverse for any misconfiguration, and the admin center gives no signal that it is happening.

If that partner, vendor, or internal tool sends without proper DKIM signing aligned to your domain, their mail enters your environment with sender identity intact. Your DMARC check may pass because the DKIM aligns, even though the message was never authorized by your infrastructure.

Why normal mail flow monitoring misses it

Most admins monitor mail through connector volume charts, NDR rates, and transport rule logs. These tools tell you how much mail came through a connector, not whether the sending identity on that mail was legitimate.

The connector acceptance criteria are not surfaced in the admin center's mail flow dashboard. You see the volume. You do not see the authorization gap.

DMARC aggregate reports are the one place where this becomes visible.

How DMARC reports show the problem

When a misconfigured connector accepts a spoofed message, the DMARC result depends on alignment, not on which tenant sent the mail.

If the sending tenant DKIM-signs outbound mail using a selector that publishes under your protected domain, the DKIM check passes and aligns. The envelope sender may or may not align depending on their SPF configuration. In the common case where the From header domain and the DKIM domain match, DMARC passes even though the message traveled through an unauthorized relay.

Your aggregate report will show aligned DKIM passes from IP addresses you do not recognize. That is the symptom. The cause is a connector accepting mail that should not have been accepted.

Real example from an RUA report:

Source IP: 40.107.x.x (Microsoft relay infrastructure)

-aligned DKIM: pass (d=contoso.com, matching protected domain)

SPF: pass (sending infrastructure belongs to relaying tenant)

Result: pass

The contoso.com domain passed DMARC. But the message entered through a third-party tenant's connector, not from contoso.com's own outbound systems. No alarm fired in the admin center.

How to detect connector abuse in your DMARC reports

Look for these patterns in your RUA data:

Aligned DKIM passes from IPs not in your SPF record. If a DKIM signature validates for your domain but the sending IP is not one you authorize for outbound mail, something is relaying through your tenant.

High-volume aligned DKIM passes from a single IP with no corresponding internal sending pattern. Legitimate bulk senders from your own infrastructure have predictable volume profiles. Unexpected spikes often indicate a misconfigured relay.

DMARC passes on subdomains you do not use for sending. If your RUA reports show aligned passes for subdomains that have no outbound mail system, a connector somewhere is accepting mail impersonating those subdomains.

Reviewing this manually in raw XML reports is time-consuming and hard to scale. DMARCFlow automates this: it parses RUA reports and surfaces aligned DKIM passes from unrecognized IPs, unexpected subdomain activity, and volume anomalies. Without this kind of monitoring, you are waiting for downstream complaints before you find out.

Hardening steps

1. Audit your inbound connectors. In the Exchange Admin Center, go to Mail flow > Connectors. For each inbound connector scoped to your primary domain, ask: is this scope actually necessary? If it was set up for a specific partner relay, confirm the partner tenant ID and verify their current configuration.

2. Switch to IP-scoped connectors where possible. If a partner or system always sends from fixed IP addresses, restrict the connector to those IPs instead of the domain. This removes the shared trust boundary.

3. Enforce MTA-STS. MTA-STS forces receiving mail servers to validate TLS certificates for your domain. It does not directly block connector abuse within Microsoft 365, but it ensures external receivers reject unauthenticated connections claiming to be your domain.

4. Move to p=reject. If you are still at p=none or p=quarantine, the connector gap is compounded by passive monitoring. With p=reject, unauthorized relays become immediately visible in your aggregate reports as DMARC failures rather than silent passes.

5. Review RUA reports weekly. The anomalies described above are fixable once you see them. Without monitoring, you find out through downstream complaints.

What to check in your reports right now

Open your latest DMARC aggregate report and answer three questions before doing anything else:

Which IP addresses show aligned DKIM passes? Cross-reference against your known sending infrastructure and your authorized third-party senders. Flag anything that does not match.

Which domains appear in aligned DKIM passes? If your protected domain list includes subdomains you do not send from, investigate why aligned DKIM is appearing for them.

Are there sudden volume changes on aligned DKIM passes? A significant spike in aligned passes from a partner IP you have not reconfigured is a signal worth following up.

If you find anomalies, the first question is: which connector is accepting this mail, and is that scope actually necessary?

FAQ

Does my inbound connector validate that the sending server is authorized to send for my domain?

No. Connector validation only checks DNS reachability and basic SMTP protocol compliance. It does not check domain authorization. There is no built-in mechanism within the connector UI to restrict acceptance to specific tenants or IP ranges based on domain ownership.

Can another Microsoft 365 tenant send email as my domain through my own inbound connector?

Yes. If their outbound connector routes mail through your tenant, and your inbound connector is scoped to your domain, their mail enters your tenant with your domain in the From header. This is documented behavior for partner routing scenarios. It is not a bug.

How do I detect this happening?

DMARC aggregate reports are the primary detection mechanism. Look for aligned DKIM passes from IP addresses outside your authorized sending infrastructure. If you are not receiving RUA reports, set that up first. Without aggregate reports, the connector authorization gap is invisible.

Will MTA-STS fix this?

MTA-STS helps with inbound security from external receivers, but it does not restrict how Microsoft 365 handles mail arriving through a misconfigured connector. Treat it as one layer of defense-in-depth, not as a fix for connector scoping behavior.

Is this a new risk?

No. The connector scoping behavior has been unchanged for years. What has changed is that more organizations use Microsoft 365 as a relay hub for third-party tools, and wider DMARC adoption has made the gap visible to those who are reviewing their reports.