Reverse DNS (PTR) for Gmail: Check and Fix It

Gmail's sender guidelines tell every sender to "Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records." If you run your own mail server on a VPS, a dedicated server or a cPanel box, that line is about you, and it is often the one check nobody has set up. By the end of this guide you will be able to test your PTR record in one command, confirm it matches your A record, and send your host a clear request to fix it.

What is a PTR record, and why does Gmail care?

A normal DNS lookup turns a name into an IP address. A PTR record is the reverse lookup entry that turns an IP address back into a name.

Think of a phone book read backwards. Normally you look up "Ali's Shop" and find a phone number. With a reverse phone book, you start with the number and find out who owns it.

Gmail's guidelines ask for both lookups to line up. They say "The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname." Then the same hostname must have an A record (for IPv4) or an AAAA record (for IPv6) that points back to the same IP.

Google puts it plainly: "The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record." In short, the IP points to a name, and the name points back to the same IP.

Why this matters: only the IP owner can set the PTR, and only the domain owner can set the A record. When both point at each other, the two records agree, which is what Gmail's guidelines ask for.

This is an old rule. RFC 1912, a guide to common DNS mistakes published in February 1996, already said: "Make sure your PTR and A records match."

You may already have SPF, DKIM and DMARC in place. If not, set those up first with our guide to SPF, DKIM and DMARC for small business email. Think of PTR as the fourth leg of the same table.

Who owns the PTR record?

Here is the part that confuses most people. Your domain's DNS zone (the place where you add A, MX and TXT records) does not hold the PTR record for your server's IP.

The PTR record lives in a special reverse zone called in-addr.arpa for IPv4 and ip6.arpa for IPv6. That zone belongs to whoever controls the IP address: your hosting company, your ISP, or the data centre.

cPanel's own documentation says it clearly: "You must have the authority to update the PTR record for the IP address associated with the domain." If you do not, it tells you to "contact the organization that owns it," such as your hosting provider, Internet service provider (ISP), or data center.

So adding a PTR record in your domain registrar's DNS panel does nothing.

Before you start

Run through this short checklist first.

• Who controls the IP: you need to know which company gave you the server's IP address. Usually it is the VPS or dedicated server provider whose invoice you pay.
• Access: you need a login to that provider's control panel, or a way to open a support ticket with them.
• The server name: decide the hostname you want the IP to point to, for example mail.example.com. It must be a full name, also called an FQDN (fully qualified domain name, a complete name such as mail.example.com rather than just mail).
• DNS access for your domain: you must be able to add or edit an A record for that hostname.
• A test machine: any Linux or Mac terminal with the dig tool, or your server itself over SSH.
• Time: about 15 minutes of your work, plus whatever time your host needs to make the change.
• Risk level: low. Checking changes nothing. Adding an A record for a new hostname is safe. Changing an existing A record that other services use is where you need care.

Heads up: before you change any DNS record, back up what you have now. Export the zone file from your DNS panel if it offers an export, or take a full screenshot of the record list. If something breaks, you can put the old values back in minutes.

Fix it step by step

Made-up example: Ali runs a small VPS at 192.0.2.10 for his shop's mail on example.com. His messages to Gmail customers keep landing in spam or bouncing, even though SPF and DKIM pass. We will follow his server through each step.

Step 1: Find the IP your mail actually leaves from

Your website and your mail may not use the same IP. Some servers have several IPs, and some route mail through a relay. You want the IP that talks to Gmail.

The easiest way is to send a test email from your server to a Gmail address you own. Open the message in Gmail in a browser, then next to Reply click More and choose Show original.

Do not pick the first IP address you see in the headers: a message can contain several Received hops and a client or relay IP. Identify the public SMTP peer that handed the message to Gmail using Google's added Received/Authentication-Results information, and compare it with your outbound mail logs. If you cannot identify that hop confidently, ask your mail host or administrator for the actual outbound IP. A Gmail rejection may leave no delivered message to inspect; use the bounce details and server logs instead.

For Ali, the Gmail-facing SMTP hop is 192.0.2.10, his VPS IP. If that hop belongs to a relay, the relay operator controls its PTR; do not change your website server's PTR as a guess. Check every outbound IPv4 and IPv6 address your server or provider actually uses.

Quick tip: if the sending address is IPv6, such as 2001:db8::10, your server is sending over IPv6. You will need a PTR for that address too. We cover this in the troubleshooting section.

Step 2: Check that dig is installed

The dig tool asks DNS servers questions and prints the answer. Run this command to see if it is installed; it prints the version number and exits.

dig -v

You should see a version line. If you get "command not found" on Debian or Ubuntu, install the bind9-dnsutils package with this command. On Ubuntu, the older dnsutils name is a transitional package that pulls in the same tools.

sudo apt install bind9-dnsutils

On Fedora, Rocky Linux and similar systems, the tool comes in the bind-utils package. Install it with this command.

sudo dnf install bind-utils

After that, dig -v should print a version line, and you are ready to test.

Step 3: Look up the PTR record

The -x option tells dig to do a reverse lookup, and +short asks for a short answer with no extra detail. This command asks "what name belongs to this IP?"

dig -x 192.0.2.10 +short

A hostname such as mail.example.com. means a PTR answer was returned; a provider hostname is still an answer that needs a forward check. An empty +short response does not by itself prove that no PTR exists: DNS could have returned NXDOMAIN, NODATA, SERVFAIL or a timeout. Run dig -x 192.0.2.10 without +short and inspect its status and answer before changing records.

Behind the scenes, dig turns the IP around and asks for the name 10.2.0.192.in-addr.arpa. That reversed name is why the record sits in the IP owner's zone and not in yours.

Ali gets no answer in +short. The full dig response confirms NXDOMAIN for the reverse name, so he has identified a missing PTR for this example. That is one Gmail sender-requirement failure to fix, but it does not by itself explain spam placement or prove why a particular message was rejected.

Step 4: Check the forward match

A PTR on its own is not enough. Now check that the name it returns points back to the same IP. This command asks for the A record of the hostname that the PTR returned.

dig mail.example.com A +short

The answer must include the sending IP, here 192.0.2.10. If it does not resolve to the sending IP, the pair does not match yet, so it does not meet the Gmail rule above.

Also make sure the hostname has a real A record and is not a CNAME (an alias that points to another name). RFC 1912 says "PTR records must point back to a valid A record, not a alias defined by a CNAME."

Step 5: Create the A record for your mail hostname

If the forward lookup failed, fix your side first. This is the part you control, in your domain's DNS zone.

Back up the zone as described above. Then in your DNS panel, add an A record with name mail (which becomes mail.example.com) and value 192.0.2.10. If you are unsure how your DNS panel maps names to hosts, our guide on how to map a host to a domain walks through it.

Why this matters: do this before you ask your host for the PTR change. Then the pair matches the moment the host sets the PTR, and you can test straight away.

When it is done, the dig mail.example.com A +short command from Step 4 should print 192.0.2.10.

Step 6: Ask the IP owner to set the PTR

Now ask whoever controls the IP to point it at mail.example.com. There are two common ways this works.

Some providers have a "reverse DNS" or "rDNS" field in their control panel next to each IP. Others create the PTR from the server's name, and some only change it through a support ticket. Look in your provider's panel or help pages, and if you cannot find it, ask support. A ready-to-send message is at the end of this guide.

Once the provider confirms the change, run dig -x 192.0.2.10 +short again. You should see mail.example.com. in the answer.

Step 7: Make the server's own name match

Your mail server also introduces itself with a name when it connects to Gmail. This is the HELO name, a greeting the sending server sends at the start of each connection.

Receiving servers can see this name, so it makes sense to use the same hostname as your PTR. On cPanel servers, the Email Deliverability tool shows a message about HELO configuration in its Reverse DNS (PTR) section when the HELO setup and the domain do not match, so you will know.

Ali asks his mail administrator to make the SMTP HELO/EHLO name mail.example.com. His sending IP, PTR, A record and HELO name now tell the same story. Changing a server-wide hostname can affect other services, so do not change it solely for this step without checking the mail software and hosting panel.

Variants

The steps above work everywhere. Only the place you click changes.

cPanel and WHM: Email Deliverability

cPanel has a built-in checker called Email Deliverability. Its documentation says it helps "identify problems with your mail-related DNS records for one or more of your domains," and it covers DKIM, SPF and Reverse DNS (PTR).

In the PTR section, cPanel can "view and verify a domain's current pointer record (PTR)." It reminds you that "A PTR record requires an associated A record." When there is a problem, it shows instructions on how to fix it.

For each domain, the Manage option lets you fix mail-related records by hand, and the Repair feature lets the system fix invalid records for you. cPanel says the repair "can take up to five minutes, depending on the server."

Heads up: Repair does not get around the authority rule. cPanel's own page says you must have the authority to update the PTR record for the IP, so if your host owns the IP, you still need them.

Two more things to know. First, the host has to switch this tool on. It is enabled in WHM » Home » Packages » Feature Manager » Feature Lists, so if you do not see it in cPanel, ask your host.

Second, if your server sends through a smarthost (a relay server that delivers mail for you), the PTR section does not appear at all. Smarthost settings live in WHM » Home » Service Configuration » Exim Configuration Manager, in the Basic Editor section. In that case, the relay's IP is the one that needs a correct PTR.

The cPanel documentation pages I checked do not give a menu path for opening Email Deliverability, so look for it by name in your cPanel or WHM search box, or ask your host.

DirectAdmin and Plesk

The idea is exactly the same: DirectAdmin or Plesk manage your domain's zone, but the PTR still belongs to the IP owner. I did not verify the exact menu paths for these panels today, so I will not guess them. If you are setting up a new panel server, our guide to installing DirectAdmin on a VPS covers the base install, and the PTR request to your host is the same as below.

A provider caution: DigitalOcean rDNS does not make a Droplet a usable direct mail server

DigitalOcean documents automatic PTR creation from a Droplet name that is a valid FQDN. But its current Droplet limits also say SMTP ports 25, 465 and 587 are blocked on all Droplets. Do not use this rDNS feature as evidence that a Droplet can deliver mail directly to Gmail; use a supported external mail service or relay and check that service's sending IP and PTR.

DigitalOcean says a Droplet named example.com can get a PTR, whereas a generic name cannot; its Control Panel does not let you create PTR records manually. This describes DNS behavior only, not SMTP permission.

For IPv6, DigitalOcean says PTR is available only for the first assigned IPv6 address, and it blocks SMTP traffic over IPv6 at the network level. Therefore an IPv6 PTR on a Droplet does not make outbound IPv6 mail viable there.

Provider policies differ. Before planning a self-hosted mail server, check your provider's current SMTP/network policy and who controls the actual outbound sending IP. If you use a relay, its IP owner must satisfy the PTR requirement.

How to check it worked

Run these checks after your host confirms the change. DNS answers can be cached for a while, so if you see the old result, wait and try again.

First, the reverse lookup. This command should print your mail hostname with a trailing dot.

dig -x 192.0.2.10 +short

mail.example.com.

Second, the forward lookup. This command should print the same IP you started with.

dig mail.example.com A +short

192.0.2.10

If you prefer, the host tool does a reverse lookup by default when you give it an IP address. On Debian it comes in the bind9-host package. This command prints the PTR in a short sentence.

host 192.0.2.10

Third, on a cPanel server, open Email Deliverability and look at the Reverse DNS (PTR) section for your domain. It should no longer report a problem.

Fourth, check from outside your own network. MXToolbox has a free Reverse Lookup tool that does a reverse IP lookup on the address you enter. Its page even notes that ISPs generally create and maintain these records.

Finally, send a new test email to Gmail and open Show original again. The sending IP in the header should be the one you just fixed.

Troubleshooting

Problem: dig -x returns nothing

Symptom: dig -x 192.0.2.10 +short is empty. Fix: repeat without +short and inspect the status. NXDOMAIN or NOERROR with no PTR answer suggests a missing PTR; SERVFAIL or a timeout means resolve the DNS failure first. If the PTR is missing, ask the IP owner to create it. A PTR entered in your domain's ordinary DNS zone does not fix the IP owner's reverse zone.

Problem: the PTR points to a name with no A record

Symptom: dig -x returns mail.example.com., but dig mail.example.com A +short prints nothing. Likely cause: the host set the PTR, but nobody created the forward record. Fix: add the A record in your domain's DNS zone, as in Step 5.

Problem: the A record points to a different IP

Symptom: the forward lookup prints 203.0.113.25, but your mail leaves from 192.0.2.10. Likely cause: the hostname points to your website or an old server. Fix: use a separate mail hostname that points only to the sending IP, or update the A record after backing up the zone and checking nothing else depends on it.

Problem: the PTR shows a generic provider name

Symptom: dig -x returns a long name made of numbers and the provider's domain. Likely cause: the provider's default PTR is still in place. Fix: ask the provider to change it to your hostname, or on a provider like DigitalOcean, check that the server's name is a full FQDN.

Problem: the host says it cannot change the PTR

Symptom: support replies that custom reverse DNS is not available. Likely cause: the IP is shared by many customers, as on most shared hosting, or the plan does not include it. Fix: send mail through your host's mail service or a relay whose IP already has a correct PTR, or move your mail server to a plan with its own IP and rDNS control.

Problem: IPv6 mail has no IPv6 PTR

Symptom: IPv4 checks pass, but the Gmail header shows a sending address like 2001:db8::10. Likely cause: your server prefers IPv6, and that address has no PTR or no matching AAAA record. Fix: check it with dig -x 2001:db8::10 +short, then ask your host for an IPv6 PTR and add an AAAA record for the same hostname.

Pro tips and when to ask for help

Quick tip: use one hostname for mail and keep it stable. Changing the mail name later means changing the PTR, the A record and the HELO name together.

Quick tip: PTR is only part of what Google checks. Its guidelines also say "Use a TLS connection for transmitting email" and ask all senders to keep spam rates reported in Postmaster Tools below 0.3 percent. The same page recommends staying below 0.10 percent and never reaching 0.30 percent.

Security note: a PTR record does not prove you own a domain. Anyone who controls an IP can point it at any name.

Ask your host when the IP is theirs, when you do not see Email Deliverability in cPanel, or when you are on shared hosting. Ask a developer or sysadmin when your server has many IPs and you are not sure which one sends mail, or when changing the server hostname might affect other services.

The one message worth forwarding

Copy this, change the example values to your own, and send it to your hosting provider's support team.

Subject: Please set reverse DNS (PTR) for 192.0.2.10

Hello,

My server at IP 192.0.2.10 sends email for example.com.

Please set the reverse DNS (PTR) record for 192.0.2.10 to:
mail.example.com

The forward record already exists:
mail.example.com A 192.0.2.10

If the server also sends over IPv6, please set the PTR for 2001:db8::10 to mail.example.com as well. I will add the matching AAAA record.

Gmail's sender guidelines require the sending IP to have a PTR record whose hostname resolves back to the same IP.

Please let me know when it is done so I can check it with dig -x.

Thank you.

Your takeaway: the PTR record belongs to whoever owns your IP, so add the matching A or AAAA record, ask the IP owner for the PTR, and check both directions with dig. Passing this requirement removes one DNS problem; it does not guarantee Gmail acceptance, inbox placement or delivery.