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.

PS C:\> Resolve-DnsName -Type MX

Name                                     Type   TTL   Section    NameExchange                              Preference
----                                     ----   ---   -------    ------------                              ----------                     MX     3600  Answer                 40

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:


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.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for


  1. Ramesh

    We have Exchange 2016 on premise. Currently encountering issues with incoming mail (although internal and outgoing emails work) . It started occurring last evening .. would anyone be in a position to assist ? Thanks

  2. Vijay Prabhu

    Der Paul,

    My test lap working fine which I followed your article . here external to internal mail flow is fine. But internal to external mail flow working though “MX Route”. I am trying to route with smarthost option and i don’t have any email security appliance OR firewall. I am connecting directly to my modem . Also port 25 not working and MY ISP mentioned no blocking for port 25. Please suggest any steps i am missing and i am ready to purchase new device if required here.

  3. Bo

    Hi Paul,
    Is it possible to forcefully convert all arriving emails at an exchange server to UTF-8? The reason for doing this is that a downstream application (Siebel, it’s Database is Oracle UTF-8) is not able to read off emails in GB18030 from Exchange, then convert it to UTF-8. Your help is appreciated.


  4. Bernard

    Hi Paul,

    Thanks for the very interesting post. I have a question and i hope you have the time to answer;
    I tested my mxrecords with the powershell you gave me, and the result is that my mx record points to my first server, not my second server on wich my exchange resides. This is (i think) logical, because during setup i entered that domain for my server. So, during install i gave in as domain, but this is also my external domain. How do i change/point to the right server instead of my internal server?

  5. John Ibik

    Hello Paul,

    I have been following your blogs, they are very helpful. Sorry, I’m not an exchange expert. I will need your help. I have just setup my exchange server 2016 homelab, I can sent outbound and inbound email to different emails, however, the issues I’m having now is that I cannot access my external URI on a differnt network but it works well on my internal network.

    I have configured both public and internal DNS in split brain mode. Please, any ideal of who I should work aroud this?

  6. Minkin

    “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.”

    Can you explain this further? In the past we used to uncheck Anonymous and lock down our connectors to only receive mail from certain places. Is that no longer the case with 2013/2016 and this default connector?

    1. Avatar photo
      Paul Cunningham

      Unchecking anon in the past (it was unchecked by default in 2010 actually) was probably in environments where a smart host (e.g. an antispam server) handled inbound email. Other than that, unless you want to explain more about why you thought it helped, it’s not necessary for Exchange 2013/2016 servers. Anonymous connections can’t relay, so it’s not an open relay risk. The anon permission is required for inbound internet mail though.

  7. Theo Hertog

    Hi Paul,

    Were in Exchange 2016 can I find the Inbound Connector for POP3/IMAP like SBS2011?

    Best regards,


  8. Farooque


    I am confused in a deployment case. What I have :
    a registered domain with suffix ip at goDaddy
    local AD 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?

  9. Kiran Ramesh

    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

    1. Avatar photo
      Paul Cunningham

      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.

  10. Kannan

    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.

  11. André Winkler

    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

Leave a Reply