Why email bounces or lands in spam: the seven causes

First, read the bounce

A rejection notice (a bounce, formally a non-delivery report) carries two load-bearing pieces: a code and a sentence. The code comes in two parts - a three-digit number like 550, where a leading 5 means permanent failure and a leading 4 means temporary (the sender will retry) - and an enhanced code like 5.7.515 that narrows down the reason. The sentence after it is the receiving server's own explanation, and it is usually more honest than people expect.

Two examples you will actually meet. Microsoft's 550 5.7.515 Access denied, sending domain does not meet the required authentication level means your domain failed SPF, DKIM, or DMARC checks - an authentication problem, fixable on your side. 550 5.2.2 with "mailbox full" means exactly that - nothing about your setup is wrong.

The seven causes

1. Authentication

The receiver could not verify the message really came from your domain: SPF failed or was not aligned, DKIM was missing or signed by the wrong domain, so DMARC failed. Since the 2024 Google and Yahoo mandates and Microsoft's 2025 follow-up, large receivers reject bulk mail outright for this - the 5.7.515 above is the signature example. This is the most common cause and the most fixable: authorize the sending service in your SPF record and turn on custom DKIM signing so it signs as your domain, not its own.

2. Reputation

Authentication passed - the receiver knows the mail is really yours - and filtered it anyway, because of how recipients have reacted to your mail. The signals: your spam-complaint rate (Gmail's rejection line sits at 0.30%), the sending IP or domain appearing on blocklists, and the receiver's own filter scoring. A DNS change cannot fix reputation; list hygiene, honest sending volume, and easy unsubscribes do, slowly.

3. Forwarding damage - not your fault

The message left you correctly authenticated, then a forwarder or mailing list modified it in transit, which broke the DKIM signature and re-sent it from a server your SPF never heard of. The receiver's rejection is honest but aimed at the middleman. Forwarders and DMARC covers why, and why aligned DKIM is the part that survives forwarding.

4. Connection and routing

The two mail servers could not complete a conversation at all: TLS negotiation failed, a certificate did not match, DNS pointed at the wrong place, or the connection timed out. These read as 4xx deferrals or network-flavored 5xx codes and often heal themselves; persistent ones show up in TLS reports if you have TLS-RPT enabled.

5. The recipient's mailbox

Mailbox full, address does not exist, account disabled. Codes like 5.2.2 (over quota) and 5.1.1 (user unknown) say the problem ends at the recipient's door. Nothing on your side is broken - though a rising rate of user-unknown bounces is a hint to clean your list before receivers read it as a reputation signal.

6. Receiver policy

The receiving organization blocked the message under its own local rules: a banned attachment type, a keyword rule, a block on your whole region or industry, an admin-maintained deny list. Your authentication and reputation can both be spotless. The fix is a conversation with the recipient's IT team, not a DNS change.

7. Genuinely unclear

Sometimes the evidence does not point one way: clean authentication, clean reputation, and a receiver that folded the message into junk anyway. An honest analysis says so, rather than inventing a cause. What helps here is more evidence over time - your DMARC aggregate reports, Gmail's Postmaster data - not another guess.

Naming the cause is the whole game

Notice what the list implies: three of the seven causes need a fix from you (authentication, reputation, and sometimes connection issues), two need nothing at all (forwarding damage, the recipient's mailbox), and one needs a phone call (receiver policy). Treating a mailbox-full bounce as a deliverability crisis wastes an afternoon; treating a 5.7.515 as random bad luck loses you a customer's invoices for a month.

This is exactly what Delivery Diagnosis in trustyourinbox does with a real artifact: forward the bounce or the junk-foldered message to your workspace's private diagnose address (as an attachment), and it decodes the bounce, checks the original's authentication results, joins them against your own DMARC report history and blocklist status, and answers with one plain-English verdict - which of these causes it was, how confident, what it ruled out, and the fix when one exists.