What Is a PTR Record? Reverse DNS Explained

What a DNS PTR record is and where it is stored

A PTR (pointer) record maps one IP address back to one hostname — the reverse of an A record for IPv4 or an AAAA record for IPv6. It sits in a separate reverse zone, in-addr.arpa for IPv4 and ip6.arpa for IPv6, which the owner of the address block delegates. Only that owner can create or change it.

IPv4 reverse names are written backwards, one octet at a time. The address 203.0.113.45 is looked up at 45.113.0.203.in-addr.arpa, so the record that answers dig -x 203.0.113.45 is stored under that name, not under your domain.

IPv6 works the same way at a finer grain: the address is expanded, reversed and split into four-bit nibbles under ip6.arpa. That length is why most hosts, WebJi® included, make the change for you rather than exposing it in a control panel.

• IPv4: one PTR per octet-reversed name under in-addr.arpa.
• IPv6: one PTR per nibble-reversed name under ip6.arpa.
• Publish one entry per address; extra PTRs make the answer order unpredictable.

How reverse DNS differs from forward DNS

Forward DNS turns a hostname into an IP address; reverse DNS turns an IP address into a hostname. The forward answer comes from an A or AAAA record in your domain zone, while the reverse answer comes from a PTR record in the network owner's zone — two lookups administered by two different teams.

You can edit your own domain zone in cPanel or at your DNS provider because you own the name. The reverse zone is delegated by whoever holds the IP range, so a domain owner usually has read-only visibility of the PTR and must ask for a change. Mail routing uses both directions: the MX record decides where a message is delivered, and the PTR on the sending IP is checked before the receiver accepts it.

Who controls the PTR record for your IP address

The PTR record belongs to the organisation that holds the IP address block — your hosting provider, your ISP or a cloud vendor — because reverse zones are delegated down from the regional registry that issued those addresses. Your domain registrar has no access to it.

On shared, reseller and most managed plans, the server IP already carries a PTR set by the host, usually to a hostname such as server1.yourhost.example. You cannot add or edit it in cPanel, Plesk or WHM, and no DNS record you create at your own domain overrides it.

On a VPS or dedicated server with a leased IP, the provider still owns the block and publishes the reverse entry on request. If an IP range is transferred, the delegation moves with it and the new holder maintains the PTR.

How to request a PTR change from your host

Email or open a ticket with the IP address, the exact hostname you want the PTR to return, and the reason — for example outbound mail from a CRM. The host edits the reverse zone; nothing you do in your own DNS panel replaces that request.

1. Confirm the sending IP: read the Received header of a test message, or run curl -4 ifconfig.me from the server itself.
2. Create the forward record first: add an A (or AAAA) record for mail.example.com pointing at that same IP, and wait until it resolves.
3. Send the request with the IP, the hostname and the use case. Say so if the IP is shared, because a shared IP's PTR affects every customer on it.
4. Wait for the zone update and for old TTLs to expire — often under an hour, but allow up to a day on slow resolvers.
5. Verify both directions: dig -x on the IP returns the hostname, and dig on the hostname returns the IP.

WebJi® sets PTR entries on request for VPS and outgoing mail IPs, and the same ticket can confirm SPF and DKIM on business email hosting.

The forward-confirmed reverse DNS (FCrDNS) test

Forward-confirmed reverse DNS means the receiver looks up the PTR, then looks up that hostname forward and checks it returns the same IP. Both directions must agree before the connection is treated as legitimate.

A PTR pointing to a name with no A record fails FCrDNS even when dig -x returns an answer. So does a PTR that returns an ISP pool name such as static-45-113-0-203.isp.example, or a generic hostname unrelated to the domain sending the mail.

Order matters: publish the forward record first, then ask for a PTR that names it. If the sending host is renamed later, update the A record and the PTR together so the pair never drifts apart.

How to check a PTR record with dig and nslookup

Run dig -x followed by the IP address. A published PTR returns a line containing "PTR" and your hostname; an empty answer section or NXDOMAIN means no PTR is set for that address.

• dig -x 203.0.113.45 +short prints just the hostname.
• nslookup 203.0.113.45 prints the name and the server that answered.
• dig +short mail.example.com confirms the forward side returns the same IP.

Test from outside your own network. A resolver that cached a negative answer keeps returning nothing until the TTL expires, so repeat the check after an hour before assuming the change failed.

Why a missing or mismatched PTR bounces email

Receiving servers use the PTR as one spam signal, and a missing, generic or mismatched entry can push a message into rejection or the spam folder. Gmail and Outlook expect a PTR that matches the sending hostname, and they weigh it together with SPF, DKIM and DMARC rather than on its own.

Typical symptoms are a 550 rejection that names reverse DNS, mail accepted from one server but refused from another, or messages landing in spam only when sent from a new IP. Read the bounce text first — it usually quotes the lookup that failed.

A PTR is not reputation repair. If the IP is already on a blocklist, fixing reverse DNS will not clear it; check the sending IP against blocklists, request delisting, then retest. The wider setup is covered in the guide to what an SMTP server does.