---
title: "Delivered but not received"
description: "The send was accepted or shows delivered and nothing arrived. Work through message status, suppression, filtering, and routing in order."
---

> **For AI agents:** the complete documentation index is at [llms.txt](/docs/llms.txt). Append `.md` to any page URL for its markdown version.

`delivered` means the receiving server accepted the message, not that a person saw it land in an inbox. Work through the message status, suppression, filtering, and recipient-side routing in that order before assuming something is broken.

## First, check the message status

Pull the message and its event timeline:

```bash
curl https://api.mailfully.com/v1/emails/01J9ZC3AB8XQ4RW2N7VKT5EMHD \
  -H "Authorization: Bearer mf_live_xxxxxxxxxxxx"

curl https://api.mailfully.com/v1/emails/01J9ZC3AB8XQ4RW2N7VKT5EMHD/events \
  -H "Authorization: Bearer mf_live_xxxxxxxxxxxx"
```

Some statuses look like success but leave room for exactly the report "nothing arrived":

| Status | Meaning | Terminal |
|---|---|---|
| `sent` | SES accepted the message; delivery outcome pending | No |
| `delivered` | SES reported successful delivery | No |

`delivered` is not terminal: a recipient can mark the mail as spam after delivery, or a late permanent-bounce report can still arrive, so a `delivered` message can still transition to `complained` or `bounced`. See [How sending works](/concepts/how-sending-works#the-lifecycle) for the full nine-status table.

## Was the recipient suppressed

This is the case that produces a `202` and no mail at all, so it is worth ruling out first when the API said it worked. Three outcomes:

- **Some recipients suppressed**: the message goes to the rest.
- **Every `to` recipient suppressed at accept time**: you get `202` with an id, but the message is persisted with status `canceled`. Nothing is enqueued and nothing is metered.
- **Suppressed in the race window between accept and dispatch**: the message flips to status `failed` with `last_event: "suppressed"`, and a synthetic `suppressed` event is written to the event timeline.

The third case is the one worth an example, because the initial `202` says nothing about it and the event timeline does. A `suppressed` event lands there alongside the ordinary `send` event:

```json
{
  "data": [
    { "type": "send", "event_at": "2026-07-08T14:02:12.000Z", "detail": null },
    { "type": "suppressed", "event_at": "2026-07-08T14:02:12.410Z", "detail": null }
  ]
}
```

See [Suppressions](/guides/suppressions#sending-to-a-suppressed-address) and [Why an address was suppressed](/deliverability/suppression-causes) for how an address ends up on the list in the first place.

## Accepted and then filtered

A `delivered` event with nothing in the inbox means the receiving server accepted the message and then filed it somewhere the recipient did not look. Spam is the first place to check. See [Why emails go to spam](/deliverability/why-emails-go-to-spam) for the causes that push mail there.

## Routing at the recipient's side

Forwarding rules, aliases, catch-all domains, and corporate quarantine can all intercept a message after `delivered`. Ask the recipient to check their organization's quarantine or a forwarding rule before assuming the send itself failed.

## Test mode sends never arrive

By design, every recipient in a test-mode send is rewritten to a labeled address on the Amazon SES mailbox simulator, so no mail reaches a real inbox. See [Test mode](/guides/test-mode). If you're seeing this report and didn't mean to send in test mode, check whether an `mf_test_` key was used by mistake.

## What to collect before contacting support

Support will want the message id, the send timestamp, the recipient's domain, and the event timeline from [`GET /v1/emails/:id/events`](/api-reference/emails/list-events).