FreeBSD DMA Mail Operations: Deliver Local System Mail Through a Relay

FreeBSD includes DragonFly Mail Agent, commonly called DMA, as its default mail transfer agent beginning with FreeBSD 14.0. DMA is intentionally small: local programs can submit mail for local delivery or for forwarding to a remote mail host. It supports SMTP authentication and TLS for remote delivery, but it is not a full-featured Internet mail server and does not listen on port 25 for incoming network mail.

That distinction matters operationally. A server may need outbound delivery for periodic reports, job failures, or administrative messages without accepting inbound mail from the Internet. Configure DMA for that role, test it with a known recipient, monitor queued mail, and preserve the default sendmail-compatible interface that system utilities expect.

Confirm which mailer owns system submission

Before changing configuration, establish the running FreeBSD release and which mailer files are active:

freebsd-version -kru
ls -l /usr/sbin/sendmail /usr/libexec/dma /etc/mail/mailer.conf
sysrc sendmail_enable sendmail_submit_enable sendmail_outbound_enable sendmail_msp_queue_enable dma_flushq_enable
sed -n '1,120p' /etc/mail/mailer.conf
mailq

DMA is the default MTA on FreeBSD 14.0 and later according to the Handbook. Older releases differ, and upgrades can preserve local configuration that does not match a fresh install. Do not infer behavior from the existence of sendmail-compatible commands: the compatibility interface may route to DMA or to another installed MTA through mailer.conf.

Inspect /etc/mail/mailer.conf and any local overrides before installation or migration. Determine whether a third-party MTA is already active and whether periodic jobs depend on its queue runner. Do not disable the current MTA until a replacement is configured, tested, and enabled; otherwise routine system mail may silently remain queued or fail.

DMA is suitable when the host needs lightweight local submission and outbound delivery through a relay. If the system must accept mail from remote clients, host mailboxes for a domain, provide filtering, or maintain complex delivery policy, evaluate a full MTA and the corresponding DNS, abuse-prevention, queue, and monitoring requirements separately.

Use the default relay configuration safely

The Handbook documents /etc/dma/dma.conf for custom settings and /etc/dma/auth.conf for SMTP authentication. A common relay configuration uses a smarthost, port, TLS, and an auth file. The exact provider hostname, port, TLS mode, username, and password must come from the mail provider’s current documentation:

SMARTHOST smtp.example.net
PORT 587
AUTHPATH /etc/dma/auth.conf
SECURETRANSFER
STARTTLS
MAILNAME host.example.net

The values are placeholders, not a working service configuration. Some providers require implicit TLS on a different port, some require STARTTLS, and some disable password-based SMTP authentication. Do not combine options from different providers. Confirm DNS, certificate trust, supported TLS behavior, and authentication requirements with the relay operator.

An auth file entry follows the documented account-and-server form:

[email protected]|smtp.example.net:REPLACE_WITH_SECRET

Treat the file as credential material. Set ownership and permissions consistent with the installed DMA implementation’s requirements, restrict configuration backups, and never put real values in a public repository or support transcript. Avoid using a personal mailbox password; use a dedicated relay credential that can be rotated without affecting interactive account access.

If the provider requires message rewriting, use the documented masquerade or mailname configuration intentionally. A local root address may need mapping to a monitored mailbox, but rewriting sender identities can affect SPF, DMARC alignment, bounce handling, and incident attribution. Do not invent a sender domain; use a domain authorized by the relay.

Submit a message and separate failure layers

After configuration, submit one non-sensitive test message to an address you control:

echo "FreeBSD DMA relay test" | mail -v -s "DMA test" [email protected]
mailq
tail -100 /var/log/maillog

The recipient is a placeholder. Replace it with an approved test mailbox, and avoid putting incident secrets or customer data in the message. The Handbook also uses mail(1) to test DMA configuration. Preserve verbose output and the queue state if delivery fails.

Triage in layers. If the local mail command cannot submit, inspect the sendmail-compatible path, mailer.conf, permissions, and local logs. If submission succeeds but delivery is queued, inspect DMA’s queue status, resolver, relay reachability, TLS negotiation, server response, and auth configuration. If the relay accepts the message but it does not arrive, investigate the receiving account’s spam or quarantine controls and the provider’s message trace.

A DNS lookup succeeding does not prove that TCP connection, TLS, authentication, relay policy, or final delivery will succeed. Test the correct endpoint and port from the same host and network path. Do not disable certificate verification or replace TLS with plaintext as a shortcut. If the provider rejects the sender or recipient, correct the authorized identity and routing rather than retrying indefinitely.

For scheduled jobs, distinguish a successful process exit from actual recipient delivery. Many local programs report only that mail was accepted for handling. Track delivery through queue state, mail logs, relay telemetry, or a controlled mailbox receipt. Configure alerts for sustained queue growth and failed periodic delivery; routine job output is not useful if the mail path is broken.

Queue handling and boot-time flushing

Use the mailq command to inspect queued messages and the DMA manual to understand supported queue options on the installed version. Do not delete queue files directly to make the queue look healthy; that can destroy evidence and lose operational messages. For an old message, inspect its age, recipient, sender, and last failure reason, then decide whether to retry, correct the cause, or remove it through a documented mailer interface.

The FreeBSD Handbook documents dma_flushq_enable=“YES” for flushing queued messages at boot or before shutdown. Enable it only after verifying the current rc.conf behavior and that a working network path and relay are available at the expected time. A queue-flush service cannot deliver mail while the interface or resolver is unavailable.

When planning a relay migration, preserve the original configuration, test the replacement endpoint with a limited message, confirm queue drainage, and keep the old route available until the acceptance criteria are met. Avoid modifying mailer.conf and DMA settings in the same uncontrolled step if the source of a failure would be ambiguous.

Local recipients, aliases, and system reports

Local mailboxes and aliases are separate from outbound SMTP authentication. Review /etc/aliases and the system’s supported alias database workflow when routing root’s mail to an administrator. Test alias expansion with a harmless sample and confirm that sensitive local reports do not reach an unauthorized external address.

System utilities such as periodic rely on a functional mail submission path. If mail is intentionally disabled, decide how reports will be captured and monitored instead of leaving jobs configured to send to an unread local mailbox. A local delivery success may put a message into a mailbox that nobody checks; it does not establish that the on-call team received it.

Keep local mailbox retention and queue retention separate. The delivery agent’s queue contains messages awaiting delivery; a user’s mailbox contains messages already delivered locally. Monitor both where they matter and define a retention policy that preserves operational evidence without allowing unbounded disk growth.

Validation and operational acceptance

Record the OS release, effective MTA, mailer.conf path, relay hostname and port, TLS mode, sender identity, test timestamp, mail log result, queue state, and receipt confirmation. Redact usernames or credentials as required. Verify that a test message survives a controlled reboot if DMA is expected to flush a queue at startup, and confirm that the normal mail submission interface still works for periodic jobs.

Acceptance means the host submits a message locally, the relay accepts the authenticated and encrypted session, the intended recipient receives the message, and queue or failure telemetry is visible to an operator. A process returning zero without an end-to-end receipt is insufficient for an alerting channel.

Use a maintained relay with a tested certificate chain and service-level monitoring. Rotate credentials using the provider’s current process, test the new credential before revoking the old one, and avoid logging secrets. If the host’s role expands from outbound relay to inbound mail hosting, redesign and review the service boundary rather than stretching DMA beyond its documented purpose.

Related:

Sources: