Synopsis #
Most application and home-server hosts need reliable outgoing notifications, not a complete public mail system. An authenticated relay reduces DNS, reputation, abuse, queue, filtering, and availability responsibilities. A public mail server is a continuing operational commitment involving more than installing an MTA.
Select the smallest mail role that meets the requirement before configuring packages or opening port 25.
Choose the role #
| Requirement | Suitable role | Main responsibility |
|---|---|---|
| Local cron and service messages only | Local delivery | Forward root and operational aliases to a monitored mailbox. |
| Application alerts to Internet recipients | Authenticated outgoing relay | Protect relay credentials and monitor the local queue. |
| Receive mail for a public domain | Full mail service | DNS, TLS, spam and malware policy, authentication, storage, backups, abuse response, and reputation. |
| Forward mail for other hosts | Restricted relay | Explicit client authorization; never an open relay. |
Do not expose SMTP merely to test that local programs can call mail(1).
Establish identity and DNS first #
For Internet delivery, record:
- the host’s stable fully qualified domain name;
- forward and reverse DNS ownership;
- envelope and visible sender domains;
- SPF, DKIM, and DMARC policy where applicable;
- TLS certificate and renewal ownership;
- provider restrictions on outbound port 25;
- where bounces and abuse reports are read.
An MTA cannot repair missing reverse DNS or a blocked provider network by configuration alone.
Prefer a relay for host notifications #
FreeBSD documents DMA for routing outgoing mail through a smarthost. Store authentication material with restrictive ownership and permissions, and use the provider’s current TLS and credential instructions rather than copying an example password format unchanged.
After configuration, send a traceable test to a controlled recipient:
$ printf '%s\n' 'mail relay test' | mail -v -s 'FreeBSD relay test' operator@example.net
Then verify receipt, sender identity, TLS evidence available from the provider, and local queue state. A zero exit status does not prove final delivery.
Treat public mail as a service stack #
A receiving mail system generally needs:
- an MTA with a closed relay policy;
- authenticated message submission separate from server-to-server SMTP;
- IMAP or another mailbox access boundary when users store mail;
- spam and malware policy;
- DKIM signing and DNS policy;
- certificate renewal;
- queue, disk, reputation, and abuse monitoring;
- tested mailbox and configuration restoration.
Separate these roles in the architecture even when one host provides several of them. Do not use a broad legacy mail chapter as a reason to publish an unmaintained copy-paste server recipe.
Protect local operational mail #
Review aliases so messages to root reach a mailbox that is actually monitored. Test after every mail transport change and release upgrade. Record queue inspection and failure commands for the selected MTA; command names are not portable between DMA, Postfix, OpenSMTPD, and other transports.