Why Emails Arrive Late: SMTP Queues, Greylisting, Retries, and Delivery Delays

You request an email from an application.

The website says the message was sent successfully.

Five minutes pass. Nothing appears.

After fifteen minutes, you request another email.

Then both messages arrive almost together.

It is tempting to blame the inbox, the sending service, or the website's refresh button. But the real explanation may lie somewhere between the application and the recipient's mail server.

An email being accepted for sending is not the same as that email being delivered, and delivery is not always the same as becoming visible in an inbox.

Several independent stages separate those events. A delay at any one of them can make an otherwise functional message arrive late.

This guide examines those stages, explains SMTP temporary failures and greylisting, and shows how to identify the likely source of a delay using evidence rather than guesswork.

One message, several checkpoints

Think of email delivery as a sequence of handoffs.

An application first prepares a message and submits it to a sending system.

That system may queue the message, attempt delivery to another mail server, and retry when a temporary problem prevents completion.

The receiving system may then perform additional processing before the message appears in a mailbox.

Finally, the recipient's email application or web interface must retrieve and display it.

Those stages represent different outcomes.

Different providers use different event names.

For example, Amazon SES distinguishes a successful send request from delivery to a recipient's mail server.

That distinction is important when an application reports success immediately after submitting an email.

A successful API response may tell you that the sending provider accepted the request.

It does not necessarily tell you what happened afterward.

What “250 OK” actually means

SMTP, the Simple Mail Transfer Protocol, uses numerical reply codes to communicate the outcome of commands.

One commonly encountered reply is 250.

Its general meaning is that the requested SMTP action completed successfully.

However, the meaning of that success depends on which command received the response.

A 250 response during recipient validation is not the same checkpoint as a 250 response after the complete message has been transmitted.

When a receiving SMTP server returns a successful completion reply after receiving the message data, it accepts responsibility for further handling under the SMTP rules.

That is an important milestone.

But it is still not proof that the email appeared in the recipient's primary inbox folder.

The receiving system may perform filtering, routing, or mailbox processing afterward.

A responsible delivery investigation therefore records both the status code and the stage at which it occurred.

Simply seeing “250 OK” in an isolated log entry is not enough to reconstruct the entire journey.

Temporary failures and permanent failures are different

SMTP groups replies into classes.

Two particularly important categories are temporary and permanent failures.

These are general protocol categories, not guarantees about the exact behavior of every provider.

A 451 reply, for example, is associated with a local processing error that prevented the requested action.

A 450 reply can indicate a temporarily unavailable mailbox.

A 550 reply indicates that the requested action was not taken, with possible causes including an unavailable mailbox, access restrictions, or policy rejection.

The complete diagnostic response matters.

Do not assume that every 550 means the address does not exist.

Likewise, do not assume that every temporary SMTP failure is caused by greylisting.

A receiving server may temporarily defer a message because of resource shortages, policy limits, maintenance, or another condition.

The first digit tells you the broad failure class.

The remaining information helps identify the actual reason.

Why a temporary failure creates a queue

Suppose the sending system attempts to deliver a message.

The receiving server responds with a temporary error.

The message has not been accepted at that stage.

Instead of immediately abandoning delivery, a standards-compliant sending system normally queues the message and retries according to its delivery policy.

That queue is effectively a waiting area.

The message remains pending while the sender waits for another opportunity to deliver it.

The interval before another attempt depends on the sending software or provider.

Retries may use increasing delays rather than trying again continuously.

That helps prevent repeated failed attempts from overwhelming a receiving server.

However, it also means a short-lived receiving problem can turn into a noticeable delivery delay.

For example, a receiving server might become ready again after one minute, while the sender's next scheduled attempt occurs several minutes later.

The message may arrive only when that retry takes place.

The time spent waiting for a retry can be longer than the original server problem.

That is why a temporary error lasting a short period can produce an email delay measured in many minutes.

Greylisting: a deliberate temporary rejection

Greylisting is a receiving-server technique that intentionally delays certain incoming messages.

The basic idea is to return a temporary SMTP failure for selected senders or messages, encouraging a legitimate sending system to retry later.

Historically, this technique helped distinguish properly configured mail systems from some simplistic spam-sending programs that did not retry failed deliveries.

RFC 6647 documents greylisting, including its potential benefits and costs.

Greylisting decisions can depend on information associated with the sender, recipient, and sending infrastructure.

Some systems apply it broadly to unfamiliar senders.

Others use more selective rules.

The exact behavior varies.

Importantly, greylisting is one possible cause of a temporary failure, not another name for every `4xx` response.

Consider a first delivery attempt that receives a temporary rejection.

The sending server retains the message and waits.

When it retries, the receiving system may accept it.

From the recipient's perspective, the email simply appeared late.

From the sending system's perspective, the first attempt failed temporarily and a later attempt succeeded.

Both observations are consistent with the same delivery history.

A 13-minute delivery investigation

Let's follow an illustrative message from an application you control.

A tester requests a harmless email using a private test account.

The application reports that the email was submitted at 10:00.

The receiving mailbox displays the message shortly after 10:13.

What caused the apparent thirteen-minute delay?

A possible event history might look like this.

All times and events in this example are fictional. They demonstrate how to interpret a delivery timeline, not the results of an actual test.

The key observation is the interval between the first temporary rejection and the later successful delivery attempt.

The message was not continuously traveling across the internet for thirteen minutes.

Most of the delay occurred while it was waiting for another delivery attempt.

This is why delivery logs are more informative than simply comparing the email's subject-line timestamp with the time it appeared on screen.

Four different sources of delay

Not every late email follows the previous pattern.

A useful diagnosis separates the main categories.

1. Application or provider queueing

The application may queue outgoing emails instead of sending them immediately.

A background worker might process requests in batches or become delayed under load.

The provider may also defer or throttle sending.

In that case, the message can spend time waiting before any attempt is made to contact the recipient's server.

Check when the application created the message and when the sending provider actually accepted or attempted delivery.

2. SMTP delivery deferrals

The sender may attempt delivery and receive a temporary SMTP failure.

Causes can include recipient-server problems, rate limits, greylisting, or insufficient resources.

Look for temporary-failure responses, queued-message status, and later retry attempts.

3. Receiving-server processing

The receiving server may have accepted the message but still need to route, scan, classify, or store it.

The sender's delivery event may be complete while the receiving mailbox continues processing.

A provider-reported delivery timestamp is therefore not automatically a precise measurement of when the recipient's interface displayed the email.

4. Mailbox refresh or interface delay

A web interface may retrieve new messages periodically rather than display every arrival instantly.

It may also have a stale session, interrupted request, or synchronization delay.

If a message is already present at the provider but the interface has not refreshed, the delay is no longer an SMTP transmission problem.

These four stages call for different investigations.

Changing DNS settings will not fix a paused application worker.

Increasing inbox polling frequency will not fix a receiving server that is temporarily rejecting delivery.

Why an email can arrive after you request another one

Consider a common user experience.

A confirmation message does not arrive immediately.

The user requests a resend.

Then the older message and the newer message appear almost together.

There are several plausible explanations.

The original message may have been deferred and later delivered successfully.

The newer message may have followed a different queue or delivery attempt.

A mailbox interface may also have retrieved both messages during the same refresh.

The order in which messages appear does not, by itself, establish when the application generated them or when the recipient server accepted them.

To investigate properly, each message should have a distinct correlation identifier in the authorized sending system.

The application should record the relevant provider message identifiers and event timestamps without exposing private message contents or authentication tokens.

The distinction is particularly important for verification messages.

A later verification request may invalidate an earlier token, depending on the application's design.

That can produce an expired-link complaint even though the older email eventually arrives.

For that separate problem, see Why Email Verification Links Fail.

Delivery timing and token validity are different properties.

Delayed delivery is not the same as a bounce

A bounce generally reports a delivery problem.

But the exact classification matters.

A permanent rejection can lead to a final failure.

A temporary rejection may lead to additional attempts.

If those attempts eventually fail or the sending system abandons delivery, the sender may receive a final failure notification even though the original problem was temporary.

Delivery Status Notifications, or DSNs, provide a standardized way to communicate certain delivery outcomes.

RFC 3464 defines notification actions including delayed, delivered, and failed.

One subtle point is worth understanding.

A final failed delivery notification can report an underlying temporary condition if the sending system eventually stops trying.

This means the action reported by a delivery notification and the underlying status-code class should be interpreted together.

A message that is delayed is still pending another delivery attempt.

A message whose delivery has permanently failed is no longer in that retry process.

The sender should not treat these outcomes as interchangeable.

Reading enhanced status codes

In addition to ordinary three-digit SMTP replies, mail systems can use enhanced status codes.

These provide more structured information.

For example, a code such as 4.2.2 begins with a 4, indicating a persistent transient failure category in the enhanced-status-code system.

A code such as 5.1.1 begins with a 5, indicating a permanent failure category.

The remaining components provide more specific detail.

The IANA SMTP Enhanced Status Codes registry documents these categories and their meanings.

These codes can help distinguish mailbox-related conditions from other delivery problems.

However, the presence of a particular code is not a substitute for reading the surrounding diagnostic message and understanding the provider's documentation.

A sending service may also translate a recipient server's reply into its own event names.

Whenever possible, retain both the provider's event and the available SMTP diagnostic details.

A provider's “delivered” event has a specific meaning

Email service dashboards can use words that sound more conclusive than they are.

For example, Amazon SES documents a SEND event separately from a DELIVERY event.

A send event means the request succeeded and the service will attempt delivery, subject to the service's documented processing rules.

A delivery event means SES successfully delivered the message to the recipient's mail server.

It does not certify that the recipient saw the message in the primary inbox.

The recipient's system may place it in spam, quarantine it, or apply additional processing.

Similarly, an open-tracking event should not be treated as absolute proof that a person read the email.

Email clients and privacy features can affect how remote resources are loaded.

If the goal is to investigate lateness, sender acceptance, recipient-server acceptance, and mailbox visibility are more useful checkpoints than an open-tracking counter.

The correct interpretation depends on the specific provider's documented events.

What email headers can tell you

When a receiving mailbox supports full-message inspection, technical headers can provide useful clues.

One important field is Received.

Mail servers typically add Received trace information as a message passes through them.

These headers can contain timestamps and information about intermediate systems.

They may help investigators identify which handoff consumed time.

However, there are limitations.

Not every mail server's clock is perfectly synchronized.

Timestamps can use different time zones.

Some header information can be inserted by untrusted systems and should not automatically be treated as authoritative.

A recipient may also lack access to the complete sending-provider event history.

For a meaningful analysis, normalize available timestamps to a common time zone and prioritize records from systems you trust.

Compare them with the sending provider's events.

Do not interpret one header date as a complete account of the entire delivery process.

RFC 5322 defines the format of the Received trace header, while RFC 5321 provides the relevant SMTP handling rules.

How to build a useful delay report

Suppose a tester reports:

"The email arrived twenty minutes late."

That is a starting observation.

A useful technical report should distinguish the visible experience from the available evidence.

A compact record might contain:

Avoid claiming a timestamp is precise if it was merely estimated by a person looking at the screen.

Also distinguish an event that was not recorded from an event that did not happen.

For example, the absence of a provider delivery event may mean event tracking was not enabled.

It does not always prove that a delivery attempt never occurred.

This approach turns a vague timing complaint into a timeline that can be investigated.

Should you keep resending the same email?

Repeatedly clicking Send is not a reliable solution to an unexplained delay.

It can create multiple messages that later arrive together.

For ordinary notifications, that may be confusing.

For operations involving invoices, approvals, or time-sensitive confirmation links, it may create additional complications.

A sending application should provide clear feedback about whether the request was accepted, whether a resend was initiated, and whether another action is necessary.

Where appropriate, rate limits and deduplication can prevent excessive duplicate messages.

For troubleshooting, an authorized tester should first determine whether the original message is pending, failed, or already accepted by the recipient's server.

If a resend is necessary, record it as a separate event rather than treating it as the same delivery attempt.

Do not try to bypass another service's sending restrictions by generating repeated requests.

What Anvil Tools Temporary Email Generator can verify

The Anvil Tools Temporary Email Generator provides a short-lived receiving inbox through Guerrilla Mail.

It is intended for permitted, non-sensitive email receipt checks.

The website's inbox interface checks for new mail approximately every 15 seconds and also offers a manual Refresh control.

Website inbox access lasts up to one hour.

The tool receives messages; it does not send them, provide outgoing SMTP logs, or control how other mail systems schedule retries.

That distinction matters when investigating an email delay.

A test message appearing in the temporary inbox confirms that it became available through the receiving service and was displayed in the interface.

It does not identify which upstream server may have queued the message or whether greylisting occurred.

Likewise, a message not appearing immediately does not establish that it was rejected.

The cause could lie with the sender, recipient provider, inbox retrieval, or a restriction on disposable addresses.

The 15-second interface-check interval is only one possible contributor to visibility delay. It is not a guarantee of end-to-end delivery within 15 seconds.

A controlled receipt test

For an application you own or are authorized to test:

1. Create a temporary address where disposable receiving addresses are permitted.
2. Send a harmless message with a distinctive test subject.
3. Record the time when your sending system accepted the request.
4. Observe when the message becomes visible in the temporary inbox.
5. Check the sender's authorized delivery logs separately, if available.
6. Compare those events without assuming that the website's polling interval explains every delay.

Do not use this workflow for real password-reset links, account-recovery messages, payment information, medical records, or other sensitive content.

Temporary inbox access is not a permanent or private archive.

Creating a new address or allowing website access to expire also does not prove that the external provider has deleted previously received messages.

For a broader explanation of these limitations, see Temporary Email for Authorized Testing and Permitted Messages.

Why testing multiple mailboxes can help

When an authorized application sends non-sensitive test messages, comparing different receiving environments can help locate the boundary where delays occur.

For example:

These observations narrow the search.

They are not definitive diagnoses without the corresponding logs and system information.

Also remember that two mailboxes can apply different filtering and policy rules.

A message reaching one provider promptly does not establish that every provider must accept it on the same schedule.

Use controlled accounts and comply with each receiving service's rules.

Improving reliability without promising instant delivery

An email system cannot guarantee immediate end-to-end delivery across every independent mail server.

It can, however, make delays easier to handle.

For an application sending important transactional messages, useful design practices include:

• Record the message request and provider acceptance separately.
• Track delivery delays and final failures when supported.
• Use stable internal identifiers to correlate events.
• Handle retries and repeated user requests predictably.
• Avoid promising that a message has reached the inbox when only submission is confirmed.
• Give users a reasonable path to request another message when appropriate.
• Use an alternative authorized communication channel for tasks where email delay is unacceptable.

These practices do not eliminate greylisting, recipient-server outages, or provider policy decisions.

They make the system more transparent and reduce the confusion caused by treating every pending message as either delivered or lost.

For account verification, a visible expiration timer or clear resend process may also improve the experience, provided it accurately reflects the application's real token rules.

A troubleshooting decision table

When a message is late, ask where the last confirmed successful handoff occurred.

This is more useful than assuming that all delays have the same cause.

An email might be delayed before leaving the application, during SMTP delivery, or after recipient-server acceptance.

The evidence needed is different at each stage.

The final takeaway

An email can be accepted by one system long before it becomes visible to the recipient.

Temporary SMTP failures, greylisting, retry queues, receiving-server processing, and mailbox refresh behavior can all contribute to the delay.

The most important distinction is between three outcomes:

The sender accepted the message for processing.

The recipient's mail server accepted the message.

The recipient could actually see the message.

Those are separate checkpoints.

A useful investigation identifies the last confirmed one, reads the available delivery responses, and traces the message forward.

That approach explains why a message can be marked sent immediately, delivered much later, and still be part of a functioning email system.

Try the relevant email tool

Need to check whether a harmless test email reaches a disposable receiving address?

Use the Anvil Tools Temporary Email Generator for permitted, non-sensitive receipt testing.

For SMTP queues, greylisting, and retry analysis, use the sending provider's authorized event logs and suitable recipient-side diagnostics. The temporary inbox is a receiving tool, not a delivery-trace or SMTP monitoring service.

Further reading

• RFC 5321 — Simple Mail Transfer Protocol
• RFC 6647 — Email Greylisting
• RFC 3463 — Enhanced Mail System Status Codes
• RFC 3464 — Delivery Status Notifications
• RFC 5322 — Internet Message Format
• Amazon SES — Monitoring Sending Activity
• Amazon SES — Troubleshooting Email Delivery