Best Lightweight Self-Hosted Email Relay Tools 2026: msmtp vs nullmailer vs dma

Why Use a Lightweight Email Relay Instead of a Full MTA?

Running a full Mail Transfer Agent like Postfix or Exim on every server is overkill when you only need outbound email delivery. Full MTAs require queue management, local delivery agents, complex configuration files, and ongoing maintenance. For servers that only need to send notifications, alerts, cron job output, and application emails, a lightweight send-only relay is the right tool.

Lightweight email relays offer several advantages for self-hosted infrastructure:

• Minimal resource usage — typically under 5 MB RAM, compared to 50-100 MB for a full MTA
• Simplified configuration — one config file with a few lines instead of dozens of config files
• No queue management — messages are forwarded immediately to a smart host; no local spool directory to maintain
• Container-friendly — easy to include as a sidecar or init container in Docker Compose stacks
• Reduced attack surface — no listening ports, no local delivery, fewer components to harden
• Reliable delivery — retry logic and queueing on the relay side, handled by your upstream SMTP server

For related reading, see our comprehensive Postfix vs Exim MTA comparison if you need a full mail server, and our Postal vs Stalwart vs Haraka SMTP relay guide for enterprise-scale email routing.

msmtp — Reliable SMTP Client with Sendmail Compatibility

msmtp is an SMTP client that provides a sendmail-compatible interface. It reads email from standard input and forwards it to an SMTP server. With 267 GitHub stars and active development since 1999, it’s the most widely used lightweight email relay in the Linux ecosystem.

Key features:

• Sendmail-compatible command-line interface (msmtp drops in as /usr/sbin/sendmail)
• TLS/STARTTLS encryption with certificate verification
• SASL authentication (PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5, XOAUTH2)
• Per-account configuration with fallback accounts
• Syslog and file logging
• Supports multiple SMTP servers with automatic failover
• Works with mutt, mailx, PHP’s mail() function, and cron

Best for: Desktop users, small servers, and applications that expect a sendmail binary at /usr/sbin/sendmail.

Installation

1
2
3
4
5
6
7
8

# Debian/Ubuntu
sudo apt install msmtp msmtp-mta

# Arch Linux
sudo pacman -S msmtp

# Alpine Linux (Docker containers)
apk add msmtp

Configuration

Create ~/.msmtprc (or /etc/msmtprc for system-wide use):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# /etc/msmtprc
defaults
auth           on
tls            on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile        /var/log/msmtp.log

# Gmail / Google Workspace
account        gmail
host           smtp.gmail.com
port           587
from           your-email@gmail.com
user           your-email@gmail.com
password       your-app-password

# Self-hosted mail server (Postfix/Stalwart)
account        selfhosted
host           mail.yourdomain.com
port           587
from           alerts@yourdomain.com
user           alerts@yourdomain.com
password       your-password

# Default account
account default : selfhosted

Set proper permissions:

1
2

chmod 600 ~/.msmtprc
chown $USER:$USER ~/.msmtprc

Test the configuration:

1

echo "Subject: Test from msmtp\n\nThis is a test." | msmtp recipient@example.com

Docker Compose Setup

Use msmtp as a sidecar container or in an Alpine-based image:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

services:
  app:
    image: your-app:latest
    environment:
      - SENDMAIL_PATH=/usr/bin/msmtp
    volumes:
      - ./msmtprc:/etc/msmtprc:ro

  msmtp-queue:
    image: alpine:latest
    command: >
      sh -c "apk add msmtp inotify-tools &&
      while true; do
        inotifywait -e create /mailqueue/ &&
        for f in /mailqueue/*; do
          msmtp -t < \"$f\" && rm \"$f\"
        done
        sleep 1
      done"
    volumes:
      - ./msmtprc:/etc/msmtprc:ro
      - ./mailqueue:/mailqueue

PHP Integration

1
2

; /etc/php/8.2/fpm/conf.d/99-msmtp.ini
sendmail_path = /usr/bin/msmtp -t

nullmailer — Simple Queue-Based Mail Relay

nullmailer is a simple, queue-based mail relay agent designed as a drop-in replacement for sendmail. Unlike msmtp (which sends synchronously), nullmailer queues messages locally and retries delivery asynchronously, making it more resilient to temporary network outages.

Key features:

• Queue-based delivery with automatic retry
• Configurable retry intervals and expiration
• Multiple relay servers with failover
• Simple text-based configuration
• Compatible with sendmail command interface
• Low memory footprint (~2 MB)
• Supports TLS and authentication

Best for: Servers that need reliable asynchronous delivery with retry logic, especially when the upstream SMTP server might be temporarily unavailable.

Installation

1
2
3
4
5
6
7
8
9

# Debian/Ubuntu
sudo apt install nullmailer

# During installation, you'll be prompted for:
# - Mail name (hostname for outgoing mail)
# - SMTP relay server and port

# Arch Linux (AUR)
yay -S nullmailer

Configuration

Configure the relay server in /etc/nullmailer/remotes:

1
2
3

# /etc/nullmailer/remotes
# Format: hostname port --option1=value1 --option2=value2
smtp.gmail.com smtp --port=587 --starttls --auth-login --user=your-email@gmail.com --pass=your-app-password

For a self-hosted relay:

1

mail.yourdomain.com smtp --port=587 --starttls --auth-login --user=alerts@yourdomain.com --pass=your-password

Set the local hostname in /etc/nullmailer/me:

1

alerts.yourdomain.com

Set the admin address for bounce messages in /etc/nullmailer/adminaddr:

1

root@yourdomain.com

Manage the queue:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Check queue status
nullmailer-queue

# Force immediate delivery
nullmailer-send

# View failed messages
ls /var/spool/nullmailer/failed/

# Retry all queued messages
nullmailer-send --verbose

Docker Compose Setup

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

services:
  nullmailer:
    image: ghcr.io/linuxserver/nullmailer:latest
    container_name: nullmailer
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - REMOTES=smtp.gmail.com:587:user=your-email@gmail.com:pass=your-app-password:ssl:starttls
      - MAILNAME=alerts.yourdomain.com
    volumes:
      - ./nullmailer-config:/config
    restart: unless-stopped

  app:
    image: your-app:latest
    depends_on:
      - nullmailer
    environment:
      - SMTP_HOST=nullmailer
      - SMTP_PORT=25

dma — Dragonfly Mail Agent

The Dragonfly Mail Agent (dma) is a small, efficient MTA designed for home and office use. Originally developed for DragonFly BSD, it works equally well on Linux. With 256 GitHub stars, it’s a popular choice for minimal server setups.

Key features:

• Extremely lightweight (~1 MB binary)
• Supports local delivery and mail forwarding
• Aliases support via /etc/aliases
• Virtual user mapping
• TLS encryption
• Simple single-binary design
• Compatible with sendmail interface
• Maildir and mbox delivery support

Best for: Minimal installations, BSD systems, and environments where you want the smallest possible MTA footprint.

Installation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Debian/Ubuntu
sudo apt install dma

# FreeBSD
pkg install dma

# Build from source
git clone https://github.com/corecode/dma.git
cd dma
make
sudo make install

Configuration

Edit /etc/dma/dma.conf:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# /etc/dma/dma.conf
# Smart host configuration
SMARTHOST mail.yourdomain.com

# Authentication
AUTH default user alerts@yourdomain.com password your-password

# TLS settings
SECURETRANS STARTTLS

# Masquerade outgoing addresses
MASQUERADE yourdomain.com

Set up aliases in /etc/dma/aliases:

1
2
3
4

# /etc/dma/aliases
root: admin@yourdomain.com
postmaster: admin@yourdomain.com
nobody: admin@yourdomain.com

Build the alias database:

1

sudo newaliases

Test delivery:

1

echo "Subject: DMA Test\n\nDelivery test from dma." | sendmail -t recipient@example.com

Docker Compose Setup

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

services:
  dma-relay:
    build:
      context: ./dma-docker
      dockerfile: Dockerfile
    container_name: dma-relay
    volumes:
      - ./dma.conf:/etc/dma/dma.conf:ro
      - ./aliases:/etc/dma/aliases:ro
    ports:
      - "25:25"
    restart: unless-stopped

  app:
    image: your-app:latest
    environment:
      - SMTP_HOST=dma-relay
      - SMTP_PORT=25
    depends_on:
      - dma-relay

Comparison Table

When to Choose Each Tool

Choose msmtp when:

• You need a sendmail drop-in replacement for existing applications
• You want per-account configuration (different SMTP servers for different use cases)
• You’re setting up email for cron jobs, PHP applications, or command-line tools
• Synchronous delivery is acceptable (you want immediate success/failure feedback)
• You need XOAUTH2 authentication for Gmail or Google Workspace

Choose nullmailer when:

• You need reliable asynchronous delivery with automatic retry
• Your upstream SMTP server may have occasional downtime
• You want simple queue management with CLI tools
• You’re deploying on Debian/Ubuntu where it’s available as a single apt install
• You need configurable retry intervals and message expiration

Choose dma when:

• You want the smallest possible binary footprint (~50 KB)
• You need local Maildir/mbox delivery in addition to relay
• You’re running DragonFly BSD or FreeBSD
• You need alias support without running a full MTA
• You’re building a minimal container image and every KB matters

Security Best Practices

Regardless of which tool you choose, follow these security practices:

1. Use app-specific passwords — never use your main account password. Generate app passwords from your email provider.
2. Enable TLS — always use STARTTLS or SSL/TLS to encrypt mail in transit.
3. Restrict config file permissions — set 600 on configuration files containing credentials.
4. Use a dedicated sending account — create a dedicated email account (e.g., alerts@yourdomain.com) for server notifications.
5. Monitor delivery failures — check logs regularly for authentication errors or delivery rejections.
6. Set up SPF/DKIM on your domain — even for relay-only setups, proper DNS records prevent your emails from being marked as spam. See our complete email authentication guide for SPF, DKIM, and DMARC configuration.

FAQ

What is the difference between a lightweight email relay and a full MTA?

A full MTA (Mail Transfer Agent) like Postfix or Exim handles both sending and receiving email, manages local mailboxes, runs queue daemons, and requires complex configuration. A lightweight email relay like msmtp, nullmailer, or dma only handles outbound email delivery — it takes messages from local applications and forwards them to an upstream SMTP server. It does not receive external mail or deliver to local mailboxes.

Can I use these tools with Gmail or Google Workspace?

Yes, all three tools support TLS and SASL authentication required by Gmail. You need to generate an App Password from your Google Account (Security → 2-Step Verification → App Passwords) and use it instead of your regular password. Configure the SMTP server as smtp.gmail.com on port 587 with STARTTLS.

How do I handle email delivery failures?

With msmtp, delivery failures are reported immediately to the calling application (e.g., cron emails the error to root). With nullmailer and dma, failed messages stay in the local queue and are retried automatically. You can check the queue status with nullmailer-queue (nullmailer) or by examining /var/spool/dma/queue/ (dma). Configure retry intervals and expiration times in each tool’s configuration.

Can these tools receive incoming email?

No. msmtp is send-only and cannot receive mail. nullmailer is also send-only. dma supports local delivery to Maildir or mbox format, but it does not accept incoming SMTP connections from external servers — it’s designed for local delivery only, not for receiving mail from the internet. For full inbound email support, you need a full MTA like Postfix or Stalwart.

Which tool is best for Docker containers?

For Docker, msmtp is the easiest to integrate — simply add the msmtp package to your Alpine-based image and point your application’s sendmail_path to it. nullmailer has an official LinuxServer.io Docker image (ghcr.io/linuxserver/nullmailer) with environment variable configuration. dma requires a custom Dockerfile build but produces the smallest container image.

How do I set up multiple SMTP servers for failover?

msmtp supports multiple accounts with a default fallback: define separate account blocks and set account default to your primary, with account fallback as backup. nullmailer supports multiple relays listed in /etc/nullmailer/remotes — it tries them in order. dma supports multiple SMARTHOST entries in its configuration, trying each in sequence.

Pre-Publish Self-Check

• Comparison table: ✅ present
• Code blocks: ✅ Docker Compose, install commands, config examples
• FAQ section: ✅ 6 Q&A items
• Internal links: ✅ 3 relative links to existing articles
• JSON-LD: see below