It is one of the most common and most frustrating support messages in email: "Your system says delivered, but my customer says they never got it." Both statements can be true. In email, "delivered" almost always means the receiving server accepted the message, not that a person saw it in an inbox. After acceptance, filters, rules, forwarding settings and security gateways can still send the message to a spam folder, a quarantine, a different mailbox or nowhere visible. This guide explains what the delivered status really tells you, lists the places an accepted message can end up, shows how to trace it with logs and message headers, and gives you a list of questions to ask the recipient so that you can find the answer in one round of messages. For the opposite case, where a message is not accepted at all, see why emails will not send.
What "delivered" really means
When your provider sends a message, it opens an SMTP connection to the recipient's mail server, sends the message and waits for a reply. A 250 reply with a queue identifier means the server accepted the message. At that point, your provider marks the event as delivered, because from the sending side the job is finished. The receiving system now owns the message. It may deliver it to a mailbox, move it to junk, hold it for an administrator, forward it elsewhere or silently discard it according to its rules. None of those later decisions is reported back to the sender in real time, so your dashboard cannot tell you about them. That is a property of the protocol, not a defect of any one provider. Our guide tracing a message through its lifecycle shows each stage in more detail.
The places an accepted message can end up
| Where it went | Why it happens | How to confirm |
|---|---|---|
| Spam or junk folder | The content or the sender reputation looked suspicious to the filter | Ask the recipient to search for the subject in Spam, Junk and All Mail |
| Promotions, Updates or Other tab | The mailbox sorts bulk looking mail into tabs or a Focused/Other split | Ask the recipient to look at every tab, not only the primary one |
| Administrator quarantine | A company security gateway held the message for review | The recipient's IT team can search the quarantine and the message trace |
| A mailbox rule or filter | The recipient or an administrator created a rule that moves, deletes or marks mail from that sender or with certain words | Check rules, filters and "Sweep" settings |
| Forwarding to another address | The mailbox forwards a copy to a different account and may keep no copy | Ask whether the address forwards, and check the final account |
| Shared or alias mailbox | The address is an alias or distribution list, and the message went to someone else | Ask which people or mailboxes sit behind the address |
| Mailbox full or over quota | The server accepted the message and later could not store it, or generated a delayed bounce | Check for a later bounce message from the recipient's system |
| Silently dropped by policy | Some providers discard mail they judge to be spam without telling the sender | Check reputation, authentication and complaint rates; see our deliverability guides |
| Delayed, not lost | Greylisting or a slow gateway holds the message for minutes or hours | Compare the accept time with the time the recipient looked |
Step 1: confirm what the log says
Open your message log and find the message by recipient and time. Read the final event and its text. You are looking for three details. First, the accept time and whether it matches when the customer expected the message. Second, the remote response text, for example "250 2.0.0 OK queued as ...". The queue identifier at the end is what a recipient's administrator uses to find the message in their own system. Third, any earlier deferrals. A message that was deferred several times before acceptance may simply have arrived much later than the customer thinks. Keep a copy of the log line, because it is the evidence you will share with the recipient's administrator.
If you use webhooks, the event stream gives you the same facts in machine form, including the timestamp and the response. Our guide to delivery event webhooks shows how to capture them so support can look up any message quickly.
Step 2: check your side of the message
Before you ask the recipient to search, rule out problems that you control. Check that the address was typed correctly. A typo in the domain usually bounces, but a typo in the name part can reach a different real person. Check that the message passed authentication: SPF, DKIM and DMARC should all pass and align, otherwise a receiving filter is likely to treat it as suspicious. Check the content for patterns that filters dislike, such as only an image, a bare link shortener or an unusual subject. Check that you are not sending a transactional message from a shared pool with poor reputation. Our guides on content and spam filters and the spam troubleshooting checklist have the full lists.
Step 3: ask the recipient the right questions
A vague "please check your spam" often ends the conversation. Ask short, concrete questions that lead to evidence.
- Search all mail, including Spam, Junk, Trash and archived folders, for the sender address and for a word from the subject.
- Does the address forward to another account? If yes, check that account too.
- Is this a personal mailbox, a shared mailbox or a distribution list?
- Does your company use a security gateway or a spam quarantine digest? Could someone check it for the sender domain?
- Can your administrator run a message trace for the sender and the time shown, and tell us the final status?
- Please send the exact time you expected it, in your time zone.
Give them the exact timestamp, the sender address, the subject and the queue ID from your log. With those four items, an administrator can run a trace in minutes. Microsoft 365 and Google Workspace both offer message tracing to administrators, and it answers the question definitively.
Step 4: test with other recipients
If you cannot get help from the recipient, test the path yourself. Send the same message to test mailboxes at two or three providers and compare. If it reaches the inbox at one provider and the spam folder at another, you have a provider-specific reputation or content issue. If it reaches the inbox everywhere but not for this customer, the cause is local to their mailbox or organisation. Seed testing at scale is covered in inbox placement testing.
Common patterns and the answer
The customer's company uses a security gateway
This is the most frequent hidden cause in business to business mail. A gateway can hold or rewrite a message even after the mail server accepts it. If you send to many addresses at one company and several report problems, ask them to allow your sending domain and your sending IPs in the gateway. Do not rely on a personal "safe sender" entry, because the gateway acts before the mailbox does. See how to whitelist an email address for the steps in common systems.
Only transactional mail is missing, such as a password reset
If the message is time sensitive, a delay of a few minutes can look like a loss. Check the time between your accept event and the recipient's attempt. If greylisting is involved, the first attempt was deferred and a retry delivered it later. Keep your retry policy sensible and give users a visible "resend" option with a short cooldown, as we describe in password reset email best practices.
The address belongs to a free mailbox provider
Large consumer providers weigh the reputation of the sending domain and IP and the engagement of past recipients. A new domain with no history can land in spam even with perfect authentication. Warm up gradually and avoid sudden jumps in volume. Our guide to email warm-up explains how.
Messages vanish only for one recipient
This points to a rule, a forwarding setting or a full mailbox on that account. It is rarely a problem on your side. A forwarding rule that sends a copy to another address and keeps no local copy produces exactly this symptom: the message was delivered, then forwarded, and the final account may have rejected it.
Prevent the next "delivered but missing" ticket
- Keep message logs for long enough to answer questions about older messages.
- Store the queue ID and accept time with each important message in your own database.
- Give users a "resend" button and a link to a help page that lists the places to check.
- Monitor complaint rate, bounce rate and engagement so that reputation problems are visible before they cost you inbox placement.
- Authenticate every sending stream and align it with the From domain.
- For critical messages, offer a second channel such as an in-app notice or SMS.
Email is a best-effort system. A good support process treats "delivered" as the start of the investigation and not the end of it. With the log line, the queue ID and the four questions above, most cases are solved in one exchange.
See what happened to every message Use message logs and event webhooks to find the accept time and the receiving server reply in seconds.
References and further reading
Frequently asked questions
What does delivered mean in email?
It means the receiving mail server accepted the message with a 250 reply. It does not mean the message reached the inbox. The server may still filter, quarantine or forward it.
Why does my email say delivered but it is not in the inbox?
Common reasons are the spam or junk folder, a Promotions tab, an administrator quarantine, a mailbox rule or forwarding to another address.
How can I prove the message was accepted?
Use the log line with the accept time and the remote response, including the queue ID. The recipient administrator can search for that ID in their message trace.
Can I find out if it went to spam?
Not from the sending side. Providers do not report folder placement. Use seed tests, Postmaster tools and the recipient's own search to find out.
How long can a delay last?
Greylisting and retries can delay a message by minutes or sometimes hours. Compare the accept time with when the recipient expected the message.