A queued email hasn’t failed — it’s waiting. And where it’s waiting decides how you fix it. If you see “queued” in the Gmail app on your phone, the message is sitting on the device because it lost connectivity at send time, and restarting the app usually clears it. If mail is queued on a server, it means the receiving end refused it temporarily and your server is retrying — which is normal for a few minutes and a problem after a few hours.
Queuing is a normal part of how email works. Every message passes through a queue on its way out; most stay there for seconds. What matters is how long it stays, and what the log says about why.
| Queued in a phone app | The message never left the device. Connectivity at send time. Restart the app, check the attachment size |
| Queued on a mail server | The recipient’s server gave a temporary refusal. Your server retries for 24–72 hours before bouncing |
| Everything queues, always | Not a queue problem — a reputation or authentication problem wearing a queue costume |
Table of Contents
Queued, deferred, bounced: three different states
These get used interchangeably and they aren’t the same thing. Knowing which one you have tells you whether to wait or to act.
| State | What happened | Will it still arrive? |
|---|---|---|
| Queued | The message is waiting to be sent. It hasn’t been handed off yet | Yes, once the obstacle clears |
| Deferred | Your server tried, and the recipient’s server said “not now” — a temporary rejection (4xx) | Probably. Your server keeps retrying |
| Bounced | Permanent rejection (5xx), or retries exhausted. The server gave up | No. You get a failure notice |
The important part: queued and deferred are temporary states. A message doesn’t disappear while it’s queued — it either gets delivered eventually, or it turns into a bounce with an explanation. If mail is vanishing without either outcome, the problem isn’t the queue.
If it’s queued in a phone or desktop app
The most common version of this problem, and the simplest. The message is still on your device.
The cause is almost always connectivity at the moment you pressed send. The classic symptom is mail queuing on the phone but sending instantly from a laptop on the same account — that’s a network difference, not an account problem.
What to check, in order:
- Restart the app. Forces a fresh connection attempt, and clears most cases
- Check the connection. Switch between Wi-Fi and mobile data; a weak signal is worse than none, because the app keeps half-connecting
- Check the attachment size. Large files on a slow connection may never finish uploading. Most providers cap attachments at around 25 MB
- Check your daily sending limit. Providers cap how many messages you can send per day, and hitting it queues the rest until the window resets
- Verify the SMTP settings if it’s a mail client rather than a webmail app. A wrong port or hostname means the message has nowhere to go — our guide on IMAP settings for Outlook covers the correct values
On a phone, there’s no timer. Unlike a server, a mobile app will keep a message queued indefinitely until it can connect. It won’t bounce on its own — which is why restarting the app matters.
If it’s queued on the mail server
Different situation, and here the queue is doing its job: the receiving server said “try again later”, and yours is complying.
How the queue actually works
Postfix — the mail server behind most cPanel and Linux hosting — uses four queues, and knowing which one a message is in tells you a lot:
| Queue | What’s in it |
|---|---|
| maildrop | Mail posted locally, waiting to be cleaned up and moved on |
| incoming | Mail that has arrived but the queue manager hasn’t picked up yet |
| active | Currently being delivered. Deliberately small, so the server never runs out of memory |
| deferred | Couldn’t be delivered, waiting to be retried. This is where stuck mail lives |
The deferred queue exists so that failing messages don’t block working ones. A large deferred queue with everything else flowing normally is the system behaving correctly — the question is why those messages deferred.
Reading the queue
# How many messages are queued
mailq | tail -1
# See the queue with reasons for deferral
postqueue -p
# Read the log for a specific message ID
grep "MESSAGE-ID" /var/log/maillog
# Force a retry of the whole queue
postqueue -f
# Delete a single message
postsuper -d MESSAGE-ID
# Delete everything deferred (use with care)
postsuper -d ALL deferred
The output of postqueue -p includes the reason each message deferred, in parentheses. That reason is the answer — everything else is guessing.
On cPanel servers, which use Exim rather than Postfix, WHM has a Mail Queue Manager under Email that shows the same information through a web interface.
What the deferral reason usually says
| Reason in the log | What it means |
|---|---|
Connection timed out | Can’t reach the recipient’s server. Their MX may point to a dead IP, or port 25 is blocked between you |
Greylisted / try again later | Deliberate delay by the recipient’s spam filter. Normal — it clears on the retry |
Rate limited / too many connections | The recipient is throttling you, often because of sending volume or reputation |
Mailbox full | Recipient over quota. Nothing you can do but wait |
Blocked using + a blocklist name | Your server’s IP is on a blocklist. This one needs action, not patience |
DMARC / SPF in the message | Authentication failure — see our guide on DMARC failures |
Greylisting: the delay that’s supposed to happen
Worth explaining, because it looks like a fault and isn’t.
Greylisting is a spam defence: the receiving server rejects the first delivery attempt from an unfamiliar sender with a temporary error, then accepts it on the retry. The logic is that spam senders rarely bother retrying, while legitimate mail servers always do.
The consequence is that the first message you send to a domain may take several minutes to arrive, and subsequent ones go straight through. If someone reports that your first email was slow but everything since has been instant, greylisting is almost certainly why — and there’s nothing broken.
When everything queues: it’s not the queue
The case worth separating out, because the fix is elsewhere entirely.
If mail is chronically slow or deferred by large providers, the queue is a symptom. What’s happening is that receivers don’t trust your sending domain or IP, so they throttle you — and throttling looks exactly like a queue problem.
The causes, in order of how often they’re the answer:
- Missing or broken authentication. SPF, DKIM and DMARC are what tell receivers your mail is legitimate. A domain with all three configured correctly gets accepted faster and deferred less. Worth checking alongside them: the reverse DNS record of your sending IP, which receivers check at connection level — before authentication is even examined
- IP reputation. A shared IP where another customer sent spam affects everyone on it
- Blocklist listing. Check whether your server’s IP appears on the major blocklists
- Sudden volume increase. Going from ten messages a day to ten thousand triggers throttling on its own. Ramping up gradually — “IP warming” — avoids it
Our guide on what an email domain is covers how SPF, DKIM and DMARC fit together, and the DMARC failures guide covers reading authentication results in the headers.
When to worry
| How long it’s been queued | What to do |
|---|---|
| Seconds to minutes | Normal. This is how email works |
| Up to an hour | Probably greylisting or a busy recipient. Wait |
| Several hours | Read the log. Something specific is failing |
| 24–72 hours | The retry window is running out. After this it bounces |
| Every message, every time | Not a queue problem. Check authentication and reputation |
Chronic queuing is usually reputation and authentication. Copahost configures SPF and DKIM automatically on every account, monitors IP reputation and handles blocklist removals — so your mail is accepted rather than deferred. Unlimited mailboxes at your domain, with full IMAP, POP3 and SMTP.
See hosting plans with emailFrequently asked questions
What does it mean when an email is queued?
It means the message is waiting to be sent and hasn’t been handed off yet. Queuing is a normal part of email delivery — most messages sit in a queue for seconds. It becomes a problem only when a message stays queued for hours, which indicates something is blocking delivery.
Why is my email stuck in the queue on my phone?
Almost always connectivity at the moment you pressed send. The message never left the device, so restarting the app is the first fix. Large attachments on a slow connection and daily sending limits are the other common causes. Unlike a server, a phone app keeps a message queued indefinitely rather than bouncing it.
What’s the difference between queued, deferred and bounced?
Queued means waiting to be sent. Deferred means your server tried and the recipient’s server gave a temporary rejection, so it will retry. Bounced means permanent failure — either a hard rejection or retries exhausted — and you receive a failure notice. Queued and deferred are temporary; bounced is final.
How long do emails stay in the queue before bouncing?
On a mail server, typically 24 to 72 hours of failed retries before the message bounces. In a mobile app there’s no fixed timer: the message keeps waiting until the app can connect, which is why restarting it forces a fresh attempt.
What is greylisting and why does it delay my email?
Greylisting is a spam defence where the receiving server rejects the first delivery attempt from an unfamiliar sender with a temporary error, then accepts the retry. Spam senders rarely retry; legitimate servers always do. The effect is that your first message to a domain may take several minutes to arrive, while later ones go straight through.
How do I check the mail queue on a server?
On Postfix, run mailq for a count and postqueue -p to see each message with its deferral reason. postqueue -f forces a retry of the whole queue. On cPanel servers, which use Exim, WHM has a Mail Queue Manager under Email that shows the same information through a web interface.
Why does all my outgoing email get queued?
That’s not a queue problem — it’s usually reputation or authentication. If receivers don’t trust your domain or IP, they throttle you, and throttling looks like queuing. Check that SPF, DKIM and DMARC are configured correctly, whether your server IP is on a blocklist, and whether your sending volume increased suddenly.
Will my queued emails eventually be delivered?
Usually yes. A queued message doesn’t disappear — it’s either delivered when the obstacle clears, or it turns into a bounce with an explanation of why. If messages are vanishing with neither outcome, the problem is elsewhere in the mail configuration.
Conclusion
A queued email is waiting, not lost — and where it’s waiting tells you what to do. On a phone, it never left the device, so the connection is the culprit and restarting the app is the fix. On a server, the recipient asked yours to try again later, and the log entry explains why in plain language: greylisting, a full mailbox, a timeout, a blocklist. The one case that isn’t really a queue problem is the chronic one — if everything you send is slow to arrive, receivers are throttling you, and the answer is in your authentication records rather than in the queue itself.
