Sending email at scale

How transactional and bulk email systems work: SMTP and email providers, deliverability with SPF, DKIM and DMARC, IP and domain reputation, warm-up, bounces and complaints, suppression lists, unsubscribe handling, queues and rate limits per provider, templates, tracking and privacy.

Reading is half of it. See this used in a real interview: walk through Design a Notification System →

Email looks like the simplest notification channel: call an API, the message arrives. At scale, the hard part is not sending but arriving in the inbox: mailbox providers like Gmail and Outlook filter aggressively, and a sender with poor practices ends up in spam or blocked. Notification system designs that include email should cover the delivery pipeline and the reputation rules around it.

The pipeline

1. A product event (password reset, receipt, weekly digest) reaches the notification service.
2. Preferences and suppression lists are checked. See Design a Notification System.
3. The message is rendered from a template in the user's language.
4. It is queued by priority: transactional (password resets, receipts) separate from marketing.
5. Sender workers submit it to an email provider (or your own mail transfer agents) via API or SMTP.
6. The provider delivers to the recipient's mail server, retrying temporary failures.
7. Events flow back: delivered, bounced, complained, opened, clicked, unsubscribed.

Use queues between stages so a slow provider or a big campaign does not block password resets. See background jobs.

Authentication: SPF, DKIM, DMARC

Mailbox providers check that mail really comes from your domain:

• SPF: a DNS record listing the servers allowed to send for your domain.
• DKIM: a cryptographic signature on each message, verified with a public key in DNS. Proves the message was not altered and was authorised by the domain.
• DMARC: a DNS policy telling receivers what to do when SPF or DKIM fail (none, quarantine, reject), and where to send reports.

Large mailbox providers now require all three for bulk senders. Use separate subdomains for transactional and marketing mail (mail.example.com, news.example.com) so a marketing reputation problem does not affect password resets.

Reputation

Receivers score senders by IP address and domain, based on spam complaints, bounces, engagement and volume patterns:

• Warm up new IPs and domains by increasing volume gradually over weeks.
• Dedicated IPs for large senders; shared pools for small ones (reputation shared with other customers).
• Keep complaint rates very low (well under 0.1 %) and bounce rates low.
• Sudden spikes in volume look like spam; spread large campaigns over time.

Bounces, complaints and suppression

• Hard bounces (address does not exist): suppress the address permanently.
• Soft bounces (mailbox full, temporary errors): retry, then suppress after repeated failures.
• Complaints (user clicked "this is spam", reported via feedback loops): suppress immediately for that category.
• Unsubscribes: honour immediately; support one-click unsubscribe headers (now required by major providers for bulk mail).

A central suppression list is checked before every send. Sending to bad addresses is the fastest way to ruin reputation.

Throughput and rate limits

• Providers and receiving domains throttle senders; workers apply rate limits per provider and per receiving domain, with backoff on deferrals. See rate limiting algorithms.
• Large campaigns are sharded into batches and sent over a window, respecting quiet hours and time zones. See delayed jobs and distributed cron.
• Priority isolation: transactional mail has its own queue, workers and often its own provider account.
• Idempotency: each email has an id so retries in your pipeline do not send duplicates. See idempotency keys in practice.
• Multiple providers with failover protect against a provider outage.

Templates and content

• Templates with versioning, localisation and previews; render server-side with escaping.
• Plain text alongside HTML; reasonable image-to-text ratio; no misleading subjects.
• Links through a tracking domain you control, signed to prevent open redirects. See hashing and encoding.

Tracking and privacy

• Opens via tracking pixels are unreliable now (privacy features preload images); treat open rates as approximate.
• Clicks via redirect links are more reliable.
• Respect consent and regional laws for marketing email; transactional mail is usually exempt but must stay transactional.
• Do not put sensitive data in email bodies; link to the app instead. See privacy and data deletion.

Transactional specifics

Password resets and one-time codes need speed (seconds) and reliability: dedicated high-priority path, short-lived single-use tokens, and monitoring of end-to-end latency from request to delivery. Receipts for payments must be sent exactly once per transaction, keyed by payment id. See Design a Payment System.

In the interview

"Emails go through the notification pipeline: preference and suppression checks, templated rendering, priority queues with transactional mail isolated, and sender workers rate-limited per provider and receiving domain. Domains use SPF, DKIM and DMARC, with separate subdomains for marketing. Bounces and complaints feed the suppression list automatically, and unsubscribes are one-click and immediate."

Checklist

• Queued pipeline with transactional and bulk paths isolated.
• SPF, DKIM and DMARC; separate sending subdomains.
• IP and domain warm-up; volume spread over time.
• Hard bounces, complaints and unsubscribes suppressed immediately.
• Per-provider and per-domain rate limits, retries and failover.
• Idempotent sends; signed tracking links; privacy-aware content.