What happens to your email after you hit send (step by step)

Most deliverability confusion traces back to a single missing piece of context: what actually happens to an email message between the moment you click Send and the moment it appears (or doesn't) in the recipient's inbox. The process runs in roughly two seconds and involves at least eight discrete stages, each with its own failure modes. This is the whole chain.

Step 1 — SMTP submission to the outbound MTA

You click Send. Your mail client (or ESP API, or sending script) opens an authenticated SMTP connection to your outbound mail transfer agent — typically on port 587 with STARTTLS, or 465 with implicit TLS. The MTA is your ESP (SendGrid, Mailgun, Postmark) or your own server (Postfix, Exim, Haraka). It accepts the message into its outbound queue.

This step fails on bad credentials, rate limits, or submission-port blocks. From here your MTA takes ownership and starts the real delivery work.

Step 2 — DNS MX lookup for the recipient domain

Your outbound MTA takes the recipient address (e.g. user@example.com) and asks DNS: which mail servers handle mail for example.com? This is an MX record query. DNS returns an ordered list — for Gmail, that's gmail-smtp-in.l.google.com and four backups at higher MX priority values.

MX lookup failures usually mean the recipient domain doesn't exist or has no mail server, producing an immediate hard bounce. If MX records exist but every host returns connection errors, the message goes into a retry queue and is attempted again over 24–48 hours.

Step 3 — TLS handshake and EHLO

Your MTA connects to the recipient MTA on port 25 and initiates an SMTP conversation. It sends an EHLO command with its hostname; the server responds with its capabilities. Modern senders and receivers immediately negotiate TLS via STARTTLS.

The EHLO hostname matters. Gmail and Microsoft check that the name resolves in DNS, that a PTR (reverse DNS) record points to the same name, and that the TLS certificate matches. Mismatches cost placement points even when they don't reject the message.

Step 4 — MAIL FROM and RCPT TO (the envelope)

Your MTA sends MAIL FROM:<bounce@yourdomain.com> (the envelope sender, a.k.a. Return-Path) and RCPT TO:<user@example.com>. The Return-Path controls where bounce notifications go, and is what SPF is checked against.

The envelope From is not the same as the header From your recipient sees. ESPs typically use their own domain in the envelope (bounces+abc@sendgrid.net) and your domain in the header. This is why DMARC alignment matters — the two have to match or SPF alignment fails.

Step 5 — DATA (the message body)

Your MTA sends DATA, then streams the full message — headers and body — followed by a terminator. The receiving server replies with 250 OK and a queue ID, indicating the message is accepted.

This is the moment your ESP marks the message as "delivered". It is not the moment the message reaches the inbox. Every step after this happens inside the recipient's infrastructure, invisible to your ESP. Everything that can still go wrong from here is what your 99% delivery rate isn't measuring.

Step 6 — Authentication checks

The receiving MTA now runs a cluster of checks:

• SPF: does the connecting IP match the SPF record of the Return-Path domain?
• DKIM: is the DKIM-Signature header valid against the public key in DNS?
• DMARC: does at least one of SPF/DKIM pass and align with the header From domain? Apply the DMARC policy on failure.
• ARC: has the message passed through trusted forwarders that sealed the original auth results?

Results are written into an Authentication-Results header. Gmail and Microsoft also consult their own historical data on your sending domain and IP at this stage.

Step 7 — Content and reputation scanning

Now the filter runs. Every major provider combines multiple engines:

• Bayesian and rule-based filters like SpamAssassin and Rspamd — pattern matching on subject lines, headers and body.
• ML classifiers trained on user feedback — Gmail's is the most mature, Outlook's SmartScreen is close behind.
• DNSBL and URIBL lookups against Spamhaus, Barracuda, SURBL — is the sending IP blacklisted? Are any links in the body blacklisted?
• URL reputation — newly-registered domains, URL shorteners, previously-flagged hosts all carry penalties.
• Content structure checks — plain-text part present? Image-to-text ratio? HTML well-formed?

The outputs are combined with the authentication and reputation scores into a single verdict.

Step 8 — Filter routing decision

The verdict dispatches the message to one of four outcomes:

• Inbox / Primary tab — the good case.
• Category tab (Gmail Promotions, Updates, Social, Forums) — not Spam, but buried. Opens drop roughly 80% versus Primary.
• Spam / Junk folder — placement failure. Message is there but unlikely to be read.
• Deferral or silent discard — the worst case.451 4.7.1 deferrals get retried, but some providers silently drop messages when they suspect abuse. Your ESP reports them as delivered.

Step 9 — Client render

Finally, the recipient opens their mail client and the message is displayed. Different clients apply their own post-filter logic: Gmail's AI summary prefetches content, Outlook strips tracking pixels, Apple Mail triggers MPP pre-fetches. Whether the human actually sees the message depends on where the filter put it and whether the client surfaces that folder.

What can break at each step

Quick guide to where real-world failures happen:

• Steps 1–2: your infrastructure — auth failures, DNS misconfig, transient errors.
• Steps 3–4: PTR mismatches, TLS issues, SPF alignment failures.
• Step 5: rate limits, throttling (421 4.7.0), temporary blocks.
• Step 6: broken DKIM selector, DMARC policy rejections, SPF record issues.
• Step 7: blacklist hits, risky content, bad links, suspicious patterns.
• Step 8: the gap between "delivered" and actually reaching the inbox — the only thing inbox placement tests measure.

Frequently asked questions