Network Verity
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 an other 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, 1 IP address might be hosting more than 1 domain name, wanting to hide services and so on. It is therefore not recommended to take a failed verification as proof of anything.
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, but correlation does not imply causation. It's not a good reason to reject emails only on this, but some systems do reject mail because of this. Therefore it's recommended to set up reverse DNS for outgoing email servers when possible and have it forward confirmed so that it's more likely that your email won't get wrongly rejected as spam. As of 2012 almost all ISPs now take the setting of reverse DNS as a standard requirement..
In some cases ISPs won't set up reverse DNS for their clients, nor delegate it to them. This causes problems for people using that ISP because they can't set up the forward-confirmed reverse DNS and so might wrongfully get email rejected as spam.
A similar problem is that some ISPs force their clients to use their email server for all outgoing mail. If the client is using a different domain than the ISP the verification will also fail.
An other 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.
Read more about this topic: Forward-confirmed Reverse DNS
Famous quotes containing the words network and/or verity:
“Of what use, however, is a general certainty that an insect will not walk with his head hindmost, when what you need to know is the play of inward stimulus that sends him hither and thither in a network of possible paths?”
—George Eliot [Mary Ann (or Marian)
“I think he is not a pick-purse nor a horse-stealer, but
for his verity in love, I do think him as concave as a covered goblet or a worm-eaten nut.”
—William Shakespeare (1564–1616)