Mail Relay in Exchange Server 2016

Introduction

In my previous series here at MSExchange.org we went through several steps to configure relay in Exchange Server 2013 using different network adapters and creating receive connectors. In this article we will keep it simple and configure the relay on the new Exchange Server 2016 in just a few steps.

Exchange Server 2016 was released at the end of 2015 and it has a simpler architecture than previous versions where the product has only two roles: Mailbox Server and Edge Server. The Mailbox Role is the role that stays inside of the network and it provides transport, mailbox and client access services capabilities (all those components used to be roles in previous versions of Exchange Server).

By default, any Exchange Server 2016 is able to receive e-mails on all accepted domains configured at the organization level. That means that in theory we can configure a Firewall to publish the Public IP on 25 (TCP) port to the internal Exchange Server 2016 and the Internet mail flow will work just fine. By default, like all other previous versions, any new deployment of Exchange Server is secure out of the box and there is no risk of open relays using default settings.

Although it is possible to move all Internet traffic to the Exchange Server box, the recommendation is to subscribe to a Cloud Service, such as EOP (Exchange Online Protection) to perform all hygiene on the Internet and then move all the valid mail traffic to your on-premises environment, or an Edge Server/Antispam solution located at the DMZ.

Checking the built-in relay capabilities in Exchange Server 2016…

We can check the accepted domains using either Exchange Management Console or Exchange Admin Center (ECP). In the ECP, click on Mail flow, and then on Accepted domains (Figure 01); if you want to get the same information using Exchange Management Shell, you can use the following cmdlet (PowerShell on Figure 01)

Get-AcceptedDomains

Figure 01

By default, any Exchange Server 2016 will have several connectors and based on the transport pipeline of the product (more details can be seen on this Microsoft article). The Receive Connector that we will be looking into is the Default Frontend <ServerName>, and in order to get there click on mail flow and then Receive Connectors, make sure to select the server from the Select Server list (Figure 02).

Figure 02

Let’s test that connector, we will create a fake message from a bogus domain to our administrator account that exists on the Exchange Server organization (domain apatricio.local), and see if that message goes through.

The preferable method to test is using telnet utility to connect to the Exchange Server on the 25 port. The entire process is described below and shown in Figure 03. We are using just a couple of commands to test the mail flow. This Microsoft KB explains the entire process.

Note:
If you are using Windows 10/Windows Server 2012 R2 you won’t have Telnet client available out of the box. In order to install it open the PowerShell as administrator and run the following cmdlet: Add-WindowsFeature telnet-client.

telnet <servername> 25

Ehlo domain.ca <enter>

Mail from: [email protected] <enter>

Rcpt to:[email protected] <enter>

Data<enter>

<enter>

<enter>

Subject: Test #01 <enter>

This is a test message <enter>

. <enter>

Figure 03

On the end-user side we can check and the result is a new message, as shown in Figure 04.

Figure 04

That is great, we tested and validated the mail flow on the default receive connector. However, if we try to do the same thing using an external e-mail address we will get an error. In Figure 05, we are trying to send a message to a remote domain (Patricio.ca for example, which is a valid domain on the Internet), the error message that we get is 550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain.

Figure 05

From the security perspective that is really good, nobody will be able to use our Exchange Server 2016 to relay messages to other domains that we haven’t configured in our Exchange Organization, however for an internal service/application that needs to relay messages to external users, that is not good and we need to allow them to do that.

Creating a Receive Connector to allow relay to external addresses…

The most important thing here is to understand how Exchange works. We know for a fact that any attempt to relay to a valid accepted domain will work, so we are good for internal flow. That may be enough for the vast majority of applications including network devices (scanners, fax machines, and etc.).

In order to allow external relay, we need to create a receive connector. Logged on Exchange Admin Center (ECP), click on Mail flow, Receive Connectors and click on New.

In the new page (Figure 06), label the new receive connector and select Frontend Transport, and select Custom, and click Next.

Figure 06

We can bound a receive connector to a specific adapter and/or port (Figure 07). In this case we will leave default settings which is listening on all IPs of the server and on the traditional 25 port. Click on Next.

Note:
Keep in mind that a unique set of IP Address/Port/Remote IP addresses is required for each Receive Connector. At the beginning of this article we pointed out that the server has already several Receive Connectors and by default they are always listening on all available IPv4 and in some specific ports.

Figure 07

So far in this new receive connector, we have configured values that are already in place (Listening IP and port). The only way to escape an error when completing this wizard is to define the Remote network settings page with the IPs of the internal servers that will be able to relay messages to the outside world (Figure 08).

Note:
That was the reason why we selected Custom at beginning of the wizard, because this page is displayed when that option is used. By doing that we make this Receive Connector unique and we can safely click on Finish.

Figure 08

Before releasing to production/test, we need to work on two details on this newly created Receive Connector: Security and AD permissions.

The security can be done using Exchange Admin Center. Double click on the new receive connector, click Security, and we can start simple by selecting Anonymous users where we say that the relay will be open (not yet) without authentication. It is not the best practice or ideal but can be used in some controlled scenarios (Figure 09).

Figure 09

The next step is to configure a specific permission at the Receive Connector level. If we run the Get-ReceiveConnector we will get a full list of all Receive Connectors, however we want to isolate the connector which we will apply the relay permission, and for we need to use <server-Name>\<Receive-Connector-Name> after the cmdlet, as shown in Figure 10 and listed below.

Get-ReceiveConnector

Get-ReceiveConnector mtlex01\relay

Figure 10

Having isolated the Receive Connector, we can apply the Active Directory Permission and we can use the following cmdlet (Figure 11).

Get-ReceiveConnector <server>\<ReceiveConnectorName> | Add-ADPermission –User “NT Authority\Anonymous Logon” –ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”

Figure 11

External relay test…

Now that we tested the internal relay, and created a Receive Connector to handle External Relay, we can start testing the process. We will perform a similar telnet test trying to send a message to an external e-mail, and at this time the Exchange Server will not refuse our connection but will let us to go through, as shown in Figure 12.

Figure 12

Conclusion

In this article we went through the steps to configure an internal and external relay connector in Exchange Server 2016.