Geeks With Blogs
Kay Sellenrode's Blog

Recently I designed and implemented a large Office 365 environment, part of it was a Hybrid Exchange 2013 server that should also serve as a central SMTP relay server to 365 and the rest of the world.
Since we didn't want to control a huge list of authorized IP addresses and of course adding complete IP subnets is a bad idea, we chose to use SMTP authentication as our main solution for supporting Mail relaying.

Every office location was assigned a separate account only for this purpose and the credentials were handed out to the IT admin.
In the past I've done this quite often where we configured these accounts as authorized users in Exchange on the receive connector.

But when I configured Exchange 2013 I noticed that the server responded differently from what I expected.
When I added the permissions to the Default Frontend receive connector I could start the process of submitting a message, but once I submitted the data portion of the message I got a reply telling me the user was not authorized to send.
The exact error was: 550 5.7.1 Client does not have permissions to send as this sender

At first I slapped my head because I knew the frontend receive connector should only proxy towards the backend connectors, there all the processing should take place.
All the documentation and even my MCM training taught me that the frontend and backend connectors are tied to each other.
Meaning the "Default Frontend" receive connector would forward towards the "Default" receive connector, and the "Client Frontend" receive connector would forward to the "Client Proxy" receive connector.

So I added the correct permissions for the relay accounts to the "Default Frontend" receive connector, but this didn't resolve the issue of receiving the 5.7.1 error message.
After quite some researching I found out that instead of what I knew of the Receive connectors, these connections were forwarded from the "Default Frontend" receive connector towards the "Client Proxy" receive connector.
Since I also noticed quite some posts on the World Wide Web, were people had the same assumptions and couldn't find a solution I put this blog post together.

So here I outlined the steps required to configure authenticated SMTP relaying in Exchange 2013.

Let's start with the Pre-requirements:

A mailbox enabled account, in my example "testkay"
A group which contains all relay accounts, in my example "Relay Accounts"

So first we will start off with adding the right permissions to the receive connectors.
To allow relaying at the "Default Frontend" receive connector we need the submit to server right assigned to our group "Relay Accounts" no other permissions are required yet.

The following PowerShell Command will set this right for our group.

Get-ReceiveConnector "default frontend*" | Add-ADPermission -User "contoso\relay accounts" -ExtendedRights ms-Exch-SMTP-Submit

For the "Client Proxy" receive connector we need to hand out the actual relay permissions, in our case we allowed the accounts to send from any address to any address but this might be different, see the list below for what each permission gives you.

  • ms-Exch-SMTP-Submit – allow to submit messages (required permission)
  • ms-Exch-SMTP-Accept-Any-Recipient – allow messages to be sent to email addresses unknown to the local server (known as relaying)
  • ms-Exch-SMTP-Accept-Any-Sender – allow sending as any email address that is unknown to the local organization
  • ms-Exch-SMTP-Accept-Authoritative-Domain-Sender – allow sending as any email address that is constructed with the authoritative domain (in our environment
  • ms-Exch-Accept-Headers-Routing – to keep all routing headers in the email, not required but can be nice for troubleshooting.

We picked the all of the above options and set the permissions with the next PowerShell command.

Get-ReceiveConnector "client proxy*" | Add-ADPermission -User "contoso\relay accounts" -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-SMTP-Accept-Any-Sender,

Ok so we configured the correct permissions now, and that should be enough to allow authenticated relaying of email messages, but reality is that not all devices on our network support NTLM authentication and our TLS encryption.
For our environment it was an acceptable risk to allow basic authentication, and especially for testing purposes this can be helpful as well.

To allow basic authentication we needed to alter the "default frontend" security settings from basic authentication only after offering TLS to allow basic authentication always.
This change can be made using the following PowerShell command

    Get-ReceiveConnector "default frontend*" | Set-ReceiveConnector -AuthMechanism Tls, Integrated, BasicAuth, ExchangeServer

You can notice if basic authentication without TLS is enable when you start a Telnet session and execute the EHLO command, you will receive a response that should list the command "AUTH LOGIN" or "AUTH NTLM LOGIN"

To test from telnet if you can relay you need to encode your username and password to Base64, google will give you several translators to perform this.


Here is some additional info to troubleshoot the relaying process.
I use Telnet to test the connection, using the following lines to test the submission of an email with Basic authentication

telnet Exchange2013 25


auth login









Since I needed to do some further troubleshooting I also set the ProtocolLoggingLevel for the "Default FrontEnd" receive Connector, "Intra Organizational Send Connectors", "Default" and "Client Proxy" receive connectors to verbose logging. Use the following commands to set each of these.


Get-ReceiveConnector "Default FrontEnd*" | Set-ReceiveConnector –ProtocolLoggingLevel Verbose
Get-FrontendTransportService | Set-FrontendTransportService -IntraOrgConnectorProtocolLoggingLevel verbose
Get-ReceiveConnector "Default servername*" | Set-ReceiveConnector –ProtocolLoggingLevel Verbose
Get-ReceiveConnector "Client Proxy*" | Set-ReceiveConnector –ProtocolLoggingLevel Verbose


The logs created by these connectors can be found at the following locations (these are the default locations):

  • For the FrontEnd Receive connectors: C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive
  • For the Hub Transport Receive connectors (ie. Default" and "Client Proxy"): C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive
  • For the Intra Organizational Send connectors: C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend

Posted on Saturday, May 3, 2014 12:56 AM | Back to top

Comments on this post: Authenticated SMTP relaying in Exchange 2013

# re: Authenticated SMTP relaying in Exchange 2013
Requesting Gravatar...
Thanks for this. Was struggling to get my head it. Exactly what I needed.
Left by Andy on Sep 03, 2014 10:44 AM

# re: Authenticated SMTP relaying in Exchange 2013
Requesting Gravatar...
Any reason you didn't just alter the Client Receive connector and leave the default front-end alone? Your clients would need to use 587 to relay, but this is the MS suggested practice anyway. 25 is supposed to be for inbound "untrusted" messages only.

Additionally, you only need the extra permissions you've mentioned if the relay account needs to be able to spoof the from: address or relay outside of the organization on to:. By default, the port 587 SMTP connector has basic auth enabled, and any authenticated Exchange user can send From: themselves and to: anybody in that Exchange org.

We do it this way for our copiers, and I use a shared "no-reply" address for all of them, and the users are supposed to scan materials to themselves and then forward to external recipients as necessary...
Left by Braden on Oct 15, 2014 11:47 PM

# re: Authenticated SMTP relaying in Exchange 2013
Requesting Gravatar...
As a further clarification to my previous comment, I meant alter the Client "frontend" connector... the various Proxy connectors should generally never need to be touched.
Left by Braden on Oct 15, 2014 11:50 PM

# re: Authenticated SMTP relaying in Exchange 2013
Requesting Gravatar...
Hi i need to enable Authentication on users on SMTP using port 25. At the moment if i use a SMTP tool from my netowok i can send emails to any user form any user. How can i restrict this So no one can send emails using SMTP:25. Can i use users or groups who will be allowed to use SMTP:25 to send emails.
Left by Z Rather on May 21, 2015 11:27 AM

# re: Authenticated SMTP relaying in Exchange 2013
Requesting Gravatar...
Hi Kay,

Just wanted to say thanks for this post. It really helped a lot :).
One thing I do not get here (new in the Exchange waters) is that when I configure a receive connector for relay purposes with Anonymous authentication then I can relay even without setting up the permissions for the "Client Proxy" receive connector but once I set a user/group for authentication purpose then nothing works until I set the permissions stated by on the Client Proxy receive connector. Do you have an Idea why is so?
Again thank you.

Left by AirMax on Apr 05, 2016 4:55 PM

# re: Authenticated SMTP relaying in Exchange 2013
Requesting Gravatar...
thanks for this help but I have a problem with my smtp.
in logs, I see the following error :
Setting up client proxy session failed with error: 451 4.5.0 Require XAnonymousTls to send mail
Have you got any idea about this problem ?
Thanks for your help.
Left by Nicolas on Aug 29, 2017 3:27 PM

# re: Authenticated SMTP relaying in Exchange 2013
Requesting Gravatar...
Hello Everyone,

In our SMTP environment, we gave permission to an AD Security group. So new users who want to use SMTP service will be added to this security group to get permission for sending emails. We have around 1K users that are sending emails. We are able to get the service account that is used to authenticate while sending emails from Receive logs. My requirement is to capture all the email logs with fields -TimeStamp, Client, sender, Receiver, Message subject, Account, SourceServer ...etc. in to a database so we can calculate the utilization of our customer.

I could get most of the fields from Get-MessageTrackingLog cmdlet but it doesn't give the authenticated account that was used to send the email. So for this, I have to go check the Receive text logs for the sessionID of the email and then filter the account by searching the session string. I have applied this logic in script and it is running as expected but it's taking loooooong time :-) . I have reduced the execution time of the powershell script by applying conditional scans of the text files but since the servers are used heavily, the speed we get the output is making the script unreliable. Could someone please let me know if there is any command or module that can be used to get the Authenticated account information straight away?

Thanks for the help in advance.
Left by Ramana on Oct 24, 2017 4:04 PM

Your comment:
 (will show your gravatar)

Copyright © Kay Sellenrode | Powered by: