PTR Records and Reverse DNS

The record that belongs to whoever holds the address

A PTR record maps an IP address back to a name, and for most domain owners it is the one record they cannot create. It does not live in your domain's zone. It lives in a separate zone attached to the address, and that zone belongs to whoever was allocated the address: your hosting company, your cloud provider, or your ISP.

This catches people out because every other record follows the domain. You buy a name, point it at nameservers, and from that moment you decide what an A record or an MX record says. Reverse DNS breaks the pattern: control follows the numbers, so the party who can publish mail.example.com for an address is the one who was given the address, not the one who registered the domain.

Some DNS panels offer a PTR record type in the drop-down anyway. Adding one there is inert, because a resolver asking about an address never looks in your domain's zone to answer. The record has to sit in the reverse zone, and only the address holder can put it there.

Reverse DNS is a second tree, written backwards

The reverse lookup is an ordinary DNS query for an ordinary name. What makes it look strange is the name being asked about. IPv4 addresses are queried under in-addr.arpa, with the octets in reverse order, so the address 10.2.0.52 is asked about as the name 52.0.2.10.in-addr.arpa. IPv6 addresses are queried under ip6.arpa, one hexadecimal nibble per label, also reversed, which turns a single address into thirty-two labels.

RFC 1035 is candid about the awkwardness and explains the reason in the same breath: the reversal, though awkward to read, allows zones to be delegated which are exactly one network of address space. Names are most specific on the left and addresses are most specific on the right, so the octets have to be flipped for the tree to branch the way DNS delegation branches.

Why your provider will not simply delegate it to you

A reverse zone can be delegated once. The natural unit for IPv4 is the /24, a block of 256 addresses, because that is where the octet boundary and the label boundary line up. Whoever receives that delegation administers the whole block, and a provider is not going to hand a shared block to one customer on it.

There is a documented way around this for smaller allocations. RFC 2317 describes doing in-addr.arpa delegation on non-octet boundaries for address spaces covering fewer than 256 addresses, using CNAME records inside the /24 that redirect individual addresses into a child zone somebody else runs. It needs no new software, and it needs the block holder to set it up for you deliberately. Most will not do that for a customer holding one address, which is not unreasonable.

What providers offer instead is a delegated field rather than a delegated zone. Several cloud platforms expose reverse DNS as a per-address setting the customer edits directly, as an attribute of an allocated address rather than as a zone of their own. That is write access to one value inside somebody else's zone, and it is all the situation requires.

Outbound mail is the reason to care

Almost nothing else checks. Browsers do not perform reverse lookups before loading a page, and a missing PTR record has no effect on a site, an API, or a game server. Mail is the exception, and a large one, because receiving systems treat reverse DNS as a cheap signal about whether an address was set up by somebody accountable.

Google's sender guidelines tell senders to ensure that sending domains or IPs have valid forward and reverse DNS records, and add that the sending IP must match the one the hostname in the pointer record resolves to. The requirement applies to small senders and high-volume senders alike. Microsoft's documentation is blunter about the consequence: mail servers that check reverse DNS as a basic anti-spam measure may reject messages or flag them as spam when they cannot find a valid record for the sending host.

This applies only to a server you send from directly. If mail leaves through a hosted platform or a relay, the sending addresses are theirs and the reverse DNS on them is already set. The problem belongs to anyone running an outbound mail server, including application servers that push transactional messages straight out.

Forward-confirmed reverse DNS, and why receivers pair the lookups

A receiving server rarely stops at the PTR record. The check that carries weight is the round trip, specified as the iprev method in RFC 8601: take the connecting IP, ask for the names it maps to, then look up each of those names and see whether the original IP comes back. The specification states the test formally and the result values are simply pass, where the reverse and forward lookup results were returned and were in agreement, and fail, where both produced results but they did not agree.

The second lookup exists because the first proves very little. The PTR record is written by the address holder, who can put any name in it, including somebody else's. Only the pair means anything, since producing a matching pair takes control of the reverse zone for the address and the forward zone for the name at once.

Two practical rules follow, both stated in RFC 1912 long before anyone used them for spam filtering. Make your PTR and A records match, and point the reverse name at a name carrying a real address record rather than an alias defined by a CNAME. Multi-homed hosts need every sending IP covered, not just the first one.

How to ask, and what to have ready

Publish the forward record first. The reverse name has to resolve back to the address, so the A or AAAA record for the hostname you plan to use must already exist and already point at that address. AWS makes this an explicit prerequisite before a reverse record can be set, and the same logic applies wherever you are asking: a reverse record pointing at a name that resolves nowhere fails the round-trip check as surely as no record at all.

Then send the request, with the specifics rather than a description of the problem:

• the exact IP, or each one in the range if you send from several
• the exact hostname you want returned, as a fully qualified name
• confirmation that the forward record is already published and matches
• the IPv6 addresses as well, if the server has them and sends over IPv6

Choose a hostname that describes the server, sits in a domain you control, and matches the name the server gives in its SMTP greeting, so all three values agree. Where a self-service field exists this takes minutes; where it does not it is a support ticket, and turnaround varies by provider, so do it before you need it.

What a PTR record proves on its own

Nothing. It is an assertion by an address holder, and every operator of a sending server, honest or otherwise, can make the same assertion. Even the forward-confirmed version is a consistency check rather than an identity check: it demonstrates that two zones agree about a name, not that the mail is legitimate. RFC 8601 itself concedes that there is some contention regarding the wisdom and reliability of the test.

The value is asymmetric, and that is the reason to bother. Correct reverse DNS wins you very little; missing reverse DNS costs you, because it is one of the few signals available before a message has been read. Treat it as a prerequisite met once, not a deliverability tactic, and spend the real effort on SPF, DKIM and DMARC.

One last piece of vocabulary. PTR and reverse DNS get used interchangeably, but the record type is broader: RFC 1035 defines its data as a domain name which points to some location in the domain name space, and service discovery protocols use PTR records in the ordinary forward tree to list service instances. Reverse DNS is the famous use, not the only one.