Every business website sends email. Contact form submissions, booking confirmations, password resets, invoices, and automated notifications all depend on a working SMTP server. When email stops delivering, these features break silently and you lose enquiries without knowing why. A customer completes a booking, your system processes it correctly, but the confirmation never arrives. You only find out when they call to ask what happened.
The most common reason business email fails to deliver is missing or misconfigured DNS authentication records. Without SPF, DKIM, and DMARC records in your domain's DNS, major email providers treat your messages as suspicious by default. Your email may technically arrive, but it lands in the recipient's spam folder or gets rejected entirely. This is not a server configuration problem. It is a DNS configuration problem, and it requires DNS changes, not server changes.
The second most common problem is outbound port blocking. Many business ISPs and cloud providers block outbound port 25 by default. This is the standard SMTP port for mail server-to-mail-server communication. If port 25 is blocked, your server cannot deliver mail to external mail servers regardless of how correctly it is configured. You will see no error in your mail logs because the connection is never established. The fix is to use port 587 with STARTTLS or route through a transactional email provider as a relay.
Understanding these two failure modes is the foundation of fixing email deliverability. Most troubleshooting guides start with Postfix configuration, but the real problems are usually upstream. This guide covers the complete setup: Postfix installation, TLS encryption, SPF records, DKIM signing, and DMARC policy. It also explains how to test your configuration and what to do when something goes wrong.
Installing Postfix on Ubuntu
Postfix is the standard SMTP server for Ubuntu. It is reliable, actively maintained, and integrates well with the Linux ecosystem. Most email delivery problems are not Postfix problems. They are DNS configuration problems, port blocking problems, or SMTP authentication problems. Postfix does its job correctly if you set it up correctly, but it cannot compensate for missing DNS records or blocked ports.
Install Postfix and the mail utilities with:
sudo apt update && sudo apt upgrade -y
sudo apt install mailutils postfix -yDuring installation, the Postfix installer prompts you to choose a configuration type. Choose Internet Site and enter your domain name when asked. This sets the basic configuration. The main configuration file is at /etc/postfix/main.cf and the Postfix service is controlled with systemctl.
After installation, verify the basic configuration is correct. Open /etc/postfix/main.cf and check these key settings:
myhostname = mail.yourdomain.co.uk
myorigin = /etc/mailname
mydestination = $myhostname, localhost.$mydomain, localhost
inet_interfaces = all
inet_protocols = all
home_mailbox = Maildir/The myhostname must match your mail server's fully qualified domain name. If you run your mail server at mail.yourdomain.co.uk, set that here. The mydestination line tells Postfix which domains it should consider local and accept mail for. The home_mailbox = Maildir/ setting stores incoming mail in Maildir format, which is what most email clients and webmail interfaces expect.
If you change any configuration, reload Postfix to apply it without restarting the service:
sudo postfix reloadIf the service fails to reload, check /var/log/mail.log for the specific error. Syntax errors in configuration are common when manually editing the file.
Enabling TLS Encryption
Modern SMTP requires TLS encryption. Without it, your email credentials and message content are transmitted in plain text, which is both a security risk and a spam trigger. Mail providers increasingly reject or flag as spam any email that arrives without TLS encryption, regardless of whether the content itself is legitimate.
Add these lines to /etc/postfix/main.cf to enable TLS:
smtpd_tls_cert_file=/etc/letsencrypt/live/yourdomain.co.uk/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/yourdomain.co.uk/privkey.pem
smtpd_use_tls=yes
smtpd_tls_security_level=may
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scacheIf you do not have a Let's Encrypt certificate yet, obtain one with Certbot. The command below obtains a certificate for the mail server subdomain:
sudo apt install certbot python3-certbot-nginx -y
sudo certbot certonly --nginx -d mail.yourdomain.co.ukCertbot automatically configures HTTPS for nginx if it detects a running nginx installation. If you only want the certificate without the nginx configuration, use the standalone challenge:
sudo certbot certonly --standalone -d mail.yourdomain.co.ukThe standalone challenge requires port 80 to be available. Stop nginx or any other web server before running this command. Once you have your certificate, proper server hardening is worth considering alongside your email configuration. A secure server setup on Ubuntu protects both your SSH access and your email infrastructure.
After any TLS configuration change, verify the certificate files are readable by the Postfix user:
sudo postfix check
sudo systemctl restart postfixTest TLS is active by connecting to your server on port 587 and checking for the STARTTLS capability:
openssl s_client -starttls smtp -connect mail.yourdomain.co.uk:587 -brief 2>/dev/null | head -5Configuring SPF Records
SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which IP addresses are permitted to send email for your domain. Without it, any server in the world can claim to be sending mail from your domain, and receiving servers have no way to verify whether that is legitimate. This is the most basic and most important email authentication record.
SPF records are TXT records in your DNS settings. The format is:
v=spf1 mx ip4:YOUR_SERVER_IP -allThe v=spf1 prefix identifies this as an SPF record version 1. mx authorises your domain's MX servers to send mail. ip4:YOUR_SERVER_IP authorises your specific server IP address. -all tells receiving servers to reject mail that comes from any other IP address. The -all qualifier is strict mode: fail if not matched. ~all is soft fail (accept but flag as suspicious), and ?all is neutral (no policy).
Use -all (fail) for production domains. Use ~all (softfail) only during initial setup and testing while you confirm your configuration is correct.
Find your server's public IP address with:
curl ifconfig.meAdd this as a TXT record in your DNS provider's control panel. The record name should be @ or your domain (depending on the DNS provider interface). The SPF record value should be the full string starting with v=spf1.
DNS propagation can take up to 48 hours, though most changes take effect within minutes to a few hours. Use MXToolbox SPF Checker or run this command to verify your record is published correctly:
dig txt yourdomain.co.uk +shortThe output should show your SPF record. If it does not appear, wait and check again. DNS changes are not instant.
A common mistake with SPF records is including too many mechanisms, which causes DNS lookup failures. Receiving mail servers limit the number of DNS lookups they perform when evaluating an SPF record (the limit is typically 10). Exceeding this limit causes the SPF check to fail, which means the receiving server cannot verify your domain's SPF policy. Count your include mechanisms and lookups carefully if you use third-party email providers who require you to include their SPF records.
Setting Up DKIM Signing
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email you send. Receiving servers use your public key, published in DNS, to verify that the email was actually sent by your server and was not modified in transit. DKIM is more robust than SPF because it does not rely on the sending server's IP address, which can change.
Install OpenDKIM and its tools:
sudo apt install opendkim opendkim-tools -yCreate a directory for your DKIM keys and generate the key pair:
sudo mkdir -p /etc/opendkim/keys/yourdomain.co.uk
cd /etc/opendkim/keys/yourdomain.co.uk
sudo opendkim-genkey -s mail -d yourdomain.co.uk
sudo chown -R opendkim:opendkim /etc/opendkim/keysThe -s mail flag sets the selector to "mail". This creates two files: mail.private (your private key, which stays on the server and is never published) and mail.txt (the public key to add to DNS).
Display the public key from the mail.txt file:
sudo cat mail.txtThe output looks like:
mail._domainkey IN TXT ( "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..." );Add this as a TXT record in your DNS. The record name is mail._domainkey.yourdomain.co.uk and the value is everything inside the parentheses (remove the quotes and the line breaks). In most DNS control panels, you paste the full contents of the mail.txt file including the quotes.
Configure OpenDKIM by editing /etc/opendkim.conf:
Syslog yes
UMask 002
Domain yourdomain.co.uk
KeyFile /etc/opendkim/keys/yourdomain.co.uk/mail.private
Selector mail
Mode sv
SubDomains yes
Socket inet:12301@localhostThe Mode sv means sign (s) and verify (v). The SubDomains yes setting signs emails from subdomains as well as the primary domain, which is useful for sending from mail.yourdomain.co.uk while the DKIM record is on yourdomain.co.uk.
Connect OpenDKIM to Postfix by adding these lines to /etc/postfix/main.cf:
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:12301
non_smtpd_milters = inet:localhost:12301Start OpenDKIM and configure it to run at boot:
sudo systemctl enable opendkim
sudo systemctl start opendkim
sudo systemctl restart postfixVerify DKIM is working by sending a test email to a DKIM testing service. You can also check your email headers in Gmail: if you see dkim=pass in the Authentication-Results header, DKIM is working correctly.
Configuring DMARC Records
DMARC builds on SPF and DKIM. It tells receiving servers what to do when an email fails authentication. Without DMARC, receiving servers apply their own heuristics when SPF or DKIM fails, which means you have no control over how legitimate email from your domain is treated. With DMARC, you specify both the policy and a reporting address so you can see when authentication failures occur.
DMARC records are TXT records at _dmarc.yourdomain.co.uk. A sensible starting configuration:
v=DMARC1; p=quarantine; rua=mailto:[email protected]p=quarantine tells receiving servers to treat failing emails as suspicious, usually by moving them to spam rather than rejecting them outright. rua=mailto:[email protected] specifies an email address to receive aggregate reports about authentication failures. These reports are sent in a standard XML format and provide data about which servers are sending mail that fails SPF or DKIM for your domain. They do not contain message content, only metadata.
As you become confident that your email authentication is working correctly, you can change p=quarantine to p=reject, which tells receiving servers to block failing emails entirely. Make this change gradually and monitor the aggregate reports. If you suddenly start receiving large numbers of DMARC failure reports, it usually means something in your email flow has changed, such as a new marketing platform or third-party service sending email on your behalf.
The DMARC aggregate reports can be difficult to interpret manually. Services like Dmarcian and Agari provide tools for parsing and visualising DMARC reports. They are worth using if you manage multiple domains or are actively working on email deliverability.
Testing Your Email Setup
Before relying on your SMTP server for business communications, test it thoroughly. The most useful free tool is mail-tester.com. Send a test email to the address it provides, check your score, and address the specific issues it identifies. Scores below 8 out of 10 usually indicate a specific problem that the report will explain clearly.
Test individual components as well. For SPF, use MXToolbox SPF Checker or run:
dig txt yourdomain.co.uk +shortFor DKIM, verify your DNS TXT record is published and correctly formatted:
dig txt mail._domainkey.yourdomain.co.uk +shortSend a test email from the command line to check delivery:
echo "Test message" | mail -s "SMTP Test" -a "From: [email protected]" [email protected]If the email does not arrive within a few minutes, check the Postfix mail log:
sudo tail -f /var/log/mail.logThis shows every email Postfix attempts to send, the status of each connection, and any errors. A delivery failure shows a specific error code. Common status codes include:
- 250 OK: Message accepted for delivery.
- 450 Requested mail action not taken: mailbox unavailable: Temporary failure, usually a recipient mailbox that does not exist on the destination server. Try again later.
- 550 5.1.1 User unknown: The recipient address does not exist. The address may be wrong or the recipient's mail server may be misconfigured.
- 554 5.7.1 Service unavailable: has been listed on DNS blocklist: Your server IP is on a blocklist. Check with MXToolbox Blacklist Check.
Email log analysis is a skill worth developing. Patterns in the logs tell you whether problems are configuration errors, DNS issues, blocklisting, or capacity problems.
Firewall and Port Configuration
Your server firewall must allow outbound SMTP on the ports you use. The standard submission port is 587 (with STARTTLS), and SMTPS (wrapped SSL on port 465) is supported by some clients though considered legacy. Port 25 should be restricted to mail server-to-mail-server communication only.
Configure UFW (Uncomplicated Firewall) to allow the necessary ports:
sudo ufw allow 22 # SSH
sudo ufw allow 587 # SMTP submission
sudo ufw allow 465 # SMTPS (legacy)
sudo ufw allow 80 # HTTP for Certbot
sudo ufw allow 443 # HTTPS for CertbotIf emails are timing out with no error in the logs, your ISP or cloud provider may be blocking outbound port 25. Most cloud providers have a form to request this block be lifted. AWS, DigitalOcean, and Vultr all provide this, though it may take 24 to 72 hours for the request to be processed.
An alternative to unblocking port 25 is to route email through a transactional email relay service such as Mailgun, SendGrid, or Amazon SES. These services provide SMTP credentials and relay your email through their infrastructure, which has established relationships with major mail providers and proper authentication already in place. This is the most reliable option for cloud servers where port 25 cannot be unblocked.
For businesses that rely on automated email notifications, configuring SMTP authentication properly is essential for reliable delivery. A Postfix SMTP authentication setup guide covers the specifics of securing your email relay and preventing unauthorized use of your mail server.
Common Problems and How to Fix Them
The most frequent issue after a new Postfix installation is email arriving in the recipient's spam folder. This is almost always a DNS authentication problem. Run a mail-tester.com test and address the specific failures it identifies. Check your SPF, DKIM, and DMARC records are correctly published and propagated. Do not assume the problem is with your Postfix configuration until you have confirmed the DNS records are correct.
If emails are not sending at all, verify your server can make outbound connections on port 587:
timeout 10 telnet smtp.gmail.com 587If this times out, port 587 is blocked. Contact your provider or route email through a relay service. Do not attempt to bypass port blocks by using alternative ports for mail submission. Port 587 is the standard for client submission and is the only port that should be used for applications submitting mail.
If emails are being rejected with a bounce message, check your server's IP address against common blocklists using MXToolbox Blacklist Check. If you appear on a blocklist, most providers have a delisting form on their website. The process typically involves confirming you are not a spam source and describing the steps you have taken to prevent future abuse. It can take 24 to 72 hours for some blocklists to process a removal request.
If your server IP is on multiple blocklists simultaneously, this often indicates that the IP range you are using has been used for spam by a previous owner of the IP. In this case, switching to a different IP address may be the only practical solution, particularly on cloud platforms where IP addresses are shared across customers.
Running Business Email on Your Own Server
For service businesses, automated email plays a practical role in daily operations. Booking confirmations, quote notifications, and invoice alerts all depend on reliable email delivery. When these fail, admin time gets spent chasing missing messages instead of serving customers.
A properly configured Postfix server gives you full control over your outbound email without per-message fees or third-party restrictions. You manage your own mail queue, your own authentication, and your own reputation. The tradeoff is that you are responsible for maintenance, updates, and monitoring. For many small businesses, this trade-off is worth it.
If your business sends high volumes of transactional email, or if you rely on email as a core part of your customer communication, investing time in a proper setup pays off. The DNS authentication layer (SPF, DKIM, DMARC) is what actually makes email deliver work, not the Postfix configuration itself. Get those records right and your server's email will be treated as legitimate by the major mail providers.
Businesses that send appointment confirmations or booking notifications may also want to consider how their email setup interacts with customer data handling. A review of booking system GDPR compliance covers the data protection side of automated customer communications.