A DNS PTR (pointer) record maps an IP address to a domain name. It is the record used for a reverse DNS lookup: given an address, what hostname does DNS return? An A or AAAA record answers the opposite question—given a hostname, what IPv4 or IPv6 address does it return?
For example, a reverse lookup of a mail server’s IP might return mail.example.net. That name is useful context, but it does not prove who operates the server. The administrator of the relevant reverse DNS zone controls the PTR record, and DNS answers can be missing, outdated, or misconfigured. Cloudflare’s PTR explanation describes this address-to-name relationship.
| Lookup | Question | Record |
|---|---|---|
| Forward | What IPv4 address does mail.example.net use? |
A |
| Forward | What IPv6 address does mail.example.net use? |
AAAA |
| Reverse | What name is associated with this IP address? | PTR |
PTR records matter most when you administer a public IP address, operate a mail server, or investigate traffic and logs. You do not need one simply to make a website reachable by its domain name.
How reverse DNS names are formed
For IPv4, DNS reverses the address’s four octets and places them under in-addr.arpa. The documentation address 203.0.113.10, for example, has the reverse lookup name:
10.113.0.203.in-addr.arpa.
A PTR record at that name could point to mail.example.net.. The trailing dot marks a complete DNS name. This is an illustration, not a live configuration: 203.0.113.10 and example.net are reserved for documentation.
IPv6 uses ip6.arpa instead. The address is expanded to its full hexadecimal form, then each hexadecimal digit, or nibble, is reversed into a separate DNS label. It is not a reversal of the colon-separated groups. You rarely need to construct this name by hand: a DNS lookup tool can do it for you. RFC 3596 defines IPv6 reverse lookups.
The reverse name identifies what name to query for a PTR record. It does not mean that a PTR record exists. An address can have working forward DNS and no reverse DNS at all.
How to check a PTR record
The dig -x option performs a reverse lookup for either an IPv4 or IPv6 address. These commands show the syntax using documentation addresses; substitute an IP address you actually want to investigate. Do not expect the example addresses to have the illustrated PTR result.
dig -x 203.0.113.10
dig -x 2001:db8::10
Look in the ANSWER SECTION for a PTR record. If you are checking a public service, query its real public IP—not a private address seen inside your network. An empty answer can mean no PTR record is published; a timeout points instead to a lookup or network problem. Check the response status and the DNS server that answered before drawing a conclusion. The BIND dig manual documents -x and its automatic IPv4/IPv6 reverse-name construction.
Next, check the hostname returned by the PTR record:
dig mail.example.net A
dig mail.example.net AAAA
Again, mail.example.net is illustrative; use the hostname in your actual PTR answer. If the reverse lookup of 203.0.113.10 returns mail.example.net, and that hostname’s A record includes 203.0.113.10, the records forward-confirm one another. For IPv6, compare the original address with the hostname’s AAAA record.
Forward-confirmed reverse DNS is a consistency check, not authentication. It cannot establish that a service is trustworthy, that a message really came from the person named in its From header, or that the host is safe to connect to. Apply the authentication and security checks appropriate to the service.
Who can create or change a PTR record?
A PTR record belongs in the reverse DNS zone for the IP address, not in the ordinary forward DNS zone for your domain. Adding a PTR-looking record to the DNS dashboard for example.net will not normally change the reverse lookup for your server’s IP.
The IP block owner controls the reverse zone or delegates control of it. If a hosting provider or ISP assigned you the address, look for a “reverse DNS” or “PTR” setting in that provider’s control panel. If there is none, ask the provider to set it or explain its delegation process. If you control your own IP prefix, you can configure its reverse zone with a DNS provider that supports it. Cloudflare’s reverse-zone documentation makes this ownership distinction explicit.
Small IPv4 allocations can require special delegation arrangements because the conventional reverse-zone boundary may cover a larger block than the addresses you own. RFC 2317 describes one approach for classless IPv4 delegation. In practice, the IP provider’s instructions should be your starting point; setting an A record for your chosen hostname is a separate step.
Allow for DNS caching after a change. A resolver may continue returning an earlier answer until its cached record expires according to its time to live (TTL). Checking both the provider’s authoritative DNS and an ordinary resolver can help distinguish an unpublished change from a cached old result. For broader lookup problems, see how to fix DNS issues.
Why PTR matters for sending email
Mail receivers can use a sending server’s reverse DNS as one infrastructure check. Google’s current guidelines for sending to personal Gmail accounts require valid forward and reverse DNS for senders. They specify that a public sending SMTP IP must have a PTR record pointing to a hostname, and that hostname’s A or AAAA record must resolve back to the sending IP.
That requirement applies to mail sent to personal @gmail.com and @googlemail.com accounts; do not assume every receiving provider has exactly the same policy. If you use a third-party email service, the provider generally manages the PTR for its sending IPs. If you run your own mail server, verify the public IP actually used for outbound SMTP, its PTR result, and the matching forward record. A server with several interfaces or an outbound relay may send from a different IP than the one you first checked.
A matching PTR is not enough to ensure inbox delivery. Gmail also has sender authentication, TLS, and other requirements. PTR does not replace SPF, DKIM, or DMARC. If a connection fails before delivery, identify the SMTP stage and error first; the SMTP TLS port guide covers connection and TLS choices separately from DNS identity.
Should you resolve IPs to hostnames in logs?
Reverse DNS can add context to an unfamiliar client or server IP in a log. For instance, a hostname may help you identify infrastructure you operate or a known service. Treat the result as a clue alongside the original IP, timestamp, request, and other evidence—not as a reliable identity label.
If you want hostnames in logs, configure enrichment in a source application or collector only where it is useful. Keep the original IP and consider caching and a bounded lookup time. Resolving every event separately can add DNS traffic and delay a busy logging path. A hostname can also change after the event occurred, so a lookup performed days later may not reproduce what DNS returned at the time. Consider whether storing resolved names introduces privacy or retention concerns for your use case.
Fluxtail can help you search and inspect logs containing IP or hostname fields that your systems emit; this article does not assume it performs automatic PTR enrichment. If you are working through an incident, start with the original address and use reverse DNS as one optional investigative step. See log management for the broader workflow.
Common PTR results that need a closer look
- No PTR answer: Confirm you queried the public IP actually in use and ask its IP provider who controls the reverse zone. A missing PTR is different from a DNS timeout.
- PTR points to an old hostname: Update the reverse record at the IP provider and check that the new hostname has the appropriate A or AAAA record. Cached answers may persist until their TTL expires.
- PTR exists but forward DNS does not match: Check the hostname’s A or AAAA answer against the original IP. For mail, compare it with the public outbound SMTP address, not merely the server’s internal address.
- More than one PTR answer: Multiple PTR records are permitted by RFC 2181. Do not label them invalid solely because there are several. Check how the application or mail receiver you care about handles them, and verify the forward records for any name you intend to use.
- IPv6 works differently from IPv4: Each address family has its own reverse zone and records. A working IPv4 PTR does not provide reverse DNS for an IPv6 sending address.
The practical rule is simple: start with the actual IP, run a reverse lookup, check any returned hostname forward, and make changes through whoever controls that IP’s reverse DNS.