Read queued, accepted, blocked, and bounced states as evidence.

Follow the message through its real path

Start with the sending source: API, authenticated SMTP, WordPress, Laravel, campaign, mailbox, or desktop client. Then check sender readiness, the selected provider response, and any later event.

The same word can have different scope. For example, an EmailDesk queue acknowledgement can mean the platform accepted ownership of a future handoff, while an SMTP provider's 250 response means that provider accepted the handoff at that moment.

Interpret the main operational states

Use the stored delivery stage, SMTP status, response text, provider message ID, and event history rather than relying on a single visual label.

• Queued: EmailDesk or the gateway accepted the message for further processing; delivery is not final.
• Gateway accepted: the provider returned an accepted response such as SMTP 250. EmailDesk SMTP relay records this as queued, not final Sent.
• Blocked before provider: EmailDesk stopped the message for sender, DNS, recipient, suppression, quota, protection, or another local requirement before an upstream attempt.
• Rejected: the upstream provider refused the handoff. Authentication, policy, sender, recipient, content, or account evidence can explain why.
• Deferred or rate limited: the response appears temporary. Retry behavior depends on the sending path and the evidence returned.
• Bounced: a later delivery-status event says the destination could not accept or retain the message.
• Handoff unknown: EmailDesk started a handoff but did not record a final provider response. Verify provider evidence before retrying.

Use the evidence in the right order

Check EmailDesk Outbound History for the source, credential or server, exact From address, selected gateway, policy decision, quota receipt, SMTP response, provider message ID, and later events.

For an uncertain outcome, ask the sender or recipient to confirm receipt before resending. A blind retry can create a duplicate if the provider accepted the first attempt but its response was lost.

• No provider response plus a local block means no provider handoff occurred.
• A provider message ID or accepted response supports handoff evidence, not inbox evidence.
• A later bounce or complaint supersedes the earlier operational assumption.
• Spam/Junk placement may not generate a bounce and remains controlled by the recipient provider.

Keep status and quota evidence separate

EmailDesk records quota at a genuine provider-handoff attempt. A local pre-handoff block does not consume sending quota. A provider failure after a genuine attempt can still count because provider resources were used.

A retry of the same EmailDesk SMTP relay transaction reuses its durable receipt and quota key. A new submission or direct API resubmission is a new send and can create a new quota event.

Do not translate acceptance into a guarantee

EmailDesk controls its checks, queue records, provider-handoff attempt, and stored evidence. The upstream and recipient providers control their own acceptance, throttling, filtering, Spam/Junk placement, and final delivery.

Some downstream systems do not expose a final event. In that case the evidence can remain accepted or uncertain rather than becoming a guaranteed Delivered state.