Designing an Email Service

An email service handles transactional emails (receipts, OTPs) and bulk marketing emails at scale.

Types of Email

Transactional: Order confirmation, password reset, OTP
               (triggered by user action, time-critical)

Marketing:     Newsletters, promotions
               (bulk, lower priority)

Architecture

Application → Email API Service
                    ↓
             Template Engine
                    ↓
              Priority Queue
              (Kafka topics)
              ↙          ↘
    Transactional     Marketing
     Workers          Workers
         ↓                ↓
    SMTP Relay       SMTP Relay
  (high priority)  (throttled)
         ↓
   ISP Mail Servers

Email Sending Flow

1. API receives send request
2. Render template with variables
3. Enqueue to priority queue
4. Worker picks up, sends via SMTP
5. Record send event in DB
6. Handle async webhook (delivery/bounce/open)

Deliverability

Email reputation is everything:

SPF:   Authorize sending IPs in DNS
DKIM:  Sign emails with private key
DMARC: Policy for SPF/DKIM failures

Warm up IPs: Start small, increase volume daily
Separate IPs: Transactional ≠ Marketing
Clean lists:  Remove bounces and unsubscribes

Bounce Handling

Hard bounce: Invalid address → Remove permanently
Soft bounce: Mailbox full → Retry 3x, then remove
Complaint:   Marked spam → Unsubscribe immediately

Unsubscribe Management

One-click unsubscribe (RFC 8058)
List-Unsubscribe header in all marketing emails
Suppression list: Never email unsubscribed users

Rate Limits

Transactional: No limit (triggered by user)
Marketing:     50K emails/hour max (ISP limits)
Per domain:    Respect MX throttling

Conclusion

Deliverability is the hardest part of email. SPF+DKIM+DMARC, IP warming, and aggressive bounce/unsubscribe handling keep your domain reputation high.