Reverse DNS, or rDNS, is the process of looking up a hostname associated with an IP address. While normal DNS typically translates a domain name into an IP address, reverse DNS performs the opposite type of lookup: it starts with an IPv4 or IPv6 address and attempts to find an associated domain name.

For example, normal DNS may answer:

mail.example.com → 203.0.113.25

Reverse DNS may answer:

203.0.113.25 → mail.example.com

This mapping is usually created using a PTR record, or Pointer record.

Reverse DNS is widely used in:

  • email infrastructure;
  • network troubleshooting;
  • logging;
  • traceroute;
  • security analysis;
  • infrastructure identification; and
  • operational monitoring.

But reverse DNS should not be confused with IP registration, routing, geolocation or proof of resource ownership.

Each system answers a different question.

What Is Reverse DNS?

The Domain Name System normally helps applications translate human-readable names into network addresses.

For example:

www.example.com

may resolve to:

203.0.113.25

This is known as forward DNS.

Reverse DNS starts with the address:

203.0.113.25

and asks:

Is there a hostname associated with this IP address?

If the appropriate reverse DNS information exists, the result might be:

mail.example.com

The mechanism is part of the DNS architecture and uses PTR records.

RFC 1035 defines the PTR resource-record type and the IPv4 reverse-address structure under the IN-ADDR.ARPA domain.

Forward DNS vs Reverse DNS

Forward and reverse DNS perform related but different functions.

FunctionInputResult
Forward DNSDomain nameIP address
Reverse DNSIP addressHostname
Common recordA / AAAAPTR

For example:

Forward DNS

server.example.com

↓

203.0.113.25

Reverse DNS

203.0.113.25

↓

server.example.com

The two records are maintained separately.

Creating an A record does not automatically create a corresponding PTR record.

Likewise, creating a PTR record does not automatically create the matching forward record.


What Is a PTR Record?

A PTR record, short for Pointer record, is a DNS resource record commonly used to associate an IP address with a hostname.

Conceptually:

203.0.113.25

can point to:

mail.example.com

A PTR record therefore works in the opposite direction from an A or AAAA record.

RFC 1035 defines PTR records as pointers to another location in the domain-name space.

PTR records are especially useful because an IP address by itself is difficult for people to interpret.

Compare:

203.0.113.25

with:

edge-router-singapore.example.net

The hostname can provide operational context that the numeric address does not.

How Does Reverse DNS Work for IPv4?

IPv4 reverse DNS uses the special DNS domain:

in-addr.arpa

The octets of the IPv4 address are reversed.

Suppose the IP address is:

203.0.113.25

The corresponding reverse DNS name becomes:

25.113.0.203.in-addr.arpa

A DNS resolver can query this name for a PTR record.

If one exists, it might return:

mail.example.com

The reversed structure makes it possible to delegate reverse DNS authority according to address blocks.

RFC 1035 describes this structure and explains why IPv4 addresses are represented in reversed order inside IN-ADDR.ARPA.


Why Is the IPv4 Address Reversed?

At first, this format:

25.113.0.203.in-addr.arpa

may look unusual.

But DNS is hierarchical.

Normal domain names become more specific from right to left.

For example:

mail.example.com

belongs under:

example.com

which belongs under:

.com

Reverse-address DNS needs a similar hierarchy.

Reversing the IPv4 octets makes it possible to delegate control over larger address blocks and then smaller parts of those blocks through the DNS hierarchy.

How Does Reverse DNS Work for IPv6?

IPv6 also supports reverse DNS, but it uses:

ip6.arpa

Instead of reversing decimal octets, IPv6 reverse DNS works at the hexadecimal nibble level.

Because IPv6 addresses are much longer than IPv4 addresses, their reverse DNS names can also be much longer.

This creates additional operational considerations.

RFC 8501 discusses reverse DNS practices specifically for IPv6 Internet service providers and notes that simply pre-populating PTR records for every possible IPv6 address does not scale in the same way as some traditional IPv4 approaches.


Who Controls Reverse DNS?

This is one of the most important differences between forward and reverse DNS.

If an organisation owns or controls:

example.com

it can normally manage the authoritative DNS records for that domain.

But control of reverse DNS follows the IP address delegation hierarchy.

The organisation responsible for the relevant address space, or a provider from which the address space is obtained, determines how reverse DNS authority is delegated.

At the upper levels, IANA and the Regional Internet Registries participate in the delegation structure for reverse DNS zones associated with Internet number resources.

For example, APNIC explains that address blocks allocated to it have corresponding reverse DNS zones delegated within in-addr.arpa and ip6.arpa.

This means that control over a forward domain name and control over reverse DNS for an IP address are separate administrative relationships.


Reverse DNS and Internet Number Resources

Reverse DNS illustrates why Internet infrastructure contains multiple coordination layers.

Consider an IPv4 prefix.

A network may have:

Registry record
Information associated with the address resource.

BGP announcement
Information about how the prefix is currently reachable.

RPKI ROA
Information about which ASN is authorised to originate the route.

Reverse DNS
Information mapping addresses to hostnames.

IP geolocation
An estimate of where the address is being used.

These systems can interact.

But they are not interchangeable.

LARUS Foundation explains a similar distinction in What Is IP Address Registration? and What Is IP Geolocation and Why Can It Be Wrong?.

Why Does Reverse DNS Matter?

Reverse DNS is not required for every Internet connection.

Many applications function perfectly well without meaningful PTR records.

But rDNS remains operationally useful in several important areas.

1. Reverse DNS Helps With Network Troubleshooting

Network engineers frequently work with IP addresses.

Logs, router interfaces and diagnostic tools may display addresses such as:

198.51.100.17

A meaningful PTR record can make that address easier to understand.

For example:

router1.sin.example.net

can suggest that the address belongs to:

  • a router;
  • a particular network;
  • or a specific operational location.

This can make tools such as traceroute easier to interpret.

RFC 8501 specifically identifies troubleshooting and traceroute as practical uses of PTR information.

2. Reverse DNS Is Important for Email

Reverse DNS is particularly important in email infrastructure.

Mail operators frequently evaluate information associated with the IP address connecting to their mail server.

A sending mail server may be expected to have a meaningful PTR record.

Operators may also compare:

IP address → PTR hostname

with:

hostname → IP address

This is sometimes called forward-confirmed reverse DNS.

A configuration might look like:

203.0.113.25

↓

mail.example.com

and:

mail.example.com

↓

203.0.113.25

A consistent configuration can help provide useful operational information.

However, reverse DNS by itself does not prove that mail is legitimate.

Modern email reputation also depends on many other mechanisms, including:

  • SPF;
  • DKIM;
  • DMARC;
  • IP reputation;
  • domain reputation;
  • sending behaviour; and
  • abuse history.

RFC 8501 notes that mail systems are among the environments where forward and reverse DNS relationships can be operationally important.

3. Reverse DNS Makes Logs Easier to Read

A security log containing thousands of raw IP addresses can be difficult to interpret.

If reverse DNS is available, systems may display a hostname alongside an address.

For example:

192.0.2.40

may appear as:

edge01.example.net

This can help network teams identify infrastructure more quickly.

But administrators should still verify the underlying address.

A hostname should not automatically be trusted simply because a PTR record exists.

4. Reverse DNS Can Help Identify Network Infrastructure

Operators often create naming conventions for:

  • routers;
  • switches;
  • gateways;
  • DNS servers;
  • mail servers;
  • transit interfaces;
  • and other infrastructure.

A router interface might have a PTR such as:

core1.kul.example.net

or:

edge2.sin.example.net

These names can make operational tools more understandable.

But naming conventions can also expose information about network architecture, which is why operators should consider what details they publish.


5. Reverse DNS Can Assist Security Investigations

Security analysts may use PTR information as one piece of context when investigating network activity.

For example, a PTR hostname might suggest that an address belongs to:

  • a hosting platform;
  • an ISP;
  • a cloud environment;
  • a network gateway;
  • or a mail server.

However:

A PTR hostname is metadata supplied through DNS. It should not automatically be treated as proof of identity or trust.

Security decisions should combine multiple sources of evidence.

Does Every IP Address Need a PTR Record?

No.

Many addresses do not need meaningful reverse DNS records.

The value depends on the use case.

PTR records are particularly useful for:

  • mail servers;
  • public infrastructure;
  • router interfaces;
  • DNS infrastructure;
  • systems frequently examined through logs;
  • and services where network identity is operationally important.

For residential or highly dynamic environments, maintaining individually meaningful reverse records may provide less value.

The problem becomes even larger with IPv6 because of the enormous number of possible addresses.

RFC 8501 discusses several approaches that IPv6 ISPs may use rather than trying to pre-populate meaningful PTR records for every possible IPv6 address.

Does Reverse DNS Affect Email Deliverability?

It can.

Receiving mail systems may check whether the connecting IP has a reverse DNS record.

A missing, obviously generic or inconsistent configuration can contribute to distrust.

However, reverse DNS is only one part of email deliverability.

A correctly configured PTR record cannot repair:

  • poor sending reputation;
  • spam activity;
  • invalid SPF;
  • missing DKIM;
  • problematic DMARC configuration;
  • compromised infrastructure;
  • or blocklist history.

The correct conclusion is:

Reverse DNS supports mail-server identity and operational hygiene, but it does not independently establish sender reputation.

What Is Forward-Confirmed Reverse DNS?

Forward-confirmed reverse DNS checks whether forward and reverse lookups are consistent.

For example:

Reverse lookup

203.0.113.25

↓

mail.example.com

Forward lookup

mail.example.com

↓

203.0.113.25

When the address appears in both directions, the relationship is internally consistent.

But this still should not be interpreted as cryptographic proof of identity.

DNS information can be configured by authorised administrators, and security systems need to consider other authentication mechanisms.

Reverse DNS Is Not the Same as RPKI

Reverse DNS and RPKI answer very different questions.

Reverse DNS asks:

What hostname is associated with this IP address?

RPKI asks:

Is this ASN authorised to originate this IP prefix?

For example:

PTR:

203.0.113.25 → mail.example.com

RPKI:

203.0.113.0/24 → AS64500 authorised

These statements operate at different layers.

A network can have:

  • correct RPKI;
  • incorrect reverse DNS;

or:

  • correct reverse DNS;
  • incorrect RPKI.

One does not automatically validate the other.

Reverse DNS Is Not the Same as IP Geolocation

This distinction is also important.

A PTR record might be:

router1.singapore.example.net

That does not necessarily prove the router is physically in Singapore.

A hostname is selected by the administrator controlling the relevant reverse DNS zone.

Naming conventions can reflect location, function or internal organisation.

But they can also be:

  • outdated;
  • generic;
  • intentionally abstract;
  • or inaccurate.

LARUS Foundation's IP geolocation guide explains why physical location should not be inferred from a single network-information source.

Reverse DNS Is Not Proof of IP Ownership

A PTR record also does not establish legal ownership or every form of operational control over an IP address.

The ability to configure reverse DNS may indicate control over a delegated reverse zone or cooperation from the upstream provider.

But Internet number-resource relationships involve other systems, including:

  • registry records;
  • contractual arrangements;
  • routing;
  • RPKI;
  • and operational deployment.

This reflects a broader principle:

No single Internet database should be treated as the complete source of truth for every aspect of a number resource.

LARUS Foundation discusses the importance of separating these layers in Why Accurate Registry Data Supports a Stable Internet.

What Happens During an IPv4 Transfer?

Reverse DNS is particularly important when IPv4 address space changes operational users.

Imagine a /24 prefix was previously used by:

Company A

and then transferred to:

Company B

The new operator may correctly update:

  • registry records;
  • BGP announcements;
  • RPKI;
  • IRR objects;
  • and geolocation information.

But old reverse DNS records may still remain if the reverse zone has not been properly updated.

A lookup might still return hostnames associated with the previous network.

This can create confusion during:

  • troubleshooting;
  • reputation checks;
  • mail deployment;
  • security investigations;
  • and infrastructure monitoring.

Reverse DNS should therefore be part of post-transfer operational preparation.

Reverse DNS and IPv4 Address Reuse

This becomes increasingly relevant as IPv4 resources are reused.

A modern IPv4 lifecycle may look like:

Previous network use

→ Transfer or reassignment

→ Registry update

→ BGP deployment

→ RPKI / IRR update

→ Reverse DNS configuration

→ Reputation and geolocation correction

→ Production use

The numeric addresses may remain identical.

Their operational context changes.

Reverse DNS is one of the metadata layers that should follow the new deployment.

This is similar to the challenge discussed in LARUS Foundation's article What Is IP Geolocation and Why Can It Be Wrong?.

What Is a Reverse DNS Delegation?

Managing a PTR record requires authority over the relevant reverse DNS namespace.

At higher levels, reverse DNS follows delegations associated with IP address resources.

For IPv4, these delegations exist beneath:

in-addr.arpa

For IPv6:

ip6.arpa

A resource holder may operate authoritative DNS servers for its reverse zone or receive reverse DNS services through a provider.

APNIC explains that its reverse DNS data uses domain objects identifying officially delegated DNS name servers for IPv4 and IPv6 reverse zones.

What Is a Lame Reverse DNS Delegation?

A reverse DNS delegation becomes lame when the nameservers listed for a zone are unable to answer authoritatively as expected.

This may happen because:

  • the nameserver is unreachable;
  • the zone is not configured;
  • the wrong server is listed;
  • or delegation information is inconsistent.

Lame delegations can cause operational problems because queries may wait for DNS timeouts before failing.

APNIC notes that lame reverse delegations can cause service delays, DNS-processing failures and unnecessary DNS traffic.

This makes reverse DNS configuration part of responsible resource administration rather than merely cosmetic naming.

Why Accurate Reverse DNS Matters During Network Changes

Reverse DNS should be reviewed whenever an organisation changes:

  • providers;
  • address space;
  • data centres;
  • mail infrastructure;
  • routing architecture;
  • cloud platforms;
  • or resource administration.

For example, an enterprise may move a mail platform from one provider to another while retaining the same public IP space.

BGP may transition correctly.

But if reverse DNS still identifies old infrastructure, some external systems may receive inconsistent information.

This is why continuity planning should include more than routing alone.

An organisation should also check:

  • registry information;
  • RPKI;
  • IRR;
  • reverse DNS;
  • forward DNS;
  • IP reputation;
  • geolocation;
  • firewall dependencies;
  • and external allowlists.

Reverse DNS and Network Identity

Public IP addresses can become part of an organisation's operational network identity.

Reverse DNS can add a human-readable naming layer to that identity.

For example:

edge1.example.net

can be easier for network operators to recognise than:

198.51.100.46

But the PTR hostname is only one representation.

The underlying network identity may also involve:

  • the IP prefix;
  • ASN;
  • BGP announcements;
  • RPKI authorisations;
  • DNS;
  • and long-standing external dependencies.

Reverse DNS should therefore support operational clarity without being mistaken for the resource itself.

Best Practices for Reverse DNS

Network operators should consider several basic practices.

Keep PTR Records Current

Remove or update hostnames that no longer represent the current infrastructure.

Match Forward and Reverse DNS Where Appropriate

For important infrastructure—particularly mail systems—maintaining a consistent relationship can reduce ambiguity.

Review Reverse DNS After Address Transfers

Do not assume old PTR records disappear automatically.

Document Delegations

Know which organisation or provider controls the reverse zone.

Avoid Exposing Unnecessary Information

Highly descriptive hostnames can reveal network topology.

Use naming conventions that balance operational usefulness with security considerations.

Monitor Authoritative Nameservers

Ensure reverse DNS nameservers remain reachable and correctly configured.

Include rDNS in Continuity Planning

Reverse DNS authority should not depend on an undocumented account or one employee.

Practical Reverse DNS Checklist

When deploying a new IP prefix, ask:

Delegation

  • Who controls the reverse zone?
  • Are the authoritative nameservers correct?
  • Are they reachable?

PTR Records

  • Which infrastructure needs meaningful PTR records?
  • Are old hostnames still present?

Forward DNS

  • Should important PTR hostnames resolve back to the expected IP?

Email

  • Do mail-server addresses have appropriate rDNS?
  • Are SPF, DKIM and DMARC also configured?

Routing

  • Is the prefix being announced by the intended ASN?

RPKI

  • Does the ROA match the intended origin?

Registry

  • Are registration records current?

Geolocation and Reputation

  • Do third-party systems reflect the new operational environment?

This helps ensure that reverse DNS is considered as one part of a larger deployment process.

Frequently Asked Questions

What is reverse DNS?

Reverse DNS is a DNS lookup that starts with an IP address and attempts to find an associated hostname.

What does rDNS stand for?

rDNS stands for reverse Domain Name System or reverse DNS.

What is a PTR record?

A PTR record is a DNS resource record used to point an IP address's reverse DNS entry toward a domain name.

What is the difference between DNS and reverse DNS?

Normal forward DNS maps a hostname to an IP address. Reverse DNS maps an IP address toward a hostname.

How does IPv4 reverse DNS work?

IPv4 reverse DNS uses the in-addr.arpa namespace and reverses the IP address octets when constructing the DNS query.

How does IPv6 reverse DNS work?

IPv6 reverse DNS uses ip6.arpa and represents the IPv6 address in reversed hexadecimal nibbles.

Does every IP address need reverse DNS?

No. Reverse DNS is especially useful for mail servers, network infrastructure and troubleshooting, but not every address requires a meaningful PTR record.

Is reverse DNS important for email?

Yes. Mail operators commonly use rDNS information as part of their evaluation of sending infrastructure, although PTR configuration alone does not guarantee successful delivery.

Does a PTR record prove who owns an IP address?

No. PTR data is a DNS mapping. Registry records, routing, contractual arrangements and other systems address different aspects of IP resource administration.

Can reverse DNS reveal location?

A hostname may contain geographic information, but that does not prove the physical location of the address.

Is reverse DNS the same as WHOIS or RDAP?

No. WHOIS and RDAP provide registration information. Reverse DNS maps an IP address to a hostname.

Is reverse DNS the same as RPKI?

No. RPKI helps verify whether an ASN is authorised to originate an IP prefix. Reverse DNS provides hostname mappings.

Why is my reverse DNS wrong?

The address may have been reassigned, the PTR record may be outdated, or the reverse DNS delegation may not have been updated correctly.

Who can change reverse DNS?

The organisation controlling the appropriate reverse DNS delegation, or the provider managing it on behalf of the user, can normally make the change.

Should reverse DNS be checked after an IPv4 transfer?

Yes. Old PTR records or delegations can remain after operational control changes, so reverse DNS should be part of a post-transfer deployment review.

Conclusion

Reverse DNS is a relatively small part of Internet infrastructure, but it performs an important function.

It gives network operators a way to associate numeric IP addresses with human-readable hostnames.

That can improve:

troubleshooting

logging

email operations

infrastructure identification

and:

network administration.

But reverse DNS is most useful when its role is understood correctly.

A PTR record does not define who legally owns an IP address.

It does not determine how the prefix is routed.

It does not replace RPKI.

And it does not prove physical location.

Instead, reverse DNS is one layer in a larger Internet number-resource environment:

Registry records
describe resource registration.

BGP
describes reachability.

RPKI
supports origin authorisation.

Reverse DNS
associates addresses with hostnames.

Geolocation
estimates geographic deployment.

IPAM
helps operators manage address use internally.

A resilient network depends on these layers remaining accurate without confusing one for another.

That becomes increasingly important as IPv4 addresses are transferred, reassigned and reused across changing networks.

The number may stay the same.

The organisation, route, hostname, reputation and deployment can all change.

For network operators, the practical lesson is simple:

Reverse DNS should describe the network that exists now—not the network that used the IP address years ago.

Keeping that information current is part of maintaining an accurate, understandable and operationally reliable Internet.