Configure Exchange 2010 to Send External Emails
Archived note. Originally published 11 August 2010 on iishacks.com. It describes Exchange Server 2010 with the Hub Transport role, configured through the Exchange Management Console, as that product behaved at that time, and is preserved here as a record. Exchange Server 2010 has reached end of support, and the Exchange Management Console described below was replaced in later versions by the browser-based Exchange admin centre. Verify against current vendor documentation before applying any of it to a live system.
So mail will not leave a fresh installation of Exchange 2010? Unlike Exchange 2003, Exchange 2010 cannot send email to external domains out of the box. The capability has to be enabled by creating an external send connector. By default no send connectors are configured when an Exchange 2010 system is set up with a Hub Transport or Edge Transport role — the typical installation.
At first sight it seems odd for a mail server to refuse external delivery by default. The reasoning is clearer in the environments the product was sold into: in insurance and financial institutions complete control over external communication is a requirement, and a server that could reach the internet the moment it was installed would be the wrong default. Making outbound routing explicit, named and auditable is the safer starting position.
What a send connector is
Exchange separates inbound and outbound SMTP into distinct objects. Receive connectors are created automatically, because a transport server that cannot accept mail is useless from the first minute. Send connectors are not, because where mail should go is a policy question only the organisation can answer.
A send connector is defined by four things: an address space naming which recipient domains it is responsible for, a routing method saying how to reach them, one or more source servers saying which transport servers may use it, and the name the connector announces itself under. The procedure below sets all four.
The procedure
- Open the Exchange Management Console. Expand Organization Configuration and select Hub Transport. Move to the Send Connectors tab. Either right-click the empty space or choose New Send Connector from the Actions list.
- Enter a name for the send connector. Under intended use, select Internet in order to send to external domains. Click Next.
- Under Address Space click Add… and select SMTP Address Space… Click Next.
- Under SMTP Address Space, in the Address field, enter
*in order to send to all external domains. This is where the address space may instead be customised, allowing external mail only to specific vendors or customers. Click OK, then Next. - If a smart host is used to route mail — sometimes required by an ISP — configure it here. Otherwise select Use domain name system (DNS) MX records to route mail automatically, which is the typical choice. Click Next.
- For a single-server installation of Exchange 2010 the source server will be the only one in the list. Where several servers carry the Hub Transport role in the organisation, a specific server can be selected here. Click Next.
- A summary page of the send connector is displayed. Click Next.
- Once the connector has been configured, a completion page appears. The syntax shown on it is the shell equivalent of what the wizard just ran, which is worth reading and keeping. Click Finish.
- One item still has to be set. Right-click the new connector and select Properties.
- To get past some of the stricter spam filters, set the Fully Qualified Domain Name (FQDN). This is typically the internet-facing name of the mail server. Click OK.
The server can then send mail to external domains.
The address space, and what the asterisk means
An address space of * tells the transport service that this connector is responsible for every recipient domain that is not handled internally. It is the broadest possible statement and it is what most organisations want.
The alternative is the reason the field exists. Entering example.com instead creates a connector responsible for that domain alone; mail to anywhere else has no matching connector and is not delivered. Building an outbound configuration from named domains rather than a wildcard turns the mail system into an enforced allow-list — precisely the control the regulated environments mentioned above are after, and a real one, because it is applied by the transport service rather than by a rule a user or an application might route around.
Where more than one connector could match a recipient domain, the more specific address space wins, so a wildcard connector and a narrower one for a single partner domain can coexist with the partner traffic routed over its own path.
MX routing against a smart host
Selecting DNS routing makes the transport server do its own delivery: for each recipient domain it resolves the MX records, connects to the published hosts in preference order, and delivers the message itself. Nothing sits between the organisation and the receiving server.
A smart host reverses that: the transport server hands everything to one nominated relay and lets it perform the lookups and the delivery. This was routinely required rather than chosen. Many providers blocked outbound port 25 from their address ranges, ranges assigned to consumer and small-business connections were widely listed as ineligible to send mail directly, and a provider-operated relay was the only path receiving servers would accept. Filtering and archiving appliances were the other common reason to insert one.
The practical difference is where delivery failures surface. With DNS routing a rejection comes back from the recipient's own server and names the real reason; behind a smart host the relay's response is what is logged, and the underlying rejection may never be visible from inside the organisation.
Why the connector FQDN matters
Step ten looks cosmetic and is not. The FQDN configured on the connector is the name the transport server announces in the HELO or EHLO greeting at the start of every outbound SMTP conversation. It is the first thing the receiving server learns, and it is checked.
Three things should line up: the announced name should resolve forward to the address the connection actually comes from, the reverse lookup on that address should return the same name, and the address should be authorised for the sending domain in its published SPF record — the mechanism defined in RFC 7208. Left unset, the connector announces the server's internal name, which resolves to nothing outside the organisation and looks to a receiving filter exactly like a compromised host. That one mismatch was among the most common causes of an otherwise correct server being scored as spam.
The shell equivalent
The completion page in step eight exists because everything the wizard does is a shell command underneath, and the shell form is what belongs in a build document or a rebuild script. The connector is created and then amended with the announced name, in roughly this shape:
New-SendConnector -Name "Internet" -Usage Internet -AddressSpaces "*" -DNSRoutingEnabled $true -SourceTransportServers HUB01
Set-SendConnector -Identity "Internet" -Fqdn mail.example.comCapturing that text records exactly what was configured, in a form that can be reviewed, compared against another server and replayed during a rebuild.
Related material
The equivalent procedure for the next release is documented in the note on configuring Exchange 2013 to send external email, where the same four decisions are made through the browser-based admin centre instead of the management console. Other mail-server notes from the archive are collected under the Exchange Server category, and the full chronological index is at post archives; the archive itself is described on the front page. For anything being built today, start from the Exchange Server documentation and confirm support dates against the Microsoft product lifecycle.