Full-circle DNS checks have been around a long time, but they are growing in popularity as an anti-spam method. This anti-spam method is another step to help prove the identity of a mail server. If you're mail server is sending to another mail server that uses this anti-spam method (like AOL.com or K12USA), you want to make sure that your full-circle DNS is correct.
K12USA WebMailPRO, K12USA SchoolBits, SpamTrakker, all mail servers.
FCrDNS, or forward-confirmed reverse DNS, or full-circle reverse DNS, is situation where a given IP address has forward (name-to-address) and reverse (address-to-name) DNS entries that match each other. The process of checking this is as follows (outlined in RFC 1912, especially section 2.1):
- First a reverse DNS lookup (PTR query) is performed on the IP address, which returns a list of zero or more PTR records.
- For each domain name returned in the PTR query results, a regular 'forward' DNS lookup (type A query) is then performed on that domain name.
- Any A or AAAA record returned by the query is then compared against the original IP address, and if there is a match, then the FCrDNS check passes.
Example:
DNS query type PTR on 1.2.3.4 ---> returns PTR-record="hostname.example.com" (1 result)
DNS query type A on "hostname.example.com" ---> returns A-record=1.2.3.4 - matches original ip address, therefore check passes
A FCrDNS verification can create a weak form of authentication that there is a valid relationship between the owner of a domain name and the owner of the network that has been given an IP address. While weak, this authentication is strong enough that it can be used for whitelisting purposes because spammers and phishers can not usually by-pass this verification when they use zombie computers to forge the domains. It is considered good practice in general that all rDNS should be forward confirmed. This is especially true for the IP addresses used by email servers to help prevent outgoing email from being wrongly rejected as spam.
A FCrDNS verification can also establish that the network owner and the domain owner both have at least a very basic understanding of the RFCs and can correctly configure things. That is, they have followed the instructions in RFC 1033 on "Adding a host". There is a statistical correlation between machines that send spam and machines that fail FCrDNS checks, but correlation does not imply causation and many network owners simply can not configure the rDNS because their upstream providers either can't or won't delegate the rDNS.
Common DNS misconfigurations are outlined in RFC 1912, of particular note is section 2.1 that states, under the heading "Inconsistent, Missing or Bad Data", "Make sure your PTR and A records match." . Those ISPs that will not or cannot configure reverse DNS will generate problems for hosts on their networks, by virtue of RFCs being contravened when communicating with hosts that do follow the RFC guidelines. From a technical perspective reverse DNS is trivial to implement correctly and there is no reason not to implement it for hosts providing regular internet services.
A good site to use to check your records, as well as any blacklist entries, is http://multirbl.valli.org/ .