Prerequisites
Before you begin setting up an SMTP server, you need several things in place. Missing any of these prerequisites will result in delivery failures, poor reputation, or messages going straight to spam folders. If you are new to the SMTP protocol, start there before diving into server configuration.
A dedicated server or VPS with a static IP address. Shared hosting environments almost never allow outbound SMTP traffic, and dynamic IP addresses are universally blocklisted by spam filters. You need a server where you have root or administrator access, a static IPv4 address (and ideally an IPv6 address), and the ability to open ports 25, 465, and 587. Cloud providers like AWS, Google Cloud, and Azure block port 25 by default and require you to submit a request to lift this restriction before your server can relay email to other mail servers.
A registered domain name with access to DNS management. You will need to create multiple DNS records including A, MX, PTR, TXT (for SPF and DKIM), and CNAME records. Make sure you have full control over your domain's DNS zone, either through your registrar or a third-party DNS provider like Cloudflare or Route 53.
A clean IP address. Before using any IP address for sending email, check it against major blocklists including Spamhaus ZEN, Barracuda, SORBS, and SpamCop. If your IP is already listed, you will need to request delisting before proceeding, or obtain a different IP. Use tools like MXToolbox or multirbl.valli.org to check multiple blocklists at once.
Basic knowledge of Linux server administration. This guide assumes you are comfortable with SSH, package management, editing configuration files, and managing system services. Most production SMTP servers run on Linux distributions such as Ubuntu, CentOS, or Debian. If you are looking for a more developer-oriented walkthrough, we have a separate guide focused on integrating SMTP into your application code.
Self-Hosted vs Managed SMTP
The first decision you face is whether to build and maintain your own SMTP infrastructure or use a managed SMTP service. Both approaches have merit, and the right choice depends on your technical resources, sending volume, and business requirements.
Self-Hosted SMTP
Running your own SMTP server gives you complete control over every aspect of email delivery. You choose the MTA software (Postfix, Exim, or Sendmail), configure every parameter, manage your own IP addresses, and retain full ownership of your data. This approach is suited for organizations with dedicated email operations teams, specific compliance requirements that mandate data sovereignty, or extremely high sending volumes where per-message costs from managed services become prohibitive.
The downsides are significant. You are responsible for server maintenance, security patches, deliverability monitoring, IP reputation management, bounce processing, feedback loop integration, blocklist monitoring, and 24/7 uptime. A misconfiguration can damage your sender reputation in hours, and recovering from a blocklisting can take weeks. Self-hosted SMTP also requires ongoing expertise; email delivery is not a set-it-and-forget-it system.
Managed SMTP Service
A managed SMTP service like QUEENSMTP.COM handles all the infrastructure complexity. You connect to the service using standard SMTP credentials, and the provider manages server maintenance, IP reputation, authentication, bounce processing, and deliverability optimization. Setup takes minutes instead of weeks, and you get access to dashboards, analytics, and support from email delivery specialists.
Managed services are ideal for businesses that want to focus on their core product rather than email infrastructure, teams without dedicated email operations engineers, and organizations that need reliable delivery without the overhead of server management. The tradeoff is a per-message or monthly cost, but for most businesses this is far less expensive than the salary and server costs of running SMTP in-house.
| Factor | Self-Hosted | Managed Service |
|---|---|---|
| Setup time | 2 to 4 weeks | Minutes to hours |
| Ongoing maintenance | You handle everything | Provider handles infrastructure |
| IP reputation | You manage and monitor | Provider manages and optimizes |
| Deliverability expertise | Required in-house | Included with service |
| Cost model | Fixed server + engineer time | Per-message or monthly fee |
| Scalability | Manual capacity planning | Automatic scaling |
| Data control | Full ownership | Shared with provider (per terms) |
DNS Setup: A, MX, and PTR Records
Correct DNS configuration is the foundation of email delivery. Missing or incorrect DNS records are the most common cause of delivery failures for new SMTP servers. You need three types of DNS records before your server can reliably send and receive email.
A Record
The A record maps your mail server's hostname to its IP address. This is what other servers use to find your SMTP server when delivering email or verifying your identity. Create an A record for your mail subdomain pointing to your server's static IP address.
# A Record for mail server
mail.example.com. IN A 203.0.113.10
# If using IPv6, also add an AAAA record
mail.example.com. IN AAAA 2001:db8::10MX Record
MX (Mail Exchanger) records tell other mail servers where to deliver email destined for your domain. The MX record points to the hostname in your A record, not directly to an IP address. The priority number (lower is higher priority) allows you to specify backup mail servers.
# MX Records for example.com
example.com. IN MX 10 mail.example.com.
example.com. IN MX 20 backup-mail.example.com.The priority 10 server (mail.example.com) is tried first. If it is unavailable, sending servers will try the priority 20 server (backup-mail.example.com). For most setups, a single MX record is sufficient, but adding a backup MX record improves reliability during maintenance windows.
PTR Record (Reverse DNS)
The PTR record is a reverse DNS entry that maps your IP address back to your mail server's hostname. This is one of the most frequently overlooked steps and one of the most important. Major email providers including Gmail, Yahoo, and Microsoft check that your sending IP has a valid PTR record that matches your EHLO hostname and forward DNS. If the PTR record is missing or mismatched, your emails will be rejected or sent to spam.
# PTR Record (set through your hosting provider or ISP)
# For IP 203.0.113.10:
10.113.0.203.in-addr.arpa. IN PTR mail.example.com.
# Verify PTR record with dig:
dig -x 203.0.113.10
# Expected output should show:
# 10.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.com.PTR records are not set in your domain's DNS zone. They are controlled by whoever owns the IP address, which is typically your hosting provider or ISP. You will need to contact them or use their control panel to set the reverse DNS entry. The PTR record must resolve to a hostname that has an A record pointing back to the same IP. This forward-confirmed reverse DNS (FCrDNS) is required by most receiving servers.
dig or MXToolbox before proceeding. Sending email before DNS is fully propagated will result in authentication failures.
SPF, DKIM, and DMARC Configuration
Email authentication is mandatory for production email delivery. Without SPF, DKIM, and DMARC, your messages will be flagged as suspicious and likely delivered to spam or rejected entirely. Our detailed SPF, DKIM, and DMARC setup guide covers each protocol in depth. These three protocols work together to verify that email actually comes from your domain and has not been modified in transit.
SPF (Sender Policy Framework)
SPF allows you to publish a DNS record listing which IP addresses and servers are authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to verify the sending IP is authorized.
# SPF Record - add as a TXT record on your domain
example.com. IN TXT "v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:_spf.queensmtp.com -all"
# Breakdown:
# v=spf1 -- SPF version 1
# ip4:203.0.113.10 -- Authorize this specific IP
# ip4:203.0.113.11 -- Authorize another IP
# include:... -- Also authorize IPs listed in another domain's SPF
# -all -- Reject (hard fail) all other sourcesDKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to every outgoing email. The sending server signs the message headers and body using a private key, and the public key is published in a DNS TXT record. Receiving servers use the public key to verify the signature, confirming the message was sent by an authorized server and was not tampered with in transit.
Generate a DKIM key pair on your server. Most MTA software includes tools for this. The private key stays on your server and is used to sign outgoing messages. The public key is published in DNS.
# DKIM DNS Record - add as a TXT record
# selector._domainkey.example.com
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."
# Breakdown:
# default -- The DKIM selector name (can be any string)
# _domainkey -- Standard DKIM namespace
# v=DKIM1 -- DKIM version
# k=rsa -- Key type (RSA)
# p=MIGf... -- Base64-encoded public keyDMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails. It also provides a reporting mechanism so you can monitor who is sending email using your domain.
# DMARC Record - add as a TXT record at _dmarc.example.com
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100; adkim=s; aspf=s"
# Start with p=none during initial setup to monitor without blocking:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100"
# Gradually move to p=quarantine, then p=reject:
# p=none -- Monitor only, do not block anything
# p=quarantine -- Send failing messages to spam
# p=reject -- Reject failing messages entirelyStart with a DMARC policy of p=none and monitor the aggregate reports (rua) for at least two weeks. This lets you identify all legitimate sources sending email on behalf of your domain before enforcing a stricter policy. Once you have confirmed all legitimate sources are properly authenticated, move to p=quarantine and eventually p=reject.
TLS Encryption Setup
Transport Layer Security (TLS) encrypts the connection between SMTP servers, preventing eavesdropping and man-in-the-middle attacks during email transmission. Modern email delivery requires TLS; major providers like Gmail and Yahoo flag messages delivered without encryption and may deprioritize them in inbox placement.
You need a valid TLS certificate for your mail server hostname. Let's Encrypt provides free certificates that are trusted by all major email providers. Here is how to obtain and configure a certificate for Postfix, the most widely used open-source MTA.
# Install Certbot and obtain a certificate for your mail hostname
sudo apt install certbot
sudo certbot certonly --standalone -d mail.example.com
# Certificate files will be at:
# /etc/letsencrypt/live/mail.example.com/fullchain.pem (certificate + chain)
# /etc/letsencrypt/live/mail.example.com/privkey.pem (private key)# Postfix TLS Configuration (/etc/postfix/main.cf)
# Outbound TLS (opportunistic - encrypt when possible)
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
# Inbound TLS (allow but do not require - for receiving mail)
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
# Enforce TLS for submission port (587)
# This is configured in /etc/postfix/master.cf for the submission service
# Modern TLS protocols only (disable SSLv2, SSLv3, TLSv1.0, TLSv1.1)
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1For the submission port (587), you should require TLS by setting smtpd_tls_security_level = encrypt in the submission service configuration within /etc/postfix/master.cf. This ensures that user credentials are never transmitted in plain text. For server-to-server relay on port 25, use may (opportunistic TLS) because not all receiving servers support TLS and you do not want to reject legitimate mail.
Set up automatic certificate renewal to prevent expiration. Let's Encrypt certificates are valid for 90 days, and Certbot can renew them automatically via a cron job or systemd timer. After renewal, reload Postfix to load the new certificate.
# Auto-renewal cron job (add to root's crontab)
0 3 * * * certbot renew --quiet --deploy-hook "systemctl reload postfix"IP Warming Strategy
IP warming is the process of gradually increasing the volume of email sent from a new IP address to build a positive sender reputation with receiving mail servers. Sending a large volume from a new, unknown IP address triggers spam filters and can get your IP blocklisted immediately. A proper warming schedule is essential.
Major ISPs track the sending history of every IP address. A new IP has no history, which means no trust. By slowly increasing volume, you give ISPs time to observe your sending patterns, bounce rates, and complaint rates. Consistent, low-complaint sending over time establishes the IP as a legitimate sender.
| Day | Daily Volume | Notes |
|---|---|---|
| 1-2 | 50 to 100 | Send only to your most engaged recipients. Monitor for bounces. |
| 3-4 | 200 to 500 | Expand to active users who opened or clicked in the last 30 days. |
| 5-7 | 1,000 to 2,000 | Include users active in the last 60 days. Check deliverability metrics. |
| 8-14 | 5,000 to 10,000 | Gradually expand to your broader active list. Monitor complaint rates. |
| 15-21 | 20,000 to 50,000 | Continue increasing. Complaint rate should stay below 0.1%. |
| 22-30 | 50,000 to 100,000+ | Approach full volume. IP should have established reputation by now. |
Key rules during IP warming: Send only to confirmed, opted-in recipients. Never send to purchased or rented lists during the warming period. Start with your most engaged subscribers since high open rates signal quality to ISPs. Remove hard bounces immediately. Keep complaint rates below 0.1 percent (one complaint per 1,000 emails). Maintain consistent daily sending volume without large spikes. Distribute your sends across the day rather than blasting all at once.
If at any point during warming you see bounce rates above 5 percent, complaint rates above 0.1 percent, or your IP appears on a blocklist, stop immediately. Investigate the cause, clean your list, and resume at a lower volume. Pushing through poor metrics will only deepen reputation damage.
Testing and Monitoring
Before sending production email, thoroughly test your SMTP server configuration. After going live, continuous monitoring is essential for maintaining deliverability.
Pre-Launch Testing
Send test emails to accounts at major providers: Gmail, Yahoo, Outlook/Hotmail, and Apple Mail. Check that messages arrive in the inbox (not spam), display correctly, and pass authentication checks. View the email headers at each provider to verify SPF, DKIM, and DMARC are passing.
# Test SMTP connectivity with telnet or openssl
openssl s_client -starttls smtp -connect mail.example.com:587
# Send a test email from command line
echo "Subject: Test Email" | sendmail -v recipient@gmail.com
# Check authentication results in Gmail:
# Open the email > Three dots menu > "Show original"
# Look for:
# SPF: PASS
# DKIM: PASS
# DMARC: PASSUse external testing services to validate your configuration. Mail-Tester.com provides a comprehensive score based on authentication, content, and blocklist checks. MXToolbox tests DNS records, blacklist status, and SMTP connectivity. Google Postmaster Tools (for Gmail) provides detailed data on your domain and IP reputation once you have established a sending history.
Ongoing Monitoring
After launch, monitor these key metrics daily: delivery rate (should be above 98 percent), bounce rate (should be below 2 percent), complaint rate (should be below 0.1 percent), open rate trends (declining opens may indicate spam folder placement), and blocklist status. Set up alerts for any metric that exceeds its threshold. For a comprehensive approach to tracking and improving these numbers, see our email deliverability guide.
Monitor your mail server logs for errors, connection timeouts, and TLS failures. Postfix logs to /var/log/mail.log on most Linux distributions. Parse these logs regularly or use a log aggregation tool to track trends and catch issues early.
Troubleshooting Common Issues
Even with careful setup, issues will arise. Here are the most common problems and their solutions.
Emails Going to Spam
If your messages consistently land in spam, check authentication first. View the email headers at the receiving provider and verify that SPF, DKIM, and DMARC all show PASS. If any fails, fix the relevant DNS record. Next, check your IP against major blocklists. If you are listed, follow the provider's delisting process. Finally, review your email content. Avoid excessive links, large images with little text, URL shorteners, all-caps subject lines, and common spam trigger words.
Connection Refused on Port 25
Most cloud providers block outbound port 25 by default. You need to submit a request to your provider to unblock it. AWS requires an Elastic IP and a reverse DNS record before they will lift the restriction. Google Cloud and Azure have similar processes. Until port 25 is unblocked, your server cannot relay email to other mail servers.
High Bounce Rates
Hard bounces (550 errors) mean the recipient address does not exist. If you see high hard bounce rates, your email list contains invalid addresses and needs cleaning. Use an email verification service to validate your list before sending. Soft bounces (4xx errors) are temporary and usually resolve on retry, but persistent soft bounces to the same domain may indicate your IP is being throttled or temporarily blocked.
TLS Handshake Failures
If you see TLS errors in your mail logs, verify your certificate is valid, not expired, and covers the correct hostname. Use openssl s_client to test the TLS connection. Make sure you are using modern TLS protocols (TLS 1.2 or 1.3) and that legacy protocols (SSLv3, TLS 1.0, TLS 1.1) are disabled. Certificate chain issues are common; ensure your certificate file includes the full chain, not just the leaf certificate.
Messages Queuing but Not Delivering
Check the mail queue with postqueue -p (Postfix) or exim -bp (Exim). Look at the deferred message reason. Common causes include DNS resolution failures (check your server's DNS resolver configuration), network connectivity issues (verify outbound port 25 is open), and receiving server rejections (check the specific error message and address the cause).