# It says delivered but the recipient didn't get it

> A delivered event means the receiving mail server accepted the message — not that it reached the inbox. Here is where a "delivered but missing" email usually ends up.

A `delivered` event means **the receiving mail server accepted the message** and returned a `250 OK` success code over SMTP. That is the furthest point we can observe: once the recipient's server takes the message, it may file it in the inbox, queue it for later, route it to spam, or even discard it — and what happens next (a forwarding rule, a filter, a quarantine) is entirely on their side and is **not** reported back to us. Any later event (open, click, unsubscribe) requires the recipient to actually engage.

> **Note:** `delivered` = accepted by the destination server. It is **not** a read receipt and **not** a guarantee the message reached the visible inbox.

## Where a "delivered" email usually is

### Spam or quarantine

The most common landing spot. The server accepted the message (so it counts as delivered) and then filed it in the **Spam/Junk** folder, or held it in an **admin quarantine** that the user never sees. Ask the recipient to check Spam/Junk, and — on corporate accounts — to ask their admin to check the quarantine and release/allowlist your sender.

### Aliases and forwarding

If the address is an **alias** or **forwarder** (e.g. `team@` redirecting to several mailboxes, or a personal address forwarding to another provider), delivery to the first hop succeeds, but the forward to the final mailbox can be silently filtered or broken by SPF/DKIM alignment loss on the second hop. Confirm the real destination mailbox and test sending to it directly.

### Provider-side filtering rules

User-created **mail rules** (filters that auto-archive, delete, or move messages by sender/subject) and organization-wide policies can move an accepted message out of the inbox immediately. Have the recipient search **all folders** (including Archive, Trash, and any custom folders) for your subject or from-address.

## How to diagnose

1. **Check the email log** — Open the email by its `id` in the dashboard (or via [retrieve email](https://www.mailblastr.com/docs/api/emails-get)). A `delivered` event with no `bounce` or `complaint` confirms the destination server accepted it.
2. **Have the recipient search everywhere** — Spam/Junk, Archive, Trash, and custom folders — search by your from-address, not just the subject.
3. **Check aliases/forwarding** — If the address forwards elsewhere, send a direct test to the final mailbox to isolate the second hop.
4. **Ask about quarantine** — On business email, the admin quarantine is invisible to the user. Have them ask IT to check it and allowlist your domain.

## If you can reach the recipient

The fastest fix is to have the recipient look in the likely hiding spots and, if they find your message, mark it **Not Spam** or add your domain to their allowlist:

- Corporate spam filters or firewalls
- Personal inbox filtering rules
- Promotional, spam/junk, or deleted folders
- Group inboxes or shared queues

## Improve your odds next time

When you can't reach the recipient, you can still raise the chance the next message lands in the inbox:

- **Publish DMARC** to build trust with the receiving provider — see [DNS records](https://www.mailblastr.com/docs/domains/dns).
- **Warm up new domains** slowly before sending large volumes — see the [warm-up guide](https://www.mailblastr.com/docs/kb/warm-up).
- **Align link domains** with your sending domain (avoid shorteners and unrelated link hosts).
- **Turn off open/click tracking** for streams where placement matters most — tracking can read as promotional.
- **Reduce images** and trim the body; succinct, balanced HTML scores better than heavy marketing layouts.

> **Warning:** If messages land in Spam consistently (not just once), it is a **deliverability** problem, not a one-off. Tighten SPF/DKIM/DMARC alignment, warm up the domain, and clean your list. See [Deliverability](https://www.mailblastr.com/docs/kb/why-spam).