Reverse DNS & PTR Records Explained (2026)

Reverse DNS & PTR Records Explained (2026)

Reverse DNS starts from an IP address and comes back with a name. The record is a PTR. It is the inverse of an A or AAAA record, and it lives in a different zone from the hostname you think you control.

Need the lookup, not the lecture? Paste one public address into the free Reverse DNS Lookup. It asks for the PTR names, then checks that each name resolves forward to the same address. What follows is the part that short page cannot fit: how the reversed name is built, who may publish it, why a bare PTR is not identity, and how the check sits next to mail policy and a log.

Stay on addresses you are allowed to ask about: yours, a host in a written scope, or a public IP already in a log you are staffed to read. OSINT for Beginners: a legal methodology draws the same line. Examples use documentation ranges only. This is not a sweep of someone else's space.

The name is backwards on purpose

An A record holds one IPv4 address for a name. An AAAA record holds one IPv6 address. RFC 1035 assigns PTR type 12, "a domain name pointer." The RDATA is a domain name. PTR records cause no additional section processing. They are not aliases. A CNAME is the alias type. A PTR points at another name and stops.

The old inverse-query opcode is not this lookup. RFC 1035 §6.4 makes IQUERY optional and says it is not an acceptable way to map addresses to names. Use IN-ADDR.ARPA. Reverse DNS is an ordinary PTR query in class IN (value 1).

IPv4: four labels, reversed

RFC 1035 §3.5 puts host addresses under IN-ADDR.ARPA. Four labels, plus that suffix. Each label is one octet, decimal 0 through 255, leading zeros omitted, except a zero octet written as a single 0. The octets run in reverse so a network can be delegated as its own zone.

RFC 5737 reserves three blocks for examples: 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3). Take 192.0.2.5. The query name is 5.2.0.192.in-addr.arpa.

RIPE's reverse DNS guide prints that pair as:

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

3600 is the TTL in their example, in seconds. The PTR definition does not require it. mail.example.com is their sample name. RFC 2606 reserves example.com, example.net, and example.org for this kind of use.

No PTR means no hostname. That empty answer is normal.

IPv6: one label per nibble

IPv6 reverse does not use in-addr.arpa. RFC 3596 §2.5 roots it at IP6.ARPA. The address becomes nibbles separated by dots, suffix .IP6.ARPA. A nibble is four bits, one hex digit. The low-order nibble is encoded first. RFC 3596 replaces the IP6.INT domain from RFC 1886 with IP6.ARPA.

The documentation prefix is 2001:DB8::/32 (RFC 3849). RIPE walks 2001:db8::567:89ab, which is inside it. Expanded:

2001:0db8:0000:0000:0000:0000:0567:89ab

Reverse the 32 hex digits, one per label:

b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

RIPE's sample points that name at mail.example.com with TTL 3600, their figure, not a required value. RFC 3596 §2.2 stores one 128-bit address per AAAA record, network byte order, so each address has its own nibble name.

On a network you administer, PTR records are optional. Microsoft's reverse-lookup page says so, and notes that some applications still use them as a check. Windows builds an in-addr.arpa zone for IPv4 and an ip6.arpa zone for IPv6. That page still cites RFC 1886; the text that replaced it is RFC 3596. An internal zone is not the public tree.

Who is allowed to publish the PTR

Forward and reverse are different delegations.

RIPE roots the public reverse tree in arpa, then in-addr.arpa or ip6.arpa, then the blocks IANA gave the RIRs, then what those RIRs assigned, then single addresses. The address holder serves the zone and asks for delegation. In the RIPE region that ask is a domain object. The parent publishes NS records only after at least two of your name servers answer for the zone. RIPE says a successful delegation may still take up to 24 hours to show up in DNS.

Zones break on label boundaries. IPv4 is bytes, multiples of 8 bits, so a length between /17 and /24 is one /24 zone per slice. 192.0.2.0/24 is already one slice: 2.0.192.in-addr.arpa. IPv6 is nibbles, multiples of 4 bits. The documentation /32 is one zone, 8.b.d.0.1.0.0.2.ip6.arpa. A prefix off that grid has to be split to the next nibble. RIPE illustrates a /29 as eight /32 zones. I will not print the neighbours. Only 2001:db8::/32 is the documentation prefix.

Owning mail.example.com does not give you the PTR for 192.0.2.5. RFC 1035 §3.5 puts IN-ADDR.ARPA and the forward name in different zones, and it warns the copies can disagree. Change the A record and the PTR can sit there stale. Point the PTR at a stranger and the forward zone never has to agree.

If you hold the block, you serve the zone and ask the RIR to delegate it. RIPE documents that for its region. I will not invent another registry's screens. If a host numbered you from a block they hold, they publish the PTR. You ask them. You do not edit their parent.

A domain registration record will not show the PTR. WHOIS and RDAP are registrar, dates, and nameservers for the forward name, which is What Is WHOIS?. The WHOIS Lookup reads that record. It does not query in-addr.arpa.

A PTR alone proves nothing

Whoever controls the address can put any name in the PTR. The string becomes evidence only when the forward direction agrees.

RFC 8601 §3 calls the loop iprev. Client address I. The PTR names are set N. A and AAAA lookups for each name in N produce set L. The test passes when I is in L. Operators call a pass forward-confirmed reverse DNS, FCrDNS.

There is no none. A TCP connection has an address, so some evaluation is always possible.

The Reverse DNS Lookup tool does this. Public IP in, every PTR name out, a forward lookup of each name, and a check that the original address is in the set.

By hand, dig -x is the reverse half. The BIND 9 dig manual says -x accepts a dotted IPv4 address or a colon-delimited IPv6 address, builds a name such as 94.2.0.192.in-addr.arpa (192.0.2.94, still TEST-NET-1), and queries PTR in class IN. IPv6 goes to IP6.ARPA in nibble form. The Linux networking guide uses the same command. One address you are allowed to ask about.

dig -x 192.0.2.5
dig mail.example.com A
dig mail.example.com AAAA

Line one is the PTR query. The next two ask whether mail.example.com has an address record of 192.0.2.5. For a real name you may check, DNS Lookup returns A and AAAA together. RFC 5737 says TEST-NET addresses SHOULD NOT appear on the public Internet, so these commands show the shape, not a live answer.

RFC 8601 does not sell a pass as authentication. It notes that in some regions forward and reverse are rarely matched, leaves the implementation details open, and repeats the advice that applications avoid this test as a means of authentication or security. A pass means the two directions agreed when you asked.

Where this sits in email

RFC 5321 §4.1.1.1 and §2.3.5: EHLO carries the client's fully qualified name when it has one, and that name must be a primary hostname, one that resolves to an address record. A client without a meaningful name, the spec's example is a dynamic address with no reverse record, SHOULD send an address literal.

§4.1.4: a server MAY check that the EHLO name corresponds to the client IP, and if the check fails it MUST NOT refuse the message for that reason. The note is for the log. §7.9 still allows refusal for a site's own operational reasons. The spec does not say "reject unless EHLO equals the PTR."

Policy on the PTR itself is separate. RFC 8601 §3 says an MTA will often reject a connection that fails iprev, or it can store the result for a later filter. Often is not a provider list, and it is not always.

Postfix documents two restrictions an administrator has to enable. reject_unknown_reverse_client_hostname rejects when the client IP has no address-to-name mapping. reject_unknown_client_hostname also rejects when the name-to-address lookup fails or does not reproduce the client IP. The default reply code is 450, and it is always 450 when a lookup failed for a temporary reason. Neither restriction judges how a hostname looks. A plain name passes when its forward records contain the client IP.

iprev is not SPF, DKIM, or DMARC, which SPF, DKIM & DMARC Explained covers. SPF lists servers allowed to use your domain as the envelope sender. DKIM signs the message. DMARC passes when at least one of those passes and aligns with the visible From domain. None of them is a PTR lookup. The Email Security Checker grades SPF and DMARC, plus DKIM when you give it a selector. The PTR still belongs to the address holder.

What I use it for, and where it lies

On an incident I am staffed on, the PTR is how I read a log. The reverse-lookup page describes the job: turn raw addresses into readable infrastructure, tell a cloud host from a residential ISP range, and cluster related systems. To me those names are hints about who numbered the block. They are not a verdict, and not a licence to query the neighbours.

A scanner-ish name is still just a name they published. No forward check, and I ignore it. A forward check confirms the naming choice. It does not prove malice. One address from the log. Then stop.

The gaps I expect:

• No PTR. Microsoft calls the record optional. The reverse tool says many addresses, dynamic ones especially, have none. RFC 8601 scores that as permerror.
• Several PTRs. Allowed. RFC 2181 §10.2 calls the one-record belief incorrect. Each value should be a canonical name, not an alias. RFC 1035's own IN-ADDR.ARPA example puts two PTR records on one name. The Andrax tool shows every name and forward-confirms each.
• Forward mismatch. Different zones can disagree (RFC 1035). RFC 8601 calls that fail. Do not file the PTR name as "the host is this."
• Cache. RFC 1035 §4.1.3: the TTL is a 32-bit count of seconds a record may be cached before it should be discarded. Zero means this transaction only. After a PTR change, a resolver can serve the old answer until its timer ends. RIPE's "up to 24 hours" is a separate wait, on a new delegation.
• Private addresses. Only public addresses belong in this check. The Reverse DNS Lookup page rejects private, loopback, link-local, and reserved ranges by design (10.x, 192.168.x, 127.x, 169.254.x, and their IPv6 equivalents): resolving internal addresses through a public service is an SSRF vector, and the answers would be meaningless. IP Address Info labels an IPv4 address's scope before you paste it, and prints its in-addr.arpa name. An internal zone, the Microsoft case, stays on resolvers you run.

FAQ

Why does this IP have no PTR?

The address holder never wrote one. An A record does not create a PTR, and dynamic space often has none. For a mail server, ask whoever assigned the address, then forward-confirm the name. A missing PTR is common, and a weak default on a host that sends mail.

Can one IP have several PTR records?

Yes. RFC 2181 says so. Unusual, and still valid. Check each name. One may match forward while another does not.

Does reverse DNS affect deliverability?

It can. RFC 8601 says MTAs often reject a failed iprev test. Postfix can be set to reject a client with no PTR, or with one that does not map back. That is not a named mailbox provider, and it is not SPF, DKIM, or DMARC. A matching PTR will not save a domain that fails authentication. A missing PTR does not, alone, prove forgery.

Is nslookup of an IP the same thing?

Same question. The BIND 9 nslookup manual says that when the argument is an Internet address and the query type is A or PTR, the host name is returned. dig -x is the explicit form: it builds the reversed name and queries PTR in class IN. Either way, resolve the name forward before you trust it.

One public address, the PTR, then the forward lookup. The Reverse DNS Lookup runs both and refuses the ranges that do not belong in a public query.