Sending Mail from a Linux Server with Postfix: A Reliable, Relay-First Setup

By Greg Nowak. Last updated 2026-07-10.

Installing Postfix is easy. Making sure password resets, contact-form notifications, invoices, and server alerts consistently reach people is the real job.

For most businesses and agency-managed servers, Postfix should be a small outbound-only component, not a complete email platform. Its job is to accept mail from local applications, queue it safely, and hand it to a trusted SMTP relay. Direct internet delivery remains possible, but it brings responsibility for DNS, reputation, network access, authentication, and ongoing monitoring.

Choose the delivery model before configuring Postfix

The important decision is not which package to install. It is who will own the difficult parts of email delivery.

Delivery model	Good fit	Your operational responsibility
Authenticated SMTP relay	Websites, business applications, agency servers, alerts, and low-volume transactional mail	Postfix configuration, relay credentials, verified sender domains, DNS records, and queue monitoring
Direct delivery	Teams intentionally operating mail infrastructure with stable IP addresses and mail expertise	Everything above, plus PTR records, port 25 access, IP reputation, abuse handling, and receiver-specific failures
Application API	Applications already integrated with a transactional email provider	API credentials, retries, bounce handling, and provider monitoring; Postfix may not be needed

A relay is usually the least risky default when email matters but operating a mail service is not part of the business.

Check the hosting network before attempting direct delivery. Amazon EC2, for example, blocks outbound port 25 to public IPv4 and IPv6 addresses by default. Other providers apply their own restrictions. Submission to a relay over port 587 is often the simpler route.

Build a lean outbound-only configuration

On Debian or Ubuntu, install Postfix, GNU Mailutils, and the SASL modules commonly needed for authenticated relays:

sudo apt update
sudo apt install postfix mailutils libsasl2-modules

Use a real fully qualified hostname. An application server might identify itself as app01.example.com; the bare domain example.com is not a suitable machine hostname.

A practical null-client configuration in /etc/postfix/main.cf starts like this:

myhostname = app01.example.com
myorigin = example.com
mydestination =
inet_interfaces = loopback-only
relayhost = [smtp.provider.example]:587

smtp_tls_security_level = encrypt
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

An empty mydestination is deliberate: this server is not responsible for local mailboxes. Square brackets around the relay hostname prevent Postfix from performing an MX lookup. Replace the example endpoint and port with values from the provider’s documentation; some providers use STARTTLS on 587, while others offer wrapper TLS on 465.

Create the credentials file with restrictive permissions:

sudo install -m 0600 /dev/null /etc/postfix/sasl_passwd
sudoedit /etc/postfix/sasl_passwd

Add one line whose endpoint exactly matches relayhost:

[smtp.provider.example]:587 USERNAME:PASSWORD

Then build the lookup database, validate the configuration, and restart Postfix:

sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd*
sudo postfix check
sudo systemctl restart postfix

Treat this file as a production secret. Restrict backups, document who owns the relay account, and have a process for rotating the credential. If inet_interfaces changes, restart rather than merely reload Postfix.

For direct delivery, leave relayhost empty, omit the SASL settings, and use opportunistic outbound TLS rather than applying a relay-only mandatory-TLS configuration to every public mail server:

relayhost =
smtp_tls_security_level = may

Run a test that exercises the real path

Start by reviewing the effective non-default configuration:

postconf -n
sudo postfix check

Next, send to an external mailbox using the same sender domain the application will use:

echo "Test from $(hostname -f)" | mail \
  -s "Postfix delivery test" \
  -a "From: Alerts <[email protected]>" \
  -r [email protected] \
  [email protected]

These flags assume GNU Mailutils. Here, -a adds the visible From: header and -r sets the return address. Other implementations of the mail command may interpret their options differently.

Inspect both the logs and queue instead of treating a successful command exit as proof of delivery:

sudo tail -f /var/log/mail.log
sudo journalctl -f --grep=postfix
sudo postqueue -p

Log availability varies by distribution and logging configuration, so use whichever log command produces Postfix events. A queued message includes a reason: authentication errors, TLS failures, DNS problems, connection timeouts, and recipient rejections require different fixes. Do not repeatedly flush the queue before addressing that reason.

Authentication and DNS are part of the application

Google currently requires SPF or DKIM for all senders to Gmail and requires SPF, DKIM, and DMARC for bulk senders. For important business mail, configuring all three is a sensible baseline even at low volume.

Publish one SPF policy that includes every legitimate sender for the domain.
Enable DKIM through the relay provider or sign messages in your own mail flow.
Publish DMARC and collect reports before moving to a restrictive policy.
Keep the visible From: domain aligned with the domain authenticated by SPF or DKIM.
For direct delivery, ensure the sending IP has a PTR hostname whose A or AAAA record resolves back to that IP.

A relay can reduce reputation and networking work, but it cannot compensate for an unverified sender domain or contradictory DNS records. It also cannot guarantee inbox placement.

Make delivery failure visible

Production readiness means more than completing one test. Monitor queue age and size, route the envelope sender to a mailbox that someone checks, and alert when messages remain deferred. Re-test after DNS changes, credential rotation, server migration, or relay-provider changes.

If email supports sales enquiries, customer access, billing, or operational response, assign an owner for the whole path—from the application’s sender address to the recipient and any resulting bounce. “Postfix accepted it” is only the start of that path.

Need a second pair of eyes?

Greg can review the delivery model, Postfix configuration, relay security, sender authentication, DNS alignment, and production test path. If a small mail task is turning into an unclear infrastructure project, get in touch for a practical setup review.

Related on GrN.dk

Need help with this kind of work?

Ask Greg to review your mail setup Get in touch with Greg.

Sources

Last modified

2026-07-10