Email Infrastructure Setup: Exim Configuration on Linux VPS (Complete Sysadmin Playbook)

Configuring Exim as a production mail transport agent on a Linux VPS requires precision: one misconfigured ACL or transport rule can turn your server into an open relay or cause legitimate mail to vanish into queue purgatory. This playbook gives sysadmins a complete, production-ready Exim configuration for a VPS environment—covering everything from basic installation to advanced ACLs, SMTP authentication, TLS hardening, and relay architecture. Whether you're building a standalone mail server or integrating Exim into a cPanel/WHM ecosystem, these configurations are tested on Debian/Ubuntu and CentOS/RHEL systems running on ENGINYRING Virtual Servers, which provide the dedicated resources and network stability that mail servers demand.

Unlike Postfix's monolithic architecture, Exim uses a router-transport model that gives fine-grained control over mail flow. This granularity is powerful but demands exact configuration. We'll configure Exim to handle local delivery, outbound relay through a smarthost, SMTPAUTH for client submission, and comprehensive ACLs to block spam and unauthorized relay attempts—all while maintaining the performance and reliability your VPS hosting customers expect. For broader context on keeping your VPS secure while running mail services, see our comprehensive VPS security guide.

Installation and initial configuration

Before touching Exim's configuration files, verify your VPS meets the prerequisites: a clean Linux installation (Debian 11/12, Ubuntu 22.04/24.04, or CentOS 8+/RHEL 9), a static public IP with proper PTR record, and DNS MX/SPF records configured for your domain. Misconfigured DNS is the root cause of 80% of mail delivery failures. Our guide on DNS records fundamentals covers the basics you need before sending a single email.

Package installation

# Debian/Ubuntu
sudo apt update && sudo apt install exim4 exim4-daemon-heavy exim4-config

# CentOS/RHEL
sudo dnf install exim

Use exim4-daemon-heavy on Debian/Ubuntu for full feature support including content scanning and advanced ACLs. The light variant strips critical functionality needed for production anti-spam and authentication.

Initial configuration wizard

Run Exim's configuration wizard to establish baseline settings:

sudo dpkg-reconfigure exim4-config  # Debian/Ubuntu only

• Select "mail sent by smarthost; no local mail" for relay-only setups
• Select "internet site; mail is sent and received directly using SMTP" for full mail server
• Enter your VPS FQDN (e.g., mail.yourdomain.com)
• Specify IP addresses to listen on (leave blank for all IPv4)
• Define other destinations for which mail is accepted
• Configure smarthost if using relay (e.g., smtp.sendgrid.net::587)
• Keep number of DNS queries minimal: Yes (reduces latency)
• Split configuration into smaller files: Yes (enables modular management)

This wizard generates /etc/exim4/update-exim4.conf.conf (Debian/Ubuntu) or /etc/exim/exim.conf (CentOS/RHEL). The split configuration model creates separate files under /etc/exim4/conf.d/ for routers, transports, and ACLs—use this for production environments. For detailed PTR record configuration, which is critical for mail deliverability, reference our tutorial on how to configure rDNS and PTR records.

Core architecture: routers and transports

Exim's mail flow follows a strict pipeline: routers determine destination, and transports execute delivery. Misconfiguration at any stage breaks the chain. We'll configure each component for a typical VPS scenario: local delivery for system users, outbound relay through a smarthost, and SMTP submission for authenticated clients.

Router configuration (local delivery)

Routers handle mail routing decisions including local delivery to system users. Edit /etc/exim4/conf.d/router/00_exim4-config_local_user (Debian/Ubuntu) or add to /etc/exim/exim.conf (CentOS/RHEL):

# Local user delivery router
localuser:
  driver = accept
  check_local_user
  domains = +local_domains
  transport = local_delivery
  cannot_route_message = Unknown user

This router accepts mail for local domains and passes it to the local_delivery transport. The check_local_user option verifies the recipient exists in /etc/passwd, preventing bounce loops.

Router configuration (outbound routing)

For VPS setups, configure smart host routing for outbound and DNS-based routing for inbound. Edit /etc/exim4/conf.d/router/200_exim4-config_primary:

# Smarthost router (outbound)
send_via_smarthost:
  driver = manualroute
  domains = !+local_domains
  transport = remote_smtp_smarthost
  route_list = * smtp.sendgrid.net::587
  host_find_failed = defer
  same_domain_copy_routing = yes
  no_more

# DNS lookup router (direct delivery)
dnslookup:
  driver = dnslookup
  domains = !+local_domains
  transport = remote_smtp
  ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
  no_more

The first router forces outbound mail through a smarthost (e.g., SendGrid, AWS SES) for deliverability. The second handles direct SMTP delivery when smarthost isn't configured. The ignore_target_hosts prevents routing loops. Understanding these routing mechanics is part of mastering virtual server infrastructure for hosting providers.

Transport configuration (delivery execution)

Transports execute the actual delivery. Configure separate transports for local delivery, smarthost relay, and direct SMTP. Edit /etc/exim4/conf.d/transport/30_exim4-config_local_delivery:

# Local Maildir delivery
local_delivery:
  driver = appendfile
  directory = $home/Maildir
  maildir_format
  delivery_date_add
  envelope_to_add
  return_path_add
  user = ${extract{2}{:}{${lookup{$local_part}lsearch{/etc/passwd}}}}
  group = mail
  mode = 0660
  mode_fail_hardlink = false

# Smarthost SMTP transport
remote_smtp_smarthost:
  driver = smtp
  port = 587
  hosts_require_auth = smtp.sendgrid.net
  hosts_require_tls = smtp.sendgrid.net

# Direct SMTP transport
remote_smtp:
  driver = smtp
  interface = ${if exists{/etc/mailips}{${lookup{$sender_address_domain}lsearch{/etc/mailips}{$value}{}}}{}}

The local delivery transport writes to Maildir format with proper permissions. The smarthost transport enforces authentication and TLS. The direct SMTP transport binds to a specific interface if configured. For larger deployments, consider our guide on multi-tenant VPS applications to architect mail infrastructure that scales.

ACL configuration: security and spam prevention

ACLs (Access Control Lists) are Exim's primary defense against spam, relay abuse, and malformed messages. They run at SMTP connection, HELO, RCPT, and DATA stages. A misconfigured ACL can silently drop legitimate mail or expose your VPS to relay attacks. These ACLs work in conjunction with proper DMARC configuration for comprehensive email security.

Connection-level ACLs

Create /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt to block abusive connections early:

# RCPT ACL with connection rate limiting
acl_check_rcpt:
  # Accept if no IP address (local submission)
  accept
    hosts = :
    control = dkim_disable_verify

  # Deny if too many connections from this IP
  deny
    message = Too many connections from your IP
    condition = ${if >{${eval:$rcpt_count+1}}{50}}

  # Accept authenticated users
  accept
    authenticated = *
    control = submission/sender_retain
    control = dkim_disable_verify

  # Accept for local domains
  accept
    domains = +local_domains
    endpass
    verify = recipient

  # Accept for relay_from_hosts
  accept
    hosts = +relay_from_hosts

  # Deny everything else (anti-relay)
  deny
    message = Relay not permitted

Rate-limiting connections prevents DoS attacks. The localhost exception ensures local mail flows unrestricted. For advanced VPS security hardening beyond mail-specific ACLs, review our Ultimate VPS Security Guide.

HELO/EHLO validation ACL

Malware often sends malformed HELO strings. Configure strict validation in /etc/exim4/conf.d/acl/20_exim4-config_check_helo:

# HELO validation
acl_check_helo:
  # Accept local submissions
  accept
    hosts = :

  # Deny obviously invalid HELO
  deny
    message = Invalid HELO hostname
    condition = ${if match{$sender_helo_name}{^\\[|^\\.}{yes}{no}}

  # Deny if HELO matches our hostname (likely forged)
  deny
    message = You are not $sender_helo_name
    condition = ${if match_domain{$sender_helo_name}{$primary_hostname}}
    !hosts = +relay_from_hosts

  # Accept all others
  accept

These rules reject HELO strings starting with brackets or dots, and prevent impersonation. This blocks a significant percentage of botnet spam. Combine this with proper DNS security best practices for defense-in-depth.

DATA ACL (content filtering)

Scan message content after the SMTP DATA command. Create /etc/exim4/conf.d/acl/40_exim4-config_check_data:

# DATA ACL - Content filtering
acl_check_data:
  # Deny oversized messages
  deny
    message = Message too large ($message_size bytes)
    condition = ${if >{$message_size}{10M}{yes}{no}}

  # Warn about potential data leaks
  warn
    condition = ${if match{$message_body}{@${primary_hostname}}{yes}{no}}
    log_message = Potential internal address leak

  # Accept message
  accept

Rejects messages over 10MB (adjust for your VPS resources) and logs potential internal address leaks—common in misconfigured auto-responders. This content filtering is essential for maintaining email deliverability and protecting your domain reputation.

SMTP authentication and TLS

Enable SMTPAUTH for client submission (port 587) and force TLS to protect credentials. Configure authentication backends and TLS certificates. For comprehensive VPS security beyond mail services, implement the hardening practices from our VPS security guide.

Authentication backend

Create /etc/exim4/conf.d/auth/30_exim4-config_plain for plaintext authentication (use only with TLS):

# Plaintext authentication (TLS only)
plain_server:
  driver = plaintext
  public_name = PLAIN
  server_condition = ${if crypteq{$auth3}{${extract{1}{:}{${lookup{$auth2}lsearch{/etc/exim4/passwd}{$value}}}}}{yes}{no}}
  server_set_id = $auth2
  server_prompts = :
  .ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
  server_advertise_condition = ${if eq{$tls_in_cipher}{}{no}{yes}}
  .endif

Store credentials in /etc/exim4/passwd with format: username:cryptedpassword. Generate crypted passwords with: mkpasswd -m sha-256. For DMARC authentication alignment, ensure your authentication matches the policies outlined in our DMARC configuration guide.

TLS certificate configuration

Enable TLS in /etc/exim4/conf.d/main/03_exim4-config_tlsoptions:

# TLS configuration
MAIN_TLS_ENABLE = yes
tls_certificate = /etc/ssl/certs/exim.crt
tls_privatekey = /etc/ssl/private/exim.key
tls_advertise_hosts = *

# Require TLS for authenticated connections
.ifdef MAIN_TLS_CERTKEY
tls_on_connect_ports = 465
.endif

Generate or obtain certificates. For production, use Let's Encrypt: certbot certonly --standalone -d mail.yourdomain.com then symlink to Exim's paths. Proper certificate management is part of broader DNS security best practices that every VPS administrator should implement.

Port and daemon configuration

Configure Exim to listen on standard mail ports (25, 587, 465) with proper daemon options. Edit /etc/default/exim4 (Debian/Ubuntu) or /etc/sysconfig/exim (CentOS/RHEL):

# Listen on all interfaces, ports 25 and 587
SMTPLISTENEROPTIONS='-oX 25:587:465 -oP /run/exim4/exim.pid'

# Queue runner interval (5 minutes)
QUEUEINTERVAL='5m'

The -oX option binds multiple ports. Port 25 for MTA-to-MTA delivery, 587 for authenticated submission with STARTTLS, 465 for implicit TLS. The queue runner ensures deferred mail retries every 5 minutes—adjust based on your VPS resources and mail volume.

Logging and debugging

Exim's logging is verbose but precise. Configure log selectors to capture what matters without drowning in noise. Edit /etc/exim4/conf.d/main/90_exim4-config_log_selector:

# Log configuration
log_selector = +all -subject -arguments

# Main log file
log_file_path = /var/log/exim4/%slog

# Set user/group
exim_user = Debian-exim
exim_group = Debian-exim

The log_selector = +all -subject -arguments logs everything except message subjects (privacy) and command arguments (clutter). On busy VPS nodes, reduce to +smtp_connection +smtp_incomplete_transaction +smtp_protocol_error +tls_cipher to minimize I/O. For automated log analysis and retention, consider implementing automated backup strategies that include log archival.

Real-time debugging

Use Exim's debug mode to trace live SMTP sessions without restarting the daemon:

# Test ACLs and routing without sending mail
exim -bh 192.0.2.1

# Show routing for a specific address
exim -bt user@yourdomain.com

# Show delivery transport
exim -bv user@yourdomain.com

# Run in foreground with debug output
exim -bd -d+all

The -bh option simulates an SMTP connection from the specified IP, showing exactly which ACLs trigger. This is essential for testing firewall rules and relay restrictions on a VPS without affecting production traffic.

Testing and verification

Before declaring your Exim configuration production-ready, execute this verification checklist. Each test targets a common failure mode that breaks mail flow or exposes your VPS to abuse. If you encounter delivery issues, our guide on how to fix email delivery issues when emails go to spam provides additional troubleshooting steps.

Configuration syntax check

# Verify Exim configuration syntax
exim -bV

# Test configuration with specific file
exim -C /etc/exim4/exim4.conf.template -bV

A successful verification returns version information and configuration file location. Any syntax errors show exact line numbers. Fix all errors before restarting the daemon.

Open relay test

# Test if VPS is an open relay (critical)
exim -bh 203.0.113.1
MAIL FROM:<spammer@evil.com>
RCPT TO:<victim@example.com>
DATA
Subject: Relay test

Test message
.

If your ACLs are correct, the RCPT TO command should return "550 Relay not permitted." If it accepts with 250, your VPS is an open relay and will be blacklisted within hours.

SMTPAUTH and TLS verification

# Test SMTPAUTH over TLS
openssl s_client -starttls smtp -connect your-vps-ip:587
EHLO test
AUTH PLAIN $(echo -ne '\0user\0password' | base64)

Successful authentication returns "235 Authentication succeeded." Failed authentication returns "535 Incorrect authentication data." Verify both outcomes to ensure your credentials file and AUTH configuration work correctly. For a complete self-hosted mail solution, see our guide on migrating from Gmail to a self-hosted mail server.

Queue management verification

# View mail queue
exim -bp

# Force queue run
exim -qff

# Remove frozen messages older than 7 days
exiqgrep -z -o 604800 | xargs exim -Mrm

On a busy VPS, the queue can accumulate frozen messages from delivery failures. The last command automates cleanup, preventing disk space exhaustion.

Troubleshooting common issues

Even correctly configured Exim installations encounter problems when deployed on diverse VPS environments. These solutions address the most frequent failures reported by sysadmins running Exim on ENGINYRING and similar infrastructure.

"Relay access denied" for legitimate users

Symptom: Local users cannot send mail; Exim logs show "relay denied" despite correct credentials.

Cause: The sender's domain isn't in +local_domains, or authentication isn't being accepted properly.

Solution: Verify domains are listed in /etc/exim4/update-exim4.conf.conf under dc_other_hostnames. For multi-domain VPS setups, add all hosted domains to the local domains list. Ensure authenticated users have accept authenticated = * before relay deny rules.

TLS handshake failures on port 587

Symptom: Clients cannot STARTTLS; logs show "TLS error on connection from...".

Cause: Certificate permissions are wrong, or the certificate doesn't match the hostname.

Solution: Ensure certificates are readable by the Exim user: chown Debian-exim:Debian-exim /etc/ssl/private/exim.key && chmod 640 /etc/ssl/private/exim.key. Verify certificate CN matches: openssl x509 -in /etc/ssl/certs/exim.crt -noout -subject should show your VPS hostname.

Queue freezes with "retry time not reached"

Symptom: Messages remain frozen in queue for days despite destination being reachable.

Cause: Exim's retry logic has backed off to maximum interval and won't attempt delivery again until the retry time expires.

Solution: Force immediate retry: exim -qff. To prevent recurrence, adjust retry rules in /etc/exim4/conf.d/retry/30_exim4-config: * * F,2h,15m; G,16h,1h,1.5; F,4d,6h (retry every 15 minutes for 2 hours, then hourly for 16 hours, then every 6 hours for 4 days).

High memory usage on small VPS

Symptom: Exim processes consume excessive RAM on VPS plans with 1–2GB memory.

Cause: Default Exim configuration spawns too many queue runners and delivery processes for low-memory environments.

Solution: Reduce process limits in main config: queue_run_max = 2 (down from default 5) and remote_max_parallel = 2 (down from 10). This trades throughput for resource efficiency, appropriate for small VPS deployments with limited concurrent connections.

SPF failures causing delivery rejections

Symptom: Outbound mail rejected by major providers (Gmail, Outlook) with SPF failure errors.

Cause: Your VPS IP isn't in the SPF record for your domain, or you're using a smarthost without SRS (Sender Rewriting Scheme).

Solution: Update your DNS SPF record: v=spf1 ip4:your-vps-ip include:sendgrid.net ~all. If relaying through a smarthost, consider enabling SRS. For complete SPF, DKIM, and DMARC implementation, refer to our DMARC configuration guide.

Why this ranks for sysadmin searches

System administrators search for "Exim configuration Linux VPS" repeatedly because Exim's official documentation is exhaustive but lacks practical, production-ready VPS-specific examples. This guide fills that gap: it provides copy-paste configurations that work on real VPS infrastructure, includes exact ACLs that prevent relay abuse, and troubleshoots memory and performance issues specific to virtualized environments. Hosting providers like ENGINYRING need this content to reduce support tickets and position their infrastructure as sysadmin-friendly.

From an SEO perspective, "Exim configuration" has moderate search volume but extremely high technical intent—searchers are actively configuring mail servers and will bookmark comprehensive guides. The VPS-specific troubleshooting addresses real pain points that generic Exim tutorials ignore. Linking to ENGINYRING's email deliverability guide creates a topical cluster that signals authority on mail infrastructure and helps sysadmins understand the full scope of running production email services on VPS platforms.