Email sent vs. delivered: what every delivery status means

“Sent” usually means your application or email provider accepted a message for processing. “Delivered” usually means the destination mail server accepted responsibility for that recipient. Neither status proves the message landed in the primary inbox, remained there, displayed correctly, or was read by a person.

Exact labels vary by provider, so treat the event contract—not the friendly word—as authoritative. Find the protocol or provider evidence behind each state, retain the recipient-level timeline, and avoid collapsing application submission, provider queuing, destination acceptance, inbox placement, and human engagement into one green checkmark.

The email delivery timeline

APPLICATION        email intent committed
     |
     v
PROVIDER API       request accepted + provider message ID       “accepted” / “sent”
     |
     v
PROVIDER QUEUE     scheduled, queued, retried, or suppressed     “queued” / “deferred”
     |
     v
DESTINATION SMTP   remote server returns final 250 response      “delivered”
     |
     v
MAILBOX PIPELINE   inbox, category, spam, quarantine, rule       usually not observable
     |
     v
HUMAN / CLIENT     render, read, reply, click                     partial/noisy signals

A status describes evidence at one boundary—not every boundary below it.

SMTP's final 250 response after message data means the receiving SMTP server accepted responsibility to deliver or relay the message. If that server later discovers a delivery failure, SMTP calls for a non-delivery notification to the envelope return path. Providers normally translate these protocol outcomes into delivered and bounce events.

What each email status means

STATUS       USUAL EVIDENCE                         DOES NOT PROVE
created      Application recorded an email intent       Provider received it
queued       A system plans or retries submission       Any network handoff
scheduled    Provider will attempt at a future time      Future eligibility or delivery
sent         Provider accepted/attempted the message    Destination acceptance
delivered    Destination SMTP accepted the recipient    Inbox placement or reading
deferred     Temporary remote/provider condition        Permanent failure
bounced      Delivery failed for that recipient         Why without the SMTP/DSN detail
dropped      Provider intentionally did not attempt     Remote rejection
suppressed   Policy/list blocked the send               Current mailbox validity by itself
opened       Tracking resource was requested            A human read or understood it
clicked      Tracked URL was requested                  Intent, conversion, or human action
complained   Complaint signal reached the sender        Every complaint at every receiver

Some systems label a message sent immediately after an API 2xx; others wait until an outbound SMTP attempt. Some use delivered for the destination server's 250 response; others expose accepted. Document your provider's exact definition and normalize it into your application without inventing more certainty than the source event contains.

Accepted by an API is not delivered

HTTP 2xx FROM EMAIL API
Provider accepted a valid request and normally returned a message ID.

SMTP 250 FROM DESTINATION
Destination server accepted responsibility for one recipient.

PRODUCT OUTCOME
Recipient completed verification, viewed the receipt, or acted in the app.

Record all three separately. Never use HTTP success as the product outcome.

An API can accept a message that later fails because the domain has no mail exchanger, the mailbox does not exist, the receiver temporarily defers traffic, or the provider suppresses the recipient under its policy. Store the provider message ID from submission, then update your ledger from authenticated delivery events.

Delivered does not mean inboxed

The destination can accept a message and subsequently place it in a spam folder, category, quarantine, moderation queue, mailbox rule destination, or another internal system. The sender generally does not receive a reliable per-message “primary inbox” receipt. A provider claiming a delivered event is normally reporting SMTP acceptance, not a view into the recipient's final folder.

• Use direct rejection and bounce details to diagnose transport failure.
• Use authentication results, complaint data, domain/IP reputation, receiver postmaster tools, and controlled seed testing for deliverability questions within their limits.
• Use product events such as verified_at or receipt_viewed_at when the application outcome matters.
• Do not tell support that delivery proves the customer ignored the message; filters, rules, aliases, and mailbox access can intervene after acceptance.

Delivered does not mean read

An open event usually records a request for a tiny remote image. Image proxies, privacy protections, security scanners, blocked images, caching, forwarded mail, and plain-text clients can create or hide that request. Treat opens as a noisy engagement signal where appropriate—not a delivery receipt, legal proof of reading, or safe trigger for a critical state change.

Clicks are stronger evidence that a URL was requested but are not automatically human either; security systems prefetch and scan links. Confirm sensitive actions in an authenticated product flow, bind tokens to one narrow purpose, and make automated GET requests harmless.

Deferred vs. bounced email

4xx / enhanced 4.x.x   temporary failure or delay
Provider normally queues and retries under a bounded schedule.
Examples: rate policy, temporary mailbox condition, greylisting, resource issue.

5xx / enhanced 5.x.x   permanent failure for this attempt/recipient
Provider normally stops retrying and emits a bounce.
Examples: nonexistent mailbox, prohibited sender, rejected content or policy.

The first digit is a class, not a complete diagnosis. Preserve the enhanced
status code, remote host, reply text, attempt time, and provider classification.

Do not mark every 5xx as an invalid address. A 5.1.1 mailbox failure differs from a 5.7.1 policy rejection, and response text can be receiver-specific. Suppression rules should distinguish recipient validity, sender authentication, content policy, reputation, and transient infrastructure failures.

Why a delivered message can later bounce

A receiving server can accept a message and later generate a delivery-status notification when downstream delivery fails. Relays, aliases, gateways, and asynchronous mailbox systems make this possible. Your event model should preserve chronology and evidence instead of assuming delivered is an irreversible business truth under every provider contract.

Build a recipient-level status model

email_intent_id       receipt:payment_4821:v3
recipient_id          usr_72
provider_message_id   msg_...
submission_state      accepted
accepted_at           2026-08-04T18:42:10Z
delivery_state        delivered
delivered_at          2026-08-04T18:42:12Z
latest_smtp_code      250 2.0.0
bounced_at            null
complained_at         null
provider_event_ids    [...]
template_version      receipt_v3

Keep the event log. A single mutable status discards useful sequence and cause.

• Track one state per recipient, not only one status for a multi-recipient SMTP message.
• Verify webhook signatures against the raw request body before trusting an event.
• Deduplicate provider event IDs and accept that events can be retried or arrive out of order.
• Retain the remote response and enhanced status code in a protected support-visible timeline.
• Separate submission state, delivery evidence, engagement signals, suppression, and business completion.
• Reconcile messages that remain queued or accepted beyond a purpose-specific threshold.

Debug “sent but not delivered”

1. Resolve the immutable application intent and provider message ID
2. Confirm API/SMTP acceptance time and exact provider status definition
3. Inspect every recipient-level attempt, remote host, reply, and event
4. If deferred, read the 4xx detail and next retry/expiry
5. If bounced, classify address vs authentication vs policy vs reputation
6. If delivered, explain SMTP acceptance without promising inbox placement
7. Check current suppression and complaint state before any resend
8. Re-read authoritative product state and token validity
9. Resend only as a new, authorized, rate-limited business action
10. Correlate repeated failures by domain, stream, template, deploy, and provider

If no provider record exists, investigate the application queue, transaction boundary, worker, credential, and request logs. If a provider record exists but no delivery event arrives, investigate provider queue state and webhook ingestion. If delivery exists but the user cannot find the message, verify the address and product state, suggest mailbox search and filtering checks, and provide a safe in-product alternative when possible.

Measure the funnel without mixing denominators

submission_acceptance = accepted submissions / attempted submissions
delivery_rate        = destination-accepted recipients / accepted recipients
bounce_rate          = bounced recipients / attempted or accepted recipients
deferral_rate        = temporarily deferred recipients / attempted recipients
complaint_rate       = reported complaints / delivered recipients
product_completion   = verified/paid/viewed outcomes / eligible intents

Publish each denominator. “98% successful” is meaningless without its boundary.

Segment by mailbox provider, sender domain, IP pool, message stream, tenant, template, and deployment. Watch time-to-accept, time-to-deliver, queue age, missing-event age, bounce class, and complaint changes. A healthy global delivery rate can hide a complete outage for one destination domain.

Frequently asked questions

What is the difference between sent and delivered email?

Sent generally means the sending application or provider accepted or attempted the message. Delivered generally means the destination mail server accepted it for that recipient. Provider terminology varies, so confirm the event definition. Delivered still does not prove inbox placement or reading.

Can an email say delivered if the recipient did not receive it?

Yes. The receiving server can accept it and then route it to spam, quarantine, a category, an alias destination, or a mailbox rule. The user can also be checking a different account or lose access. Delivery is strong transport evidence but not proof of final folder visibility.

Should I resend an email that only says sent?

Not automatically. Check whether sent means provider acceptance, whether the message is queued or deferred, whether a later event is missing, and whether the business action remains valid. Blind resends can duplicate receipts and security messages. Use a named, authorized resend flow with rate limits and new intent evidence.