DEV Community

Cover image for Send email from any Linux server in 60 seconds — no SMTP config
Qasim Muhammad
Qasim Muhammad

Posted on

Send email from any Linux server in 60 seconds — no SMTP config

#linux #bash #tutorial #devops

You ssh'd into a fresh Linux box and you need to send an email. Maybe a backup completed. Maybe a deploy succeeded. Maybe a process crashed and you want a stack trace in your inbox.

The traditional path: install Postfix, edit main.cf, configure a smart relay, generate SASL credentials, restart the daemon, and pray nothing else on the box uses port 25. That is the 30-minute path.

The 60-second path:

curl -fsSL https://cli.nylas.com/install.sh | bash
~/.config/nylas/bin/nylas auth config --api-key YOUR_KEY
~/.config/nylas/bin/nylas email send --to you@example.com --subject hi --body "From $(hostname)"
Enter fullscreen mode Exit fullscreen mode

Three lines. Zero daemon. Works on every modern Linux distro and macOS.

Why the old path is so slow

Setting up outbound SMTP from scratch involves five separate concerns:

Concern Time Failure mode
Install Postfix or Exim 2 min Distro package conflicts
Configure relayhost 5 min Wrong port, blocked by ISP, DNS lookup
SASL auth to relay 10 min Hashing format, postmap regen
TLS to relay 5 min Cert path, CA bundle
Test send through queue 5 min mqueue stuck, tail /var/log/mail.log

Five places to get it wrong. Most people get it wrong twice before it works.

What the 60-second path skips

The CLI ships a static binary. No package dependencies, no system services, no firewall punches. The send happens over HTTPS to the Nylas API on port 443 — already open in 99% of environments.

Specifically, you are not:

  • Opening port 25 outbound (most cloud providers block this)
  • Setting up STARTTLS to a relay
  • Maintaining sender DKIM/SPF/DMARC keys (the API handles signing)
  • Writing config files in /etc/postfix

Real-world recipes

Cron job that emails on failure 

#!/usr/bin/env bash
if /usr/local/bin/run-backup.sh; then
  exit 0
fi

nylas email send --to oncall@yourcompany.com \
  --subject "[FAIL] backup on $(hostname)" \
  --body "$(date): backup failed. See /var/log/backup.log"
Enter fullscreen mode Exit fullscreen mode

systemd OnFailure handler 

# /etc/systemd/system/notify-failure@.service
[Unit]
Description=Notify on service failure for %i

[Service]
Type=oneshot
ExecStart=/usr/local/bin/nylas email send --to oncall@yourcompany.com \
  --subject "[%H] %i failed" \
  --body "Check journalctl -u %i for details"
Enter fullscreen mode Exit fullscreen mode 
# In any service that should notify on failure:
[Unit]
OnFailure=notify-failure@%n.service
Enter fullscreen mode Exit fullscreen mode

This is exactly the pattern the systemd man pages document for OnFailure, with one less moving part.

Deploy notification from CI 

nylas email send --to team@yourcompany.com \
  --subject "✅ Deploy v${VERSION} to prod" \
  --body "https://app.example.com/deploys/${DEPLOY_ID}"
Enter fullscreen mode Exit fullscreen mode

Shell trap on script exit 

trap 'nylas email send --to me@example.com --subject "rebuild done on $(hostname)" --body "exit code $?"' EXIT

./long-running-rebuild.sh
Enter fullscreen mode Exit fullscreen mode

What about mailx, msmtp, sendmail?

They are venerable, and on a single machine where you already have a working relay, they are fine. Where they hurt:

  • mailx needs an MTA underneath (Postfix, Exim). Nothing changes about the SMTP setup.
  • msmtp is itself an SMTP client, so you still maintain relay credentials and TLS.
  • sendmail is the historical command, usually backed by Postfix.

The Nylas CLI replaces all three for the "I need to send from a script" use case. There is no relay to maintain because the relay is the API.

The 60-second checklist 

# 1. Install
curl -fsSL https://cli.nylas.com/install.sh | bash

# 2. Add to PATH for the session
export PATH="$HOME/.config/nylas/bin:$PATH"

# 3. Auth
nylas auth config --api-key YOUR_KEY

# 4. Test
nylas email send --to you@example.com --subject hi --body "from $(hostname)"

# 5. Verify it landed (should be in your inbox in <30 sec)
Enter fullscreen mode Exit fullscreen mode

If step 5 worked, you are done. Add the binary location to a system-wide PATH (e.g., symlink to /usr/local/bin) if other users on the box need it.

A note for hardened environments

If your server has no outbound HTTPS — air-gapped, restricted egress firewall — the CLI cannot reach the API. In that case, ship messages to an internal queue (or a relay box that does have egress) and let that machine call the CLI. The CLI itself is not the bottleneck; outbound HTTPS is.

Otherwise, this is the cleanest "make this Linux box send mail" setup I have used.

Next steps

Top comments (0)