Take the 2-minute tour ×

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?

share|improve this question
Want to say a big thank you to all who spent time posting answers and comments at length to help me. I would give more up votes if I could. Thanks. –  Jake Oct 2 '11 at 16:39
add comment

6 Answers

up vote 12 down vote accepted

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:

  1. Is the HELO name equal to the hostname (A record)?
  2. Is PTR of the IP equal to the A record of the hostname (hostname ==(PTR)==> IP ==(A)==> hostname)?
  3. Is the IP part of the provided SPF record?
  4. 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 =
  • PTR of = 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, ...
share|improve this answer
add comment

You have a generic PTR record now, but it still makes sense to modify that to your server's name.


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]*
share|improve this answer
Sorry, I think I am too dumb to understand. So what even if the forward and reverse DNS matches? It doesn't say anything about the sender or the sending MTA. I can set up mydomain.com A w.x.y.z and w.x.y.z PTR mydomain.com, they match and I can still send my email as me@another.com. –  Jake Oct 2 '11 at 9:42
specifically in my case, whatismyip.com tells me my IP is x.y.z.114 but my MX is "mail.domain.com IN A x.y.z.115". So I can set up an honest PTR for x.y.z.114 but it doesn't say anything about my MTA. –  Jake Oct 2 '11 at 9:45
It says the server admin had a clue how to set up properIP networks - which is different from "some bot on a home machine just being spamming over an end user ADSL connection". Even if you dont understand WHY - it is a condition for sending email, so JUST DO IT. –  TomTom Oct 2 '11 at 15:34
@TomTom I know I just have to do it. But I am still not convinced of the value of checking the PTR!! Must be missing some important link. –  Jake Oct 2 '11 at 16:37
I sent the reasoning AOL gives for checking this information. The value is that it tells the receiving server that the sender is established properly. Other than that, it's a best-practice. –  ewwhite Oct 2 '11 at 16:43
show 1 more comment

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.

share|improve this answer
But I can choose not to lie about my PTR and still format FROM as me@gmail.com. It doesn't stop me from sending as me@gmail.com does it? –  Jake Oct 2 '11 at 9:33
Which incidentlaly is the job of SPF. So why doesnt it simply just check the SPF for gmail.com and ignore the PTR altogether? –  Jake Oct 2 '11 at 9:53
Because as email goes, SPF is relatively new. –  bahamat Oct 2 '11 at 17:03
add comment

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.

share|improve this answer
That's what I don't understand too. In practice, my outgoing and incoming could both be different. Then why would the PTR resolution be any useful to prove that my email address/domain is not a fake one? –  Jake Sep 28 '11 at 7:50
It is not, as the domain in the email has nothing to do with the host name. Hosts may send tons of different domomains from one computer. The PTR just has to point back to the name the hosts identifies ITSELF as (not the email) - otherwise it is assumed you area dial up host and people dont want to deal with botnet spam from private computers via DSL, pretty much. PTS to Host name is basic network setup, not email. It is used to check you have your network under control. –  TomTom Oct 2 '11 at 4:29
add comment

Though not required, it is good practice to set up a PTR record for your sending mail server which matches the forward DNS for your sending mail server. This gives some indication that the sending server is a proper host of its domain (you can point a DNS record at any host), and that the admin isn't careless or clueless.

If you've begun having problems after you changed IPs, you may want to ensure that your mail server's IP is not on any RBLs (Realtime black lists). To check the most common lists, you can enter the mail server's IP into the RBL checker at anti-abuse.org.

share|improve this answer
But my public IP is .114 while my MX only listen on .115. The receipient server sees the connection coming from .114 (it does, right?) So technically, these 2 IPs can be different mail servers altogether. Doesn't this proves nothing about the authority of the sending mail server? Or do i have to set PTR for both 115 and 114? –  Jake Sep 29 '11 at 3:24
Your MX doesn't matter. Reverse DNS should be set up for the IP you send mail from. –  vezult Sep 29 '11 at 18:03
That means I need to have a hostname for .114? –  Jake Sep 30 '11 at 3:11
@jake yes. You can have multiple A records (or CNAMEs) for that IP, but the A record for the mail server should have a matching PTR record. Like I said in my answer, this isn't required, but some receiving mail servers put a lot of stock in it. –  vezult Oct 1 '11 at 22:05
add comment

All of these people are right. Whether you like or understand why, if you want to send email reliably, you will ensure the helo/A/PTR name is the same across the board. It does not matter what domain you are sending from, but the host sending email should have it's DNS house in order so to speak.

HELO name = the name the mail server reports itself as when greeting a remote smtp server:

[spork@hc1:/tmp]$ telnet example.com 25
Connected to example.com.
Escape character is '^]'.
220 example.com ESMTP Postfix <<<--- remote server
HELO someserver.jake.com <<<--- your server using it's HELO name  
250 example.com <<<--- remote server answering

A record = the published DNS name of your mail server (need not match the domain you are sending email from). example: jake.com =

PTR record = should match the A record of the server. example: = jake.com

You'll go a long way towards better deliverability by making sure those three things match.

Bear in mind a good deal of spam filtering relies on assessing the general shadiness of the host that's connecting to an mxer. Not following best common practice is a pretty big red flag. If a sysadmin can't get DNS right, what else might be wrong with the server about to send you email? There's enough critical mass these days that it's really not worth fighting what's now a BCP, even if it doesn't quite make sense to you.

As to rejecting email from IPs with "generic" PTRs, that's not uncommon either, even if your triplet of DNS-related configs mentioned above all agree. Again, the remote host is looking at this generic DNS and assuming that generic means "random home user", which in turn means you're more likely talking to a bot than an actual mail server.

share|improve this answer
add comment

Your Answer


