How to create Anonymous relay for applications in Exchange 2016
In this blog we will see the step by step procedure of “how to create an anonymous relay connector to allow applications to relay through the Exchange Server 2016”.
Check this new article with screenshots:
SMTP Relay connectors in Exchange 2016: SMTP Relay connectors in Exchange 2016
Basically, as we all know that the application we are planning to relay through the Exchange Server requires certain relay permission and only then it can relay mails through the Exchange Server 2016. We have to create separate Relay connectors for this purpose.
Let’s the steps to create an anonymous relay connector in the Exchange 2016:
Step 1: Launch Exchange Control panel. Navigate to Mail flow => Receive Connectors => then Click “+” => Provide a Name for the Relay Connector as “Application Relay” => Select Role as “FrontEnd Transport“& the Type as “Custom” (For Example, to allow application relay) => click next.
Step 2: Under Network adapter binding Leave it as it is (All available IPv4) => click next.
Step 3: In the next screen for Remote Network Settings (Receive mail from servers that have these remote IP addresses). Add the
IP address of the application servers that needs to be relayed through the Exchange Server. Click Finish.
Step 4: Now double click on the new “Application Relay” connector => click “Security” option on the left side => Under authentication select “Transport Layer Security (TLS) and under Permissions select “Anonymous Users” and then Save.
Alternatively we can even create the Relay connector using the Exchange Management Shell command. Below is the PowerShell command we can use to create the Relay connector:
First run the below command to create a relay connector:
New-ReceiveConnector -Name “Application Relay” -RemoteIPRanges (“10.1.1.0″,”10.1.1.7”) -TransportRole “FrontendTransport” -Bindings (“0.0.0.0:25”) -Usage “Custom” -Server “Servername.domain.com”
Next we have to add permission to the created Relay connector. Run the below command to add anonymous permission to the relay connector created:
Set-ReceiveConnector -Identity “ServernameApplication Relay” -PermissionGroups “AnonymousUsers”
Below is the command to enable permission to accept any recipient (Open relay):
Get-ReceiveConnector “ServernameApplication Relay” | Add-ADPermission -User “NT AUTHORITYANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”
Example: Get-ReceiveConnector “Exchange servernamereceive connector name” | Add-ADPermission -User “NT AUTHORITYANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”
Note: Certain applications like automated ticketing system, CRM application etc require an open relay permission. In such cases we can give the open relay permission explicitly to the specific connector alone. We must be very careful when giving the open relay permission, do not assign this permission to the Default receive connector at any cost, the server will become open relay & spammers will start hacking the server.
As we are already discussing extended rights on the receive connector let us review some more permissions which I was reviewing here at Microsoft Technet.
| Receive connector permission | Description |
|---|---|
| ms-Exch-SMTP-Submit | The session must be granted this permission or it will be unable to submit messages to this Receive connector. If a session doesn’t have this permission, the MAIL FROM and AUTH commands will fail. |
| ms-Exch-SMTP-Accept-Any-Recipient | This permission allows the session to relay messages through this connector. If this permission isn’t granted, only messages that are addressed to recipients in accepted domains are accepted by this connector. |
| ms-Exch-SMTP-Accept-Any-Sender | This permission allows the session to bypass the sender address spoofing check. |
| ms-Exch-SMTP-Accept-Authoritative-Domain-Sender | This permission allows senders that have e-mail addresses in authoritative domains to establish a session to this Receive connector. |
| ms-Exch-SMTP-Accept-Authentication-Flag | This permission allows Exchange 2003 servers to submit messages from internal senders. Exchange 2010 will recognize the messages as being internal. The sender can declare the message as trusted. Messages that enter your Exchange system through anonymous submissions will be relayed through your Exchange organization with this flag in an untrusted state. |
| ms-Exch-Accept-Headers-Routing | This permission allows the session to submit a message that has all received headers intact. If this permission isn’t granted, the server will strip all received headers. |
| ms-Exch-Accept-Headers-Organization | This permission allows the session to submit a message that has all organization headers intact. Organization headers all start with X-MS-Exchange-Organization-. If this permission isn’t granted, the receiving server will strip all organization headers. |
| ms-Exch-Accept-Headers-Forest | This permission allows the session to submit a message that has all forest headers intact. Forest headers all start with X-MS-Exchange-Forest-. If this permission isn’t granted, the receiving server will strip all forest headers. |
| ms-Exch-Accept-Exch50 | This permission allows the session to submit a message that contains the XEXCH50 command. This command is needed for interoperability with Exchange 2003. The XEXCH50 command provides data such as the spam confidence level (SCL) for the message. |
| ms-Exch-Bypass-Message-Size-Limit | This permission allows the session to submit a message that exceeds the message size restriction configured for the connector. |
| Ms-Exch-Bypass-Anti-Spam | This permission allows the session to bypass anti-spam filtering. |
We can now test mails from the application to see if we receive it. For troubleshooting the issue with application mails not being relayed through the server, we can enable the Logging in the Relay connector & analyse the logs.
Ratish Nair
Microsoft MVP | Exchange Server
Team @MSExchangeGuru
April 8th, 2016 at 10:12 am
Hi Ratish,
We are running On-Premises Exchange 2010 environment with Exchange Online Protection (EOP) subscription. our all inbound and outbound emails pass through EOP.
We have following Exchange Infrastructure for email routing:
two Hub Transport > Single Edge > EOP
We recently encountered an issue when our marketing department sent bulk emails to customers and we were told that we can’t send email to large recipients (250k+ recipients).
so we are looking to find a way to exclude bulk email from going to EOP and we would be able to route email through a separate send connector that sends email to recipients. please suggest, how can we achieve it?