Why can't I add a PTR record in my domain's DNS panel?

Because reverse DNS belongs to whoever holds the IP address, not whoever hosts your domain. The in-addr.arpa zone for your IP is delegated to your cloud provider, hosting company or ISP, so the PTR has to be set there.

What should the PTR record point to?

A hostname you control, such as mail.example.com, that has an A (or AAAA) record pointing back to the same IP. Use the same name your mail server announces in HELO/EHLO.

Forward-confirmed reverse DNS: the IP's PTR gives a name, and that name's A or AAAA record contains the original IP. Gmail requires this from senders, and many other receivers check it.

I use Google Workspace or Microsoft 365. Do I need to set up reverse DNS?

No. Your mail leaves from the provider's servers, and the provider manages their reverse DNS. You only set a PTR for IPs you send from directly.

Reverse DNS (PTR) Setup: Who Controls It and How to Set It

What reverse DNS is

Normal DNS turns a name into an address: mail.example.com → 203.0.113.10. Reverse DNS goes the other way, through a PTR record in a special part of the DNS tree. For IPv4 the address is written backwards under in-addr.arpa; for IPv6 it’s written nibble by nibble, backwards, under ip6.arpa.

$ dig +short -x 203.0.113.10
mail.example.com.

# the same query, spelled out
$ dig +short PTR 10.113.0.203.in-addr.arpa
mail.example.com.

Web traffic doesn’t care about reverse DNS. Mail does. Receiving servers look up the PTR of every connecting IP and use it as one of the first, cheapest signals about the sender. Gmail’s sender guidelines require that sending IPs have a PTR record and that the name it returns resolves back to the same IP; Gmail rejects mail that fails the check with a 5.7.25 error. Other providers are less explicit, but a missing or generic PTR counts against you nearly everywhere.

Do you need to do anything?

Only if mail leaves from an IP you are responsible for: a VPS or cloud instance running Postfix or Exim, an on-premises Exchange server, an appliance, a dedicated IP at a hosting company.

If you send through Google Workspace, Microsoft 365, or a sending service such as Amazon SES, SendGrid or Mailgun, the mail leaves from their IPs and they handle reverse DNS. A PTR for your website’s IP won’t change anything. If those messages are going to spam, the cause is somewhere else, usually SPF, DKIM or DMARC.

To see which IP your mail actually leaves from, send a message to a Gmail address, open “Show original”, and read the first Received: line Google added: from mail.example.com (mail.example.com. [203.0.113.10]). That bracketed address is the one that needs a PTR. Inside the parentheses, the name in front of the address is the PTR Google found; the name right after from is what your server announced in HELO.

Why your DNS host can’t set it

This is the part that confuses most people. Your domain’s DNS host is authoritative for example.com. It is not authoritative for 10.113.0.203.in-addr.arpa. That zone is delegated down the chain of whoever holds the address: the regional internet registry hands the block to an ISP or cloud provider, and they run the reverse zone. The PTR has to be created there.

You can see who controls it:

$ dig +noall +answer +authority SOA 10.113.0.203.in-addr.arpa
113.0.203.in-addr.arpa. 3600 IN SOA ns1.hosting-provider.example. hostmaster.hosting-provider.example. 2026100701 7200 3600 1209600 3600

The zone name and the nameservers in that SOA tell you whose system it is. Almost always it’s your cloud or hosting provider, and they give you a field or an API call to set the PTR for your address. Some DNS panels show a “PTR” record type; adding one there creates a record nobody ever queries.

There are two exceptions. If you hold the IP block yourself (your organisation got it directly from the registry), you register your own nameservers for the reverse zone with the registry and run it like any other zone. And if your ISP gave you a small block such as a /29, it may delegate the reverse entries to your nameservers using the CNAME scheme from RFC 2317, or simply set the PTRs for you on request.

What the PTR should say

Pick one hostname for the mail server, typically mail.example.com or smtp.example.com, and make three things agree:

PTR: 203.0.113.10 → mail.example.com
Forward record: mail.example.com → 203.0.113.10 (A record in your own DNS zone, which you do control)
HELO/EHLO name: the name your server announces when it connects. In Postfix that’s myhostname (used by default for outgoing HELO); in Exim, primary_hostname.

The first two together are forward-confirmed reverse DNS (FCrDNS), the part receivers actually verify. The third isn’t strictly required by most receivers, but a server that says it’s localhost.localdomain or server1 while its PTR says something else looks exactly like a compromised machine. It costs nothing to match them.

A few rules of thumb:

One PTR per IP. DNS allows several, but receivers will pick one and you don’t control which.
Use a name in a domain you send from, or at least one you own. The PTR doesn’t have to match the From: domain of every message, and if you host mail for several domains it can’t. It does have to be a real, resolvable name.
Avoid names that look residential. Provider defaults such as ec2-203-0-113-10.ap-northeast-2.compute.amazonaws.com or 203-0-113-10.static.isp.example exist and resolve, but some receivers treat IP-shaped names as a sign of an unmanaged or end-user machine.

Create the forward A record first. Several providers refuse to set a PTR until the name already resolves to that IP.

Setting it at common providers

Provider consoles change; the field names below are what to look for, not guaranteed menu paths.

AWS EC2. Reverse DNS can be set on an Elastic IP, not on an auto-assigned public IP. In the console: EC2 → Elastic IPs → select the address → Actions → Update reverse DNS. Or with the CLI:

aws ec2 modify-address-attribute --allocation-id eipalloc-0abc1234 --domain-name mail.example.com
aws ec2 describe-addresses-attribute --allocation-ids eipalloc-0abc1234 --attribute domain-name

AWS checks that mail.example.com already resolves to the Elastic IP. Separately, EC2 restricts outbound port 25 by default; you have to ask AWS to lift that before the instance can deliver mail directly at all.

Microsoft Azure. Set the reverse FQDN on the public IP resource:

az network public-ip update --resource-group my-rg --name my-mail-ip --reverse-fqdn mail.example.com.

Azure verifies that the name resolves to that IP (or to the public IP’s own Azure DNS name), and may require the public IP to have a DNS name label first. Azure also blocks outbound port 25 on many subscription types.

Google Cloud. The PTR is set on the VM’s external IP access config, via the console or gcloud compute instances update-access-config with --public-ptr-domain. Google may ask you to prove you own the domain. Note that Compute Engine blocks outbound connections to port 25 on external addresses, so a GCE VM normally can’t deliver mail directly anyway and has to relay through a sending service.

DigitalOcean sets the PTR from the Droplet’s name. Rename the Droplet to the full hostname, mail.example.com, and the PTR follows. Hetzner, Vultr, Linode/Akamai and most VPS hosts have a reverse DNS field on the IP address or networking page; Linode, like AWS, wants the forward record in place first.

ISP business lines and colocation. There’s usually no self-service panel. Open a support ticket with the IP and the hostname you want; keep the A record already in place so they can verify it.

Don’t forget IPv6

This one catches many people after they’ve set everything up. If the server has an IPv6 address and the receiver has one too, your MTA will usually prefer IPv6. Your IPv4 PTR is perfect, the IPv6 address has none, and mail to Gmail bounces with the reverse-DNS error over IPv6.

Either set a PTR (and matching AAAA record) for the IPv6 address you send from, or stop sending over IPv6. In Postfix:

# /etc/postfix/main.cf
inet_protocols = ipv4

Then systemctl restart postfix. Setting up IPv6 reverse DNS properly is the better long-term answer, but it requires your provider to support PTRs on your IPv6 range.

Checking the result

dig +short -x 203.0.113.10          # → mail.example.com.
dig +short A mail.example.com       # → 203.0.113.10
dig +short -x 2001:db8::25          # if you send over IPv6

Both directions must agree. If dig -x still returns the old value, look at the TTL on the previous answer: caches will hold it until it expires, and some providers take a while to publish a change. Querying the reverse zone’s own nameserver (from the SOA above, dig -x 203.0.113.10 @ns1.hosting-provider.example) shows whether the change is live at the source.

The reverse DNS lookup does the round trip from outside your network: it shows the PTR for an IPv4 or IPv6 address, whether that name resolves back to the same address, and which hosting provider the name points to. You can also give it a hostname and it looks up the address first. The email check, given the IP, shows the PTR next to the address’s blocklist status. Then send a test message to Gmail and confirm the first Received: line shows your hostname inside the parentheses, next to the address.

If reverse DNS is right and mail still gets rejected, look at the address’s reputation next (mail server blacklist checklist) and at SPF, DKIM and DMARC (email deliverability guide).

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.