Basic DNS: PTR records and why you care
You may have come to this because you've been told that you need a PTR record to avoid rejections from sites like AOL and others.
You may have thought that you can add your own PTR record. You usually cannot.
A PTR record (sometimes called a "host PTR record") is what lets someone do a "reverse" DNS lookup - that is, they have your IP address and want to know what your host/domain is. At any Unix/Linux command line, you can use "dig -x" to do a reverse lookup:
bash-2.05a$ dig -x 188.8.131.52 ; <<>> DiG 9.2.1 <<>> -x 184.108.40.206 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38101 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;220.127.116.11.in-addr.arpa. IN PTR ;; ANSWER SECTION: 18.104.22.168.in-addr.arpa. 1762 IN PTR pcunix.com. ;; Query time: 49 msec ;; SERVER: 10.1.36.238#53(10.1.36.238) ;; WHEN: Fri Jul 2 11:03:29 2004 ;; MSG SIZE rcvd: 67
If you are totally confused by DNS, I recommend Take Control of Your Domain Names, a $10.00 PDF E-Book that demystifies all of this.
Not every IP address has a corresponding PTR record. In fact, if you took a random sampling of addresses your firewall blocked because they were up to no good, you'd probably find most have no PTR record - a dig -x gets you no information. That's also apt to be true for mail spammers, or their PTR doesn't match up: if you do a dig -x on their IP you get a result, but if you look up that result you might not get the same IP you started with.
That's why PTR records have become important. Originally, PTR records were just intended as a convenience, and perhaps as a way to be neat and complete. There still are no requirements that you have a PTR record or that it be accurate, but because of the abuse of the internet by spammers, certain conventions have grown up. For example, you may not be able to send email to some sites if you don't have a valid PTR record, or if your pointer is "generic":
dig -x 22.214.171.124 ; <<>> DiG 9.2.1 <<>> -x 126.96.36.199 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55565 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;188.8.131.52.in-addr.arpa. IN PTR ;; ANSWER SECTION: 184.108.40.206.in-addr.arpa. 3570 IN PTR h00c0f06bacf1.ne.client2.attbi.com. ;; Query time: 2 msec ;; SERVER: 10.1.36.238#53(10.1.36.238) ;; WHEN: Fri Jul 2 11:12:45 2004 ;; MSG SIZE rcvd: 90
Typically, the reason you get refused is because the "generic" pointer doesn't have an MX (mail exchange record):
This is technically inaccurate if your inbound and outbound servers are different. It's the outbound (the one that is connecting to other machines) - that needs the reverse lookup. For most small businesses, these are the same. It's perhaps more accurate to say (as a commenter did below) the PTR record should match the SMTP response on port 25 when the receiving server sends back a verification check.. However, it is usually only necessary that the record exist and not contain "in-addr.arpa". See the comments below.
dig h00c0f06bacf1.ne.client2.attbi.com MX ; <<>> DiG 9.2.1 <<>> h00c0f06bacf1.ne.client2.attbi.com MX ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32826 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;h00c0f06bacf1.ne.client2.attbi.com. IN MX ;; Query time: 292 msec ;; SERVER: 10.1.36.238#53(10.1.36.238) ;; WHEN: Fri Jul 2 11:14:01 2004 ;; MSG SIZE rcvd: 52
How do you get a PTR record? You might think that this is done by your domain registrar - after all, they point your domain to an IP address. Or you might think whoever handles your DNS would do this. But the PTR record isn't up to them, it's up to the ISP that "owns" the IP block it came from. They are the ones who need to create the PTR record. In some cases, that may be the same folks who handle your DNS, but the point is that it is not necessarily so: you may have no control over this whatsoever. See RFC 2317 and Avoid RFC 2317 style delegation of 'in-addr.arpa.' also.
If you don't have a PTR record, and can't get one (for example because you have a dynamic address), you will want to send outgoing email through a server that does. Your INCOMING server doesn't need a PTR record - you can use a dynamically assigned IP address for a mail server as long as you have some way of updating your MX record when your IP changes. And it isn't that you can't send SMTP mail out from such a server (although some ISP's do block outgoing SMTP to any but their own server); it's just that some recipients may block you because you don't have that PTR record or because it doesn't match up wth an MX record for you.
Usually, you'll use your ISP's SMTP server as your "delegate" server - that can be done at your internal mail server or at the client machines ("Outgoing SMTP Server"). However, assuming that you aren't blocked for outgoing SMTP, you can use any server that "likes" you - that is, any server that will allow your IP address to relay mail through it. That's probably going to be another server under your control, or someone who knows you - there are few servers left that will let just anyone use them as a mail relay.
There are two other DNS records that can be helpful in getting your mail through: Caller-ID and SPF. These are records you can add to your own dNS and they help prevent people masquerading as your mail server. Servers that check these records (not all do) know when it really is your server that sent the mail; it is therefore less likely to be refused. See Kerio Spam Control: Caller-ID and SPF for more details.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.