Plesk Mail Queue Stuck? Fix Deferred Emails on Postfix (2026)

Your Plesk server is running, Postfix appears to be up, but emails are sitting in the mail queue for hours — status: deferred. No delivery errors, no bounce messages, just silence. This is one of the most frustrating email issues on a Plesk server because everything looks fine until you actually check the queue.

In this guide, we'll walk through every cause of a stuck Plesk mail queue and exactly how to diagnose and fix each one.

Step 1: Check the Current Mail Queue Status

Before fixing anything, you need to see how many messages are stuck and what errors they're generating.

1. Check queue via Plesk UI: Go to Tools & Settings > Mail Server Settings > Mail Queue. This shows the current queue count and lets you view individual message headers.

2. Check queue via command line (more detailed):

# Count total queued messages
mailq | grep -c "^[A-F0-9]"

# View full queue with status
mailq | head -50

# Or use postqueue directly
postqueue -p | head -50

3. View detailed error for stuck messages:

# Get queue ID from mailq output, then:
postcat -q QUEUE_ID

# See why a specific message is deferred:
grep "QUEUE_ID" /var/log/maillog | tail -20

Common error patterns to look for in the logs:

• Connection timed out — destination mail server unreachable
• Connection refused (port 25) — outbound port 25 blocked by ISP or firewall
• connect to 127.0.0.1[127.0.0.1]:10024: Connection refused — Amavis/SpamAssassin down
• conversation with 127.0.0.1 timed out — Plesk Email Security (Amavis) timeout
• mail transport unavailable — Postfix misconfiguration

Step 2: Fix "Connection Timed Out" — Port 25 Blocked

The most common cause of deferred emails on Plesk is outbound port 25 being blocked by your server's upstream provider or firewall.

1. Test if outbound port 25 is reachable:

telnet gmail-smtp-in.l.google.com 25
# Should show: 220 mx.google.com ESMTP
# "Connection refused" or timeout = port 25 blocked

2. If your VPS provider blocks port 25 (common on AWS, GCP, Azure, Linode, and some budget VPS providers), you'll need to either:

• Request port 25 unblocking from your provider (submit a support ticket)
• Use a smart relay host (SendGrid, Mailgun, Amazon SES) to route outgoing mail through port 587

3. Configure a relay host in Plesk: Go to Tools & Settings > Mail Server Settings. In the Relay Options section, enable Use the following relayhost and enter your SMTP relay credentials.

4. Or configure Postfix relay directly via command line:

# Add to /etc/postfix/main.cf:
relayhost = [smtp.sendgrid.net]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_security_level = encrypt

# Create credentials file:
echo "[smtp.sendgrid.net]:587 apikey:YOUR_API_KEY" > /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
postfix reload

Step 3: Fix Amavis/SpamAssassin Causing Queue Stall

If you have Plesk Email Security installed, emails pass through Amavis for spam and virus scanning before delivery. If Amavis is down or overloaded, every outgoing email gets stuck with a connection refused error.

1. Check Amavis status:

service amavis status
# or:
systemctl status amavis

2. Restart Amavis if it's stopped:

service amavis restart
service postfix restart

3. Check Amavis is listening on port 10024:

netstat -tlnp | grep 10024
# Should show amavis listening on 127.0.0.1:10024

4. If Amavis keeps crashing, check its logs:

tail -100 /var/log/amavis.log
grep -i "error\|panic\|fatal" /var/log/amavis.log | tail -20

5. If Plesk Email Security was recently removed but Postfix still tries to route through Amavis, run the Plesk repair utility:

plesk repair mail -y

This reconfigures Postfix to remove the Amavis transport references and restore direct delivery.

Step 4: Use "plesk repair mail" to Fix Misconfiguration

The Plesk repair utility is the fastest way to fix mail queue issues caused by Postfix misconfiguration after a Plesk update or extension change.

1. Run in interactive mode (prompts you before making changes):

plesk repair mail

2. Run in automatic mode (applies all fixes without prompting):

plesk repair mail -y

3. Check the repair output — it will report which Postfix settings were corrected and whether services were restarted.

4. Restart mail services after repair:

service postfix restart
service dovecot restart

Step 5: Flush the Stuck Queue and Force Retry

Once the underlying cause is fixed, the deferred messages won't automatically retry immediately. Force a retry on all deferred messages.

1. Force retry on all deferred messages:

postqueue -f
# or equivalently:
postsuper -r ALL deferred

2. Monitor whether messages clear:

watch -n 5 "mailq | tail -5"

3. If specific messages should not be retried (spam, broken accounts), delete them:

# Delete a specific message by queue ID:
postsuper -d QUEUE_ID

# Delete ALL deferred messages (use with caution):
postsuper -d ALL deferred

4. Delete messages from a specific sender:

mailq | grep "^[A-F0-9]" | grep "sender@domain.com" | awk '{print $1}' | xargs postsuper -d

Step 6: Check for IP Blacklisting

If your server IP was blacklisted, destination mail servers will refuse connections and Postfix will defer the messages indefinitely.

1. Check your server IP against major blacklists: Use MXToolbox Blacklist Check (mxtoolbox.com/blacklists.aspx) or run:

dig +short YOUR_SERVER_IP.zen.spamhaus.org
# Empty response = not listed, any IP returned = listed

2. Check what's causing the blacklisting: Usually a compromised mailbox sending spam. Check for outgoing spam:

grep "status=sent" /var/log/maillog | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

3. If a Plesk mailbox is compromised: change its password immediately in Plesk, then check the outgoing mail limits under Tools & Settings > Server-wide Mail Settings > Outgoing Messages Limits.

4. Request delisting: Each blacklist has its own delisting process. Spamhaus has an automated lookup-and-delist form at spamhaus.org/lookup/.

Step 7: Adjust Queue Lifetime and Retry Intervals

By default, Postfix retries deferred messages for 5 days. If you want faster failure notifications or shorter retry windows, adjust these in /etc/postfix/main.cf:

# How long to keep trying (default 5 days):
maximal_queue_lifetime = 1d

# How long to keep bounces in queue:
bounce_queue_lifetime = 1d

# Minimum time between retries (default 5 minutes):
minimal_backoff_time = 300s

# Maximum time between retries (default 4000s):
maximal_backoff_time = 3600s

# Apply changes:
postfix reload

Shorter retry windows mean failed deliveries generate bounce notifications sooner, giving users visibility into delivery failures rather than silent deferrals. Proactive monitoring of your Plesk mail queue and server health is part of CloudHouse's managed server management service — our team catches and resolves mail delivery issues before your clients notice them.

FAQs