How Exchange Online Sender-Domain Connectors Become a Spoofing Risk on Shared Relays

A SOC team found six invoice phish arriving through a partner relay. The relay had recently started accepting mail for three clients. One of those clients could submit mail using the partner domain, so the domain string itself had become the trust boundary. The connector in the Exchange Online admin center still showed valid.

This is not a hypothetical. It is a specific, documented failure mode that the admin center does not surface.

What went wrong

Exchange Online inbound connectors have several scoping options. The most permissive is a sender domain scope with no IP address restriction and no certificate requirement. When a partner or third-party relay uses this configuration, any customer sharing that relay infrastructure can submit mail as your domain. The connector accepts it because the domain string matches, regardless of which customer submitted the message.

The scenario breaks down like this:

1. Your organisation sets up an inbound connector scoped to partner.example.com.
2. The partner uses a shared relay that serves multiple clients, including one that also uses partner.example.com.
3. That other client can submit mail claiming to be from your domain through the same relay infrastructure.
4. Exchange Online accepts the mail because the connector matches the domain, not the sender.

The connector works correctly. It is doing exactly what it was configured to do. The problem is that the configuration itself creates a trust boundary that is wider than it looks.

Why the admin center does not warn you

The Exchange Online admin center shows a connector as valid when the domain validates and the connector is active. It does not show you the blast radius of a domain-scoped connector on shared infrastructure. There is no warning that says "this connector will accept mail from any relay that can connect to Microsoft's servers, regardless of which customer sent it."

This is not a UI bug. It is a documentation and configuration problem. The tooling does what it is designed to do. The design does not account for the operational reality of shared relays.

What a safe connector configuration looks like

There are three constraint options for inbound connectors, in order of security:

Source IP restrictions. Add a specific IP address or IP range owned by the relay provider. Only mail originating from those IPs passes the connector. This is the strongest option when a static IP is available. Most managed relay providers can supply a dedicated IP.

TLS certificate constraints. Require the connecting relay to present a specific TLS certificate. This ties the connector to a particular certificate issued to a particular entity. Even if someone else gets access to the relay infrastructure, they cannot complete TLS authentication without the right certificate.

Domain scope only. The most permissive option. Requires only that the sending domain matches the connector domain. Suitable only for dedicated infrastructure where no other customer shares the relay path.

If your connector currently uses domain scope only, the question to ask your relay provider is simple: can any other customer of this relay submit mail using our domain? If the answer is unknown or yes, the connector needs a tighter constraint.

How to audit your existing connectors today

Run the following in Exchange Online PowerShell to list all inbound connectors and their current constraints:

powershell
Get-InboundConnector | Select-Object Name, ConnectorType, SenderDomains, RestrictDomainsToIPAddresses, RestrictDomainsToCertificates, CloudServicesMailEnabled | Format-List

Flag any connector where:

• RestrictDomainsToIPAddresses is False


• RestrictDomainsToCertificates is False


• SenderDomains is set to a domain you own or control


• ConnectorType is set to OnPremises or Partner

A connector meeting all four conditions is using domain scope only and is potentially exposed if the relay is shared.

If you have many connectors, filter further:

powershell
Get-InboundConnector | Where-Object {\$_.RestrictDomainsToIPAddresses -eq \$false -and \$_.RestrictDomainsToCertificates -eq \$false -and \$_.CloudServicesMailEnabled -eq \$false} | Select-Object Name, SenderDomains, Enabled

This returns connectors that use domain-only scope and are not Microsoft-managed. These are the ones to review first.

What to do if you find a gap

Priority order:

Immediate. Contact the relay provider and request a dedicated IP or certificate constraint for the connector. Set a hard deadline. If the provider cannot supply either, the connector should be disabled until a safe configuration is available.

Short term. Enable domain-to-IP mapping in your SPF record if the relay provider can commit to a static range. This does not fix the connector gap but adds an authentication layer that the shared relay cannot easily bypass.

Longer term. Move any relay-dependent mail flows to dedicated infrastructure. If a relay provider cannot offer a per-customer IP or certificate, that provider is not suitable for domain-scoped connectors on shared infrastructure.

The partner in the original incident asked for two weeks to split the relay. That is reasonable if they are moving to a dedicated IP. It is not reasonable if they are simply reorganising the shared infrastructure without a per-customer constraint.

How to detect this being exploited

DMARC aggregate reports are the fastest way to spot connector-based spoofing. Look for these patterns:

• SPF failures from IP addresses that do not belong to your known relay providers
• DKIM failures where the signing domain matches your domain but the aligned DKIM signature comes from an unexpected source
• High volumes of auth results from a single source IP that appears in rua reports but is not in your SPF record

If you are not receiving DMARC rua reports, you cannot see this class of attack. Setting up rua reporting takes a DNS record and a receiving endpoint. Many organisations skip this because it feels optional. It is not.

A DMARC monitoring tool that aggregates and alerts on these patterns catches connector spoofing faster than checking connector settings manually. DMARCFlow receives DMARC rua reports automatically, parses authentication results, and flags when SPF or DKIM failures originate from IPs you have not authorised. For connector-based spoofing specifically, the tool surfaces DKIM failures where the signing domain matches yours but the key was never published in your DNS. That is a clear signal that something is submitting mail as your domain through a path your DNS does not recognise. Without an aggregated rua feed, you do not see that signal until the phishing reports come in.

FAQ

Can I use domain scope safely with any shared relay?

No. Domain scope means the connector accepts mail from any source that presents your domain in the MAIL FROM or From header. On shared relay infrastructure, that includes every other customer of that relay. The only safe configuration for shared relays is IP restriction or TLS certificate constraint.

What if my relay provider cannot give me a static IP?

If the provider uses dynamic IP ranges or cannot commit to a fixed set, do not use a domain-scoped connector with them. Use a dedicated sending domain that does not match your primary brand domain. This limits the blast radius to a subdomain rather than your apex domain.

Does MTA-STS help with connector spoofing?

MTA-STS enforces TLS for message transport, but it does not authenticate the sender. A malicious actor can still use a misconfigured connector to submit mail that passes MTA-STS validation if the relay has a valid certificate. MTA-STS complements connector hardening but does not replace it.

What does this look like in a DMARC report?

In a DMARC rua report, connector spoofing typically appears as an SPF failure with an SPF-authenticated IP that is not yours, or a DKIM result of pass on a DKIM signature from an unexpected key. The report will show the sending IP, which you can then map to your relay provider. If the IP is shared, you have found the gap.

---

The connector validated. The admin center showed green. The problem was that the trust boundary was defined by a domain string, and that string lived on shared infrastructure. Tighter scoping closes the gap. DMARC monitoring catches it when scoping is not yet tightened.