Linux can send mail easily. Getting that mail accepted and trusted is the harder part. If you only need password resets, form notifications, cron alerts, or system messages, the goal is usually not to build a full mail platform. The goal is to send small volumes reliably, with clear DNS, sane Postfix settings, and a delivery path that modern providers will accept. The examples below assume Ubuntu or Debian, Postfix, and GNU Mailutils.
Start with the right delivery model
Before editing main.cf, decide whether this server should send directly to the internet or hand mail to a relay. Direct delivery can work for small operational mail, but it now comes with more requirements than it used to: proper host naming, forward and reverse DNS, SPF, DKIM, and ideally DMARC. For most businesses and agency teams, a relay service is the safer default because it reduces deliverability risk and avoids queue debugging on production servers.
If you are on a cloud VM, do not assume outbound port 25 is open. It often is not. A quick connectivity check still helps, but failure may be your provider policy rather than a Postfix mistake.
Minimal Postfix setup for an outbound-only host
The original article used the bare domain as the hostname. In practice, that is usually the wrong shape. Use a real mail host such as mail.example.com, not just example.com. That host should resolve in DNS and its PTR record should point back to the same name.
If the server only needs to send application mail and should not receive mail from the internet, a lean Postfix setup looks like this:
myhostname = mail.example.com
myorigin = example.com
mydestination = $myhostname, localhost.$mydomain, localhost
relayhost =
inet_interfaces = loopback-onlyThat tells Postfix to identify itself as a fully qualified host, send local mail as your main domain, deliver only local system mail to itself, and avoid listening publicly if the box is outbound-only. If you plan to use a relay, replace relayhost = with your provider endpoint, for example relayhost = [smtp-relay.gmail.com]:587 when using a TLS-enabled Google Workspace relay.
On Debian and Ubuntu, it is also sensible to keep /etc/mailname aligned with your sender domain. Use /etc/hosts only to make local name resolution sane; it does not replace public DNS.
After most changes, reload Postfix instead of doing a full restart:
sudo postfix reloadIf you change inet_interfaces, do a full restart because listener changes need more than a reload.
Useful install and test commands
If the required tools are not installed yet:
sudo apt install mailutils postfixTo inspect the non-default Postfix configuration:
postconf -nTo test basic SMTP reachability to Gmail's MX, you can still use the old check, or a slightly cleaner modern equivalent:
telnet gmail-smtp-in.l.google.com 25
nc -vz gmail-smtp-in.l.google.com 25That only proves network connectivity. It does not prove your messages will be delivered. For a live send test, keep the command simple and use a real sender address from your domain:
echo "Test from $(hostname -f)" | mail -s "Test Email" \
-a "From: Alerts <[email protected]>" \
[email protected]If you prefer to set the return address explicitly, Mailutils also supports -r:
echo "Nightly check" | mail -s "Server Status" -r [email protected] [email protected]Then watch the mail log while you test:
sudo tail -f /var/log/mail.logDeliverability checks that matter now
This is where most “it works on the server” mail setups still fail.
- Use a real FQDN for
myhostname, and make sure forward DNS and reverse DNS match. - Publish SPF for your sending domain. If you send direct and through a relay or SaaS tool, include all legitimate senders.
- Enable DKIM if the volume or importance of the mail justifies it. Even for low-volume business mail, it is now a sensible baseline.
- Publish a DMARC record so receivers know how to treat unauthenticated mail claiming to be from your domain.
- Prefer a TLS-enabled relay on port 587 when your server is in AWS or another environment where port 25 may be restricted.
- Keep the visible
From:domain consistent with the domain you authenticate. Mismatched sender identities are a common reason for spam placement.
Google's current sender guidance is a good practical benchmark even if your recipients are not all on Gmail: authenticated mail, valid PTR records, and clean sender identity are no longer optional if you want reliable inbox placement.
When a relay is the better business decision
If your site sends password resets, contact-form notifications, invoices, or agency workflow emails, running direct outbound SMTP is often more operational burden than benefit. A relay service usually gives you better deliverability, easier rate management, and fewer production surprises. Keep direct delivery for the cases where you actually need it and can own the DNS and reputation work around it.
If you want this implemented cleanly, Greg can help with the practical pieces that usually get missed: hostname and DNS alignment, Postfix setup, relay selection, test flows, and production verification without turning a small mail task into a week of troubleshooting.
Need help with this kind of work?
Need the mail server, DNS, and relay details handled properly? Contact Greg for a practical setup or delivery audit. Get in touch with Greg.