Set a PTR Record on Your VPS

Every support ticket about reverse DNS starts the same way: someone added a PTR record in Cloudflare or cPanel, it did nothing, and they conclude DNS is broken. It is not. PTR records live in the in-addr.arpa tree, which is delegated by IP address ownership, and your VPS provider owns the address. The control is in their panel, attached to the IP — never to your domain.

Where is the rDNS setting at a typical VPS provider?

The field is nearly always on the *IP*, not the server, and it is labelled some variation of Reverse DNS, rDNS, or PTR. The exact navigation differs and providers redesign their panels regularly, so treat the following as patterns rather than fixed paths — check your provider's current documentation for the precise clicks.

Two consequences of "the field is on the IP". First, if you detach and reattach a floating IP, or rebuild the instance on a new address, the PTR does not follow — it belongs to the old address. Second, IPv4 and IPv6 are separate entries. A dual-stack box that sends over IPv6 needs an ip6.arpa entry too, and most panels expose that as a second row next to the v4 one.

Create the forward record first

Receivers do not check the PTR in isolation; they run forward-confirmed reverse DNS. They take the hostname your PTR returns, resolve it forward, and require the answer to contain the original IP. A PTR pointing at a hostname with no matching A record fails that check, and several providers now validate the forward record before they will even accept the PTR value you type.

So do it in this order: publish mail.example.com A 203.0.113.25 in your own DNS zone, confirm it resolves, then set the PTR for 203.0.113.25 to mail.example.com. If the domain is on Cloudflare, that A record must be unproxied (grey cloud) — a proxied record resolves to Cloudflare's anycast addresses, not your server, and the forward confirmation fails. Verify with the A Record Lookup.

Match the PTR to your mail server's HELO name

The PTR hostname, the forward A record, and the name your MTA announces in its EHLO command should all be the same string. Receivers score the mismatch: a server that connects from an IP called mail.example.com but introduces itself as localhost.localdomain looks misconfigured at best. Default installs get this wrong constantly, because the MTA takes its HELO name from the system hostname, which the provider set to something like ubuntu-2gb-nbg1-1.

# Postfix — what will it announce?
postconf myhostname smtp_helo_name

# Set it (then reload)
postconf -e 'myhostname = mail.example.com'
systemctl reload postfix

# Exim uses primary_hostname in the main configuration
exim -bP primary_hostname

# What the system itself thinks its FQDN is
hostname -f

In Postfix, smtp_helo_name defaults to $myhostname, so setting myhostname is usually enough; set smtp_helo_name explicitly only when the outbound identity must differ from the machine's own name. Also set the system hostname to the FQDN so hostname -f agrees — several other services read it.

Verify with dig -x

Reverse DNS changes propagate like any other DNS change, but the TTLs in provider-run reverse zones are often long, and the delegation itself can take a few minutes to update after you save. Check both directions:

# 1. Reverse — does the IP have a name?
dig -x 203.0.113.25 +short
# mail.example.com.

# 2. Forward — does that name come back to the same IP?
dig +short A mail.example.com
# 203.0.113.25

# Both in one go
dig +short -x 203.0.113.25 | xargs -I{} dig +short A {}

# IPv6, if the server sends over v6
dig -x 2001:db8::25 +short
dig +short AAAA mail.example.com

# Without dig
host 203.0.113.25

The two addresses in steps 1 and 2 must match exactly. If step 1 is empty after fifteen minutes, the panel did not commit the change or the block is not delegated for customer rDNS — that is a ticket to the provider, not something you can fix.

Once rDNS is clean, confirm the rest of the sending posture: the Email Deliverability Test checks SPF, DKIM, DMARC, MX, and PTR together, and the Email Blacklist Check tells you whether the IP carries baggage from a previous tenant. New VPS addresses are recycled constantly and inheriting a listed IP is common.

What if you are on a shared IP?

A PTR record is per-IP, and an IP has exactly one meaningful PTR. On shared hosting, dozens of customers send from the same address, so the PTR names the *host's* server — something like srv142.hostingcompany.net — and that is correct. You cannot and should not change it, and no receiver expects it to match your domain.

• Verify it exists and forward-confirms. That is the only thing that matters on a shared IP. If dig -x returns nothing, open a ticket with the host — it affects every customer on that address, so they will usually fix it.
• Do not expect your domain in the PTR. Alignment for DMARC comes from SPF and DKIM, not from reverse DNS. A host-branded PTR does not hurt DMARC at all.
• Watch the neighbours. On shared IPs your delivery reputation is pooled with everyone else on the address. If the Email Blacklist Check shows listings you did not earn, that is the trade-off.
• Move to a dedicated IP or a relay if it matters. Either buy a dedicated IP from the host and set the PTR yourself, or stop sending from the box entirely and relay through an authenticated smarthost on port 587, where the provider's IPs and reputation do the work. Is Port 25 Blocked? covers that path.

For why receivers insist on this at all, and what the current bulk-sender requirements actually say, read PTR Records Are Now Required by Yahoo and Microsoft. The record format itself is covered in the PTR record reference, and if you need to confirm which IP your mail is really leaving from, paste headers into the Email Header Analyzer.