# Reverse DNS (PTR) for a mail server: why it matters and how to set it

> Reverse DNS for a mail server explained: what a PTR record is, why Gmail, Yahoo and Outlook check it, how to set it at each cloud provider and how to test it.

Source: https://zopanel.net/blog/reverse-dns-ptr-mail-server  
Updated: 2026-10-21

## Key takeaways

- A PTR record maps your server's IP back to a hostname, and receivers expect that hostname to resolve to the same IP again.
- Gmail, Yahoo and Outlook.com all require valid reverse DNS for sending IPs, and Gmail returns errors 4.7.23 or 5.7.25 when it is missing.
- PTR is set by whoever owns the IP, which means your VPS provider, not your domain registrar or DNS host.
- One IP has one PTR, so name it after the mail server, not after each customer domain.

Reverse DNS for a mail server means the server's IP address has a PTR record that points to a real hostname, such as `mail.example.com`, and that hostname resolves back to the same IP. Gmail, Yahoo and Outlook.com all check this for every sending IP, and Gmail rate limits or rejects mail from IPs without it. You set the PTR record at your VPS or cloud provider, because they own the IP range, not at your domain registrar.

This guide goes deeper than the PTR section of our [emails going to spam](/blog/email-going-to-spam) checklist: how reverse DNS works, what exactly the big mailbox providers require, where to set PTR at each major cloud provider, how to test it, and the mistakes that still break it.

## What is a PTR record?

Normal ("forward") DNS turns a name into an IP: `mail.example.com` has an A record `203.0.113.10`. Reverse DNS does the opposite. The IP is written backwards under a special domain, `10.113.0.203.in-addr.arpa`, and that name has a PTR record whose value is a hostname.

The important part: the `in-addr.arpa` zone for an IP is controlled by whoever was allocated that IP block. For a VPS, that is your provider. You can create all the A records you want in your own DNS zone, but only the provider can change the PTR of their IPs, usually through a field in their control panel or a support ticket.

**Forward-confirmed reverse DNS (FCrDNS)** is the check receivers actually perform. They look up the PTR of the connecting IP, then look up the A (or AAAA) record of the name they got, and expect the original IP in the answer. Hetzner's [rDNS documentation](https://docs.hetzner.com/dns-console/dns/general/reverse-dns/) describes it the same way. The idea is old: [RFC 1912](https://www.rfc-editor.org/rfc/rfc1912.html), from 1996, already says "Make sure your PTR and A records match" and warns that many services will not talk to hosts that are not correctly registered in DNS.

## Why mailbox providers check reverse DNS

Spam has long come from hijacked home computers and throwaway servers with generic or missing reverse DNS. A matching PTR is a cheap signal that someone runs the IP as a real mail server. The large providers now write it into their rules:

| Provider | What it requires | Source |
| --- | --- | --- |
| Gmail | All senders: valid forward and reverse DNS for sending IPs. The PTR must resolve to a hostname whose A or AAAA record points back to the sending IP | [Email sender guidelines](https://support.google.com/a/answer/81126) |
| Gmail errors | `4.7.23` (no PTR, or PTR does not map back: rate limited) and `5.7.25` (blocked: "Gmail requires that sending IP addresses have a PTR record") | [Sender guidelines FAQ](https://support.google.com/a/answer/14229414) |
| Yahoo | All senders: valid forward and reverse DNS; PTR should be meaningful and non-generic and reflect your domain in some way | [Sender best practices](https://senders.yahooinc.com/best-practices/) |
| Outlook.com | "Email servers must have valid reverse DNS records"; mail from dynamic IP space may not be accepted | [Postmaster policies](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies) |

Gmail's requirements have applied to all senders since 1 February 2024, and Google's FAQ says that starting November 2025 Gmail is "ramping up its enforcement on non-compliant traffic." In other words, a missing PTR is no longer just a spam score penalty; it can stop delivery outright.

Note that PTR is about the **IP**, while SPF, DKIM and DMARC are about the **domain**. You need both. A perfect DMARC setup does not rescue an IP without reverse DNS, and a perfect PTR does not authenticate your domain.

## Choosing the right hostname

Before you set anything, decide on one hostname for the server's mail identity, for example `mail.yourcompany.com`. Then make three things agree:

1. **The A record** `mail.yourcompany.com → 203.0.113.10` in your DNS zone (and AAAA if you send over IPv6).
2. **The PTR record** `203.0.113.10 → mail.yourcompany.com` at your provider.
3. **The SMTP greeting (HELO/EHLO)** your mail server sends. In Postfix, `smtp_helo_name` defaults to `$myhostname`, so set `myhostname = mail.yourcompany.com`.

Common questions about the name:

- **Does the PTR have to match my customers' domains?** No. One IP can only have one PTR, so on a server that sends for 50 domains, it names the server, not each domain. What matters is FCrDNS and a name that does not look generic. Yahoo's advice to reflect "your domain" is satisfied by your own company domain.
- **Can the PTR point to a CNAME?** Avoid it. RFC 1912 says PTR records must point to a name with an A record, not to an alias.
- **Is the provider's default PTR good enough?** Usually not. Defaults like `203-0-113-10.ip.example-cloud.net` look exactly like the generic names Yahoo warns against, and they rarely resolve back to your IP.

## How to set PTR at each cloud provider

The forward A record must exist first at most providers, because they check it before accepting a custom PTR.

| Provider | Where to set reverse DNS | Notes |
| --- | --- | --- |
| DigitalOcean | Name the Droplet with the full hostname (`mail.example.com`); the PTR is generated from the name | Cannot be created by hand; renaming the Droplet updates it. Reserved IPs do not support PTR ([manage DNS records](https://docs.digitalocean.com/products/networking/dns/how-to/manage-records/)) |
| Vultr | Instance settings, **IPv4** section: replace the default reverse DNS value | Per IP ([IPv4 networking](https://docs.vultr.com/products/compute/cloud-compute/networking/ipv4)) |
| Linode (Akamai) | **Network** tab, menu next to the IP, **Edit RDNS** | A record must exist first; can take up to 48 hours ([configure rDNS](https://techdocs.akamai.com/cloud-computing/docs/configure-rdns-reverse-dns-on-a-compute-instance)) |
| Hetzner Cloud | Server, **Networking**, edit the rDNS entry next to each IP | Works for primary and floating IPs ([cloud server rDNS](https://docs.hetzner.com/cloud/servers/cloud-server-rdns/)) |
| AWS EC2 | **Elastic IPs**, **Actions**, **Update reverse DNS** | A record must resolve to the Elastic IP; the IP is then locked to your account ([reverse DNS for email](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Elastic_Addressing_Reverse_DNS.html)) |
| Google Cloud | **Public DNS PTR record** on the VM's primary network interface | Verify domain ownership first; primary interface only ([create a PTR record](https://docs.cloud.google.com/compute/docs/instances/create-ptr-record)) |
| Microsoft Azure | `ReverseFqdn` property of the public IP, with Azure CLI or PowerShell | Not in the portal; IPv4 only; the name must already resolve to the IP ([reverse DNS for Azure services](https://learn.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services)) |

Two warnings tied to the table. On AWS and Google Cloud, use a static (Elastic or reserved) IP, otherwise a stop and start can give the server a new IP without your PTR. And remember that a PTR alone does not let you send: most of these providers also block outbound port 25 by default. See [port 25 blocked on your VPS](/blog/port-25-blocked-vps) for each provider's policy.

For Vietnamese and other local providers, PTR is often set by support ticket. Ask before you buy whether they can set it for your IP and how long it takes.

## How to test reverse DNS

From any machine with `dig`:

```bash
dig -x 203.0.113.10 +short          # expect: mail.yourcompany.com.
dig +short mail.yourcompany.com A   # expect: 203.0.113.10
```

Both answers must point at each other. If the first command returns the provider's default name, your change has not been saved or has not propagated yet. Then check the greeting your server sends:

```bash
postconf myhostname smtp_helo_name
```

The final test is a real message. Send one to a Gmail address, open it, choose **Show original** and look at the `Received` header from your server: it shows the IP and the reverse name Google saw.

### Don't forget IPv6

If your server has an IPv6 address, Postfix may deliver over IPv6 to providers that support it, Gmail included. Gmail's guidelines then require a PTR for the IPv6 address too, and they list the error "Message does not meet IPv6 sending guidelines regarding PTR records and authentication." Either set a PTR (and AAAA record) for the IPv6 address, or make Postfix send over IPv4 only with `inet_protocols = ipv4`. Some providers cannot help here: Azure, for example, does not support PTR for its public IPv6 addresses.

## Common reverse DNS mistakes

| Mistake | Symptom | Fix |
| --- | --- | --- |
| PTR set in your own DNS zone | `dig -x` still shows the provider default | Set it in the provider's panel or by ticket |
| A record missing or pointing elsewhere | FCrDNS fails; Gmail `4.7.23` | Add `mail.example.com A <server IP>` |
| HELO name is `localhost` or the provider's default hostname | Spam filters score the mismatch | Set `myhostname` to the PTR name |
| Server moved to a new IP | Old PTR on the old IP, nothing on the new one | Set PTR for the new IP before switching MX |
| Sending over IPv6 without a PTR | IPv6 errors at Gmail | Add IPv6 PTR or send over IPv4 only |

When you move to a new server, setting PTR for the new IP is one of the first steps, before any mail moves. Our guide to [moving a whole hosting server](/blog/move-whole-hosting-server) includes it in the checklist.

## Reverse DNS with ZoPanel

ZoPanel does not set PTR records, because nobody but the IP owner can. What it does is make the requirement visible. When you install the mail server, you enter a **Mail hostname** that must resolve to the server, and the Email page reminds you to ask your provider to set the PTR to that name. ZoPanel uses that hostname for the mail server, and the panel's certificate covers it, so mail clients connecting to `mail.example.com` see no warning.

After you set it, click **Run check** in **Mail delivery check**. It checks reverse DNS (PTR) and outbound port 25, compares public DNS with the expected MX, SPF, DKIM and DMARC records, and looks up the server IP on Spamhaus, SpamCop and Barracuda, with a hint for each problem. Step-by-step provider notes are in [install on cloud providers](/docs/install-cloud-providers), and the mail server itself is described in the [email docs](/docs/email).

## Conclusion

Reverse DNS is a five-minute job that many mail problems trace back to. Pick one mail hostname, create its A record, ask your provider to point the IP's PTR to it, make your mail server greet with the same name, and test both directions with `dig`. Then move on to SPF, DKIM and DMARC.

If you want a panel that checks all of this for you, [ZoPanel's Free plan](/pricing) includes the mail server and Mail delivery check, for 3 hosting accounts and 10 websites with no time limit.

## Frequently asked questions

### Where do I set the PTR record for my server?

At the provider that owns the IP: your VPS, cloud or dedicated server provider. Most have a reverse DNS field per IP in their control panel; some need a support ticket. Setting a PTR record in your own domain's DNS zone has no effect.

### Do I need reverse DNS if I send through a relay like SendGrid or Amazon SES?

The relay's IPs deliver your mail, and the relay manages their reverse DNS. Your server's own PTR matters for mail it delivers directly. It is still good practice to set it, so nothing breaks if you later stop using the relay or some mail bypasses it.

### Can one IP address have several PTR records?

Technically DNS allows it, but most providers support one PTR per IP, and receivers expect one clear name. Name the PTR after the server (for example `mail.yourcompany.com`) and let SPF, DKIM and DMARC handle each customer domain.

### How long does a PTR change take?

Often minutes, but it depends on the provider and on caching. Linode says reverse DNS updates can take up to 48 hours. Check with `dig -x` against a public resolver before you test delivery.

### Does reverse DNS affect websites?

Not in practice. Browsers and visitors do not check PTR records. It matters for mail servers and some other services that log or check the connecting IP's name.