Help me understand (and fix) why Sender ID filtering blocks some emails and not others.

SINC_dmack used Ask the Experts™
We manage multiple Exchange '10 and '13 servers for various clients.  These are all small (50 users or less) sites, each with a single Exchange server.  A problem that's been cropping up recently is that some servers have problems emailing other servers, and the NDRs indicate: #550 5.7.1 Sender ID (PRA) Not Permitted ##

It's clearly Sender ID filtering that's blocking the emails.  Further down in the NDR, I see the following:

Received: from localservername.localdomain.local ([]) by
 localservername.localdomain.local ([]) with mapi id
 14.02.0387.000; Wed, 13 Aug 2014 08:05:49 -0500

It appears that the sending server is reporting its local FQDN and IP address, rather than its internet FQDN and IP address.  

Each of the clients have the following internet domain control panel DNS settings:
MX -
SPF - v=spf1 a mx -all

The especially odd thing is that this is sporadic.  For example, if sends 5 emails to, one or two of them might be NDRed and the rest might go through.   The emails that go through indicate:

Received: from ([public IP address]) by ([public IP address]) with mapi id
 14.02.0387.000; Wed, 13 Aug 2014 08:05:49 -0500

Apparently, the sending mail server SOMETIMES reports its internet FQDN and IP address, and other times it reports its internal FQDN and IP address.  

(What is additionally frustrating is that Sender ID filtering isn't catching obvious fakes--for example, might receive spam from, when the email tags indicate that the email came from a server IP address that's clearly not associated with that domain in the SPF record.  That, however is a side issue--legitimate emails being blocked as spam is much worse than a few extra spam making it past the filter.)

This problem seems to have arisen over the past few weeks or so, but searching Google for " #550 5.7.1 Sender ID (PRA) Not Permitted ##" and limiting it to the last year hasn't turned up anything helpful.  

My primary question is either why Exchange is sometimes reporting its internal FQDN and IP address, or why Sender ID sometimes NDRs emails from a particular server, but other times will allow them with no problems?  And, more importantly, how to fix that?

Secondary is why does Sender ID sometimes allow emails that should blatantly fail?
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Not sure I have an answer. It depends on whether when you say

"Apparently, the sending mail server SOMETIMES reports its internet FQDN and IP address, and other times it reports its internal FQDN and IP address.  "

you are talking about more than one server doing this, or all of them. The reason I ask is that the name a server responds with is configured at the send connector. There is an input field that asks "Specify the FQDN this connector will provide in response to HELO or EHLO". If it's blank, the server will just respond with it's internal DNS name.

If you are saying that some servers respond with 'localservername.localdomain.local', while others respond with '', then you need to check the configuration of all the send connectors.

If you are saying that any single server is randomly responding with either value, then I've no idea what's happening.
Svet PaperovIT Manager

A missing PRT record for the sending host could cause this kind of NDR errors.

PRT DNS records a generally handled by the last ISP because he owns the public IP addresses.

However, if you are using a smart host for filtering the outgoing mail, like Microsoft Exchange Online Protection for example, configuring such PRT it not necessary  – it’s handled by the last sending host.


Both of the servers that were occasionally being blocked by Sender ID filtering had multiple send connectors, and in both cases, at least one send connector had the server's local FQDN as the "respond to EHLO".  I've since removed all of the send connectors except one, and ensured that the sole send connector had the internet FQDN instead of the local FQDN.  I'm going to give it a few days of testing to confirm that this has resolved the issue, but it seems reasonably likely that the send connector misconfiguration was the issue.  Thanks for the suggestion, Lee.
Should you be charging more for IT Services?

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!


Svet, could you elaborate about your comments regarding PTR records?  (I assume you meant PTR, not PRT.)  As far as I know, PTR records are primarily used for reverse DNS, and in this case the ISP for each server has a reverse DNS entry that resolves to


Apparently removing the extra send connectors didn't help--one of the clients just received the following NDR:

Generating server: client'slocalserver.domain.local #550 5.7.1 Sender ID (PRA) Not Permitted ##

Received: from client'slocalserver.domain.local ([]) by
 client'slocalserver.domain.local ([]) with mapi id
 14.02.0387.000; Thu, 21 Aug 2014 10:52:59 -0500

The sending server is still reporting its local name and its local IP address when attempting to send to the recipient.


I just had it happen again--this time the email was from a totally different server to a totally different server.  Same error syntax as my post above this one.
I think I may have fixed it.  On the server that NDRed today (my second post up from this one), last night I had gone to:
Exchange Management Console -> Organization Configuration -> Hub Transport -> Send Connectors -> Properties of Send Connector ->Network tab, and I had unchecked "use the external DNS lookup settings on the transport server".  
Apparently that setting affects the send AND receive connectors, because with it unchecked, I started getting the NDRs as listed above, with the receiving mail server reporting that the sending mail server was server.localdomain.local, not  

I rechecked that box on the server that NDRed today, and now emails are delivered as expected, and the mail tag reports that the emails were sent from via the public IP address.  I've logged into the other servers that were giving the error and they all had that box unchecked, so I've checked it on them as well.  I'll follow up and confirm if the problem is truly fixed.

I am unclear as to why this setting, on a send connector for the sending server, affects how the receiving server perceives the incoming emails.  Perhaps when the sending server sends and looks to external DNS, it resolves as the external host name and IP address and appends those to the outgoing email.  It seems counter-intuitive, but my empirical results suggest that's what's happening.
I have no idea at all why that checkbox should have an effect on the receive connector. The sending server should just announce it's name regardless.

You might do some telnet tests. That way you can be 100% sure what name you supply with the HELO, and you can see if it gets accepted, or changed and rejected.
Svet PaperovIT Manager

That means you have a misconfigured local DNS server. Configuring a split DNS (as in the case where the internal name space is different from the external one, like .local vs .com) could be tricky. Using External DNS Lookups helps in such cases. However, this should not have effect on the Receive connector.


Hi Lee, when I run an SMTP test using, the server replies with the following header:
220 Microsoft ESMTP MAIL Service ready at Thu, 28 Aug 2014 16:15:22 -0500
I've run this test a half dozen times over the last few weeks and it's returned the same result every time.  Is that sufficient to prove that the server is reporting its name properly, or did you have some other tests in mind?

Hi Svet, yes, we have split DNS configured.  Do you have any recommendation as to what you think is misconfigured?  The DNS configuration on the two problematic servers is the same as we've used at many other clients which are not experiencing this issue--a .local for internal and a .com for external.
I think that's a sufficient test. I can't imagine that it would respond with a variety of names. What I was specifically referring to was a telnet test, i.e. from the command prompt

telnet 25

and see how it replies. You'd need to install the telnet component these days - i don't think it's there on a standard windows install. But the results should be the same.


Unchecking "use the external DNS lookup settings on the transport server" appears to have fixed the problem.  Lee's suggestions about testing the mail server's response were things I'd already tried but may be helpful to other users who are having similar problems.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial