Stalwart Mail Server: Ecosystem SMTP Relay

The Architecture Rationale

In a virtualized infrastructure, reliability is paramount. Relying on an enterprise MS Exchange server for low-level system alerts, cron jobs, and internal application notifications creates a single point of failure and unnecessary complexity. I deployed Stalwart as a dedicated SMTP relay to handle all VM ecosystem outbound traffic. By keeping this service decoupled, I ensure that internal notifications are never hindered by Exchange-level policy updates or mailbox quotas, while maintaining full control over deliverability.

Phase 1: Deployment & Internal Network Setup

The server is deployed via Proxmox Helper-Scripts for a lean, stable Debian base, followed by a manual installation of the Stalwart Mail Server.

Network & Security

To ensure reliable communication between the Nginx proxy and the mail server, the Nginx internal IP must be explicitly permitted:

  • Security: Navigate to Settings > Security > AllowedIPs and whitelist the Nginx reverse proxy IP to prevent potential connection rejection.
  • Internal Resolution: Add the Stalwart host to the /etc/hosts file to ensure the container can resolve itself and other services on the internal network.

Phase 2: DNS & Deliverability (Cloudflare)

To ensure high deliverability and avoid spam classification, Stalwart requires strict DNS records. These were carefully integrated into the Cloudflare zone alongside existing MS Exchange records, utilizing descriptive notes for maintenance clarity:

  • DKIM: Generated and added as TXT records to authenticate outbound mail.
  • SPF/DMARC: Configured to explicitly permit the Stalwart relay as an authorized sender for the domain.
  • TLS Configuration: While reverse proxies often handle TLS, Stalwart is configured for internal LAN communication with dedicated certificates managed via Cloudflare DNS challenges to ensure all transit is encrypted.

Phase 3: SMTP Outbound Strategies

A critical adjustment was required to distinguish between local and external routing for the relay:

  • Strategy Modification: Updated Settings > SMTP > Outbound > Strategies.
  • Configuration Change: Set is_local_domain('*', rcpt_domain) to use the mx strategy instead of the default local strategy. This ensures that even for internal domains, the mail server properly evaluates DNS/MX records for routing, increasing compatibility with my internal VM ecosystem.

Evaluation: Stalwart vs. Alternatives

SolutionRationale
StalwartChosen for its modern architecture, built-in security, and low memory footprint compared to traditional stacks like Postfix/Dovecot.
Postfix / DovecotThe “industry standard,” but extremely complex to configure, maintain, and harden properly.
MS ExchangeEnterprise-grade, but overkill (and risky) to use as a generic relay for internal VM/scripted alerts.

Operational Summary

This setup provides a robust, encrypted, and isolated email relay. By using Stalwart, I’ve achieved:

  1. Deliverability: Properly signed DKIM/SPF ensures system notifications reach their destination.
  2. Isolation: The VM ecosystem has its own dedicated path for alerts.
  3. Control: DNS and outbound strategies are tuned specifically for high-volume automated traffic rather than user-based email.