Delivered but not received

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:

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":

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 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:

{
  "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 and Why an address was suppressed 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 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. 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.