If you see "queued" or "deferred" next to an email, it means the message has not been delivered yet but has not failed either. It is waiting in line on a mail server, which will try again. Greylisting is one reason for a short delay, and it is a deliberate anti-spam technique. This guide explains what queued, deferred and greylisted mean, how long delays normally last, the reasons a message sits in a queue, and what to do if a message stays queued for too long.
What "queued" means in email
Email is a store-and-forward system. When you send a message, your mail server places it in a queue, and a delivery process takes messages from the queue and connects to the recipient's server. If the recipient's server accepts the message, it leaves the queue. If it cannot be delivered at that moment, it stays in the queue and the server tries again later. So "queued" is a normal state, and many messages are queued for a very short time. It becomes a concern only when a message stays there for a long time.
You may see the word in a mail app, where "queued" can mean that the app has not yet handed the message to the server. You may also see it in a sending service's logs, where "queued" is often the first status of an accepted message before delivery attempts begin. Read the status in the context of where you see it.
What "deferred" means
A delivery attempt can end in three ways: accepted, rejected for good, or deferred. A deferral is a temporary failure, signalled by a reply code that starts with 4, such as 421, 450, 451 or 452. The sending server keeps the message and retries on a schedule, usually with growing gaps between attempts, until it succeeds or gives up after a set time. Our guide to reading a bounce code and SMTP bounce codes explain the codes. A permanent rejection starts with 5, and is reported to the sender as a bounce.
| Status | Reply code | What happens next |
|---|---|---|
| Accepted | 2xx | The message is delivered to the receiving system |
| Deferred (temporary failure) | 4xx | The sender keeps it in the queue and retries |
| Rejected (permanent failure) | 5xx | The sender stops and reports a bounce |
What greylisting is
Greylisting is an anti-spam method used by some receiving servers. The first time a server sees a new combination of sender, recipient and sending server, it answers with a temporary failure, such as a 4xx reply that asks the sender to try later. A properly built mail server will retry, and the receiving server accepts the message on the second attempt. Many spam tools never retry, so they never get through. The cost is a delay, which is often a few minutes and sometimes longer, for the first message from a new source. Later messages from the same source usually pass at once, though the details depend on the server.
Greylisting is not a sign that you did anything wrong, and you do not have to do anything about it, as long as your sending system retries properly. All reputable sending services and mail servers do. If you run your own sending code, make sure it queues and retries after a 4xx reply, and does not treat it as a final failure.
Common reasons a message stays queued
- Greylisting at the receiving server, which clears on retry.
- Rate limiting. A mailbox provider may accept only a limited number of messages from your IP address in a given time, especially a new or low-reputation sender. See rate limits and back-off.
- Receiving server busy or down, or a network problem between the servers.
- Recipient mailbox full, which is often a temporary condition for a time.
- DNS problems at the recipient domain, such as missing or failing mail server records.
- Reputation or policy deferrals. Large providers may defer mail from senders with a poor reputation or a sudden jump in volume, with a message in the reply that explains why.
- Your own sending server being overloaded, misconfigured or unable to connect out, for example on a blocked port. See SMTP ports and why port 25 is blocked.
How long will a queued message wait?
It depends on the sending system. Mail servers commonly retry for a period of days before they give up and send a failure notice to the sender, and many sending services use a shorter window for transactional mail. Read your provider's documentation for its retry schedule, since we cannot give a number that applies to every system. The longer a message waits, the less useful it may be: a password reset code that arrives an hour late is probably no use. For time-sensitive mail, monitor the queue and alert when messages wait longer than your limit.
What to do when a message stays queued
- Read the deferral reason. The reply text in the log often says exactly why: rate limit, greylisting, mailbox full, or a policy block.
- Wait for the retry, if the reason is greylisting or a short rate limit.
- Check your own side. Make sure the sending server can reach the internet on its outgoing port, that DNS works and that there are no authentication failures. See SMTP connection and TLS troubleshooting.
- Check authentication and blocklists. Failing SPF, DKIM or DMARC, or a listed IP, can cause deferrals. Use the blacklist check and the SPF, DKIM and DMARC checker.
- Slow down. If a provider is deferring for volume, reduce your sending rate and spread messages over time. See the warm-up guide.
- Trace the message. Your logs show each attempt and its reply. See tracing a message through logs and events.
Do not resend the same message while it is still queued. Doing so can deliver duplicates when the original finally goes through. Wait for a final status, and resend only after a message has bounced or been dropped.
Queued email in your own application
If your application sends email, put your own queue in front of the sending call, so that a slow or unavailable mail service cannot hold up your website. Let a worker pick up jobs, retry on temporary errors with growing delays, and record the final status. Use unique identifiers so that a retry cannot send the same message twice. Our guide to integration patterns for idempotency and retries shows how, and the delivery events webhook guide shows how to receive the final delivery status.
Reading a deferral in practice
A deferral reply usually carries text after the code. A line such as "451 4.7.1 Greylisted, try again later" tells you the reason in plain words. A line that mentions a rate limit or too many connections tells you to slow down. A line that mentions your IP address or domain reputation tells you to look at your sending history. Copy the whole reply into your notes when you investigate, because the exact wording often identifies the provider's rule, and it helps if you need to contact their postmaster team.
See what happened to every message Follow each email from accepted to delivered, deferred or bounced, with the server replies in the log.
References and further reading
Frequently asked questions
What does queued mean in an email?
It means the message has been accepted by a server but has not been delivered yet. It is waiting in line for a delivery attempt. It has not failed.
What is the difference between deferred and bounced?
Deferred means a temporary failure with a 4xx reply and the server will retry. Bounced means a permanent failure with a 5xx reply and the sender stops and reports it.
What is greylisting?
A receiving server's anti-spam method of answering a temporary failure the first time it sees a new sender, recipient and server combination. A proper mail server retries and gets through, and spam tools often do not.
How long does a queued email wait?
It depends on the sending system's retry schedule, which can run to days for ordinary mail servers. Check your provider's documentation, and monitor time-sensitive mail so that delays raise an alert.
Should I resend an email that is stuck in a queue?
No, not while it is still queued, since duplicates may result. Wait for a final status. Resend only after the message has bounced or been dropped.