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 missing421 4.7.0 ... does not have authentication information or fails to pass authentication checks→ SPF or DKIM failure550 5.7.26 ... does not have a valid SPF record→ SPF misconfigured550 5.7.1 ... The user you are trying to contact is receiving mail at a rate that prevents→ Rate limit hit550 5.7.1 Our system has detected unusual...→ IP reputation / blacklist
💡 None of these worked? Skip the guesswork.
Get Expert Help →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.
Log in to your VPS provider's control panel (Vultr, DigitalOcean, Linode, OVH, etc.) and set the reverse DNS / PTR for the server's IP to your mail 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
Go to Plesk → Tools & Settings → Mail Server Settings and enable Use DKIM spam protection system to sign outgoing email messages. Click Apply.
For each domain, go to Plesk → Domains → [domain] → Mail Settings and enable DKIM signing. Plesk automatically generates the public/private key pair and publishes the DNS TXT record.
dig default._domainkey.yourdomain.com TXT
# Should return a record starting with: v=DKIM1; k=rsa; p=...
Send a test email to check-auth@verifier.port25.com — you will receive a reply showing whether DKIM, SPF, and DMARC passed or failed.
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.comto 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
ruaaddress after 24 hours - Monitor
/var/log/maillogfor 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.
