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

Exchange send connectors route by recipient domain, not sender — how to route outbound mail by sender address anyway

An Exchange Server send connector is selected by the recipient’s domain (its address space) and cost, never by who sent the message; to send different sender domains through different smart hosts on-premises you need either separate Active Directory sites with scoped connectors, a transport agent, or an SMTP relay in front of Exchange that routes by sender. This guide explains how connector selection works, why the obvious workarounds fail, and what the three real options cost you in complexity.

Updated on 2026-09-16

The question, and the short answer

The setup is common: one Exchange Server hosts company-a.com and company-b.com, or a corporate domain plus a few addresses at a hosted provider. Each domain has its own provider relay with its own login, and each provider only accepts mail from the addresses that belong to that login. So the administrator creates two send connectors, one per smart host, and expects Exchange to use the right one for each sender. It does not, and no setting on the connector changes that. Microsoft’s own documentation lists what a send connector is selected by, and the sender is not on the list.

How Exchange chooses a send connector

According to Microsoft Learn, the send connector used to route a message to a recipient is selected during the routing resolution phase of message categorization, and the settings that matter are these (Send connectors in Exchange Server, Mail routing in Exchange Server):

Setting	What it does	Depends on the sender?
Address spaces	The destination domains the connector is responsible for, for example * for every domain or *.contoso.com. A message is matched to the connector with the most specific address space for its recipient.	No
Cost	Breaks ties between connectors with the same address space: the connector with the lower cost value is preferred.	No
Scope	A scoped connector is visible only to Exchange servers in its own Active Directory site; unscoped connectors are visible to the whole forest.	No (depends on the sending server’s site)
Source servers	Which Exchange servers may deliver through the connector.	No
Network settings	DNS delivery or one or more smart hosts, plus the authentication for the smart host.	No
Message size limit	Connectors whose limit is smaller than the message are skipped.	No

Every input to the decision describes the destination, the topology or the message size. The sender address, the sender’s domain, the mailbox database or the department are not evaluated. That is not an oversight in a particular version: the logic is, in Microsoft’s words, basically unchanged since Exchange 2010, and it applies to Exchange 2013, 2016, 2019 and Exchange Server SE alike.

Why the obvious attempts fail

• Two connectors with the address space * and different smart hosts. Both claim every destination. Exchange resolves the tie with the cost value, and nothing in the tie-break looks at the sender. Mail from every sender goes to whichever connector wins, or to both, and the provider that expects only its own domains answers with a sender or authentication error such as 530 SMTP authentication is required or a rejection of the sender address.
• An address space per sender domain. The address space is the recipient domain. An entry company-b.com makes the connector responsible for mail to company-b.com, which is your own accepted domain and is delivered internally anyway. There is no field for the sending domain.
• A mail flow (transport) rule. Rules can redirect, modify, copy or reject a message and can add recipients, but they run in a different stage and cannot name a connector or a smart host. This is exactly what the Exchange Online outbound connector can do with its rule condition, and what the on-premises product cannot.
• A second Exchange server per domain. Only helps if the servers are in different Active Directory sites (see the first option below); two servers in one site share the same routing decision.

The three ways that actually work

Option	How it works	What it costs you
Separate Active Directory sites with scoped connectors	Each sender domain gets its own AD site with its own Exchange server and a scoped send connector for that provider. Because a scoped connector is only visible inside its site, mail submitted on that server can only leave through it.	One Exchange server and mailbox database per domain, AD site links to maintain, and users of a domain must live on that server. Supported by Microsoft, but heavy for the two-domains case.
Custom transport agent	A routing agent written against the Exchange transport SDK inspects the sender and overrides the routing destination before categorization ends.	Code you write and maintain yourself, re-tested after every Cumulative Update, and running inside the transport pipeline where a bug stops all mail.
Sender-routing relay in front of Exchange	Exchange keeps one send connector, which forwards everything to a local relay service. The relay matches the sender address against its rules and delivers through the provider relay with the credentials that belong to that sender.	One service to install and configure. Exchange itself stays unmodified; the routing rules live in the relay, and the Exchange queue viewer still shows the mail leaving.

The first two options are Microsoft mechanisms and are described on the Microsoft Learn pages linked above. The third is what MultiSendcon implements: it installs as a Windows service on the Exchange server, listens as a local smart host (by default on port 2500, because Exchange itself uses port 25 for its receive connectors), and the installer creates the send connector that points Exchange at it. If the installer cannot create the connector, for example because PowerShell remoting is disabled, one command in the Exchange Management Shell does it (knowledge base: create the MultiSendcon send connector manually):

new-sendconnector -name MultiSendcon -Addressspaces "SMTP:*;100" -port 2500 -SmarthostAuthMechanism none -smarthosts 127.0.0.1

The address space * with cost 100 makes it the connector for all Internet mail; change the cost to 1 so it wins over any older connector. From then on Exchange makes exactly one routing decision, and the sender-dependent part happens in the relay.

What the relay decides per sender

Inside MultiSendcon each provider relay is an SMTP account with a sender mask: *@company-a.com for a whole domain, user@company-b.com for a single address, or a wildcard pattern. Each account carries its own relay server, port (25, 587 or 465), login and TLS settings, and optionally a recipient filter and a local IP address to send from. The first matching rule in list order wins, so a specific address can sit above its domain rule, and two accounts with the same mask form a primary/fallback pair. Senders that match no rule fall through to the Master Relay configuration, or can be handed back to Exchange’s own send connectors. A fixed-sender option replaces the outgoing address where a provider only accepts the authenticated account’s address, and it also fills in the empty envelope sender that Exchange uses for non-delivery reports and out-of-office replies, which some providers now reject (knowledge base: IONOS blocks NDRs and out-of-office messages).

The same mechanism covers the related cases: several companies on one server, a corporate domain mixed with Google Workspace addresses, bulk mail on a separate IP for reputation reasons, or a destination that needs its own relay (recipient-dependent routing). Exchange 2003 through 2019 and Exchange Server SE are supported; the connector framework is the standard send connector, no transport agent or pipeline plug-in is installed.

Exchange Online is different

If your mailboxes are in Exchange Online, you do not need any of this: an outbound connector there can be set to be used only when a transport rule redirects messages to it, and the rule can match on the sender, so “route mail from these senders through this smart host” is a native configuration (Conditional mail routing in Exchange Online). This guide is about Exchange Server on-premises, where that option does not exist.

Next steps

• Two domains, two providers: install the MultiSendcon 30-day trial, let the installer create the send connector, add one SMTP account per provider with its sender mask, and send a test from each domain.
• Only one provider but several logins: the same setup with one account per login.
• One provider, one login, but the empty-sender rejections: the LITE edition included in the download replaces the empty sender and is enough for that case.

Frequently asked questions

More on outbound mail flow in the Exchange mail flow guides, or in the knowledge base. Auf Deutsch: Exchange-Sendeconnectoren routen nach Empfängerdomäne, nicht nach Absender.