An SMTP relay server accepts outgoing email from applications, websites, and services and delivers it to external recipients — handling the connection management, retry logic, bounce processing, and queuing that makes email delivery reliable at scale. Understanding when you need a relay server, how to configure it, and how to secure it is fundamental email infrastructure knowledge for both developers building email-sending applications and email operations teams managing production sending infrastructure. This guide covers SMTP relay from the basics through production configuration.
SMTP Relay Overview: What It Does and Why You Need It
An SMTP relay is a mail server that accepts messages on behalf of clients (applications, websites, other mail servers) and delivers them to the final destination. The relay handles the operational complexity of email delivery: establishing connections to destination mail servers, managing TLS handshakes, processing 4xx temporary failures through retry queues, classifying 5xx permanent failures as bounces, and managing connection rate limits per destination domain.
Applications that send email without a relay — using PHP's mail() function, Python's smtplib connecting directly to the destination MX, or Node.js's nodemailer in direct delivery mode — are responsible for all of this delivery complexity themselves, and typically do it poorly. PHP mail() uses the local system's mail agent (often misconfigured for deliverability), and direct delivery scripts are rarely implemented with proper retry logic, bounce handling, or rate limiting.
An SMTP relay centralises this complexity in a dedicated component: applications send email to the relay using simple SMTP (authenticated submission on port 587), and the relay handles delivery optimisation, retry queuing, bounce classification, and the TLS requirements of modern email delivery. The relay is the operational boundary between "application sends email" and "email is correctly delivered to the recipient."
SMTP Relay vs Smarthost vs Direct Delivery
Three email delivery architectures for applications and servers:
Direct delivery: The sending server looks up the MX record for each recipient domain and connects directly to the destination mail server. No relay server involved. Requires: the sending server's IP to be whitelisted by the destination ISP (or have established reputation), correct PTR record, TLS capability, and the full retry and bounce-handling logic in the sending application. Appropriate for: high-volume production MTAs (PowerMTA) where full delivery control is needed.
Smarthost (relay to a single upstream): The sending server routes all outbound email to a single upstream SMTP service (Mailgun, Postmark, Gmail Workspace, or a corporate relay) for delivery. The smarthost handles all downstream delivery complexity. The sending server authenticates to the smarthost and does not need its own sending reputation. Appropriate for: web applications, WordPress sites, transactional email from application servers where simplicity and outsourcing delivery complexity is the priority.
Internal SMTP relay: A dedicated internal relay server (Postfix) accepts email from multiple application servers within the network and forwards to the internet or to a smarthost. The internal relay provides a single management point for authentication credentials, logging, and rate limiting across multiple applications. Appropriate for: infrastructure teams managing email for multiple internal applications that should not each have their own SMTP configuration.
Setting Up Postfix as an SMTP Relay
Postfix is the most widely used SMTP relay software. Configuration as an outbound relay with authentication to an upstream smarthost (Mailgun in this example):
# /etc/postfix/main.cf — Postfix as authenticated relay client # Relay host: route all outbound email to Mailgun's SMTP relayhost = [smtp.mailgun.org]:587 # SASL (Simple Authentication and Security Layer) configuration smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous # TLS for relay connection smtp_tls_security_level = encrypt smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtp_use_tls = yes # Relay access: only accept from local network and localhost inet_interfaces = loopback-only, 10.0.0.0/8 mynetworks = 127.0.0.0/8, 10.0.0.0/8 smtpd_relay_restrictions = permit_mynetworks, reject # The relay won't accept mail for local delivery mydestination = # /etc/postfix/sasl_passwd — credentials for Mailgun auth # [smtp.mailgun.org]:587 username@mg.yourdomain.com:API_KEY # After editing, run: postmap /etc/postfix/sasl_passwd
For a self-hosted relay that delivers directly (without upstream smarthost) — common for PowerMTA or production mail infrastructure:
# /etc/postfix/main.cf — Direct delivery relay myhostname = mail.brand.com mydomain = brand.com myorigin = $mydomain # No smarthost — deliver directly to destination MX relayhost = # Only accept from trusted networks inet_interfaces = loopback-only, 10.0.0.0/8 mynetworks = 127.0.0.0/8, 10.0.0.0/8 smtpd_relay_restrictions = permit_mynetworks, reject # TLS for outbound connections smtp_tls_security_level = may # Use TLS when available smtp_tls_mandatory_protocols = !SSLv2,!SSLv3
Authentication and Access Control for SMTP Relay
SMTP relay security is critical — an improperly secured relay that accepts connections from any IP is an "open relay" that spammers will discover and abuse within hours. Two authentication mechanisms for relay access control:
Network-based access control (for internal relays): Restrict acceptance of relay submissions to specific internal IP addresses or subnets. Applications on the internal network (10.0.0.0/8 or 192.168.0.0/16) submit through the relay; connections from external IPs are rejected. This approach works for relays serving only internal application servers but provides no access control between different application servers on the same internal network.
# Postfix: network-based access control mynetworks = 127.0.0.0/8, 10.0.0.100, 10.0.0.101, 10.0.0.102 smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination
SASL authentication (for any client location): Applications authenticate to the relay using a username and password before submitting email. This allows authenticated submission from any network location and provides per-application credential management. Configure the submission service (port 587) in Postfix's master.cf to require authentication:
# /etc/postfix/master.cf — submission port with SASL auth submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING # Install Dovecot for SASL backend: # apt-get install dovecot-core # Configure /etc/dovecot/conf.d/10-auth.conf for PLAIN/LOGIN mechanisms
TLS Configuration for Relay Security
TLS is required for all email relay connections — both for the incoming submission connection (application to relay) and the outgoing delivery connection (relay to destination). Configure TLS for both directions:
# TLS for incoming connections (clients connecting to the relay): smtpd_tls_cert_file = /etc/letsencrypt/live/mail.brand.com/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/mail.brand.com/privkey.pem smtpd_tls_security_level = may # Accept TLS; enforce on submission port smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1 smtpd_tls_ciphers = high smtpd_tls_mandatory_ciphers = high smtpd_tls_loglevel = 1 # TLS for outgoing connections (relay to destination MX): smtp_tls_security_level = may # TLS when available (use 'encrypt' if required) smtp_tls_mandatory_protocols = !SSLv2,!SSLv3 smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache smtp_tls_loglevel = 1
Rate Limiting and Queue Management
Rate limiting on the relay server prevents individual applications from overwhelming the relay's outbound capacity or triggering ISP rate limits by injecting too much volume too quickly:
# Postfix rate limiting configuration: # Limit messages from a single client per time unit smtpd_client_message_rate_limit = 1000 # Max 1000 messages/minute from any client # Outbound delivery limits: default_destination_concurrency_limit = 10 # Max concurrent connections per domain smtp_destination_rate_delay = 0 # No per-connection delay # Per-domain delivery limits for major ISPs: gmail.com_destination_concurrency_limit = 20 outlook.com_destination_concurrency_limit = 12 yahoo.com_destination_concurrency_limit = 15 # Queue configuration: maximal_queue_lifetime = 5d # Keep retrying for 5 days bounce_queue_lifetime = 1d # Bounce after 1 day of failure minimal_backoff_time = 300s maximal_backoff_time = 4000s
Monitoring and Logging the SMTP Relay
The Postfix relay logs all delivery events to /var/log/maillog (RHEL/AlmaLinux) or /var/log/mail.log (Debian/Ubuntu). Key monitoring commands:
# Real-time log monitoring: tail -f /var/log/maillog | grep -E "(status=|reject|warning)" # Queue status: mailq # List queued messages postqueue -p # Detailed queue listing postqueue -f # Flush queue (retry all deferred messages) # Statistics with pflogsumm (install: dnf install pflogsumm): pflogsumm /var/log/maillog --detail 5 # Daily summary report # Count delivery statuses for the current log: grep "status=sent" /var/log/maillog | wc -l # Delivered grep "status=bounced" /var/log/maillog | wc -l # Permanent failures grep "status=deferred" /var/log/maillog | wc -l # Temporary failures
Managed SMTP Relay vs Self-Hosted: When to Use Each
The decision between a managed SMTP relay service (Postmark, Mailgun, Amazon SES, SendGrid) and a self-hosted Postfix relay mirrors the broader self-hosted vs managed infrastructure decision, with additional considerations for relay-specific use cases:
Use a managed relay service when: the team does not have Linux/Postfix administration expertise; the use case is transactional email (password resets, notifications) where managed SLA (99.99% uptime) is commercially required; the relay needs to serve email from a publicly-hosted application (web app, SaaS product) rather than an internal network where network-based access control works; or delivery speed is critical (managed relay services have pre-warmed IPs with established reputation at all major ISPs).
Use a self-hosted Postfix relay when: the team has the Linux expertise to operate and maintain it; the relay serves only internal application servers on a private network; data sovereignty or compliance requirements prevent sending email through third-party services; or the volume is high enough that managed relay pricing exceeds the operational cost of a self-hosted server.
The hybrid architecture — Postfix on internal servers forwarding to a managed smarthost (Mailgun, Postmark) — provides the benefits of both: internal applications submit to the local Postfix relay using network-based access control (simpler than per-application SASL configuration), and the local relay forwards to the managed service for delivery. This gives the simplicity of network-based internal access control plus the managed deliverability infrastructure of a commercial ESP, without the security risk of exposing the ESP credentials directly to each application server.
SMTP relay setup is foundational email infrastructure knowledge that enables reliable email delivery from any application, server, or service. The configurations in this guide produce a production-ready relay that delivers email with proper TLS, correct access control, appropriate rate limiting, and full delivery logging -- the operational baseline that makes email delivery reliable rather than intermittent, and secure rather than exploitable.
The correctly configured SMTP relay becomes invisible in the infrastructure stack -- it simply accepts email from applications and delivers it reliably, quietly, without generating operational incidents. That invisibility is the operational excellence goal: infrastructure that works so reliably that it generates no tickets, no incident alerts, no deliverability investigations. The configurations in this guide are the starting point for achieving that invisibility; the ongoing monitoring practices are the discipline that maintains it over time as the applications sending through the relay evolve and the email volumes grow.
Security Checklist for SMTP Relay Deployment
Before deploying any SMTP relay to production, verify this security checklist: (1) Relay restrictions configured -- the relay only accepts connections from authorised sources (mynetworks or SASL authenticated clients), not from any IP on the internet. Run an open relay test at mxtoolbox.com/diagnostic.aspx after deployment to confirm the relay is not an open relay. (2) TLS enabled on the submission port -- applications connecting to the relay should use TLS-encrypted connections on port 587, not unencrypted port 25. (3) Firewall rules configured -- port 25 should be accessible from the internet only if the relay accepts direct MX delivery; the submission port (587) should be restricted to known application server IPs at the firewall level as an additional layer beyond SASL authentication. (4) Log rotation configured -- mail logs can fill disk space rapidly at high volume; configure logrotate to rotate and compress mail logs daily.
SMTP relay operations at production scale require the monitoring and maintenance discipline documented throughout this guide -- not as one-time setup but as ongoing operational practice. The relay that is correctly configured, actively monitored, and regularly maintained becomes the reliable backbone of the email programme's sending infrastructure, invisibly handling the delivery complexity that would otherwise fall on individual applications and services.
Email delivery infrastructure -- whether a single Postfix relay serving one web application or a distributed multi-relay architecture serving dozens of applications across multiple datacenters -- works on the same fundamental principles: accept email from authorised sources, authenticate it correctly, deliver it reliably with appropriate retry logic, and provide visibility through logging. The guide above documents these principles in production configuration; the operational discipline of monitoring, maintaining, and evolving the configuration is what keeps the relay performing reliably as requirements grow and change over time.
Begin with the simplest configuration that meets the immediate need -- typically a Postfix smarthost relay configured to forward to a managed ESP -- and evolve toward more complex self-hosted delivery as volume and expertise grow. The configurations in this guide scale from the simple (single application, managed smarthost) to the complex (multi-application, direct delivery, custom domain blocks), and the operational principles remain consistent across all scales.