PTR records and reverse DNS

What a PTR record is

A PTR record maps a name to another name. That is all it does at the protocol level: the data field is a domain name, and there is nothing address-specific about the record type itself. What makes it reverse DNS is where it is published.

For an IPv4 address, the name is built by writing the four octets in reverse order and appending in-addr.arpa. For IPv6, each of the 32 hexadecimal digits becomes its own label, in reverse order, followed by ip6.arpa. Reversing is what makes the tree work: DNS delegation runs from the right of a name to the left, and address allocation runs from the left of an address to the right, so the address has to be turned around before the two line up.

RFC 3596 section 2.5 defines the IPv6 form and gives a worked example, reproduced below alongside two documentation addresses.

203.0.113.10
  becomes  10.113.0.203.in-addr.arpa.

2001:db8::1
  becomes  1.0.0.0.0.0.0.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.

4321:0:1:2:3:4:567:89ab   (the example in RFC 3596 section 2.5)
  becomes  b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.arpa.

Why the PTR is not yours to publish

The in-addr.arpa and ip6.arpa trees are delegated along with the address space itself. The regional internet registry delegates a block to the organisation it allocated the addresses to, that organisation delegates smaller pieces to its customers, and the PTR record for your server sits at the bottom of that chain, inside a zone that belongs to whoever gave you the address.

So the PTR for a server on a rented IP is published by the hosting provider, the cloud platform or the ISP. It is not in your domain's zone, it cannot be added at your registrar, and no amount of editing example.com's DNS will produce it. This is the single most common misunderstanding about reverse DNS, and it is why our own reverse-DNS findings are attributed to the address provider rather than to your DNS host: a recommendation that says add a PTR record to your DNS would send you to a control panel where the record cannot exist.

If you do not know who holds the address, look it up. A WHOIS or RDAP query on the address returns the organisation the block is allocated to, and that is the party to ask. It is frequently not the company you buy hosting from, because resellers sit on top of someone else's allocation.

The exception is an organisation large enough to have its own address allocation from a registry. If your employer holds its own block, the reverse zone is delegated to your own nameservers and the PTR record is yours to write, in a zone file that sits alongside your forward zones.

whois 203.0.113.10

# or query RDAP directly, which returns structured JSON
curl -s https://rdap.arin.net/registry/ip/203.0.113.10

How reverse delegation works for a /24

A /24 is the clean case, because the boundary between the third and fourth octet is also a label boundary in the reverse name. The whole of 203.0.113.0/24 maps to the zone 113.0.203.in-addr.arpa, and that zone can be delegated with an ordinary NS record, exactly like any forward zone.

That is why a provider selling you a full /24 can hand you the reverse zone outright: they add NS records pointing 113.0.203.in-addr.arpa at your nameservers, and from then on every PTR under it is yours. Ask for this explicitly if you hold a /24 and expect to change reverse names often; it removes the provider from the loop entirely.

Anything larger than a /24 splits into several such zones, one per /24, with no special handling needed. A /22 is four zones.

Smaller than a /24: the RFC 2317 arrangement

Below a /24 the boundary no longer lines up. If you have been given 203.0.113.0/29, there is no label in the reverse tree that corresponds to your eight addresses, so the zone cannot simply be delegated to you.

RFC 2317 defines the workaround that is used in practice. The provider keeps the /24 zone, creates a sub-zone whose name contains a slash or a dash and is therefore not a real address label, delegates that sub-zone to you with an NS record, and then publishes one CNAME per address in the /24 pointing at the corresponding name inside your delegated zone. A resolver following the CNAME ends up in your zone and reads your PTR record from it.

The naming convention is not standardised beyond the RFC's own examples. Providers use 0/25, 0-25, 0_25 and other variants, and it does not matter which, as long as the CNAMEs and the delegation agree. What you need from the provider is the exact name of the zone they delegated to you, because that is the origin your PTR records must sit under.

The practical consequence: with a small allocation you either take an RFC 2317 delegation and run the reverse zone yourself, or you keep asking the provider to edit each PTR. Most providers of small allocations do the second, through a form or a ticket.

; in 2.0.192.in-addr.arpa, held by the address block owner
0/25            NS      ns.provider.example.
1               CNAME   1.0/25.2.0.192.in-addr.arpa.
2               CNAME   2.0/25.2.0.192.in-addr.arpa.
; ... one CNAME for every address in the delegated range

; in 0/25.2.0.192.in-addr.arpa, delegated to you
$ORIGIN 0/25.2.0.192.in-addr.arpa.
@               NS      ns.provider.example.
1               PTR     mail.example.com.
2               PTR     mail2.example.com.

IPv6 reverse zones, and how long the names get

Every IPv6 reverse name is exactly 32 labels plus ip6.arpa, because each hexadecimal digit is its own label whether or not it is a leading zero. There is no compressed form: the :: notation exists in the address, not in the reverse name, so you must expand the address fully before reversing it.

Delegation is far easier than in IPv4, because every IPv6 prefix that is a multiple of four bits falls exactly on a label boundary. A /48 is a zone 12 labels deep, a /56 is 14, a /64 is 16, and each is delegated with a plain NS record. There is no equivalent of the RFC 2317 problem unless a prefix length is not a multiple of four, which essentially never happens in assignments.

The awkward part of IPv6 reverse DNS is volume rather than structure: a /64 contains more addresses than you can enumerate, so nobody publishes a PTR for every one. For a mail server, publish a PTR for the specific address the server sends from and ignore the rest of the range. Our checks, and receivers' checks, only ever look at the address a connection actually came from.

Use dig -x with the address and it builds the reverse name for you. It is worth doing that once by hand for an IPv6 address, though, so the shape of the name is not a surprise the first time a provider's form rejects it.

2001:db8::/32   ->  8.b.d.0.1.0.0.2.ip6.arpa            (8 labels)
2001:db8:abcd::/48
                ->  d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa    (12 labels)
a single address
                ->  32 labels, always

Forward-confirmed reverse DNS: the check receivers actually apply

A PTR record on its own proves nothing, because the person who controls the address block can point it at any name at all, including one belonging to somebody else. The check that carries weight is the round trip: take the connecting address, look up its PTR name, then resolve that name forward and confirm it comes back to the same address. That is forward-confirmed reverse DNS, and RFC 8601 section 2.7.4 registers it as the iprev authentication method so the result can be recorded in an Authentication-Results header.

The forward half is the half you control, and it is the half people forget. If the provider sets the PTR to mail.example.com, you must publish an A record for mail.example.com pointing back at that address, in your own zone. Half a pair is treated much like no pair at all.

Google's published sender guidelines state the requirement directly: the public IP address of a sending SMTP server must have a PTR record that resolves to a hostname, and that hostname must have an A or AAAA record resolving back to the same address. Microsoft's published high-volume sender requirements name SPF, DKIM and DMARC rather than reverse DNS, so the strongest primary-source case for PTR is Google's; we have not found an equivalent explicit PTR statement in Microsoft's high-volume announcement and do not claim one.

Our scanner reports a missing PTR as a failure worth real points, and a PTR that does not confirm forward as a failure too, because both are visible to every receiver on every connection. A PTR that simply differs from your MX hostname is only a warning: it is legal, and on hosted mail it is normal.

The HELO name is the third name that has to agree

When your server opens an SMTP connection it announces itself with EHLO followed by a hostname. RFC 5321 section 4.1.1.1 says that name should be the fully qualified domain name of the sending host, and section 4.1.4 allows a receiver to record a mismatch between that name and the connecting address but says it must not refuse the message on that basis alone. In practice receivers score it rather than reject on it.

The configuration you want is three names that agree: the PTR for the address, the forward record for that name, and the EHLO name the server announces. When all three are the same string, a receiver gets three independent confirmations of one identity. When they disagree, it gets none, and a filter that weighs consistency has nothing to weigh.

The EHLO name is set in your mail server's own configuration, not in DNS: myhostname in Postfix, smtp_helo_name in some relays, the HELO field in a sending application. A default left as localhost or as the machine's short hostname is a very common and completely self-inflicted signal.

One thing to avoid: the EHLO name does not have to be your domain, and it should not be your domain's apex if the apex resolves to your website rather than to the mail server. Use the mail server's own hostname.

Setting a PTR at common hosts, as of September 2026

The paths below were read from each provider's own documentation in September 2026. Dashboard wording and menu positions drift, so treat them as a starting point and confirm against the provider's current documentation rather than against this page.

• Amazon EC2. Elastic IPs, select the address, Actions, Update reverse DNS. AWS documents one prerequisite that trips people up: a forward A record resolving to that Elastic IP must exist before you set the reverse name. AWS also notes that once a reverse DNS record is attached, the Elastic IP is locked to your account and cannot be released until the record is removed.

• Google Cloud. PTR is a property of the VM's external access config, not a DNS record you create. The gcloud command is below. Google requires you to prove ownership of the domain, one accepted method being an A record for that name pointing at the VM's external address. Records can be added only to a VM's primary network interface, and are not available for load balancer frontends or Cloud NAT addresses.

• Azure. Reverse DNS is the reverseFqdn property of the public IP address resource. Azure only creates the record when the name you give already resolves to a public IP in the same subscription, or is a CNAME to one. Microsoft documents that this cannot be set through the portal for Cloud Services, so the CLI or PowerShell is the route.

• DigitalOcean. The PTR is derived from the resource name: name the Droplet or reserved IP as a fully qualified domain name, such as mail.example.com, and the PTR follows. A short name such as my-droplet produces no usable PTR.

• Anyone else. Open a ticket with the organisation that WHOIS names as the holder of the address, give them the address and the exact hostname you want, and publish the matching forward record first so they can verify it.

# AWS: set the reverse name on an Elastic IP
aws ec2 modify-address-attribute \
  --allocation-id eipalloc-abcdef01234567890 \
  --domain-name mail.example.com

# Google Cloud: set the PTR on a VM's external address
gcloud compute instances update-access-config INSTANCE_NAME \
  --public-ptr \
  --public-ptr-domain mail.example.com

# Azure: set the reverse FQDN on a public IP resource
az network public-ip update \
  --resource-group my-group --name my-ip \
  --reverse-fqdn mail.example.com

How to verify it worked

Check both directions, in that order, and do not stop after the first one. dig -x builds the reverse name for you from either an IPv4 or an IPv6 address.

A PTR change is a DNS change like any other, so it is bounded by the TTL of the records involved and by whatever schedule the provider runs their zone updates on. Minutes is typical, a few hours is not alarming, and a day with nothing visible means the request did not take effect rather than that you are waiting.

If the forward lookup returns a different address from the one you started with, the pair does not confirm, and receivers will treat it as unverified. That usually means the A record points at a load balancer or a CDN while mail leaves from a different address.

# 1. address to name
dig +short -x 203.0.113.10
# expect: mail.example.com.

# 2. name back to address
dig +short mail.example.com
# expect: 203.0.113.10

# what dig -x is actually querying, if you want to see it
dig +noall +answer PTR 10.113.0.203.in-addr.arpa

Where PTR matters, and where it does not

It matters for any host that opens outbound SMTP connections. That is the whole of the practical case, and it is a strong one: a missing or unconfirmed PTR gets mail rejected at connection time, before content filtering, often with a bounce message the sender cannot interpret.

It is useful, without mattering, for reading your own operational data. Traceroute output, web server logs, SSH logs and firewall logs are all easier to read when addresses resolve to names, and a sensible naming scheme in your reverse zone pays for itself the first time you read an incident timeline.

It does not matter for a website. No browser checks reverse DNS, no certificate authority looks at it, and no search engine ranks on it. A web server with no PTR is not misconfigured. Some older documentation implies otherwise; it is describing mail.

It is not a security control. A PTR record asserts a name and nothing else, and the address block holder can point it anywhere, which is precisely why the forward confirmation exists. Do not authenticate anything on the strength of a reverse lookup alone.

If your mail is hosted by a provider, none of this is your work. The addresses your mail leaves from belong to that provider, their reverse names name their infrastructure, and that is the correct state. Our own name-mismatch check is a warning rather than a failure for exactly this reason.

What commonly goes wrong

• Trying to add the PTR in your own DNS. Many control panels will happily accept a record called a PTR record in your forward zone. It is published at a name nobody will ever query, it changes nothing, and it hides the real problem behind a record that looks present.

• Setting the PTR and forgetting the forward record. The reverse lookup now returns a name that resolves nowhere, the full-circle check fails, and receivers treat the sender as unverified, much as they would with no PTR at all.

• Leaving the provider's generated name in place. A name containing the address itself is the oldest heuristic in spam filtering, because consumer broadband ranges were named that way. It is a weak signal rather than a rule, but it is free to fix if the provider will change it, and if they will not, send through a relay instead.

• Pointing the PTR at the domain apex. example.com usually resolves to a web server or a CDN, so the forward lookup returns an address that is not the mail server and the pair does not confirm. Use a dedicated hostname for the mail server.

• Changing the address and leaving the old PTR behind. A new instance means a new address with whatever reverse name the provider assigns; the reverse record you set up last year is attached to an address you no longer have.

• Requesting a PTR for a NAT or load balancer address. The address a receiver sees is the one mail actually leaves from, which behind NAT is often not the address you configured. Check what the connection presents before opening a ticket.

• Assuming an IPv6 sender is exempt. If your server has an AAAA record and working IPv6, mail will leave over IPv6, and the IPv6 address needs its own PTR and its own forward record. A common outcome is mail that is accepted over IPv4 and rejected over IPv6, which reads as intermittent.