Reverse DNS for leased IP space: PTR records, delegation and mail

Reverse DNS maps an IP address back to a name, through a PTR record. For most services it is a detail. For a mail server it is not: Google requires every address that sends to Gmail to have a PTR record whose name resolves back to the same address, and many other receivers look for the same match. With leased space the record sits in a zone you do not control by default, so it is worth knowing who sets it and how.

How reverse DNS works

A forward lookup turns a name into an address. A reverse lookup turns an address into a name, by reading its digits backwards under a special domain: the PTR record for 203.0.113.10 lives at 10.113.0.203.in-addr.arpa. IPv6 works the same way under ip6.arpa, one hexadecimal digit at a time.

The zone for a /24, 113.0.203.in-addr.arpa in this example, is delegated by the registry to the nameservers listed for it. In the RIPE NCC service region those are the nserver lines of a domain object in the RIPE Database. Whoever runs those nameservers decides what the PTR records say.

dig -x 203.0.113.10 +short

Who controls it for leased space

The registry delegates the reverse zone to the holder of the block, so for leased space that is the lessor, not you. In practice there are two arrangements.

• The lessor sets the records you ask for. You send the name for each address, the lessor publishes the PTR records. It is the simplest arrangement and enough for nearly everyone.
• The lessor delegates the zone to you. With a domain object pointing at your nameservers, you manage the PTR records yourself. That works for a whole /24. For a smaller piece, the lessor can hand over just your addresses with the classless delegation described in RFC 2317: CNAME records in its zone that point into a zone on your nameservers.

Either way, ask before the lease starts how changes are made and how quickly they appear, because a mail server you cannot give a proper name is a mail server that does not deliver.

What mail receivers check

Google's sender guidelines spell out the rule for every sender, not only bulk ones: "The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname." That hostname must in turn have an A record, or AAAA for IPv6, that resolves to the same address. This is forward-confirmed reverse DNS: address to name, and name back to the same address. Gmail answers a missing or mismatched record with a temporary or a permanent error, and has been enforcing its rules more strictly since November 2025.

Two habits go with it. Use the same name in the greeting your mail server sends (HELO or EHLO), and choose names that look like a server rather than a pool. Yahoo, which requires reverse DNS from every sender, asks for PTR records that are "meaningful, non-generic", and some filters treat a name such as 203-0-113-10.dynamic.example.net as a sign of a home connection.

Setting it up, step by step

1. Choose one name per sending address, under a domain you control: mail1.example.com.
2. Create the forward record: mail1.example.com. A 203.0.113.10.
3. Set the PTR record: 10.113.0.203.in-addr.arpa. PTR mail1.example.com., through your lessor or in your delegated zone.
4. Check both directions from a network outside your own:

dig -x 203.0.113.10 +short        # expect: mail1.example.com.
dig +short mail1.example.com A    # expect: 203.0.113.10

1. Make the mail server use the same name. In Postfix that is myhostname = mail1.example.com.

Mistakes that break delivery

• A PTR record without a matching A record. The reverse lookup works and the forward check fails.
• Two PTR records for one address. Checks disagree about which one counts. Keep one.
• A rename on a long TTL. Resolvers keep serving the old name until the TTL runs out. Lower it a day before a planned change.
• IPv6 forgotten. If the server sends over IPv6, its IPv6 address needs the same treatment under ip6.arpa, with an AAAA record to match.
• A delegated zone on nameservers that stop answering. The registry only checks the nameservers when the delegation is made. If they fail later, every reverse lookup for the block fails with them.

Where RTM Networks fits

Reverse DNS is part of every lease at no extra cost: tell us the name for each address and we set the PTR records (lease IPv4). If the addresses will send mail, their reputation matters as much as their names, so we check every IPv4 block we lease against blocklists before delivery and every day while you have it (keeping a block clean).