How Email Delivery Actually Works: The Complete Journey From Send to Inbox

Email feels instant. You click send, and seconds later a message appears in someone else's inbox halfway around the world. But between that click and that appearance, your message passes through a chain of systems, protocols, and decisions that most senders never see.

Understanding this chain is not academic. Every deliverability problem, every spam folder placement, every bounced message traces back to a specific step in this process. When you know how the system works, you know where to look when it breaks.

The Cast of Characters

Before tracing the journey, here are the key systems involved:

Step 1: Composing and Submitting the Message

When you compose an email in your mail client (the MUA), your client builds a structured message with two distinct parts:

• The envelope: Contains the SMTP-level routing information, specifically the envelope sender (MAIL FROM) and the recipient address (RCPT TO). This is like the address written on a physical envelope.
• The message: Contains the headers (From, To, Subject, Date, Message-ID, MIME type) and the body (your actual content). This is like the letter inside the envelope.

The envelope and the message are separate. The From address displayed to the recipient (in the message headers) can differ from the envelope sender (used for routing and bounces). This separation is by design, but it is also what makes spoofing possible, which is why authentication protocols like DMARC exist to verify that these identities align.

Your MUA connects to the Mail Submission Agent on port 587 (or 465 for implicit TLS) using authenticated SMTP. The MSA verifies your credentials, validates the message format, and passes it to the outbound MTA for delivery.

Step 2: The DNS Lookup

The sending MTA needs to know where to deliver the message. It extracts the domain from the recipient's address (e.g., "example.com" from user@example.com) and queries DNS for the domain's MX (Mail Exchange) records.

MX records specify which servers accept email for a domain, along with priority values:

example.com.  IN  MX  10  mail1.example.com.
example.com.  IN  MX  20  mail2.example.com.

The sending MTA tries the server with the lowest priority number first (mail1). If that server is unreachable or returns a temporary error, it falls back to the next priority (mail2). If no MX record exists, the MTA falls back to the domain's A record as a last resort.

The MTA then resolves the MX hostname to an IP address (via A/AAAA records) and establishes a TCP connection to port 25 on the receiving server.

Step 3: The SMTP Handshake

Once the TCP connection is established, the two servers perform an SMTP handshake. This is a structured conversation that has remained fundamentally the same since RFC 5321 (and its predecessor RFC 821, published in 1982):

Receiving: 220 mx.example.com ESMTP ready
Sending:   EHLO sender.example.org
Receiving: 250-mx.example.com Hello
           250-SIZE 52428800
           250-STARTTLS
           250 OK
Sending:   STARTTLS
Receiving: 220 Ready for TLS
           [TLS negotiation happens here]
Sending:   MAIL FROM:<bounce@sender.example.org>
Receiving: 250 OK
Sending:   RCPT TO:<user@example.com>
Receiving: 250 OK
Sending:   DATA
Receiving: 354 Start mail input
Sending:   [Headers and body of the message]
           .
Receiving: 250 OK, message queued
Sending:   QUIT
Receiving: 221 Bye

Several important things happen during this handshake:

• EHLO/HELO: The sending server identifies itself. The receiving server checks whether the HELO/EHLO hostname resolves and matches the connecting IP. Mismatches can trigger spam scoring.
• STARTTLS: If both servers support TLS, they negotiate an encrypted connection. In 2026, most major providers require or strongly prefer TLS for inbound connections.
• MAIL FROM: This sets the envelope sender (also called the Return-Path). Bounce notifications go to this address.
• RCPT TO: Specifies the recipient. The receiving server can accept or reject at this point (e.g., if the address does not exist, returning a 550 error).
• DATA: The full message (headers + body) is transmitted. The receiving server accepts it into its queue and returns a 250 confirmation.

Step 4: Authentication Checks

After accepting the message, the receiving server performs authentication checks. These happen in a specific order and each checks something different:

SPF (Sender Policy Framework)

The receiving server looks up the SPF TXT record for the domain in the MAIL FROM (envelope sender). This record lists which IP addresses are authorized to send for that domain. If the sending server's IP is not in the list, SPF fails.

DKIM (DomainKeys Identified Mail)

The receiving server reads the DKIM-Signature header in the message, extracts the selector and domain (d= and s= values), looks up the corresponding public key in DNS, and verifies the cryptographic signature. If the signature does not match, the message was altered in transit or the DKIM key is wrong.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together with alignment: the domains authenticated by SPF or DKIM must match the domain in the visible From header. If neither SPF nor DKIM passes with alignment, DMARC fails, and the receiving server follows the domain's published DMARC policy (none, quarantine, or reject).

Step 5: Reputation and Spam Filtering

Authentication tells the receiving server who sent the message. Reputation tells it whether that sender is trustworthy. These are separate questions.

The receiving server evaluates sender reputation using signals including:

• IP reputation: The sending IP's history of spam complaints, spam trap hits, and volume patterns.
• Domain reputation: The sending domain's historical engagement (opens, clicks, complaints, unsubscribes).
• Content analysis: SpamAssassin scores, Bayesian classification, machine learning models that analyze the message text, links, HTML structure, and attachments.
• Engagement history: How have this sender's previous messages performed with this specific recipient and with the provider's broader user base?
• Blocklist checks: Is the sending IP or domain listed on any DNSBL (DNS-based blocklist)?

Each mailbox provider uses its own proprietary blend of these signals. Gmail weights engagement heavily. Microsoft emphasizes IP reputation and content analysis. Yahoo uses a combination of both. The exact algorithms are not public, but the input signals are well-documented.

Step 6: The Final Delivery Decision

Based on the combined results of authentication, reputation, and content analysis, the receiving system makes a final delivery decision:

• Inbox (Primary): The message is trusted and delivered to the main inbox.
• Category/Tab: The message is legitimate but categorized (Gmail's Promotions, Updates, or Social tabs; Outlook's "Other" inbox).
• Spam/Junk: The message passed enough checks to be accepted but is flagged as unwanted.
• Silent discard: Some providers accept the message (returning 250 OK) but silently drop it without delivering to any folder. This is rare but does happen for known spam sources.

The Mail Delivery Agent (MDA) handles the physical storage of the message into the recipient's mailbox. For consumer providers, this is a highly distributed storage system. For on-premises servers, it might be Dovecot or a Microsoft Exchange mailbox store. The recipient's MUA then retrieves the message via IMAP or a proprietary API for display.

When Things Go Wrong: Where Failures Happen

Bounce at SMTP Level

If the receiving server rejects the message during the SMTP handshake (e.g., invalid recipient, blocked IP), the sending MTA generates a bounce notification (NDR) back to the envelope sender. These are 5xx codes for permanent failures (hard bounces) and 4xx codes for temporary failures (soft bounces/deferrals).

Post-Acceptance Filtering

If the server accepts the message (250 OK) but then routes it to spam, there is no bounce notification. From the sending MTA's perspective, the delivery was successful. This is the most frustrating type of deliverability failure because your logs show success while the recipient never sees the message.

Retry and Queue Management

When a sending MTA receives a 4xx temporary failure (common during throttling or graylisting), it places the message in a retry queue. The MTA will attempt redelivery on an exponential backoff schedule, typically trying every 15 minutes, then 30, then 60, up to 24-72 hours before giving up and generating a permanent bounce.

The Full Picture in One Diagram

Here is the complete flow condensed:

1. You click send in your MUA (email client).
2. MUA to MSA: Your client submits the message via authenticated SMTP (port 587/465).
3. MSA to MTA: The submission agent passes the formatted message to the sending MTA.
4. DNS lookup: The sending MTA queries DNS for the recipient domain's MX records.
5. MTA to MTA: The sending MTA connects to the receiving MTA on port 25 and performs the SMTP handshake.
6. TLS negotiation: If supported, the connection is encrypted via STARTTLS.
7. Message transfer: The envelope and message are transmitted. The receiving MTA returns 250 OK.
8. Authentication: The receiving server checks SPF, DKIM, and DMARC.
9. Reputation and filtering: IP/domain reputation, content analysis, engagement signals, and blocklist checks are evaluated.
10. Delivery decision: The message is placed in the inbox, a category tab, spam, or (rarely) silently discarded.
11. MDA to mailbox: The Mail Delivery Agent stores the message.
12. Recipient reads: The recipient's MUA retrieves and displays the message.

The entire process typically completes in 1-5 seconds for a single message. At scale, sending millions of messages involves connection pooling, queue management, IP rotation, and rate limiting to stay within each receiving provider's acceptance thresholds.

Frequently Asked Questions