“Delivered” usually means the recipient’s mail server accepted the message. It does not prove that the message reached the inbox or that anyone read it. Find the last confirmed event, then investigate the next handoff.
Start with one message, not a dashboard average
A user asks for another password reset. Your dashboard is green, but their inbox is empty. Before changing DNS or sending again, identify the exact logical request. A healthy delivery rate cannot tell you what happened to this one email.
Record the application event ID, recipient, environment, provider message ID, and UTC timestamps. Confirm the address against the account record; a typo, stale account address, or Test credential can explain the mismatch immediately. Keep reset tokens and API keys out of support tickets.
Use the most specific evidence available. An HTTP success response may only prove durable queue acceptance. A provider submission is another step. A receiving-server response is another. An open event is an observation affected by image loading and privacy features, not a reliable receipt from the person.
What each status can actually tell you
| Last evidence | What you know | What to inspect next |
|---|---|---|
| No request record | The application may not have submitted successfully. | Validation, authentication, request logs, and the application outbox. |
| Queued | The service accepted a job for processing. | Queue age, worker health, project pauses, and limits. |
| Submitted | The provider accepted the submission. | Provider delivery events and their timestamps. |
| Bounced or rejected | The attempt failed at a specific boundary. | SMTP response, recipient validity, policy, and suppressions. |
| Accepted / delivered | The receiving server accepted the message. | Recipient-side spam, quarantine, routing rules, and message trace. |
| Uncertain | The result of a submission is unresolved. | Reconciliation using the existing request and provider identifiers. |
If the message is still queued
Compare the oldest queued message with the time the worker last reported healthy. A queue can be growing while the web application serves requests normally. Look for a paused project, exhausted sending allowance, a disabled dispatcher, or a provider capacity limit.
Check whether the problem affects one project or every project. A single-project problem suggests a credential, domain, template, or project-level limit; a broad problem suggests shared infrastructure. This is a diagnostic starting point, not proof of the cause.
Make the recovery action match the evidence. Restoring the worker is different from creating a new message. Re-submitting the application event can leave two valid jobs waiting for the same recipient.
If the receiving server accepted it
DNS authentication fixes do not retrieve an already quarantined message. Treat the current incident and the next-send configuration as two work items. Preserve the original evidence so you can tell whether a change helped.
- Ask the recipient to search all folders by the exact sender and subject, including spam and archive. Check mailbox rules and forwarding.
- For an organization mailbox, ask its administrator to inspect quarantine and run a message trace. Supply the provider/message identifier and UTC acceptance time.
- If a copy is available, examine its original headers. Prefer the Authentication-Results field written by the receiving system you trust; pasted headers can contain forged results.
- Check whether the email arrived after the token expired. Delivery latency and token lifetime are separate problems that need separate evidence.
If it bounced, read the reason before retrying
Keep the SMTP response and provider category together. A nonexistent mailbox, a temporary receiving-server problem, and a sender-policy rejection need different actions. Repeated attempts at a permanently invalid recipient add noise and can damage sender reputation.
Check both project-level suppressions and provider-level restrictions. Removing a local record may not remove a provider suppression, and a complaint should not be treated as a technical obstacle to bypass. Correct the underlying recipient or sending-policy problem first.
If an API connection timed out, do not infer that nothing happened. Reconcile the existing operation or retry with the same idempotency key and unchanged payload within the provider’s supported window.
Leave the next person a useful handoff
A good incident note separates observations from assumptions: “Receiving server accepted at 14:08 UTC; inbox location unknown; recipient administrator is tracing message X.” That note is more actionable than “Email works on our side.”
After recovery, retain a small regression fixture: a paused queue, a rejected recipient, or a delayed event. Exercise the application behavior without contacting a real mailbox. Track queue age and unresolved sends so the next incident is visible before a customer reports it.
Sources and further reading
Written for Stampwing with AI assistance and checked against the linked documentation. Examples are educational; simulated results are labelled. How these resources are maintained.