Reverse DNS and FCrDNS
How PTR lookup and forward-confirmed reverse DNS are used in operations and email.
Definition and scope
How PTR lookup and forward-confirmed reverse DNS are used in operations and email.
Use this reference to establish the meaning and limits of the result before changing production configuration.
How it works
Reverse DNS stores PTR records below in-addr.arpa for IPv4 and ip6.arpa for IPv6. Control normally belongs to the address provider. FCrDNS additionally resolves each PTR hostname forward and checks whether the original address returns.
How to read it
A PTR answer identifies a name chosen by the address operator; it does not prove ownership of a website. Multiple PTR names are possible. FCrDNS match is stronger consistency evidence but is not authentication by itself.
Correct and incorrect examples
Compare the normalized examples. Technical values are illustrative and use documentation ranges or reserved names.
192.0.2.10 → mail.example.com → 192.0.2.10192.0.2.10 → mail.example.com → 198.51.100.20| Element | Role | Example |
|---|---|---|
| IPv4 PTR | in-addr.arpa | 10.2.0.192.in-addr.arpa |
| IPv6 PTR | ip6.arpa | nibble |
| Forward check | A / AAAA | mail.example.com |
| FCrDNS | PTR + forward | original IP present |
Common problems
Missing delegation, stale forward records, generic provider names and assuming a domain owner can edit provider-controlled reverse zones are frequent sources of confusion.
Practical checklist
Set a stable hostname, publish matching A/AAAA, request the PTR from the provider, wait for TTLs, then confirm both directions. Mail systems should also align the SMTP banner and operational identity.
Standards and primary references
These primary specifications define the protocol behavior. Provider documentation may add operational requirements but cannot replace the standard.