Emails Not Being Delivered? Complete Diagnostic Guide

Short answer: Every undelivered email is in exactly one of four states - bounced, silently dropped, delayed, or junked. Identify the state first, because the fix for each is completely different, then work only that playbook.

• If a bounce arrived: read the code. A 4xx retries itself; a 5xx means stop and fix the stated cause.
• If no bounce arrived and it is in neither Inbox nor Junk: rule out the recipient side first - rules, forwarding, a full mailbox, or a quarantine nobody was told about.
• If it arrives, just late: suspect greylisting on a first message, a backlog on your side, or throttling because you sent too fast.
• If it landed in Junk, Spam or Quarantine: it was delivered. Fix authentication and reputation, and ask the recipient to mark it not junk.
• If all of your mail stopped at once: the sending account or domain is the problem, not any individual message.

Start by Naming the Failure

Most people troubleshooting email delivery start in the wrong place. They check SPF, run a blacklist lookup, rewrite the subject line, and two hours later still do not know whether the message was rejected, filtered, or sitting in a queue. The checks are not wrong. The order is.

There is only one useful first question: what actually happened to the message? Not why - what. An email that failed to reach a human being is always in exactly one of four states, and those states do not overlap. It bounced. It was silently dropped. It was delayed. Or it arrived and got filtered somewhere the recipient never looks.

Each state has a different diagnostic path and a different fix. A bounce hands you the reason in writing. A silent drop hands you nothing and is the hardest of the four. A delay often resolves itself and is not always a fault. A junked message was technically delivered, so nothing you change about your sending setup helps until you know why it was filtered.

This guide is a decision tree. Identify your state in the table below, go straight to that playbook, and use the shared diagnostics only when a playbook sends you there. The wider library of delivery and account-recovery walkthroughs is in our guides library.

Which of These Four Is Happening to You?

Answer three questions and you will land on exactly one row. Did a bounce or non-delivery report arrive in your inbox? Has the recipient actually looked in Junk, Spam and Deleted Items? Did the message eventually turn up, even hours later?

Outcome	Did you get a bounce?	Where the message is	What it usually means	Read
Bounced	Yes - an NDR or bounce arrived	Nowhere. It was rejected before acceptance	The receiving server refused it and told you why in a code	Outcome 1
Silently dropped	No	Not in Inbox, not in Junk, not in Deleted Items	Accepted then discarded, or removed by a rule or quarantine on the recipient side	Outcome 2
Delayed	Sometimes a delay warning, then nothing	Arrives eventually - minutes to hours late	Greylisting, a backlog on your side, or the receiver throttling your rate	Outcome 3
Junked or filtered	No	In Junk, Spam, Quarantine, or a secondary tab	It was delivered. It was scored badly enough not to be shown	Outcome 4

Two notes before you pick a row. A bounce can take hours to arrive, so do not conclude silent drop five minutes after sending - most systems retry a temporary failure for a day or more before reporting it. And if different recipients sit in different rows, treat them as separate investigations, because mixed symptoms almost always mean more than one cause.

Outcome 1: It Bounced

A bounce is the easiest of the four states because the system told you what it did. Your only job is to read it correctly.

The rule that decides everything

The first digit is the whole decision. 4xx is temporary - the receiving server is saying try again later, and any competent sending system retries on its own schedule. Take no action on a single 4xx. It needs attention only if the same address or domain keeps deferring past a day or two, at which point it has stopped being temporary in practice.

5xx is permanent - stop. Do not retry, resend by hand, or queue the same address into tomorrow's send. Hammering an address that returned a 5xx is one of the fastest ways to turn one bad address into a reputation problem. Suppress it, then fix the cause the code names.

Code, meaning, action

Code	What it means	What to do
421	Service unavailable or deferred, often rate related	Let it retry. If it repeats all send, slow your rate.
450	Mailbox temporarily unavailable	Let it retry. Investigate only if it persists past two days.
451	Local error at the receiver, or greylisting	Let it retry. New senders often see this once, then deliver.
452 4.2.2	Insufficient storage - the mailbox is full	Retry a few days, then suppress the address as inactive.
550 5.1.1	User unknown - the address does not exist	Remove it now. Never retry a 5.1.1.
550 5.7.1	Policy rejection - spam scoring, blocked sender, or failed authentication	Stop sending to that domain, read the bounce text, fix the named cause.
551 and 553	Not local, or the address format was refused	Correct the address. Do not resend the same string.
552	Message too large for the recipient limit	Link the attachment instead and resend.
554	Transaction failed - a catch-all rejection	Read the plain-text part; it usually names the real reason.

The extended code tells you which department refused you

Modern bounces carry a three-part extended code such as 5.7.1. The first digit repeats temporary versus permanent. The middle digit is the useful one: it names the subsystem that objected, which tells you who can fix it.

Class	Subsystem	What it points at
x.1.x	Address	Does not exist, is malformed, or was retired
x.2.x	Mailbox	Full, disabled, or not accepting mail right now
x.3.x	Mail system	The receiver is out of capacity or misconfigured
x.4.x	Network and routing	DNS, MX or connection problems between the servers
x.5.x	Protocol	The two servers disagreed about the SMTP conversation
x.6.x	Content or media	The format could not be converted or was refused
x.7.x	Security and policy	Authentication, reputation, spam scoring, or a block

Practically: x.1.x and x.2.x are list problems, and verifying addresses before you send prevents almost all of them. x.7.x is a you problem - the receiver decided not to trust your mail, which is an authentication, reputation or content question, so go to the shared diagnostics. If the bounce names a public blocklist or links to a removal page, work through how to get off an email blacklist before you send anything else.

Outcome 2: It Was Silently Dropped

No bounce. Not in the Inbox. Not in Junk. This is the state people cannot get answers about, because there is no error message anywhere to search for. Work it in three passes, in this order, and do not skip to pass three.

Pass 1: confirm it really was accepted

Silent drop means accepted then discarded, so prove the acceptance first. Your sending log should show the message handed off successfully with no bounce recorded against it in the following 48 hours. A deferral that is still retrying puts you in Outcome 3. A bounce routed to a mailbox nobody reads - a common trap when the return address differs from the visible From address - puts you in Outcome 1. Check that mailbox before going further.

Pass 2: rule out the recipient side

This is where most silent drops actually live, and it is the pass people skip because it feels like blaming the recipient. It is not - it is the cheapest pass and it resolves a large share of cases:

• An inbox rule that moves or deletes mail matching a sender, domain or keyword. Rules built years ago and forgotten are very common.
• Forwarding to another address, where the second hop rejects or filters it. Forwarding also breaks some authentication checks, so the second hop can discard mail that passed the first.
• A full mailbox, which sometimes bounces and sometimes just quietly stops accepting.
• A blocked-senders list the recipient added you to, or inherited from a colleague's report.
• An organization quarantine that held the message and notified nobody. This is the most common invisible cause at business domains, because many administrators disable end-user quarantine notifications.

What to ask the recipient, in words they can use

Do not ask a non-technical person to check their filters. Ask this instead, and ask for all four:

1. Search your whole mailbox for my email address, not just the Inbox - most mail apps have a search that covers every folder including Junk and Deleted Items.
2. Look in Junk or Spam, and in Deleted Items, for anything from my domain in the last week.
3. Check whether you have a rule that files or deletes mail from outside your company, or whether your mail is forwarded anywhere.
4. If nothing turns up, ask your IT or email administrator to check the quarantine for my address - they can see held messages that were never shown to you.

That last one resolves a surprising number of cases in a single message. If the recipient is on Microsoft 365 or Outlook, the Microsoft-specific version of this behavior - including rejections and silent holds that never surface to the user - is covered in depth in Outlook blocking your emails.

Pass 3: rule out your side

If the recipient side is clean, the message was almost certainly accepted and then discarded by the receiving filter. Providers do this deliberately for mail they are confident is unwanted, because a bounce would confirm to a spammer that the address is real. The diagnosis is then reputation, authentication or content, in that order of likelihood - work all three in the shared diagnostics section, or start with a blocklist check if your domain or sending IP is listed.

Outcome 3: It Arrived Late

Late delivery is often not a fault. It is the mail system doing exactly what it was designed to do. The useful work is telling the three causes apart, because two of them need no action and one of them needs you to slow down.

Cause	Tell-tale sign	Action
Greylisting	Only the first message from a new sender is late. The retry gets through and everything after is normal.	None. It is working as intended.
Queue backlog on your side	Everything you send is late, to every recipient domain, regardless of who they are.	Look at your own sending system, not the receiver.
Throttling by the receiver	Delay tracks your sending rate. Small sends are fine, bursts are slow, and you see repeated 421 or 4.7.x deferrals.	Reduce your rate. Do not retry harder.

Greylisting

A greylisting server deliberately defers the first delivery attempt from a sender it has never seen, then accepts the retry minutes later. It works because legitimate mail servers always retry and old-style bulk senders often did not. The symptom is a first email that arrives ten minutes or an hour late, followed by normal delivery forever after. Nothing is broken. The one thing that turns greylisting into a real problem is a sending setup that does not retry properly, so if first messages to new domains never arrive at all, confirm retries are actually happening.

Throttling, and why retrying harder makes it worse

When you send faster than a provider will accept from your sending source, it defers you. That is a rate signal, not a rejection. The correct response is to send less per hour across a longer window. The incorrect response - shortening your retry interval or pushing the same volume from a second source - reads as exactly the behavior the throttle exists to suppress, and tends to escalate into policy rejections. Consistent, paced volume is what earns a higher acceptance rate over time.

Outcome 4: It Landed in Junk or Quarantine

This is a delivery success and a deliverability failure. The receiving server accepted your message, which means authentication and connection were good enough to get in the door. It then scored the message and decided not to show it. Nothing about your sending infrastructure will change that outcome until the scoring changes.

Junk, Quarantine and Promotions are three different things

• Junk or Spam folder - a per-mailbox decision. The recipient can see it and move it back themselves, and that action is a genuine positive signal to the provider.
• Quarantine - an organization-level hold. The message is not in the recipient's mailbox at all and only an administrator can release it, often with no notification. From outside it looks identical to a silent drop, which is why the ask-the-administrator step in Outcome 2 matters.
• Gmail Promotions tab - not filtering at all. The message reached the inbox, just a secondary tab. Bulk-styled formatting, heavy imagery and marketing-shaped links push mail there; plain, personal-looking mail generally does not go there.

Confirming placement without asking every recipient

You do not need to survey your list. Three methods, in increasing effort:

1. Seed accounts you control at each major provider. Send to them alongside a real send and check every folder. Fastest signal, and it costs nothing.
2. Google Postmaster Tools for Gmail, which shows domain and IP reputation, authentication pass rates and spam complaint data - free, first-party, and the closest thing to Gmail telling you what it thinks of you.
3. Microsoft SNDS for Microsoft's consumer domains, which reports filter results and complaint data for traffic from your sending IP.

Reply rate is a good proxy too. If a segment's replies collapse while your volume and copy stayed the same, placement moved.

What actually moves mail back to the inbox

Four things, and only four. Authentication that passes and aligns, so the provider knows the mail is really from your domain. Reputation built by consistent volume and low complaint and bounce rates. Genuine engagement, especially replies, which is the strongest positive signal you can generate. And the recipient's own action: marking the message not junk, adding you to contacts, or replying. When someone tells you they never got your last message, ask them to do exactly that - a single positive action from a real recipient carries more weight with the filter than any change you make in DNS.

When the Account Is the Problem, Not the Message

There is one branch that overrides all four playbooks, and checking it takes thirty seconds. Did all of your mail stop at once?

If every message to every recipient failed within the same short window - not one campaign, not one domain, but everything including personal one-to-one email - stop diagnosing individual messages. Nothing in the four playbooks will help, because the problem is not any message. It is the sending account or the domain itself.

The usual causes:

• The sending account is limited or suspended. Providers restrict accounts that trip volume or abuse thresholds, and the restriction is usually abrupt and total. If your Gmail account is the one that stopped, work through Gmail account suspended recovery.
• The whole organization stopped. If colleagues on the same domain lost sending at the same moment, the account-level view is the wrong scope - the domain or workspace is affected. Start with Google Workspace account suspended.
• Credentials or app passwords changed. A revoked app password or a re-authenticated account breaks sending from a connected tool while the mailbox still works fine in the browser. People rule this out last and should rule it out first, because it is free to check.
• Billing or licensing lapsed on the mail provider, which suspends sending with no deliverability signal at all.

The diagnostic is simple: send one email from the provider's own web interface to an address you control. If that works, your mailbox is fine and the problem is in whatever connects to it. If it fails too, the account itself is restricted and no amount of authentication tuning will change anything.

Shared Diagnostics All Four Playbooks Point To

These three checks are referenced by the playbooks above. Run only the ones your playbook sent you to.

Authentication

Authentication is a pass or fail gate, and a failure here explains policy rejections and silent drops far more often than anything else.

• SPF - publish exactly one record, include every service that sends as your domain, and stay within the DNS lookup limit. Two SPF records on one domain is a failure, not a merge.
• DKIM - send a message to an account you control, open the full headers, and confirm the results header shows DKIM passing. If it fails, the published key at the selector your mail names is usually missing or wrong.
• DMARC - a published policy plus alignment between the visible From domain and the domain that passed SPF or DKIM. Alignment is the part people miss: both mechanisms can pass and DMARC can still fail if neither aligns with the From domain.

This stopped being optional. Google and Yahoo introduced bulk-sender requirements in February 2024 covering SPF, DKIM, DMARC, one-click unsubscribe on bulk mail, and keeping spam complaint rates low. Microsoft introduced comparable requirements for high-volume senders to its consumer domains, with enforcement beginning in May 2025. Check the current thresholds in each provider's own sender documentation rather than relying on a number from a blog post.

Reputation and blocklists

Reputation is a score, not a gate, and it decides Inbox versus Junk once authentication passes. Check your sending IP and your domain against the major public lists; if you find a listing, both the removal process and the underlying cause are covered in how to get off an email blacklist, and removal without fixing the cause simply relists you. Use Google Postmaster Tools and Microsoft SNDS alongside the public lists, because both providers hold internal reputation data no public lookup can see. Being clean everywhere public and still blocked is completely normal.

The two numbers every provider watches are hard bounces and spam complaints. Keep both low. Hard bounces are a list-quality signal, so verify addresses before you send rather than discovering invalid ones through rejections.

Content and links

Content matters least of the three but can still sink a healthy sender. The reliable offenders: link shorteners, links to domains with poor reputations of their own, heavy image-to-text ratios, HTML with no plain-text alternative, and subject lines shaped like advertising. For cold outreach, fewer links is better than more, and mail that reads like a person wrote it outperforms mail that reads like a template - that is exactly what the filter is scoring.

Provider Differences That Change the Answer

The same message can land in four different places at four providers. Where the playbooks diverge:

Gmail

Gmail rarely rejects outright and rarely drops silently. It sorts. Most Gmail problems are Outcome 4 - Junk or the Promotions tab - and the lever is engagement plus aligned authentication. Google Postmaster Tools is the only place you can see Gmail's own view of your domain, so set it up before you need it.

Microsoft

Microsoft is the opposite. It rejects explicitly and often, with policy codes in the 5.7.x family including IP-block variants such as 550 5.7.606, and it quarantines aggressively at business tenants - which is why Microsoft produces most of the genuine Outcome 2 cases. It also weighs unknown senders more harshly than Gmail does. The full Microsoft playbook, including delisting and quarantine, is in Outlook blocking your emails.

Yahoo and AOL

Expect Outcome 3 more often here - deferrals and slow acceptance when volume rises - plus strict DKIM handling. The complaint feedback loop gives you data you cannot otherwise see.

Business domains behind a security gateway

Corporate recipients often sit behind a filtering gateway with its own rules, quarantine and reputation view. A gateway that accepts and holds reads exactly like a silent drop from your side. When one contact at a company gets your mail and a colleague does not, per-user rules or per-user quarantine settings are the usual explanation.

Find Out Before Your Recipients Do

By the time someone tells you they did not get your email, the problem has usually been building for days. Monitoring turns that into an early warning. Watch four things:

• Bounce rate per send. A jump is the earliest signal of both a list-quality problem and a reputation problem. Investigate a rise the day it happens, not at month end.
• Reply rate against your own baseline. A sharp drop with unchanged copy and volume means placement moved. This is the most sensitive spam-folder detector you have.
• Provider dashboards. Google Postmaster Tools and Microsoft SNDS show trends before they become rejections. Check them weekly, not in a crisis.
• Blocklist status. A weekly automated check on your sending IP and domain is enough, and listings are far cheaper to resolve on day one.

The practical schedule: bounce rates daily, provider dashboards and blocklist status weekly, list hygiene and an authentication re-check monthly. That catches every failure mode in this guide while it is still small.

Prevent the Next One with WarmySender

Most delivery failures are not mysteries. They are the delayed bill for sending too much, too soon, from a mailbox no provider had a reason to trust yet. WarmySender is built around that problem: peer-to-peer email warmup that ramps a new mailbox gradually instead of pointing it at a cold list on day one, cold email campaigns with per-mailbox daily sending caps and paced sending rather than bursts, inbox rotation so no single mailbox carries the whole volume, mailbox health monitoring that flags a box before its recipients notice anything, and list verification before you send so bad addresses never generate the hard bounces that start the damage. LinkedIn outreach runs alongside it, and you can combine both channels in one multichannel sequence when email alone is not landing.

The honest limit: warmup, pacing and verification reduce the chance of ending up back in this guide. They do not reverse a block, a blocklist listing or a suspension that has already happened - those still need the recovery steps above. See how WarmySender works.