Why can I not add a PTR record in my DNS panel?

Because PTR records live in the reverse zone under `in-addr.arpa` or `ip6.arpa`, which is controlled by whoever owns the IP block — your hosting provider, ISP, or a regional registry. Adding a PTR to your own forward zone has no effect, since reverse queries never reach it. Set it through your provider's rDNS control or by ticket.

What is forward-confirmed reverse DNS?

A two-step check: look up the PTR for an IP, then look up the A or AAAA record for the hostname it returns, and confirm the original IP appears. It proves the same party controls both the address and the name. Receiving mail servers rely on it because a PTR alone can be set by anyone holding the block.

Do I need a PTR record for my website?

No. Web browsers never do reverse lookups. PTR matters for outbound mail servers, and to a lesser degree for logging and abuse attribution. A web-only host with no PTR loses nothing operationally.

Can one IP address have multiple PTR records?

It is technically legal but a bad idea. Receivers may check only the first answer returned, and the ordering is not stable, so behaviour becomes unpredictable. Publish exactly one PTR per address, matching the hostname your mail server announces in EHLO.

What should my mail server's PTR point to?

A hostname in a domain you control that has a matching A (and AAAA, if you send over IPv6) record pointing back to the same IP — typically something like `mail.example.com`. It should also match the name your MTA uses in its EHLO greeting. Generic ISP-style names are treated as low-reputation by many receivers.

How long does a PTR change take to take effect?

It depends on the reverse zone's TTL, which the block owner sets, plus however long your provider takes to push the change into their zone. Some cloud providers apply it in seconds; some ISPs take a business day. Verify with `dig -x ` against a public resolver rather than assuming it is live.

PTR Record: Syntax, Examples & Troubleshooting

A PTR record maps an address back to a hostname. It lives in a special reverse zone — in-addr.arpa for IPv4, ip6.arpa for IPv6 — controlled by whoever owns the IP block, not by the domain owner. Mail servers depend on it.

What does a PTR record do?

PTR is record type 12 from RFC 1035. Its RDATA is a single hostname. Forward DNS answers "what address is this name?"; PTR answers the reverse. But DNS has no reverse index, so the reverse lookup is implemented as an ordinary forward lookup in a purpose-built namespace: the address is reversed, turned into labels, and appended to in-addr.arpa.

8.8.8.8 becomes 8.8.8.8.in-addr.arpa — the octets reversed because DNS reads from most-specific label to least, while IP addresses read the other way. IPv6 goes further: each of the 32 hex nibbles becomes its own label, reversed, under ip6.arpa. That is why the IPv6 example above is 32 labels long. dig -x builds these names for you.

Reverse DNS (PTR) Lookup

Hostname behind an IP — required for mail servers

PTR syntax and fields

Field	Example	Meaning
Name (owner)	`8.8.8.8.in-addr.arpa.`	The reversed address under `in-addr.arpa` (IPv4) or `ip6.arpa` (IPv6, nibble-reversed).
TTL	`19839`	Cache lifetime, set by the reverse-zone operator, not by you.
Class	`IN`	Internet class.
Type	`PTR`	Record type 12.
RDATA	`dns.google.`	One fully qualified hostname. Not an IP, not a URL, and conventionally exactly one per address.

Who controls the reverse zone?

This is the part that surprises people. You cannot add a PTR record to your own DNS zone and have it work. Reverse zones are delegated down the IP allocation chain: IANA delegates to the regional registries (ARIN, RIPE, APNIC, LACNIC, AFRINIC), they delegate to the ISP or hosting provider that holds the block, and that provider delegates to you only if you hold a large enough allocation.

VPS or cloud instance. Your provider owns the block. You set the PTR through their control panel or API — often a field labelled "reverse DNS", "rDNS", or "PTR" on the instance or the floating IP. See Set a PTR record on your VPS.
Colocated or leased IPs from an ISP. You usually open a ticket, or the ISP delegates the reverse zone to your nameservers with NS records under in-addr.arpa.
A /24 or larger of your own. The RIR or your upstream delegates the whole reverse zone to you and you run it like any other zone.
Smaller than a /24. IPv4 reverse delegation is byte-aligned, so a /27 cannot be delegated cleanly. RFC 2317 defines a CNAME-based workaround, but in practice most providers just set the PTR for you on request.
Shared hosting. You generally cannot set it at all, and the PTR points at the host's generic name. This matters if you send mail from that IP.

The single most common PTR support ticket is a customer who added a PTR record to their own zone file and cannot understand why it does nothing. It does nothing because the query never reaches their zone — it goes to in-addr.arpa.

Forward-confirmed reverse DNS (FCrDNS)

A PTR on its own proves nothing, because the person who set it and the person who owns the hostname may be unrelated. Receivers therefore check both directions, a test called forward-confirmed reverse DNS:

Take the connecting IP and look up its PTR — say 8.8.8.8 returns dns.google.
Look up the A record (or AAAA) for dns.google.
If that forward lookup includes the original IP, the pair is forward-confirmed. If not, the PTR is unverified and effectively worthless for reputation purposes.

# 1. Reverse
dig +short -x 8.8.8.8
# dns.google.

# 2. Forward on the result
dig +short dns.google A
# 8.8.8.8
# 8.8.4.4

# The original IP appears in the forward answer, so FCrDNS passes.

Both directions must agree. Setting the PTR without a matching A record is the most common half-configuration.

You control step 2 even when your provider controls step 1 — so create the A record for your mail hostname first, then ask the provider to set the matching PTR.

PTR and email deliverability

For a mail server, reverse DNS is not optional. Receiving MTAs check the connecting IP's PTR before they look at anything else, and the major mailbox providers include a valid PTR in their published sender requirements alongside SPF, DKIM, DMARC alignment, one-click unsubscribe for bulk mail, and low spam-complaint rates. Missing or generic reverse DNS is one of the cheapest reasons to be rejected.

Set the PTR to your mail hostname, for example mail.example.com — a name in a domain you control, with a matching A record.
Make the HELO/EHLO name match. The name your MTA announces in EHLO should be the same as the PTR. Mismatches score badly at several receivers.
A generic PTR is nearly as bad as none. 203-0-113-25.dynamic.isp.example looks like a residential or dynamic host and is scored accordingly. Some receivers reject on generic-looking reverse DNS alone.
IPv6 senders need a PTR too, and the requirement is enforced more aggressively than on IPv4. If you cannot set an IPv6 PTR, disable IPv6 on the outbound MTA rather than sending without one.
One PTR per address. Multiple PTRs for one IP are legal but confuse receivers, since they may check only the first answer returned.

Background on the current requirements is in PTR records are now required by Yahoo and Microsoft. Once reverse DNS is set, verify the rest of the sending stack with the deliverability test and confirm the IP is clean with the blacklist check.

TTL guidance

Reverse-zone TTLs are usually set by the block owner and you may have no control at all — the values in the examples above range from about twenty minutes to several hours. If you do run your own reverse zone, 3600 to 86400 is right: PTR records almost never change, and long TTLs reduce load on your nameservers from every mail server that checks you. When you are about to renumber a mail server, drop the PTR TTL ahead of the move if your provider lets you; if it does not, plan for the old value to linger.

Common PTR mistakes

Adding a PTR to your forward zone. It has no effect. Reverse queries go to in-addr.arpa.
Setting the PTR without the matching A record. FCrDNS fails and the PTR provides no benefit.
PTR pointing at a name with no A record at all, usually because the hostname was decommissioned and the PTR was never updated.
PTR value containing an IP address. The RDATA is a hostname. Some panels accept an IP and produce nonsense.
Assuming PTR affects inbound mail. It governs how *your outbound* connections are judged. Inbound routing is MX records.
Ignoring IPv6. A server that sends over IPv6 with no IPv6 PTR gets rejected by receivers that would have accepted the same message over IPv4.
Setting a PTR on a shared or NAT egress IP you do not control. Whatever the provider set is what receivers see, and changing it may not be possible — if you need reliable mail from that host, use a relay or a dedicated IP.

Check it with dig

# Reverse lookup, IPv4
dig +short -x 8.8.8.8

# Reverse lookup, IPv6
dig +short -x 2001:4860:4860::8888

# The fully expanded reverse name, if you want to see it
dig +noall +answer -x 1.1.1.1

# Query the reverse zone name directly (equivalent to -x)
dig +short 8.8.8.8.in-addr.arpa PTR

# Who is authoritative for the reverse zone? This tells you who to ask.
dig +short 8.8.8.in-addr.arpa NS

# host(1) does the same thing more tersely
host 8.8.8.8

The NS query on the reverse zone identifies which operator can actually change the record for you.

To find out who holds the address block in the first place, use the ASN lookup or a WHOIS lookup on the IP. Confirm your own egress address with What's My IP.

PTR Record: syntax, examples, and troubleshooting

Example PTR record