When you first install Exchange Server 2016 there is no outbound mail flow configured by setup. If you happen to be installing into an existing Exchange organization then the existing outbound routes for the organization will apply, and mail sent by mailboxes on your new Exchange server to external recipients will likely work. However if you’re installing into a new organization, or want to change your existing outbound mail flow, then you’ll need to create a send connector.
Send connectors control outgoing mail flow from your Exchange server. Every organization that needs to send email message to external recipients will need at least one send connector. In this tutorial we’ll look at creating and testing a new send connector for outbound email from an Exchange Server 2016 server.
Creating a Send Connector for Exchange Server 2016
Log on to your Exchange Admin Center and navigate to mail flow and then send connectors.
Give the new send connector a meaningful name and set the Type to Internet.
Next you’ll need to decide how the outbound emails will be delivered. There are two choices – by MX record, or via smart host. MX record delivery involves your Exchange server looking up the MX records of the recipient’s domain in DNS, and then connecting directly to their email server via SMTP to deliver the email message. Smart host delivery involves your Exchange server sending the messages to a specified IP address or host name for another system (typically an email security appliance or cloud service) that is then responsible for the further delivery of that email message.
For this example I’m going to use MX records to deliver the message. My server already has outbound firewall access on TCP port 25, and can resolve MX records on the internet using DNS, so at a basic level this should work fine. There are other considerations such as SPF and IP reputation in the real world that may impact the delivery of email messages from your server.
Set the address space for the send connector. An address space of “*” means “any domain” and is suitable if you have one send connector that is used for all outbound mail flow. You can use this address space option if you later need to configure specific send connectors for different domains.
Finally, set the source server for the send connector. If you have multiple servers that you want to be responsible for outbound mail flow you can add more than one server to this list.
Click Finish to complete the wizard.
Testing the Send Connector
A simple test to verify that the send connector is working is to send an email from a mailbox on the server to an external address. If the email message is received by the external mailbox you can then check the message headers by copying them from the message and pasting them into the Message Analyzer at ExRCA.com. This will verify for you that the email message took the intended route (via your new server) instead of some other existing outbound route in your organization.
If the email message was not received check the transport queue on the Exchange 2016 server.
[PS] C:\>Get-Queue Identity DeliveryType Status MessageCount Velocity RiskLevel OutboundIPPool NextHopDomain -------- ------------ ------ ------------ -------- --------- -------------- ------------- EXSERVER\3 DnsConnec... Ready 0 0 Normal 0 gmail.com EXSERVER\Submission Undefined Ready 0 0 Normal 0 Submission
If you see message stuck in the queue for the next hop domain that you’re trying to send to you can see more details about them by piping the command to Get-Message.
[PS] C:\>Get-Queue | Get-Message | fl
In particular look for the LastError attribute of the queued messages, which will often contain a status code that will tell you why the messages are not being delivered.
Since outbound mail flow depends on DNS and firewall access you can also check those items. For example, to verify that MX records can be resolved in DNS by the Exchange server use the Resolve-DnsName cmdlet.
[PS] C:\>Resolve-DnsName gmail.com -Type MX
You can also test SMTP connectivity from the server using Telnet. Because the Telnet client is not installed by default on Windows Server you may need to install it first.
[PS] C:\>Install-WindowsFeature Telnet-Client
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {Telnet Client}
From a CMD prompt try to telnet to one of the MX records you resolved earlier.
C:\>telnet gmail-smtp-in.l.google.com 25 220 mx.google.com ESMTP bv3si49894863pbd.105 - gsmtp
If you do not see the 220 response and banner you may have an outbound SMTP connectivity issue that you need to look into further on your firewall.
Finally, if SMTP connectivity looks fine but the emails are still not being delivered you can enable protocol logging on your send connector and then use the log data to assist your troubleshooting.
[PS] C:\>Set-SendConnector "Internet Email" -ProtocolLoggingLevel Verbose
The protocol logs are stored by default in C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend and can be opened and read in a text editor such as Notepad. The protocol log will show the SMTP conversation between your server and the external recipient’s server, so any SMTP errors should appear in the log.
Summary
Outbound mail flow from your Exchange 2016 server requires a send connector to be configured. In the article above I demonstrated how to configure a new send connector for a simple scenario, as well as some troubleshooting steps to help you test and validate that the send connector is working.
This article Outbound Mail Flow for Exchange Server 2016 is © 2015 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com
