Home » Exchange Server » Inbound Mail Flow for Exchange Server 2016

Inbound Mail Flow for Exchange Server 2016

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 exchange2016demo.com 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 mail.exchange2013demo.com
  • 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 MXToolbox.com 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:


As you can see establishing inbound mail flow for an Exchange 2016 server involves the configuration of several different items. Fortunately some of them are configured automatically for you and require little adjustment for most environments.

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


  1. André Winkler says:

    Hi Paul,

    nice post, thx.

    We are using a postfix server as mail frontend at the internet. Is it possible to use Exchange AntiSpam Features (dynamic Recipient check) with the FrontendTransport Connector? In Exchange 2013 i think you will need a HubTransport Connector?

    Thanks and best regards

  2. Kannan says:

    Hi Paul,
    In my case it is completely weird. I have exchange 2010 and introduce EX2016 two servers. Mail flow was working fine before and stopped after EX 2016. My EX 2010 hub is the ony one allowed to send external and receive through firewall. Any reason why? I moved my mailbox to Ex2016.

  3. Kiran Ramesh says:

    Hello Paul,

    MAPI/HTTP :-

    Starting with Ross Smith Quote :

    Ross Smith quote
    “It removed the dependency of RPC as an intermediary. It was a huge win for us. RPC, as great as it is, is not owned by the Exchange development team. Any time we felt we wanted to enhance the RPC protocol…we couldn’t do it. We own MAPI. We can make any investment in the MAPI protocol we want.

    Ross Smith IV”

    I have a question now, If you see the Mail flow architecture in Exchange 2016. Mailbox Transport Submission Service & Mailbox Delivery Service still uses RPC to communicate with the Database. Any idea why it is kept like that.

    Kiran Ramesh

    • Clients talk to Exchange over all kinds of network conditions, and in particular with Exchange Online they need a protocol optimized for those conditions and that they can improve over time as they see fit.

      Exchange components talk to each other over a fairly predictable set of network conditions, or in many cases, internal to the server itself. So the need to optimize is not the same.

  4. Farooque says:


    I am confused in a deployment case. What I have :
    a registered domain with suffix exchnage365experts.com ip at goDaddy
    local AD exchange365experts.com with exchange 2016.
    Local AD is also DNS and DC with ip and my local exchnage 2016 ip is
    All internal mailflow is fine.
    I setup a outbound connector with name space * to send email to interenet but it never works?

    My public DNS settings are as
    Created A record with ip of my exchange ip
    Created MX pointing to A record of my exchnage
    Created autodiscover pointing to A record.
    It also never works for inbound emails……What DNS configurations i ma missing?

    Outbound emails remains in queue for days ….and exchange attempt to send it but it never….Some times it does outbound emails to yahoo hotmail or any other domain but it is very rare case.
    What im missing?

Leave a Reply

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