Design an Email Service (like Gmail)

Email Send Flow

Outbound delivery validates recipient domains, writes attachments to object storage, signs cryptographically via DKIM, and coordinates SMTP handshakes with exponential backoff.

1. User clicks "Send" -> POST /api/messages/send
2. Validate: recipients exist, attachment size < 25MB, rate limit check
3. Store email body and attachments to Blob Store (S3 or GCS)
4. Store email metadata to Bigtable or Cassandra
5. Enqueue to send queue (Kafka topic: outgoing-emails)
6. SMTP Sender Worker picks up message from queue:
   a. DNS MX lookup: resolve recipient domain to locate receiving mail server
   b. Open TLS connection to receiving server using STARTTLS
   c. Authenticate: sign message headers with DKIM private key for sender domain
   d. Transmit email via standard SMTP commands
   e. Receiving server acknowledges receipt -> mark message as delivered
   f. If rejected -> generate delivery status notification (DSN bounce) to sender
7. On transient failure: retry with exponential backoff (from 1 minute up to 72 hours)
   After 72 hours of unsuccessful retries -> mark permanent failure and bounce to sender

Optimization for internal delivery (sender@gmail to recipient@gmail):
   Bypass external SMTP entirely, writing directly into recipient mailbox with ~100ms latency.

Incoming Email Flow (SMTP Receive)

The inbound path applies connection-level filtering, evaluates cryptographic authentication headers, scores spam probability, and archives payloads.

1. External sender MTA establishes connection to our SMTP gateway (advertised via MX records).
2. Execute standard SMTP handshake: EHLO, MAIL FROM, and RCPT TO.
3. Pre-data validation checks:
   a. SPF verification: confirm whether the sending IP is authorized for the sender domain.
   b. Ingress rate limiting: if connection limits are exceeded, return temporary 421 code.
   c. Recipient mailbox validation: return 550 User Unknown if address does not exist.
4. Accept DATA payload, streaming email MIME content directly.
5. Verify DKIM cryptographic signature using sender DNS public key.
6. Evaluate DMARC alignment combining SPF and DKIM validation outcomes.
7. Execute multi-tier spam and phishing classification models:
   Score > 0.7 routes to Spam folder; 0.3 to 0.7 displays security banner; < 0.3 routes to Inbox.
8. Scan attachments for malicious payloads and viruses using streaming antimalware engines.
9. Persist MIME body to distributed Blob Store and write metadata to Bigtable.
10. Index searchable tokens asynchronously into Elasticsearch cluster.
11. Dispatch real-time push notification to active recipient devices.
12. Return 250 OK acknowledgment to sending MTA.

Spam Filtering Architecture

A three-layer filtering pipeline balances execution latency against classification accuracy, filtering 70% of malicious traffic at the TCP connection boundary.

Layer 1: Connection-level filters (< 1ms per connection)
  - IP reputation: verify against established DNS-based blocklists (Spamhaus ZEN).
  - Volume anomaly detection: throttle connections exceeding 1,000 emails per hour from single IP.
  - Forward-confirmed reverse DNS: ensure sending IP reverses to a legitimate hostname.
  Catches: ~70% of inbound spam volume before payload inspection.

Layer 2: Content and cryptographic analysis (10 to 50ms per email)
  - SPF, DKIM, and DMARC verification: authenticate sender identity and domain ownership.
  - Heuristic rules: scan for known phishing text fragments, deceptive HTML, and obfuscated links.
  - URL intelligence: compare embedded links against real-time malicious domain registries.
  - Attachment analysis: scan binary attachments for malware signatures.
  Catches: additional ~20% of inbound spam.

Layer 3: Machine learning classification (100 to 300ms per email)
  - Deep learning NLP: fine-tuned transformer model evaluating subject and body semantics.
  - Behavioral features: sender domain age, historical user interaction graph, and click ratios.
  - Confidence scoring: score > 0.85 moves to spam, 0.50 to 0.85 flags warning, < 0.50 routes to inbox.
  Catches: additional ~9% of sophisticated spam.

Cumulative outcome: achieves a false positive rate below 0.01% on legitimate messages.

Push vs Pull Synchronization

Mobile and web clients leverage specialized push channels rather than periodic polling: IMAP IDLE maintains long-lived TCP connections for legacy desktop clients, Firebase Cloud Messaging and Apple Push Notification service deliver battery-efficient mobile wakeups, and WebSockets drive live browser inbox updates.

SPF, DKIM, and DMARC Authentication

Sender Policy Framework (SPF) publishes authorized IP ranges in DNS, DomainKeys Identified Mail (DKIM) attaches asymmetric cryptographic signatures to headers, and DMARC specifies recipient enforcement policies when authentication checks fail.