Configuring inbound mail flow for an Exchange Server 2016 environment is reasonably simple, however there are several different parts involved. For your server to receive email from the internet and deliver it to internal recipients there needs to be:

  • An Accepted Domain configured for the organization
  • An email address assigned to the recipient
  • MX records in your public DNS zone
  • SMTP connectivity from external senders to your Exchange server, or a mail route that leads to your Exchange server

The Exchange server will accept SMTP connections using a receive connector. A receive connector that is suitable for incoming email from the internet is pre-configured for you by Exchange setup, so there’s no need for you to configure one yourself. The receive connector is named Default Frontend SERVERNAME.


If you look at the properties of that connector you might notice that “Anonymous Users” is enabled as a permission group. Yes this is the correct configuration for the connector, and no that does not mean it can be abused as an open relay.

Configuring Accepted Domains

Accepted domains define which domain names your Exchange servers will accept email for. When you install a new Exchange 2016 server the DNS name of the Active Directory forest is automatically added as an accepted domain for the Exchange organization. If your Active Directory forest DNS name happens to match the SMTP domain you plan to use for email, then there’s no additional work required here. Similarly, if you’re installing Exchange 2016 into an existing Exchange organization, the accepted domains are likely already configured.

You can view your accepted domains in the Exchange Admin Center. Navigate to mail flow and then choose accepted domains. In my test environment the accepted domain of is already present.


If you need to add a new accepted domain click the “+” icon, which launches a wizard for the task. Enter a name for the accepted domain, then the domain name itself (I always just configure those two values to be the same).


Notice the three options for the type of domain. The explanations are very clear, but to summarise:

  • Authoritative – a domain for which your servers host the only recipients. For most scenarios this will be the correct choice.
  • Internal relay – a domain for which your servers host some, but not all of the recipients. A typical use case for this type of accepted domain is a shared SMTP namespace, which is often required when two companies are merging or separating.
  • External relay – a domain for which your server receives email, but hosts none of the recipients.

Add any domain names that you need for your organization, then move on to the email address policies.

Configuring Email Address Policies

The next step is to add email addresses to recipients in your organization. You can do this on a per-recipient basis, by simply opening the properties of the recipient (such as a mailbox), selecting email address, and adding the desired SMTP address.


Of course this is not a very efficient way to manage multiple recipients, and even though PowerShell is available for automating this step, the more effective method is to use email address policies. An email address policy is configured by default when you install a new Exchange 2016 server, or it will simply use the existing policy if you’re installing into an existing organization. Email address policies are found in the mail flow section of the Exchange Admin Center.


In my test environment the default email address policy configured by Exchange setup already contains the default accepted domain that was also configured by setup. The default address format is alias@domain, and we can either change that or add more address formats or addresses for different domain names to the policy if required.


Earlier you may have noticed the check box on the mailbox user that says:

Automatically update email addresses based on the email address policy applied to this recipient.

In effect this means that the email address policy shown above will stamp the SMTP addresses on that recipient (and all the other recipients with that check box enabled), without me having to add them manually.

Review or modify your email address policies and confirm that recipients have the desired SMTP addresses, then move on to DNS records.

Configuring MX Records in DNS

With the accepted domains and email addresses configured the next thing to look at is the MX records in the public DNS zone. At least one MX record is required for other email systems to be able to locate yours in DNS. The steps to add the MX record to your DNS zone will vary depending on the DNS control panel your provider gives you access to. Basically you will need to configure:

  • An MX record that resolves to an A record, for example
  • The A record that resolves to an IP address

You can test your MX record using PowerShell and the Resolve-DnsName cmdlet.

Or you can use tools such as to test your MX records.



Configure and test your DNS records, then move on to SMTP connectivity.

Configuring SMTP Connectivity to the Exchange Server

The final piece of the solution is to establish SMTP connectivity to the Exchange server. There’s generally two approaches used for this:

  • The firewall is configured to NAT and allow SMTP connections directly to the Exchange server (either the Mailbox server or an Edge Transport server)
  • SMTP connections first go to an inbound smart host, such as an email security appliance or cloud service, which then routes the messages on to your Exchange server

Of course, there are many other variations of how inbound SMTP connectivity is established depending on the size and complexity of the organization, but those are two typical examples.

The configuration steps for your firewall will depend on the type of firewall you’re running. After configuring your firewall you can look at performing tests of your end to end solution.

Testing Inbound Mail Flow to Exchange

Considering all of the parts involved in this solution it’s important to test the configuration in a way that will help to pin-point any issues that may be present. I cover inbound SMTP connectivity troubleshooting in the following article:

Abdulsalam Garba

The author Abdulsalam Garba

Leave a Response