PTR Records and Reverse DNS: Why Gmail Rejects Your Server's Mail

If your mail server sends and Gmail answers with a message starting 550-5.7.25, the cause is almost always a missing or mismatched PTR record. A PTR record is DNS in reverse: instead of asking "what IP does this name have?" you ask "what name does this IP have?". Gmail and most large mailbox providers require FCrDNS (forward confirmed reverse DNS), which means the sending IP points through PTR to a name such as mail.example.sa, and that same name points through an A record back to the same IP. Break the loop at either end and your mail is rejected or lands far from the inbox. The fix needs three things to match: the hostname your server announces in its SMTP greeting, the PTR record for the IP, which is set by whoever owns the IP (your server provider, not you), and an SPF record authorising that IP to send for your domain. This article explains the common rejection codes, gives you the dig commands to check the whole loop in a minute, and finishes with a checklist for moving a mail server to a new IP, which is the moment these settings break more often than any other.

FCrDNS in One Example

Say your mail server sits on 203.0.113.25 and your domain is example.sa. A healthy loop looks like this:

Step	Question	Required answer
1	What is the name of 203.0.113.25? (PTR)	mail.example.sa
2	What is the IP of mail.example.sa? (A)	203.0.113.25
3	What does the server call itself in HELO?	mail.example.sa
4	Does SPF for example.sa allow this IP?	Yes, through ip4:203.0.113.25, a or mx

Steps one and two are FCrDNS. Why does Gmail care? Compromised home machines and cheap unmanaged IPs rarely have a proper PTR, and they usually carry generic names like 203-0-113-25.dynamic.isp.example. A matching PTR tells the receiver that the IP owner and the domain owner cooperated to identify this machine as a real mail server, and it is one of the first checks run before the message itself is even read.

Common Rejection Codes and What They Mean

The rejection message is your best diagnostic tool, so read it in full in the mail log before you change anything.

• 550-5.7.25: the sending IP has no PTR record, or the PTR name does not point back to the same IP. This is a plain FCrDNS failure and the fix starts with your IP provider.
• 550-5.7.27: the message failed SPF, meaning the sending IP is not listed in the SPF record for the domain in the sender address. It shows up constantly after a server moves to a new IP while SPF still lists the old one.
• 550-5.7.26: authentication failed in a way the domain's DMARC policy does not allow, typically SPF and DKIM both failing or not aligning with the sender domain.
• 421-4.7.0: a temporary deferral, usually meaning Gmail does not currently trust the IP because of weak reputation or a sudden burst from a fresh IP. Your server retries automatically, but hours of repeats mean a deeper problem.

Since February 2024 Gmail's sender requirements have been much more explicit: every sender needs SPF or DKIM and a valid PTR, and anyone sending more than 5,000 messages a day to Gmail accounts needs SPF, DKIM and DMARC together. That is why a setup that worked two years ago can stop working today without a single change on your side.

Check the Whole Loop With dig

These commands give you the full picture in about a minute, and you can run them from any machine:

# 1) PTR for the IP
dig -x 203.0.113.25 +short

# 2) A record for the returned name
dig +short A mail.example.sa

# 3) Hostname as the OS sees it
hostname -f

# 4) SPF for the domain
dig +short TXT example.sa | grep spf

# 5) SPF for the HELO name itself (some receivers check it)
dig +short TXT mail.example.sa

# 6) MX records
dig +short MX example.sa

A healthy result: the first command returns mail.example.sa., the second returns 203.0.113.25, and the third matches both. The SPF record should list the IP explicitly or include a mechanism that covers it, for example:

v=spf1 ip4:203.0.113.25 mx -all

Remember that SPF has a ceiling of 10 DNS lookups, with every include, a or mx counting as one, and exceeding it produces a permerror that many receivers treat as a failure. To test the SMTP greeting directly from an outside machine:

openssl s_client -connect mail.example.sa:25 -starttls smtp -quiet
EHLO test.example

The banner line should carry the same name, such as 220 mail.example.sa ESMTP.

Aligning the Hostname, PTR and SPF on One Name

The Hostname

hostnamectl set-hostname mail.example.sa

Also make sure /etc/hosts has a line mapping the IP to the full name. In Postfix the setting is myhostname = mail.example.sa in main.cf, and with Exim on cPanel the name lives under the Hostname setting in WHM. Pick a dedicated mail subdomain rather than the bare domain, because the root domain usually points at the website server and its A record will break the first time the site moves.

The PTR Record

This is where the most common mistake happens. People add a PTR inside their own domain's DNS zone and nothing changes. PTR records live in the in-addr.arpa zone owned by whoever holds the IP block, which is your server provider. You request it from the provider through their control panel if it offers the option, or through a support ticket naming the IP and the hostname you want. Before you ask, make sure the A record already exists and points at the IP, since some providers refuse to set a PTR for a name that does not point back to them.

The SPF Record

Update the domain's SPF to include the new IP, and for full coverage add a simple SPF record for the HELO name itself: v=spf1 a -all on mail.example.sa. Go further and enable DKIM, then publish a DMARC record starting with p=none and a reporting address, raising it gradually to quarantine after two weeks of clean reports.

Do Not Forget IPv6

If your server has a global IPv6 address, Postfix and Exim will prefer it when delivering to Gmail, since Gmail accepts mail over IPv6 too. That creates a silent failure: you set the IPv4 PTR carefully, then mail leaves from an IPv6 address with no PTR and gets rejected with the same 550-5.7.25. Gmail is stricter with IPv6 in particular, because the address space is too large to judge reputation address by address. You have two options. Either request a PTR for the IPv6 address as well and add it to SPF with an ip6: mechanism alongside an AAAA record for the same name, or force the mail server to send over IPv4 only. In Postfix, inet_protocols = ipv4 in main.cf followed by a reload is enough. Check with ip -6 addr show scope global, and if a public address shows up, settle the decision before rejection messages settle it for you.

Checklist After Moving a Mail Server to a New IP

A move is when everything above breaks at once, because the old IP carried a PTR and a reputation built over years. Follow this order:

1. 48 hours before the move: lower the TTL on A and MX records to 300 seconds so the switch propagates quickly.
2. Request the PTR for the new IP before sending a single message from it, and confirm it with dig -x.
3. Add the new IP to SPF while keeping the old one during the transition.
4. Carry over the DKIM keys as they are, or create a new selector and publish its record before switching.
5. Switch the mail hostname's A record, then rerun the full dig loop from the previous section.
6. Check blocklists for the new IP before sending, since a previous tenant may have left a mark.
7. Ramp up gradually: do not push 20,000 messages in the first hour from an IP with no reputation. Start with a few hundred and grow the volume over several days.
8. Watch the logs for 72 hours with grep -E "5\.7\.(25|26|27)" /var/log/maillog or your distribution's equivalent.
9. After a stable week, remove the old IP from SPF and restore the TTL to its normal value.

How CLOUD Handles It

On a CLOUD cloud server we set the PTR for your IP on request through a support ticket, provided the A record for the name is already in place. If you want a separate IP for the mail server, away from the website's IP, an additional IP costs 400 SAR per year. If your goal is corporate email that reaches government inboxes without running a full mail server, managed cloud hosting starts at 2,900 SAR per year and includes mail accounts with PTR, SPF and DKIM configured on our side. Compare both options on the pricing page, and run dig -x against your current server's IP today, because that one command may explain weeks of missing mail.