Send Email From Your VPS With a Postfix SMTP Relay

Sooner or later your VPS needs to send email. A cron job that fails wants to tell you. Fail2Ban wants to report a ban. Your Laravel or Django app wants to send a password reset. Netdata wants to alarm. The naive fix - point everything at localhost:25 and hope - almost never works on a modern VPS, because most providers block outbound port 25 and every big mailbox provider treats a fresh datacenter IP as guilty until proven innocent.

Running a full mail server to fix this is the wrong tool. You don't want to accept inbound mail, manage mailboxes, or babysit an IP reputation. You want the opposite: a small, send-only setup that hands every outgoing message to a real SMTP provider - Amazon SES, Mailgun, Postmark, Brevo, Fastmail, even a Gmail app password - and lets them deal with deliverability.

That's exactly what Postfix in "satellite" mode does. This guide installs it, wires it to a provider over authenticated TLS, rewrites the sender address so mail passes SPF and DKIM, routes root and cron mail to your real inbox, and tests the whole chain. About 20 minutes, and every process on the box can send mail that actually arrives.

TL;DR

• Install Postfix in Satellite system mode - it relays everything, accepts nothing from outside
• Set relayhost to your provider's submission endpoint ([smtp.provider.com]:587)
• Store the SMTP username and password in /etc/postfix/sasl_passwd, then postmap it and chmod 600
• Turn on SASL auth and mandatory TLS so credentials never cross the wire in the clear
• Rewrite the envelope and header sender to a verified address so SPF and DKIM pass
• Alias root to your real email so cron and system warnings reach you
• Publish SPF, DKIM, and DMARC DNS records for the provider you chose
• Test with sendmail and read /var/log/mail.log

What You Need

• A VPS running Ubuntu 22.04 or 24.04 with root or sudo access
• A transactional email provider account. Any of these work - pick one:
  • Amazon SES, Postmark, Mailgun, Brevo (Sendinblue), Mailjet, Resend/SMTP, SMTP2GO
  • Or a mailbox provider that offers SMTP submission: Fastmail, Gmail (with an app password)
• The provider's SMTP hostname, port 587, and a username + password (often an API key)
• A domain you control, with access to its DNS records
• 128 MB of free RAM - Postfix is tiny

Step 1: Install Postfix in Satellite Mode

Install Postfix along with the SASL modules it needs to authenticate to the provider:

The installer shows a blue configuration screen. Two answers matter:

• General mail configuration type: choose Satellite system. This tells Postfix it will forward all mail to a smart host and never accept mail from the network.
• System mail name: enter your domain, for example example.com.

If you missed the dialog or want to redo it, run:

At this point Postfix is running but not yet pointed at your provider. Confirm it's alive:

Step 2: Point Postfix at Your Provider

Open the main config:

Find and set the relayhost line - the square brackets tell Postfix to skip an MX lookup and connect directly to that host:

Swap in your provider's submission endpoint. A few common ones:

• Amazon SES: [email-smtp.<region>.amazonaws.com]:587
• Postmark: [smtp.postmarkapp.com]:587
• Mailgun: [smtp.eu.mailgun.org]:587 (or the US host)
• Brevo: [smtp-relay.brevo.com]:587
• Fastmail: [smtp.fastmail.com]:587
• Gmail: [smtp.gmail.com]:587

Now add the authentication and TLS block at the bottom of the same file:

The smtp_tls_security_level = encrypt line is important: it makes TLS mandatory, so Postfix refuses to send your password to a server that can't encrypt the connection.

Step 3: Store the SMTP Credentials

Create the password file. The format is [host]:port username:password:

Use the exact same host and port you put in relayhost. For Gmail the username is your full address and the password is an app password, not your account password.

Now hash the file into the database Postfix reads, then lock the permissions:

The postmap command produces sasl_passwd.db next to it - that's the file Postfix actually uses. Any time you edit the plaintext version, re-run postmap.

Step 4: Rewrite the Sender So Mail Passes SPF and DKIM

By default, cron and system mail goes out as root@your-vps-hostname. Your provider has never heard of that address, so it fails their sender checks and either bounces or lands in spam. You need every message to appear to come from an address on your verified domain.

Set up a generic address map that rewrites local senders:

Replace your-vps-hostname with the output of hostname -f. Hash it:

Then tell Postfix to use it by adding this to main.cf:

Now outgoing mail carries [email protected] in the envelope and headers, which is an address your provider recognizes and signs with DKIM.

Step 5: Route Root and Cron Mail to Your Inbox

System warnings - a full disk, a failed cron job, a package that needs attention - are addressed to root. Forward them to an address you actually read:

Add or edit the last line:

Rebuild the alias database:

Combined with the sender rewrite from Step 4, a message to root now goes out as [email protected] and arrives in your [email protected] inbox.

Step 6: Apply the Config and Send a Test

Reload Postfix so every change takes effect:

Send yourself a test message. The mail command comes from the mailutils package you installed earlier:

Immediately watch the log to see the handoff:

A successful relay looks like this:

status=sent with a 250 reply means the provider accepted the message. Check your inbox - and the spam folder the first time.

Step 7: Publish the DNS Records That Keep You Out of Spam

Handing mail to a reputable provider gets you most of the way, but the receiving mailbox still checks that your domain authorized that provider to send on its behalf. Add three records to your domain's DNS. The exact values come from your provider's dashboard - these are the shapes:

SPF - one TXT record on the root domain listing who may send. If you already have one, add the provider's include, don't create a second SPF record:

DKIM - your provider gives you one or more CNAME or TXT records to publish. They let the provider cryptographically sign your mail. SES, for example, hands you three CNAMEs; Postmark and Mailgun give you a TXT selector.

DMARC - a TXT record on _dmarc.example.com that tells mailboxes what to do with mail that fails the checks. Start in monitoring mode:

Verify the sender domain inside your provider's console before you rely on it - most require you to click "verify" once the DKIM records propagate. Once SPF and DKIM both pass, tighten DMARC to p=quarantine and later p=reject.

Troubleshooting

• status=bounced ... 535 Authentication failed - the username or password in sasl_passwd is wrong, or you forgot to postmap after editing it. Re-check the credentials, re-run sudo postmap /etc/postfix/sasl_passwd, and restart Postfix.
• Connection timed out to port 587 - your provider is firewalling outbound 587, or you left the port as 25. Try the provider's alternate port (often 2587 or 465 with smtp_tls_wrapper_mode = yes).
• Mail sends but lands in spam - SPF or DKIM isn't passing. Send a message to [email protected] or use mail-tester.com and read which check failed.
• Sender address rejected: not owned by user - the provider requires the From address to be verified. Confirm Step 4's rewrite is active (postconf smtp_generic_maps) and that [email protected] is verified in the dashboard.
• fatal: open database /etc/postfix/sasl_passwd.db: No such file - you never ran postmap. Run it, then restart Postfix.

Going Further

• Send from your apps. Point Laravel (MAIL_MAILER=sendmail), Django, or any framework at the local Postfix instead of embedding SMTP credentials in every app's config. One relay, one place to rotate the key.
• Alert on failures. Pipe Fail2Ban and cron output through this relay, then watch the box itself with Uptime Kuma or Netdata so a broken relay doesn't fail silently.
• Harden the host. A box that holds an SMTP API key deserves a locked-down front door - see our SSH hardening and Fail2Ban guide.
• Rotate the key. Treat the provider password like any secret. Store it in a self-hosted vault - our Vaultwarden guide covers exactly that - and swap it on a schedule.

A send-only Postfix relay is one of those small setups you configure once and forget, right up until the day a disk fills or a backup fails and the warning email actually lands in your inbox. That's the whole payoff: your server can finally talk to you.

Need a VPS that can reliably send its own mail? Our Linux plans include a static IP, IPv6, full root access, and generous bandwidth - everything a Postfix relay needs. See the options.