What you’re looking at

This table shows messages currently sitting in Exim’s queue — emails that haven’t been delivered yet (they’re waiting for a retry, the remote server is delaying, or something bounced).

Quick guide to the columns

• ID – the message’s unique queue handle.
• Sender / Recipient(s) – who sent it and where it’s going. Multiple recipients are line-broken.
• Subject – extracted from the message headers (if present).
• Status – short reason from the queue. A Frozen badge means Exim stopped retrying (usually a hard bounce or permanent error).
• Size – message size reported by the queue.
• Age – how long it’s been waiting.

What you can do

• View – opens the full raw message (headers + body) so you can see exactly what was sent.
• Resend (verbose) – retries delivery and shows the live SMTP conversation. Great for seeing the remote server’s response (e.g., greylisting, 4xx/5xx codes).
• Delete – removes the message from the queue. Use this for obvious dead-ends (bad address, spam, etc.).
• Delete selected – tick the checkboxes to bulk-remove several messages.
• Delete ALL – wipes the entire queue. Handy for emergencies; be certain before you use it.

Before you resend or delete

• Check the error: The verbose resend shows the exact reason (DNS failure, 550 user unknown, greylisting, rate limit, TLS mismatch, etc.).
• Look for patterns: Many frozen messages to one domain usually means a DNS/MX issue or that recipient server is rejecting your traffic.
• Consider throttling: If you’re sending a lot to one provider, brief pauses or staggered sends help avoid rate-limits.

Troubleshooting tips

• Use View to confirm the sender, recipient and headers (SPF/DKIM/DMARC alignment issues often show here).
• Use Resend (verbose) to capture the remote server’s reply — this usually points straight to the fix.
• If the queue grows quickly, check your application’s sending rate and authentication settings; also verify your server’s rDNS, SPF and DKIM are correct.