Does a PTR record prove anything about the sender's email domain?
My outgoing mail server has problems reaching some recipients. This happened after we changed ISP for our dedicated IP address. I think it might be due to PTR records, but I cannot be sure.
My assigned IP address is x.y.z.112/29. When I do an nslookup on x.y.z.114 (WAN-facing public IP address), it gives 114.x-y-z.myisp.com. Am I right to say that there is indeed a PTR record set for my IP address, only that it does not match my MX mail.mycompany.com. (x.y.z.115)?**
I also learned that the extent to which mail servers check PTR records varies. Some only check that a reverse DNS lookup (rDNS) hostname exist while some go all the way ensuring that the MX and the rDNS hostname matches. So what should I do? Should I still tell my ISP to set PTR records for mail.mycompany.com?
So now my PTR record resolves to 114.x-y-z.myisp.com whose A resolves to the same IP address as the PTR record. So what does this prove about the sender's email address?
To answer your new question first: No, PTRs don't tell you anything about the sender's domain. See below for the explanation.
Now back to your original question:
Receiving mail servers check none, one, many or all of the following:
- Is the HELO name equal to the hostname (A record)?
- Is PTR of the IP equal to the A record of the hostname (hostname ==(PTR)==> IP ==(A)==> hostname)?
- Is the IP part of the provided SPF record?
- Does the sender's domain have at least one MX record? Which doesn't have to match IP/hostname.
Receiving mail servers that check if the sending server is also the MX server are badly configured and should be eliminated from the Internet.
Edit: The PTR does absolutely prove nothing about the email domain. It is never meant to prove this. There are thousands of domains hosted at Google, Amazon, AOL and others. But none of them match the hostname or PTR of Google, Amazon, AOL and others. They all have the servernames of the providers. And there is nothing bad about that.
The PTR only proves the identity of the server but not the identity of the hosted domains. Point.
2nd Edit: A good example for a working environment would be
- HELO = mail.example.com
- hostname = mail.example.com
- A record of mail.example.com = 172.20.25.25
- PTR of 172.20.25.25 = mail.example.com
- Domains hosted on this server/system = example.com, *.example.com, *.example.net, *.example.org, mycompany.invalid and many many more.
- SPF records of hosted domains (optionally) = v=spf1 a:mail.example.com -all
- MX record of hosted domains can be anything. E.g. mx1.example.com, mx2.example.com, mailfilter.anti-spam-corp.invalid, mail.example.com, postini.google.invalid, ...
You have a generic PTR record now, but it still makes sense to modify that to your server's name.
Why?
You are correct in that you do have a PTR record assigned, and many mail systems today reject email from sources without reverse PTR records. One condition you've missed is that a good number of mail hosts/spam filters tend to reject traffic from sending servers whose reverse PTR records are "too generic". That includes hosts where the reverse PTR is of the in-addr.arpa... format or contains an IP address in the name. Yours is the latter case in that 114.x-y-z.myisp.com is just a placeholder set by your ISP. You don't need to have your reverse match your company name (although you may as well make it match if you can). It just needs to be a fully-qualified domain name (FQDN).
From AOL's Postmaster guidelines:
Reverse DNS is a way of associating an IP address with its hostname. The reverse DNS identifier is contained in the PTR portion of the IP Zone File. The IP Zone File contains all the different ways that your IP and domain name can be associated; each association serves a different need.
- AOL requires that all connecting Mail Transfer Agents have established reverse DNS, regardless of whether it matches the domain.
- Reverse DNS must be in the form of a fully-qualified domain name. Reverse DNS containing in-addr.arpa are not acceptable, as these are merely placeholders for a valid PTR record.
- Reverse DNS consisting of IP addresses are also not acceptable, as they do not correctly establish the relationship between an IP address and its associated domain.
- Reverse DNS that may be similar to dynamic IP space (containing pool, dhcp, dyn, etc.) may be treated as suspect, and should therefore should be changed to reflect a fully-qualified domain name with standard MTA reverse DNS. [Example: mail.aol.com]*
It proves that you are who you say you are.
Here's the scenario. Let's say that I'm trying to send spam pretending to be Gmail. I'm not Gmail, I'm just some lowlife with a VPS, with control of my own DNS.
I can set the PTR of any IP I own to mail.google.com. But doing an A look up on mail.google.com will not show my IP address, it will show Google's IPs. The mismatch means you're lying.
Update: Some history and clarification.
You need to know that none of this is guaranteed to work.
E-mail was invented in 1961. This is shortly after it was estimated that the entire world only needed five computers.
E-mail's popularity exploded in the early 80's with the introduction of the TCP/IP stack to UNIX. Back then every host on the Internet was either U.S. Government, a university, or a very large corporation. Back then everybody was pretty much friends. The first worm wasn't created until 1988. Nobody thought anybody would ever do anything malicious because it was an extremely (by today's standards) small community and just about everybody knew everybody.
There were a lot of protocols created that we, today, are embarrassed about. Among them are ftp, telnet, rsh, rlogin, nfs and smtp. SMTP, as was common with several protocols, was created with no security whatsoever. It was assumed that whatever you said was the truth, because why would anybody lie?
One day some enterprising schmuck decided to e-mail a bunch of people who didn't want it and spam was born. Since then we have been fighting an ever losing battle against spam.
The spam problem is so severe that any and all tactics that will reduce spam by even the slightest fraction of a percent means that the load on our mail servers will drop significantly. I ran a check on my mail server once and the messages it was processing was over 99% spam.
Administrators are desperate for anything that will help to even the slightest degree. Anything that anybody heard helped "that one time" becomes standard practice in fighting spam. Not that any one tactic is particularly effective. But these days we put as many restrictions on mail relay as possible in the hope to gain some ground in the fight against spam.
There's no spam panacea. But even a very basic check such as this might mean the difference in millions fewer messages sent.
You've got it just about right. The PTR record for your mail server's IP address doesn't match the host name that your email server identifies itself as. You would do well to have the ISP change the PTR record to match the outgoing FQDN of your email server.
The part that's not quite right is where receiving servers check that the PTR and the MX records match, because that's a stupid thing to do. The MX record designates where email goes TO, not where it comes FROM. An SPF record designates where email comes FROM. Any email server checking that the PTR record matches the MX record before accepting email from that server is doing it wrong.