Exchange Online mail flow and connectors

Exchange Online's mail flow is mostly invisible — messages just arrive — but understanding how mail moves makes troubleshooting and design dramatically easier.

The default flow

For a typical cloud-only tenant:

1. Sender's mail server queries DNS for your domain's MX record.
2. The MX record points to your-domain-com.mail.protection.outlook.com (Exchange Online Protection).
3. EOP runs anti-spam, anti-malware, and anti-phishing on the incoming message.
4. If accepted, the message hands off to Exchange Online and lands in the recipient's mailbox.

Outbound mail does the same in reverse: Outlook (or any client) hands off to Exchange Online, which signs the message, applies any transport rules, and delivers via EOP to the recipient's MX.

Connectors

Connectors are explicit routing rules into or out of Exchange Online for non-default flows.

• Inbound connectors receive mail from a partner organisation, an on-prem Exchange server (hybrid), or a third-party service like a security gateway.
• Outbound connectors send mail to a partner organisation, an on-prem server, or a third-party gateway (for example, a smart host for compliance archiving).

Each connector has matching criteria, TLS requirements, and IP/certificate restrictions. Configuring them wrong is a top cause of mail delivery problems.

Transport rules

Transport rules (also called mail flow rules) act on every message that passes through Exchange Online — incoming, outgoing, or internal. They can:

• Add disclaimers and footers.
• Redirect, copy, or block messages by sender/recipient/content.
• Append warnings to external senders.
• Apply encryption (Office 365 Message Encryption) automatically.
• Hand off to compliance journaling.

The classic Exchange admin center exposes the full rule editor.

DNS records for senders

For deliverability and anti-spoofing, three DNS records matter:

• SPF — v=spf1 include:spf.protection.outlook.com -all (or ~all).
• DKIM — signing keys published as CNAMEs, enabled in Defender for Office 365.
• DMARC — policy record telling recipients what to do when SPF/DKIM fail.

Every Microsoft 365 tenant should publish all three.

Security posture beyond mail flow

Mail flow configuration and mailbox security posture are two different jobs that share the same admin console. Once mail flow itself is correct, the controls that most affect what actually reaches (or fools) an inbox are:

• Anti-phishing policies with impersonation protection — Defender for Office 365 can flag messages that impersonate specific protected users (executives) or your own domain, using mailbox intelligence trained on each user's real mail patterns rather than static rules alone.
• DMARC enforcement, not just publication — publishing a DMARC record at p=none collects reports but blocks nothing; moving to p=quarantine or p=reject is the step that actually stops spoofed mail claiming to be from your own domain, and it's worth doing gradually with report monitoring first since a too-fast move to p=reject can bounce legitimate mail sent through a forgotten third-party sender.
• Tenant Allow/Block List — the manual override layer for URLs, files, and sender domains that automated filtering gets wrong in either direction; entries here take precedence over the standard anti-spam and anti-phish verdicts.
• Safe Links and Safe Attachments (Defender for Office 365 Plan 1 and up) — time-of-click URL rewriting and sandboxed attachment detonation, layered on top of the connector-level filtering EOP already does. See Defender for Office 365 explained for the full picture.
• The External sender tag — a simple banner Outlook adds to mail from outside the organisation, cheap to enable and still one of the better user-awareness controls against display-name spoofing.

None of these are mail-flow settings in the connector/transport-rule sense above, but a tenant that has connectors perfectly configured and DMARC sitting at p=none with no impersonation protection is still wide open — the two halves of "Exchange Online security" have to be reviewed together.

Hybrid flow

In a hybrid Exchange deployment, on-prem and cloud mailboxes coexist. Mail between them flows through send connectors wired both ways, often via a smart host or TLS-only direct delivery. Hybrid is a transition state — Microsoft's recommended end state is cloud-only.

Troubleshooting

The Message Trace tool in the Exchange admin center tracks any individual message through every hop. The Mail Flow Insights dashboard surfaces patterns. For deeper traces, the Microsoft Remote Connectivity Analyzer tests authentication, autodiscover, and connector configuration end-to-end.

Connector security — the TLS and IP restriction pattern

Every connector should be scoped as tightly as the sending or receiving system allows, because a loosely-scoped connector is a mail-spoofing risk in its own right — an inbound connector that accepts mail from "any IP claiming to be the partner domain" with no certificate or IP restriction lets an attacker who simply knows the partner's domain name send mail that Exchange Online treats as if it genuinely came through that trusted relationship. The recommended pattern is certificate-based restriction where the partner supports it (the connector verifies a specific TLS certificate subject, not just "TLS was used"), falling back to IP-range restriction where certificates aren't available, and treating a connector with neither restriction configured as a standing finding worth fixing in any mail-flow security review.

Frequently asked questions

Do I need a connector just to send and receive ordinary internet email? No — a cloud-only tenant with no hybrid Exchange server, no third-party gateway, and no special partner-routing requirement needs zero connectors; ordinary mail flows through the default MX-record path with no explicit connector configuration at all. Connectors only enter the picture for the non-default routing scenarios described above.

What's the difference between a transport rule and a connector for controlling mail flow? A connector decides which network path a message takes into or out of Exchange Online (and under what TLS/authentication terms); a transport rule acts on messages already flowing through Exchange Online's normal pipeline, inspecting and modifying them (adding disclaimers, blocking by content, redirecting) regardless of which connector, if any, was involved in their delivery. They solve different problems and are frequently used together, not as alternatives to each other.

Can a transport rule reference a connector directly? Yes — a transport rule can be scoped to apply "only if the message was received from" or "only if the message will be sent via" a specific connector, which is the standard way to apply different disclaimer, encryption, or routing behaviour specifically to hybrid or partner-routed mail without affecting ordinary internet mail flow.