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

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?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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 ManagerCommented:
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.
SINC_dmackAuthor Commented:
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.
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

SINC_dmackAuthor Commented:
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
SINC_dmackAuthor Commented:
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.
SINC_dmackAuthor Commented:
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.
SINC_dmackAuthor Commented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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 ManagerCommented:
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.
SINC_dmackAuthor Commented:
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.
SINC_dmackAuthor Commented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.