Email System Architecture: From SMTP to Inbox

Email remains one of the most critical communication channels in software. Whether you are sending password resets, order confirmations, or marketing campaigns, understanding email system architecture is essential for building reliable, deliverable messaging infrastructure.

The Email Protocol Stack#

Three protocols form the backbone of every email system:

SMTP (Simple Mail Transfer Protocol) handles sending. Your application hands a message to an SMTP server, which relays it hop-by-hop until it reaches the recipient's mail server. SMTP operates on port 587 (submission) or 465 (implicit TLS).

IMAP (Internet Message Access Protocol) lets clients read mail while keeping messages on the server. It supports folders, search, flags, and partial fetches — ideal for users who access email from multiple devices.

POP3 (Post Office Protocol v3) downloads messages to a single client and typically deletes them from the server. Simpler than IMAP but poorly suited to multi-device workflows.

MTA, MDA, and MUA#

Email architecture divides into three agents:

• MUA (Mail User Agent) — The client (Outlook, Gmail web, Thunderbird) where users compose and read messages.
• MTA (Mail Transfer Agent) — The relay engine (Postfix, Exim, Exchange) that routes messages between servers using SMTP.
• MDA (Mail Delivery Agent) — The final hop (Dovecot, Cyrus) that drops the message into the recipient's mailbox, applying filters along the way.

A typical flow: MUA submits to MTA via SMTP, MTAs relay until the destination MTA is reached, then the MDA writes to the mailbox, and the recipient's MUA fetches via IMAP or POP3.

The Email Delivery Pipeline#

A production email system follows a multi-stage pipeline:

1. Message composition — Application generates content (HTML + plain-text fallback) and headers.
2. Template rendering — A template engine (Handlebars, MJML, React Email) merges dynamic data into a responsive layout.
3. Enqueueing — The message enters a job queue (Redis, SQS, RabbitMQ) to decouple sending from the request path.
4. SMTP submission — A worker picks the job and submits through an SMTP relay or API (SendGrid, SES, Postmark).
5. DNS resolution — The sending MTA looks up the recipient domain's MX records.
6. Relay and delivery — The message hops through MTAs until the destination MDA stores it.
7. Inbox placement — The recipient's provider runs spam filters, categorization, and rendering.

Authentication: SPF, DKIM, and DMARC#

Spam filters rely on three DNS-based mechanisms to verify sender identity:

SPF (Sender Policy Framework) publishes a TXT record listing IP addresses authorized to send on behalf of your domain. Receiving servers check the envelope sender against this list.

DKIM (DomainKeys Identified Mail) signs outgoing messages with a private key. The public key lives in DNS. Receivers verify the signature to confirm the message was not tampered with in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with a policy. It tells receivers what to do when both checks fail (none, quarantine, or reject) and where to send aggregate reports.

A properly configured domain publishes all three:

v=spf1 include:_spf.google.com include:sendgrid.net -all

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100

Without these records, your messages are far more likely to land in spam.

Bounce Handling#

Bounces fall into two categories:

• Hard bounces — Permanent failures (invalid address, domain does not exist). Remove these addresses immediately to protect sender reputation.
• Soft bounces — Temporary failures (mailbox full, server down). Retry with exponential backoff, but suppress after repeated failures.

A bounce processing pipeline typically:

1. Parses DSN (Delivery Status Notification) messages or webhook callbacks from your ESP.
2. Classifies the bounce type using RFC 3463 status codes.
3. Updates the suppression list in your database.
4. Triggers alerts if bounce rates exceed thresholds (over 2% is a red flag).

Rate Limiting and Throttling#

Sending too fast triggers rate limits and damages reputation. Best practices:

• Per-domain throttling — Major providers (Gmail, Outlook) enforce hourly and daily limits. Spread volume across time windows.
• IP warm-up — New IPs start with low volume and gradually increase over weeks to build reputation.
• Connection pooling — Reuse SMTP connections to reduce handshake overhead while respecting concurrent connection limits.
• Feedback loops (FBLs) — Register with ISPs to receive complaint notifications and suppress those recipients.

Email Templates#

Modern email templates must handle:

• Responsive design — Email clients have inconsistent CSS support. Use table-based layouts or frameworks like MJML that compile to compatible HTML.
• Plain-text fallback — Always include a text/plain MIME part for accessibility and deliverability.
• Dynamic content — Personalization tokens, conditional blocks, and localization.
• Preview text — The snippet shown in inbox lists, controlled via a hidden preheader element.
• Unsubscribe headers — RFC 8058 one-click unsubscribe via the List-Unsubscribe-Post header.

Transactional vs Marketing Email#

These two categories have different requirements:

Mixing transactional and marketing mail on the same IP is risky — a spam complaint on a campaign can tank delivery of your password reset emails.

Infrastructure and Tools#

SendGrid — High-volume API with webhook-based event tracking, template management, and IP warm-up tools. Good for both transactional and marketing.

Amazon SES — Cost-effective at scale (around $0.10 per 1,000 emails). Requires more self-management for bounce handling, reputation monitoring, and template storage.

Postmark — Focused exclusively on transactional email with industry-leading delivery speed (median delivery under 1 second). Strict anti-spam policies enforce high deliverability.

Mailgun — Developer-friendly API with powerful inbound email parsing, log search, and validation tools.

For self-hosted stacks, Postfix plus Dovecot remains the standard MTA/MDA combination, often fronted by Rspamd or SpamAssassin for filtering.

Architecture Patterns#

Dedicated sending service — Isolate email behind a microservice with its own queue, template store, and suppression list. Other services publish send requests via events or API.

Event-driven triggers — Use domain events (OrderPlaced, UserRegistered) to trigger emails asynchronously, keeping business logic decoupled from delivery.

Multi-provider failover — Route through a primary ESP and fall back to a secondary on failure. An abstraction layer (email gateway) handles provider switching transparently.

Observability — Track open rates, click rates, bounces, and complaints per template and per provider. Alert on delivery rate drops or bounce spikes.

Key Takeaways#

1. Authenticate your domain with SPF, DKIM, and DMARC before sending a single production email.
2. Separate transactional and marketing email on different IPs and subdomains.
3. Process bounces and complaints in real time to protect sender reputation.
4. Use a queue-based pipeline to absorb traffic spikes and enable retries.
5. Warm up new IPs gradually and monitor reputation dashboards.
6. Always include plain-text fallbacks and one-click unsubscribe headers.

---

If you found this guide useful, explore more system design deep dives at codelit.io.

This is article #213 in the Codelit engineering blog series.