Why am I not receiving emails? Sent but not received guide

If you are asking why am i not receiving emails, or a sender says an email was sent but not received, 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.
"Sent" does not mean "received." It may only mean the app handed the message to a provider.
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, Gmail tabs, Outlook focused/other placement, forwarding rules, and alias behavior next.
If the message was rejected, inspect SPF, DKIM, DMARC, Return-Path, and any SMTP 550 evidence before retrying.
For release-critical workflows like verification codes, password resets, invitations, invoices, and alerts, 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:

Was the message actually sent, or did the sender see a bounce or rejection?
Was it delivered to spam, junk, promotions, updates, or another filtered location?
Do mailbox rules, forwarding, aliases, or shared-mailbox routing move it away from the expected inbox?
Did the sender break SPF, DKIM, DMARC, or Return-Path alignment?
Is sender reputation weak enough that mailbox providers are filtering or throttling delivery?
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 message undeliverable notice, use Message undeliverable to separate recipient, policy, routing, and size failures before you retry anything.

Sent, delivered, received, and visible are different

Missing-email debugging gets easier when the team uses precise words:

Sent means the application or email service attempted to hand off the message.
Accepted means an SMTP server or provider accepted responsibility for the message.
Delivered means the receiver accepted the message for the mailbox or domain.
Received means the message reached a place the mailbox can search.
Visible means the user can actually find it in the expected inbox view.

A customer saying "I did not receive the email" can mean any of those stages failed. A provider saying "sent" usually proves only the first stage. Look for the message ID, provider event, SMTP response, bounce, raw headers, and mailbox placement before declaring the incident fixed.

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 550 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 provider-specific inbox behavior

Different mailbox providers hide messages in different places. Do this before rewriting templates or changing DNS.

For Gmail and Google Workspace, check:

Spam
Promotions and Updates tabs
filters that archive, label, forward, or delete
blocked senders
search by sender domain, subject, and approximate timestamp
raw headers for SPF, DKIM, DMARC, and Authentication-Results

For Outlook, Microsoft 365, and Hotmail, check:

Junk Email
Focused and Other inbox placement
quarantine or organization-level policy
transport rules
safe senders and blocked senders
message trace evidence if you administer the tenant

For iCloud, Apple Mail, Yahoo, and other consumer inboxes, check junk placement, aliases, forwarding rules, account storage, and whether the same message arrives in a controlled test inbox. If only one provider filters the mail, compare headers and placement with the Email header analyzer and Inbox placement test.

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 550 permanent failure 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 From domain
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.

Troubleshooting matrix

Symptom	Likely cause	MailSlurp check
The app says it sent the email, but no provider event exists	queue, job, credential, or API submission failure	Send the same template to a controlled Email Sandbox inbox and assert receipt
The provider returns a bounce or `550` response	invalid address, policy block, relay rule, or authentication failure	Inspect the bounce and follow Fixing SMTP 550 errors
Gmail receives the message in Promotions or Spam	content, sender history, authentication, or reputation issue	Run an Inbox placement test and review headers
Outlook users report no email, but other providers receive it	Microsoft filtering, tenant quarantine, or sender reputation issue	Compare placement and header results across test recipients
Only password reset, invite, or OTP emails fail	template, link, sender, or environment-specific routing problem	Use Email integration testing to send the exact production-style message and wait for it
A custom domain inbox never receives mail	MX, domain routing, or conflicting DNS records	Check MX records with MX record checker and review the MailSlurp inbox support guide

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:

capture sender-side evidence
capture raw headers for a known sample
verify SPF, DKIM, DMARC, and Return-Path
inspect spam placement and mailbox rules
run a controlled test inbox workflow
document root cause and preventive control

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

Validate product emails before users depend on them

Missing transactional email hurts more than a newsletter placement problem because the user is blocked in the product.

Test these flows with controlled inboxes:

signup verification
login codes and MFA
password resets
organization invitations
invoice and receipt delivery
security alerts
comment, ticket, and workflow notifications

With MailSlurp, create a fresh test inbox for the flow, trigger the real application action, wait for the expected email, then assert the sender, subject, links, OTP code, headers, and attachments. That gives engineering, QA, and support teams a reproducible signal before the same issue reaches customers.

Use Email integration testing for automated checks, Email Sandbox for controlled staging sends, and Email deliverability test when you need placement and authentication evidence.

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.

What does email sent but not received mean?

It means the sender has evidence that the message was submitted, but there is not yet evidence that the recipient can see it. Check provider events, bounces, spam placement, mailbox rules, headers, and authentication before changing the template.

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.

Why is Outlook not receiving emails from my app?

Outlook and Microsoft 365 may place messages in Junk, Focused/Other, quarantine, or tenant-level policy holds. Compare a controlled test send across providers, then inspect headers and sender-authentication results.

Why is Gmail not receiving password reset emails?

Gmail may filter messages to Spam, Promotions, Updates, or a rule-managed location. For product emails, test the exact reset flow with a controlled inbox and review SPF, DKIM, DMARC, links, and sender consistency.

Final take

Why am I not receiving emails 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.