The three fates of an email: inbox, spam, or rejected

Every email you send meets one of three fates: refused at the receiving server's door, accepted and placed in the inbox, or accepted and filed into spam. Only the first fate reports itself back to you. The other two leave identical records on your side, and the single word your ESP uses for both of them, delivered, may be the most successfully misleading word in marketing software. This lesson pins the three fates down, separates the two words the industry constantly blurs (delivery and deliverability), and shows why the fate nobody reports is the one that decides whether email earns you anything.

Lesson one followed a single message through the SMTP conversation and ended on these outcomes. Here we slow down and look at each fate from the sender's chair, because the asymmetry in what you can see is the whole game.

The loud fate

Rejection happens during the SMTP conversation itself. The receiving MTA (the mail server on the recipient's side) answers with a 5xx code, refuses to take the message, and the exchange ends. Because refusal happens while the two servers are still connected, the receiver can say why, and usually does, in a line built for both machines and humans:

550 5.1.1 <reader@example-mail.com>: Recipient address rejected: User unknown

Your sending server wraps that refusal into a bounce (the failure notice from lesson one), your ESP parses it, and the recipient appears in your dashboard as bounced, often with the stated reason attached. A retired address, a full mailbox, a sending server found on a blocklist the receiver consults (the list operators from last lesson), a receiver policy that simply refuses mail like yours: all of these end here.

Rejection costs you a recipient, but it pays you back in information. You know the same day, you know which address, and you usually know why. There's a full lesson later on reading bounce codes properly; for now, the visibility itself is the point.

Two fates, one receipt

The other two fates begin identically. The receiving server answers 250 OK, takes custody of the message, and hangs up. Everything after that, the provider's filters deciding between inbox and spam folder, happens once the conversation is over. The receipt has already been issued. No protocol message exists for "we put that one in spam", and no provider volunteers one, because handing senders their filtering verdicts would give spammers a free testing service. The opacity you met last lesson is deliberate.

A useful picture is a courier and an office mailroom. The clerk signs for the parcel and the courier drives away with a signature on file. Whether the parcel goes up to the recipient's desk or into a bin behind the building is decided later, by people the courier never meets, and the signature stays valid either way.

Your ESP is the courier. Delivered means signed for. That is the entire claim, and your ESP is not lying when a heavily spam-foldered campaign shows 99% delivered; it is reporting the only event the protocol let it witness. The split inside that 99% between fate two and fate three is invisible to it, and to every other dashboard on your side of the wire.

I don't believe ESPs chose the word to deceive; in the protocol's own vocabulary it is accurate. But notice that nobody has an incentive to rename the column "accepted". The honest word invites the obvious next question, accepted into which folder, and that question has no flattering answer to sell.

Two words the industry blurs

Delivery rate is arithmetic: of the messages you sent, the share the receiving servers accepted. Sent minus bounces, roughly. Healthy lists sit in the high nineties, and the number is real and precise. It describes the door and nothing past it.

Deliverability is the thing this course is named for: your mail's tendency to reach the inbox rather than the spam folder. It is a property, not a dashboard column, and it depends on your authentication, your reputation, your list, your content. No sender-side tool reports it as a single true number; a later lesson is devoted to how much of it can honestly be measured.

Keep the two apart and one common absurdity dissolves: a 99% delivery rate with terrible deliverability is not a contradiction. It is ordinary. All it takes is fate three.

Where the money leaks

Rejection self-corrects; silent spam placement compounds.

When mail is rejected, the feedback forces a reaction: bounces arrive, the dashboard turns red, someone investigates. When mail is spam-foldered, every instrument you watch stays green. You keep paying to send, the reports keep looking normal, and the only trace is a slow sag in opens and replies that is easy to blame on the content or the season. The classic response is to rewrite subject lines. The classic result is nothing, because content was never the fate being suffered.

Now notice where email actually earns: replies, clicks, orders, renewals all happen in the inbox. The fate that removes mail from the inbox is precisely the one that emits no signal. If a third of an accepted campaign lands in spam, the delivered number does not move by a single point. The entire loss occurs below the resolution of the metric everyone watches.

The mix moves

Your domain's blend of the three fates is not a fixed property. It is a running verdict, recomputed by receivers all the time, and the proportions drift as your reputation shifts, your DNS records rot, and your list ages. The drift usually runs through the silent fate: domains rarely fall from inboxed to rejected in one step. They slide from inbox to spam folder first, and that leg of the decline produces no bounce, no alert, no red dashboard, no email from anyone. Nobody emails you when the mix moves.

Watching sending domains over time, the pattern is consistent: the delivered rate is the last number to react, and by the time it does, the silent fate has been collecting your mail for months. The layer underneath the verdict, your published DNS records and what they claim, is at least checkable from outside (the free health check reads it for any domain), which is why this course keeps returning to it. Part 5 takes the decay mechanisms apart one by one.

The three fates also raise a question this part hasn't answered yet: when a message claims to come from you, how does the receiver know it really did? Anyone can type your name into a From line (you saw the two From addresses in lesson two). The next lesson is about that impersonation problem, and it explains why the entire next part of this course exists.

Terms from this lesson

• rejection - a 5xx refusal during the SMTP conversation; the message is never accepted, and a bounce carries the reason back to the sender.
• spam placement - the silent fate: accepted with 250 OK, then filed into the spam folder after the conversation ends. No signal returns to the sender.
• delivery rate - the share of sent messages that receiving servers accepted (roughly, sent minus bounces). Describes the door only, never the folder.
• deliverability - your mail's tendency to reach the inbox rather than spam; a property you manage, not a column any dashboard shows.

Check yourself

1. Your ESP marks a message as delivered. Which of the three fates could that message still have met?

Inboxed or spam-foldered; delivered only rules out rejectionOnly inboxed; spam-foldered mail is reported separately as spamAny of the three, including rejectedOnly spam-foldered; inboxed mail is reported as opened

2. A campaign report reads: Sent 12,000 · Bounced 120 · Delivered 11,880 (99.0%) · Opened 1,150. What do you know for certain about the 11,880?

They reached inboxes, because they didn't bounceThey were accepted by the receiving servers; how many reached an inbox is unknownAbout 10,700 of them went to spam, since only 1,150 openedThey passed the receivers' spam filtering

3. Why does a sender find out about rejection but not about spam placement?

Providers do notify senders of spam placement, but ESPs suppress it to keep delivered numbers highSpam placement also generates a bounce, but it goes to the recipient insteadRejection happens during the SMTP conversation, while folder filtering happens after the receiver has already accepted and hung upSpam filtering is random, so there is nothing to report

4. Your delivery rate has held at 99% all year. What does that tell you about your deliverability?

It's fine, since spam-foldered mail would have shown up as bouncesDeliverability and delivery rate are the same thing measured at different timesYour reputation must be good, because bad reputation causes rejectionsAlmost nothing; acceptance can stay high while inbox placement collapses