By Greg Nowak. Updated 10 September 2026.
A password reset that never arrives becomes a support request. A missing invoice delays payment. Installing Postfix is straightforward; making email dependable means checking the whole journey from application to recipient.
For most business websites and agency-managed servers, I recommend Postfix with an authenticated SMTP relay. Postfix accepts local messages and queues them for retry. The provider handles onward delivery. Your team still owns sender authentication, application settings, and noticing when delivery fails.
Choose the delivery model before configuring the server
| Approach | Choose it when | Your operational responsibility |
|---|---|---|
| Postfix with SMTP relay | Applications and scripts need local mail submission and queueing | Server queue, relay credentials, sender DNS, and bounce handling |
| Provider API | The application already has a maintained integration | Application retries, API credentials, and delivery events |
| Direct SMTP delivery | Your team deliberately operates public mail infrastructure | Outbound port 25 access, IP reputation, reverse DNS, abuse, and receiver policies |
Before choosing a relay, check its sending limits, permitted message types, domain verification, and access to delivery logs. Confirm who controls the provider account and DNS, particularly when an agency manages a client's infrastructure.
Configure Postfix for local submission
This example assumes a dedicated outbound service on Debian or Ubuntu, with applications running on the same host. Back up existing configuration before editing. If the machine already receives email, review that role before applying these settings.
sudo apt update
sudo apt install postfix mailutils libsasl2-modules ca-certificates
postconf -m
postconf default_database_typeThe example uses hash lookup tables. Confirm that postconf -m lists hash; otherwise use a supported indexed type consistently in the configuration and postmap command, with its corresponding database filename.
Adapt these settings in /etc/postfix/main.cf, replacing the example hostname, domain, and provider endpoint:
myhostname = app01.example.com
myorigin = example.com
mydestination =
inet_interfaces = loopback-only
relayhost = [smtp.provider.example]:587
smtp_tls_security_level = secure
smtp_tls_secure_cert_match = nexthop
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_wrappermode = no
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwdThis follows Postfix's outbound-only configuration pattern: mydestination disables local mailbox delivery, while loopback-only restricts SMTP listening to the host. Containers with separate network namespaces need an explicit submission design; their localhost is different.
The brackets select the relay endpoint without an MX lookup. Port 587 normally uses STARTTLS. For a provider requiring implicit TLS on port 465, change the port and set smtp_tls_wrappermode = yes.
Verify the relay's identity as well as encrypting traffic. Postfix's TLS documentation explains that encrypt permits untrusted or mismatched certificates. Here, secure and nexthop require a trusted certificate matching the configured endpoint. This suits a known relay; it is not a general configuration for direct Internet delivery. Resolve certificate or CA errors before proceeding.
Add credentials and validate the configuration
Use the provider's SMTP credentials, which may differ from its dashboard login. Create or edit the file without truncating existing entries:
sudo sh -c 'umask 077; touch /etc/postfix/sasl_passwd'
sudo chmod 600 /etc/postfix/sasl_passwd
sudoedit /etc/postfix/sasl_passwdAdd the endpoint and credentials:
[smtp.provider.example]:587 USERNAME:PASSWORDThe lookup key must match relayhost, including brackets and port. Build the database using the explicitly selected type:
sudo postmap hash:/etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
sudo postfix check
sudo systemctl restart postfix
postconf -nFollow the Postfix SASL guidance for authentication and lookup tables. Protect both credential files in backups, and rebuild the database after credential changes. Configuration checks catch some setup errors; they do not prove authentication or delivery works.
Test an actual customer journey
First send a controlled message to an external mailbox you own, using an authorised sender:
echo "Test from $(hostname -f)" | mail \
-s "Postfix delivery test" \
-a "From: Alerts <[email protected]>" \
-r [email protected] \
[email protected]These are GNU Mailutils options: -a appends a header and -r sets the return address. Other programs named mail can interpret these flags differently.
sudo postqueue -p
sudo tail -f /var/log/mail.logIf your system logs to the journal instead, use sudo journalctl -f and locate the Postfix daemon messages. A view limited to the service unit may omit mail transactions.
Trace the queue ID to the relay response. With this setup, status=sent means the relay accepted the message. Check provider events, the recipient mailbox, spam placement, and authentication headers too. Then trigger the real password reset, enquiry, or invoice workflow: the application may use different credentials or bypass Postfix entirely.
Make sender authentication part of deployment
Google's sender guidelines require SPF or DKIM for all senders to personal Gmail accounts, and SPF, DKIM, and DMARC for bulk senders. Configure all three as your baseline:
- Verify the sending domain with the provider and enable DKIM signing.
- Publish one SPF record per relevant domain, covering its authorised sending services.
- Ensure the visible From domain aligns with the domain authenticated by SPF or DKIM.
- Start DMARC with reporting and a monitoring policy; review legitimate senders before tightening enforcement.
The relay provider normally manages reverse DNS for its outbound delivery IPs. Your application server does not become a receiving mail server merely because it sends messages.
Give delivery a named owner
Monitor queue growth and the oldest deferred message. Fix authentication failures, timeouts, or provider limits before repeatedly flushing the queue. Use a working return address or process provider bounce events, and route critical delivery alerts through an independent channel.
For agency handover, record the account owner, DNS access, credential rotation procedure, and tested application workflows. Repeat delivery checks after migrations or provider changes.
If responsibility is scattered across hosting, application code, and DNS, Greg can help review the setup and turn the findings into a practical implementation plan. Get in touch with Greg about your mail delivery setup.
Related on GrN.dk
- Sending Mail with Drupal: A Reliable Setup for Business-Critical Email
- Enable TLS on a Linux Mail Server Without Breaking Delivery
- Before Your Support Bot Learns the Help Center, Test Whether It Can Forget
Need help with this kind of work?
Ask Greg to review your mail delivery setup Get in touch with Greg.
