How Email Works: A Complete Technical Guide to Protocols, Steps, and Architecture

Email remains the backbone of digital communication for businesses and individuals alike, yet its underlying mechanics are poorly understood by most of its users. At its core, email delivery is a multi-stage relay process governed by a precise chain of protocols — SMTP for transmission, DNS MX records for routing, and IMAP or POP3 for retrieval — each executing in sequence to move a message from a sender's client to a recipient's inbox in seconds.

Understanding this architecture is not merely academic. System administrators, developers, and anyone managing a mail environment must grasp how these components interact to diagnose delivery failures, harden security posture, configure servers correctly, and avoid the spam folder. This guide covers the complete technical picture, including the edge cases and failure modes that introductory articles consistently omit.

Key Components of the Email Infrastructure

Before tracing the lifecycle of a single email, it is essential to identify the discrete systems involved. Each plays a non-negotiable role, and a misconfiguration in any one of them can silently break delivery.

Email Client (MUA — Mail User Agent)

The Mail User Agent (MUA) is the interface through which a user composes, sends, and reads email. Examples include Microsoft Outlook, Apple Mail, Mozilla Thunderbird, and browser-based clients like Gmail's web interface. The MUA does not deliver email directly to the recipient. Its job is to hand the message off to a Mail Submission Agent (MSA), typically running on port 587 with authentication, which then passes it to the outbound SMTP server.

A common architectural misunderstanding is treating the MUA and the SMTP server as a single unit. They are not. The MUA is a client; the SMTP infrastructure is the transport layer.

Mail Server (MTA — Mail Transfer Agent)

The Mail Transfer Agent (MTA) is the server software responsible for relaying email between systems. Postfix, Exim, Sendmail, and Microsoft Exchange are the most widely deployed MTAs. An MTA can act as both a sender and a receiver, depending on the direction of the transaction. It is the MTA that performs DNS lookups, establishes SMTP connections to remote servers, and queues messages for retry when delivery fails.

Mail Delivery Agent (MDA)

Often overlooked in simplified explanations, the Mail Delivery Agent (MDA) is the component that takes a message accepted by the receiving MTA and places it into the correct user's mailbox on disk. Dovecot and Courier are common MDAs. The MDA enforces mailbox quotas, applies server-side filtering rules (Sieve scripts), and writes the message to the appropriate storage format (Maildir or mbox).

DNS and MX Records

The Domain Name System is the routing backbone of email. Without a valid MX (Mail Exchange) record, no external server can locate where to deliver mail for a given domain. MX records carry a priority value — lower numbers indicate higher priority — allowing administrators to configure primary and fallback mail servers. The sending MTA queries MX records, then resolves the resulting hostname to an IP address via an A or AAAA record before initiating a connection.

The Email Delivery Process: Step-by-Step

Step 1: Message Composition and Submission

The user writes a message in their MUA, specifying the recipient address, subject line, body content, and any attachments. Attachments and HTML content are encoded using MIME (Multipurpose Internet Mail Extensions), which wraps binary data in a base64-encoded format safe for transmission over text-based SMTP. A message with a PDF attachment, for example, is split into multiple MIME parts: one for the text body and one for the encoded binary.

When the user clicks "Send," the MUA opens an authenticated, encrypted connection to the outbound mail server — typically on port 587 (STARTTLS) or port 465 (SMTPS). Authentication via SASL (Simple Authentication and Security Layer) prevents unauthorized relay abuse.

Step 2: SMTP Handshake and Message Transfer

The sending MTA initiates an SMTP session with a formal handshake:

1. The client sends `EHLO` (Extended HELO), identifying itself by hostname.
2. The server responds with its capabilities (e.g., STARTTLS, AUTH, SIZE limits).
3. The client issues `MAIL FROM:<sender@domain.com>` to declare the envelope sender.
4. The client issues `RCPT TO:<recipient@domain.com>` to declare the recipient.
5. The client sends `DATA`, followed by the full message headers and body.
6. The session closes with `QUIT`.

This SMTP dialogue is the same whether the connection is between a client and its submission server, or between two MTAs relaying mail across the internet.

Step 3: DNS Resolution and MX Lookup

Before the sending MTA can connect to the recipient's server, it must resolve the destination. The process follows a strict sequence:

1. Query DNS for MX records of the recipient's domain (e.g., `example.com`).
2. Receive one or more MX records, each with a hostname and priority value.
3. Resolve the MX hostname to an IP address via an A record (IPv4) or AAAA record (IPv6).
4. Attempt connection to the highest-priority (lowest-number) MX host first.

Critical edge case: If no MX record exists for a domain, RFC 5321 specifies that the sending MTA should fall back to the domain's A record and attempt delivery directly. This behavior is often exploited in misconfigured domains and can lead to unexpected delivery paths. Additionally, if the MX record points to a CNAME, this violates RFC 2181 and can cause delivery failures with strict MTAs.

Step 4: Server-to-Server SMTP Relay

Once the IP address is resolved, the sending MTA establishes a TCP connection on port 25 to the recipient's MTA. Port 25 is reserved for server-to-server communication and is typically blocked by ISPs for residential connections to prevent spam originating from consumer IP ranges.

In enterprise and cloud environments, email may traverse multiple relay hops before reaching its destination. Each relay adds a `Received:` header to the message, creating a traceable audit trail. Examining these headers is the primary method for diagnosing delivery delays and identifying where a message was held or rejected.

STARTTLS opportunistic encryption is negotiated at this stage if both servers support it. If the receiving server does not advertise STARTTLS, most MTAs will fall back to unencrypted transmission rather than fail delivery — a known security weakness that MTA-STS (Mail Transfer Agent Strict Transport Security) is designed to address by enforcing encrypted connections.

Step 5: Acceptance, Filtering, and Spam Evaluation

When the receiving MTA accepts the message, it does not immediately place it in the user's inbox. A series of checks occur:

• SPF (Sender Policy Framework): The receiving server queries the sender's domain DNS for a TXT record listing authorized sending IP addresses. If the sending IP is not listed, the SPF check fails.
• DKIM (DomainKeys Identified Mail): The sending server cryptographically signs the message headers and body with a private key. The receiving server retrieves the corresponding public key from DNS and verifies the signature. A valid DKIM signature proves the message was not altered in transit.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Ties SPF and DKIM together. The domain owner publishes a DMARC policy specifying what to do with messages that fail authentication — `none` (monitor only), `quarantine` (send to spam), or `reject` (discard the message). DMARC also enables aggregate and forensic reporting.

After authentication checks, the message passes through content filtering and spam scoring engines (SpamAssassin, Rspamd, or proprietary systems). Scores are assigned based on header anomalies, blacklist lookups (RBLs/DNSBLs), content patterns, and sender reputation. Messages exceeding the threshold are routed to the junk folder or rejected outright.

Step 6: Mailbox Storage and Retrieval

Messages that pass all filters are handed to the MDA, which writes them to the user's mailbox. The two dominant storage formats are:

• Maildir: Each message is stored as an individual file in a directory structure. Preferred for its resilience — a corrupt message does not affect others.
• mbox: All messages in a folder are concatenated into a single file. Simpler but prone to corruption and locking issues under concurrent access.

The recipient's email client then retrieves the message using either IMAP or POP3.

Step 7: Client Retrieval via IMAP or POP3

The final leg of delivery is the client pulling the message from the mailbox server. The choice of protocol has significant operational implications.

IMAP vs. POP3 vs. SMTP: Protocol Comparison

IMAP is the correct choice for virtually all modern deployments. It keeps messages on the server, synchronizes read/unread state, folder structure, and flags across every connected device in real time. Deleting a message on a phone is immediately reflected in the desktop client.

POP3 downloads messages to the local device and, by default, removes them from the server. This made sense in the era of single-device access and limited server storage, but it creates serious problems in multi-device environments and eliminates server-side backup. POP3 should be considered a legacy protocol for new deployments.

Email Security Architecture: SPF, DKIM, and DMARC in Depth

These three mechanisms form a layered authentication stack. Deploying only one or two of them leaves exploitable gaps.

SPF — Envelope-Level Authorization

SPF validates the envelope sender (the `MAIL FROM` address used in the SMTP dialogue, not the `From:` header visible to users). A typical SPF record looks like:

“`

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

“`

The `~all` softfail allows messages from unlisted IPs to be accepted but flagged. The `-all` hardfail instructs receiving servers to reject them outright. SPF alone does not protect the visible `From:` header, which is what users actually see — this is why DMARC is required.

DKIM — Cryptographic Message Integrity

DKIM signs a defined set of headers (typically `From`, `To`, `Subject`, `Date`) and a hash of the message body. The signature is embedded in a `DKIM-Signature:` header. The selector and domain in that header point to a DNS TXT record containing the public key. If the message is modified after signing — even a single character in the body — the signature verification fails.

Important operational note: Mailing list software and some forwarding configurations modify message content (appending footers, rewriting headers), which breaks DKIM signatures. This is a known interaction between DKIM and mailing list managers that requires careful configuration.

DMARC — Policy Enforcement and Alignment

DMARC introduces the concept of identifier alignment: the domain in the `From:` header must align with either the SPF-authenticated domain or the DKIM-signing domain. This closes the gap that SPF alone leaves open. A `reject` policy is the strongest configuration:

“`

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=s

“`

`adkim=s` and `aspf=s` enforce strict alignment, requiring an exact domain match rather than organizational domain matching.

Advanced Topics: MTA-STS, DANE, and ARC

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS allows a domain to publish a policy via HTTPS declaring that inbound connections must use TLS and specifying which certificates are acceptable. Unlike STARTTLS, which is opportunistic and can be stripped by a man-in-the-middle attacker, MTA-STS enforces encryption. Sending MTAs that support MTA-STS cache the policy and refuse to deliver to a server that cannot satisfy it.

DANE (DNS-Based Authentication of Named Entities)

DANE uses DNSSEC-signed TLSA records to bind a specific TLS certificate or public key to a mail server hostname. This eliminates reliance on the commercial Certificate Authority trust model for server authentication. DANE adoption is growing in European government and financial sectors but remains limited in mainstream deployments due to the prerequisite of DNSSEC on both the sending and receiving domain.

ARC (Authenticated Received Chain)

ARC was developed to solve the forwarding problem that breaks DMARC. When a message is forwarded through an intermediary (such as a mailing list or an email alias), the original SPF and DKIM alignment may be broken. ARC preserves a chain of authenticated `Received:` headers, allowing the final receiving server to evaluate the authentication state at each hop and make a more informed delivery decision.

Common Email Delivery Failures and Diagnosis

Understanding the architecture makes troubleshooting systematic rather than speculative.

Symptom: Email bounces with "550 5.7.1 Message rejected"

• Cause: SPF hardfail, DMARC rejection, or IP blacklisting.
• Diagnosis: Check the bounce message for the specific rejection reason. Run `dig TXT yourdomain.com` to inspect SPF. Query MX Toolbox or similar for blacklist status.

Symptom: Email delivered to spam folder

• Cause: SPF softfail, missing DKIM, low sender reputation, or content triggers.
• Diagnosis: Examine the `X-Spam-Status` header in the received message. Verify DKIM signing is active. Check that PTR (reverse DNS) record for the sending IP matches the SMTP EHLO hostname.

Symptom: Email delayed with "451 Temporary failure"

• Cause: Receiving server is temporarily unavailable or rate-limiting the sender.
• Diagnosis: The sending MTA will queue and retry automatically per its retry schedule. Check MTA logs for the retry queue. Persistent 451 errors from major providers often indicate IP reputation issues.

Symptom: DKIM signature fails despite correct DNS record

• Cause: Message modified in transit (mailing list footer appended, header rewritten by relay).
• Diagnosis: Use a DKIM verification tool on the raw message source. Check if the `h=` tag in the DKIM-Signature header includes headers that were modified.

Email Architecture for Hosted Environments

For businesses and developers deploying their own mail infrastructure, the hosting environment directly affects deliverability and security. A VPS Hosting environment gives full control over MTA configuration, PTR records, and IP reputation — factors that shared environments cannot provide. Running Postfix or Exim on a VPS allows precise tuning of rate limits, TLS policies, and authentication mechanisms.

Organizations requiring high-volume transactional email or complete isolation from neighboring tenants benefit from Dedicated Servers, where the sending IP is exclusively assigned and not shared with other customers. IP reputation on a dedicated server is entirely within the operator's control.

For smaller operations that do not require a self-managed MTA, Email Hosting provides a fully managed mail environment with pre-configured SPF, DKIM, and DMARC, removing the operational burden of maintaining mail server software.

Securing webmail and mail client connections requires valid TLS certificates. Self-signed certificates generate client warnings and can cause authentication failures in strict MUA configurations. Deploying trusted SSL Certificates on mail server hostnames (e.g., `mail.yourdomain.com`) is a non-negotiable baseline for any production mail environment.

Domain configuration is equally foundational. MX records, SPF TXT records, DKIM TXT records, and DMARC TXT records all live in DNS. Accurate and reliable DNS management through a Domain Registration provider with a robust DNS editor is essential for maintaining correct mail routing and authentication records.

Email Header Analysis: Reading the Audit Trail

Every email carries a set of headers that document its complete journey. These are prepended in reverse chronological order — the topmost `Received:` header is the most recent hop. A typical header chain looks like:

“`

Received: from mail.example.com (mail.example.com [203.0.113.10])

by mx.google.com with ESMTPS id …

for <recipient@gmail.com>; Mon, 10 Jun 2024 09:15:32 -0700

Received: from [192.168.1.5] (dynamic-pool.isp.net [98.76.54.32])

by mail.example.com with ESMTPSA id …

for <recipient@gmail.com>; Mon, 10 Jun 2024 09:15:29 -0700

“`

Key headers for diagnostics:

• `Return-Path:` — The envelope sender address used for bounce notifications. Must align with SPF.
• `Authentication-Results:` — Added by the receiving server, documents the outcome of SPF, DKIM, and DMARC checks.
• `X-Originating-IP:` — Often added by webmail services to record the client's IP address.
• `Message-ID:` — A globally unique identifier assigned by the originating MTA. Used to correlate log entries across servers.
• `MIME-Version:` and `Content-Type:` — Define the MIME structure of the message body.

Technical Decision Matrix and Key Takeaways

Use this checklist when configuring or auditing a mail environment:

DNS and Routing

• MX records are published with correct priority values and point to valid hostnames, not CNAMEs
• A/AAAA records for MX hostnames resolve correctly
• PTR (reverse DNS) record for the sending IP matches the SMTP EHLO hostname

Authentication Stack

• SPF TXT record published with `-all` or `~all` and covers all legitimate sending sources
• DKIM keys are 2048-bit minimum; selector is published in DNS and signing is active on the MTA
• DMARC policy is published with at minimum `p=quarantine`; aggregate reporting (`rua`) is configured
• DMARC alignment mode is set to `s` (strict) for high-security domains

Transport Security

• STARTTLS is enabled on all inbound and outbound SMTP connections
• MTA-STS policy is published if strict TLS enforcement is required
• Valid, CA-signed TLS certificate is installed on the mail server hostname

Receiving Configuration

• IMAP is used over POP3 for all multi-device deployments
• IMAP over SSL/TLS on port 993 is enforced; plaintext port 143 is disabled or restricted
• Server-side spam filtering (Rspamd or SpamAssassin) is configured with current rulesets

Operational Monitoring

• DMARC aggregate reports are reviewed regularly to detect unauthorized senders
• MTA queue is monitored for deferred messages indicating delivery issues
• Sending IP is checked against major RBLs (Spamhaus ZEN, Barracuda, SORBS) on a scheduled basis

FAQ

What is the difference between SMTP port 25, 465, and 587?

Port 25 is used exclusively for server-to-server MTA relay and is blocked by most ISPs for end users. Port 587 is the designated submission port for authenticated client-to-server connections and uses STARTTLS for encryption negotiation. Port 465 is the legacy SMTPS port that wraps the entire SMTP session in SSL/TLS from the start; it was briefly deprecated but is now formally re-assigned for authenticated submission with implicit TLS under RFC 8314.

Why does my email pass SPF but still fail DMARC?

DMARC requires identifier alignment between the authenticated domain and the `From:` header domain. SPF authenticates the envelope sender (`MAIL FROM`), which can differ from the visible `From:` header. If those domains do not align (under the configured alignment mode), DMARC fails even when SPF passes. The fix is to ensure the `From:` header domain matches the SPF-authenticated domain, or to configure DKIM signing with the `From:` domain so that DKIM alignment satisfies DMARC instead.

What causes a valid DKIM signature to fail verification at the receiving server?

The most common causes are: the message body or signed headers were modified in transit (mailing list footers, header rewriting by relays); the DNS TXT record for the DKIM selector was deleted or changed after signing; or the public key in DNS does not match the private key used to sign the message. Always verify using the raw message source, not a forwarded copy.

What is the practical difference between IMAP and POP3 for a business environment?

IMAP synchronizes the full mailbox state — read/unread flags, folder structure, sent items, drafts — across every device in real time, with messages remaining on the server. POP3 downloads messages to one device and removes them from the server by default, making it impossible to access those messages from a second device. For any business with employees accessing email on more than one device, POP3 creates data silos and eliminates server-side message retention. IMAP is the only appropriate choice.

How do I diagnose why a legitimate email was delivered to the spam folder?

Retrieve the raw message source from the spam folder and examine the `Authentication-Results:` header to check SPF, DKIM, and DMARC outcomes. Look for `X-Spam-Status:` or `X-Spam-Score:` headers added by the receiving server's filter to identify which rules triggered. Verify that the sending IP has a matching PTR record, is not listed on any RBL, and that the sending domain has a complete authentication stack. A missing or failing DKIM signature combined with a neutral SPF result is the most frequent cause of legitimate mail being scored as spam.