Microsoft 365 connectors explained: when you need them and how they work

Connectors are one of the least understood parts of Exchange Online. Many admins create one because a setup guide told them to, and never look at it again until mail stops flowing. This guide explains what connectors are, the handful of cases that need them, how Microsoft decides which connector applies, and the mistakes that cause bounces or let spam skip your filtering.

What is a connector in Microsoft 365?

Microsoft describes connectors as "a collection of instructions that customize the way your email flows to and from your Microsoft 365 or Office 365 organization" (Microsoft Learn). It also says that "most Microsoft 365 and Office 365 organizations don't need connectors for regular mail flow."

The wizard no longer says "inbound" and "outbound". You choose a start and end point instead, but the PowerShell cmdlets still use the old names:

You manage them in the Exchange admin center at Mail flow > Connectors.

When do you actually need a connector?

Microsoft lists the scenarios:

1. Some mailboxes on-premises, some in Exchange Online. You need connectors both ways. If you run Exchange Server and use the Hybrid Configuration Wizard, it creates them for you.
2. Only on-premises mailboxes, filtered by Microsoft's built-in security add-on. Connectors are required in both directions.
3. Printers, scanners and apps relaying through Microsoft 365. One inbound connector from your organization's email server. It's optional, because other methods exist; see sending scan-to-email through Microsoft 365.
4. Extra security with a partner. Optional connectors to require TLS or limit the partner's source IPs.

There's one more case Microsoft documents separately: a third-party filtering service in front of Exchange Online. That needs a Partner inbound connector, and it's the case most small businesses meet. It's covered below.

How does an inbound connector recognize the sender?

An inbound connector only applies if Microsoft 365 can match the connection to it. The options differ by type.

OnPremises connectors (from your organization's email server) offer two choices in the wizard:

• By verifying that the subject name on the certificate that the sending server uses to authenticate with Office 365 matches the domain entered in the text box below (recommended)
• By verifying that the IP address of the sending server matches one of the following IP addresses, which belong exclusively to your organization

The word "exclusively" matters. Never put a shared hosting or cloud provider IP on an OnPremises connector. Microsoft says OnPremises connectors "grant special rights," including "allowing relay through the tenant to internet destinations" and treating mail as internal in hybrid setups.

Partner connectors match on the sender domain or the sending IP, then apply security restrictions:

• Reject email messages if they aren't sent over TLS, optionally with And require that the subject name of the certificate that the partner uses to authenticate with Office 365 matches this domain name
• Reject email messages if they aren't sent from within this IP address range

Microsoft says choosing at least one is mandatory, and that mail that doesn't meet the restrictions is rejected (Microsoft Learn).

In PowerShell, the relevant New-InboundConnector parameters are:

Microsoft also warns: "You should not have IPs and certificates configured in the same partner connector. Instead, you should use separate connectors."

How do connectors work with a filtering gateway?

When your MX points to a filtering service, every message arrives at Microsoft 365 from the gateway's servers. Microsoft's third-party filtering guidance asks for two things:

1. Lock down Exchange Online with a Partner inbound connector that uses TlsSenderCertificateName ("preferred") or SenderIpAddresses, with the matching RestrictDomainsToCertificate or RestrictDomainsToIPAddresses set to $true. Microsoft says mail "smart-host routed directly to Exchange Online will be rejected." Those restrict parameters only work on Partner connectors, so you need one even if an OnPremises connector already exists.
2. Turn on Enhanced Filtering for Connectors on that connector, which Microsoft "highly recommend[s]" over an SCL -1 bypass rule. Without it, every message looks like it came from the gateway, and SPF, DMARC and spoof checks break.

Microsoft's example:

New-InboundConnector -Name "Reject mail not routed through MX" `
  -ConnectorType Partner -SenderDomains * `
  -RestrictDomainsToCertificate $true `
  -TlsSenderCertificateName *.gateway.example -RequireTls $true

The full procedure, including the order of steps and rollback, is in our guide to Enhanced Filtering for Connectors. Closing the direct route is covered in blocking filter bypass.

How do outbound connectors and smart hosts work?

An outbound connector from Office 365 to a partner organization has three decisions:

• Use of connector: Only when I have a transport rule set up that redirects messages to this connector, or Only when email messages are sent to these domains.
• Routing: Use the MX record associated with the partner's domain, or Route email through these smart hosts.
• Security restrictions: Always use Transport Layer Security (TLS) to secure the connection (recommended), then, under Connect only if the recipient's email server certificate matches this criteria, require a certificate from a trusted certificate authority (CA), optionally with a subject name or subject alternative name (SAN) that matches a domain you enter.

In PowerShell, -TlsSettings takes EncryptionOnly, CertificateValidation or DomainValidation (New-OutboundConnector).

A smart host is simply the server the connector hands mail to; our guide to smart hosts and SMTP relays explains the idea. If outbound mail goes through another service, update SPF. Microsoft notes you "would only need to include the third-party service in your SPF record if your organization sends outbound internet email through the service."

Which connector does Microsoft 365 use when several match?

For outbound mail to your own servers, Microsoft picks the most specific connector, in this order (Microsoft Learn):

1. A connector that exactly matches the recipient domain.
2. A connector that applies to all accepted domains.
3. Wildcard pattern matching, such as *.contoso.com.

For inbound Partner connectors, Microsoft warns that "you can't have an 'allow' by sender domain connector when there is a restrict by IP or certificate connector. The restrict connector will take precedence." It also says not to create duplicate connectors for one partner, because that "can cause errors, and your mail might not be delivered."

How do you validate a connector?

Connectors that send mail out of Microsoft 365 can be tested from the admin center (Microsoft Learn):

1. Go to Mail flow > Connectors and select the connector.
2. Choose Validate this connector.
3. Enter an email address on the destination server, select +, then Validate.
4. Read the results. Fix anything that fails before you turn the connector on.

Validation covers mail flowing from Microsoft 365. For inbound connectors, Microsoft's advice is to have the sending side send a test message that triggers the connector, then check it arrived. Open its headers in the Email Header Analyzer to confirm the original sender's IP is visible, which tells you Enhanced Filtering worked.

When you edit a connector, Microsoft keeps using the old settings until you save. That makes edits safe, but it also means a half-finished edit does nothing.

What are the common connector mistakes?

• OnPremises type for a cloud service. A gateway or SaaS sender belongs on a Partner connector. OnPremises connectors carry relay and internal-mail rights.
• Shared IPs on an OnPremises connector. Anyone else on that provider's IP range could relay through your tenant.
• Certificates and IPs on one Partner connector. Microsoft says to split them.
• Restricting before MX has propagated. Mail from senders still using the old MX will bounce. Wait for the old TTL; our guide to DNS TTL and MX changes explains how long.
• Missing one of the gateway's IP ranges. Some legitimate mail gets rejected or skips Enhanced Filtering.
• An SCL -1 rule left in place. It bypasses most of Microsoft's filtering for everything arriving through the connector.
• Forgetting old connectors. Remove connectors for services you no longer use, especially after switching spam filter providers.

Next steps

1. List your connectors with Get-InboundConnector | Format-List Name,ConnectorType,SenderDomains,SenderIPAddresses,TlsSenderCertificateName,RestrictDomainsToCertificate,RestrictDomainsToIPAddresses, and check each one has a reason to exist.
2. Check your MX with the MX Lookup. If it points to a gateway, confirm there's a restricted Partner connector with Enhanced Filtering on it.
3. Make sure your SPF record lists every service that sends outbound mail for you, using the SPF Checker.
4. If you're putting iBlockSpam in front of Microsoft 365, our Microsoft 365 setup page walks through the Partner connector and Enhanced Filtering steps, and the outbound relay page covers sending through us.