Zone Mail Suite Architecture

WildDuck is part of the Zone Mail Suite — a collection of components that together form a complete, scalable email server. Each component handles a specific role and can be independently scaled.

Components

Component	Role	Default Port
WildDuck	IMAP/POP3 server + HTTP API	IMAP: 9993, POP3: 9995, API: 8080
WildDuck MCP (optional)	Read-only mail access for MCP clients	8082
WildDuck metrics (optional)	Prometheus monitoring	8081
Haraka + haraka-plugin-wildduck	Inbound SMTP (receiving mail)	25
ZoneMTA + zonemta-wildduck	Outbound SMTP (sending mail)	587
Rspamd	Spam filtering	11333
MongoDB	Persistent storage	27017
Redis	Pub/sub, caching, rate limiting	6379

Inbound Mail Flow

When an email arrives from the internet:

Internet
  ↓
MX record → Haraka (port 25)
  ↓
Rspamd spam check
  ↓
haraka-plugin-wildduck
  ├── Validates recipient exists
  ├── Checks user quota
  ├── Applies SPF/DKIM/DMARC/ARC verification
  ├── Applies message filters (forward, autoreply, etc.)
  └── Stores message in MongoDB, attachment payloads in GridFS or S3
  ↓
Redis pub/sub notification
  ↓
Connected IMAP clients receive update

Outbound Mail Flow

When a user sends an email:

Email client (SMTP submission)
  ↓
ZoneMTA (port 587)
  ↓
zonemta-wildduck plugin
  ├── Authenticates user against WildDuck
  ├── Validates From: address matches user
  ├── Applies rate limits
  ├── Signs with DKIM
  └── Copies to Sent Mail folder
  ↓
ZoneMTA queue → Internet

Messages can also be submitted via the WildDuck HTTP API (POST /users/:user/submit), which queues them through ZoneMTA.

No Single Point of Failure

The mail suite can be deployed without a single point of failure by replicating its application services and storage:

• WildDuck: Run multiple instances behind a TCP load balancer (e.g., HAProxy). Users can connect to any instance.
• Haraka: Run multiple MX servers. DNS MX records handle distribution.
• ZoneMTA: Run multiple submission servers behind a load balancer.
• MongoDB: Use replica sets for high availability, sharding for horizontal scaling.
• Redis: Use Redis Sentinel for automatic failover.

Storage Architecture

MongoDB stores the persistent account and message model:

• Messages: Parsed into MIME tree structure, stored in the messages collection
• Attachments: Deduplicated by content hash, with a MongoDB catalog and payloads in GridFS or optional S3 storage
• User data: Accounts, addresses, mailboxes, filters, settings in the main wildduck database

The GridFS database can be configured separately through dbs.gridfs, allowing message metadata and attachment payloads to use different storage resources. S3 and GridFS payloads can coexist. Draft uploads and audit copies continue to use GridFS.

Redis Usage

Redis serves several purposes in the mail suite:

• Pub/sub: Propagates mailbox change notifications to connected IMAP clients
• Caching: User profile cache, mailbox counters
• Rate limiting: Authentication attempts, outbound recipient limits, forwarding limits
• 2FA: Stores temporary WebAuthn challenges and used TOTP tokens
• Job queues: BullMQ-based queues for webhook delivery and full-text search indexing
• Distributed locks: Coordinates ACME certificate operations across instances

Related Repositories

• WildDuck — Core IMAP/POP3/API server
• Haraka — SMTP server framework
• haraka-plugin-wildduck — Haraka plugin for WildDuck integration
• ZoneMTA — Outbound SMTP relay
• zonemta-wildduck — ZoneMTA plugin for WildDuck integration
• wildduck-dockerized — Docker Compose setup for the full suite