---
title: "Received mail is missing"
description: "Work out why a message sent to your domain or hosted address never appeared in Mailfully, or appears but cannot be opened."
---

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

A message someone sent you is not in the Received list, or it is listed but the API refuses to return its content. Work through the checks in order; the first one that fails is usually the cause.

## Check the MX record

Mail reaches Mailfully only when the recipient domain's MX record points at it. Query the exact name the sender used:

```bash
dig +short mail.acme.com MX
```

| Answer | What it means |
|---|---|
| `10 inbound-smtp.us-east-1.amazonaws.com.` only | Correct. Move on to the next check. |
| Empty | The record is not published, or has not propagated yet. Publish the MX row from the domain's `records`. |
| Another provider's host | Mail goes to that provider, not Mailfully. Receive on a subdomain instead; see [When the domain already receives mail](/guides/receiving-email#when-the-domain-already-receives-mail). |
| Both | Mail is split between the two. Remove one. |

Look up the name after the `@` exactly. Receiving on `mail.acme.com` does not cover `support@acme.com` or `support@eu.mail.acme.com`; each name needs its own domain and MX record.

## Check that receiving is on

The MX record alone is not enough. Fetch the domain and read `receiving`:

```bash
curl https://api.mailfully.com/v1/domains/dom_01J1PZ3M8Q7VXCK4T2R9WFH6BD \
  -H "Authorization: Bearer mf_live_xxxxxxxxxxxx"
```

When `receiving` is `false` but the MX record still points at Mailfully, incoming mail is accepted and then dropped. It is not stored, and the sender gets no bounce, so nothing on either side shows an error. Turn it on with [`PATCH /v1/domains/{id}`](/api-reference/domains/update-receiving).

For the hosted address, check that it is still on in the dashboard's settings. Mail to it while it is off is dropped the same way.

## Check the sender's side

If DNS and the toggle are both right, ask the sender for the bounce they received, if any. Two causes show up there:

- **The message was over 40 MB.** SES refuses it during the SMTP conversation, so the sender gets a bounce and Mailfully never sees it.
- **The sender typed the address wrong.** Receiving is catch-all, so a typo in the local part still arrives; a typo in the domain does not.

## Listed, but the content is refused

| What you see | Cause | Fix |
|---|---|---|
| `quota_locked: true` in the list, `403 email_above_quota` on detail | It arrived after your organization crossed its monthly ceiling or spend cap | It unlocks at the start of the next month, after an upgrade, or after raising the spend cap. See [Mail received over the limit](/guides/receiving-email#mail-received-over-the-limit). |
| `html`, `text`, and `raw` are `null`, and `headers` is `[]` | `virus` is `FAIL`, so only metadata was stored | Nothing to recover; ask the sender to resend a clean copy |
| `403 insufficient_scope` | The key lacks `read:inbound` | Create a new key with `read:inbound`; `send` and `read:emails` do not grant it |
| `404 not_found` for an id you saw before | The email passed your plan's retention window and was deleted | Save what you need within the window |

## The webhook never arrived

When the email is in the list but no `email.received` reached your endpoint, check that the endpoint is subscribed to `email.received`: endpoints created before receiving existed are not subscribed to it. Then read the endpoint's [delivery attempts](/api-reference/webhooks/list-deliveries) and [dead letters](/api-reference/webhooks/list-dead-letters) as you would for any other event. See [Webhooks](/guides/webhooks).