Design a bulk email campaign sender

Sending is easy; reaching the inbox is the product. Mailbox providers decide based on authentication and reputation. Every message must pass SPF (the sending IP is authorised for the envelope domain) and DKIM (a signature with a key published in DNS), and the visible From domain must align with them so DMARC passes. In a multi-tenant platform, tenants should authenticate their own domain (CNAME records pointing to our DKIM keys and a custom return-path), otherwise all tenants share our domain's reputation. Since February 2024, Gmail and Yahoo require bulk senders (over ~5,000 messages a day to Gmail) to have SPF, DKIM and a DMARC policy, support one-click unsubscribe via the List-Unsubscribe-Post header (RFC 8058) and honour it within two days, and keep spam complaint rates below 0.3%. Practical targets are tighter: complaints under 0.1%, hard bounces under 2%. Monitor Google Postmaster Tools and Microsoft SNDS for domain and IP reputation, and process feedback-loop complaints so complainers are never mailed again. India adds no extra law here beyond DPDP consent rules, but good list hygiene matters everywhere.

Receivers rate-limit each sending IP. Push 500k messages to Gmail from a new IP in an hour and you get 421 deferrals, then spam-foldering. So the bottleneck is not our workers but per-destination limits. The shaper keeps queues keyed by (ip_pool, receiving domain) with token buckets per IP and domain, plus a cap on concurrent SMTP connections per destination. When a receiver returns 4xx deferrals, the bucket rate drops automatically (AIMD: back off fast, increase slowly). New IPs and domains need warm-up: start with a few thousand messages a day to the most engaged recipients, then roughly double every day or two over several weeks, watching bounces and complaints. Pools separate traffic types: transactional mail on its own IPs and domains so a campaign problem never delays password resets; dedicated IPs for large senders with steady volume; shared pools for small tenants, where volume is too low to build reputation alone. A campaign's speed is the minimum of the tenant's plan limit, its reputation-based limit and receiver capacity, and the dashboard should show why a campaign is slow.

With 10M recipients, workers will crash, batches will be retried and queues will redeliver. Duplicates annoy users and raise complaints, so per-recipient idempotency is a must. The audience is frozen at launch, so a retry processes the same recipients. Before handing a message to the MTA, the worker does an insert-if-not-exists of (campaign_id, contact_id) in the sends ledger (a lightweight transaction in Cassandra/Scylla or a conditional put in DynamoDB); if the row exists, the recipient was already handled and is skipped. There is still a small window: the row is written, then the worker dies before the MTA accepted the message. Record status pending first and sent after the MTA's 250 OK; a sweeper re-sends only rows stuck in pending beyond a timeout, accepting a tiny duplicate risk rather than silently dropping someone. Once the MTA has accepted a message, it owns retries for deferrals. Pause works naturally: the launcher stops releasing batches and workers check the campaign's state before each batch, so a pause takes effect within seconds.

On a shared platform, one tenant with a purchased list can generate thousands of complaints and hard bounces, and receivers will penalise the shared IPs that every other tenant uses. Defend at several layers. At import, validate lists: syntax and MX checks, catch role addresses and known spam traps, and flag lists with high unknown-user rates. Score each tenant continuously on bounce rate, complaint rate and engagement; new tenants start in a probation pool with low limits and graduate as their numbers stay clean. Run large campaigns as a canary: send the first 1-2% to engaged recipients, and if bounce or complaint rates cross thresholds, pause automatically before the remaining 98% go out. Move tenants with poor scores to a quarantine pool so the damage stays there, and suspend repeat offenders. Global suppression of hard bounces and complaints protects everyone: an address that bounced for tenant A is not mailed for tenant B. Expose these metrics to tenants so they understand and fix their own list quality.

SES is cheap per message and removes MTA operations, but gives less control over IP pools, per-domain shaping and warm-up. Large platforms run their own MTAs (KumoMTA, PowerMTA, Postfix) for control and cost at billions of emails. A hybrid is common: own MTAs for campaigns, a provider as failover and for transactional mail.

A snapshot makes retries deterministic and progress measurable; contacts added after launch miss the campaign. A live segment is fresher but makes idempotency and counts harder. Snapshot, with suppression checked live at send time.

Sending 10M emails in 10 minutes looks great but triggers receiver throttling. Spreading over an hour or more, or per timezone, improves inbox placement and engagement. Let tenants choose within limits set by reputation.

Tracking pixels are blocked or pre-fetched (Apple Mail Privacy Protection loads all images), inflating opens. Report opens as approximate, and prefer clicks and conversions for A/B winners and engagement scoring.

Everyone sends at 10 am. Spread campaigns with send-time optimisation per recipient, and keep enough warm IPs per major receiver.

Computing a 50M-row segment on the OLTP store is slow. Run segments on a columnar copy (ClickHouse) and stream results to the snapshot.

Millions of opens and clicks within minutes of a send. The tracking edge is stateless, returns the pixel or redirect immediately and writes events to Kafka asynchronously.

The batch lease expires and another worker retries it; the sends ledger skips recipients already sent, so no duplicates.

Bounce messages and deferral patterns show it; the shaper drains that IP and moves traffic to other IPs in the pool while the cause (usually one tenant) is found and delisting requested.

Kill switch: pause stops new batches within seconds. Messages already accepted by MTAs may still go out; the canary phase limits how many that can be.

Links must still work: click redirects run on a highly available edge (CDN workers) with the destination encoded in the signed token, so the redirect works even if the backend is down; only the event is lost.