A step-by-step guide to how email travels from your mail client to its destination — and where things can go wrong.
When you click Send on an email, you might imagine your message flying directly from your computer to the recipient's inbox. The reality is considerably more complex. A single email typically passes through three to six distinct servers, each performing a specific role in the delivery chain. Understanding this chain is the foundation of diagnosing email delivery problems — and it explains why an email can take minutes, hours, or occasionally even days to arrive.
SMTP stands for Simple Mail Transfer Protocol. Defined in RFC 5321 (and its predecessor RFC 2821), SMTP is the standard protocol for transferring email between servers. It operates over TCP, traditionally on port 25 for server-to-server mail and port 587 (submission) or port 465 (submission with implicit TLS) for mail client to server connections. Despite being a protocol designed in the early 1980s, SMTP remains the backbone of global email infrastructure today, extended over the decades by ESMTP (Extended SMTP) to add authentication, encryption negotiation, and size limits.
Every email delivery involves up to five distinct components, each with a defined role:
1. Mail User Agent (MUA) — This is your email client: Gmail's web interface, Microsoft Outlook, Apple Mail, Thunderbird, or any mobile app you use to compose and read email. The MUA is responsible for composing the message, formatting it as a MIME-encoded email with headers and body, and submitting it to your outgoing mail server. The MUA writes the initial From:, To:, Subject:, Date:, and Message-ID: headers.
2. Mail Submission Agent (MSA) — When you click Send, your MUA connects to your email provider's outbound SMTP server — the MSA. This is typically smtp.gmail.com, smtp.office365.com, or your corporate mail server. The MSA authenticates you (using your username and password over an encrypted connection on port 587 or 465), accepts the message, and queues it for forwarding. The MSA may perform initial spam checks and enforce sender policy before accepting the message.
3. Sending MTA (Mail Transfer Agent) — The MSA hands the queued message to the sending MTA, which is responsible for routing the message to the recipient's mail server. The MTA performs a DNS lookup for the recipient domain's MX (Mail Exchanger) records to find the address of the receiving mail server. MX records are prioritized — the MTA tries the highest-priority (lowest preference number) MX server first. If that server is unavailable, it falls back to the next-priority MX record.
4. Receiving MTA — The recipient domain's inbound mail server accepts the incoming SMTP connection. Before accepting the message, the receiving MTA typically performs several checks: it verifies the sender's IP against SPF records, checks whether the IP is on any DNS blocklists (DNSBLs), runs anti-spam content analysis, and may perform greylisting for first-time senders. If the message passes all checks, the receiving MTA accepts it and passes it to the final delivery stage.
5. Mail Delivery Agent (MDA) — The MDA performs the final step: placing the message in the recipient's mailbox. The MDA uses LMTP (Local Mail Transfer Protocol) for delivery within a single mail system. Once the MDA has written the message to the mailbox store, delivery is complete and the recipient's email client can retrieve it via IMAP or POP3.
The DNS MX record system is what makes global email routing possible without any central directory. When the sending MTA needs to deliver a message to user@example.com, it queries DNS for the MX records of the example.com domain. DNS returns a list of mail server hostnames with priority values. Lower priority numbers indicate higher preference. For example:
The sending MTA first attempts delivery to mail1.example.com (priority 10). If that connection fails or times out, it tries mail2.example.com (priority 20), then the backup. This redundancy is why email delivery can survive a primary mail server outage — at the cost of some delay.
Modern SMTP connections between servers use TLS (Transport Layer Security) to encrypt the message in transit. There are two mechanisms: STARTTLS (opportunistic TLS, where an unencrypted connection upgrades to TLS after initial negotiation) and Implicit TLS (where TLS is established immediately on connection, used on port 465). The "with" field in a Received: header reveals which was used: ESMTP indicates no encryption or STARTTLS negotiation; ESMTPS indicates TLS-encrypted; ESMTPSA indicates authenticated and TLS-encrypted.
When a TLS handshake fails — due to an expired certificate, a certificate mismatch, or a protocol incompatibility — the servers must decide whether to fall back to unencrypted delivery or reject the connection entirely. This failure and fallback can add 10–30 seconds of latency per attempt, and if repeated across retry cycles, it can account for significant delays in the Received: chain.
Large organizations typically deploy dedicated email security gateways between the internet and their internal mail servers. Common products include Proofpoint, Mimecast, Barracuda, Cisco IronPort, and Microsoft Defender for Office 365. These gateways intercept all inbound and outbound mail and apply policy rules: content filtering, attachment scanning, URL rewriting, data loss prevention (DLP) checks, and quarantine workflows. When a message triggers a policy rule, the gateway holds it for review — which can mean delays of 30 minutes to 24 hours or more, depending on the organization's approval workflows.
In the Received: header chain, a corporate gateway usually appears as a hop with a hostname containing words like "gateway," "filter," "proxy," "inbound," or the gateway vendor's name. A large time delta at a gateway hop is the hallmark of a policy-based delay.
Reading the Received: chain bottom-up (or using WhyIsMyEmailLate to read it top-down chronologically) gives you the complete routing path of your message. Each hop reveals: which server sent, which server received, what protocol was used, and when the handoff occurred. The delta between consecutive timestamps is the time spent processing at that hop. A normal SMTP handoff takes under one second. A TLS handshake adds one to five seconds. Spam scanning adds two to sixty seconds. Greylisting adds five to fifteen minutes. A policy hold can add hours. Any of these patterns — once you know what to look for — turns a cryptic block of mail infrastructure text into a clear diagnostic story.