Introduction

Running Sendmail in a Docker container can work for controlled relay or test environments, but it requires careful configuration. Mail systems are sensitive to DNS, relay policy, and security controls, and those concerns do not disappear in containers. A reliable setup emphasizes explicit relay behavior, reproducible configuration, and operational visibility.

Decide If Containerized Sendmail Is the Right Choice

Before implementation, clarify your use case.

Reasonable cases:

• Local integration testing where app expects sendmail binary.
• Internal relay inside trusted network boundaries.
• Legacy compatibility migration step.

High-risk cases:

• Direct internet-facing outbound SMTP from untrusted hosts.
• Production delivery without SPF, DKIM, DMARC, and reputation strategy.

For most modern production notification flows, managed SMTP relay is simpler and safer.

Build a Minimal Reproducible Image

A deterministic image reduces environment drift.

1FROM debian:12-slim
2
3RUN apt-get update \
4    && DEBIAN_FRONTEND=noninteractive apt-get install -y sendmail mailutils ca-certificates \
5    && rm -rf /var/lib/apt/lists/*
6
7COPY sendmail.mc /etc/mail/sendmail.mc
8RUN m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
9
10EXPOSE 25
11CMD ["/usr/sbin/sendmail", "-bd", "-q15m"]

Keep sendmail.mc under version control so relay and security behavior is auditable.

Start Container With Explicit Runtime Settings

Use explicit host name and port mapping.

1docker build -t sendmail-local .
2docker run --name sendmail \
3  --hostname mail.local \
4  -p 2525:25 \
5  -d sendmail-local

Using host port 2525 is often safer for development than direct port 25 binding.

Validate End-to-End Delivery Path

Configuration is not complete until message flow is verified.

Send a test mail from inside container:

docker exec -it sendmail sh -lc 'printf "Subject: Test\n\nHello\n" | sendmail -v [email protected]'

Send an SMTP probe from host:

swaks --to [email protected] --server 127.0.0.1:2525 --from [email protected]

Inspect queue state:

docker exec -it sendmail mailq

Deferred queue growth usually indicates relay or DNS issues.

Configure Relay Host for Production-Like Reliability

Direct outbound delivery from random hosts is frequently rejected. Relay-host mode is usually the correct production path.

Benefits:

• Better deliverability and reputation management.
• Centralized auth and TLS controls.
• Lower operational burden on application team.

Even with relay mode, enforce sender domain restrictions and monitor rejection trends.

Security Hardening Checklist

Minimum security controls:

• Do not run open relay configuration.
• Restrict accepted client networks.
• Keep credentials out of image layers.
• Use least-privilege runtime where possible.
• Centralize logs and alerting.

Mail daemons are common abuse targets. Treat configuration as security-critical infrastructure.

Compose Setup for Team Reproducibility

A simple compose file improves consistency for local and CI testing.

1services:
2  sendmail:
3    build: .
4    container_name: sendmail
5    hostname: mail.local
6    ports:
7      - "2525:25"
8    volumes:
9      - ./mail-queue:/var/spool/mqueue

Start and verify listener:

docker compose up -d
docker exec -it sendmail sh -c "netstat -lntp | grep :25"

This helps reproduce mail-dependent integration behavior reliably.

Monitoring and Incident Response

Monitor at least:

• Deferred queue count and age.
• Relay error rates.
• Bounce categories.
• TLS handshake failures.

Prepare runbooks for queue backlog and relay outage recovery. Without runbooks, delivery incidents become long and costly.

Common Pitfalls

• Running permissive relay defaults in shared networks.
• Assuming local test success proves production deliverability.
• Ignoring DNS and sender-policy prerequisites.
• Losing queued messages due to non-persistent spool storage.
• Using containerized Sendmail where managed relay would be lower risk.

Summary

• Containerized Sendmail is feasible but operationally sensitive.
• Prefer managed relay for most production notification workloads.
• Use reproducible images and explicit relay configuration.
• Validate full delivery path and monitor queue behavior continuously.
• Apply strong security controls to prevent misuse and delivery failures.