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.
PS C:\> Resolve-DnsName -Type MX exchange2016demo.com Name Type TTL Section NameExchange Preference ---- ---- --- ------- ------------ ---------- exchange2016demo.com MX 3600 Answer mail.exchange2016demo.com 40
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.
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.
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.
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 test.nl as domain, but this is also my external domain. How do i change/point to the right server instead of my internal server?
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?
“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?
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.
Were in Exchange 2016 can I find the Inbound Connector for POP3/IMAP like SBS2011?
No such thing. What functionality are you looking for?
I am confused in a deployment case. What I have :
a registered domain with suffix exchnage365experts.com ip 126.96.36.199 at goDaddy
local AD exchange365experts.com with exchange 2016.
Local AD is also DNS and DC with ip 10.10.10.128 and my local exchnage 2016 ip is 10.10.10.129.
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 10.10.10.129 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?
Here’s some info (including troubleshooting tips) for outbound mail flow.
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.
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.
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.
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