Exchange Online Connectors: The Spoofing Blind Spot

The connector that looks safe in the admin center

Open the Exchange Online admin center, go to Mail Flow, and check your connectors. You will see a list of inbound and outbound connectors, each tagged with a sending domain. If the domain matches your tenant, the UI shows a green check or a clean domain label. It looks safe.

Now check your DMARC aggregate reports for that same domain.

If you are like most Exchange Online operators, you will find alignment failures from IP addresses that are not in your sending infrastructure. These IPs belong to third-party services, marketing platforms, or internal relay servers that route mail through your domain without proper DKIM signing or SPF alignment. Your DMARC policy may be set to reject. The mail is failing. Your connector settings say everything is fine.

That gap between what the admin center shows and what DMARC reports reveal is the spoofing blind spot.

Why the admin center shows domain match but not sending infrastructure

Exchange Online connector settings are built around the concept of a sending domain. When you create a connector for a partner domain or a third-party service, you tell Exchange "mail from this domain is allowed." Exchange validates that the envelope-from domain matches your entry, and the UI marks it as trusted.

What the UI does not validate is the actual sending infrastructure behind that connector. A connector configured for newsletter.example.com may route mail through a shared relay operated by a third-party ESP. That relay may also handle mail from marketing.example.com, support.example.com, and a dozen other subdomains and sender identities. All of them appear under the same connector in Exchange Online. All of them inherit the same implicit trust.

When any of those sending identities fails DMARC alignment, the cause is not necessarily a compromise or a direct spoofing attack. It is often a legitimate relay that the connector configuration allows, but which does not meet the strict alignment requirements that DMARC enforces.

The admin center cannot show this. It shows domain match. DMARC aggregate reports show sending infrastructure reality.

What a misconfigured connector looks like in your DMARC aggregate report

A DMARC aggregate report (XML, as defined in RFC 7489) records every message that either passed or failed DMARC checks for your domain. Each record includes:

The source IP of the sending mail server
The result of SPF, DKIM, and DMARC alignment checks
The envelope-from domain (the RFC 5321 Mail From domain)
The header-from domain (the RFC 5322 From domain)
The DKIM domain that signed the message, if any

When a connector routes mail from a third-party relay, the source IP in the aggregate report is the relay server, not the original sender. If the relay does not DKIM-sign with your aligned domain, or if the SPF check runs against the relay's IP rather than the original sender's SPF record, the message fails alignment.

Here is a simplified example of what that record looks like in an aggregate report:

<record>
  <row>
    <source_ip>198.51.100.45</source_ip>
    <count>142</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
    <envelope_from>newsletter.example.com</envelope_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>newsletter-provider.example</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>newsletter-provider.example</domain>
      <result>pass</spf>
    </spf>
  </auth_results>
</record>

Notice the mismatch: the header_from is example.com, but both DKIM and SPF results are checked against newsletter-provider.example, not example.com. DMARC alignment requires the DKIM signature domain or the SPF HELO/EHLO domain to match the header-from domain exactly. A pass against newsletter-provider.example is not a DMARC pass for example.com.

This is the pattern that connector misconfiguration produces in aggregate reports. The connector allowed the relay. The relay did not align. DMARC reported a failure.

How to find connector-related alignment failures in your DMARC data

Start with your aggregate reports. Look for the following pattern across multiple records:

A consistent header_from domain (your domain) across many records
A varying or inconsistent envelope_from domain (often a subdomain used by an ESP or relay)
DKIM or SPF results that pass for a different domain than your header_from
Source IPs that are not part of your known sending infrastructure

When you find this pattern, ask: which connectors in Exchange Online handle mail from the envelope domains you are seeing? Trace the envelope domain back to the service that owns it. Then check whether that service DKIM-signs with your aligned domain or uses its own signing domain.

If the relay is under your control (for example, an internal SMTP gateway), the fix is to configure it to DKIM-sign with your organizational domain, or to update your SPF record to include the relay's IP ranges.

If the relay is a third-party service (an ESP, a marketing platform, a support ticketing system), the fix options are:

Ask the vendor to DKIM-sign with your organizational domain
Move that traffic to a subdomain with its own DMARC policy
Exclude that subdomain from your main domain's DMARC enforcement using the "subdomain policy" mechanism in RFC 9091
Set p=none for the affected subdomain while you work with the vendor

The key is that you cannot see this from Exchange Online connector settings alone. You need the aggregate report data to know which connectors are causing failures, how often, and for which sending identities.

Fixing the gap: connector hygiene and DMARC policy enforcement

Connector hygiene is the missing step between "set DMARC to reject" and "actually receiving legitimate mail." Here is the process most operators skip:

Map every connector to its sending purpose. Note the domains and subdomains each connector handles, and the infrastructure (IP ranges, third-party services) behind each one.
Collect aggregate reports for at least 2 weeks before changing your DMARC policy. You want a complete picture of what is currently sending under your domain.
Identify which connectors generate alignment failures in your aggregate reports. These are the ones that need remediation before you move to p=reject.
For each failing connector, decide whether to fix alignment (DKIM signing or SPF update), migrate traffic to a subdomain with separate policy, or accept p=none for that subdomain while working with the vendor.
Update your DMARC record to reflect the decision. Use "rua" to receive aggregate reports by email. Use "ruf" for forensic reports if you need per-message failure data.
Reassess your aggregate reports after 30 days at the new policy level. If failures spike, revert to p=none and repeat the mapping step.

This process is not optional. Operators who set p=reject without it routinely break legitimate mail flow, often from vendors they did not know were sending on their behalf.

How DMARCFlow surfaces connector risk automatically

The manual process above is manageable for one or two domains. It becomes a visibility problem at scale. When you are tracking multiple domains, multiple sending services, and aggregate reports that arrive in XML format from dozens of receiving domains simultaneously, the raw report volume makes the connector hygiene process impractical without automated help.

The gap this article describes is fundamentally a monitoring problem. You cannot see connector risk from Exchange Online settings alone. You need aggregate report data that shows you which source IPs, relay infrastructure, and sending identities are producing alignment failures for your domain.

This is the problem DMARCFlow was built to solve. Rather than parsing raw XML reports from each receiving domain, you get a structured connector risk view that maps alignment failures back to the sending infrastructure behind your Exchange Online connectors. The dashboard surfaces the specific mismatch between what Exchange Online shows as trusted and what DMARC alignment actually confirms: which connectors are generating failures, which sending identities are affected, and whether the failure pattern is growing or stable.

If you are managing Exchange Online connectors and you are not reviewing DMARC aggregate reports at least weekly, the admin center is giving you an incomplete picture. The connector risk view in DMARCFlow is where that picture becomes complete.

FAQ

Q: My Exchange Online connector shows a green check. Does that mean my DMARC is working correctly? A: No. The connector shows that the sending domain matches your configuration. It does not show whether the sending infrastructure behind that connector produces DMARC-aligned authentication results. Check your aggregate reports.

Q: Can I set my DMARC policy to reject and let Exchange Online connectors handle the rest? A: No. Exchange Online connector settings do not influence DMARC authentication results. If a relay behind your connector does not DKIM-sign with your aligned domain, mail will fail DMARC regardless of what your connector settings say.

Q: I found alignment failures from a vendor I cannot change. What do I do? A: Move that vendor's sending traffic to a dedicated subdomain with its own DMARC record. Set p=none for that subdomain while you negotiate proper alignment with the vendor. Your main domain's DMARC policy remains independent.

Q: How often should I review DMARC aggregate reports? A: At minimum, weekly during active DMARC rollout or after any change to your connector configuration. Monthly is acceptable for stable configurations, but you should check after any new vendor onboarding or infrastructure change.

Q: Does DMARCFlow support multiple domains with different connector configurations? A: Yes. DMARCFlow supports multi-domain monitoring, which is useful when different business units use different connectors or when parent and subdomains have separate DMARC policies.