What happens when you hit send

Every email you send has to pass two gates. The first gate is acceptance: the receiving server either takes your message or refuses it, and it tells you which. The second gate is placement: the inbox or the spam folder, decided after acceptance, in silence. "Delivered" and "inboxed" are two different events, and the gap between them is where deliverability lives. This entire course is about that gap.

Before we can talk about spam filters, authentication, or reputation, you need to see the machinery. So this first lesson follows one message, start to finish. Say it's your weekly newsletter, going to one reader at example-mail.com.

The machinery on your side

You write email in one of two places. Either a mail client (Apple Mail, Outlook, Thunderbird, Gmail's web interface: the thing you personally type into), or an ESP, an email service provider, which is any tool that sends on your behalf to a list: Mailchimp, Kit, Klaviyo, and their many relatives. For one-to-one mail the client hands your message to your provider's outgoing server. For a newsletter, the ESP is both the writing surface and the sending machinery.

Either way, the message ends up at an MTA, a mail transfer agent. That's the actual mail server: a program whose whole job is moving messages between machines. Your side has one (the sending MTA), the recipient's side has one (the receiving MTA), and everything interesting in this lesson happens between those two.

One important mental adjustment: when you hit send, nothing has been sent yet. Your message has been submitted to your own side's MTA, which now owns the problem of getting it across the internet. Sending is a handoff chain, and you only ever touched the first link.

Finding the door: the MX lookup

Your sending MTA holds a message addressed to reader@example-mail.com. Where does it take it? It asks DNS, the internet's public directory (we give DNS a whole lesson at /learn/dns-for-email, because your email configuration lives there).

Specifically, the MTA asks for the MX records of example-mail.com. MX stands for mail exchanger, and the records answer one question: which servers accept mail for this domain? The answer is a list of server names with priority numbers, and the MTA tries the lowest number first. If a domain publishes no MX record at all, the standard allows falling back to the domain's plain address record, but for any real mailbox there will be an MX.

That's it. No central post office, no registry of senders. Any machine on the internet can look up your MX and knock on the door. This openness is why email works everywhere, and also why the rest of this course exists: since anyone can knock, receivers have built elaborate systems for deciding who to trust.

The SMTP conversation

The two MTAs now talk over SMTP, the Simple Mail Transfer Protocol, defined in RFC 5321. It's a text conversation, and it is genuinely readable. Here is the whole thing, lightly trimmed, with C: for your sending server (the client in this exchange) and S: for the receiving server:

S: 220 mx.example-mail.com ESMTP ready
C: EHLO mail.yourdomain.com
S: 250 mx.example-mail.com, hello
C: MAIL FROM:<bounce@yourdomain.com>
S: 250 OK
C: RCPT TO:<reader@example-mail.com>
S: 250 OK
C: DATA
S: 354 Go ahead, end with a dot on its own line
C: From: You <you@yourdomain.com>
C: Subject: This week's issue
C:
C: (the entire message body)
C: .
S: 250 OK: message queued

In plain English, line by line:

• EHLO is the greeting. The sender introduces itself by name. (The E is for "extended"; the original command was HELO, and yes, the protocol literally opens with hello.)
• MAIL FROM states the return address: where failure notices should go if this message can't be delivered. Note that this address never appears in the reader's inbox view. It can be, and for ESP mail usually is, a different address from the one your reader sees.
• RCPT TO names the recipient. For a message to many people at the same provider, this line repeats.
• DATA says "here comes the message itself", and everything after it, headers and body, is the email as you know it, ending with a lone dot.
• The final 250 is the receiver saying: accepted. I take responsibility for this message now.

That mismatch between the MAIL FROM address and the From: your reader sees is not a bug. It is a load-bearing design decision, and the next lesson is entirely about it, because the whole authentication system is built on knowing which "from" is which.

Queues, retries, and answering machines

Every reply in that conversation starts with a number, and the first digit is the verdict. A 2xx code means success. A 5xx code means permanent refusal: don't try again. And a 4xx code means "not right now": a temporary failure, maybe the server is busy, maybe it's deliberately slowing you down to see if you behave like a legitimate sender (a tactic called greylisting, since real MTAs retry and much spamware doesn't).

On a 4xx, your sending MTA doesn't give up. It puts the message in a queue and retries on a schedule, typically for hours and up to a few days, before it finally surrenders and reports failure. This is why email is described as store-and-forward: each server along the way stores the message and takes responsibility for the next hop. It's also why email can arrive late rather than never, and why "I sent it an hour ago" and "it hasn't arrived" can both be true with nothing broken.

When delivery fails permanently, the failure notice, called a bounce, goes to the MAIL FROM address from the conversation above. Now you know why that address exists.

The three fates

So your message meets one of three ends.

Fate one: rejected at the door. The receiving MTA answers 5xx during the conversation, delivery never happens, and a bounce comes back. Painful, but honest. You know, and you can react.

Fate two: accepted, then inboxed. The 250 OK arrives, the provider's internal filtering looks the message over, and it lands in the inbox. This is the outcome everything in this course is engineered toward.

Fate three: accepted, then spam-foldered. Same 250 OK. Same "delivered" status in your ESP dashboard. But after acceptance, the provider's filters judged the message unwanted and filed it in spam. No bounce comes back, and no error code appears anywhere. Your ESP counts it as delivered because, by the SMTP definition, it was.

Read fate three again, because it's the one that costs people months. The second gate is silent by design: providers don't tell senders their filtering verdicts, since that would hand spammers a testing service. From the outside, a message in spam and a message in the inbox produce identical delivery records. The first symptom most senders notice is an open rate sliding downward, weeks after the folder decisions started.

I'll be straight about what that means for measurement, since we build monitoring tools and this limit applies to us too: nobody outside the mailbox provider can directly observe the second gate at scale. What can be measured is the layer the gate's decision is based on: whether your domain's records are intact, whether your messages actually pass authentication, whether your sending server sits on a blocklist, and whether the headers carry what modern receivers require. That layer is public and checkable, and you can run those checks on your own domain right now, free. What we see running them across many sending domains is that senders confidently describe their setup as "done" while the public record says otherwise, and they find out in exactly the order this lesson describes: open rate first, cause much later.

The rest of this module builds your vocabulary. Next comes the anatomy of a message, then the DNS it depends on, and the module closes with a map of who runs all this. Then we get to the gates themselves.

Terms from this lesson

• mail client - the program you personally read and write email in, such as Apple Mail, Outlook, or Gmail's web interface.
• ESP (email service provider) - a tool that sends email to a list on your behalf: Mailchimp, Kit, Klaviyo, and similar.
• MTA (mail transfer agent) - a mail server; software whose job is transferring messages from one machine toward their destination.
• MX record - the DNS record listing which servers accept incoming mail for a domain, with priority numbers.
• SMTP - the Simple Mail Transfer Protocol, the text conversation two mail servers use to hand a message over (RFC 5321).
• bounce - the failure notice sent to the return address when a message is permanently refused or undeliverable.
• greylisting - a receiver tactic of answering "try again later" to first contact, filtering out software that never retries.
• delivered - accepted by the receiving server during SMTP. Says nothing about which folder the message landed in.
• inbox placement - the silent second decision: whether an accepted message goes to the inbox or the spam folder.

Check yourself

1. Your ESP dashboard shows a campaign as 98% delivered. What does that actually tell you?

98% of messages were accepted by receiving servers; folder placement is unknown98% of recipients saw it in their inbox98% of recipients opened it2% of recipients marked it as spam

2. A sending server needs to deliver mail to someone at example-mail.com. How does it find the right server to connect to?

It asks a central email registryIt connects to www.example-mail.comThe recipient's mail client tells it where to connectIt looks up the MX records for example-mail.com in DNS

3. During the SMTP conversation, the receiving server answers a command with code 421 (a 4xx code). What happens next?

The message bounces immediatelyThe message is silently discardedThe sending server queues the message and retries laterThe message is delivered to the spam folder

4. Which address receives the bounce when a message can't be delivered?

The From address the reader sees in their inboxThe address given in MAIL FROM during the SMTP conversationThe Reply-To addressThe recipient's postmaster address