Plesk Email Not Delivering to Gmail: Fix PTR Records, DKIM, SPF & IPv6 Issues (2025)

Gmail is the most widely used email provider in the world, and when your Plesk server stops delivering to it, the impact on your clients is immediate. Whether you're seeing bounce codes like 421 4.7.0, 550 5.7.26, or messages silently landing in spam, the root causes almost always fall into a predictable set of categories — and every one of them is fixable. This guide covers every reason why Plesk email is not delivering to Gmail in 2025, with exact commands and step-by-step fixes.

Why Gmail Rejects Email from Plesk Servers in 2025

Since February 2024, Google enforces strict requirements for all senders delivering to Gmail addresses. For bulk senders (over 5,000 messages/day), these are mandatory. For all senders, they are best practice that directly affects deliverability. The main rejection reasons from Plesk servers are:

• Missing or mismatched PTR (reverse DNS) record — Gmail requires the sending IP to have a PTR record resolving to the hostname, and the hostname must resolve back to the IP.
• IPv6 sending without a PTR record — Plesk servers with IPv6 enabled often send from an IPv6 address that has no PTR record set up.
• SPF failure — The sending IP is not included in the domain's SPF record.
• DKIM missing or invalid — Gmail requires DKIM signing on all mail; unsigned email is heavily penalised.
• No DMARC policy — Google now requires a DMARC record for all senders.
• IP reputation / blacklist — The server IP has been listed on Spamhaus, Barracuda, or Google's own reputation system.
• Sending rate exceeded — Gmail has per-IP rate limits; shared hosting servers that send high volume hit these limits.

Step 1 — Check the Exact Bounce Message

Before fixing anything, identify exactly what Gmail is rejecting. Check the Plesk mail log:

# Postfix mail log (Plesk default)
tail -100 /var/log/maillog | grep -i gmail
# or on Debian/Ubuntu-based Plesk:
tail -100 /var/log/mail.log | grep -i gmail

Common Gmail rejection codes and their meaning:

• 421 4.7.0 ... does not meet IPv6 sending guidelines regarding PTR records → IPv6 PTR missing
• 421 4.7.0 ... does not have authentication information or fails to pass authentication checks → SPF or DKIM failure
• 550 5.7.26 ... does not have a valid SPF record → SPF misconfigured
• 550 5.7.1 ... The user you are trying to contact is receiving mail at a rate that prevents → Rate limit hit
• 550 5.7.1 Our system has detected unusual... → IP reputation / blacklist

Step 2 — Fix PTR (Reverse DNS) Record for Your Server IP

PTR records are set at your hosting provider or data centre, not in Plesk. You need to configure this in your VPS/dedicated server control panel.

hostname -I
# or check which IP Postfix uses:
postconf mynetworks
postconf inet_interfaces

dig -x YOUR_SERVER_IP +short
# Should return your server hostname, e.g.: mail.yourdomain.com.

dig mail.yourdomain.com A +short
# Should return your server IP — this forward-confirmed reverse DNS is required by Gmail

dig default._domainkey.yourdomain.com TXT
# Should return a record starting with: v=DKIM1; k=rsa; p=...

Step 6 — Add a DMARC Record

Google requires a DMARC record as of 2024. Without it, Gmail will increasingly route your messages to spam. Add a TXT record to your DNS:

# DNS record name: _dmarc.yourdomain.com
# Record value (start with monitoring policy):
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The p=none policy monitors without rejecting. Once you've confirmed clean DKIM and SPF alignment for 2–4 weeks (using the reports sent to the rua address), escalate to p=quarantine and eventually p=reject.

Step 7 — Check and Delist Your IP from Blacklists

Even with perfect authentication, a blacklisted IP will be rejected by Gmail. Check your server IP against major blacklists:

# Quick multi-RBL check (install if needed: apt install -y postfix-policyd-spf-python)
# Or use the web tool: https://mxtoolbox.com/blacklists.aspx

# Check Spamhaus from command line:
dig YOUR_REVERSED_IP.zen.spamhaus.org +short
# No response = not listed. 127.0.0.x = listed.

If your IP is listed on Spamhaus, go to the Spamhaus lookup page and follow the delisting process. For Barracuda, use barracudacentral.org/rbl/removal-request. Most delist requests are processed within 24 hours if the underlying spam source has been resolved.

After delisting, check Google's own Postmaster Tools (postmaster.google.com) — add your domain and monitor the IP reputation score. A "Bad" rating means Gmail is actively filtering your mail even if you're not on public blacklists.

Step 8 — Fix Gmail Rate Limit Errors

If you see 550 5.7.1 ... receiving mail at a rate that prevents additional messages, your server is sending too many messages to Gmail too quickly. Fix this by configuring Postfix delivery rate limiting:

# Edit /etc/postfix/main.cf and add:
smtp_destination_concurrency_limit = 2
smtp_destination_rate_delay = 1s
smtp_extra_recipient_limit = 10

Then restart Postfix: systemctl restart postfix. This slows delivery to Gmail but ensures messages are accepted rather than deferred.

Post-Fix Verification Checklist

• Send a test email from your Plesk domain to a Gmail address and confirm delivery to inbox (not spam)
• Use mail-tester.com to get a deliverability score — aim for 9/10 or above
• Check Google Postmaster Tools for domain and IP reputation
• Verify DMARC reports are arriving at your rua address after 24 hours
• Monitor /var/log/maillog for 24 hours after changes to confirm no new rejections

If you've worked through all of these steps and Gmail deliverability is still failing, the issue may be deeper — a compromised account sending spam, a shared IP with a problematic neighbour, or a configuration conflict between Plesk's mail stack and a custom Postfix setup. CloudHouse Technologies provides expert Plesk server management including full email deliverability audits, blacklist recovery, and ongoing mail server monitoring.