Emails not being delivered? Trace a missing message step by step

Before you start: get two facts from the customer#

It usually starts with a message from a customer: “I never got my receipt.” Before you change anything, ask for two facts: the exact address they expected it at, and roughly when. A reply like this gets you both facts and buys time:

Thanks for telling us. Could you check two things for me?
1. Is this the address you expected it at: ada@exmaple.com?
2. Could you search your spam folder and other tabs for "Order 1042"?
I'm checking our side now and will write back today.

Sent by your store or booking platform?#

Then the platform holds the records, and you read them through it. Open the order or booking and look at its timeline or notes: most platforms log each notification with the address and the time it went out.

• No notification logged: the email was never triggered. Check the notification is switched on for that order type.
• Logged, wrong address: correct the address on the order and use the order page’s resend action, then go to step 5.
• Logged, right address: ask the platform’s support two questions: “What did the receiving server answer for this address at this time?” and “Is the address on your suppression list?” Their answer is a reply code or a suppression, which step 3 explains. If support cannot see it, ask the customer for another address.

1. Did your system send it?#

Look in your sending service’s log (the store platform, newsletter tool or email API that sent it) for the message by recipient and time. No record at all means it was never handed over: the code did not run, the request failed, or a job is stuck. If your own code sends it, check its log for the send call and the response.

If there is a record, check the address character by character. A typo in the domain, such as gmial.com, can be a real domain that accepts the mail. Then check that the email was not scheduled for later or cancelled.

2. Did the receiving server accept it?#

The customer’s mail server answers every message with yes, try later, or no, as a three-digit reply code. RFC 5321 splits them into classes: 2xx means accepted, 4xx means a temporary failure the sender may retry, and 5xx means a permanent failure that the sender “SHOULD NOT repeat” as it is.^[1]

• Delivered means the receiving server accepted it, not that it reached the inbox: a delivery event never reports the folder. Go to step 4.
• Delayed means a 4xx, and the sender retries. RFC 5321 advises retrying no sooner than every 30 minutes and giving up after “at least 4-5 days”; each sending service sets its own limit, and when it gives up the delay becomes a bounce.^[1] Read the reason. At Gmail, a run of 421 4.7.28 means it has detected an unusual rate of mail from you, and several variants of that message say unsolicited mail. Slowing down helps, but check your list and your spam rate against Gmail’s limits too.^[2]
• Bounced usually means a 5xx, or a 4xx the sender stopped retrying, and the text after the code says why. Go to step 3.

3. Was it bounced or suppressed, and why?#

Read the code before you act on it. In an enhanced code like 5.1.1, the middle number names the kind of problem: 1 the address, 2 the mailbox, 7 security or policy.^[3] For a policy refusal, read the receiver’s text: it usually says whether the refusal is about your mail or the recipient’s own rules.

Sources for the texts: Gmail’s SMTP error reference^[2], Microsoft’s blocked-senders page^[4] and Outlook.com’s sender policies.^[10] Microsoft’s own bounce reference names 5.1.1 “Bad destination mailbox address” and 5.7.1 “Delivery not authorized”.^[5]

SPF lists the servers allowed to send for your domain, DKIM signs each message with a key your domain publishes, and DMARC tells receivers what to do when neither passes for the domain in your From address. Gmail uses 5.7.26 for three cases, and the text says which: “sender is unauthenticated” means neither SPF nor DKIM passed; “hard fail policy (-all)” means SPF failed for a bounce domain whose record ends in -all; and “DMARC policy” means neither passed in alignment with your From domain, for example when SPF passed only for the sending service’s own bounce domain. The usual causes are a sending service never set up for your domain, or a DKIM record that was removed. To check, open one of your own sent messages in Gmail with Show original: it lists SPF, DKIM and DMARC as PASS or FAIL. The DKIM, SPF and DMARC article shows how to read them. If someone else runs your domain or your platform, send them the code and the date it started.

Suppressed: nothing was sent#

Most sending services keep a suppression list of addresses that bounced, complained or unsubscribed, and skip them on later sends. That protects your reputation, and it is the most common answer to “it never arrived, and there is no bounce”. Look the address up on your suppression list. The suppression list article explains when removing one is safe.

A bounce that names a blocklist, or a wave of 5.7.x rejections from one provider, points at your sending reputation. Checking whether you are on a blocklist is the next step.

4. Accepted, but where did it land?#

• Spam or junk. Ask the customer to mark it as not spam, and read why emails go to spam.
• Promotions, Updates or another tab. That is the inbox, sorted. The Promotions tab guide explains why.
• Their own rules and filters, including forwarding to another address.
• A company quarantine. Work email often passes a security filter that holds messages for an administrator. Send their IT team the message’s Message-ID, the address and the time you sent it with its time zone, so they can run a trace.
• Nowhere at all. Rarely, a receiver accepts a message and then discards it, or sends its bounce hours later. Only the receiving side’s own trace can show that, which is why the Message-ID matters.

To find a Message-ID, open your copy of the message in your Sent folder and show its full header. In Gmail on a computer: open the message, select More beside Reply, then “Show original”.^[6] In Outlook on the web: More actions, View, then “View message details”; in classic Outlook for Windows, open the message, then File, Properties.^[7] Look for the line that starts Message-ID:. A sending service usually shows it in its log too.

If you run the receiving side: Exchange Online’s message trace and Google Workspace’s Email Log Search both find a message by its Message-ID.^[8][9]

5. Fix the cause, then send it again#

Once you know the cause, the fix decides whether a second send will arrive:

• Wrong address: correct it on the customer’s record and send to the corrected one. Never retry the wrong one.
• Your setup refused (5.7.x): fix it, check the address is not left on your suppression list, then send again.
• Suppressed after their own bounce, complaint or unsubscribe: leave the suppression in place and ask for another address.
• In spam, a tab or a quarantine: they have it. Sending again only adds a second copy to the same folder.

Then tell the customer what happened, in one or two lines:

Found it: the receipt went to ada@exmaple.com, one letter off.
I've sent it again to ada@example.com just now, and fixed the address on your order.

When many emails stop arriving at once#

One missing email is about one address. Many at once is about you, and the bounce codes say which part: count them by code and by receiving domain for the last day.

• Many 5.7.26 or 5.7.515: authentication broke. Look for a DNS edit or a rotated DKIM key in the days before, and read your DMARC aggregate reports, which show which sources fail at every receiver that sends them. The DMARC guide covers them.
• Many 4.7.28 at Gmail: Gmail is limiting you. Postmaster Tools shows its view, for mail to personal Gmail accounts only.^[11] The Postmaster Tools guide explains it.
• Many 5.1.1: a bad list, usually a new import. Stop mailing it. On order emails it usually means checkout accepts typos.
• Delivered as usual, but clicks fell: check placement first, since bounce codes cannot show spam or a tab, then rule out a blocked link domain or a change in who you mailed. When mail suddenly goes to spam is the checklist for that.

After an authentication incident, clean up the good addresses it suppressed: the last section shows how in Rasket.

Tracing a message in Rasket#

This section is for developers sending through Rasket’s API. If a platform sends your mail, its own log and support are the place to look, and you can stop here. Every email you send through Rasket has a record with its latest status and a timeline of events for each recipient. Open it from the Emails page in the dashboard, or ask the API:

# Find the email by recipient and send time (search matches any recipient address)
curl "https://api.rasket.com/emails?search=ada@example.com&start_date=2026-10-17T00:00:00Z&end_date=2026-10-18T00:00:00Z" \
  -H "Authorization: Bearer $RASKET_API_KEY"

# What happened to it, step by step ($EMAIL_ID is its "id" above)
curl https://api.rasket.com/emails/$EMAIL_ID/events \
  -H "Authorization: Bearer $RASKET_API_KEY"

# Is the address on your suppression list, and why (origin)?
curl https://api.rasket.com/suppressions/customer@example.com \
  -H "Authorization: Bearer $RASKET_API_KEY"

# The cause is fixed and the person wants your mail: take the address off the list
curl -X DELETE https://api.rasket.com/suppressions/customer@example.com \
  -H "Authorization: Bearer $RASKET_API_KEY"

• queued, scheduled or canceled: step 1. It has not gone out.
• sent (handed to our mail servers, waiting for the receiver’s answer) or delivered: step 2.
• delivery_delayed: step 2. The event’s delay object carries each recipient’s reply and an expirationTime, when our mail servers stop trying and the delay becomes a bounce.
• bounced: step 3. The event’s bounce.message is the receiver’s reply.
• failed: the message could not be handed over at all. Its event says why.
• suppressed: nothing was sent to that address. The send still returned an id, and the email.suppressed event gives the reason: a previous bounce, a previous complaint, a manual entry, an unsubscribe, or an address that cannot receive mail.
• complained: the recipient marked it as spam, so it did reach them.

To hear about failures before customers do, subscribe a webhook to email.bounced, email.suppressed, email.delivery_delayed, email.failed and email.complained. A bounce arrives like this, trimmed; the webhooks reference lists every field and shows how to verify each delivery’s signature:

{
  "type": "email.bounced",
  "created_at": "2026-10-17T09:12:40.118Z",
  "data": {
    "email_id": "0bc578f5-9fc5-4a1d-af03-3c8945fe655d",
    "to": ["ada@example.com"],
    "subject": "Your receipt for order 1042",
    "message_id": "<8a4c0f12@yourshop.com>",
    "bounce": {
      "type": "Permanent",
      "subType": "General",
      "message": "smtp; 550 5.7.26 This email has been blocked because the sender is unauthenticated.",
      "diagnosticCode": ["smtp; 550 5.7.26 This email has been blocked because the sender is unauthenticated."]
    }
  }
}

Read bounce.message, the first recipient’s reply; diagnosticCode holds one reply per recipient for a send to several. The nested bounce object keeps its field names in camelCase.

When a policy refusal suppresses a good address#

Rasket puts an address on your suppression list automatically when the receiving side reports the bounce as permanent, whatever the code. So a broken DKIM record can suppress real customers along with dead addresses. Catch it early: alert on a run of 5.7.26 or 5.7.515 in bounce.message, which name authentication. Other 5.7.x codes are mixed: one person’s “not authorized” can be their own company’s rule. Once the cause is fixed, list the bounce suppressions added during the incident, read each one’s source email, and remove only the ones that were yours:

# 1. Bounce suppressions added while authentication was broken. While the reply
#    says "has_more": true, repeat with &after=<the last item's id>.
curl "https://api.rasket.com/suppressions?origin=bounce&start_date=2026-10-17T08:00:00Z&end_date=2026-10-17T11:30:00Z&limit=100" \
  -H "Authorization: Bearer $RASKET_API_KEY"

# 2. For each item, read the bounce of the email that caused it (its source_id).
#    5.7.26 or 5.7.515, or text naming authentication: yours, so remove it.
#    5.1.1, or any other 5.7.x: leave it suppressed until you have read it.
curl https://api.rasket.com/emails/$SOURCE_ID/events \
  -H "Authorization: Bearer $RASKET_API_KEY"

# 3. Remove the ones that were yours, up to 100 addresses per call
#    (the suppressions reference at rasket.com/docs/api-reference/suppressions)
curl -X POST https://api.rasket.com/suppressions/batch/remove \
  -H "Authorization: Bearer $RASKET_API_KEY" -H "Content-Type: application/json" \
  -d '{"emails": ["ronald@example.com", "ada@example.com"]}'

Then send those customers’ emails again (step 5). If your send calls carry an Idempotency-Key, the header that stops a retried request sending twice, give the new send a new key: a key you already used returns the first response for 24 hours and sends nothing (the emails reference).