The receive connector will not allow an anonymous, unauthenticated sender to relay to external domain names, which prevents your server from being exploited as an open relay.
There are two ways you can resolve this and allow your devices and applications to send to external recipients: The first method is to use authenticated SMTP connections.
We can now test the connector using Telnet from the IP address that was added to the remote network settings of the receive connector.
PS C:\> Send-Mail Message -Smtp Server mail.exchange2016-Credential $credential -From '[email protected]' -To '[email protected]' -Subject 'Test email' -Port 587 -Use Ssl In the above example the email is successfully received by the external recipient.Set the Role to “Frontend Transport”, and the Type to “Custom”. This represents the IP and port that the server will be on for connections.Multiple receive connectors on the Frontend Transport service can listen on the same port of TCP 25.True EXSERVERClient Frontend EXSERVER True C:\>telnet exserver 25 220 EXSERVER.exchange2016Microsoft ESMTP MAIL Service ready at Thu, 1000 helo 250 EXSERVER.exchange2016Hello [192.168.0.30] mail from: [email protected] 2.1.0 Sender OK rcpt to: [email protected] 2.1.5 Recipient OK Data 354 Start mail input; end with . 250 2.6.0 <[email protected]om> [ Internal Id=854698491929, Hostname=EXSERVER.exchange2016demo.com] Queued mail for delivery So there's no specific configuration required on the server or the connectors to allow this scenario, however it is recommended that you use a DNS alias instead of the real server name.This will allow you to configure all of your devices and applications with the DNS alias, and you can later move that DNS alias to point to a different Exchange server during a migration.Remove the default IP range from the Remote network settings, and then add in the specific IP addresses or IP ranges that you want to allow anonymous SMTP relay from.I do not recommend adding entire IP subnets that contain other Exchange servers as this can cause issues with server to server communications.The receive connector is named “SERVERNAMEDefault Frontend SERVERNAME”, for example, “EXSERVERDefault Frontend EXSERVER” in my test environment.[PS] C:\> Get-Receive Connector Identity Bindings Enabled -------- -------- ------- EXSERVERDefault EXSERVER True EXSERVERClient Proxy EXSERVER True EXSERVERDefault Frontend EXSERVER True EXSERVEROutbound Proxy Frontend EXS...However, as you'll see by reading my article on issues with load balancing SMTP traffic, when a load balancer is source NATing the connections the only IP address that will appear to the Exchange server is that of the load balancer itself, not the source device or application.While this simplifies the receive connector configuration (only the load balancer IP needs to be added as an allowed IP) it opens up a number of concerns: You can read more about these issues here.