Configure Exchange 2013 to Send External Email

Originally published 26 April 2013 / Filed under Exchange Server

Archived note. Originally published 26 April 2013 on iishacks.com. It describes Exchange Server 2013 configured through the browser-based Exchange admin centre at /ecp, as that product behaved at that time, and is preserved here as a record. Exchange Server 2013 has since reached end of support and the administrative interfaces have changed again in the releases that followed. Verify against current vendor documentation before applying any of it to a live system.

This was the last post published on iishacks.com. The site ran from May 2007 to October 2013; this note from April 2013 is the final entry in the original blog's own category listing for Exchange Server, and the archive ends a few months after it.

So Exchange 2013 is installed and mail will not reach other domains. Similar to Exchange 2010, Exchange 2013 is installed without a default send connector enabled. To send mail to other Exchange servers or to external domains, one has to be set up. The steps below create a send connector that enables mail to all external domains.

The procedure

1. Log in to the Exchange admin centre at https://FQDN/ecp — or against localhost or the IP address — internally, or using the external address or domain name from outside. As a security matter, the default administrator account should not be the one used in production.
2. Go to Mail Flow and then Send Connectors. Click the + button to add a new external send connector.
3. Give it a name, such as External Email Connector, and select Type: Internet. Click Next.
4. Select MX record associated with recipient domain for sending mail, unless the ISP or host requires the use of smart hosts. Click Next.
5. Click the + button to add a new address space.
6. Under Type enter SMTP, under Cost enter 1, and under FQDN enter *. This ensures mail can be sent to all internet domains. To restrict which domains mail may be sent to, create a new address space for each domain instead, putting the domain name in the FQDN field. This is a useful feature for organisations that require high security and control over outbound mail — government, financial and insurance environments in particular. Click Next.
7. Click Next.
8. Click the + button to add a new source server. On a single-server organisation this will be the current transport server.
9. All Exchange servers in the organisation are listed. Highlight the one to be used for transport and click Add. Click OK.
10. Click Finish.
11. The FQDN for the server sending external mail still has to be set. Highlight the External Email Connector just created and click the Edit button above it.
12. Click Scoping, scroll to the bottom, and enter the FQDN of the server. This will usually be domainname.com or will match the MX record, for example email.domainname.com. Click Save. This is an important step: it decreases the likelihood of the organisation's mail being flagged as spam, by identifying the server properly to the servers it connects to.

Exchange 2013 is then set up to send external mail correctly.

What changed between 2010 and 2013

The decisions are identical to those in the Exchange 2010 procedure — a name and usage, a routing method, an address space, a source server, and the announced FQDN. Everything that differs is the surface they are made through.

The Exchange Management Console, the Windows application that had carried Exchange administration for years, was gone. Its replacement was the Exchange admin centre, served by the server itself at /ecp and reached with a browser. That was a genuine change in working practice rather than a reskin: administration no longer required a management workstation with the correct console version installed, it worked from outside the network over the same published path as the web client, and it meant the administrative interface was now something with a login page exposed on the network. The advice in step one about not using the default administrator account belongs to that change.

The server roles were consolidated at the same time. Where 2010 distributed work across Hub Transport, Client Access, Mailbox and Unified Messaging roles, 2013 collapsed the design into a much smaller number of roles carrying the same functions. In this procedure that consolidation shows up quietly: the connector is created under Mail Flow at the organisation level rather than under a Hub Transport node, and the source server list on a single-server organisation contains the one server that does everything.

One field appears in 2013 that had no direct equivalent in the 2010 wizard, and it is worth understanding rather than typing past.

The Cost field

Cost is a routing preference. Where two connectors could both handle a recipient domain, the one with the lower cost is selected. A value of 1 on a single outbound connector means nothing on its own — it becomes meaningful the moment a second connector exists.

The usual arrangement is a primary path and a fallback: the same address space configured on two connectors, one routing by MX at low cost and one through a relay at higher cost, so that traffic uses the preferred path and moves to the alternative when it is unavailable. It also gives a way to prefer a particular route for a particular partner domain without disturbing everything else. Cost is set once and then forgotten for years, which is exactly why it is worth recording what the number was chosen to mean.

Restricting the address space is a real control

Entering * makes the connector responsible for every external domain. Creating one address space per permitted domain instead produces an outbound allow-list: mail to a domain with no matching address space has no route and is not delivered.

In a regulated environment that is not a cosmetic setting. The restriction is enforced by the transport service, below the level of mailbox rules, client configuration or an application's own mail settings, so it cannot be bypassed by a user or by a misconfigured line-of-business system that happens to have SMTP credentials. It survives a mailbox being moved and an Outlook profile being rebuilt. Where an organisation has to be able to state which external parties it can correspond with, this is where that statement is actually made and where an auditor can read it back.

The cost of it is operational rather than technical: every new correspondent becomes a change request, and a missing address space produces a delivery failure that looks like a fault rather than a policy. That trade is the reason the wildcard is the default choice everywhere the control is not required.

The announced name, again

Step twelve does the same job as the final step of the 2010 procedure, in a different place in the interface. The FQDN entered under Scoping is the name the server announces when it opens an SMTP conversation with a receiving server. It should resolve forward to the address the connection actually originates from, that address should resolve back to the same name, and it should be authorised to send for the sending domain under that domain's SPF record, as defined in RFC 7208. Skipping it leaves the server announcing an internal name that means nothing to anyone outside, which is one of the cheapest ways to have legitimate mail filtered.

More mail-server material from the archive is collected under the Exchange Server category, the complete chronological index of all 138 original posts is at post archives, and the scope of the archive is described on the front page. For a supported release, work from the Exchange Server documentation and check support dates on the Microsoft product lifecycle pages.