Terry Zink: Security Talk

Discussing Internet security in (mostly) plain English

Sender authentication Part 4: Forward Confirmed Reverse DNS

Sender authentication Part 4: Forward Confirmed Reverse DNS

  • Comments 4

Now that we have seen how email headers are inserted by the receiving machine upon receipt of an email, we need to go into a little bit on how mail servers convert IP addresses to host names and vice versa.

DNS stands for Domain Name System.  It converts a host name to its IP address.  Reverse DNS is the opposite, it converts an IP address to its host name.  It does this by examining the IP's PTR record.  From answers.com:


A PTR record or pointer record maps an IPv4 address to the canonical name for that host. Setting up a PTR record for a hostname in the in-addr.arpa domain that corresponds to an IP address implements reverse DNS lookup for that address. For example (at the time of writing), www.icann.net has the IP address 192.0.34.164, but a PTR record maps 164.34.0.192.in-addr.arpa to its canonical name, referrals.icann.org.


The converse of a PTR record is the A record, which maps a hostname to its 32-bit IP address.  So, A-records are used for DNS lookups, PTR records are used for reverse DNS lookups.

This brings us to Forward Confirmed Reverse DNS, or FCrDNS.  An IP is said to have FCrDNS if it has a forward DNS (name -> IP) and reverse DNS (IP -> name) that match.  First, an IP has a reverse DNS performed.  This returns a list of hostnames associated with that IP (the list could 0, 1 or more entries).  For each entry in that list (assume it is greater than or equal to 1), a regular DNS lookup is performed to see if the IP matchup matches the original IP address.  So, for example:

IP = 292.28.75.16

Reverse DNS = tzink-is-awesome.com, tzink-is-okay.com, tzink-is-not-that-great.com

A-record for tzink-is-awesome.com = 292.13.130.22 -- no match
A-record for tzink-is-okay.com = 292.21.14.15 -- no match
A-record for tzink-is-not-that-great.com = 292.28.75.16 -- match!

Since we matched the IP address in one of the domain's A-records that was found in the PTR, we are said to have FCrDNS for the IP. 

In spam filtering, if an IP has FCrDNS then we can be sure that the mail originated at the domain.  Spammers cannot normally forge this if they are sending from zombie computers.  Of course, if the ISP in question doesn't care about spammers then this form of authentication won't stop the mail.  On the other hand, if the ISP doesn't care about spam filtering and a spam analyst figures this out, this IP can very quickly be placed on a blocklist and accept no further mail from them until they clean up their act. 

You can see how DNS lookups can be useful in some circumstances.  At the very least, if the connecting IP says HELO, has an rDNS that matches the HELO, then the mail did indeed originate from that domain.  The DNS information can then be inserted into the received headers.  If the mail is spammy, the ISP can be complained to.  If the ISP ignores the spammee, they can be placed on a blacklist.  After all, it's proof that the IP is sending spam that indeed is originating from that host.

Leave a Comment
  • Please add 4 and 3 and type the answer here:
  • Post
  • PingBack from http://testsubdomain.netmoviehost.com/sender-authentication-part-4-forward-confirmed-reverse-dns/

  • I'm afraid I'm lost on this one, for at least two reasons.  It's been a while so I might be misremembering things that I did, but I think things happened this way:

    (1) I think the mail server put "HELO domain.name" in the envelope.  But there was no A-record for "domain.name", there was an MX-record and there were some other things that I don't remember.  There was an A-record for "dns.domain.name".  If I recall correctly, this would cause your algorithm to treat this as unconfirmed, but I think the combination of PTR and MX should be enough to make it confirmed.

    (2) If I misremembered the from envelope then the correct memory would be that the mail server put "HELO smtp.domain.name" in the envelope.  But there was no A-record for "smtp.domain.name" either, there was a CNAME-record for it.  As mentioned above the A-record was for "dns.domain.name".  The PTR-record pointed back to "dns.domain.name".  A forward inquiry for "smtp.domain.name" served by "dns.domain.name" would still match the IP address.  (The public address was the ISA server.)  But without the redundant PTR, you would have treated this as unconfirmed?

    Now I'm surprised to learn that there can be multiple PTR records for a single address; somehow I never noticed that.  So this could be used in producing a confirmed configuration even with your algorithm.

    But still, why wouldn't it be enough to do a forward MX check on the asserted domain name and see if that matches the known IP address?

  • There's a bit more involved in this including MX checks and CNAME-records, but for the sake of simplicity I omitted them.

  • We use linkproof load balancers.  We have 3 different ISP links and our MTA is setup to go down any one of them (multi-homed, kinda)  

    So if we connect to an MTA down 1.1.1.1 and it asks for a DNS reverse pointer record from its own DNS server, it might get 2.2.2.2 or 3.3.3.3 which are legit for us but still do not match.

    We run into multiple ISPs that block based just on this one check.  We loose a lot of outbound email that way.

    Is there something different we can do.

Page 1 of 1 (4 items)