Forward-confirmed reverse DNS
|This article does not cite any references or sources. (March 2014)|
Forward-confirmed reverse DNS (FCrDNS), also known as full-circle reverse DNS, double-reverse DNS, or iprev, is a networking parameter configuration in which a given IP address has both forward (name-to-address) and reverse (address-to-name) Domain Name System (DNS) entries that match each other. This is the standard configuration expected by the Internet standards.
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 for mail spoofing. That is, the reverse DNS might verify, but it will usually be part of another domain than the claimed domain name.
A failed verification does not mean that there is no relation between the domain name and the IP address. There are various reasons why it may be impossible, impractical or not desirable to set up forward confirmed reverse DNS in the correct domain including being on a dynamic IP address, not having control over the reverse DNS, one IP address might be hosting more than one domain name, wanting to hide services and so on. It is therefore not recommended to take a failed verification as proof of anything. It is, however, a mandatory Internet requirement, according to RFCs that each and every host has a valid reverse lookup. If your connection for sending mail is on a dynamic IP, which does not allow a reverse lookup, then the logical choice is to use your ISP's mail server to relay for you.
However, there are systems that take having no reverse DNS, a failed verification, reverse DNS in an other domain or something that looks like the reverse of a dynamic IP address into account because they see a correlation between that and spam. Reverse records are easy to set up and impossible to fake, and thus rejecting mail based on a failed reverse lookup is a very good first line of defense, and prevents further wasteful processing by the downstream anti-spam system on a message already deemed to be faulty or suspect. Therefore it is recommended to set up reverse DNS for outgoing email servers when possible and have it forward confirmed so that it is more likely that your email will not get wrongly rejected as spam. As of 2012[update], almost all ISPs now take the setting of reverse DNS as a standard requirement.
In some cases ISPs will not set up reverse DNS for their clients, nor delegate it to them. This causes problems for people using that ISP because they can not set up the forward-confirmed reverse DNS and so might get email rejected on this basis. It is very effective and filtering out spam, and is typically common practice for discerning mail systems to check the pointer records and reject those that fail the test.
Using your ISPs mail server as a relay will solve the reverse DNS problem, because, contrary to what some believe, the requirement is the forward and reverse lookup for the sending relay only has to match, it does not have to be related to the "from" or sending domain of emails it relays. For example, joe (at) example.com might wish to relay through smtp.someisp.com (ip a.b.c.d), provided the forward and reverse lookup for smtp.someisp.com matches with its ip of a.b.c.d the test passes. So there is no excuse not to have this set correctly under any legitimate circumstances.
Another way to establish a relation between an IP address and the domain when using email is using the Sender Policy Framework and the MX record. It is however unclear whether systems that try to check that an IP address belongs to some domain take this as alternative to the reverse DNS check.
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. ISPs that cannot or will not provide reverse DNS ultimately will be limiting the ability of their client base to use Internet services they provide effectively and securely.
- Most e-mail mail transfer agents (server software) use a FCrDNS verification and if there is a valid domain name, put it into the "Received:" trace header field.
- Some e-mail mail transfer agents will perform FCrDNS verification on the domain name given on the SMTP HELO and EHLO commands. This can violate RFC 2821 and so e-mail is usually not rejected by default.
- The Sender Policy Framework e-mail anti-forgery system uses a FCrDNS check in its "ptr:" mechanism.
- Some e-mail spam filters use FCrDNS checks as an authentication method for domain names or for whitelisting purposes; for example, according to RFC 7001.
- SpamCop uses the FCrDNS check, which sometimes causes problems for SpamCop users who are also customers of internet service providers who do not provide properly matching DNS and rDNS records for their mail servers.  
- Some FTP, Telnet and TCP Wrapper servers will perform FCrDNS checks.
- Some IRC Servers perform FCrDNS checks to prevent abuse.