Email Architecture: The Foundation of Electronic Messaging

When you click "Send" on an email, you initiate a remarkable journey through the global Internet infrastructure. Within seconds—or sometimes milliseconds—your message traverses networks, passes through multiple servers, undergoes security checks, and arrives in your recipient's inbox. This apparent simplicity masks a sophisticated multi-stage process involving numerous protocols, components, and decisions.

Understanding mail flow is essential for anyone operating email infrastructure, troubleshooting delivery issues, or designing systems that integrate with email. Each stage presents opportunities for filtering, logging, security enforcement, and potential failure. Knowing where to look when mail doesn't arrive, understanding why legitimate mail ends up in spam folders, and designing reliable email-based workflows all require mastery of the complete message journey.

This page traces an email's complete path from the moment a user composes it until the recipient reads it, examining every component interaction, protocol exchange, and potential failure point.

Email flow follows the store-and-forward model—messages are stored at each hop before being forwarded to the next. This fundamental architecture choice ensures reliability: even if the next server is temporarily unavailable, the message is safely queued for later delivery.

The complete mail flow consists of these major stages:

Timing Characteristics:

Mail flow timing varies dramatically based on conditions:

The mail flow begins when a user composes a message in their Mail User Agent (MUA). While seemingly straightforward, the composition stage involves significant processing as the MUA constructs a properly formatted message.

User Actions During Composition:

• Entering recipient addresses (To, Cc, Bcc)
• Writing subject line
• Composing message body (plain text and/or HTML)
• Attaching files
• Setting priority, read receipts, or other options
• Saving drafts during composition

MUA Responsibilities During Composition:

When the user clicks "Send," the MUA initiates an SMTP connection to the configured Mail Submission Agent (MSA) on port 587. This submission stage authenticates the sender and validates the message before it enters the mail transfer system.

Submission Flow Steps:

MSA Processing:

The MSA performs critical validation before accepting the message:

Authentication Verification:

• Verify submitted credentials against user database (LDAP, database, etc.)
• Check that authenticated user is authorized to send as specified sender
• Rate-limit per-user to prevent abuse

Message Validation:

• Syntax check of envelope addresses
• Message format compliance (RFC 5322)
• Size limit enforcement
• Attachment type restrictions (organizational policy)

Header Processing:

• Add Received header documenting receipt
• Add/verify Message-ID if missing
• Add Date header if missing
• Strip Bcc header from message content
• May add X-Originating-IP for tracking

Signing:

• DKIM signature computation and addition (if configured)
• Organization digital signature (if required)

After the MSA accepts the message, it enters the Mail Transfer Agent's queue. The MTA must now determine where to send the message—a process dependent on DNS MX (Mail Exchanger) record lookups.

Routing Algorithm:

For each recipient domain, the sending MTA follows this logic:

Routing Edge Cases:

Multiple Recipient Domains: When a message has recipients in multiple domains, the MTA must route separately to each domain. The message is duplicated and delivered to each domain's MX independently.

Sender Domain Considerations:

• MTA checks sender domain has valid MX or A record (rejectability)
• Some receivers verify sender can receive bounces

MX Record Edge Cases:

Null MX (RFC 7505):

Domains that never receive email can advertise this fact:

example.com. IN MX 0 .

The single dot (.) as the MX target with priority 0 explicitly indicates "this domain does not accept mail." Compliant senders immediately generate bounces rather than attempting delivery.

With the destination MX resolved, the sending MTA initiates an SMTP connection to the receiving MTA on port 25. This server-to-server transfer differs from submission in authentication expectations and represents the core internet mail relay function.

SMTP Transfer Characteristics:

No Authentication (Typically): Unlike submission on port 587, MTA-to-MTA transfer on port 25 traditionally does not require SMTP AUTH. Any server may attempt to deliver mail to an MX. This openness is fundamental to email's distributed architecture but creates spam challenges.

TLS Opportunistic (STARTTLS): Modern MTAs negotiate TLS when available:

• Sender offers STARTTLS
• Receiver advertises STARTTLS support
• If both support, connection upgrades to encrypted
• If receiver doesn't support, sender may proceed unencrypted or defer

Received Headers:

Each MTA adds a "Received" header documenting the hop. These headers create an audit trail:

Received: from mail.sender.com (mail.sender.com [198.51.100.10])
    by mx1.recipient.com (Postfix) with ESMTPS id 8A3C4D5E6F
    for <bob@recipient.com>; Mon, 17 Jan 2026 12:30:05 +0530

Multi-Hop Scenarios:

Messages may traverse multiple MTAs:

• Internal relay servers within organizations
• Border gateways before internal mail systems
• Backup MX holding mail for unavailable primary
• Email service providers handling customer domains

Each hop adds latency and a Received header, creating traceable delivery paths.

Response Codes:

Before accepting a message, the receiving MTA performs extensive security and policy checks. This filtering stage determines whether mail reaches the inbox, spam folder, quarantine, or is rejected outright.

Filtering Occurs at Multiple Points:

1. Pre-DATA Checks — Before message content is transmitted
2. Post-DATA Checks — After full message is received
3. Post-Queue Checks — After acceptance, before final delivery

SPF, DKIM, DMARC Verification Flow:

Received message: From: alice@sender.com

1. SPF Check:
   Query: sender.com TXT record
   Result: v=spf1 mx ip4:198.51.100.0/24 -all
   Connecting IP: 198.51.100.10
   Verdict: PASS (IP in authorized range)

2. DKIM Check:
   Signature selector: "default"
   Query: default._domainkey.sender.com TXT
   Result: v=DKIM1; k=rsa; p=MIGfMA0...
   Signature verification: VALID
   Verdict: PASS

3. DMARC Check:
   Query: _dmarc.sender.com TXT
   Result: v=DMARC1; p=reject; adkim=s; aspf=s
   SPF alignment: PASS (From domain matches envelope)
   DKIM alignment: PASS (From domain matches signed domain)
   Verdict: PASS

Final authorization: ACCEPT (all checks passed)

Filtering Outcomes:

After passing all filters, the message reaches the Mail Delivery Agent (MDA) for final delivery to the recipient's mailbox. This local delivery stage performs final processing and persistent storage.

MDA Invocation Methods:

The MTA hands off messages to the MDA through several possible mechanisms:

MDA Processing Steps:

1. User Resolution:

   • Look up recipient address in directory (LDAP, database, passwd)
   • Resolve aliases and forwards
   • Determine mailbox location

2. Quota Checking:

   • Check user's storage quota
   • Reject or defer if quota exceeded
   • May notify user of quota status

3. Sieve Filtering:

   • Execute user's Sieve filter scripts
   • File to folders based on rules
   • Forward copies as configured
   • Set flags, vacation responses

4. Final Delivery:

   • Write message to mailbox format (Maildir, mbox, database)
   • Update mailbox indexes
   • Set new message flag
   • Trigger push notifications

Mailbox Storage Formats:

Maildir Format:

/var/mail/vhosts/recipient.com/bob/
├── cur/           # Read messages
│   └── 1737105010.V802I....:2,S
├── new/           # Unread messages (just delivered)
│   └── 1737105610.V802I...
├── tmp/           # Temporary during delivery
├── dovecot.index
├── dovecot.index.cache
└── dovecot.index.log

dbox/mdbox (Dovecot optimized):

• Multiple messages per file
• Better performance for large mailboxes
• Metadata in separate index files
• Dovecot-specific format

Database Storage:

• Messages stored as database records
• Enables sophisticated querying
• Common in webmail-focused systems
• Requires database administration

The final stage occurs when the recipient checks their email. The Mail User Agent connects to the Mail Access Agent (IMAP/POP3 server) to retrieve and display the delivered message.

Retrieval Initiation:

Retrieval may be triggered by:

• User manually checking email
• Scheduled polling (every N minutes)
• IMAP IDLE push notification of new mail
• Mobile push notification triggering app fetch

Push Notification Flow:

Modern mobile email delivery often involves push notifications:

1. IMAP IDLE: Client maintains persistent connection; server pushes new message notification
2. Proprietary Push (Gmail, Outlook): Server sends push via platform services (APNs, FCM); app wakes and fetches
3. Exchange ActiveSync: Server pushes notification indicating new mail; client syncs changed items

Complete Message Journey Summary:

Alice's message to Bob traversed:

1. Alice's MUA → MSA (submission, port 587, authenticated)
2. Sender MTA → DNS (MX lookup for recipient.com)
3. Sender MTA → Recipient MTA (transfer, port 25)
4. Recipient filters (SPF, DKIM, DMARC, spam, virus)
5. Recipient MTA → MDA (local delivery via LMTP)
6. MDA → Mailbox (written to Maildir/INBOX)
7. MAA → Bob's MUA (retrieved via IMAP, port 993)

When mail doesn't arrive as expected, understanding how to trace its path through logs is an essential skill for email administrators and developers.

Key Log Locations:

Tracing by Message-ID:

Every message has a unique Message-ID header. Searching logs for this ID reveals the complete path:

# Find all log entries for a specific message
grep "550e8400-e29b-41d4-a716" /var/log/mail.log

# Postfix queue ID correlation
grep "4F7B892C1A" /var/log/mail.log

We have traced an email's complete journey from sender to recipient, examining every component, protocol, and potential failure point. Let's consolidate this knowledge:

What's Next:

With mail flow mastered, we'll examine Email Addressing—understanding address formats, domain handling, aliases, forwarding, catch-all configurations, and the addressing schemes that route billions of messages daily.