Home » Exchange Server » How to Configure Exchange Server 2016 for SMTP Application Relay

How to Configure Exchange Server 2016 for SMTP Application Relay

In most organizations there are several devices or applications that need to use an SMTP service to send email messages. An Exchange 2016 server can provide that service for you, however the configuration required on the server depends on the SMTP relay requirements of your scenario.

The steps for how to configure Exchange Server 2016 SMTP relay are:

  1. Determine whether your scenario is internal relay or external relay
  2. Determine whether devices and applications will authenticate or connect anonymously
  3. For authenticated relay, configure the TLS certificate for the client front end connector
  4. For anonymous relay, configure a new receive connector that is restricted to specific remote IP addresses

Determining Internal vs External Relay Scenarios

There are generally two types of SMTP relay scenarios that Exchange Server 2016 is used for:

  • Internal relay – devices and applications that need to send email messages only to internal recipients in the Exchange organization.
  • External relay – devices and applications that need to send email messages to external recipients.

exchange-2016-smtp-relay-01

Let’s take a look at each of those scenarios, and then some additional considerations when you are deploying this in your own production environments.

Internal SMTP Relay with Exchange Server 2016

When Exchange Server 2016 is first installed the setup routine automatically creates a receive connector that is pre-configured to be used for receiving email messages from anonymous senders to internal recipients. This allows inbound internet email to be received by the server, and is also suitable for internal relay scenarios.

The receive connector is named “SERVERNAMEDefault Frontend SERVERNAME”, for example, “EXSERVERDefault Frontend EXSERVER” in my test environment.

You can test this connector by making an SMTP connection using Telnet and issuing SMTP commands. For example:

So there’s no specific configuration required on the server or the connectors to allow this scenario, however it is recommended that you use a DNS alias instead of the real server name. This will allow you to configure all of your devices and applications with the DNS alias, and you can later move that DNS alias to point to a different Exchange server during a migration.

External SMTP Relay with Exchange Server 2016

Continuing from the previous demonstration, let’s see what happens if I try to use Telnet to send an email message from a valid internal address to an external recipient.

An SMTP error code “550 5.7.54, Unable to relay recipient in non-accepted domain” is received instead. The receive connector will not allow an anonymous, unauthenticated sender to relay to external domain names, which prevents your server from being exploited as an open relay.

There are two ways you can resolve this and allow your devices and applications to send to external recipients:

  • Using authentication for SMTP connections
  • Configuring an anonymous SMTP relay connector

External SMTP Relay with Exchange Server 2016 Using Authentication

The first method is to use authenticated SMTP connections. Exchange Server 2016 has a receive connector designed to be used by clients that need to send via SMTP called “SERVERNAMEClient Frontend SERVERNAME”, for example “EXSERVERClient Frontend EXSERVER” in my test environment.

Minimal configuration is required to get this working. Assuming you’ve already configured an SSL certificate for Exchange Server 2016, and added a DNS alias for your SMTP devices and applications to use (I’m using a DNS alias of mail.exchange2016demo.com in this example), you should then also set the TlsCertificateName for the receive connector.

Use Get-ExchangeCertificate to identify the thumbprint of the SSL certificate you’ll be using.

The syntax of the TlsCertificateName string is made up of two different attributes of the certificate, so I use the following commands to apply the configuration to my receive connector.

To test using the Client Frontend connector to send an email message I’m going to use PowerShell’s Send-MailMessage cmdlet instead of Telnet. First, capture some valid credentials to use for authentication.

Next, use the Send-MailMessage cmdlet with parameters specifying the server, to and from addresses, subject line, and the port number.

In the above example the email is successfully received by the external recipient. So any device or application on the network that can use authenticated SMTP can be set up to use that connector listening on port 587 on your Exchange 2016 server.

External SMTP Relay with Exchange Server 2016 Using Anonymous Connections

When authenticated SMTP is not an option you can create a new receive connector on the Exchange 2016 server that will allow anonymous SMTP relay from a specific list of IP addresses or IP ranges.

In the Exchange Admin Center navigate to mail flow and then receive connectors. Select the server that you want to create the new receive connector on, and click the “+” button to start the wizard.

exchange-2016-smtp-relay-02

Give the new connector a name. I like to keep the name consistent with the other default connectors. Set the Role to “Frontend Transport”, and the Type to “Custom”.

exchange-2016-smtp-relay-03

The default Network adapter bindings are fine. This represents the IP and port that the server will be listening on for connections. Multiple receive connectors on the Frontend Transport service can listen on the same port of TCP 25.

exchange-2016-smtp-relay-04

Remove the default IP range from the Remote network settings, and then add in the specific IP addresses or IP ranges that you want to allow anonymous SMTP relay from. I do not recommend adding entire IP subnets that contain other Exchange servers as this can cause issues with server to server communications.

exchange-2016-smtp-relay-05

Click Finish to complete the wizard, then there is some additional configuration still required.

In the Exchange Management Shell run the following two commands.

We can now test the connector using Telnet from the IP address that was added to the remote network settings of the receive connector. In my test environment that IP address will now be allowed to send email from any email address (whether it is a valid internal address or not) to any external address.

Additional Considerations

Here’s some additional items that you should consider when you’re providing SMTP relay services with Exchange Server 2016 for your environment.

High Availability and Load Balancing

If you want to provide a highly available SMTP service then a load balancer is the natural solution. If you plan to load balance you’ll need to ensure that the same receive connectors exist on all of the servers in the load balanced pool. This means creating the same relay connector on multiple servers and managing the same list of permitted IP addresses on those connectors.

However, as you’ll see by reading my article on issues with load balancing SMTP traffic, when a load balancer is source NATing the connections the only IP address that will appear to the Exchange server is that of the load balancer itself, not the source device or application. While this simplifies the receive connector configuration (only the load balancer IP needs to be added as an allowed IP) it opens up a number of concerns:

  • Access control (which IP’s are allowed to send) needs to be applied at the load balancer, or you risk having a wide open anonymous SMTP relay service on your network
  • Depending on the load balancer, health probes to the Exchange servers may not detect all health conditions, resulting in traffic being sent to unhealthy servers (and failing)
  • Connections made via the load balancer are anonymous and in some cases untraceable to the source IP (depending on what logging your load balancer is capable of)

You can read more about these issues here.

If a load balancer is not an option for you and you still want some high availability for SMTP services, then you can consider DNS round robin. However, many devices and applications do not handle DNS round robin as well as Outlook or a web browser would. Some devices, when they attempt a connection to one of several IP addresses available in DNS round robin and that IP address is not responding, will not try other IP addresses that are available and will simply consider the connection attempt failed. So it really depends on how well your devices and applications deal with that situation as to whether DNS round robin will be suitable for your environment.

Security vs Convenience

A lot of organizations simply go with the anonymous relay option and set up a connector that allows wide ranges of IP addresses to relay email anywhere. This is the simplest approach, but clearly not the best in terms of security and auditing. Anonymous relay relies on trusted, identifiable IP addresses. If the IP addresses are in a DHCP pool, are associated with a load balancer (see above), are multi-user (such as terminal servers), or the IP/host itself is compromised in some way, then your ability to trace emails back to the real source is difficult if not impossible.

Although authentication adds some complexity, it may be worth it from security perspective. However it does mean managing credentials for all of your devices and applications. Sharing SMTP credentials across multiple systems might seem like a way to avoid complexity, but it re-introduces the problems associated with anonymous SMTP.

Encryption

In the tutorial above I demonstrated configuring a TLS certificate name for a receive connector and also used TLS/SSL for my testing with Send-MailMessage. If you are going to use authentication for SMTP in your environment, or the SMTP traffic is in any way sensitive, then you should protect it with TLS/SSL encryption.

Multiple Receive Connectors

You may be wondering how the Exchange server is able to differentiate between traffic destined for one receive connector vs another receive connector, when both of them are listening on the same IP address and port number, for example “EXSERVERDefault Frontend EXSERVER” and “EXSERVERAnon Relay EXSERVER”.

The answer is in the Remote network settings of the receive connectors. Exchange will use the receive connector that is the most specific match for the source IP address of the SMTP connection.

In my examples above this means that the default connector with its remote network settings of 0.0.0.0-255.255.255.255 (which is basically “anywhere”) is less specific than the relay connector with its remote network settings of 192.168.0.30. So when an SMTP connection comes from IP 192.168.0.30 to port 25 on the server it will be handled by the relay connector, while everything else connecting to port 25 will be handled by the default connector.

exchange-2016-smtp-relay-06

Troubleshooting

One of the most common issues when troubleshooting receive connector behaviour on an Exchange server is determine which connector is actually handling a given connection. There are two ways to approach this type of troubleshooting.

The first is to set different SMTP banners on each connector. Exchange MVP Jeff Guillet has a PowerShell example that you can run to configure each connector’s SMTP banner with the name of the connector itself, so that when you connect with Telnet you can immediately see which receive connector you’ve connected to.

Now when you use Telnet to connect you will see the connector name in the banner.

The other troubleshooting method is to use protocol logging. In the PowerShell example above the protocol log level for each connector was also set to “Verbose”. You can set this on individual connectors if you need to by running Set-ReceiveConnector.

You can then review the protocol logs to determine what is happening to SMTP connections. I generally recommend you leave protocol logging enabled for receive connectors at all times.

Summary

This article demonstrates how Exchange Server 2016 can be used to provide SMTP relay services to devices and applications on your network. As you can see there are multiple approaches that you can take to achieve this, each being suitable for different scenarios, and each having some pros and cons associated with it.

Internal relay needs are already met with the default configuration of an Exchange 2016, and authenticated SMTP for external relay is also available with minimal setup. When anonymous relay is required an additional receive connector can be easily configured.

I do recommend that you consider your actual requirements and implement the most appropriate solution to meet them, instead of simply configuring an anonymous relay connector for all devices and applications on your network.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server

28 comments

  1. Douglas Plumley says:

    Hi Paul,

    Have you done anything with message throttling in Exchange 2016? One of the biggest challenges we’ve been unable to overcome so far is it seems like throttling doesn’t take place at all on the frontend transport but all frontend transport connections are routed via the two default hub transport receive connectors. If you up the rate limits on the default hub transport receive connectors you up the rate limit for all frontend transport receive connectors and it doesn’t seem like you can scope to IP through the hub transport.

  2. Shimon Adimor says:

    Hi Paul
    I am experiencing delays in sending emails out.
    I found out that our exchange server is identified with it’s internal fqdn and ip…
    This may have happened because of a wrong definition of the send connector, or something else which is not defined correctly.
    The configuration is like this:
    The exchange “farm” has two exchange servers 2016 (DAG), two AD DCs, and a witness server.
    The majority of the users are on an RDS cloud farm, which is in the same subnet and is considered “internal” and users are using Outlook 2013 SP1
    I thought that I could use internal separate to external sending method.
    I assume that I’m lacking some knowledge but I think that part of our problem is that the server is identified by it’s internal ip and fqdn.
    Your help will be appreciated.

  3. Aldis says:

    Hello, Paul!

    I have couple of probably very basic questions as I’m only learning Exchange but they are &%^$ important.
    In other mail servers like Kerio, MDaemon etc you have simple checkbox:
    “User must authenticate in order to send from local domain.”
    But i could not find anything similar to this in Exchange.
    The idea is: Internet->SMTP Frontend transport->…
    Spamers can send mail from: domain_user@mydomain com rcpt_to: domain_user@mydomain.com
    Normally other mail servers would say that if you want to send from internal user to internal user using internet facing smtp you should authenticate.
    In exchange default install you can even send email from non-existent_user@mydomain.com rcpt to: domain_user@mydomain.com

    Question.
    What to do to prevent receiving spam from “local” users? SPF is nice thing of course, but i cannot enforce SPF on all incoming traffic as there are a lot of domains that don’t have SPF defined.

    How to prevent sending from non-existent_domain users to existing domain users?
    Thanks

  4. Aldis says:

    I forgot to mention that i have single server installation and no Edge server.
    Maybe Edge server would do all the things I’m looking for?

  5. Mark Levy says:

    Thank you for this excellent article on relay settings. We are getting ready to migrate from an open source/ postfix based email system to Office 365/Exchange Online, and we’ve got a great number of servers running services that will require internal relay. Since the new Exchange server will be in the cloud, does this mean that I will continue to need having a local relay server on our private network, and I’m wondering how I would set this up on the Exchange server? Would I continue to use our current postfix relay server, or would it be better to set up a local Exchange server for the relay?

    Thanks!

    Mark

  6. TLN says:

    Try to create a new receive connector for anonymous users but unable to select the “Frontend Transport” role, the role pre-selected “Hub Transport” and it’s grayed out.

    Any suggestion?
    Thanks

  7. Ron Steurer says:

    First of all thank you Paul thank you for all of your fantastic articles you write. You just seem to have a way to teach it explain it from others that makes is some much easier to understand so thank you! One item on the above am I not quite 100% sure on is this: Your example to allow anonymous external relay are you adding the exchange server of 192.168.0.30 in the remote network settings page or is that IP the IP of the device you want to be able to relay? I am confused on that part – I guess I was thinking in that screen you enter the IP/IP Range of the devices (printers, scanners, etc.) you want to able to send out to the Internet. Can you clarify more for me please. And also, the two PS commands you have to run after that can you not configure those settings within the ECP under the security settings/properties of that Receive Connector? Thank you Paul

  8. sonam wangyal says:

    Hi Paul.

    Thank you for the excellent article.

    I have configured both authenticated and anonymous relay. Authenticated relay fails with error ” 5.7.60 SMT, client does not have permissions to send as this sender. Not sure what I am missing from your steps. Your advice to for troubleshotting steps is highly appreciated.

    Thank you
    Sonam

    • Sounds like you’re trying to send as an address that the account doesn’t have permissions to send as. If you’re using authenticated SMTP, the credentials you use either need to own the mailbox that has that From email address, or have permissions to send as the user it is impersonating.

  9. Joanne Blomert says:

    Hi Paul,

    Your article is excellent. We recently deployed our Exchange 2016 server and copied the External Mail Relay connector from the old Exchange 2013 server. The settings are exactly the same “anonymous users, port 1501, IP address of the server we allow relay from” but relay continues to fail on 2016 server with 550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain. Is there anything else you can suggest we try for troubleshooting this problem?

  10. “Unable to relay recipient in non-accepted domain”

    Well that’s a clue I guess. Are you sure the connections are being handled by the correct receive connector? Turning on protocol logging and looking in the receive protocol logs should help you identify if that’s the issue.

    Not sure why you’re using port 1501 either.

  11. Paul says:

    If you want to use STARTTLS via 25 instead of 587 is it safe to change the FQDN on the Default Frontend Connector or do you recommend creating a new connector and setting the FQDN to the namespace in your cert?

      • Dilshan Saminda says:

        I followed article section “EXTERNAL SMTP RELAY WITH EXCHANGE SERVER 2016 USING AUTHENTICATION” to configure default client frontend connector ERVERNAMEClient Frontend SERVERNAME. So everyone can send email outside now. I just need to stop it. Please advice

  12. Dustin Jones says:

    Paul, Love your website. Thanks for all you do. We recently migrated from 2010 to 2016 and thanks to you the migration has been fairly uneventful. One issue I am having is when I create receive connectors the Exchange FrontEndTransport service won’t start after I reboot the server. If I disable the receive connectors the service starts and external mail flows as normal.

    I created the connectors with Powershell and they are all FrontendTransport connectors not HubTransport. Any help is much appreciated.

    • The most likely cause is a port conflict. Are the custom receive connectors configured a port other than 25?

      You can also check the event log for more info on what’s causing the service to fail to start.

Leave a Reply

Your email address will not be published. Required fields are marked *