Transactional email - the receiver decides

Ask these before drawing anything

• Transactional only, or marketing too? If both, the first real design decision is whether they share IPs, and the honest answer is that they must not.
• Do we own the sending domain, or are we sending on behalf of customers? Customer domains mean per-customer DKIM keys, per-customer DNS instructions, and a support burden bigger than the system.
• What is the latency promise? A password reset in 10 seconds and a weekly digest are different systems sharing a queue at their peril.
• Do we store the rendered body? It is the difference between 16 GB a day and 1.8 TB a day - see the storage page.
• What is the bounce deadline: how long may a deferred message keep retrying before delivering it is worse than dropping it? A password reset landing four hours late is a security event.
• Are we required to track opens and clicks? Pixel tracking is a second traffic pattern, a privacy question, and increasingly a lie - Apple Mail Privacy Protection preloads images and fabricates opens.
• Who owns unsubscribe, and does it apply across streams? A one-click unsubscribe from marketing must not stop a receipt.
• What is the compliance retention on message content and on consent records? They are different answers and both belong in the schema.

Functional

• Accept a send request, render a versioned per-locale template, and deliver it.
• Never send to a suppressed address, and check that before queueing.
• Sign every message with DKIM and send from an IP whose SPF and DMARC alignment is correct.
• Retry 4xx deferrals with capped exponential backoff; never retry a 5xx.
• Process DSN bounces, ARF complaints and feedback-loop reports, and suppress accordingly.
• Warm new IPs gradually, per receiving domain.
• Record every outcome per message, per attempt.
• Ingest DMARC aggregate reports and surface authentication failures.

Non-functional

• Transactional: p95 accept-to-first-SMTP-attempt under 5 seconds.
• Marketing: a 20M-recipient campaign fully handed over within 2 hours.
• 99.95% availability for accepting a send. Delivery to the inbox is not an availability target and cannot be one.
• Exactly-once semantics at the address level via an idempotency key - a duplicated password reset is a security problem, not an annoyance.
• Complaint rate below 0.1% per receiving domain, which is a hard architectural constraint, not a marketing KPI: above it, Gmail throttles everything from the IP.
• No message is lost silently. Every message reaches a terminal state and that state is recorded.

Out of scope

• Inbound mail, parsing and threading - a different system entirely.
• Campaign composition, audience selection and A/B assignment.
• The MTA software itself; assume a hardened off-the-shelf one.