Lesson 21 — How Email Works: How an Email Reaches the Receiver's Inbox from Sender

At first glance, email seems straightforward: you type some text, hit send, and the recipient reads it.

In computer science, however, an email is a strictly formatted Structured Digital Document (specified under RFC 5322). An email is split into rigorous logical sections:

When you attach a file to an email, the entire bundle travels across the wire as a single structured textual stream.

To understand email architecture, we must distinguish between three distinct software entities:

Suppose Salim sends an email from salim@gmail.com to Rahim at rahim@example.com. Salim uses the Gmail app on his phone or Gmail web on his laptop.

When Salim clicks "Send", his laptop does not open a connection to example.com directly! Instead, his client communicates exclusively with his own authenticated mail service:

The sender-side mail infrastructure accepts the message, verifies Salim's credentials, and takes over full responsibility for discovering the destination server and executing delivery.

SMTP stands for Simple Mail Transfer Protocol (standardized under RFC 5321). It is one of the earliest and most resilient application-layer protocols on the Internet.

Notice that SMTP is used exclusively for pushing mail into servers and between servers. It is never used to retrieve mail down to a user device.

In Lesson 7, we learned how HTTP operates. Both HTTP and SMTP operate at the Application Layer over reliable TCP connections. However, their design philosophies are fundamentally opposite:

When you click "Send", the Message Submission Phase begins:

During submission, two strict security mechanisms occur:

1. Authentication (SASL): The client must prove its identity via username/password or OAuth2 token. A server that accepts submissions without authentication is an "Open Relay"—a vulnerability spammers rapidly exploit.
2. Encrypted Transport: The connection is wrapped in TLS encryption (STARTTLS) so that local Wi-Fi sniffers cannot intercept passwords or message text.

After accepting the message, the sender server parses the recipient address: rahim@example.com:

The segment before the @ is the Local Part (identifying a specific mailbox on the destination server). The segment after is the Domain Name.

The sender server must now solve a critical question: "Where on the global Internet should emails for example.com be delivered?" Enter our faithful friend: DNS!

In Lesson 6, we learned that websites rely on A Records and AAAA Records. For email, DNS features a dedicated record type: MX Record (Mail Exchange).

Domains often operate multiple mail servers to ensure high availability. To coordinate which server should be contacted first, MX records include a Preference / Priority Number:

Salim's sending mail server sends an asynchronous recursive DNS query:

Now the sending server knows exactly which host accepts incoming mail for the destination domain.

No! This is a classic systems engineering interview question.

Therefore, the sending server must immediately perform a second DNS resolution to find the host's actual IP address:

Only after resolving both layers does the sender server have a valid destination IP for TCP socket connection.

With IP 198.51.100.25 in hand, the sender opens a TCP 3-way handshake on Port 25. Once established, the classic SMTP Dialogue unfolds:

Once the receiver returns 250 Ok: queued, custody of the message officially passes to the receiver server.

Let us look at the full delivery flow together for the first time:

Never! This is the most crucial mental model in messaging architecture.

If email required a direct peer-to-peer connection between devices, you could only receive messages when your laptop was turned on, connected to Wi-Fi, and running a listening port with a public IP. Instead, email messages are delivered to an always-on mail server, which acts as a permanent custodian for your messages.

Suppose Salim sends an email on Monday at 10:00 AM. Rahim is boarding a flight and his phone is in Airplane Mode.

Is the email lost? Not at all!

This asynchronous store-and-forward architecture decouples message generation from message consumption.

We know SMTP is used exclusively to send and relay mail. How does the recipient's mail application access the messages sitting in the server's mailbox?

This brings us to Mail Retrieval Protocols. Historically, two primary protocols have powered the Internet:

• IMAP (Internet Message Access Protocol): Modern synchronized server-side mailbox access.
• POP3 (Post Office Protocol version 3): Legacy local download model.

IMAP (RFC 3501 / RFC 9051) is designed around a single master premise: the mailbox lives permanently on the mail server, and all your devices maintain a real-time, bidirectional sync with that central source of truth.

If you lose your phone or replace your laptop, you lose zero messages because all folder structures, flags, and contents remain intact on the server.

POP3 (Post Office Protocol version 3 - RFC 1939) was developed in the 1980s when server storage was exorbitant and users connected intermittently via dial-up modems.

It mirrors a physical post office box: once you take a letter home, the post office box is empty. If you download mail to your office PC via POP3, you won't find it when you check your phone at home. While modern clients support "Leave copy on server", POP3 lacks folder synchronization, flag tracking, and multi-device parity.

Memorize this foundational protocol triad:

Today, millions use mail.google.com or outlook.live.com directly inside a browser without configuring desktop email software.

Does the browser speak SMTP or IMAP directly? No! The browser speaks standard HTTPS.

Webmail is an interactive web application that provides a graphic interface in the browser while coordinating with mail backends via internal services.

This is a foundational distinction in software architecture:

• Email: An independent, decentralized protocol suite and global server network.
• Webmail: A browser-based graphical user interface for interacting with that underlying system.

If all web browsers ceased to exist tomorrow, email would continue operating seamlessly via desktop MUAs, terminal clients, and automated daemons.

In modern chat apps, we expect immediate delivery ticks. But email was designed for an imperfect, distributed world.

A mail server cannot always deliver a message immediately. If the destination server is temporarily unreachable, the sending server holds the message in persistent disk storage known as the Mail Queue:

The real-world Internet faces constant transient failures:

• Destination Server Maintenance: The recipient's mail cluster might be rebooting or updating SSL certificates.
• Network Partitions: Fiber cable damage or temporary routing blips along BGP transit paths.
• Temporary Greylisting: Recipient anti-spam filters often intentionally defer the first delivery attempt from an unfamiliar IP, expecting legitimate mail servers to retry.
• Rate Limiting: High-traffic spikes may cause the destination to throttle incoming connections.

Without queues, any transient network glitch would cause permanent message loss. The mail queue makes email uniquely resilient.

SMTP response status codes determine whether an issue is transient or final:

Most users have received a message reading: "Mail Delivery Subsystem: Delivery Status Notification (Failure)".

Because email lacks a central authority, when an irrecoverable delivery failure occurs, the sender-side mail server synthesizes an automated diagnostic email (Delivery Status Notification / DSN) and drops it in the sender's inbox detailing why the transfer failed.

The real architectural truth of an email lies inside its Headers. Headers serve as an unalterable passport stamped by every immigration checkpoint along the route:

Examine the Received: header. Each MTA prepends its own IP address and timestamp to the top of the message as it forwards it. In cybersecurity forensics, these headers reveal the true origin of spam and phishing attacks.

SMTP was originally conceived in 1982 to transmit 7-bit ASCII text only. Transmitting raw binary images or executables was technically impossible on the early protocol!

To solve this, the Internet community engineered MIME (Multipurpose Internet Mail Extensions - RFC 2045). MIME converts binary files into ASCII text characters using Base64 Encoding and bundles them using unique boundary delimiters:

The receiving MUA parses these boundaries, renders the plain text or HTML part, decodes the Base64 stream back into binary bytes, and displays the familiar "Download Attachment" button.

Now we arrive at the most critical security frontier in email engineering: Authentication & Anti-Spoofing.

Imagine receiving an urgent message:

In reality, the email was sent by a cybercriminal on a rogue server. This attack is known as Email Spoofing.

To eradicate this vulnerability, three modern cryptographic defense layers were built on top of DNS: SPF, DKIM, and DMARC.

SPF (RFC 7208) is an IP-based authorization whitelist published by the domain owner in DNS.

For example, byteion.com publishes the following DNS TXT record:

When an inbound MTA receives a message claiming to be from salim@byteion.com, it inspects the sender's connecting IP address. If the IP is not in 203.0.113.10 or Google's SPF range, the SPF check fails!

No! This is an essential distinction:

• SPF is strictly an Identity Authorization Signal.
• It provides zero encryption or confidentiality for the email body.
• SPF answers only one question: "Is this connecting IP authorized to send for this domain?"

SPF has a fundamental limitation: Email Forwarding. If you forward an email from your university address to your Gmail, the forwarding server's IP is not in the original sender's SPF record, causing legitimate emails to fail SPF.

To solve this, DKIM (RFC 6376) replaces IP checking with Cryptographic Asymmetric Digital Signatures!

In Lesson 8, we explored Public Key Cryptography. DKIM is its direct production application:

If an attacker alters even a single character in transit, the calculated hash will not match the decrypted signature, triggering an immediate DKIM: FAIL. DKIM guarantees both Authenticity and Integrity across any number of forwarding hops.

No! Just like SPF, DKIM does not encrypt the email text. The email body remains readable by anyone intercepting the raw packet stream. DKIM merely signs the text to prove its origin and that it was not tampered with.

Suppose an attacker sends a spoofed email claiming to be your domain, and both SPF and DKIM fail. What should the receiving server do? Quarantine the email in the spam box? Or drop it completely?

This decision is declared by the domain owner via DMARC (Domain-based Message Authentication, Reporting, and Conformance - RFC 7489)!

Here, p=reject instructs receiving servers: "If an email claims to be from my domain but fails authentication, reject and drop it immediately." Furthermore, rua= causes receiving providers to send daily aggregated XML reports documenting every unauthorized IP attempting to impersonate your domain.

In modern enterprise email, these three technologies function as a coordinated defense shield:

When properly configured, this trinity makes corporate domain impersonation virtually impossible.

Notice how DNS has surfaced in almost every major topic of Course 08. It is far more than an IP phonebook:

DNS serves as the decentralized identity and security substrate of the entire global Internet.

Let us trace the complete lifecycle from Salim (salim@company-a.com) to Rahim (rahim@company-b.com):

In Lesson 5, we examined the Transport Layer. Email protocols are uncompromisingly anchored in TCP:

• SMTP (Ports 25, 587, 465): Relies on TCP 3-way handshakes, sequence numbers, and packet acknowledgments. A single dropped packet could corrupt financial data or legal correspondence.
• IMAP (Ports 143, 993): Persistent TCP connections allow servers to push notifications to active client sockets.
• POP3 (Ports 110, 995): TCP streams guarantee byte-for-byte fidelity during mailbox downloads.

Lesson 8's TLS is heavily utilized in modern email via the STARTTLS command, upgrading plaintext channels to encrypted sessions.

Yes! Cryptographically, they share the identical foundation:

• Servers present X.509 digital certificates signed by public Certificate Authorities.
• Clients verify certificate chains against root CA trust stores.
• Diffie-Hellman key exchanges negotiate ephemeral symmetric AES session keys.

The difference is solely at the Application Layer: web uses HTTP over TLS, while email uses SMTP over TLS or IMAP over TLS.

An enterprise mail server is not a single executable, but a coordinated micro-ecosystem of specialized software daemons:

A small business can host all these components on a single Linux VPS. But at global consumer scale (Google, Microsoft), the topology transforms into a massive distributed system:

As established in Lesson 18: "A server is a network role, not a physical chassis."

In Lesson 17, we explored Message Queues and Background Workers. In real-world software architecture, email dispatch is the quintessential use case for asynchronous queueing!

Imagine a user clicks "Sign Up" or "Reset Password" on your website. If your web backend synchronously establishes an SMTP connection across the Internet before answering the HTTP request, what happens?

Production systems decouple this immediately: the web server pushes an asynchronous task onto a fast in-memory queue (Redis, RabbitMQ) and returns an HTTP 201 response in under 10 milliseconds.

Here is how modern SaaS applications dispatch onboarding emails reliably at scale:

In application engineering, email divides into two distinct worlds. The first is Transactional Email:

Key characteristics: Single recipient, urgent priority, high delivery speed expectation (<10 seconds), and near-100% inbox placement requirement.

The second category is Marketing Email (newsletters, feature announcements, promotions).

While transactional emails send one message at a time, marketing campaigns blast 1,000,000 emails concurrently. This demands unique engineering disciplines:

• IP Warm-Up: Blasting 1,000,000 emails from a brand-new IP address triggers instant blacklisting by Gmail and Microsoft. Sending volumes must ramp up gradually over 30 days.
• Mandatory One-Click Unsubscribe (RFC 8058): Requires List-Unsubscribe-Post headers to prevent spam complaints.
• Automated Bounce Pruning: Immediate removal of bounced addresses to prevent domain reputation degradation.

A fundamental reality of email infrastructure:

Major email providers (Gmail, Outlook) run sophisticated reputation algorithms. Even after an MTA returns 250 OK, it evaluates continuous signals:

Because email was designed on an open, trusting network, yet today it is the primary vector for ransomware distribution, credential phishing, and Business Email Compromise (BEC) attacks totaling billions in losses.

Modern email defense is a 24/7 battle involving asymmetric cryptography, machine learning heuristic classifiers, IP reputation blocklists (DNSBL), and continuous domain policy monitoring.

Suppose you register byteion.com and want to operate professional addresses like hello@byteion.com. You must configure four pillars in your DNS management console:

This decoupling is the cornerstone of modern cloud email:

You maintain sovereign ownership of your brand and domain name, while delegating the complex physical realities of spam filtering, storage replication, and server uptime to specialized providers (Google Workspace, Microsoft 365, Fastmail, Proton).

A global-scale email provider operates across several tiers:

• Multi-Region Anycast Edge Clusters: PoPs on every continent absorbing volumetric DDoS attacks and terminating inbound TLS sessions.
• Redundant MX Priority Routing: Secondary data centers that automatically accept mail if primary facilities suffer outages.
• Sharded Queue Topologies: Resilient distributed queues ensuring zero message loss during peak holiday shopping seasons.

In Lesson 16, we studied Inverted Indexes and Search Engines.

When you have 500,000 emails accumulated over a decade and search for invoice 2024, Gmail does not sequentially grep 500,000 files on disk!

Every incoming message is tokenized upon arrival and added to high-speed inverted indexes.

The separation of concerns between relational storage and object storage (from Lesson 16) is fully applied here:

Separating lightweight metadata from binary payloads keeps databases lightning fast and slashes storage costs.

Observe how email seamlessly maps to the 5-layer Internet model established in Lesson 1:

In Lesson 6, we called DNS the Internet's directory. Today, observe how a single domain name (byteion.com) projects multiple distinct personas across the Internet:

DNS is the universal directory enabling different application systems to route traffic independently under one unified identity.

In Lessons 18 and 19, we followed the evolution of physical servers into VMs and containers. Today, we saw that when we say "Mail Server", we are referring to an architectural system:

Today we discovered that an email is far more than a simple message. It is the Internet's premier decentralized distributed application. From sender client submission to recipient inbox rendering, a single email coordinates enterprise infrastructure, DNS lookups, cryptographic validations, asynchronous queues, and automated retry mechanisms across global networks.

At the start of Course 08, we asked: "What is the Internet?" We defined it as a "Network of Networks".

After conquering 21 comprehensive engineering lessons, you understand how the modern computing world operates:

The Internet is not a single monolith. It is a shared global substrate upon which the Web, Email, APIs, Streaming, and all digital communications are constructed.