Sending mail from Linux is easy. Sending mail that actually arrives is the operational work. If this server only needs to send password resets, contact-form notices, cron alerts, invoice notifications, or internal workflow messages, your goal is not to become a mail provider. Your goal is to deliver low-volume mail consistently, with minimal maintenance and no surprise queue issues on a production box.
For most businesses and agency teams, the right answer is a small, boring Postfix setup with clear DNS and a relay when appropriate. The examples below assume Ubuntu or Debian, Postfix, and GNU Mailutils.
Choose the delivery model before you tune Postfix
Start with one decision: will this server deliver directly to the internet, or hand messages to an SMTP relay? Direct delivery gives you control, but it also makes you responsible for hostname quality, forward and reverse DNS, authentication, reputation, queue monitoring, and cloud provider network limits. That is a lot of moving parts for a server that mainly needs to send app mail.
If the mail is business-critical but low volume, an SMTP relay is usually the safer default. It reduces deliverability risk, avoids a lot of troubleshooting, and fits how most modern SaaS and production stacks work. Direct delivery still makes sense when you intentionally operate mail infrastructure and can own the DNS and reputation work around it.
Check your hosting environment early as well. On AWS EC2, outbound port 25 to public addresses is still restricted by default. If you assume direct SMTP will work and your provider blocks port 25, you can lose hours debugging the wrong layer.
Use a lean Postfix configuration for outbound-only mail
Do not use the bare domain as the server hostname. Postfix should identify itself with a real fully qualified host such as mail.example.com. For an outbound-only server, keep the configuration tight and resist the urge to make it look complete by adding unnecessary local domains.
myhostname = mail.example.com
myorigin = example.com
mydestination = $myhostname, localhost.$mydomain, localhost
relayhost =
inet_interfaces = loopback-onlyThis does four useful things. It gives Postfix a proper FQDN, makes locally generated mail appear from your main domain, keeps local delivery limited to the host itself, and avoids listening publicly when the box only needs outbound mail. One common mistake is adding your whole business domain to mydestination even though this server is not supposed to receive mail for that domain. That can create confusing local-delivery behavior.
If you are relaying mail, set relayhost to your provider endpoint instead. For example:
relayhost = [smtp-relay.gmail.com]:587On Debian or Ubuntu, it is also sensible to keep /etc/mailname aligned with your sender domain. Use your provider’s documented TLS and authentication settings rather than pasting a generic SASL snippet from an old blog post. After most changes, reload Postfix with sudo postfix reload. If you changed inet_interfaces, do a full restart instead: sudo systemctl restart postfix.
Install, inspect, and run a real send test
Keep the toolchain simple. On Ubuntu or Debian:
sudo apt update
sudo apt install postfix mailutilsCheck the effective non-default Postfix configuration with:
postconf -nIf you want to test basic network reachability for direct SMTP, use:
nc -vz gmail-smtp-in.l.google.com 25That only proves connectivity. It does not prove your mail will be accepted or placed in the inbox. A better operational test is to send a real message from your own domain and then watch the log:
echo "Test from $(hostname -f)" | mail -s "Postfix test" \
-a "From: Alerts <[email protected]>" \
[email protected]
echo "Nightly check" | mail -s "Server status" -r [email protected] \
[email protected]
sudo tail -f /var/log/mail.log
sudo postqueue -pUse -a when you want to set the visible From: header. Use -r when you need to set the return address explicitly. These examples assume GNU Mailutils, which matters because the mail command differs between implementations and the -a behavior shown here is specific to Mailutils.
If the message stays queued, read the delivery reason in /var/log/mail.log before changing settings blindly. Most failures are DNS, authentication, TLS, or provider policy problems, not missing packages.
Deliverability basics that are no longer optional
Modern receivers expect more than a server that can open port 25. At minimum, make sure these pieces are in place:
- Use a real FQDN for
myhostname, and make sure forward DNS and PTR or reverse DNS point to the same identity. - Publish SPF for the sending domain and include every legitimate sender, whether that is this server, a relay provider, or a SaaS platform.
- Use DKIM whenever your relay or mail flow supports it. For higher-volume sending to Gmail, SPF and DKIM plus DMARC are baseline requirements.
- Publish a DMARC record, even if you start with monitoring only. It helps you see who is sending as your domain and whether alignment is working.
- Keep the visible
From:domain aligned with the domain authenticated by SPF or DKIM. A technically signed message can still fail DMARC if the domains do not line up. - Prefer TLS-enabled submission or relay on port 587 when possible, especially in cloud environments where port 25 may be restricted.
The practical takeaway is simple: if password resets, client notifications, or agency workflow mail matter, treat sender identity and DNS as part of the application, not as an afterthought on the server.
When a relay is the better business decision
If your team does not want to spend time reading queue logs, maintaining sender reputation, or handling provider-specific edge cases, use a relay. That is usually the right operational choice for websites, apps, agencies, and internal tools that send modest volumes of important mail. Keep direct delivery for cases where you genuinely need it and are willing to own it.
If you want this set up without turning a small email task into a week of DNS and SMTP troubleshooting, Greg can help with the practical pieces that usually get missed: hostname and PTR alignment, Postfix configuration, relay selection, sender authentication, and production verification. Contact Greg for a setup review or delivery audit.
Need help with this kind of work?
Talk to Greg about a mail delivery setup or audit Get in touch with Greg.