Moved Mail to a New Server and Gmail Rejects It? Reverse DNS Didn't Move With You

A common assumption during a server migration goes like this: export the DNS zone, import it at the new host, update the SPF record with the new IP, copy the DKIM key, and mail authentication is done. Then the first messages to Gmail bounce, or land in spam, and nothing in the zone looks wrong. Usually nothing in the zone is wrong. The missing piece is the PTR record, and it was never in your zone to begin with.

Why the PTR record was never in your zone

Normal DNS lookups go from a name to an address. You ask for mail.example.com and get back an A record (IPv4) or AAAA record (IPv6). Reverse DNS goes the other way: you start with an IP address and ask what name it belongs to. The answer comes from a PTR (pointer) record. The key detail is where that PTR record lives. Reverse lookups for IPv4 are done under a special domain called in-addr.arpa, with the address written backwards. A lookup for 203.0.113.25 becomes a query for 25.113.0.203.in-addr.arpa. IPv6 uses ip6.arpa with each hex digit reversed. Those reverse zones are delegated along the chain of whoever was allocated the IP block: the regional registry, then the provider or network that owns the range. So the authority for the PTR of your server's IP sits with the IP owner, which is your VPS, dedicated, or cloud provider. Not with your domain's nameservers. You can add a record called ptr or a PTR-type entry inside example.com and it will do nothing, because no resolver ever looks there for reverse DNS. This is also why the old server worked. The previous provider had set a PTR for the old IP, either because you asked for it years ago or because their default happened to be acceptable. That setting belongs to the old IP. When you moved to a new IP, you got whatever reverse DNS the new provider assigned by default, which is often a generic hostname or nothing at all.

What Gmail checks when a new IP shows up

When your server connects to Gmail, the receiving side sees only the connecting IP address. It looks up the PTR for that IP, then looks up the hostname from the PTR to see whether it resolves back to the same IP. If both directions agree, the IP has forward-confirmed reverse DNS, often shortened to FCrDNS. Google's sender requirements list valid forward and reverse DNS for sending IPs alongside SPF, DKIM, and DMARC. The research behind this article frames it as part of the bulk sender rules, which apply once a domain sends roughly 5,000 messages a day to personal Gmail accounts. In practice, a sending IP with no PTR or a broken match tends to get rejected or junked well below that volume, so it is safer to treat FCrDNS as a baseline for any mail server, not a bulk-only item. When this is the cause, the bounce text usually says so fairly directly: the sending IP has no PTR record, or the forward lookup of that name doesn't point back to the IP. At a support desk, when a ticket says Gmail started rejecting mail right after a migration, a reverse lookup on the new sending IP is typically the first thing worth running, before anyone touches SPF or DKIM. Note that FCrDNS is about the server, not your From domain. The PTR does not need to say example.com. A server hosting fifty domains has one PTR per IP, usually pointing at the server's own hostname, and that is normal. What matters is that the PTR name exists, resolves back to the same IP, and ideally matches the name the server announces when it says hello.

Checking forward-confirmed reverse DNS in three lookups

You can check all of this from any machine with dig, before cutting over mail. Replace the documentation addresses and names below with your own.

BASH

# 1. Reverse lookup: what name does the new IP claim?
dig +short -x 203.0.113.25

# 2. Forward lookup: does that name point back to the same IP?
dig +short A mail.example.com

# 3. Repeat for IPv6 if the server has a public IPv6 address
dig +short -x 2001:db8::25
dig +short AAAA mail.example.com

A healthy result looks like this:

TEXT

# Illustrative output format
$ dig +short -x 203.0.113.25
mail.example.com.

$ dig +short A mail.example.com
203.0.113.25

If the first command returns nothing, there is no PTR. If it returns something like a long provider-style name built from the IP digits, you have the provider's default. That can technically pass FCrDNS when the provider also publishes the matching forward record, but generic names look like residential or unmanaged ranges, and some filters treat them with suspicion. It's better to set your own. The third check is the HELO (or EHLO) name, the hostname your mail server announces at the start of every SMTP conversation. After a migration it is often still the provider's default hostname or the old server's name. You can read it from the MTA itself:

BASH

# Postfix: hostname used in HELO/EHLO by default
postconf myhostname

# Exim: primary hostname (used for HELO unless overridden)
exim -bP primary_hostname

# List all addresses on the server, including any public IPv6
ip -br addr

The last command matters more than it looks. Gmail's MX hosts have IPv6 addresses, so a new server with a working IPv6 address will often deliver to Gmail over IPv6 by default. If you only set the IPv4 PTR, the IPv6 connections still arrive with no reverse DNS, and mail fails in a way that looks random because some messages go out over IPv4. The fix is either a PTR and AAAA record for the IPv6 address too, or limiting outbound SMTP to IPv4. In Postfix that is the inet_protocols setting. In Exim there are options for this as well, but on cPanel servers change it through WHM's Exim configuration tools rather than editing files by hand, since the panel can regenerate the config.

Getting the PTR set by the IP owner

Because the IP owner controls the reverse zone, the change has to go through them. Many VPS and cloud providers expose a reverse DNS field per IP in their control panel. Others handle it by support request. Check your provider's documentation or panel for the exact process, since it differs a lot. A few things make this go smoothly:

Pick the hostname first, usually something like mail.example.com or the server's own hostname.
Create the A record (and AAAA, if using IPv6) for that hostname in your domain's DNS, pointing to the new IP. Many providers check the forward record before accepting a PTR request.
Request the PTR for each sending IP, giving the exact IP and hostname.
Set the MTA's HELO name to the same hostname.
Re-run the dig checks from outside the server once the provider confirms.

On shared hosting you usually cannot set a PTR at all. The shared IP's PTR points at the server hostname, and that is fine as long as the forward lookup matches. If you need full control over the sending IP's reputation and reverse DNS, that is a different decision, and the trade-offs of shared server mail versus an external relay are covered in Send Newsletters Through cPanel's Exim or an External Relay Under Gmail Bulk Rules?. Reverse zones have their own TTLs, set by the provider. A PTR change may not be visible to Gmail immediately, which is one more reason to do this days before the cutover rather than an hour after.

The order that avoids the bounce window

The pattern that tends to work is to prepare the new IP's identity completely while the old server is still sending mail. Get the new IP, create the forward record, have the PTR set, configure the HELO name, and decide what to do about IPv6. Add the new IP to SPF alongside the old one, and make sure DKIM signing on the new server uses the same selector and key that's already published. Then send a few test messages from the new server to a Gmail account you control before moving MX or switching applications to the new SMTP host. Open the original message and read the headers. They show the connecting IP, whether it came over IPv4 or IPv6, and the SPF, DKIM, and DMARC results. If something fails there, Reading Authentication-Results Headers to Fix DMARC Alignment walks through what each result means. Only after those tests pass is it worth switching real traffic. Remove the old IP from SPF later, once nothing sends from it anymore. The short version: your DNS zone describes your domain, but reverse DNS describes the IP, and the IP owner holds that record. Every time mail moves to a new IP, treat the PTR as a separate task. Run dig -x on each sending address, IPv4 and IPv6, confirm the name points back, match it to the HELO name, and do it before the cutover rather than after the first bounce.