Allowing application servers to relay off Exchange Server 2007

From time to time, you need to allow an application server to relay off of your Exchange server. You might need to do this if you have a SharePoint, a CRM application like Dynamics, or a web site that sends emails to your employees or customers.

You might need to do this if you are getting the SMTP error message “550 5.7.1 Unable to relay

The top rule is that you want to keep relay restricted as tightly as possible, even on servers that are not connected to the Internet. Usually this is done with authentication and/or restricting by IP address. Exchange 2003 provides the following relay restrictions on the SMTP VS:

Here are the equivalent options for how to configure this in Exchange 2007.

Allow all computers which successfully authenticate to relay, regardless of the list above

Like its predecessor, Exchange 2007 is configured to accept and relay email from hosts that authenticate by default. Both the “Default” and “Client” receive connectors are configured this way out of the box. Authenticating is the simplest method to submit messages, and preferred in many cases.

The Permissions Group that allows authenticated users to submit and relay is the “ExchangeUsers” group. The permissions that are granted with this permissions group are:

NT AUTHORITY\Authenticated Users {ms-Exch-SMTP-Submit}
NT AUTHORITY\Authenticated Users {ms-Exch-Accept-Headers-Routing}
NT AUTHORITY\Authenticated Users {ms-Exch-Bypass-Anti-Spam}
NT AUTHORITY\Authenticated Users {ms-Exch-SMTP-Accept-Any-Recipient}

The specific ACL that controls relay is the ms-Exch-SMTP-Accept-Any-Recipient.

Only the list below (specify IP address)

This option is for those who cannot authenticate with Exchange. The most common example of this is an application server that needs to be able to relay messages through Exchange.

First, start with a new custom receive connector. You can think of receive connectors as protocol listeners. The closest equivalent to Exchange 2003 is an SMTP Virtual Server. You must create a new one because you will want to scope the remote IP Address(es) that you will allow.

The next screen you must pay particular attention to is the “Remote Network settings”. This is where you will specify the IP ranges of servers that will be allowed to submit mail. You definitely want to restrict this range down as much as you can. In this case, I want my two web servers, & to be allowed to relay.

The next step is to create the connector, and open the properties. Now you have two options, which I will present. The first option will probably be the most common.

Option 1: Make your new scoped connector an Externally Secured connector

This option is the most common option, and preferred in most situations where the application that is submitting will be submitting email to your internal users as well as relaying to the outside world.

Before you can perform this step, it is required that you enable the Exchange Servers permission group. Once in the properties, go to the Permissions Groups tab and select Exchange servers.

Next, continue to the authentication mechanisms page and add the “Externally secured” mechanism. What this means is that you have complete trust that the previously designated IP addresses will be trusted by your organization.

Caveat: If you do not perform these two steps in order, the GUI blocks you from continuing.

Do not use this setting lightly. You will be granting several rights including the ability to send on behalf of users in your organization, the ability to ResolveP2 (that is, make it so that the messages appear to be sent from within the organization rather than anonymously), bypass anti-spam, and bypass size limits. The default “Externally Secured” permissions are as follows:

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Anti-Spam}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Message-Size-Limit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Exch50}
MS Exchange\Externally Secured Servers {ms-Exch-Accept-Headers-Routing}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Submit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender}

Basically you are telling Exchange to ignore internal security checks because you trust these servers. The nice thing about this option is that it is simple and grants the common rights that most people probably want.

Option 2: Grant the relay permission to Anonymous on your new scoped connector

This option grants the minimum amount of required privileges to the submitting application.

Taking the new scoped connector that you created, you have another option. You can simply grant the ms-Exch-SMTP-Accept-Any-Recipient permission to the anonymous account. Do this by first adding the Anonymous Permissions Group to the connector.

This grants the most common permissions to the anonymous account, but it does not grant the relay permission. This step must be done through the Exchange shell:

Get-ReceiveConnector “CRM Application” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”

In addition to being more difficult to complete, this step does not allow the anonymous account to bypass anti-spam, or ResolveP2.

Although it is completely different from the Exchange 2003 way of doing things, hopefully you find the new SMTP permissions model to be sensible.

More information

See the following for more information:

Scott Landry

Comments (16)
  1. Back in the dark time of inconsistent admin interface. An admin stuff (very common, indeed) we do in the GUI since 1996. Now we have to do it partially in the gui, partially in the cmdline (without persistent evidence, to other admins, of what we have configured); and we have to use the GUI in "the right order" otherwise don’t work….not enough words for that.

  2. Scott Landry says:

    Option #1 (which is preferable) is 100% in the GUI.

  3. Tim Davis says:

    I had this working great, until I enabled spam protection within Exchange 2007… What do I need to do in order to get this working with Exchange 2007 Antispam? Our CRM application needs to relay for outbound messages only.

  4. Scott Landry says:

    Tim: Option 1, which is preferable, grants the server "ms-Exch-Bypass-Anti-Spam".  I’m assuming you want the server to bypass the spam checks?  If that does not help, you might have a red herring here.

  5. Tim Davis says:

    I did that, it didn’t work. And what’s a red herring? Any other ideas?

  6. Mik says:

    With all these things that can only be done via cryptic Shell commands, and even registry settings in some cases (just see some of the advice given by the Best Practices Analyzer), it looks to me like this product shipped half-complete!

  7. ewall says:

    Yeah, guys: I hate to complain: but relaying has gone from an easy-to-abuse feature (but hey, you should know what you’re doing to use the product!) to an undocumented feature. It takes a few attempts of Googling to find this page, and in the process you can find a few other, shall we say, "less correct" attempts to solve the need-to-relay problem (I will resist the urge to link them here)… Until then, this page has to be in my permanent bookmarks for Exchange 2007’s "Missing Manual".

  8. Anonymous says:

    This took me a while so I want to share some of my findings. My situation may be a common one so here's

  9. John Weathers says:

    I’ve been searching for the way to do this in Exchange 2003.  I have external servers that need to be able to anonymously relay alert messages through our Exchange 2003 server.  I have Anonymous Authentication permitted and the IP addresses of the servers in the "Select which computer may relay through this virtual server" field.  I unchecked the "Allow any computer which authenticates to relay…" box.  I am still able to telnet to the Exchange server and relay mail from IP addresses that are not explicitly allowed.  Why is that?  To confuse matters worse, I took one of the IP addresses out of the list and the application could no longer send alerts but I could send messages thru telnet from that server.  

  10. Exchange says:


    It sounds like you are doing the right thing… so not sure why this is not working as expected… however as blog does not work very well for troubleshooting – I’d suggest either our newsgroups or a support case with us?

  11. Scott Landry says:

    This reminds me that if you’re testing to see if you’re an open relay by using one of the web based test tools, you might want to first read through this KB:

    The KB has not been updated for 2007 at this time, but Exchange 2007 will give you similar results on a couple of the tests (Exchange 2007 does not append a default domain by default, however).  In essence, failing a few of these tests does not necessarily mean that you’re an open relay.

  12. John Weathers says:

    I misspoke somewhat when describing my issue and it appears that maybe Exchange 2007 addresses the issue that I’m having.  It’s not a relaying issue so much as an authentication issue.  I can’t telnet to my server and send email to an outside organization, only to my own.  So I need to restrict Anonymous Access to prevent internal spoofing of email internally, but at the same time I need to allow Anoymous Access to external servers that can’t authenticate but need to relay alert messages through Exchange.  It seems that the connectors described above addresses that in 2007.  I suppose my question is, do I need to upgrade to Exchange 2007 to restrict Anonymous Access based on IP addresses?

  13. Scott Landry says:

    Correct, you are not having a relay issue.  Notice how the relay dialog is actually a slightly different screen than the authentication tab (the options are similar).  Relay is any destination domain.  Authentication is any connection, even if the destination is local.  Exchange 2007 does provide a little more granularity (the new permission you use to control this is ms-Exch-SMTP-Accept-Authoritative-Domain-Sender, see, but the fundamental SMTP problem is the same.  In this day and age, you have to accept anonymous connections to receive Internet mail, which does lead you open to the possibility of spoofing.  Part of the solution to the spoofing problem is SPF.  There’s also a really good earlier post on how you can configure border servers with two SMTP VS for 2003, one for internal submissions only, one for Internet submissions only:

  14. KarlB says:

    I spent several hours doing this without any success.  Finally, I manually restarted the Exchange Transport services and everything started working well.  I had all the settings correct but it still was not working.  Anyone who is having problems doing this should try restarting the service manually.  Perhaps a addition to the GUI to restart the service would be a nice touch.

  15. TMartin MS says:

    This was a life saver for me.  Thanks.

Comments are closed.