Why you're not receiving emails: causes and how to identify them

When mail stops arriving, the cause is almost always one of a small number of things. The difficulty is that they produce nearly identical symptoms from the recipient's chair: someone insists they sent a message, and it is not there.

This is a reference organised by cause rather than a procedure. It explains why each failure happens and how to recognise it. If you want an ordered set of steps to work through instead, see email delivery troubleshooting.

First: is it one sender, or everyone?

This single question splits the problem in half, and answering it first saves most of the work.

Only one sender fails. The cause is almost certainly on their side — authentication, reputation, or a blocklist entry — or in a rule on your side that targets them specifically.
Several unrelated senders fail. The cause is on your side: routing, mailbox state, or filtering policy.
Everything fails. Something structural is wrong — MX records, domain status, or the mailbox itself.

Causes on the receiving side

The message was filtered, not lost

By a wide margin the most common explanation. The receiving server accepted the message and then filed it somewhere other than the inbox: Spam, Junk, Promotions, Other, or an organisational quarantine that the user never sees.

Business accounts complicate this. Microsoft 365 and Google Workspace both hold suspect mail in an administrative quarantine that is invisible from the mailbox — only an administrator can release it.

How to recognise it: delivery reports success and the message is findable by searching all folders, including Trash.

An inbox rule moved or deleted it

Rules run after delivery and can move, archive, forward, or delete messages silently. Rules created years ago for a purpose long forgotten are a recurring culprit, as are rules matching broad terms like "test," "invoice," or "no-reply."

How to recognise it: the message is in an unexpected folder, or absent entirely while delivery reports success.

The mailbox is full

Over quota, a server rejects new messages with a storage error. The sender may or may not receive a bounce depending on the provider.

Storage caps catch people out on older hosting plans and on shared Google accounts where Drive and Gmail draw from the same allocation.

How to recognise it: a 552 or 452 storage code, or a bounce mentioning quota.

Forwarding is broken or looping

If the address forwards elsewhere, several things can go wrong: the destination no longer exists, the destination rejects forwarded mail, "delete after forwarding" is removing the local copy, or two addresses forward to each other and the loop is detected and dropped.

Forwarding also frequently breaks SPF validation, causing the destination provider to treat forwarded mail as suspicious.

How to recognise it: mail sent directly to the destination arrives, mail to the forwarding address does not.

The address does not exist as you believe it does

Aliases get deleted during migrations. Distribution lists get emptied. Employees leave and their mailbox is converted to something that no longer accepts mail. A domain gets added to a new provider without every address being recreated.

How to recognise it: a permanent 550 "user unknown" rejection.

Causes in routing and DNS

MX records point to the wrong place

MX records tell sending servers which machine handles mail for the domain. If they are wrong, mail either bounces or arrives at a server nobody is monitoring.

Recurring versions of this:

Records from a previous provider were never removed, so mail splits between old and new
Records were edited at the registrar while a different DNS host is actually authoritative for the domain
A recent change has not yet propagated — DNS caching honours the record's TTL
Two providers' records coexist at the same priority

For how MX records work in detail, see MX, DNS, and mail routing explained.

How to recognise it: "relay access denied," or mail arriving somewhere unexpected, or nothing at all.

The domain expired or was suspended

Domains lapse quietly. Once a domain stops resolving, MX lookups fail and all mail to it bounces. Registrar renewal notices are themselves sent by email, which is an unfortunate loop.

How to recognise it: every address on the domain fails simultaneously, including ones that worked a day earlier.

A security gateway is intercepting mail

Organisations frequently route mail through a filtering appliance or service before it reaches the mail server. These hold, rewrite, or drop messages according to policy, and the policy is not visible from the mailbox.

How to recognise it: the message reached the gateway according to logs but never reached the mail server.

Causes on the sending side

Authentication failures

SPF, DKIM, and DMARC let a receiving provider verify that a sender is genuinely authorised to use the domain it claims. When these fail — or when a DMARC policy is set to reject — receiving providers may refuse the message or file it as spam.

This has tightened considerably. Since 2024, Google and Yahoo have required SPF and DKIM on all bulk mail, DMARC for high-volume senders, and one-click unsubscribe, with spam complaint rates kept low. Microsoft has since introduced comparable requirements. Senders who were fine for years have found their mail rejected under the newer rules.

How to recognise it: one sender consistently fails while everything else arrives; their bounce message references authentication, SPF, DKIM, or DMARC.

Poor sending reputation or a blocklist entry

Mail servers consult reputation data and blocklists. A shared hosting IP can be listed because of another customer's behaviour, and a newly provisioned IP has no history at all, which is treated with suspicion.

How to recognise it: a rejection referencing a blocklist, often with a URL explaining the listing.

The sender mistyped the address

Mundane and extremely common. The message went somewhere else entirely, or bounced back to a sender who did not notice.

How to recognise it: nothing in your logs at all — no accepted message, no rejection. The mail never arrived to be refused.

Causes that are not really failures

The message is deferred, not lost

A 4xx response means "try again later," and sending servers retry over a day or more. Greylisting deliberately rejects unfamiliar senders once, expecting a retry. Rate limits and short outages behave the same way.

Mail arriving twenty minutes late is normal behaviour, not a fault.

Synchronisation, not delivery

The message reached the mailbox but the mail client has not fetched it. Checking the same account through webmail settles this in seconds: if it is there in the browser and not in the app, the problem is the app.

Narrowing it down quickly

The fastest way to separate these is a controlled message from an independent sender, because it removes the sender-side variables entirely. Send a test message and compare two things: what the delivery status reports at the SMTP level, and what appears in the mailbox.

Accepted and visible: the mailbox works; the original problem is sender-specific
Accepted, not visible: filtering, rules, or forwarding
Rejected: routing, address, or mailbox state — and the code says which
Deferred: wait and retry before investigating further

Frequently asked questions

Why do I receive some emails but not others?

Almost always sender-specific: an authentication or reputation problem affecting one sender, or a rule on your side matching their address or domain.

Can an email be delivered but never appear?

Yes. Acceptance at SMTP and placement in a folder are separate decisions. The server can accept a message and then file it in Spam, quarantine, or nowhere.

How long can a delayed message take?

Deferred mail typically retries for a day or more before the sending server gives up. Anything within a few hours is unremarkable.

My inbox works but a form on my website never emails me. Why?

That is usually a sending problem at the form's end, not a receiving problem. Confirm the mailbox accepts mail from an independent sender first — that separates the two halves.

Should I change my MX records?

Only if you control the domain and understand the current setup. An incorrect MX edit stops all mail to the domain, not just the message you were chasing.

Not sure which half of the problem you have? Send a free test message and check the delivery status — that alone rules out most of this list.