Exchange Online connectors explained: inbound, outbound and partner setups

Exchange Online connectors are sets of instructions that change how mail flows between your Microsoft 365 tenant and a specific other system: your own on-premises servers, a business partner, a third-party filtering service, or devices that relay through the tenant. Most tenants need no connectors at all. You add an outbound connector (Office 365 to a partner or your server) to force TLS or route through a smart host, and an inbound connector (a partner or your server to Office 365) to identify a sender by IP address or certificate and reject mail that doesn't meet your conditions.

Who this is for and what you will have at the end

This guide is for Exchange Online administrators who connect the tenant to a partner that requires TLS, a gateway that owns the MX record, a non-hybrid on-premises server, or a relay that fails with a TenantAttribution error.

By the end you will have:

• A clear decision on whether a connector is needed and which type (Partner or OnPremises).
• Working outbound and inbound connectors for partner, gateway and on-premises scenarios, built in the Exchange admin center (EAC) or PowerShell.
• A validated configuration and a short list of the errors that point back to connector problems.

If you are planning a larger move, connectors are one piece of the mail flow design covered in the Google Workspace to Microsoft 365 migration guide. If your on-premises server is Exchange and you want full coexistence, read the hybrid remote move guide instead: the Hybrid Configuration Wizard builds the connectors for you.

How connectors work

Inbound and outbound are now "from" and "to"

The new EAC no longer uses the words inbound and outbound. When you create a connector you choose a Connection from and a Connection to endpoint. Under the hood nothing changed, and the PowerShell cmdlets still carry the old names: an inbound connector (New-InboundConnector) handles mail coming into Microsoft 365, and an outbound connector (New-OutboundConnector) handles mail leaving it.

Partner versus OnPremises

Every connector has a ConnectorType:

• Partner services domains that are external to your organization. Restriction settings such as RestrictDomainsToIPAddresses, RestrictDomainsToCertificate and RequireTls on the inbound side apply only to Partner connectors.
• OnPremises services domains that your own on-premises organization uses. These connectors grant special rights to matching mail, such as relaying through the tenant to internet destinations or treating hybrid mail as internal.

When you actually need one

Microsoft's guidance is that Exchange Online sends and receives internet mail without connectors. You need them in these cases:

• Some mailboxes live on your own servers and some in Exchange Online.
• You use the Built-in security add-on for on-premises mailboxes.
• Devices or applications relay through Microsoft 365 (optional; other options exist that need no connector).
• You want TLS or source IP restrictions with a partner (optional).
• A third-party service sits in front of or around Microsoft 365.

Connectors also help avoid graylisting. When large volumes arrive from your on-premises servers or partners without a connector, Microsoft 365 can throttle the source and return temporary 451 4.7.500-699 (ASxxx) errors.

Prerequisites

• An account with permission to manage connectors in Exchange Online (for example, membership in the Organization Management role group).
• The Exchange Online PowerShell module:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

• All your sender domains added and verified as accepted domains. Microsoft requires accepted domains to be configured before you set up a connector.
• For certificate-based connectors, a certificate from a commercial certification authority that both sides trust.
• For partner connectors, the partner's sending IP ranges or certificate subject, and their receiving MX or smart host name.

Step 1: Inventory what already exists

Duplicate connectors for the same partner cause errors and undelivered mail, and hybrid tenants already have connectors created by the Hybrid Configuration Wizard. List everything first:

Get-InboundConnector | Format-Table Name,ConnectorType,ConnectorSource,Enabled
Get-OutboundConnector | Format-Table Name,ConnectorType,ConnectorSource,RecipientDomains,Enabled

ConnectorSource shows HybridWizard for connectors the wizard created and Default for manually created ones. Leave hybrid connectors to the wizard.

Step 2: Force TLS on mail you send to a partner

In the new EAC:

1. Go to Mail flow > Connectors and select + Add a connector.
2. Under Connection from, choose Office 365. Under Connection to, choose Partner organization. Select Next.
3. Enter a name and select Next.
4. On Use of connector, choose Only when email messages are sent to these domains, add the partner domain (for example fabrikam.com) and select +. The alternative, Only when I have a transport rule set up that redirects messages to this connector, is covered in Step 5.
5. On Routing, choose Use the MX record associated with the partner's domain, or Route email through these smart hosts if the partner gave you a specific host.
6. On Security restrictions, select Always use Transport Layer Security (TLS) to secure the connection (recommended) and choose how strictly to check the certificate under Connect only if the recipient's email server certificate matches this criteria. If you choose Issue by a trusted certificate authority (CA), you can also require that the subject name or SAN matches a domain.
7. On Validation email, add a test address at the partner, select + and then Validate.
8. Review and select Create connector.

The PowerShell equivalent uses TlsSettings. Its values are EncryptionOnly (encrypt, no certificate check), CertificateValidation (encrypt plus chain and revocation checks) and DomainValidation (all of that plus a check that the certificate FQDN matches TlsDomain):

New-OutboundConnector -Name "To Fabrikam (forced TLS)" -ConnectorType Partner `
    -RecipientDomains fabrikam.com,*.fabrikam.com `
    -UseMXRecord $true `
    -TlsSettings DomainValidation -TlsDomain *.fabrikam.com

Outbound connectors also have MtaStsMode and SmtpDaneMode settings; both default to Opportunistic. Leave them at their defaults unless you have a specific reason, because None removes protection against downgrade attacks and spoofed MX redirection.

Step 3: Require TLS or a source IP range for mail from a partner

In the new EAC:

1. Go to Mail flow > Connectors > + Add a connector.
2. Under Connection from, choose Partner organization. Connection to is fixed to Office 365.
3. Name the connector.
4. On Authenticating sent email, choose either By verifying that the sender domain matches one of the following domains or By verifying that the IP address of the sending server matches one of the following IP addresses, which belong to your partner organization.
5. On Security restrictions, select Reject email messages if they aren't sent over TLS (optionally requiring that the certificate subject matches the partner's domain), and/or Reject email messages if they aren't sent from within this IP address range. You must choose at least one.
6. Review and select Create connector.

The same thing in PowerShell, scoped to the partner domain and restricted to their IP range with TLS required:

New-InboundConnector -Name "From Fabrikam (TLS + IP)" -ConnectorType Partner `
    -SenderDomains *.fabrikam.com `
    -SenderIPAddresses 203.0.113.0/24 -RestrictDomainsToIPAddresses $true `
    -RequireTls $true

Keep these constraints in mind:

• SenderIPAddresses accepts IPv4 only, with CIDR masks from /24 to /32. IPv6 isn't supported.
• With RestrictDomainsToIPAddresses $true, mail from the listed sender domains is rejected if it comes from any other IP address.
• Don't put IP addresses and certificates in the same partner connector. Microsoft recommends separate connectors.
• You can't have an "allow" connector by sender domain alongside a connector that restricts by IP or certificate for the same traffic: the restricting connector wins, because partner connectors are looked up by IP or certificate when restrictions are applied.

Step 4: Lock down the tenant behind a third-party gateway

When your MX record points to a non-Microsoft filtering service, internet senders can still bypass it by delivering straight to your contoso-com.mail.protection.outlook.com host. Microsoft's recommended fix is a Partner inbound connector that accepts mail only from the service, preferably identified by certificate:

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

Or by the service's published IP ranges:

New-InboundConnector -Name "Reject mail not routed through gateway" -ConnectorType Partner `
    -SenderDomains * -RestrictDomainsToIPAddresses $true `
    -SenderIPAddresses 198.51.100.0/24

Even if you already have an OnPremises inbound connector for the same certificate or IP addresses, you still need this Partner connector, because the restriction parameters only work on Partner connectors. The two coexist without problems.

Then turn on Enhanced Filtering for Connectors (skip listing) on that inbound connector, so Microsoft 365 sees the real sending IP address instead of the gateway's. In the Microsoft Defender portal go to Email & Collaboration > Policies & Rules > Threat policies > Enhanced filtering, or in PowerShell:

Set-InboundConnector -Identity "Reject mail not routed through gateway" -EFSkipLastIP $true

Microsoft strongly recommends this over a mail flow rule that sets SCL to -1, because gateway IP addresses are usually shared by many customers. Your SPF record stays v=spf1 include:spf.protection.outlook.com -all unless you also send outbound mail through the service.

Step 5: Route only some mail through a connector

Sometimes only certain messages should take a special path, for example mail with a specific classification that must go through an encryption appliance. Create the outbound connector with Only when I have a transport rule set up that redirects messages to this connector (IsTransportRuleScoped $true), and point an existing mail flow rule at it with the RouteMessageOutboundConnector parameter:

New-OutboundConnector -Name "To encryption appliance" -ConnectorType Partner `
    -IsTransportRuleScoped $true -UseMXRecord $false -SmartHosts relay.contoso.com `
    -TlsSettings CertificateValidation
 
Set-TransportRule -Identity "Route confidential mail" -RouteMessageOutboundConnector "To encryption appliance"

Step 6: Connect a non-hybrid on-premises mail server

If you have your own SMTP server and are not using an Exchange hybrid deployment, you need two connectors.

Office 365 to your organization's email server. Create it in the EAC with Connection from set to Office 365 and Connection to set to Your organization's email server, enter the smart host name or IP address and select +, set TLS on Security restrictions, then validate with an address that lives on the on-premises server. Before you create it, open port 25 on your firewall to the Exchange Online IP ranges and make sure the server has a CA-signed certificate.

Your organization's email server to Office 365. Choose Your organization's email server under Connection from, then on Authenticating sent email pick either the certificate option (recommended) or the IP address option. For relaying to the internet, the certificate subject must match an accepted domain, or all sender domains must be accepted domains.

On an Exchange Server, the matching send connector looks like this (the CloudServicesMailEnabled parameter is available in Exchange 2013 and later):

New-SendConnector -Name "My company to Office 365" -AddressSpaces * -CloudServicesMailEnabled $true `
    -Fqdn mail.contoso.com -RequireTLS $true -DNSRoutingEnabled $false `
    -SmartHosts contoso-com.mail.protection.outlook.com -TlsAuthLevel CertificateValidation

How Exchange Online picks an outbound connector

With several outbound connectors for the same scenario, Microsoft 365 selects the most specific match for each recipient:

1. A connector that exactly matches the recipient domain.
2. A connector that applies to all accepted domains.
3. A wildcard match, for example *.contoso.com.

Microsoft's example uses a tenant whose accepted domains include contoso.com, sales.contoso.com and fabrikam.com, with three connectors to the on-premises server: one for all accepted domains, one for contoso.com and one for *.contoso.com. Mail to john@fabrikam.com uses the first, john@contoso.com the second and john@sales.contoso.com the third. Microsoft also advises against AssociatedAcceptedDomains unless you're testing a connector with a subset of domains.

Verify the connectors

• Validate outbound connectors. In the EAC select the connector and choose Validate this connector, or run the cmdlet, which tests SMTP connectivity to each smart host and sends test messages:

Validate-OutboundConnector -Identity "To Fabrikam (forced TLS)" -Recipients test@fabrikam.com

Validate-OutboundConnector doesn't record the result on the connector. If you want the EAC to show it as validated, set it yourself:

Set-OutboundConnector -Identity "To Fabrikam (forced TLS)" -IsValidated $true -LastValidationTimestamp (Get-Date).ToUniversalTime()

• Check that it's turned on. In the EAC, a connector with Status Off does nothing; use Edit name or status and select Turn it on.
• Test inbound connectors with real mail. Ask the partner or gateway to send a message and confirm delivery with message trace. When Enhanced Filtering is enabled, the message header X-MS-Exchange-SkipListedInternetSender shows the true source address.

When you edit a connector, Microsoft 365 keeps using the old settings until you save the change.

Troubleshooting connector problems

To check which certificate your Exchange Server presents to Exchange Online, enable protocol logging on the send connector and read the log path:

(Get-SendConnector "outbound to Microsoft 365").SourceTransportServers | foreach {Get-TransportService $_.name} | Select-Object name,SendProtocolLogPath

Checklist

• List existing connectors and leave HCW-created ones alone.
• Use Partner connectors for external organizations and gateways, OnPremises for your own servers.
• Outbound to partners: TlsSettings DomainValidation with the right TlsDomain.
• Inbound from partners: restrict by IP (IPv4, /24 to /32) or certificate, never both in one connector.
• Behind a gateway: a Partner connector with SenderDomains * plus Enhanced Filtering.
• Validate outbound connectors and turn every connector on.
• After certificate renewals, update TlsSenderCertificateName before mail starts bouncing with 5.7.64.

References

• Configure mail flow using connectors in Exchange Online
• Set up connectors for secure mail flow with a partner organization
• Set up a connector to apply security restrictions to mail sent to your partner organization
• Set up a connector to apply security restrictions to mail sent from your partner organization
• Examples of connector configurations for securing email with a partner organization
• Set up connectors to route mail between Microsoft 365 and your own email servers
• Manage mail flow using a third-party cloud service with Exchange Online
• Enhanced filtering for connectors in Exchange Online
• Validate connectors in Exchange Online
• 550 5.7.64 TenantAttribution when users send mails externally
• NDR error 550 5.7.64 TenantAttribution when sending emails through Microsoft 365
• New-InboundConnector
• New-OutboundConnector
• Set-OutboundConnector
• Get-InboundConnector
• Validate-OutboundConnector