571 Delivery not authorized

I have seen several questions and answers regarding this issue, however my situation is slightly different (I believe).

We have several emails in queue on our Exchange 2007 server that have the message:

451 4.4.0 Primary target IP address responded with: "571 Delivery not authorized, message refused"

I have checked and we are not on any blacklists, however we use Postini, so our MX records have four postini servers before our email server. I noticed that many folks were fixed by setting up reverse DNS entries via PTR records - however I think our Postini prevents me from pointing directly to my email server.

Is there something else I should be doing to facilitate delivery of these messages?
FEI WebmasterAsked:
Who is Participating?
 
Alan HardistyConnect With a Mentor Co-OwnerCommented:
Check that Reverse DNS is configured properly on your fixed IP Address (the FQDN on your IP should resolve in DNS to your IP Address).

Check the FQDN on your SEND Connector - this should also resolve in DNS to your fixed IP Address.

Using Postini for inbound mail filtering is not a problem - your problem is more likely lack of Reverse DNS or incorrect FQDN / FQDN not resolving in DNS abck to your fixed IP Address.

My article might help you understand this:

http://www.experts-exchange.com/Software/Server_Software/Email_Servers/A_2427-Problems-sending-mail-to-one-or-more-external-domains.html
0
 
FEI WebmasterAuthor Commented:
OK - so if I understand you correctly:

I have a fixed IP Address (65.51.255.xx) for my email server (email.domain.org). This is the FQDN on the send connector as well as my DNS records. I will contact my ISP and ask them for a PTR record and supply them with those two pieces of information.

Correct?
0
 
Alan HardistyCo-OwnerCommented:
Yes - your current reverse DNS record is 4133ff63.cst.lightpath.net - which is completely wrong by the looks of it.

Correct that by calling your ISP and asking them to setup Reverse DNS as email.domain.org and you should be much happier.

Alan
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
FEI WebmasterAuthor Commented:
Alan,

I contacted OLP and am in the process of changing that. BTW - I went to the dnsgoodies website you have in the above link, and when I put in email.domain.org in the reverse dns box I get the following results:

Server: 208.82.183.131
Address: 208.82.183.131#53

Non-authoritative answer:
Name: email.domain.org
Address: 65.51.255.xx

I'm not sure that this response would tell me I have a problem - where did you do your lookup?
0
 
FEI WebmasterAuthor Commented:
LOL - sorry admin - you're going to have to do it again ...
0
 
Alan HardistyCo-OwnerCommented:
From a command prompt!

C:\Users\ahardist>nslookup email.yourdomainname.org
Server:  UnKnown
Address:  10.0.2.1

Non-authoritative answer:
Name:    email.yourdomainname.org
Address:  65.51.255.xx


C:\Users\ahardist>nslookup 65.51.255.xx
Server:  UnKnown
Address:  10.0.2.1

Name:    4133ff63.cst.lightpath.net
Address:  65.51.255.xx
0
 
FEI WebmasterAuthor Commented:
yep - sure enough.

OK - waiting to hear back from OLP and then will award points.

BTW - your document was VERY helpful.
0
 
Alan HardistyCo-OwnerCommented:
If you send mail from the 65.51.255.xx - then the Reverse DNS record is all wrong.
0
 
Alan HardistyCo-OwnerCommented:
If you liked my article - please vote for it : )
0
 
FEI WebmasterAuthor Commented:
We do and it is.

I'm surprised we have not had more issues.
0
 
Alan HardistyCo-OwnerCommented:
It all depends on the Anti-Spam software / device at the receiving end.  Some are very fussy - some are not.

Thanks for the vote : )
0
 
Hypercat (Deb)Commented:
That odd PTR record shouldn't be causing a problem at thisp oint, since it has a metric of 50 and you have 4 other MX records with lower metrics that point to Postini servers.  All of those Postini servers have valid and accurate PTR records, so there's no problem there.  A 5.7.1 error is caused by a misconfiguration on the receiving side, not on the sending side. Unless you are getting back an actual NDR stating that the message was rejected because it is being identified as spam, you're not on any block lists, and you said you had checked anyway.

If you re-send the message, or if you send another message to the same domain, does it get through? If you send an email using a direct telnet connection to the receiving server, does it get through?
0
 
Alan HardistyCo-OwnerCommented:
Postini will be used for inbound mail - not necessarily outbound mail too and the reverse DNS record would be a problem if mail is sent directly not via Postini.
0
 
FEI WebmasterAuthor Commented:
Resending fails and sending to other email addresses on the domain fails with the same errors.

I am not familiar enough with Telnet to send an email, I know how to connect to the remote server but not send anything.
0
 
Hypercat (Deb)Commented:
Also, I noticed that you don't have an SPF record. Regardless of the absence or presence of a PTR record, if you have an SPF record, and if the email is in fact being rejected as spam, having an SPF record will help resolve the issue.
0
 
Alan HardistyCo-OwnerCommented:
msteele999 - do you send mail via Postini or just receive it via them?
0
 
FEI WebmasterAuthor Commented:
We also see other variations of undeliverable messages occasionally that are similar:

421 Syntax errors
0
 
FEI WebmasterAuthor Commented:
We use Postini for INBOUND filtering only. Outbound email goes directly out from our server.
0
 
Alan HardistyCo-OwnerCommented:
: ) - Then your Reverse DNS will be causing you problems as I have advised.
0
 
FEI WebmasterAuthor Commented:
hypercat - thanks.

I have access via netsol console to add SPF records. I will investigate. Is there a format that I should use?
0
 
Hypercat (Deb)Commented:
Here's a link to a website which has lots of SPF info, including a tool to walk you through configuring your record. If you don't use Postini to send email, just receive, then they don't have to be listed on your SPF record:

http://www.openspf.org/
0
 
Hypercat (Deb)Commented:
OOPS! Sorry, that website appears to be down and has been down for awhile - I haven't checked in on it for months. Here's a sample (very simple) SPF record:

"v=spf1 mx ~all"

This specifies the record type as "SPF," and the qualifying mechanism as "MX" meaning that any MX record in the domain's zone is validated. IOW, any email coming from servers with MX records in the domain's public zone should be accepted.
0
 
FEI WebmasterAuthor Commented:
Thank you - I added the SPF record as well. Now just waiting in ISP tech support to verify the RDNS PTR record.
0
 
FEI WebmasterAuthor Commented:
OK - the SPF is in and the PTR record is in as well. I suppose I will need to allow time for it to propagate thru the net before I see those queue's empty out?
0
 
FEI WebmasterAuthor Commented:
OK - the good news is that it looks like the 571 errors have cleared the queue.

Now, however, I have a lot of the following two errors:

421 Syntax Error - attempted failover to alternate host, but that did not succeed.

And

421 Unable to connect - attempted failover to alternate host, but that did not succeed.

Are these errors my issues or the remote servers?
0
 
Alan HardistyCo-OwnerCommented:
It's either a DNS issue your side or problems at the remote side.

What are some of the domains?
0
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.

All Courses

From novice to tech pro — start learning today.