Plesk Greylisting Causing Email Delays? Here's How to Fix It

Greylisting is one of Plesk's most effective spam defences — and one of its most misunderstood email delay culprits. When enabled, Plesk temporarily rejects the first delivery attempt from any unknown sender with a 451 "try again later" response. Legitimate mail servers retry within minutes; spam bots typically don't. The problem is that large senders like Microsoft 365, Amazon SES, and mailing list services use dozens of IP addresses. Greylisting sees each retry from a different IP as a brand-new first attempt, creating delays of 5–30 minutes or more. This guide shows you exactly how to diagnose, whitelist, and configure greylisting to eliminate delays without sacrificing spam protection.

Why Plesk Greylisting Causes Email Delays

Greylisting works by temporarily deferring the first delivery attempt from a new sender/IP combination with a 4xx temporary failure code. The receiving mail server adds the sender's IP address, the sending domain, and the recipient address to a "greylist." When the sender retries — as all RFC-compliant mail servers do — the combination is now known and the message is delivered.

This works perfectly for single-IP senders. The problem arises with:

• Microsoft 365 (formerly Office 365). Microsoft uses hundreds of IP addresses in rotating pools. Each retry from the 365 infrastructure may come from a different IP, causing the greylisting system to treat each attempt as new.
• Amazon SES and similar bulk senders. Large sending infrastructure distributes outbound messages across many IPs for deliverability reasons.
• Mailing lists and newsletter services. Mailchimp, SendGrid, and similar platforms route through shared sending pools.
• Google Workspace (Gmail). Less problematic than 365, but Google also retries from different IPs within the same subnet.

The result: emails from these services arrive 5–30 minutes late or, in worst cases, trigger bounce notifications if the delay exceeds the recipient's mail client timeout expectations.

Diagnosing Greylisting as the Cause of Your Email Delays

Before modifying greylisting settings, confirm it is actually causing your delay. Check the Plesk mail log:

tail -f /var/log/maillog           # CentOS/RHEL
tail -f /var/log/mail.log          # Ubuntu/Debian

Look for entries like this — the Greylisted status is the indicator:

postfix/smtpd[12345]: NOQUEUE: reject: RCPT from mail-eopbgr120069.outbound.protection.outlook.com[40.107.12.69]: 451 4.7.1 Service unavailable - try again later; from=<sender@example.com> to=<recipient@yourdomain.com> proto=ESMTP helo=<mail-eopbgr120069.outbound.protection.outlook.com>

You can also check the greylisting database in Plesk:

# View current greylist entries
plesk bin grey_listing --info

# Or check via SpamAssassin/postgrey logs
grep "greylisted" /var/log/maillog | tail -50

Step-by-Step: Whitelist Senders via the Plesk UI

The safest fix for specific senders (like Microsoft 365) is to whitelist their IP ranges or domains in Plesk's greylisting configuration. Whitelisted senders bypass greylisting entirely.

40.92.0.0/15
40.107.0.0/16
52.100.0.0/14
104.47.0.0/17
2a01:111:f400::/48
2a01:111:f403::/48

64.18.0.0/20
64.233.160.0/19
66.102.0.0/20
66.249.80.0/20
72.14.192.0/18
74.125.0.0/16
209.85.128.0/17
216.58.192.0/19
216.239.32.0/19

CLI Method: Configure Greylisting Whitelist via SSH

For servers where you prefer CLI management, or when you need to script whitelist changes across multiple Plesk servers, use the Plesk CLI:

# Check current greylisting status
plesk bin grey_listing --status

# Add a trusted IP address
plesk bin grey_listing --add-trusted-ip 40.107.0.0/16

# Add a trusted domain (sender domain bypasses greylisting)
plesk bin grey_listing --add-trusted-domain microsoft.com

# List all trusted entries
plesk bin grey_listing --list-trusted

# Remove a trusted entry
plesk bin grey_listing --remove-trusted-ip 40.107.0.0/16

Alternatively, edit the greylisting configuration directly. Plesk uses postgrey on most Linux systems:

# Postgrey whitelist by client (sending IP/hostname)
nano /etc/postfix/postgrey_whitelist_clients.local

# Add entries (one per line):
/^.*\.outbound\.protection\.outlook\.com$/
/^.*\.google\.com$/
amazonses.com
mailchimp.com

After editing, reload postgrey:

systemctl reload postgrey

Adjust Greylisting Interval for Faster Retry

If whitelisting specific senders isn't sufficient, you can reduce the greylisting delay window. The default greylisting interval on most Plesk servers is 300 seconds (5 minutes). Reducing this to 60 seconds dramatically shortens delays while keeping the spam protection benefit (most bots don't retry at all).

Edit the postgrey configuration:

nano /etc/default/postgrey    # Debian/Ubuntu
nano /etc/sysconfig/postgrey  # CentOS/RHEL

Find the POSTGREY_OPTS line and add or modify the delay parameter:

# Reduce delay from 300 to 60 seconds
POSTGREY_OPTS="--inet=127.0.0.1:10023 --delay=60"

Restart postgrey:

systemctl restart postgrey

You can also set a maximum age for greylist entries. The default is 35 days — entries older than this are purged. For high-volume servers, reducing this to 7 days keeps the database smaller:

POSTGREY_OPTS="--inet=127.0.0.1:10023 --delay=60 --max-age=7"

When to Disable Greylisting Entirely

For some environments, the spam reduction benefit of greylisting is outweighed by the business cost of email delays. Consider disabling greylisting when:

• Your server hosts transactional email applications where delivery speed is critical.
• You already have strong spam filtering through SpamAssassin, ClamAV, or an upstream spam gateway.
• Your clients receive email from large enterprise senders (Microsoft 365, Salesforce, SAP) and whitelisting all their IP ranges is impractical.

Disable greylisting via Plesk UI:

Go to Mail > Mail Server Settings > Greylisting and set greylisting to Disabled.

Disable via CLI:

plesk bin grey_listing --turn-off

Remove postgrey from Postfix:

If you want to permanently remove greylisting, edit /etc/postfix/main.cf and remove check_policy_service inet:127.0.0.1:10023 from the smtpd_recipient_restrictions line. Reload Postfix:

postfix reload

Alternative spam protection without greylisting: Enable SpamAssassin in Plesk (Mail > Mail Server Settings > SpamAssassin) with a threshold of 5–7 to catch most spam. Combine with DKIM verification and SPF reject policies for near-equivalent protection without delivery delays.

Verifying the Fix

After applying whitelist changes or adjusting the greylisting interval, test immediately:

# Watch the mail log for the next incoming message from the whitelisted sender
tail -f /var/log/maillog | grep -i "outlook\|greylisted\|delivered"

# Send a test email from the problematic sender and measure delivery time
# A successful fix shows delivery within 30 seconds with no "Greylisted" entries in the log

Greylisting configuration is one of the most impactful quick wins for Plesk email reliability. A well-tuned greylisting setup — with major enterprise senders whitelisted and a reduced delay interval — eliminates most email delay complaints without opening the door to spam. If your Plesk email environment has deeper delivery issues beyond greylisting, the team at CloudHouse Technologies provides managed Plesk server support covering full email stack diagnosis and optimisation.