A campaign can fail before anyone reads it if the sending server has poor DNS, weak authentication, or no protection against abuse. This guide explains how to build an Ubuntu mail server for permission-based email marketing on Ubuntu Server 24.04 LTS, including Postfix, Dovecot, TLS, SPF, DKIM, DMARC, monitoring, and practical testing.
The goal is not to create a high-volume shortcut. A reliable mail system requires clean subscriber lists, clear consent, useful content, and careful operational controls. You will learn how the pieces fit together, which settings matter most, and how to verify each stage before sending a real campaign.
What an Ubuntu mail server actually does
Think of email delivery as a chain of handoffs. Your application or email client submits a message, a mail transfer agent delivers it to the recipient’s server, and a mailbox service lets an authorized user read it.
Postfix is the mail transfer agent in this setup. It accepts and routes messages using SMTP, the standard protocol used to transfer email between systems. Dovecot provides mailbox access through IMAP or POP3 and can also authenticate users for message submission.
These services have different jobs:
- Postfix: receives, queues, routes, and sends mail.
- Dovecot: provides mailbox access and user authentication.
- DNS: tells other systems where your server is and whether it is authorized to send.
- TLS: encrypts connections between mail clients and servers.
- Logging and controls: help you detect errors, abuse, and delivery problems.
For marketing, the sending side is usually more important than local mailbox access. If a separate platform generates your campaigns, you may need only authenticated SMTP submission and monitoring. Installing every mail feature without a clear purpose increases the number of settings you must secure.
Prerequisites and a sensible server plan
Start with a clean, fully updated Ubuntu Server 24.04 LTS host and a stable public IP address. You also need administrative access, a domain you control, a hostname such as mail.example.com, and a provider that allows the SMTP traffic you need.
Set the hostname before installing mail software. Replace the example domain with your own values:
sudo hostnamectl set-hostname mail.example.com
hostname --fqdn
sudo apt update
sudo apt full-upgradeDo not treat a mail server like an ordinary web server. Confirm that your hosting provider supports reverse DNS and that you can request changes to it. Also check provider policies before planning a campaign. A server that cannot set reverse DNS, or that has its outbound SMTP traffic restricted, is a poor foundation for direct delivery.
Keep a simple record of these values:
- Fully qualified hostname:
mail.example.com - Sending domain:
example.com - Public IPv4 address and, if used, IPv6 address
- Administrative email address for abuse and service alerts
- Which system submits campaigns and which system stores mailboxes
DNS, reverse DNS, and email deliverability
Email deliverability begins with consistent identity. Create an A record for the mail hostname and point it to the server’s IPv4 address. Add an AAAA record only when IPv6 is correctly configured, reachable, and included in your authentication plan.
Create an MX record for the sending domain that points to the mail hostname. The hostname in the MX record should resolve correctly, and the server’s reverse DNS should point back to the same hostname. Forward and reverse names do not replace authentication, but mismatches can make troubleshooting harder and may reduce trust.
For example, a basic DNS design might look like this:
| Record | Example value | Purpose |
|---|---|---|
| A | mail.example.com → server IPv4 address | Maps the hostname to the server |
| MX | example.com → mail.example.com | Identifies the receiving mail host |
| PTR | server IP → mail.example.com | Provides reverse DNS identity |
Use one consistent hostname in Postfix, TLS certificates, DNS, and monitoring. For example, if the certificate covers mail.example.com but the server introduces itself as a different name, clients and receiving systems may report confusing warnings.
Install and configure Postfix
Install Postfix and choose Internet Site during the package prompts. Enter the domain used for local mail when asked. You can revise the settings later, but checking them immediately reduces mistakes.
sudo apt install postfix
sudo postconf -n
sudo postfix checkOpen the main configuration file and review the identity and destination settings. The following example is intentionally conservative; adapt it to your domain and mailbox design.
sudo nano /etc/postfix/main.cfmyhostname = mail.example.com
mydomain = example.com
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
inet_interfaces = all
inet_protocols = all
home_mailbox = Maildir/Do not copy a configuration line simply because it appears in a blog post. A setting such as mydestination affects which domains Postfix considers local. If you add a domain incorrectly, you can create mail loops or accept messages for a domain you do not manage.
After each change, validate and reload:
sudo postfix check
sudo systemctl reload postfix
sudo systemctl status postfixDovecot mailboxes and secure SMTP submission
Dovecot is useful when the server hosts local mailboxes or when it supplies authentication to Postfix. Install only the protocols you need. IMAP is normally preferred for users who read mail across multiple devices because messages remain on the server.
sudo apt install dovecot-imapd
sudo nano /etc/dovecot/conf.d/10-mail.confFor Maildir storage in each user’s home directory, use:
mail_location = maildir:~/MaildirAuthenticated submission should use TCP port 587 rather than exposing an unrestricted relay. In /etc/postfix/master.cf, enable the submission service and require encryption before authentication.
submission inet n - y - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,rejectThe exact authentication integration depends on how Postfix and Dovecot are connected. Confirm that credentials are accepted only over TLS, and never configure an open relay. An open relay allows unauthorized users to route mail through your server and can quickly damage its reputation.
Check both services after changes:
sudo doveconf -n
sudo systemctl restart dovecot
sudo systemctl restart postfix
sudo systemctl status dovecot postfixTLS encryption and certificate checks
TLS encrypts the connection between a mail client and the server. It does not prove that a message is legitimate, and it does not guarantee inbox placement, but it protects credentials and message traffic while the connection is active.
Use a certificate whose name matches the hostname clients use, such as mail.example.com. Store the private key with restrictive permissions and configure Postfix and Dovecot to use the certificate and key paths supplied by your certificate process.
smtpd_tls_cert_file=/etc/ssl/certs/mailserver.pem
smtpd_tls_key_file=/etc/ssl/private/mailserver.key
smtpd_tls_security_level=may
smtpd_tls_auth_only=yesDo not enable settings without understanding whether they apply to incoming mail, outgoing mail, or authenticated submission. Port 587 should require TLS before login. If you also use IMAP, configure secure IMAP on port 993 and avoid sending passwords over an unencrypted connection.
You can inspect a TLS service with OpenSSL:
openssl s_client -connect mail.example.com:587 -starttls smtp
openssl s_client -connect mail.example.com:993Review the certificate name, expiration date, and verification result. Repeat the check after certificate renewal so a routine update does not interrupt submission.
SPF, DKIM, and DMARC for authenticated sending
SPF, DKIM, and DMARC are separate controls that work together. SPF lists approved sending systems in DNS. DKIM adds a cryptographic signature to messages. DMARC tells receiving systems how to evaluate authentication results and provides a place to send reports.
For example, if only this server sends mail for example.com, the SPF record might authorize its public IP. If a marketing provider also sends mail, its approved mechanism must be included according to that provider’s documented instructions. Keep one SPF record for a domain; multiple SPF records can cause evaluation problems.
DKIM requires a signing service, such as OpenDKIM, or a compatible signing feature in the sending platform. The public key is published under a selector in DNS, while the private key stays on the signing system. Choose a selector that you can replace later without removing the previous key immediately.
DMARC alignment matters: the visible From domain should align with the domain authenticated by SPF or DKIM. Start with a monitoring policy while you identify legitimate senders, then tighten the policy only when normal messages pass. Test transactional mail, newsletters, contact forms, and any third-party service separately.
Authentication cannot repair poor list practices. Send only to people who gave permission, provide a working unsubscribe method, process complaints quickly, and avoid purchased lists. These practices support compliance obligations in the United States, Canada, and Europe, but the exact legal requirements depend on your organization, audience, and campaign.
Practical setup checklist and test campaign
Use a staged rollout instead of sending a large campaign immediately. This checklist gives you a repeatable path from installation to a small, controlled test.
- Confirm identity: Check the hostname, A or AAAA records, MX record, and reverse DNS.
- Install services: Install Postfix and, if needed, Dovecot. Record every configuration change.
- Secure submission: Enable authenticated port 587 and require TLS before login.
- Publish authentication: Add SPF, configure DKIM signing, and publish a carefully chosen DMARC policy.
- Open only needed ports: Use a firewall and avoid exposing unused services.
- Test a mailbox: Send a message to an address you control on another provider. Check headers, authentication results, and delivery time.
- Test failure handling: Use an invalid recipient in a controlled test and confirm that Postfix records the failure instead of retrying forever.
- Start small: Send a permission-based test group, review bounces and complaints, and pause if results are unexpected.
For example, a small business might use Postfix only for authenticated submissions from its campaign application. A consultant might host several local mailboxes through Dovecot but send newsletters through a separate provider. A nonprofit might begin with a single domain, verify DKIM and DMARC, and add another sender only after confirming alignment. The right design depends on who sends mail and who needs mailbox access.
Firewall, rate limits, and abuse prevention
Open only the ports your design requires. A server that accepts mail from other systems may need TCP 25, while authenticated clients commonly use 587. Secure IMAP uses 993 when local users need mailbox access. Port 465 may be used for implicit TLS in some client setups, but do not open it unless your configuration supports it.
sudo ufw allow 25/tcp
sudo ufw allow 587/tcp
sudo ufw allow 993/tcp
sudo ufw enable
sudo ufw status verboseApply limits that match your expected traffic. Connection limits, recipient limits, and per-user sending limits reduce the damage caused by stolen credentials or a compromised application. The correct values depend on your hardware, campaign size, and provider policy, so test them before a scheduled send.
smtpd_recipient_limit = 50
smtpd_client_connection_count_limit = 10Also secure the operating system: use SSH keys, restrict administrative access, apply updates, protect backups, and remove unused accounts. A mail server should have a documented owner and a process for responding to abuse reports.
Monitoring, logs, and troubleshooting
Logs tell you whether a message was accepted, queued, delivered, deferred, or rejected. On Ubuntu, review the mail log and service status during testing:
sudo tail -f /var/log/mail.log
sudo journalctl -u postfix -u dovecot --since today
sudo systemctl status postfix dovecotCheck listening services with:
sudo ss -tlnp | grep -E ':25|:465|:587|:993'If a message is delayed, look for a queue ID and follow that ID through the log. A DNS error, refused connection, temporary recipient response, or authentication failure points to different fixes. Do not repeatedly resend the same message while investigating; that can create duplicates and make the queue harder to understand.
Common mistakes include an incorrect reverse DNS record, an expired certificate, a second SPF record, a DKIM selector typo, and a firewall rule that blocks the required port. Another frequent error is testing only successful delivery. Test rejected recipients, expired credentials, service restarts, and disk-space alerts as well.
Backups, maintenance, and the next step
Back up configuration files, DKIM keys, mailbox data, DNS records, and the documentation needed to restore the service. Protect backups as carefully as the live server because private keys and mailbox contents are sensitive.
Before changing Postfix or Dovecot, copy the relevant files and record the current service status. After an update, run configuration checks, restart one service at a time, send a controlled test, and inspect the logs. A short maintenance record makes it easier to identify which change caused a problem.
A dependable Ubuntu mail server is built through consistent identity, authenticated submission, encryption, careful list management, and observable operations. Your next step is to write down the hostname, domains, sending systems, and required ports, then verify DNS and reverse DNS before installing campaign software. Once those foundations pass a small test, expand gradually and keep monitoring every send.
Frequently asked questions
Can I use an Ubuntu mail server for email marketing?
Yes, but it should be used for permission-based campaigns with clear unsubscribe handling, accurate authentication, and careful volume controls. Direct delivery is an operational responsibility, so a managed email service may be a better fit if you do not want to maintain DNS, reputation, abuse response, and monitoring.
Which ports should a mail server use?
Port 25 is commonly used for server-to-server SMTP, while authenticated clients usually submit mail through port 587. Secure IMAP commonly uses port 993; open only the ports your design and firewall rules actually require.
Do SPF, DKIM, and DMARC guarantee inbox delivery?
No. They help receiving systems verify who is allowed to send and whether a message aligns with your domain, but they do not guarantee placement. Consent, list quality, complaint handling, message content, server reputation, and correct DNS also matter.
How do I troubleshoot a message that was not delivered?
Find the message queue ID in /var/log/mail.log, read the remote server’s response, and check DNS, TLS, authentication, and firewall rules. Test one recipient at a time and avoid repeated retries until you understand whether the failure is temporary or permanent.
