How to Set Up Reverse DNS (PTR) for a Mail Server

If you run your own mail server, a correct PTR record (reverse DNS) is non-negotiable. Big providers like Gmail and Outlook reject or spam-folder mail from IPs whose reverse DNS is missing, generic, or doesn't match the sending hostname. This guide explains reverse DNS and shows you how to set the PTR right.

What reverse DNS is

Forward DNS maps a name to an IP (an A record). Reverse DNS does the opposite: it maps an IP to a name using a PTR record. When your mail server connects to Gmail and says "HELO mail.example.com," Gmail looks up the PTR for your IP and checks it points back to a sensible hostname — ideally the same one. It's a basic sender-legitimacy signal, and it's covered alongside other email DNS in MX records and email deliverability.

The key rule: PTR lives with the IP owner

Here's what confuses people: you set forward records (A, MX) at your DNS provider, but the PTR record is controlled by whoever owns the IP address — your hosting provider or VPS host, not your registrar. You usually can't add a PTR in Cloudflare or Namecheap; you set it in your VPS control panel or by asking your host.

Step 1: Set up forward DNS first

Before the PTR, make sure forward DNS is correct. Pick a hostname for the mail server and give it an A record:

• Type: A, Name: mail, Value: 203.0.113.10

So mail.example.com → 203.0.113.10. See how to set up an A record for your server if you need the basics.

Step 2: Set the PTR to match

In your VPS provider's panel, find Reverse DNS, rDNS, or PTR for the IP and set it to the exact same hostname:

203.0.113.10  ->  mail.example.com

The golden rule is FCrDNS (Forward-Confirmed reverse DNS): the PTR points to a hostname, and that hostname's A record points back to the same IP. Both directions must agree.

Step 3: Match your HELO/EHLO

Configure your mail server (Postfix, Mailcow, etc.) so its HELO hostname matches the PTR. In Postfix's main.cf:

myhostname = mail.example.com
smtp_helo_name = mail.example.com

Now three things line up: the sending IP's PTR, the HELO name, and the forward A record. That's what receivers want to see.

Step 4: Verify

dig -x 203.0.113.10 +short

This should return mail.example.com.. Then confirm the forward matches:

dig +short mail.example.com A

Both must reference each other. You can also use online rDNS checkers or the query techniques in diagnosing DNS problems with dig and nslookup.

Why this matters so much

Along with a proper PTR, deliverability depends on SPF, DKIM and DMARC — see how to set up SPF, DKIM and DMARC step by step — and on not being on a blocklist. But a bad PTR alone will sink you: many servers refuse mail from IPs with generic rDNS like 203-0-113-10.pool.isp.net. If you're fighting the spam folder, start here and read how to stop your emails going to spam.

How to actually get rDNS on a VPS

Because the PTR lives with the IP owner, the exact route depends on your provider:

• Self-service panel: most quality VPS hosts expose a Reverse DNS / rDNS / PTR field next to each IP in their control panel. Enter your mail hostname (mail.example.com) and save.
• Support request: some budget hosts require you to open a ticket asking them to set the PTR. Give them the IP and the exact hostname.
• Delegated rDNS: for a block of IPs, a provider may delegate the reverse zone (10.113.0.203.in-addr.arpa) to your own nameservers so you manage PTRs yourself. That's overkill for a single mail server.

If your provider offers *no* way to set rDNS, that IP isn't suitable for sending mail — pick a host that does.

One IP, one clean PTR

An IP address should have exactly one PTR record for mail purposes, matching the hostname your server announces in HELO. If you host several domains' mail on one server, don't try to give the IP multiple PTRs — instead, pick one canonical mail hostname (say mail.example.com), point the PTR there, and have all domains send through that HELO name. The individual domains still have their own SPF, DKIM and MX; only the *transport* hostname needs to match the PTR. This keeps FCrDNS clean while serving many domains.

Test before you send a single message

Verifying rDNS after you've already sent (and been blocklisted) is too late. Check both directions up front:

dig -x 203.0.113.10 +short          # PTR -> should return mail.example.com.
dig +short mail.example.com A       # forward -> should return 203.0.113.10

Then send one test to a Gmail account and open Show original — under the received headers you'll see whether Gmail resolved your rDNS and whether it matched. Many blocklist-check tools also flag generic rDNS. Only once this is clean should you start real sending, alongside SPF/DKIM/DMARC from how to set up SPF, DKIM and DMARC step by step.

FAQ

Where do I set a PTR record?

With whoever owns the IP — your VPS or hosting provider, usually in a "Reverse DNS" field in their control panel. Not at your registrar or DNS host.

What should my PTR point to?

The hostname of your mail server (e.g. mail.example.com), and that hostname's A record must point back to the same IP. Both directions must match.

Can I have a PTR on a shared or dynamic IP?

On dynamic/residential IPs, usually not usefully — that's why self-hosting mail from home fails. Use a VPS with a static IP and rDNS control.

Does one IP support multiple PTR records?

Technically yes, but for mail you want exactly one clean PTR that matches your HELO and forward DNS. Multiple PTRs cause confusion and can hurt deliverability.

Can I self-host email at home instead of on a VPS?

In almost all cases, no. Residential ISPs typically block outbound port 25, hand out dynamic IPs, and don't let you set the PTR record — and those three together make deliverable mail impossible. Even where port 25 is open, home IP ranges sit on blocklists that major providers reject on sight, and without rDNS control you can't achieve the forward-confirmed reverse DNS receivers expect. A VPS with a static IP and a panel that exposes the PTR field solves all three, which is why self-hosted mail belongs on a server, not a home line. If you only need to *receive* mail, forwarding sidesteps the issue entirely — but for sending, a proper static IP with reverse DNS is non-negotiable.

Running mail needs a static IP and rDNS control — exactly what a proper VPS gives you. Get a fast VPS from Nxeon, or skip self-hosting entirely with managed business email.