If you are asking , the first thing to determine is whether the message was never sent, was rejected before delivery, was delayed in transit, or was delivered somewhere you are not checking.

Those are different failures. Treating them as the same problem is why missing-email incidents drag on for hours.

Executive summary

  • Missing mail is usually caused by one of four buckets: filtering, mailbox rules, sender-side rejection, or sender-auth and reputation problems.
  • Start with evidence, not guesswork. Check whether the sender has a bounce or rejection log before changing mailbox settings.
  • If the message was accepted but not visible, check spam placement, category tabs, forwarding rules, and alias behavior next.
  • If the message was rejected, inspect SPF, DKIM, DMARC, , and any SMTP 550 evidence before retrying.
  • For release-critical workflows, run controlled inbox tests instead of waiting for a customer to report the failure.

Quick answer

If you are not receiving emails, check these in order:

  1. Was the message actually sent, or did the sender see a bounce or rejection?
  2. Was it delivered to spam, junk, promotions, updates, or another filtered location?
  3. Do mailbox rules, forwarding, aliases, or shared-mailbox routing move it away from the expected inbox?
  4. Did the sender break SPF, DKIM, DMARC, or alignment?
  5. Is sender reputation weak enough that mailbox providers are filtering or throttling delivery?
  6. Can you reproduce the failure with a controlled deliverability test instead of ad hoc manual checks?

If you are already confident the message is being filtered, go straight to Why emails go to spam and the Spam folder guide. If the sender has SMTP rejection logs, start with Fixing SMTP 550 errors.

If the only evidence you have so far is a generic notice, use Message undeliverable to separate recipient, policy, routing, and size failures before you retry anything.

First identify which stage failed

The phrase "not receiving emails" hides several very different incidents.

1. The message was never sent

This is common in application flows where:

  • the app never queued the message
  • the job failed before submission
  • the provider rejected credentials or policy
  • the sender suppressed the recipient after a prior bounce

If you operate the sender, confirm there is a message ID, submission timestamp, and provider response before looking at recipient-side settings.

2. The message was rejected

A message can fail before delivery because of:

  • invalid recipient addresses
  • relay policy errors
  • mailbox policy blocks
  • sender-auth failures
  • reputation problems

This usually leaves evidence in SMTP transcripts, bounce events, or provider logs. Permanent errors like should be diagnosed, not blindly retried.

3. The message was delayed

Sometimes mail is not missing. It is just late.

Typical causes:

  • retry and backoff behavior after temporary failures
  • provider throttling
  • queue congestion
  • DNS propagation after auth changes

If email arrives much later than expected, treat this as a reliability problem, not a mailbox-search problem.

4. The message was delivered, but not where you expected

This includes:

  • spam or junk placement
  • category-tab placement
  • server-side rules or forwarding
  • shared-mailbox routing
  • archived or threaded placement that hides the message

This is the most common outcome when the sender says "accepted" but the user still says "I never got it."

Check recipient-side visibility first

Before you assume the sender is broken, confirm the message is not simply out of view.

Check for:

  • spam or junk placement
  • categories such as promotions or updates
  • search mismatches caused by aliases or plus-addressing
  • rules that auto-label, forward, archive, or delete messages
  • shared-mailbox ownership patterns where another teammate already moved it

For engineering and operations teams, the important question is not just "can a user find the message?" It is "what mailbox rule or provider behavior moved it?"

If the issue looks like filtering, use:

Check sender-side rejection evidence

If the sender controls the application or platform, inspect send logs before touching mailbox rules.

Look for:

  • SMTP status codes
  • bounce classifications
  • suppression events
  • provider delivery events
  • webhook evidence showing reject, defer, or accepted state

Questions to answer:

  • Did the provider accept the message?
  • If not, which stage failed?
  • Was the recipient address valid?
  • Was the sender blocked by policy?
  • Was the mail suppressed because of a prior incident?

If you see or similar response codes, use Fixing SMTP 550 errors as the incident runbook.

Check sender identity and authentication

Even when a message leaves the sender, receivers may still distrust it.

The first technical checks are:

Pay special attention to:

  • whether SPF authorizes the sending infrastructure
  • whether DKIM signatures validate after transit
  • whether DMARC alignment matches the visible strategy
  • whether the Return-Path points to the right sender identity
  • whether the sending IP has coherent reverse DNS using Reverse DNS lookup

Authentication problems often appear after:

  • provider migrations
  • subdomain changes
  • DKIM key rotation
  • DNS propagation windows
  • complex SPF include chains

If SPF has grown messy across multiple vendors, review SPF flattening before you make more record changes under pressure.

Check reputation and spam placement risk

Sometimes email is technically accepted but still filtered away from the inbox.

Common causes:

  • weak domain or IP reputation
  • complaint spikes
  • bounce spikes
  • broken or suspicious links
  • abrupt volume changes
  • inconsistent sender identity across environments

Use:

This is where the difference between "delivered" and "visible to the user" matters. A provider can accept a message while still placing it in spam or delaying its availability.

Build a repeatable missing-email workflow

The best fix is to stop treating missing mail as a one-off support ticket.

Use a standard sequence:

  1. capture sender-side evidence
  2. capture raw headers for a known sample
  3. verify SPF, DKIM, DMARC, and
  4. inspect spam placement and mailbox rules
  5. run a controlled test inbox workflow
  6. document root cause and preventive control

This turns "weird email issue" into a diagnosable operational workflow.

Use controlled testing before customers report the problem

For signup, reset, billing, alerting, and notification flows, do not wait for production complaints to confirm receipt.

Run controlled tests with:

  • isolated inboxes
  • known recipient expectations
  • explicit wait conditions
  • header and auth inspection
  • spam and inbox-placement checks

MailSlurp matters here because teams can create deterministic inboxes, wait for the exact message they expect, and inspect links, headers, and delivery behavior without relying on personal mailboxes. Start with Email deliverability test or Email Sandbox if you need a release-gate workflow instead of ad hoc mailbox troubleshooting.

If you use MailSlurp-managed inboxes

If the missing message is supposed to arrive in a MailSlurp inbox, also review the product-specific support page: Inbox not receiving emails.

That page covers MailSlurp-specific causes such as:

  • choosing the wrong inbox type for the client or workflow
  • sender-side domain or SMTP issues
  • product-specific support escalation paths

FAQ

Why am I not receiving emails even though the sender says they were sent?

Because "sent" only confirms submission. The message may still be rejected, delayed, filtered, or routed somewhere else.

Why are some emails arriving and others are missing?

That usually points to template-level risk, routing differences, provider-specific filtering, or mailbox rules affecting only certain senders or message classes.

Can SPF, DKIM, or DMARC problems cause missing emails?

Yes. They can cause outright rejection, spam placement, or intermittent filtering depending on receiver policy.

What should I check first for a password-reset or verification email that never arrives?

Check spam placement and sender-side rejection evidence first. Those two steps eliminate a large share of incidents quickly.

Final take

is not one problem. It is a decision tree across sending, routing, filtering, and mailbox visibility. The fastest teams isolate the failure stage first, validate sender identity second, and then re-test with controlled inbox workflows before closing the incident.