Ubuntu Mail Server Setup Guide for 24.04 LTS

A mail server can appear healthy while messages quietly fail because of one missing DNS record, an expired certificate, or an open relay. This Ubuntu mail server guide shows how to plan and configure Postfix for sending, Dovecot for mailbox access, TLS for encryption, and SPF, DKIM, and DMARC for sender authentication on Ubuntu Server 24.04 LTS.

You will also learn how to prepare DNS, enable secure submission, limit network access, test each service, and handle common failures. The examples use example.com and mail.example.com; replace them with your own domain and host name before running commands.

Plan your Ubuntu mail server before installing software

The most reliable setup starts with a clear mail flow. Postfix is the mail transfer agent (MTA), which accepts and routes messages. Dovecot provides IMAP access so users can read and manage messages in their mailboxes. Think of Postfix as the delivery desk and Dovecot as the secure set of mailboxes behind it.

For a small organization, a typical design looks like this:

• Host name: mail.example.com
• Mail domain: example.com
• SMTP delivery: TCP port 25 between mail servers
• Authenticated submission: TCP port 587 for mail clients
• Encrypted mailbox access: TCP port 993 for IMAPS
• Mailbox format: Maildir, with separate files stored in each user’s home directory

Before you begin, confirm that the server has a static public IP address, a fully qualified host name, SSH access, and administrator privileges. A provider that blocks outbound port 25 can prevent server-to-server delivery, so check that policy before committing to the design.

Update the operating system and set a time zone appropriate for your team. Accurate system time helps certificates, logs, and authentication behave predictably.

sudo apt update && sudo apt upgrade -y
hostnamectl status

Do not test on a personal domain first. Use a separate domain or subdomain until you understand how mail flow, reputation, and account security work. A configuration mistake can cause bounced messages or make the server an abuse target.

Set DNS records and reverse DNS first

DNS records tell other systems where to find your server and whether your messages are authorized. Create an A record for mail.example.com that points to the server’s public IPv4 address. If you use IPv6, create an AAAA record only when the server is correctly configured for IPv6 mail delivery.

The domain’s MX record should point to the mail host name, not directly to an IP address:

example.com.       MX 10 mail.example.com.
mail.example.com.  A     203.0.113.25

Your hosting provider controls the PTR, or reverse-DNS, record. Ask the provider to map the public IP address to mail.example.com. The forward and reverse names should agree: looking up the host name should lead back to the same address. This is a common reputation check performed by receiving systems.

DNS changes may take time to appear, depending on the records’ time-to-live settings. Check the records from outside your server before troubleshooting Postfix:

dig +short A mail.example.com
dig +short MX example.com
dig +short -x 203.0.113.25

Do not publish an MX record until the host name, IP address, and reverse DNS are ready. Otherwise, other servers may try to deliver mail to an incomplete service.

Install Postfix and choose local delivery

Install Postfix after DNS is planned. During the package setup, choose Internet Site when the server should send and receive mail directly. Set the system mail name to the domain that will receive mail, such as example.com.

sudo apt install postfix
sudo postconf -n

Postfix uses /etc/postfix/main.cf for its main settings. Keep the configuration focused: define the server name, destination domains, network behavior, and TLS settings. A basic starting point can look like this, but review every value for your environment:

myhostname = mail.example.com
mydomain = example.com
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
inet_interfaces = all
inet_protocols = all

The mydestination setting identifies domains delivered locally. Never copy a configuration from an unrelated server without understanding this value. If a domain is missing, local mail may be rejected; if an unintended domain is included, the server may accept mail it should not handle.

After changes, check the syntax and reload the service:

sudo postfix check
sudo systemctl reload postfix
sudo systemctl status postfix --no-pager

A successful reload does not prove that delivery works. It only shows that the service accepted the configuration. Testing comes later, after Dovecot and authentication are ready.

Configure Dovecot Maildir and user access

Dovecot gives mail clients a secure way to read messages. This guide uses Maildir, a mailbox format that stores each message as a separate file. Compared with one large mailbox file, that structure can make individual message delivery and recovery easier to reason about.

sudo apt install dovecot-core dovecot-imapd

Set the mailbox location in /etc/dovecot/conf.d/10-mail.conf:

mail_location = maildir:~/Maildir

Enable IMAP over TLS on port 993 and avoid collecting passwords over an unencrypted connection. The exact include files can vary with package configuration, so inspect the active settings with:

sudo doveconf -n

Use a dedicated Linux account for each mailbox rather than sharing one password. For example, a user named alex can receive mail at [email protected] when local delivery is configured to map that address to the account. Confirm that the account’s home directory and Maildir have appropriate ownership; do not solve permission problems by making the mailbox world-writable.

For a small test, create the mailbox account through your normal account-management process, then send a message to it from an approved test address. Connect a mail client using:

• Incoming server: mail.example.com
• Protocol: IMAP over TLS
• Port: 993
• Username: the full email address when supported by your account mapping
• Outgoing server: the same host on port 587

Secure the Ubuntu mail server with TLS and submission

TLS protects the connection between a mail client and the server. It does not make the contents of every message private from every system involved in delivery, but it prevents credentials from crossing the client connection as plain text.

Obtain a certificate for the exact host name clients use. Certbot can request a certificate when the host is publicly reachable and the chosen validation method is allowed by your environment:

sudo apt install certbot
sudo certbot certonly --standalone -d mail.example.com

If another service already uses the validation port, use a validation method that fits your web server or DNS provider instead of stopping production services blindly. Point Postfix and Dovecot to the certificate and private key paths provided by the certificate tool. Protect the private key and test renewal before the first certificate expires.

Port 587 is the submission service for authenticated users. 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

The snippet is a starting point, not a complete authentication policy. Configure Postfix SASL to use Dovecot’s authentication socket, and confirm that the socket permissions allow Postfix to access it. Require strong, unique passwords and never permit unauthenticated clients to relay through the server.

For example, a remote employee should submit mail through port 587 after signing in. A different mail server should use port 25 to deliver mail to your domain. Keeping those roles separate makes firewall rules and abuse investigations easier.

Publish email authentication records

Modern receiving systems evaluate more than the message’s visible From address. SPF, DKIM, and DMARC work together, but they solve different problems:

• SPF lists systems allowed to send for a domain.
• DKIM adds a cryptographic signature that receiving systems can verify with a DNS public key.
• DMARC tells receivers how to handle messages that fail authentication and provides reporting options.

Start with one SPF record at the domain root. Do not publish several separate SPF records; combine authorized senders into a single record. A simple example for one server is:

example.com. TXT "v=spf1 ip4:203.0.113.25 -all"

The address above is an example only. Replace it with your actual sending address, and include legitimate third-party senders only when you understand their SPF requirements.

For DKIM, install and configure a signing service such as OpenDKIM, generate a key pair, and publish the public key under the selector chosen in the configuration. Keep the private key on the server and never place it in public DNS. Verify that Postfix passes outgoing mail to the signer and that the resulting signature uses the expected domain.

DMARC should be introduced carefully. A monitoring policy lets you review reports before asking receivers to quarantine or reject failures:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Only use a reporting address you control and can monitor. Review authentication alignment before tightening the policy. A legitimate newsletter or help-desk platform may need its own DNS and alignment work.

Harden access, relay rules, and the firewall

The most important abuse control is preventing open relay behavior. Postfix should accept mail for your own domains and authenticated submissions, while rejecting unauthenticated attempts to deliver elsewhere. Review mynetworks, recipient restrictions, and SASL rules together instead of copying one line from a forum post.

Use a host firewall such as UFW to expose only the services you need:

sudo ufw allow OpenSSH
sudo ufw allow 25/tcp
sudo ufw allow 587/tcp
sudo ufw allow 993/tcp
sudo ufw enable
sudo ufw status verbose

If you do not need direct server-to-server delivery, port 25 may not belong in the public firewall. If users need POP3, configure it deliberately; do not open additional ports simply because a package supports them.

Protect SSH with keys, keep administrative access limited, and apply operating-system updates on a schedule. Rate limits, fail2ban or an equivalent control, and sensible mailbox quotas can reduce damage from stolen passwords. These controls complement, but do not replace, strong authentication and log review.

Test the complete mail flow

Test one layer at a time. First check services and configuration, then TLS, then mailbox login, and finally delivery in both directions:

sudo postfix check
sudo doveconf -n
sudo systemctl status postfix dovecot --no-pager
sudo ss -tulpen | grep LISTEN

Test SMTP TLS from a separate machine or from the server when appropriate:

openssl s_client -connect mail.example.com:587 -starttls smtp
openssl s_client -connect mail.example.com:993

A practical checklist should include these three scenarios:

1. Send from an external provider to [email protected], then confirm that Dovecot exposes the message through IMAP.
2. Send from the authenticated account to an external address, then inspect the received headers for SPF and DKIM results.
3. Attempt an unauthenticated relay to an unrelated domain and confirm that Postfix rejects it.

For example, if inbound mail arrives but outgoing mail fails, inspect the submission service, credentials, port 587, and provider restrictions. If outgoing mail leaves but is rejected, check DNS, reverse DNS, authentication alignment, and the remote server’s bounce message rather than repeatedly retrying.

Monitor logs and troubleshoot methodically

Logs are the server’s flight recorder. On Ubuntu, Postfix activity is commonly available in /var/log/mail.log, while Dovecot events may be written to a Dovecot log or the system journal, depending on configuration. Use the journal when a service will not start:

sudo journalctl -u postfix -u dovecot --since "1 hour ago"
sudo tail -f /var/log/mail.log

Search for the message queue ID, sender, recipient, and error text. A DNS failure, authentication rejection, certificate mismatch, and mailbox permission problem each require a different fix. Copying a larger configuration file will often hide the original cause.

Back up configuration before editing it, and record the change:

sudo cp /etc/postfix/main.cf /etc/postfix/main.cf.bak
sudo cp /etc/dovecot/conf.d/10-mail.conf /etc/dovecot/conf.d/10-mail.conf.bak

If a change causes trouble, restore only the affected file, run the relevant syntax check, and reload the service. Also back up mailbox data, DKIM keys, certificate renewal details, and DNS documentation. A configuration backup without mailbox data is not a complete recovery plan.

FAQ about Ubuntu mail server setup

What ports does a mail server need?

Port 25 is used for server-to-server SMTP delivery, port 587 is used for authenticated client submission, and port 993 is used for IMAP over TLS. Open only the ports required by your design and provider policy.

Is Postfix enough to read email?

No. Postfix handles mail transfer and delivery, but users normally need Dovecot or another mailbox service to read mail over IMAP. A complete setup also needs user accounts, TLS, authentication, and mailbox permissions.

How do I stop my server from becoming an open relay?

Allow unauthenticated delivery only to domains you host, require authentication on port 587, and review Postfix relay restrictions. Test from an external network by attempting delivery to a domain you do not control.

Why is my mail going to spam?

Check forward and reverse DNS, SPF, DKIM, DMARC alignment, certificate settings, message content, and the receiving provider’s bounce or rejection details. Authentication improves trust signals, but it cannot guarantee inbox placement.

Maintain the server after launch

A working deployment is the beginning, not the end. Schedule operating-system updates, certificate-renewal checks, backup restoration tests, log reviews, and mailbox cleanup. Keep an inventory of DNS records and every service that is allowed to send mail for the domain.

Review accounts regularly and remove unused credentials. Watch queue size, disk space, failed logins, outbound volume, and delivery errors. A sudden rise in any of these can indicate a stolen password, a broken DNS record, or a compromised application.

The practical next step is to create a staging domain, document your host name and DNS plan, and complete the tests in order: DNS, Postfix, Dovecot, TLS, authentication, and external delivery. Once every check passes and backups restore cleanly, move a small, monitored group of mailboxes rather than switching every user at once.