Mail Server Setup on Ubuntu 24.04 for 2026

A campaign can be perfectly written and still fail if messages arrive late, land in spam, or cannot be traced when something goes wrong. This guide explains a practical mail server setup on Ubuntu 24.04 for 2026, including DNS, Postfix, authenticated submission, TLS, SPF, DKIM, DMARC, monitoring, and safe testing.

There is one important distinction at the start: sending marketing email is not the same as hosting personal inboxes. A small team may need only an outbound SMTP service, while a business that manages its own mailboxes also needs IMAP and Dovecot. Understanding that difference helps you avoid unnecessary software and reduces your security risk.

Plan the mail server setup before installing packages

Postfix is the mail transfer agent, or MTA. It accepts messages, places them in a queue, and delivers them to receiving mail servers. Dovecot provides mailbox access and authentication for users who read mail through IMAP or related clients.

For outbound email marketing, Postfix is the core component. Dovecot is useful only when the same server will host inboxes, such as [email protected]. If you already use a hosted mailbox provider, keep that service for incoming mail and avoid exposing an unnecessary IMAP service.

Before you begin, confirm that you have:

• A clean Ubuntu Server 24.04 LTS installation with sudo access.
• A stable public IPv4 address, and preferably a provider that supports reverse DNS.
• A domain you control, such as example.com.
• A hostname such as mail.example.com that resolves to the server.
• Permission from your hosting provider to send mail on TCP port 25.
• A separate plan for consent, unsubscribe requests, bounces, and complaint handling.

Do not treat a cloud server as a shortcut around email rules. A self-hosted server gives you control, but you also become responsible for patching, reputation, logs, authentication, and abuse response.

DNS records that support email deliverability

DNS is the public directory that tells other systems where your domain sends and receives mail. Correct DNS does not guarantee inbox placement, but incomplete or conflicting records make delivery problems much more likely.

Set the hostname, A record, and reverse DNS

Set the server hostname to the fully qualified name you plan to use in SMTP greetings. Then create an A record similar to this:

mail.example.com.    A    203.0.113.25

The IP address above is an example address, not an address to copy. Ask your hosting provider to create a PTR, also called reverse DNS, that maps the same IP back to mail.example.com. The forward and reverse names should agree wherever possible.

An MX record tells other servers where to deliver incoming mail for your domain:

example.com.         MX   10 mail.example.com.

For an outbound-only server, the MX record may continue pointing to your existing mailbox provider. Do not change it just because Postfix is installed. A common mistake is pointing MX to a new server that has no working inbox service.

Publish SPF, DKIM, and DMARC

SPF lists servers allowed to send for a domain. DKIM adds a cryptographic signature to each message. DMARC tells receiving systems how to evaluate those results and where to send aggregate reports. Together, they create an identity check; they do not replace permission-based marketing or good list hygiene.

An SPF record is a TXT record. Use the exact sending services you actually operate, and avoid creating several SPF records for one domain:

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

OpenDKIM creates the DKIM key pair. The public key goes in DNS under the selector you choose, such as mailer._domainkey.example.com. Keep the private key on the server and restrict access to it.

Start DMARC with a monitoring policy while you confirm alignment. A typical record has this shape:

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

Only move to a stricter policy after you understand legitimate sources and report results. If your organization uses a third-party campaign platform, include its documented SPF or DKIM arrangement rather than guessing.

Install and configure Postfix on Ubuntu 24.04

Update the server and install Postfix:

sudo apt update
sudo DEBIAN_FRONTEND=noninteractive apt install postfix
sudo systemctl enable --now postfix

During an interactive installation, select Internet Site only if this server will deliver mail directly. Set the system mail name carefully. The main configuration file is /etc/postfix/main.cf; the service layout, including submission, is in /etc/postfix/master.cf.

Use postconf to inspect or set individual values instead of repeatedly editing a large file by hand. A basic starting point might look like this:

sudo postconf -e 'myhostname = mail.example.com'
sudo postconf -e 'mydomain = example.com'
sudo postconf -e 'myorigin = $mydomain'
sudo postconf -e 'inet_interfaces = all'
sudo postconf -e 'mydestination = $myhostname, localhost.$mydomain, localhost'
sudo postfix check
sudo systemctl reload postfix

Do not copy a complete configuration from an unrelated server. Values for local domains, relay restrictions, certificates, and authentication depend on whether you are hosting inboxes, relaying through another provider, or delivering directly.

Use authenticated SMTP submission on port 587

Port 25 is normally used for server-to-server delivery. Applications and mail clients should submit messages through authenticated SMTP on port 587. Authentication proves that a permitted user or application may send; it does not mean every recipient is allowed.

First install SASL support and a TLS package:

sudo apt install sasl2-bin libsasl2-modules
sudo systemctl restart postfix

Enable a submission service in /etc/postfix/master.cf. The exact defaults can vary, so inspect the existing section before changing it. A representative configuration is:

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

The encrypt setting requires TLS before credentials are accepted. Configure the SASL backend and user-management method that matches your environment, then test with a non-privileged account. Never enable an unauthenticated relay. An open relay can quickly damage your IP and domain reputation.

Add TLS and decide whether Dovecot is needed

TLS encrypts the connection between the client and server. It protects credentials in transit and lets clients verify that they reached the expected hostname. Obtain a certificate for the hostname users connect to, not merely for the bare domain.

For a certificate managed by Certbot, the command may look like this:

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

Make sure temporary standalone validation can use the required port, or use the validation method supported by your hosting setup. Then point Postfix to the certificate and key:

sudo postconf -e 'smtpd_tls_cert_file=/etc/letsencrypt/live/mail.example.com/fullchain.pem'
sudo postconf -e 'smtpd_tls_key_file=/etc/letsencrypt/live/mail.example.com/privkey.pem'
sudo postconf -e 'smtpd_tls_security_level=may'
sudo postfix check
sudo systemctl reload postfix

Use a stronger TLS requirement on the authenticated submission service, where supported by your client requirements. Plan certificate renewal and test it before the certificate expires.

If this is an outbound-only server, stop here and leave Dovecot out. If you will host inboxes, install it:

sudo apt install dovecot-core dovecot-imapd
doveconf -n

Maildir stores each message as a file in a mailbox directory. A typical setting is mail_location = maildir:~/Maildir. Use IMAPS on port 993 when possible, and avoid exposing unencrypted IMAP on port 143 unless you have a specific, protected use case.

A practical mail server setup walkthrough

Consider a small nonprofit sending a monthly message from [email protected]. The team already uses a hosted inbox provider, so it needs outbound delivery but not local inboxes. This is a safer, simpler design:

1. Use mail.example.com as the server hostname and match its A and PTR records.
2. Keep the existing MX record if the hosted provider receives incoming mail.
3. Publish SPF for the actual sending IP and configure DKIM with a unique selector.
4. Start DMARC in monitoring mode and review reports.
5. Submit messages through port 587 with TLS and a dedicated application account.
6. Send only to recipients who gave permission, include an unsubscribe path, and process bounces.

For a second example, imagine a development team testing a new campaign application. It should not use the production domain or a real subscriber list. Create a controlled test domain or isolated environment, send to internal addresses, and verify headers, links, unsubscribe behavior, and bounce handling before production access is granted.

A third example is a company that wants local inboxes for support staff. In that case, Dovecot and IMAPS may be appropriate, but the team must also protect mailbox accounts, back up mail data, manage storage, and monitor failed logins. The extra service is justified by the requirement; it should not be installed by habit.

Firewall, abuse prevention, and list safety

Allow only the ports your design needs. For direct delivery with authenticated submission and secure mailbox access, a starting UFW rule set may be:

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

Keep SSH restricted to your administration network or approved source addresses when practical. Do not expose database ports, management panels, or internal services to the public internet without a clear reason.

Abuse prevention begins with access control. Require authentication for submission, use strong unique credentials, limit sending privileges, and monitor unusual volume. Rate limits should protect the queue without silently delaying legitimate campaigns. Also set a process for disabling compromised accounts quickly.

Technical controls cannot make an unwanted list acceptable. Import contacts only when you have a lawful basis and clear permission, identify the sender, honor unsubscribe requests, and remove persistent bounces. Requirements differ across the United States, Canada, and Europe, so obtain qualified legal advice for your organization and audience.

Test email deliverability and troubleshoot failures

Test in layers rather than sending a large campaign immediately. Check configuration syntax first:

sudo postfix check
sudo systemctl status postfix
sudo doveconf -n
sudo systemctl status dovecot

Then test the TLS handshake on submission:

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

Review the received message headers. Confirm that the visible From domain, DKIM signing domain, and return-path align with your DMARC plan. Test at least one message to each major mailbox provider used by your audience, but treat one successful delivery as a test result, not a guarantee.

For a message that is delayed, inspect the queue and logs:

mailq
postqueue -p
sudo tail -f /var/log/mail.log

A connection refusal may indicate a firewall rule, a provider block on port 25, or a service that is not listening. A TLS error often points to a hostname mismatch, an expired certificate, or a client that requires settings different from the server. An authentication failure usually means the SASL service, account, or submission settings do not agree.

Never respond to a queue problem by removing safety restrictions at random. Change one setting, reload the relevant service, test again, and record the result.

Common mistakes and a maintenance checklist

The most damaging mistakes are usually simple configuration decisions:

• Using a residential or poorly managed IP with no reverse DNS.
• Creating multiple SPF records instead of one combined record.
• Pointing MX records to a server that does not provide incoming mail.
• Allowing unauthenticated relay or accepting mail for unrelated domains.
• Sending a large list before testing authentication and bounce handling.
• Installing Dovecot when no local inboxes are required.
• Changing several files without saving a known-good configuration.

Build maintenance into the mail server setup from day one. Apply Ubuntu security updates, renew certificates, review authentication failures, inspect queue growth, and verify that DNS records still match your actual sending services.

Before each significant change, back up at least /etc/postfix/main.cf, /etc/postfix/master.cf, relevant Dovecot files, and DKIM keys. Store backups securely because private keys and credentials must not be exposed. Keep a dated change record so you can roll back a setting that causes delivery problems.

FAQ about Ubuntu email servers

Can I use Ubuntu 24.04 for email marketing?

Yes, Ubuntu 24.04 can run Postfix and related services for outbound email. The harder work is maintaining authentication, reputation, consent, bounce processing, and reliable monitoring rather than installing the packages.

Do I need Dovecot for a mail server setup?

No. Dovecot is mainly needed when the server hosts mailboxes that users access through IMAP. An outbound-only Postfix server can be smaller and easier to secure without it.

What DNS records are needed to send email?

At minimum, plan for a matching hostname and reverse DNS, plus SPF and DKIM. DMARC adds policy and reporting, while MX is needed wherever the domain receives mail; it does not always need to point to the sending server.

Why are my emails going to spam?

Spam placement can result from authentication problems, poor list quality, complaints, confusing identity signals, or an IP and domain with weak reputation. Check headers, DNS, bounce patterns, and sending practices instead of assuming that one Postfix setting will solve it.

Make your 2026 mail server plan safer

A reliable email server is a system, not a single installation command. Start with the smallest design that meets your needs, publish accurate DNS, require authenticated submission, secure certificates and keys, and test with a controlled audience.

Your next step is to draw a one-page map of the hostname, IP address, DNS records, sending applications, mailbox provider, and required ports. Then verify each item before sending a real campaign. That simple inventory will expose many mistakes before they affect subscribers or your sender reputation.