Two Seconds, Six Systems

You press send. Two seconds later it is in someone's inbox on another continent. It feels like one action, and it is at least six, each of which can quietly fail in ways that explain most email problems people ever have.

This is worth understanding even if you never touch a mail server, because it tells you why messages land in spam, why "delivered" does not mean "read", and why email is not private in the way most people assume.

Step 1: Your Client Hands It Over

Your mail app packages the message into headers (who, when, subject, routing) and a body, then connects to your provider's outgoing server over SMTP — Simple Mail Transfer Protocol, a design from 1982 that still carries essentially all the world's email.

It authenticates as you, over an encrypted connection. This part is reliable and rarely the problem.

Step 2: Finding the Recipient's Server

Your provider now needs to know where mail for the recipient's domain goes. It asks DNS for that domain's MX records — a prioritised list of mail servers.

This is a public lookup. Anyone can run it, which is how you can tell that a company uses Google or Microsoft to handle its mail.

If the domain has no MX records, delivery fails immediately and you get a bounce. This is the usual cause of the instant "address not found" reply after a typo in the domain.

Step 3: The Handshake

Your provider connects to the receiving server and they negotiate. Modern servers upgrade to an encrypted connection using STARTTLS.

Here is the detail worth knowing: that encryption is opportunistic. It protects the message in transit between those two servers, and classic SMTP will fall back to plain text if encryption is unavailable. It is not end-to-end. Both providers can read the contents, and so can anyone who compromises either.

That is the honest answer to "is email private?" It is private from casual interception and not private from the companies handling it. If you need genuine secrecy, you need encryption applied to the message itself, not to the pipe.

Step 4: The Receiving Server Decides

This is where most of the interesting failures live. Before accepting anything, the receiving server tries to establish whether the sender is who they claim. Three mechanisms do the work, and every one of them is a DNS record the domain owner publishes.

SPF — who is allowed to send

The domain publishes a list of servers permitted to send its mail. The receiver checks whether this connection came from one of them. Fail, and the message is suspect.

DKIM — was it altered

The sending server signs the message cryptographically. The receiver fetches the public key from DNS and verifies the signature. Valid means the message genuinely came from that domain and was not modified in transit.

DMARC — what to do about failures

Ties the first two together and states the domain owner's policy: do nothing, quarantine, or reject outright. It also enables reports, so a domain owner can see who is sending mail claiming to be them.

These three explain a great deal:

  • Why your mail from a custom domain lands in spam. Usually SPF or DKIM was never configured.
  • Why forwarding breaks things. Forwarding changes the sending server, so SPF fails at the final destination.
  • Why phishing still works. DMARC only protects domains that publish a strict policy. Plenty do not — and attackers simply register a lookalike domain and pass every check legitimately, because they genuinely own it.

Then the reputation check

Authentication proves identity, not honesty. A server that passes every check can still be a spam source, so the receiver also weighs the sending IP's history, the domain's age and reputation, whether the content resembles known spam, and — crucially — how recipients have treated similar mail.

That last one is why marking spam matters. You are not just filing a message; you are voting in a system used across millions of inboxes.

Greylisting

Some servers reject the first attempt from an unfamiliar sender with a "try again later." Real mail servers retry; a lot of spam software does not. This is the usual explanation for a verification code arriving several minutes late and instantly the second time you request it.

Step 5: Sorting

Accepted mail is scored and filed — inbox, promotions, spam. This is now overwhelmingly machine-learned rather than rule-based, which is why nobody can give you a reliable list of words to avoid.

Delivery to the server is a technical fact. Delivery to the inbox is a judgement call, and the two are not the same thing.

Step 6: It Sits There

Your message now rests on the recipient's provider's servers, typically in plain text, retained under their policy, subject to their jurisdiction. It stays there until deleted, and often for some period afterwards in backups.

Every copy along that path — your sent folder, your provider, their provider, their device — is a place it can be read later. Email is a fundamentally copy-heavy system.

What This Explains

Why "read receipts" are unreliable

SMTP has no built-in concept of reading. Tracking works by embedding a tiny remote image that reports when it loads. Blocking remote images — which many clients now do by default — silently defeats it.

Why bounces differ

A hard bounce means permanent failure: the address does not exist. A soft bounce is temporary: mailbox full, server down, greylisting. Senders retry soft bounces for a day or two before giving up.

Why disposable domains get blocked

Reputation attaches to domains. Services that hand out throwaway addresses attract signups the receiving sites do not want, so many maintain blocklists. It is a reputation decision, not a technical limitation — which is why an address that worked last month may be refused today.

Why you cannot unsend

Once the receiving server accepts a message, it is theirs. "Unsend" features work only inside a single provider, by delaying transmission for a few seconds. Across providers, there is no recall mechanism and never has been.

What It Means for You

  • Treat email as a postcard, not a sealed letter. Fine for most things, wrong for secrets.
  • If your own mail lands in spam, check SPF, DKIM and DMARC before rewriting the copy. It is almost always authentication.
  • Report spam rather than deleting it. You are training a shared system.
  • A late verification code is usually greylisting. Requesting a second one is generally faster than waiting.
  • Passing authentication does not mean a sender is trustworthy. A lookalike domain passes everything, because the attacker really does own it.

Common Questions

Can my provider read my email?

Technically, yes. Standard email is stored unencrypted on their servers. Reputable providers restrict access and log it, and some offer encrypted storage — but the protocol itself gives them the ability.

Is a temporary address less secure than a normal one?

It is the same protocol with the same transit protections. The difference is at rest: a disposable inbox has no password, so anyone knowing the address can read it. It hides who you are from the sender rather than hiding contents from onlookers.

Why does the same message reach one person and not another?

Because filtering is per-recipient. Their provider, their filter's training, their own history with that sender. There is no global verdict on a message.

What is the difference between an alias and a separate mailbox?

An alias is a label routing to an existing mailbox — no separate storage, no separate login. A mailbox is its own account with its own credentials. Aliases are lighter; mailboxes are properly separate.

The Short Version

Sending an email is a chain: your client, your provider, a DNS lookup, an opportunistically encrypted handshake, an authentication and reputation check, then a filtering decision. Most problems are the authentication step, most spam outcomes are the reputation step, and privacy is limited by the fact that both providers hold readable copies.

Knowing the chain turns "email is being weird" into a question with an answer.