Exchange mail flow guides › Outbound: send connectors and smart hosts

Exchange: “A matching connector cannot be found to route the external recipient” — causes and fix

Exchange Server puts a message into the Unreachable queue with the last error “A matching connector cannot be found to route the external recipient” when no enabled send connector that is visible from the sending server’s Active Directory site has an address space covering the recipient’s domain. The usual causes are a connector without the address space *, a disabled connector, a scoped connector in another site, or an address space that does not match the way you expected. Nothing is wrong with the message or the recipient; the routing table simply has no exit for that domain.

Updated on 2026-09-19

What the error means

For every external recipient Exchange has to pick one send connector. Microsoft documents the procedure in Connector selection in external message routing (applies to Exchange 2016, 2019 and Subscription Edition). Exchange first removes connectors whose message size limit is smaller than the message, then keeps only the connectors that meet all three of these conditions:

• the connector is enabled,
• the connector is not scoped, or it is scoped to the local Active Directory site,
• the connector has an address space that matches the recipient’s e-mail address.

If that list is empty, Microsoft’s wording is: “If there is no matching connector for an SMTP address space, the recipient is marked as unreachable and the message is routed to the Unreachable queue.” The message stays there; the sender gets no bounce at this point. The queues documentation describes the Unreachable queue as the place for messages that cannot be routed to their destinations and adds that this is typically caused by configuration changes that modified the routing path. That matches practice: the error almost always appears right after somebody created, deleted, disabled or re-scoped a send connector.

The causes, and how to recognise each

Cause	How it shows	Fix
No connector with the address space *	Mail to a few domains leaves, everything else is stuck. The connectors list only specific domains.	Add one connector with the address space * for all other Internet mail, or add * to an existing connector. The more specific connectors still win for their domains.
The connector is disabled	Enabled is False. Only enabled connectors are used in routing decisions, so a disabled connector is the same as none.	Set-SendConnector "Name" -Enabled $true, or enable the connector in the EAC under Mail flow → Send connectors.
A scoped connector in another Active Directory site	IsScopedConnector is True and the source servers are in a different site from the server that holds the message. A scoped connector is invisible to Exchange servers in other sites and is not used in their routing decisions.	Remove the scope (EAC: the Scoping tab of the connector; shell: -IsScopedConnector $false) or create a connector that the affected site can see.
The address space does not match the recipient domain	contoso.com covers that domain without subdomains, so mail to user@mail.contoso.com has no match; only *.contoso.com covers the domain and all subdomains. The documented forms are *, a domain, and *.domain. An address space is a destination domain, not an e-mail address.	Correct the address space to one of the three documented forms.
No usable source server	Microsoft requires at least one Mailbox server or Edge Transport server to host the connector. After a migration the only source server listed may be one that has been removed.	Add a current Mailbox server on the connector’s Scoping tab, or with -SourceTransportServers.

The syntax and the scoping rule are in Send connectors in Exchange Server. Two things that look like candidates are not: a message size limit on the connector leads to a non-delivery report when the message is too large for every connector, not to this error; and the cost value only decides between connectors that already match, so a high cost never makes a connector unavailable.

Check it in the Exchange Management Shell

One command shows every setting that takes part in the decision (Get-SendConnector):

Get-SendConnector | Format-List Name,Enabled,AddressSpaces,IsScopedConnector,SourceTransportServers,MaxMessageSize

Read the output against the recipient domain of a stuck message. Is there an enabled connector whose AddressSpaces contains * or the recipient’s domain? Is it unscoped, or are its source servers in the same site as the server where the message waits? Then look at the queue itself:

Get-Queue -Identity Mailbox01\Unreachable | Format-List Identity,Status,MessageCount,LastError
Get-Message -Queue Mailbox01\Unreachable | Format-Table FromAddress,Subject,LastError

Replace Mailbox01 with your server name. The recipient domains of the waiting messages tell you which address space is missing. If all external mail is stuck, look for the * connector; if one domain is stuck, look for a connector that claims that domain and is disabled, scoped elsewhere or written without the subdomain wildcard.

When a second connector interferes

The most confusing case is a connector that should not be involved at all. Exchange prefers the most specific address space: for julia@marketing.contoso.com Microsoft gives the order marketing.contoso.com, then *.contoso.com, then *. But a connector only takes part in that comparison if it passed the three conditions above. A specific connector that is disabled or scoped to another site therefore does not win and then fail; it is simply ignored, and the mail falls through to the * connector if one exists. If no * connector exists, the domain is unreachable. The reverse also happens: an old test connector with a specific address space that is enabled takes the mail for that domain away from your main connector and sends it to a smart host that no longer accepts it. That produces a delivery queue in Retry, not the Unreachable queue, and it is worth telling the two apart before changing anything. When you are not sure which connector Exchange uses, disable the suspects one at a time and watch which queue the next test message enters.

After the fix: getting the waiting mail out

Exchange resubmits the Unreachable queue to the categorizer by itself when it detects a configuration update, unless the queue has been suspended. If the messages are still waiting a few minutes after your change, resubmit them. Microsoft’s queue procedures state that Queue Viewer cannot resubmit a queue and give this command for exactly this case:

Retry-Queue -Identity Mailbox01\Unreachable -Resubmit $true

Resubmitting sends the messages back to the Submission queue, so the categorizer makes a fresh routing decision with the corrected connectors. Messages with the status Suspended are not resubmitted; resume them first.

The same error with a relay such as MultiSendcon

Setups that route outbound mail by sender through a local relay reduce Exchange to a single send connector, which makes this error easy to cause and easy to fix. MultiSendcon receives all outgoing mail from Exchange on 127.0.0.1, port 2500, through one connector with the address space SMTP:*, and chooses the provider relay per sender itself. The installer creates that connector disabled and with cost 100, so that mail keeps leaving through the existing connector while you enter the relay accounts (installation guide). Two mistakes lead straight to the Unreachable queue:

• The old connector is deleted or disabled before the MultiSendcon connector has been enabled. No enabled connector is left, and every external recipient is unreachable. Enable the connector and set the cost to 1.
• The connector was never created, for example because PowerShell remoting was switched off during setup. Create it by hand with the command from the knowledge base article How to manually create the MultiSendcon send connector, then set the cost to 1.

A cost of 100 on its own does not cause the error: as long as the connector is enabled and is the only one with *, Exchange uses it. The cost matters when an older * connector is still enabled beside it; then the lower cost wins, which is why the guide tells you to change 100 to 1. How several connectors and several smart hosts work together is described in Multiple smart hosts in Exchange 2016/2019, and why Exchange cannot choose a connector by sender in Exchange send connectors route by recipient domain, not sender. MultiSendcon can be tried for 30 days from the download page.

Frequently asked questions

More on outbound mail flow in the Exchange mail flow guides, or in the knowledge base. Auf Deutsch: Exchange: „A matching connector cannot be found“ – Ursachen und Lösung.