BLOG
PTR Records
PTR records are easy to over look and they have a significant impact on your ability to deliver mail without them. Some ISP and mailbox providers will reject mail from IP addresses that do not have a PTR record created. PTR records are a type of DNS record that resolves an IP address to a fully qualified domain name or FQDN. The PTR records are also called Reverse DNS records. If you are sending mail on a shared IP address, you’ll want to check to make sure the PTR record is setup, however you most likely will not be able to change it. If you are on a dedicated IP address or using a hosting provider like Rackspace or Amazon AWS, you’ll want to create or change the PTR records to reflect your domain name.
We usually think about DNS records resolving a domain name such as www.wordtothewise.com to an IP address. A query for www.wordtothewise.com is sent to a DNS server and the server checks for a matching record and returns the IP address of 184.105.179.167. The A record for www is stored within the zone file for wordtothewise.com. PTR records are not stored within your domain zonefile, they are stored in a zonefile usually managed by your service provider or network provider.
Some service providers provide an interface where you can create the PTR record yourself, others require you to submit a support request to create or change the PTR record.
If you know what IP address you are sending mail from, use our web based DNS tool to check if you have a PTR record created.
http://tools.wordtothewise.com/dns
Checking for a PTR record for 184.105.179.167 returns
167.128-25.179.105.184.in-addr.arpa 3600 PTR webprod.wordtothewise.com.
If you received Response: NXDOMAIN (There is no record of any type for x.x.x.x.in-addr.arpa), this means you’re missing the PTR record and need to create one ASAP if you are sending mail from that IP address!
Old article, but this keeps coming up for our new Oracle Email Delivery service.
We historically (from sendlabs/dyn days) have used semi generic reverse on our IPs for shared environments. For example if you dig 216.146.33.200, you’ll see that the reverse is a naming convention “mtaout-200-ewr.sendlabs.com.” Most places do not have issues, but the small time providers will kickback a “this is a generic PTR record”.
As an ESP, there’s not a lot we can do here if it’s being used by many sending domains. This has been a challenge to our new infrastructure (Example: 162.88.24.29) where we’re sending a lot of mail to these mentioned small providers, where they’re outright blocking mail.
Is there any thoughts out there as a way around this (apart from obviously putting all on their own dedicated IP and customizing reverse)
“Generic rDNS” has never been clearly defined. And there are lots of folks like you that have very good reasons not to do more custom rDNS. I’m not sure what the overall right answers is. Personally I think including “mtaout” makes it clear this os intentionally an outgoing mail server. Others get upset if they ever see even a piece of IP address in there. It’s as much a philosophical problem as a technical one, and I don’t necessarily know how to resolve that.
FWIW, rDNS is part of standard 1 and mandated in RFC1123/1124. The requirement is that it works, and matches. I think most business providers will verify forward and reverse DNS because it should always be correct. Some will block it outright if its missing or incorrect, others will just tag it or mark it down. This is the only requirement for reverse DNS. You are not required to have it match the sender’s domain, but there are implied requirements that the HELO/EHLO should match the DNS assignment.
Your rDNS is fine however…
Hostname from IP 216.146.33.200 is mtaout-200-ewr.sendlabs.com
Hostname mtaout-200-ewr.sendlabs.com resolved to 216.146.33.200
So there’s no reason for anyone to block it or mark it down IMO and we certainly wouldn’t penalise it. If I’m missing the question completely then please elaborate?