When your VPS mail queue jumps from a handful of messages to thousands, the fix usually isn’t postqueue -f. First, prove why mail is backing up, where it’s failing, and which changes won’t wreck deliverability.
This mail queue troubleshooting tutorial gives you a repeatable workflow for Postfix on Ubuntu/Debian VPS servers. It covers the right commands, safe cleanup steps, and checks that lower your odds of getting blocked.
If you run a business site or WordPress and rely on transactional email, keep mail on a dedicated VPS (or split web and mail). A traffic spike or plugin failure won’t take everything down.
A properly sized HostMyCode VPS also gives you predictable CPU and disk I/O. You also get IP reputation isolation you won’t get in crowded environments.
Before you touch the queue: confirm what “stuck” means
Answer three questions first. Is mail not leaving at all, leaving slowly, or getting rejected upstream?
The commands below give you a clean snapshot in under two minutes.
1) Check queue size and age distribution
sudo postqueue -p | tail -n +2 | wc -l
sudo postqueue -p | head -n 25Scan for repeated domains (Gmail, Microsoft, your own destination). Also scan for repeated errors like connect to ... timed out or host ... said: 550.
Lots of “deferred” entries usually means Postfix is retrying and failing. The root cause is often remote policy or connectivity.
2) Get a high-signal view from the mail log
# Ubuntu/Debian
sudo tail -n 200 /var/log/mail.log
sudo grep -E "status=deferred|status=bounced|NOQUEUE|reject" /var/log/mail.log | tail -n 80Postfix is explicit about what’s wrong, but you need the failure lines. Filter aggressively and ignore the noise.
3) Confirm Postfix and DNS are sane
sudo systemctl status postfix --no-pager
sudo postconf -n | head -n 60
hostname -f
If hostname -f doesn’t return a real FQDN (not localhost, not an internal name), fix that early.
A bad HELO/hostname setup triggers rejections and long deferrals.
Mail queue troubleshooting tutorial step 1: isolate the failure type
Most backlogs come from a small set of causes. Put your queue into the right bucket before you change config files.
- Network/path issue: timeouts to port 25, intermittent connectivity, provider blocks.
- Remote policy blocks: SPF/DKIM/DMARC failures, missing rDNS, poor reputation, “spam-like” content.
- Local resource constraint: CPU pegged, disk I/O wait, too many concurrent deliveries, queue runner stuck.
- Authentication/relay misconfig: SASL failures to an upstream relay, wrong credentials, TLS mismatch.
- Abuse/compromise: unexpected outbound volume, new local users, PHP mail() abuse, WordPress plugin spam.
Fast triage: top recurring errors and domains
# Top recipient domains in queue (rough but effective)
sudo postqueue -p | awk '/@/ {print $7}' | sed 's/.*@//' | tr -d '>' | sort | uniq -c | sort -nr | head
# Most common status lines in the mail log
sudo grep "status=" /var/log/mail.log | awk -F"status=" '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | headIf “deferred” dominates, your server is attempting delivery and getting held up. If “bounced” dominates, recipients are rejecting immediately.
In that case, the queue may churn without growing as fast.
Step 2: verify outbound SMTP connectivity (port 25) and TLS basics
Many “stuck queue” incidents are blocked connectivity. Some providers rate-limit or block outbound 25 by default.
Test from the VPS itself, not from your laptop.
Connectivity test to common MX targets
# DNS lookup for a target domain
dig +short mx gmail.com
# Test SMTP connectivity
nc -vz gmail-smtp-in.l.google.com 25
If nc times out, treat it as a path problem. Common causes include a local firewall, an upstream block, or routing trouble.
If it connects, move on to policy and configuration.
Inspect TLS handshake with STARTTLS
openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -servername gmail.com -briefThis is a quick way to catch local TLS issues, like bad system time or a broken CA bundle. If your clock is off, fix NTP first:
timedatectl
sudo timedatectl set-ntp trueStep 3: stop the bleeding (rate-limit and pause noisy senders safely)
If the queue is still growing, slow things down while you investigate. The goal is to reduce damage without deleting evidence.
Temporarily reduce delivery concurrency
Lower concurrency to keep the VPS responsive. It also reduces the chance you trip remote throttling while you diagnose.
sudo postconf -e 'default_process_limit = 50'
sudo postconf -e 'smtp_destination_concurrency_limit = 5'
sudo postconf -e 'smtp_destination_rate_delay = 1s'
sudo systemctl reload postfixThese settings are deliberately conservative for many VPS sizes. Once you’re stable, tune based on CPU usage and queue behavior during peak send times.
Identify the source of outbound mail (WordPress, scripts, users)
# Show recent authenticated submissions and local submissions
sudo grep -E "sasl_username=|client=" /var/log/mail.log | tail -n 80
# Look for PHP mail() usage patterns (varies by stack)
sudo grep -i "php" /var/log/mail.log | tail -n 80If one site, plugin, or user is driving the volume, fix the application. Flushing the queue won’t solve a compromise.
It often makes reputation worse.
If you suspect the VPS is compromised or an account is spamming, contain it before you resume normal delivery. This internal guide lays out a clean sequence to follow: VPS incident response tutorial.
Step 4: check the three deliverability must-haves (rDNS, SPF, DKIM/DMARC)
In 2026, large mailbox providers expect identity alignment. If these basics are wrong, you’ll see deferrals, 5xx rejections, or mail that gets accepted but buried.
Any of those outcomes can create long retry cycles and a messy queue.
Reverse DNS (PTR) must match your sending identity
curl -4s ifconfig.me; echo
host $(curl -4s ifconfig.me)Your IP should resolve to a hostname you control. Your Postfix myhostname should match that identity.
If PTR is missing or wrong, fix it at the provider level. For a step-by-step PTR workflow, use: Reverse DNS setup tutorial.
SPF, DKIM, DMARC: fix policy rejections and protect reputation
If you run SMTP on a VPS, publish email authentication for the domain you send from. If you relay through a third party, your DNS still needs to reflect what actually sends mail.
Use this guide to configure and validate all four (including rDNS alignment): email authentication setup tutorial.
Step 5: fix common Postfix misconfigurations that create backlogs
These issues show up constantly on small hosting VPS setups and after migrations.
Wrong hostname / HELO name
Use a real hostname and make sure it resolves. Ideally, forward and reverse lookups should agree.
sudo postconf -e 'myhostname = mail.example.com'
sudo postconf -e 'mydomain = example.com'
sudo systemctl reload postfixAlso confirm mail.example.com has an A record pointing to your server IP.
Relayhost auth failures (if you use an upstream SMTP relay)
If you see SASL authentication failed or Relay access denied in the queue or logs, focus on relay configuration and credentials.
sudo postconf -n | grep -E 'relayhost|smtp_sasl|smtp_tls|smtp_sasl_password_maps'
sudo postmap -q '[smtp.relay.tld]:587' /etc/postfix/sasl_passwd 2>/dev/null || true
sudo tail -n 120 /var/log/mail.logTypical files to check:
/etc/postfix/main.cf/etc/postfix/sasl_passwd(thenpostmap /etc/postfix/sasl_passwd)
Broken DNS resolver (delays look like “random” deferrals)
resolvectl status 2>/dev/null || true
cat /etc/resolv.conf
dig +time=2 +tries=1 mx outlook.com
If DNS lookups are slow or failing, Postfix will stall and deliveries will pile up. Fix resolver reliability first.
Common fixes include stable upstream DNS, no captive NAT, and no broken local caching resolver.
Step 6: clean up the queue the safe way (don’t delete blindly)
After you fix the root cause, work down the backlog. You generally have two safe patterns:
- Requeue everything (when the cause is truly fixed).
- Delete mail you can defend deleting (confirmed spam, clearly wrong domains, incident traffic).
Requeue or flush (after fixing the cause)
# Retry deferred mail
sudo postqueue -f
# If you made major changes and want a clean retry ordering
sudo postsuper -r ALLpostsuper -r ALL requeues; it does not delete. It’s useful after DNS fixes, relay auth fixes, or restored outbound connectivity.
Delete only what you can justify deleting
If you’ve confirmed spam or a compromised sender, remove those messages. It protects your IP reputation and stops pointless retries.
# Delete ALL queued mail (dangerous, but sometimes required during an incident)
# sudo postsuper -d ALL
# Safer approach: delete messages to a specific domain (example)
sudo postqueue -p | awk '/@example-baddomain\.tld/ {print $1}' | tr -d '*!' | sudo postsuper -d -Grab a small sample first. Validate what you’re removing:
sudo postcat -q <QUEUE_ID> | sed -n '1,120p'Step 7: verify recovery with measurable checks
A shrinking queue is a good sign, but it’s not the finish line. Confirm mail is leaving, getting accepted, and not bouncing right back.
Watch the queue drain in real time
watch -n 2 'postqueue -p | tail -n +2 | wc -l'Track deferrals and bounces after your fix
sudo grep -E "status=deferred|status=bounced" /var/log/mail.log | tail -n 60Send a controlled test message with clear headers
printf "Subject: VPS SMTP test\nFrom: postmaster@example.com\nTo: you@yourmailbox.tld\n\nPostfix queue test.\n" | sendmail -tThen inspect the received headers. You want DKIM pass, SPF pass, and a sensible HELO/hostname.
Hardening to prevent the next backlog: practical guardrails
Once the queue is stable, add a few guardrails. They help prevent one buggy plugin—or one compromised account—from filling your disk and torching your domain reputation.
Put WordPress on an SMTP relay (recommended) instead of local sendmail
On many hosting stacks, the simplest pattern is: apps submit mail locally, Postfix relays upstream with authentication, and local sending stays tightly controlled.
That keeps your web server from behaving like a bulk sender by accident.
If you want that setup, follow: email relay setup tutorial.
Add basic monitoring triggers for queue growth
You don’t need a full monitoring platform to catch the obvious failures. At minimum, alert when the queued message count stays high for more than a few minutes.
# Simple local check (cron/systemd timer friendly)
Q=$(postqueue -p | tail -n +2 | wc -l)
if [ "$Q" -gt 500 ]; then
echo "Mail queue high: $Q" | logger -t mailq-watch
fiIf you want a dashboard with alerting, Netdata is a practical choice for VPS mail and web stacks: server monitoring setup guide.
Separate roles if you’re growing
As your sites or client accounts grow, stacking web, mail, DNS, and backups on one small VPS becomes brittle. A common upgrade path looks like this:
- Web/WordPress on one VPS
- Mail relay or mail server on a second VPS with its own IP reputation
- Offsite backups to object storage or a backup VPS
If you’d rather not maintain the OS and mail stack yourself, managed VPS hosting can cost less than losing a day to a mail incident.
Quick checklist: Postfix backlog response you can reuse
- Confirm queue count and oldest messages (
postqueue -p). - Extract top errors from
/var/log/mail.log(deferred vs bounced). - Test outbound port 25 and STARTTLS to common MX hosts.
- Validate hostname/HELO alignment and ensure correct A/PTR records.
- Verify SPF/DKIM/DMARC and rDNS. Fix the identity layer before retrying.
- Throttle concurrency while diagnosing; stop abusive senders.
- Requeue/flush after root cause is fixed; delete only confirmed bad mail.
- Confirm drain rate and acceptance; send a controlled test email.
- Add monitoring and consider role separation as volume grows.
Summary
A queue backlog is a symptom, not the cause. Start with the logs, confirm connectivity, and fix identity (rDNS + SPF/DKIM/DMARC).
Do that in order, and Postfix usually recovers without trashing your IP reputation.
If you need a VPS sized for steady mail throughput, stable DNS, and isolation from noisy neighbors, start with a HostMyCode VPS. If you’d rather offload patching and service oversight, managed VPS hosting is a better fit for production email and business-critical sites.
Running email on the same box as your websites works—right up until the first backlog, blocklist hit, or plugin-driven spam burst. HostMyCode can help you move to a cleaner layout with a reliable VPS, or take the admin work off your plate with managed VPS hosting for production workloads.
FAQ
Should I run postsuper -d ALL to fix a stuck queue?
Only if you’ve confirmed the queue is spam or truly irrecoverable, and you’re fine losing those messages. In most cases, fix the cause first.
Then requeue with postsuper -r ALL and flush with postqueue -f.
Why is Postfix deferring mail to Gmail/Microsoft even though my server is “up”?
The usual causes are missing/incorrect rDNS (PTR), SPF/DKIM/DMARC failures, or remote throttling due to reputation. Start with the exact status=deferred reason in /var/log/mail.log.
How big should a normal queue be on a small VPS?
For most small business sites, it should hover near zero. A short spike during a newsletter send is normal.
Sustained growth (hundreds+) means retries are failing or your application is sending too much.
Can WordPress cause mail queue floods?
Yes. Contact form plugins, compromised admin accounts, and misconfigured SMTP plugins can all generate large bursts.
If the queue grows and you didn’t intentionally send mail, investigate WordPress early.
What’s the fastest “safe” first action during a backlog?
Throttle delivery concurrency, pull the top error from logs, and verify outbound SMTP connectivity. Don’t delete the queue until you know whether the messages are recoverable.