Resend says delivered, but the email is not in the inbox

What delivered actually means

Resend documents email.delivered as delivery to the recipient's mail server. Its deliverability guidance explains that the receiving server can return 250 OK and then route the message to spam, quarantine, a category tab, a rule, a queue, or in rare cases discard it. Resend receives the acceptance signal, not the receiver's private placement decision.

Map the latest Resend event to the next owner

No email ID

Start in the application or queue. Prove that one request was generated and accepted by Resend before investigating deliverability.

queued / scheduled

The message is waiting for later processing. Confirm the intended send time and wait for a later event instead of creating a duplicate request.

sent

The message was sent from Resend, but this event alone does not prove that the recipient's mail server accepted it. Follow the same email ID to a later result.

suppressed

Resend did not send because the recipient is on a suppression list. Review the exact prior bounce, complaint, or suppression evidence before changing the list.

failed

The send failed before successful delivery. Preserve the failure reason and correct that boundary before one controlled retry.

delivery_delayed

A temporary problem prevented delivery to the recipient's mail server. Keep provider backoff and inspect the evolving event trail; do not start a parallel retry storm.

bounced

The recipient's mail server rejected the message. Preserve the exact bounce response and separate a permanent denial from a transient condition.

delivered

The recipient's mail server accepted the message. Move the investigation to receiver visibility, filtering, and trusted message-header evidence.

The first ten minutes

1. Find the exact application action and UTC timestamp. Confirm that only one login, verification, password-reset, or transaction message should have been generated.
2. Correlate the application record with the Resend email ID and event trail. An API success response is not a substitute for the later message events.
3. Classify scope: one recipient, one receiving domain, one message type, or all traffic. Scope determines whether the next owner is application, provider, or receiver operations.
4. Record the latest event name, event time, provider message ID, and any bounded diagnostic reason. Keep the message body and secret link out of the incident packet.
5. Choose the next action from the event map. Do not change DNS merely because one recipient cannot see a message.

If the latest event is delivered

Ask a controlled recipient to search the mailbox's own interface, not only a synced mobile client. Check spam or junk, quarantine, category tabs, rules, aliases, forwarding, group inboxes, mailbox storage, and security gateways. If the message is found, export the complete original header and compare its trusted receiver timestamps with the Resend delivered event.

• Read the final receiver's Authentication-Results, visible From domain, SPF identity, DKIM d=, DMARC alignment, and newest trusted Received fields.
• Check whether the issue affects one mailbox or the whole receiving domain. Corporate quarantine and routing rules often need the receiving administrator.
• Treat open or click events as recipient engagement signals, not prerequisites for delivery. Missing tracking events do not prove that the message is absent.
• Use one controlled resend only after preserving the first event trail. Verification links should remain short-lived and single-use according to the application's security model.

Analyze a controlled message header locally. The tool structures authentication and routing evidence without uploading the pasted header.

If Resend has not reported delivered

For delivery_delayed or bounced, preserve the full SMTP diagnostic when available. A 4xx response normally represents a temporary failure for that attempt, while a 5xx response normally represents a permanent rejection for that attempt; the enhanced status code and receiver text identify the useful repair path.

Decode the SMTP response locally before changing sender DNS or retry policy. For suppressed or failed, stay at the provider or application boundary until the exact reason is resolved. For an implementation that must reconcile initial 250 acceptance with a later bounce, use the generic per-recipient state model.

Check sender controls without overclaiming

SPF, DKIM, DMARC, PTR, reputation, complaint history, consent, content, volume, and receiver policy can influence acceptance or placement. Public DNS can verify only part of that picture. A clean domain check does not prove inbox placement, and a failed public control should be repaired on the actual sending path rather than by copying another domain's record.

• Use the exact visible From domain and the DKIM identity Resend signs with.
• Confirm that at least one passing authenticated identity aligns with the visible From domain for DMARC.
• Separate a public DNS problem from a receiver-only rule, private quarantine, or reputation decision.
• Inventory every login, verification, fallback, regional, and incident sender before tightening DMARC policy.

A safe handoff packet

Application

UTC event time, random correlation ID, message type, template version, queue result, and Resend email ID.

Resend

Ordered event names and timestamps, latest bounded reason, and the provider message ID. Exclude API keys and webhook secrets.

Receiver

Affected domain and scope, quarantine or rule evidence, and a controlled original header when the message can be found.

Public controls

Visible From domain, current SPF and DMARC state, actual DKIM selector, and known sending-path ownership.

Retry decision

Owner, first corrective action, when one controlled retry is allowed, and how a duplicate secret is invalidated.