Deferred vs Bounced Email: What "Delivery Delayed" Means and When It Becomes a Bounce
A deferred email has not failed. A bounced email has. A deferral is a temporary 4xx reply: the receiving server said "not now", and your sending server keeps the message and retries. A bounce is final: either a 5xx refusal straight away, or a deferral that kept failing until your server gave up. Microsoft 365 gives up after 24 hours and returns 550 4.4.7 QUEUE.Expired. Other servers can keep trying for days. So don't resend a delayed message, and don't suppress an address because of one deferral. Wait for the outcome.
Our post on hard vs soft bounces covers how to classify a failure once it happens. This post is about the step before: the waiting period, and how it turns into a bounce.
What happens on the wire
When your sending server delivers a message, the receiving server answers each step with a three-digit code. The first digit is what matters here:
| Reply | Meaning | What your server does |
|---|---|---|
2xx |
Accepted | Done; the message is delivered (or at least accepted) |
4xx |
Temporary failure | Keeps the message and retries later: a deferral |
5xx |
Permanent failure | Stops and sends a failure notice: a bounce |
The retry schedule is up to the sending server. The SMTP standard, RFC 5321 section 4.5.4.1, says: "In general, the retry interval SHOULD be at least 30 minutes," and "the give-up time generally needs to be at least 4-5 days." Large providers choose their own windows within that spirit.
How long the big providers keep trying
| Sending from | Retry window | What you get at the end |
|---|---|---|
| Microsoft 365 / Exchange Online | 24 hours | NDR with 550 4.4.7 QUEUE.Expired; message expired |
| Gmail / Google Workspace | Not published; its delay notice states the hours left | A "Delivery incomplete" notice while retrying; a failure notice if it gives up |
| Your own server (Postfix, Exim) | Configurable; Postfix's default is 5 days | A bounce to the envelope sender |
| ESPs (SendGrid, SES, others) | Their own policy, often up to 72 hours | An event in the dashboard or webhook |
Microsoft's own page is explicit: "Exchange Online repeatedly tries to deliver the message over 24 hours. Only after 24 hours of unsuccessful delivery attempts does a recipient receive this NDR" (Fix NDR 550 4.4.7, updated 10 August 2026). Note the code: 550 with a 4.4.7 enhanced code. It starts with 5 because the attempt is now over, but the enhanced code still says the underlying problem was temporary.
Gmail's help simply advises: "Wait a few hours to see if you get a delivery error message" (Gmail Help). For ESP retry windows, see our soft bounce handling table.
Reading the delay notice
When a message is still being retried, some providers send you an interim notice. It typically says there was a temporary problem, quotes the receiving server's reply, and says how much longer the server will keep trying.
The important part is the quoted reply. It tells you why the message is waiting:
| Quoted reply | What it means | Your move |
|---|---|---|
450 4.2.1 mailbox temporarily unavailable, or "try again later" from a small server |
Often greylisting: the server defers unknown senders once | Nothing. The retry usually goes through |
452 4.2.2 mailbox full |
The recipient's mailbox is over quota | Wait; if it ends in a bounce, treat the address as stale |
421 4.7.0 or 4.7.28 from Gmail |
Rate limiting or reputation | Slow down your sending to Gmail. See Gmail 421 4.7.28 |
451 4.7.650 from Outlook.com |
Microsoft IP reputation throttling | See Microsoft 451 4.7.650 |
421 4.7.0 [TSS04] from Yahoo |
Yahoo deferring your traffic | See Yahoo TSS04 |
| Connection timed out, no reply | The receiving server is down or unreachable | Wait; if every address at the domain fails, check its MX |
Paste the notice into Bounce Doctor or the bounce message analyzer to sort it.
Why cold senders often don't see deferrals
If you send cold email through Google Workspace or Microsoft 365 inboxes connected to a sequencer, the retries happen inside Google's or Microsoft's servers. Your sequencer only sees what lands back in the inbox: a delay notice, if the provider sends one, and the final failure notice, if it comes. Two consequences:
- Late bounces get attributed to the wrong day. A message deferred on Monday and given up on Tuesday shows as a bounce a day after the send. If step 2 was scheduled for Tuesday, it may already have gone out. Our post on why follow-ups bounce more than step 1 covers this.
- Delay notices can be mistaken for bounces. Some sequencers parse every "delivery" message as a bounce and stop the lead. Check how yours treats them, and look at a few by hand.
What to do with each
| Situation | Do | Don't |
|---|---|---|
| A single deferral to one address | Wait for delivery or a final notice | Resend; suppress the address |
A final failure after retries (4.4.7, "gave up") |
Treat as a soft bounce; suppress after a repeat on the next send | Count it as proof the address doesn't exist |
A 5xx refusal about the address (5.1.1) |
Suppress immediately | Retry |
| Many deferrals at one provider at once | Slow down to that provider; check authentication and blocklist status | Delete the addresses: the problem is your sending |
| Many deferrals at one company domain | Check the domain's MX with the MX lookup; it may be down or migrating | Keep sending to it while it fails |
The key distinction is whether the deferral is about the recipient (mailbox full, server down, greylisting) or about you (rate limits, reputation). Recipient deferrals usually resolve on their own. Sender deferrals get worse if you push harder.
How verification relates
A verifier sees deferrals too. If a receiving server answers a mailbox check with 4xx, an honest verifier reports unknown or risky, not valid. SimpleVerifier returns those rows as risky with send_advice set to retry and a reason such as "Server would not confirm", so you know to check them again later rather than drop them. That is why a small share of unconfirmed results on a fresh list is normal, especially at domains that use greylisting.
Where SimpleVerifier fits
Verifying before you send keeps hard bounces out of your campaigns, so the deferrals you do see are easier to read. Upload a list on the verify page; the first 100 checks are free with a Google sign-in. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.
Common questions
What is the difference between a deferred email and a bounced email?
A deferred email got a temporary 4xx reply and is still waiting in the sender's queue to be retried. A bounced email has failed for good: the receiving server refused it with a 5xx reply, or the sender gave up after retrying a deferral for too long. Only a bounce means the message will not arrive.
How long will my email be retried after a deferral?
It depends on the sending server. Microsoft says Exchange Online retries over 24 hours before sending a 4.4.7 NDR. The SMTP standard, RFC 5321, says retries should usually be at least 30 minutes apart and the give-up time generally needs to be at least 4-5 days. Gmail's delay notices state how many more hours it will keep trying.
Should I resend an email that says delivery is delayed?
No. The original is still queued and may arrive. Resending creates duplicates and, if the delay was caused by rate limiting, adds to the problem. Wait for either delivery or a final failure notice.
Does a deferral count toward my bounce rate?
Usually not while it is being retried. If it ends in a final failure it is then reported as a bounce, often as a soft bounce. Sequencers that send through your Google or Microsoft inbox only see the final failure notice, not each retry.
Check your list before you send
Real mailbox checks over SMTP, and nothing is sent to the address. Sign in with Google and your first 100 email checks are free, no card. Plans for bigger lists are on the pricing page.