What is reverse DNS (rDNS)?
Reverse DNS, usually shortened to rDNS, maps an IP address to a hostname through a DNS pointer (PTR) record. A normal forward lookup starts with a name and returns an IPv4 or IPv6 address. A reverse lookup starts with an address and asks the reverse DNS tree for a name.
For IPv4, the address octets are reversed below in-addr.arpa. A lookup for the documentation address 203.0.113.25 therefore asks for the PTR record at 25.113.0.203.in-addr.arpa. IPv6 uses reversed hexadecimal nibbles below ip6.arpa. These reverse names make the DNS hierarchy follow address-space delegation instead of the spelling of a forward domain.
A PTR result is an operator-published name. It does not prove who is using the address, that a service is reachable, that email is authenticated, that a route is authorized, or that the address has a good reputation. Treat it as one maintained DNS record whose authority, freshness, and forward match still need to be checked.
| Lookup | Starts with | Common record | Example result | Does not prove |
|---|---|---|---|---|
| Forward DNS | A hostname | A for IPv4 or AAAA for IPv6 | mail.example.net returns 203.0.113.25 | That the address maps back to the same name |
| Reverse DNS | An IP address | PTR | 203.0.113.25 returns mail.example.net | Identity, ownership, route authorization, reachability, or reputation |
| Forward-confirmed reverse DNS | An IP address, then its PTR hostname | PTR followed by A or AAAA | The returned hostname includes the original address in its forward answers | That the host is trustworthy or that mail will be accepted |
How does a reverse DNS lookup work?
- The client constructs a reverse name. For IPv4 it reverses the four decimal octets and appends
in-addr.arpa. For IPv6 it expands the address, reverses each hexadecimal nibble, and appendsip6.arpa. - A recursive resolver follows delegation. It locates the authoritative name servers for the relevant reverse zone, just as it would for a forward DNS name.
- The authoritative server answers the PTR query. The answer can contain a hostname, no matching record, or an error. A cached answer can remain visible until its TTL expires.
- The client decides what to do with the name. Logging tools may display it, diagnostics may use it as context, and a mail receiver may perform a forward lookup to see whether the name maps back to the sending address.
RFC 1035 defines the IPv4 in-addr.arpa structure and PTR record use. RFC 3596 defines IPv6 address records and the ip6.arpa reverse domain. The IP version used to send the DNS query is independent of whether the record describes IPv4 or IPv6.
What is FCrDNS?
Forward-confirmed reverse DNS (FCrDNS) is a two-direction consistency check. First, resolve the IP address to one or more PTR names. Then resolve a returned hostname through its A or AAAA records. The check passes for that name when the forward answers include the original IP address.
| Step | Passing example | Failure example |
|---|---|---|
| Reverse lookup | 203.0.113.25 returns mail.example.net | 203.0.113.25 returns no PTR record |
| Forward lookup | mail.example.net includes 203.0.113.25 | mail.example.net returns only 203.0.113.80 |
| Result | Forward-confirmed for mail.example.net | Missing PTR or forward mismatch |
RFC 1912 recommends matching PTR and address records as an operational practice. FCrDNS is not a separate authentication protocol, and DNS data can be wrong or deliberately misleading. Use it with transport security, service-specific authentication, routing and registry evidence, access control, and current reputation observations.
Why does reverse DNS matter?
- Email delivery: receiving systems commonly check whether the sending IP has a PTR name and whether that name resolves back to the same IP. Google requires valid forward and reverse DNS for senders to Gmail, while also requiring authentication and other controls.
- Operations and troubleshooting: logs, traceroute output, monitoring, and incident tools can show an intentional hostname instead of only a numeric address. The name is useful context, not proof of the device or person behind the traffic.
- Service policy: some services reject, rate-limit, or flag clients with missing, generic, or inconsistent reverse DNS. Each service sets its own policy; a PTR record does not create a universal acceptance right.
- IPv4 handover: buying or leasing a prefix requires a named owner for reverse-zone delegation, PTR changes, acceptance tests, and cleanup at renewal, return, or transfer.
Reverse DNS is not required for a browser to reach an ordinary website, and changing a PTR record does not create forward DNS, BGP reachability, TLS, SPF, DKIM, DMARC, or application acceptance. Diagnose each layer separately.
What do mail receivers check?
For mail sent to personal Gmail accounts, Google's current sender guidelines require the public sending IP to have a PTR record whose hostname resolves through A or AAAA back to that same IP. Google documents temporary and permanent failures when a sending address has no PTR record or the forward answer does not match.
That DNS consistency is only one requirement. The same guidelines also cover SPF or DKIM, TLS, message format, spam rate, and additional authentication and unsubscribe requirements for bulk senders. A successful FCrDNS check therefore removes one infrastructure defect; it does not guarantee inbox placement or prove permission to send mail.
Use the Gmail email sender guidelines and the sender-guidelines FAQ for the current Google requirements and error meanings. Check the policy of every receiver you depend on rather than assuming all mail systems use the same thresholds.
Who controls reverse DNS for an IP address?
The organization with authority over the reverse zone controls which name servers or PTR records are published. That may be an RIR member, an ISP, a cloud provider, a hosting provider, or a resource holder that has delegated operational control. Owning a forward domain does not by itself let you change the PTR record for an unrelated IP address.
ARIN's reverse DNS guide explains that IPv4 and IPv6 reverse data are rooted in in-addr.arpa and ip6.arpa, and describes delegation management for registered resources. RIPE NCC's reverse-delegation guide describes the same public delegation model. Exact tools, minimum delegation sizes, DNSSEC support, and approval paths depend on the address source and registry.
| Address arrangement | Likely control path | Evidence to keep |
|---|---|---|
| ISP, cloud, or hosting address | Provider portal or support request; the provider usually retains reverse-zone authority | Requested hostname, ticket, completion time, TTL, and independent lookup result |
| Directly registered prefix | RIR delegation to authoritative name servers, then PTR records in the delegated reverse zone | Registry delegation, zone configuration, DNSSEC status where used, and change receipt |
| Leased IPv4 prefix | Holder, lessor, or delegated DNS operator according to the agreement | Named change owner, allowed names, response target, acceptance test, and return cleanup |
| Transferred IPv4 prefix | Current registered holder during transfer; receiving organization after registry and DNS handover | Cutover order, old and new authority, TTL plan, rollback, and final verification |
How do you set up and verify reverse DNS?
- Identify the address and service. Record the exact IPv4 or IPv6 address, the intended hostname, the service that depends on it, and the acceptance rule you must satisfy.
- Find the reverse-zone operator. Check the provider account, agreement, registry delegation, or authoritative
NSresponse. Do not assume the forward-domain registrar controls rDNS. - Choose a stable hostname you control. Use a valid fully qualified hostname whose forward zone you can maintain. Avoid a name that will be removed while the PTR is still cached.
- Publish the forward record. Add the intended
AorAAAArecord and verify that it includes the target address before or in coordination with the PTR change. - Create the PTR record or request the change. Use the provider workflow or operate the delegated reverse zone. Preserve who approved the change, the TTL, and the expected propagation boundary.
- Verify both directions independently. Query the PTR from the address, then query the returned name and confirm that the original address appears. Repeat from a resolver outside the authoritative environment after caches have expired.
dig -x 203.0.113.25 +short
dig A mail.example.net +short
dig AAAA mail.example.net +short
dig NS 113.0.203.in-addr.arpa +shortThe commands show DNS answers; they do not test SMTP authentication, routing authority, port reachability, reputation, or whether a receiving service will accept traffic. Add service-specific checks after the DNS pair is correct.
How do you fix common reverse DNS problems?
| Symptom | Likely cause | Next check |
|---|---|---|
No PTR answer or NXDOMAIN | No record exists, the wrong reverse name was queried, or the reverse zone is not delegated correctly | Confirm the address expansion and authoritative NS chain, then ask the reverse-zone operator |
| “Forward-confirmed reverse DNS failed” | The PTR name has no forward address record, or its A/AAAA answers do not include the original IP | Query the PTR hostname directly and compare every returned address with the tested IP |
| Old hostname still appears | A resolver has cached the prior positive answer, or the old authority still serves it | Check TTLs and query the authoritative servers as well as independent recursive resolvers |
| Some resolvers disagree | Delegation, zone replicas, DNSSEC, or caches are inconsistent | Compare authoritative answers, serials, DS/DNSKEY state where used, and resolver cache age |
| PTR is correct but mail still fails | Another sender requirement, authentication control, reputation signal, or service policy is failing | Read the exact SMTP response and test SPF, DKIM, DMARC alignment, TLS, rate, and reputation separately |
| You cannot edit the record | The provider or address holder retains reverse-zone authority | Locate the contractual change path; a forward DNS edit cannot replace reverse authority |
What should a leased IPv4 agreement say about rDNS?
Before accepting a leased prefix, identify the party that can make reverse DNS changes and test the actual workflow. A generic statement that “rDNS is supported” does not define authority, timing, allowed hostnames, DNSSEC handling, incident response, or what happens when the lease ends.
- List the exact prefix, reverse zones, and whether control is delegated or changes are ticketed.
- Name the party authorized to request, approve, publish, and roll back PTR changes.
- State the required hostname format, TTL range, validation, response target, and maintenance window.
- Define acceptance with PTR, forward-match, authoritative-server, DNSSEC, and service-specific checks.
- Coordinate rDNS with LOA, BGP, RPKI, IRR, geofeed, abuse contacts, monitoring, and application cutover.
- Document renewal, transfer, route withdrawal, PTR removal, and forward-record cleanup so stale names do not outlive authorized use.
Review the wider operating path in the IPv4 leasing guide, or use the managed IPv4 leasing request to state the required prefix, origin ASN, rDNS model, timing, and acceptance evidence.
Reverse DNS FAQ
What does rDNS mean?
rDNS means reverse Domain Name System lookup. It starts with an IP address and queries a PTR record in the IPv4 in-addr.arpa or IPv6 ip6.arpa tree to obtain an operator-published hostname.
What is a PTR record?
A PTR record points a reverse DNS name to another domain name. For an IP address, it supplies the hostname returned by a reverse lookup. It is separate from the forward A or AAAA record for that hostname.
How do I check reverse DNS?
Run dig -x IP_ADDRESS +short, host IP_ADDRESS, or an equivalent resolver query. Then resolve the returned hostname and compare its A or AAAA answers with the original address.
What is FCrDNS?
Forward-confirmed reverse DNS checks an IP's PTR hostname and then checks whether that hostname resolves forward to the original IP. It is a consistency signal, not proof of identity, security, reputation, or permission to send mail.
What does “forward-confirmed reverse DNS failed” mean?
It normally means there is no PTR name, the PTR hostname has no forward address record, or its forward answers do not include the tested IP. Query both directions and correct the record at the authority that controls the failing side.
Can I set reverse DNS myself?
Only if the address provider or registered holder has delegated the reverse zone or exposed a supported PTR-management workflow to you. Controlling the forward domain alone is not enough.
Does reverse DNS guarantee email delivery?
No. Valid forward and reverse DNS can be required by a receiver, but delivery also depends on authentication, authorization, content, sending behavior, complaint rate, reputation, and that receiver's current policy.
Does reverse DNS work for IPv6?
Yes. IPv6 reverse lookups use PTR records under ip6.arpa, with the fully expanded hexadecimal nibbles written in reverse order. Delegation and operational tooling can differ from IPv4.
