What are email queues?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
An email queue is a holding area where messages wait before they leave your server or while they wait for another retry. When your MTA cannot hand a message off right now, the message sits in queue until conditions change. "Cannot hand off right now" covers a lot: the receiving server returned a 4xx temporary error, you hit a per-recipient rate limit, DNS is slow, the connection dropped mid-DATA, or you are simply sending faster than Gmail wants to accept from your IP.
The queue is not a bug. It is the part of the sending pipeline that makes the whole thing reliable. Without it, every temporary hiccup would turn into a hard bounce.
What queues actually do
Absorb volume spikes. You send 200,000 messages in five minutes. Gmail will not accept them in five minutes. The queue holds them and feeds them out at a pace Gmail tolerates.
Hold messages for retry. SMTP defines two failure categories: 4xx (try again later) and 5xx (give up). A 4xx response from the receiver means "not now, come back." The queue is where "come back" lives. RFC 5321 §4.5.4.1 sets the default retry expectation at four to five days before a sender declares the message undeliverable (RFC 5321).
Pace delivery per destination. Most MTAs queue by destination domain so you can throttle Gmail at one rate, Yahoo at another, Microsoft at a third. This is how ESPs queue and retry messages without one slow receiver stalling the rest.
The queues you will see in an MTA
Postfix is the cleanest example because the names are literal directories under /var/spool/postfix/:
- incoming / maildrop - just arrived, not yet sorted.
- active - being delivered right now. Kept small on purpose so the MTA can keep state in memory.
- deferred - got a 4xx, scheduled for retry. Most of your "problem" messages live here.
- hold - parked by an admin, will not move until released.
- corrupt - the message file itself is unreadable. Rare, but check it exists.
Other MTAs use different names. Exim has "frozen" instead of hold. Commercial gear like PowerMTA or MailerQ exposes per-VirtualMTA queues so you can see, for example, that your Gmail queue is 40,000 deep while your Yahoo queue is empty. The concept is the same.
What to monitor
Two numbers matter and you should graph both:
- Queue depth - how many messages are waiting. Steady is fine. Steadily growing means you are sending faster than you are delivering, and you need to find out why before the oldest messages age out.
- Queue age - how long the oldest message has been waiting. If you are seeing messages older than 24 hours in deferred, something is wrong: a specific receiver is blocking you, your reverse DNS broke, your IP got listed, or a DNS lookup is timing out.
A growing deferred queue is almost always a reputation or auth problem at one specific receiver. Pull a sample of the 4xx responses and read them. Receivers tell you what is wrong in the response text. Google's bounce code reference is the cleanest published list (Google Postmaster - SMTP error reference).
The mistake operators make
Flushing the queue when it gets big. Do not do this. "Flush" in most MTAs means "try to deliver everything right now," which on a stuck queue means hammering the receiver that is already telling you to slow down. That gets you rate-limited harder or blocked outright. Fix the underlying cause first - bad auth, listed IP, content trigger - then let the queue drain on its own retry schedule.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
