Mail Server DNS and TLS Certificates

August 13, 2026

system-administration email dns tls

A mail server lives or dies by its DNS records. Missing or incorrect records mean rejected mail, failed TLS negotiation, and deliverability problems that are invisible until someone complains. Before installing Postfix or Dovecot, you need DNS records in place and TLS certificates issued. This post covers the complete DNS setup for a multi-domain mail server and obtaining SAN certificates that cover every hostname.

Planning the Domain Layout

A mail server typically hosts multiple domains. Each domain needs its own set of DNS records, but they all point to the same server. Define your domains and hostnames:

Domain Mail Hostname Purpose
example.com mail.example.com Primary domain
example.org mail.example.org Secondary domain

The primary domain is used as the server's FQDN hostname and as the base for the TLS certificate. Secondary domains have their mail hostnames CNAMEd or A-recorded to point at the same server.

Setting the Server Hostname

The server's hostname should be the primary mail FQDN:

echo "mail.example.com" > /etc/hostname
hostname mail.example.com

Verify:

hostname -f

This should return mail.example.com. The hostname is used in SMTP banners and TLS certificate validation.

Required DNS Records

Each domain needs the following records. Create them in your DNS provider's control panel or via their API.

MX Records

MX records tell other mail servers where to deliver email for your domain:

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

The priority (10) is arbitrary when you have a single mail server. Lower numbers are tried first in multi-server setups.

A Records

The mail hostnames need A records pointing to your server's IP:

mail.example.com.    A    203.0.113.10
mail.example.org.    A    203.0.113.10

Both domains point to the same server IP.

CNAME Records for Service Subdomains

For convenience, create CNAME records for common service names. This lets users configure their mail clients with imap.example.com and smtp.example.com:

imap.example.com.    CNAME    mail.example.com.
smtp.example.com.    CNAME    mail.example.com.
imap.example.org.    CNAME    mail.example.org.
smtp.example.org.    CNAME    mail.example.org.

Reverse DNS (PTR Record)

The server's IP address needs a PTR record that resolves back to the primary mail hostname. This is configured at your hosting provider ( Hetzner, OVH, etc.), not in your DNS zone:

10.113.0.203.in-addr.arpa.    PTR    mail.example.com.

Many mail servers reject connections from IPs without a matching PTR record. This is one of the most common deliverability issues.

SPF Records

SPF (Sender Policy Framework) tells receiving servers which IPs are authorized to send mail for your domain:

example.com.    TXT    "v=spf1 mx -all"
example.org.    TXT    "v=spf1 mx -all"

v=spf1 mx -all means: only the servers listed in the MX records are authorized to send mail. Everything else should be rejected (-all). Use ~all (soft fail) during testing.

DMARC Records

DMARC ties SPF and DKIM together and tells receivers what to do with messages that fail both:

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:postmaster@example.com"
_dmarc.example.org.    TXT    "v=DMARC1; p=reject; rua=mailto:postmaster@example.org"

p=reject tells receivers to reject messages that fail both SPF and DKIM. Use p=none during initial setup to monitor without rejecting, then move to p=quarantine, and finally p=reject once you've verified everything works.

The rua address receives aggregate DMARC reports — XML summaries of who's sending mail claiming to be your domain.

Verifying DNS Records

Before proceeding, verify every record:

# MX records
dig MX example.com +short
# Expected: 10 mail.example.com.

# A records
dig A mail.example.com +short
# Expected: 203.0.113.10

# SPF
dig TXT example.com +short
# Expected: "v=spf1 mx -all"

# DMARC
dig TXT _dmarc.example.com +short
# Expected: "v=DMARC1; p=reject; rua=mailto:postmaster@example.com"

# PTR
dig -x 203.0.113.10 +short
# Expected: mail.example.com.

Fix any missing or incorrect records before continuing. DNS propagation can take up to 48 hours, but most providers update within minutes.

Autoresponder and Postmaster Addresses

RFC 5321 requires that every mail domain accepts mail to postmaster@domain. Additionally, create abuse and hostmaster addresses. These will be configured as aliases in PostfixAdmin later, but plan for them now.

CAA Records (Optional)

CAA records control which Certificate Authorities can issue certificates for your domain. If you want to restrict issuance to Let's Encrypt:

example.com.    CAA    0 issue "letsencrypt.org"
example.org.    CAA    0 issue "letsencrypt.org"

Without CAA records, any CA can issue certificates for your domain. CAA adds a layer of protection against unauthorized issuance.

Obtaining TLS Certificates

Mail servers need TLS certificates for:

  • SMTP (port 25, 465, 587) — encrypting mail in transit
  • IMAP (port 993) — encrypting client connections
  • HTTPS — web interfaces (PostfixAdmin, Roundcube, Nextcloud)

A single certificate with Subject Alternative Names (SANs) covering all hostnames is the most practical approach.

Building the SAN List

The certificate needs to cover every hostname clients will connect to:

mail.example.com
example.com
imap.example.com
smtp.example.com
mail.example.org
example.org
imap.example.org
smtp.example.org

If you're running web applications on the mail server (PostfixAdmin, Roundcube), add those subdomains too:

mailadmin.example.com
webmail.example.com
cloud.example.com

Installing lego

lego handles ACME certificate requests with DNS-01 validation:

emerge -av app-crypt/lego

Requesting the Certificate

Use DNS-01 validation with your DNS provider's API. This example uses Hetzner:

mkdir -p /etc/lego/example.com

HETZNER_API_TOKEN="your-dns-api-token" lego \
  --accept-tos \
  --email=admin@example.com \
  --dns=hetzner \
  --pem \
  --path=/etc/lego/example.com \
  --domains=mail.example.com \
  --domains=example.com \
  --domains=imap.example.com \
  --domains=smtp.example.com \
  --domains=mail.example.org \
  --domains=example.org \
  --domains=imap.example.org \
  --domains=smtp.example.org \
  run

The --pem flag generates a combined PEM file that some services prefer. The first domain in the list becomes the certificate's Common Name.

Certificates are stored in /etc/lego/example.com/certificates/:

ls /etc/lego/example.com/certificates/
mail.example.com.crt
mail.example.com.key
mail.example.com.pem

Verifying the Certificate

Check that all SANs are present:

openssl x509 -noout -text -in /etc/lego/example.com/certificates/mail.example.com.crt \
  | grep -A1 "Subject Alternative Name"

This should list every domain you requested.

Check the expiry date:

openssl x509 -enddate -noout -in /etc/lego/example.com/certificates/mail.example.com.crt

Setting Up Automatic Renewal

Create a renewal script at /usr/local/bin/mail-cert-renew.sh:

#!/bin/sh
set -e

export HETZNER_API_TOKEN="your-dns-api-token"

lego \
  --accept-tos \
  --email=admin@example.com \
  --dns=hetzner \
  --pem \
  --path=/etc/lego/example.com \
  --domains=mail.example.com \
  --domains=example.com \
  --domains=imap.example.com \
  --domains=smtp.example.com \
  --domains=mail.example.org \
  --domains=example.org \
  renew --days=30

RESULT=$?

if [ $RESULT -eq 0 ]; then
    # Reload services that use the certificate
    rc-service postfix reload 2>/dev/null || true
    rc-service dovecot reload 2>/dev/null || true
    rc-service apache2 reload 2>/dev/null || true
fi
chmod 750 /usr/local/bin/mail-cert-renew.sh

Add a cron job:

crontab -e
30 3 * * * /usr/local/bin/mail-cert-renew.sh >> /var/log/mail-cert-renewal.log 2>&1

The renewal script reloads Postfix, Dovecot, and Apache after a successful renewal so they pick up the new certificate without downtime.

Configuring the Default Apache SSL VHost

With certificates in place, configure Apache's default SSL virtual host to use them. This provides HTTPS for web interfaces deployed later.

Edit /etc/apache2/vhosts.d/00_default_ssl_vhost.conf:

<IfDefine SSL>
<VirtualHost _default_:443>
    SSLEngine on
    SSLCertificateFile /etc/lego/example.com/certificates/mail.example.com.crt
    SSLCertificateKeyFile /etc/lego/example.com/certificates/mail.example.com.key

    DocumentRoot /var/www/localhost/htdocs
</VirtualHost>
</IfDefine>

Restart Apache:

apache2ctl configtest
rc-service apache2 restart

Summary

After completing these steps:

  • MX records direct incoming mail to your server
  • A records and CNAMEs map hostnames to your server IP
  • SPF records authorize your server to send mail for each domain
  • DMARC records define the policy for failed authentication
  • PTR record matches your primary mail hostname
  • TLS certificates cover all mail hostnames with automatic renewal
  • Apache serves HTTPS using the mail server certificate

With DNS and certificates in place, the server is ready for Postfix and Dovecot installation.