PTR record reference

A PTR record maps a DNS owner name to another domain name. Its most familiar use is reverse DNS: an address is encoded below in-addr.arpa for IPv4 or ip6.arpa for IPv6, and the PTR RDATA names the host associated with that address.

Reverse DNS is a separate lookup direction. A PTR answer does not create or verify the forward A or AAAA record for its target.

Purpose and type code

IANA registers PTR as type code 12 [1]. RFC 1035 defines PTR as a pointer to another location in the domain-name space and describes its use in the address-mapping domains [2].

Operationally, PTR is commonly used for:

• identifying an address in diagnostic output;
• presenting a meaningful name in logs or monitoring;
• one input to mail-server reputation and policy checks; and
• inventory and network-management workflows.

It is not a general ownership proof or an authentication mechanism.

Presentation format

For the reserved IPv4 address 192.0.2.25, a simplified record is:

25.2.0.192.in-addr.arpa.  3600  IN  PTR  mail.example.com.

IPv4 address octets are reversed below in-addr.arpa. IPv6 reverse names use individual hexadecimal nibbles in reverse order below ip6.arpa, so they are longer and are normally generated by tooling rather than typed manually.

The PTR target is a domain name. In zone-file presentation, its final dot makes the name absolute.

Owner-name and coexistence rules

The organization controlling the address block normally controls, or delegates, the corresponding reverse zone. That is commonly an internet service provider, cloud platform, hosting provider, or enterprise network team—not the operator of the target’s forward DNS zone.

Changing mail.example.com in the example.com zone therefore does not change the PTR for its address. Use the address provider’s reverse-DNS workflow or the delegated reverse zone.

Several PTR records can technically exist at one owner, but many applications expect one stable, canonical-looking hostname. Follow the address provider’s documented constraints.

Caching and changes

Resolvers cache PTR answers and negative answers independently of forward records. A corrected reverse record can coexist temporarily with an older cached answer.

When a service moves to a new address:

1. confirm who controls the new address’s reverse DNS;
2. publish the intended forward address record;
3. request or publish the matching PTR;
4. observe the relevant TTLs; and
5. verify both directions from named resolvers.

Do not lower a forward-record TTL and assume it changes PTR caching; the records live in different zones and can have different owners and TTLs.

Security and operational limits

A PTR record can be changed only through its reverse-zone control path, but its presence does not establish that the named host is trustworthy. It does not:

• prove the target name maps back to the same address;
• authenticate a mail sender;
• authorize mail delivery;
• establish domain registration ownership;
• encrypt traffic; or
• replace service-specific identity checks.

Some mail receivers compare reverse and forward DNS as one signal. Their exact acceptance policy is outside DNS and can differ by operator. A matching pair is useful operational hygiene, not a delivery guarantee.

Verify

Use the DNS diagnostic command guide or the DNS Lookup pathway and capture:

1. the exact address and derived reverse owner name;
2. the PTR answer, TTL, resolver, and observation time;
3. a direct authoritative answer from the reverse-zone authorities when available;
4. A and AAAA results for the PTR target;
5. whether a forward result returns to the original address; and
6. the address provider or delegated reverse-zone owner responsible for change.

A forward-confirmed reverse result supports consistency. It still does not prove application identity or mail acceptance.

Next step

If reverse DNS is part of a mail incident, continue with Diagnose email failure when the website works and preserve the SMTP receiver’s exact response separately from DNS evidence.