Email Sent but Not Received: How to Prove Where It Went

The short answer
When your email shows as sent but the recipient has nothing and no bounce arrived, the receiving server accepted the message and then filtered, quarantined, or silently discarded it. Ask the recipient to check spam and quarantine first, then run a message trace in your email platform, and check your domain authentication records for failures.
Email sent but not received? No bounce means the server accepted it, then filtered it. Here is how to trace exactly where it went and fix the cause.
On this page
- 01What does it mean when an email shows as sent but was not received?
- 02What can cause an email to disappear after sending?
- 03Fix 1: Ask the recipient to check spam and quarantine
- 04Fix 2: Run a message trace to see what the receiving server did
- 05Fix 3: Check your sending domain authentication
- 06How to tell which cause you are dealing with
- 07How to prevent silent email delivery failures going forward
You sent the email. Your client confirms it in Sent. No delivery failure notification came back. The recipient says they never got it. This specific failure — email sent but not received by recipient, with no bounce explaining what happened — is one of the harder email problems to diagnose, because every signal on your end looks normal.
The silence is a clue, not a mystery. When a receiving mail server accepts a message and then filters, quarantines, or silently discards it, it sends no second notification to your server. Your server already received its delivery confirmation and considers the job done. The message disappears somewhere between server acceptance and the recipient's inbox, with nothing on your side to show for it.
This guide builds the evidence trail. It explains what the sent confirmation actually means, maps every common cause to a confirmation method and a fix, and walks through the three diagnostic steps in the order most likely to produce an answer quickly.
What does it mean when an email shows as sent but was not received?#
Your email client marks a message as sent the moment your outgoing mail server accepts it. That event is internal: your software handed the message to your server, and your server queued it for delivery. Nothing about that handoff tells you what happened at the other end.
When your server actually delivers the message to the recipient's mail server, the receiving server issues a reply code. A 250 OK tells your server the message was accepted. Your server records that as a successful delivery and removes the message from its retry queue. What the receiving server does next — route the message to the inbox, to a spam folder, to a quarantine holding area, to a compliance archive, or to a discard policy — is entirely its own decision, and it notifies your server of none of it.
A bounce, or non-delivery report, only fires when the receiving server refuses the message at the moment of delivery. Once the server accepts the message with a 250 OK, it takes ownership. Bounces are no longer in play. This is why an empty inbox on your end is not evidence that the message was delivered — it is evidence only that the message was accepted.
After acceptance, the email could be in any of five places: the inbox, a spam or junk folder, a quarantine held for administrator review, a compliance or legal hold archive, or permanently discarded by a silent drop policy. Each location has a different cause and a different fix. The goal of diagnosis is to determine which one applies.
What can cause an email to disappear after sending?#
The causes divide into two groups: things that happen on the recipient's server after the message is accepted, and authentication problems on your sending domain that trigger aggressive filtering. Both produce the same experience on the sender's side — silence — but the fixes point in opposite directions. The table below maps each cause to how you confirm it and what clears it.
| Cause | How to confirm | Fix |
|---|---|---|
| Routed to spam or junk folder | Recipient searches spam or junk by sender address and subject line | Mark as not spam; ask recipient IT to allowlist the sending domain |
| Held in corporate quarantine | Recipient's administrator runs a message trace; quarantine is separate from the junk folder | Administrator releases the message and adjusts the filter policy or adds an allowlist entry |
| Blocked by a content filter rule | Message trace shows the rule name and action taken | Remove triggering content such as excessive links or image-only formatting; request an allowlist |
| SPF record failure | Run an SPF lookup for your domain at MXToolbox | Add the missing sending service or IP address to your SPF record |
| DKIM signature missing or invalid | Run a DKIM lookup using your domain and selector at MXToolbox | Enable DKIM signing through your mail provider and publish the public key in DNS |
| DMARC policy rejection | DMARC record shows p=reject or p=quarantine; message trace confirms authentication failure | Fix SPF or DKIM so authentication passes; align the From domain with the signing domain |
| Sent to the wrong address | Verify the exact address; message trace at the intended recipient finds no record | Confirm the correct address by another channel and resend |
| Silent discard by an inbound security policy | Administrator message trace only; shows the message was dropped after the 250 OK | Recipient's administrator adjusts the inbound policy or adds an explicit allowlist entry |
Fix 1: Ask the recipient to check spam and quarantine#
Start here. The majority of missing emails in corporate environments are sitting in a spam folder, a junk folder, or a quarantine the recipient has not checked. The fix is fast when the message is there: find it, release it if it is in quarantine, and take the allowlist step to prevent a repeat. Walk the recipient through these checks before doing anything on your end.
- 1
Search spam and junk by sender address
Have the recipient search their spam or junk folder using your exact email address as the search term — not just browse the folder visually. Many corporate spam filters catch messages that look clean to a human eye, and the message may be buried in a folder the recipient rarely opens. Searching by sender address rather than scrolling is faster and more reliable.
- 2
Check quarantine separately in Microsoft 365
If the recipient is on Microsoft 365, quarantine is a separate location from the Junk Email folder — a message goes to one or the other, never both. The recipient or their administrator should go to protection.office.com, sign in, and look under Review in the left panel. Messages held in quarantine will appear there with the sender, subject, and reason the filter triggered.
- 3
Search All Mail in Google Workspace or Gmail
If the recipient uses Google Workspace or personal Gmail, have them search All Mail using the query 'from:[email protected]'. The Spam label sometimes receives messages without surfacing them prominently in the Spam folder view, and the All Mail search catches everything regardless of label.
- 4
Mark as not spam once found
Once the message is located, the recipient should mark it as Not Spam or Not Junk. This corrects the classification for that message and signals the filter. In a corporate environment, the IT team may need to release a quarantined message — the recipient can request release directly from the quarantine interface.
- 5
Request an allowlist for your sending domain
To prevent recurrence, ask the recipient to forward a request to their IT team or email administrator. An allowlist entry for your sending domain or IP address overrides most spam scoring on future messages. If the recipient is the administrator, they can add the allowlist entry directly in the Microsoft 365 anti-spam policy or Google Workspace admin console. This is the one step that prevents the same message from going missing again.
Fix 2: Run a message trace to see what the receiving server did#
If the recipient checks spam, junk, and quarantine and finds nothing, a message trace is the next step. A message trace is an administrator-level log search that shows the exact path a message took through the receiving mail server: whether it was delivered to the inbox, filtered to spam, held in quarantine, redirected, or discarded. It is the only tool that definitively answers where the message went after the receiving server accepted it.
Message traces require administrator access to the recipient's mail platform. If the recipient is a standard user without admin rights, they will need to ask their IT team to run it. A useful framing for the request: 'Can you run a message trace for a message from [your address] to [their address] sent at approximately [time] on [date]? I need to know the delivery status and whether any filter acted on it.'
- 1
Run a message trace in Microsoft 365
A Global Administrator or Exchange Administrator opens the Microsoft 365 admin center, navigates to Exchange admin center, then goes to Mail flow and selects Message trace. Enter the sender address, recipient address, and a date range that covers the send time. Run the trace and look at the Status column: it will show Delivered, Quarantined, Filtered, or Failed. Click through to the detail view to see the specific rule or filter that acted on the message and the reason code.
- 2
Run a message trace in Google Workspace
An administrator opens the Admin Console, navigates to Apps, then Google Workspace, then Gmail, and selects Email Log Search. Search by recipient address and the date range of the send. The log shows each delivery hop and the final disposition — delivered, spam, or rejected — along with the reason.
- 3
Read the action and reason in the trace result
The trace detail names the specific filter, rule, or policy that acted on the message. If a content filter is named, the message content itself triggered it. If a policy rule is named, the recipient's administrator can adjust the policy or add an exception for your domain. If the status shows Delivered but the recipient cannot find the message, look for a client-side rule in Outlook or Gmail that may have moved or deleted it on arrival.
- 4
Share the trace result with the recipient's IT team
The message trace result gives both sides a shared, factual account of what happened. If a policy is blocking all external mail from your domain, the IT team can add an exception. If a single message was caught by a content rule, the team can release it from quarantine and adjust the rule going forward. Without this trace, both sides are guessing from opposite ends of the delivery chain.
When the trace shows delivered but the recipient still has nothing
Fix 3: Check your sending domain authentication#
If the message trace shows the message was rejected or scored as spam specifically because of authentication failures, the problem is in your DNS records — SPF, DKIM, or DMARC. Many receiving servers apply heavy spam scoring to unauthenticated mail, and a DMARC rejection policy causes messages to be discarded without a bounce when authentication fails. This is entirely fixable from your side.
- 1
Check your SPF record
Go to MXToolbox (mxtoolbox.com) and run an SPF lookup for your domain. The result shows every authorized sending source in your record. If you send through Gmail with a custom domain, Outlook, a CRM, or any third-party tool, the service's IP range or include statement must appear in your SPF record. A sending source that is not listed arrives with an SPF fail, which many filters treat as a reason to route to spam or reject.
- 2
Check your DKIM record
In MXToolbox, run a DKIM lookup using your domain and the selector your mail provider assigned. Your provider's documentation will list the selector name. A missing or invalid DKIM record means your messages arrive unsigned. Many corporate mail systems treat unsigned messages from external senders as suspicious and route them to junk or quarantine — even when the content is clean.
- 3
Check your DMARC record
Run a DMARC lookup for your domain. If DMARC is set to p=reject or p=quarantine and either SPF or DKIM is failing, your messages are being discarded or held by policy — with no bounce to you, because DMARC dispositions occur after the initial 250 OK is issued. If you have no DMARC record at all, add one starting at p=none to begin monitoring without affecting delivery, then tighten the policy once authentication is consistently passing.
- 4
Verify the fix with header analysis
After correcting any authentication record, send a test message to a test account and examine the Authentication-Results header in the received message. It shows a pass or fail result for SPF, DKIM, and DMARC individually. All three should pass before you consider the fix complete. If any still fail, verify that the DNS change has propagated — SPF and DMARC changes are typically visible within an hour, DKIM can take longer depending on your DNS TTL.
How to tell which cause you are dealing with#
Follow the evidence in order and start with the cheapest check: ask the recipient. If they find the message in spam or quarantine, you have your cause and the fix is an allowlist request — no admin access required, no DNS changes needed. This resolves the majority of cases. If the recipient finds nothing in spam, junk, or quarantine, escalate to a message trace. Only an administrator can run it, but it definitively shows what the receiving server did with the message.
If the trace shows a content filter triggered, the content of the message is the problem. Revise it to remove the triggering pattern — excessive links, image-only formatting, certain attachment types — and resend. If the trace shows an authentication failure, the problem is in your DNS: check SPF, DKIM, and DMARC at MXToolbox and fix whatever is missing or broken.
If the trace shows the message was delivered to the inbox and the recipient still cannot find it, look for a client-side rule in the recipient's mail client. Outlook rules and Gmail filters can move, archive, or delete messages on arrival without any server-side trace. Ask the recipient to review their active rules for anything that matches your address. Once you know which cause you have, the fix in the table above applies directly.

How to prevent silent email delivery failures going forward#
Most silent delivery failures follow recognizable patterns, and most of them are preventable once the underlying mechanisms are clear. The following practices address the root causes directly.
- Keep SPF, DKIM, and DMARC records accurate and updated. Every new sending service you add — a CRM, a marketing tool, a transactional email provider — needs to be reflected in your SPF record. A record that was correct six months ago may now be incomplete if your sending infrastructure has changed.
- Avoid content patterns that raise filter scores. Messages that are image-only, contain many links, lack a plain-text alternative, or include certain attachment types score higher in spam filters. Write readable plain email as a default, especially for important one-to-one messages.
- Build sending reputation with new domains and IP addresses gradually. A domain you just started sending from has no reputation history and faces higher filter scrutiny. Start with low volume and build a clean track record before scaling up.
- Ask regular recipients to add your address to their contacts. A sender in a recipient's contact list is treated more favorably by most filters. This is the simplest allowlist you can request, and any recipient can do it without needing IT access.
- For important messages, confirm receipt through a second channel. A short message on Slack, a text, or a quick call takes ten seconds and removes all ambiguity. This is especially useful when the message is time-sensitive and waiting 24 hours to discover it never arrived is not an option.
The root frustration with a silent delivery failure is the absence of a record: on the sender side, there is nothing to look at after the message leaves the Sent folder. AI Emaily keeps a complete audit log of every message sent through the client, so when a recipient says they never received something, you can pull the exact send time, the account it went from, and whether any error was recorded at send — rather than reconstructing the story from timestamps alone. Because AI Emaily routes through your existing Gmail or Outlook account via OAuth, your SPF and DKIM signing flows through your provider's authenticated infrastructure, which is the strongest authentication posture available without managing your own mail server. We build AI Emaily; you can review the full feature set and start a 7-day free trial at AI Emaily pricing.
Frequently asked
See it in AI Emaily
Keep reading

Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.