Introduction
A “delivered but not received” complaint is confusing because “delivered” sounds final. In practice, delivered usually means the recipient mail system accepted the message. After that, the email can still be moved to Spam or Junk, quarantined by security tools, routed to another mailbox, or hidden by rules and filters.
This guide is for SaaS and development teams sending transactional email such as OTPs, password resets, receipts, and alerts. It explains a repeatable way to debug delivered but not received reports by collecting the right evidence first, confirming the exact message, reviewing logs and headers, validating SPF, DKIM, and DMARC, and then isolating whether the issue is mailbox-side filtering, a corporate gateway, or sender-side reputation or content.
The goal is not guesswork. It is a short and consistent process that helps you reach the likely root cause faster. Start by using MailCub Documentation to find the exact message in logs and capture the message ID and timestamps.
Quick Answer
- “Delivered” usually means accepted by recipient infrastructure, not necessarily visible in the inbox.
- Collect a small debug packet first: recipient, timestamp, subject or template, correlation ID, and provider log or message reference.
- Ask the recipient to check Spam, Junk, Quarantine, tabs, rules, and forwarding before changing anything.
- Pull full headers and review Authentication-Results for SPF, DKIM, DMARC, and alignment.
- If it repeats across users, segment by domain and template to identify reputation or content patterns.
- If it is a corporate domain, assume a security gateway may be the real delivery point.
Why It Matters
These complaints affect high-value transactional flows. When OTPs or password resets are not found, users retry actions, create duplicate requests, and open urgent support tickets. This increases load on both your app and your email pipeline.
It also affects future inbox placement. If users repeatedly mark your messages as spam, or gateways keep quarantining them, more of your mail can get filtered over time. The faster you separate mailbox visibility issues from true sending failures, the less long-term damage you take.
What “Delivered” Actually Means
In most systems, “delivered” means the message was accepted by a receiving server or gateway. That gateway can still quarantine the message, rewrite links, or apply filtering rules before the user ever sees it.
Your investigation should focus on what happened after acceptance, including:
- Spam placement
- Quarantine
- Rules or forwarding
- Authentication and reputation signals
- Corporate security tooling
Step-by-Step Debug Process
1) Capture the debug packet first
Before troubleshooting, collect a small debug packet so you do not investigate the wrong send attempt:
- Exact recipient email address
- Send time (with timezone)
- Subject line or template name
- Correlation ID (user ID, order ID, reset token ID)
- Provider log or message reference
2) Confirm you are investigating the same message
Mismatches are common. Double-check:
- The exact recipient address (including aliases, plus addressing, and forwarding)
- The send time window (user’s local time vs your server time)
- The template or subject matches what the user triggered
- You are not looking at a different retry or the wrong environment (staging vs production)
3) Use delivery logs to confirm status and timeline
In logs, capture the status and timeline clearly. Record:
- Status (accepted, delivered, deferred)
- Timestamps (queued, accepted, delivered)
- Any response details
- Whether multiple attempts exist
If webhook events are enabled, compare webhook timestamps with log timestamps to build one consistent timeline. You can use MailCub Documentation to standardize how your team captures this timeline.
4) Ask the recipient to check the right places (in order)
Send the recipient a short checklist so they check mailbox-side causes before anyone changes templates or DNS:
- Search All Mail for your sending domain and subject keywords
- Check Spam or Junk
- Check tabs (Gmail Promotions/Social) or Focused/Other (Outlook)
- Check Quarantine (very common in Microsoft 365 and corporate domains)
- Check rules and filters (auto-archive, move to folder, delete, forward)
- Confirm the mailbox is not over quota
If they find the message in Spam or Quarantine, ask for a redacted screenshot to confirm what happened.
5) Pull headers and verify SPF, DKIM, and DMARC alignment
If the email is found anywhere, pull full headers and review:
- Authentication-Results: SPF, DKIM, and DMARC pass or fail
- Alignment: From domain matches DKIM signing domain and/or SPF domain
- Received chain: Where it was accepted and whether a gateway is present
A common pattern is that SPF breaks on forwarding, but DKIM should still pass if signing is configured correctly.
6) Decide if it is a corporate gateway policy issue
If the recipient domain is corporate and multiple users report the same problem, assume a gateway may be controlling delivery visibility. Common issues include:
- Quarantine portal actions
- Allowlist or blocked-list policies
- Aggressive link scanning or content rules
In these cases, recipient IT often needs to release the message and allowlist your sending domain or IP.
7) If it is happening broadly, check reputation and template patterns
When complaints come from many domains, look for sender-side patterns:
- Sudden volume spikes
- Specific templates triggering filtering
- Suspicious link domains or mismatched branding
- High complaint rate or repeated sends to stale addresses
- Suppression list handling (whether bad addresses are still being retried)
Use MailCub Documentation to build a support checklist that includes a debug packet and timeline, and review event visibility on the Transactional Email page if you are improving your troubleshooting workflow.
Evidence Map for Delivered but Not Received
| What you see | Likely meaning | Next best check |
|---|---|---|
| Delivered in logs, found in Spam | Inbox placement or filtering issue | Headers, content patterns, and authentication alignment |
| Delivered in logs, not found anywhere | Rules, forwarding, quarantine, or wrong mailbox | Quarantine, mailbox rules, and exact recipient address |
| Corporate domain, many users affected | Gateway policy or allowlisting issue | Recipient IT, gateway logs, and allowlist review |
| Delivered but arrives hours later | Deferrals, greylisting, or sync delay | Timestamps, retries, and mailbox sync behavior |
| Only one mailbox provider affected | Provider-specific filtering | Segment by domain and compare templates/links |
Common Mistakes
- Treating “delivered” as “in inbox” and skipping Spam or Quarantine checks
- Debugging without a log or message reference, which leads to the wrong send attempt
- Changing templates during an active incident and adding new variables
- Ignoring headers, so SPF, DKIM, and DMARC results are never confirmed
- Not segmenting by domain and template, which hides useful patterns
Troubleshooting
If the user says “it’s nowhere”
Follow this order:
- Verify the exact address and time window
- Confirm logs show accepted or delivered for that address
- Ask for a Quarantine check (especially for corporate domains)
- Ask for rules and forwarding checks
- If corporate, involve recipient IT to check gateway logs
If the email is in spam
Focus on:
- Authentication alignment (DMARC and DKIM alignment)
- Link domains and content patterns
- Volume spikes and complaint rate
If only one provider is affected (for example, Outlook)
Compare:
- The same template on Gmail vs Outlook
- Link domains and From domain consistency
- Timing patterns and retries
FAQ
What does “delivered but not received” actually mean?
It usually means the recipient mail server or a security gateway accepted the message. The email may still be filtered to Spam or Junk, quarantined, forwarded, or hidden by mailbox rules.
How can an email be delivered but not show in the inbox?
After acceptance, the message can be moved to Spam or Junk, quarantined by security tools, routed to another mailbox through forwarding, or hidden by rules and inbox tabs.
What evidence should I collect from logs to debug faster?
Collect the exact recipient address, send time with timezone, subject or template, correlation ID, and a provider log or message reference so you can trace one specific send attempt.
Which headers matter for SPF, DKIM, and DMARC checks?
Check Authentication-Results for SPF, DKIM, and DMARC pass or fail and alignment, plus the Received chain to see where the message was accepted and whether a gateway handled it.
Why do corporate domains quarantine emails that look fine on Gmail?
Corporate gateways often apply stricter policies such as link scanning, content rules, and allowlists. A message can be accepted by the gateway but quarantined before it reaches the user’s inbox.
What should I do if this repeats across many recipients?
Segment complaints by domain and template, review authentication alignment and link domains, check volume spikes and complaint rate, and improve list hygiene and suppression handling to reduce filtering.
Conclusion
Most delivered but not received complaints are mailbox visibility issues, not true sending failures. The fastest approach is evidence-first: identify the exact message, confirm the timeline, check Spam, Quarantine, rules, and forwarding, then verify authentication using headers.
Once your team follows this process consistently, you can resolve complaints faster and spot patterns before they spread. Use MailCub Documentation to standardize your support checklist, review tracking and webhook capabilities on the Transactional Email page, and check MailCub Pricing if you are planning broader monitoring or support workflow improvements.