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:

Sender's mail server queries DNS for your domain's MX record.
The MX record points to your-domain-com.mail.protection.outlook.com (Exchange Online Protection).
EOP runs anti-spam, anti-malware, and anti-phishing on the incoming message.
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.

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.

Frequently asked questions

When do I need a connector in Exchange Online?

When mail must flow between Exchange Online and something that is not the internet at large: an on-premises Exchange server (hybrid), a third-party email security gateway, a smart host, or devices and applications that relay through Microsoft 365 using your domain. Ordinary inbound and outbound internet mail needs no connector.

How do I let a printer or application send email through Microsoft 365?

Three options: SMTP AUTH client submission with a licensed mailbox (simplest, needs SMTP AUTH enabled for that mailbox and modern auth is required); direct send to your own tenant only (no auth, internal recipients only); or an inbound connector relay authenticated by certificate or static IP for volume and external recipients.

Why is my mail rejected with 'Relay Access Denied' or 5.7.x errors?

The sending system is not authenticated (SMTP AUTH off or disabled for the mailbox), it is sending from an IP or certificate not matching the connector, the sender domain is not an accepted domain, or a transport rule blocked it. The NDR's 5.7 code and the message trace identify which.