Reverse DNS on leased IPv4: setting up PTR records for mail and APIs

Reverse DNS maps an IP address back to a hostname. On your own address space you control it directly, but on leased IPv4 the reverse zone belongs to the holder, so you need to agree how PTR records will be managed. This article explains why PTRs matter for mail and APIs, the three common set-ups on leased space, and how to configure and test the records.

Why do PTR records matter?

A PTR record answers the question “what is the name of this address?”. Several systems care about the answer.

• Mail. Receiving mail servers routinely check that a sending IP has a PTR record and that the hostname resolves back to the same IP, known as forward-confirmed reverse DNS. Google’s sender guidelines, for example, require valid forward and reverse DNS for sending IPs. Missing or mismatched PTRs lead to rejected or junked mail.
• APIs and allowlisting. Partners who allowlist your IPs or review their logs find a clear hostname easier to trust and troubleshoot than a bare address or a name belonging to someone else.
• Operations. Traceroutes, logs and abuse reports are easier to read when addresses have meaningful names.
• Cloud BYOIP. Some providers, Google Cloud among them, use reverse DNS when validating a prefix you bring to them.

Many mail filters treat generic names that look like dynamic or residential ranges, such as ones containing “pool” or “dhcp”, with suspicion. Use names that clearly identify a server you operate.

Who controls reverse DNS on leased space?

Reverse zones are delegated through domain objects in the RIPE Database, and creating one needs authorisation from the maintainers on the holder’s inetnum. With leased space you’ll usually meet one of three set-ups.

The holder manages the PTRs

The lessor keeps the zone on its own nameservers and sets PTR records for you, through a control panel or on request. It’s simple, but every change depends on them, so ask how quickly requests are handled before you rely on it.

The holder delegates the zone to you

For a whole /24, the holder can create a domain object for the zone, for example 2.0.192.in-addr.arpa, pointing to your nameservers. You then manage the PTRs yourself. The RIPE NCC checks the listed nameservers before accepting the delegation, so set up and test the zone before the holder submits the object.

Classless delegation for smaller blocks

IPv4 reverse zones follow octet boundaries, so a /27 or /28 can’t be delegated as a zone of its own. The standard workaround, described in RFC 2317, is for the holder to publish CNAME records that point each address into a sub-zone hosted on your nameservers. It works well, but both sides have to configure it correctly.

If you announce leased space through a cloud provider, check how that provider handles PTRs for brought-in addresses, as some manage them through their own interface instead.

How should you set up the records?

Whichever model applies, the records follow the same rules.

1. Pick a naming scheme that identifies the service and your domain, such as mail1.example.com or api-eu1.example.com.
2. Create the forward record first. The A record for the hostname must point to the IP.
3. Create the PTR for the IP, pointing to that hostname. Use one PTR per address, since multiple PTRs on one IP confuse some checks.
4. Match your mail server’s HELO/EHLO name to the PTR hostname.
5. Publish SPF, DKIM and DMARC for the sending domain. Reverse DNS alone won’t get mail delivered, but its absence can stop it.
6. Repeat for IPv6 if you send or serve over it. Reverse zones sit under ip6.arpa in nibble format, and mail receivers often apply stricter checks to IPv6 senders.

Keep TTLs moderate while you’re setting things up, so corrections take effect quickly, then raise them once the records are stable.

How do you test, and what should you watch on leased space?

Check the result with standard tools:

• dig -x 192.0.2.25 should return your hostname.
• dig mail1.example.com A should return the same IP.
• Send a test message to an external mailbox and read the headers for the receiving server’s reverse DNS result.

Leased space needs a few extra checks:

• Old records. Make sure PTRs left by a previous user are removed or replaced.
• Reputation. Check the range against major blacklists before sending mail. A correct PTR won’t overcome a listed IP.
• End of lease. When the lease ends, control of the PTRs goes back to the holder. Move services to new addresses before that date.
• Abuse contact. Reports about your traffic may reach the holder first, so agree how they’ll be forwarded to you.

For mail, start new sending IPs at low volume and increase gradually. Receivers judge a new IP by its behaviour as well as its DNS.

How TACS can help

When you lease IPv4 from TACS, reverse DNS can be handled either way: PTRs set on request, or the zone delegated to your own nameservers. See Lease IPv4 for available ranges, and if a range you use turns up on a blacklist, our Blacklist delisting service can help.