Email Says Delivered but Was Not Received: A Diagnostic Checklist

TL;DR

• A delivered event usually confirms acceptance by the recipient's mail server, not that the message appeared in the inbox or was read.
• Start with the exact recipient, provider message ID and event timestamps before changing configuration.
• Check mailbox folders, rules, forwarding and organization-level quarantine with the recipient or their administrator.
• Avoid repeated blind resends; use the evidence to decide whether a new send is appropriate.

Understand what the delivered event confirms

When an email says delivered but the recipient cannot find it, the first step is to define “delivered.” Amazon SES's delivery-event documentation describes delivery to the recipient's mail server and includes information such as the receiving server's SMTP response. That is a transport milestone, not proof of inbox placement or reading.

After acceptance, the receiving system can apply filtering, mailbox rules, forwarding or quarantine. The sender may have limited visibility into those decisions. A useful investigation separates what your logs prove from what needs evidence on the recipient's side.

Confirm that you are investigating the right message

Collect the intended recipient address, the provider message ID, the subject, the send time and the relevant event timestamps. Check for aliases, spelling differences and multiple attempts with similar subjects.

Make sure the delivered event belongs to the message and recipient you are discussing. In systems that send to multiple recipients, a result for one recipient does not automatically describe every address in the request. Keep the provider's actual event scope intact.

Do not ask the recipient to paste private message contents into an unsecured chat. Most initial troubleshooting can begin with identifiers, timestamps and a description of the missing notification. Use an appropriate support channel for sensitive details.

Review the complete event sequence

Look at the available send, delay, delivery, bounce and complaint events. Record when the event occurred and when your application received it; those timestamps can differ. A delayed webhook should not be mistaken for a later transport event.

Verify that your application did not overwrite a more meaningful state with an older event that arrived late. The webhook retry guide explains why arrival order alone is a poor state-management rule.

If the provider returned a message ID but no delivery evidence exists yet, describe the state accurately as accepted or pending according to the provider's contract. Do not convert every successful API response into an inbox-delivered label.

Check the recipient's mailbox and organization

Ask the recipient to search for the sender and subject across the relevant folders, including spam or junk and any archive. They should also check filters, forwarding rules and alternate inbox categories in their own mail client.

For an organization-managed mailbox, an administrator may be able to inspect message tracing or quarantine. Give them the recipient, timestamp, sender and message identifier needed to locate the event. A corporate gateway can accept a message before a separate policy decides where it goes.

Avoid assuming that a successful delivery to one mailbox provider proves delivery behavior at another. Test accounts can help identify a pattern, but they do not reproduce every recipient's rules or organization policy.

Inspect the sender-side details that matter

Review the actual From address, sending domain, subject and content. Confirm that the domain authentication setup is still correct and that the message is not misleading or unexpectedly promotional. Check links and attachments for the specific message, not just a generic test template.

Use the SPF, DKIM and DMARC explanation when authentication needs review. If a DNS record is failing verification, follow the domain-verification checklist rather than replacing unrelated records at random.

A support investigation should change one justified variable at a time. If you alter the domain, template, subject and recipient simultaneously, a successful test will not explain which change mattered.

Decide whether to resend

Do not repeatedly resend the same message merely because the first copy is hard to find. That can create several valid receipts, invitations or reset links and make the investigation more confusing.

If a new send is appropriate, make it an explicit new notification or user-requested resend with its own record. Preserve the original message's evidence. The idempotency guide distinguishes retrying an uncertain request from deliberately sending another copy.

For time-sensitive actions, verify that the destination still works and that any expiration or replacement behavior is clearly explained to the recipient. A delivered but expired link is a different problem from a missing message.

Keep a concise support record

Finish with the message ID, event evidence, recipient-side findings, changes made and final outcome. If the receiving system accepted the email but its later handling remains unknown, say so. An honest unresolved boundary is more useful than a confident claim that the recipient must have overlooked it.

MailBlastr's message and event records can support the sender-side investigation. Combine them with the recipient's mailbox evidence to identify the actual failure point and improve the next notification.