Link to home
Start Free TrialLog in
Avatar of awucrail
awucrail

asked on

550-'ERROR: No or mismatched reverse DNS (PTR) entries for

Hi Guys,

it might have someone asked same question. but one of our user has  problem for sending Email to a domain.
mx-laughing.atl.sa.earthlink.net gave this error:
ERROR: No or mismatched reverse DNS (PTR) entries for 76.81.57.130

the IP is our gateway IP which has setup PTR records. all records link to domain names. my understanding is the recipient server will check the PTR for correct domain.
I cannot figure it out what problem it is.

I need help.

thank you,
Avatar of James Bunch
James Bunch
Flag of United States of America image

Do you have the associated A record to accommodate the PTR record?
Avatar of awucrail
awucrail

ASKER

the PTR record associated domains. is that need A record?
Yes tyipically. Just a quick reference on google associates this as well.

PTR records are used for the Reverse DNS (Domain Name System) lookup. Using the IP address you can get the associated domain/hostname. An A record should exist for every PTR record. The usage of a reverse DNS setup for a mail server is a good solution.
setup A record like mail.domain.com    76.81.57.130, and ask the ISP to put reverse on their DNS table, right?
The problem I see (if that's the actual IP), is that you have multiple PTR records for the single IP.  The names in each of those PTR records does not resolve back to the same IP (only one does).  I'm not certain about how different recipient servers would handle the situation when there are multiple PTR records, but I think it could pick one using round-robin, and then it will check for an A record with the matching name, and if the IP in the A record doesn't point back to the original IP of the PTR record then you have a problem.  This check is known as forward-confirmed reverse DNS (fcrDNS).

So my suggestion is either to remove all but one PTR record and make sure you have fcrDNS.  Or all names that are referenced by PTR records for that IP should point back at the same IP.
or setup A record for the domain.com 76.81.57.130? Since the ISP has setup the Domains  associated the IP?
Addendum to my previous post:
It's typically best to only have a single PTR, and the name used by it and the A record should match the SMTP banner used to send mail.
The A records are on your zones, not the ISP. You can use, which I assume is something like Footech did, MXtoolbox or some other sniffing site for DNS records etc to find out the locations of the PTR in correlation with the A records. Like Footech suggested, we can't have multiple pointing to different IP addresses without the cluster of servers to work together and spread that load evenly. Otherwise 1/5 will work properly etc.
there are four domains that handled by our exchange server. the question is recipient servers will check the domain match up or not between gateway PTR and sending Email domain?
The recipient doesn't really care whether the domain name referenced in a PTR record for the IP it received an email from matches the domain name in the from address.
is there any solutions? Since the IP PTR is only associated with domains. assuming don't remove the PTR records, just add A record with a host name and setup a PTR point for the host, should it work?
I already gave you my recommended solutions in #a42394953.
You're A + PTR records are correct...

lxd: net11-ubuntu-zesty-php72 # dig +short a mx-laughing.atl.sa.earthlink.net
207.69.195.179
lxd: net11-ubuntu-zesty-php72 # dig +short ptr 179.195.69.207.in-addr.arpa
mx-laughing.atl.sa.earthlink.net.

Open in new window


Never guess. Always use dig + verify your setups are correct.

I've been tooling mail systems since 1994 + I only consider a config correct if testing tools show config correctness.
Unsure where your 76.81.57.130 record comes in. This doesn't show up in your config anywhere.

Also, just because you've setup your PTR records correctly doesn't mean you'll have any deliverability.

PTR record correctness is just one step of many + you'll have to manage your return loop every day (answer any SMTP return codes which require action).

Your far better off using a relay system like MailGun.

If you have months to warm up your own native MTA (domain + IP), then post your actual domain name from which you'll be sending email + people can check your entire setup for deliverability issues.

My comments in https://www.experts-exchange.com/questions/29036679/AWS-EC2-mail-server.html cover the starting steps to producing high deliverability.
@David - mx-laughing.atl.sa.earthlink.net is the recipient server, not the sender.  You're looking at the wrong end.
thank you so much guys.
I am still think  the PTRs on the IP 76.81.57.130 are correct.  but recipient server reject the Email from our mail server.
show the error :
mx-herron.atl.sa.earthlink.net gave this error:
ERROR: No or mismatched reverse DNS (PTR) entries for 76.81.57.130
is there recipient server only check  host name mail.domain.com?
If 76.81.57.130 is the IP that you're sending email from, then the situation is as I described.
I'll repeat.  It's typically best to only have a single PTR.  You should have an A record (and only one) with the same name as used in the PTR, and that A record should resolve to the same IP as the PTR.  The name in both the PTR and the A record should match the SMTP banner used to send mail.
Thanks All. the problem has been resolved. for this case, I just add a host record to point the IP. Since the IP's PTR only set four domains without A record . Sending Email to Earthlink won't work.
I had a little trouble understanding your last post.  But checking your existing records for your IP I see you followed my advice in #a42396099.

As such, I recommend that you accept it as the answer to close this question.  Thanks!
This question needs an answer!
Become an EE member today
7 DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.