DNSSEC and Email Authentication on Ubuntu Server 24.04

Why this DNSSEC and email authentication setup matters

This tutorial shows you how to harden DNS and mail identity on Ubuntu Server 24.04 so your domain signs DNS responses with DNSSEC and your outgoing mail passes SPF, DKIM, and DMARC checks. That combination cuts down spoofing, improves deliverability, and gives you a cleaner recovery path when mail from a fresh VPS or dedicated server starts landing in spam.

You will follow a real production-style workflow: create a non-root admin, confirm the OS, install the required tools, generate a DKIM key pair, publish DNS records, test mail authentication, and verify the final result from both the server and an external mail tester. If you are planning a migration or launching a new host in New Zealand or APAC, this is where a Hostperl VPS gives you enough control to set DNS and mail policy correctly without overbuying infrastructure.

Focus keyword: DNSSEC and email authentication. Primary intent: secure a domain for trustworthy DNS and deliverable mail on Ubuntu Server.

Scenario and architecture

Assume you own example.com, your Ubuntu server answers on 203.0.113.10, and you want mail sent from server.example.com to align with your DNS records. Replace 203.0.113.10 with the public IP assigned to your VPS or dedicated server. Keep your registrar or DNS provider open in a second tab; you will publish records there, not only on the server.

• DNSSEC signs your DNS zone so resolvers can validate answers.
• SPF tells receivers which servers may send mail for your domain.
• DKIM signs outgoing mail with a private key kept on the server.
• DMARC tells receivers how to handle mail that fails SPF or DKIM alignment.

This workflow fits a small business mailbox, a transactional mail relay, or a domain used by a panel account. If your team also manages accounts in WHM, the migration and setup guidance in WHM account setup and migration checklist for 2026 is a useful companion when you move DNS and mail at the same time.

Log in and confirm Ubuntu Server 24.04

On your local computer

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation example. Replace it with the real public IP from your provider.

If your Hostperl VPS was provisioned with a default non-root login, you may use that account first and then elevate with sudo:

ssh deploy@203.0.113.10

On the VPS as root

cat /etc/os-release

Confirm you are on Ubuntu Server 24.04 before continuing. If you are on another distribution, stop here and follow the Ubuntu branch only. This tutorial uses apt, ufw, and Ubuntu’s systemd service names.

Create a non-root admin and keep root open until tested

Do not disable root login until the new account has been tested from a second terminal. That avoids lockout during the first pass.

On the VPS as root

adduser deploy

Set a strong password when prompted. Then grant sudo access:

usermod -aG sudo deploy

Create the SSH directory and copy a public key into place. Replace the key text with your own public key from your workstation.

install -d -m 700 /home/deploy/.ssh
printf '%s
' 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyForDocumentationOnly deploy@example.com' > /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

On your local computer

ssh deploy@203.0.113.10

Open a second terminal and log in as deploy. Then confirm sudo works:

sudo -v
sudo whoami

You should see root from the second command. Keep the original root session open until this succeeds.

Update packages, time sync, and mail tooling

On the VPS as the non-root sudo user

sudo apt update
sudo apt -y upgrade
sudo apt -y install bind9-utils opendkim-tools dnsutils ufw
sudo timedatectl set-ntp true
timedatectl status

bind9-utils gives you dnssec-keygen and related tools, opendkim-tools lets you generate and test DKIM keys, and dnsutils provides dig for verification. The time sync check matters because DNSSEC signatures and mail headers depend on correct time.

Harden SSH and open only the ports you need

Before changing SSH settings, add the firewall rule first. That keeps you connected while you test.

On the VPS as root or via sudo

sudo ufw allow OpenSSH
sudo ufw allow 53
sudo ufw allow 25
sudo ufw enable
sudo ufw status verbose

OpenSSH stays reachable, and you only expose DNS and SMTP if this server actually runs those services. If this host only signs mail for another SMTP relay, you may not need port 25 open at all.

Now make a minimal SSH hardening change. If you already use keys, disable password login after testing. Create a drop-in file:

sudo nano /etc/ssh/sshd_config.d/50-hardening.conf

Use this content:

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

Save the file, then test and reload SSH safely:

sudo sshd -t
sudo systemctl reload ssh

Open a new terminal and confirm you can still log in as deploy. If that works, you can close the root session later.

Generate a DKIM key for example.com

Choose a selector name that identifies this server. Here, use mail2026. The selector becomes part of the DNS record and helps you rotate keys later without breaking old mail.

On the VPS as the non-root sudo user

sudo install -d -m 750 -o root -g root /etc/opendkim/keys/example.com
sudo opendkim-genkey -D /etc/opendkim/keys/example.com -d example.com -s mail2026
sudo chown root:root /etc/opendkim/keys/example.com/mail2026.private
sudo chmod 600 /etc/opendkim/keys/example.com/mail2026.private
sudo cat /etc/opendkim/keys/example.com/mail2026.txt

The .txt output contains the DKIM DNS record you must publish. Keep the private key on the server only. Do not paste it into DNS.

Publish SPF, DKIM, DMARC, and DNSSEC records

Open your DNS provider’s control panel. If Hostperl manages the domain or you are using a registrar with DNS hosting, add these records for example.com.

SPF record

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

This says only 203.0.113.10 may send mail for the domain. If you use a separate mail relay, add that relay instead and remove the IP if it should not send directly.

DKIM record

Copy the value from /etc/opendkim/keys/example.com/mail2026.txt. It will look similar to this:

mail2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY_FROM_KEYGEN"

DMARC record

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Start with quarantine so you can see failures before moving to a stricter policy. Once your mail is clean, you can change the policy to reject.

DNSSEC

DNSSEC is published at the zone or registrar level, not only as a normal TXT record. If your DNS host signs the zone automatically, enable DNSSEC there and publish the DS record at the registrar. If you sign the zone yourself, you must publish the DNSKEY and DS records as instructed by your provider. The exact steps vary by registrar, but the verification commands below will tell you whether validation works.

Because DNS changes take time to propagate, use the verification section after the records have had time to appear.

Configure OpenDKIM to sign outgoing mail

Now tell OpenDKIM where the key lives and which domain to sign.

On the VPS as the non-root sudo user

sudo nano /etc/opendkim.conf

Use these settings or add them if the file is mostly empty:

Syslog                  yes
UMask                   002
Mode                    sv
Canonicalization        relaxed/simple
Socket                  local:/run/opendkim/opendkim.sock
UserID                  opendkim:opendkim
KeyTable                /etc/opendkim/key.table
SigningTable            /etc/opendkim/signing.table
InternalHosts           /etc/opendkim/trusted.hosts

Create the mapping files:

sudo tee /etc/opendkim/key.table >/dev/null <<'EOF'
mail2026._domainkey.example.com example.com:mail2026:/etc/opendkim/keys/example.com/mail2026.private
EOF
sudo tee /etc/opendkim/signing.table >/dev/null <<'EOF'
*@example.com mail2026._domainkey.example.com
EOF
sudo tee /etc/opendkim/trusted.hosts >/dev/null <<'EOF'
127.0.0.1
localhost
203.0.113.10
example.com
server.example.com
EOF
sudo chown root:root /etc/opendkim/key.table /etc/opendkim/signing.table /etc/opendkim/trusted.hosts
sudo chmod 644 /etc/opendkim/key.table /etc/opendkim/signing.table /etc/opendkim/trusted.hosts

Enable and start the service, then check its socket:

sudo systemctl enable --now opendkim
sudo systemctl status opendkim --no-pager
sudo ss -lpn | grep opendkim

If OpenDKIM fails, the log usually shows a permissions problem on the private key or a bad path in the tables.

Install a local mail transfer agent for testing

If you already route mail through another SMTP service, you can still test DKIM signing locally. On a fresh Ubuntu server, postfix is a practical local relay for checking mail headers.

On the VPS as the non-root sudo user

sudo apt -y install postfix mailutils
sudo systemctl enable --now postfix
postconf -n | sed -n '1,80p'

Use the default Internet Site setup if you are sending directly from this machine. If you are relaying through another provider, set the relay host instead and keep outbound policy aligned with SPF.

Reload services only after syntax checks

Check OpenDKIM syntax by restarting it after review, then inspect the journal. If you changed SSH, you already validated its configuration. For DNS records, use dig from the server and from a client after propagation.

On the VPS as the non-root sudo user

sudo systemctl restart opendkim postfix
sudo journalctl -u opendkim -n 50 --no-pager
sudo journalctl -u postfix -n 50 --no-pager

You want to see normal startup messages and no missing-key or socket errors.

Verify DNSSEC, SPF, DKIM, and DMARC

On the VPS as the non-root sudo user

dig +short TXT example.com

dig +short TXT mail2026._domainkey.example.com

dig +dnssec example.com

dig +short TXT _dmarc.example.com

Expected results: SPF returns your policy string, DKIM returns the public key record, DMARC returns the policy, and DNSSEC queries should show signed answers or validation metadata if your resolver supports it.

For a stricter check, use a validating resolver and inspect the AD flag:

dig @1.1.1.1 example.com +dnssec
 dig @8.8.8.8 example.com +dnssec

If the AD bit is missing or the response says bogus, the DS record at the registrar is usually wrong or stale.

Send a test message and inspect the headers

On the VPS as the non-root sudo user

printf 'Subject: DKIM test\nFrom: admin@example.com\nTo: your-real-address@example.net\n\nTest message from example.com\n' | sendmail -t

Replace the recipient with a mailbox you control. Then open that message in the mailbox and inspect the headers. You should see SPF pass, DKIM pass, and DMARC aligned or at least not failing.

For a server-side look, check the postfix log:

sudo tail -n 50 /var/log/mail.log

If your provider routes mail through journald only, use journalctl -u postfix instead. A clean send should show the message being accepted without rejection.

Confirm reboot persistence and firewall state

On the VPS as the non-root sudo user

systemctl is-enabled opendkim postfix ssh
sudo ufw status numbered
sudo reboot

After the reboot, log back in with SSH from your local machine and confirm the services came back:

ssh deploy@203.0.113.10
systemctl status opendkim postfix --no-pager
sudo ufw status verbose

If the services are enabled and active, your mail identity survives restarts, which is what you want on a production VPS.

Rollback and recovery

If mail breaks after a change, roll back in the smallest possible step. Revert the last DNS record first, not the whole zone. For service issues, stop OpenDKIM, remove the signing table change, and restart postfix only after you know the key path is correct.

On the VPS as the non-root sudo user

sudo systemctl stop opendkim
sudo rm -f /etc/opendkim/signing.table /etc/opendkim/key.table
sudo systemctl restart postfix

If SSH access is lost after a hardening change, use your provider console or rescue mode, then restore PasswordAuthentication yes in /etc/ssh/sshd_config.d/50-hardening.conf, run sshd -t, and reload SSH.

Troubleshooting the most likely failures

Problem: DKIM verification fails
Run:

sudo journalctl -u opendkim -n 100 --no-pager
sudo ls -l /etc/opendkim/keys/example.com/
sudo cat /etc/opendkim/key.table

If the log shows permission denied, fix ownership and mode on mail2026.private. If the key table path is wrong, update the file and restart OpenDKIM.

Problem: SPF passes but DMARC fails
Run:

dig +short TXT example.com
postconf -n | grep -E 'myhostname|myorigin|relayhost'

Check that the visible envelope sender aligns with the domain in your SPF record. If you relay mail through another host, add that relay to SPF and align the From domain with your sending identity.

Problem: DNSSEC validation is bogus
Run:

dig +dnssec example.com
 dig DS example.com @your-registrar-dns-server

If the DS record at the registrar does not match the current DNSKEY, republish the DS value from the signed zone or disable DNSSEC before rotating providers. Do not leave mismatched DNSSEC data in place.

Problem: Port 25 is blocked
Run:

sudo ss -ltnp | grep ':25 '
sudo ufw status verbose

If nothing is listening, postfix is not running. If the port is listening but mail still stalls, your host or upstream network may restrict outbound SMTP, which is common on some VPS plans. In that case, use a relay service or ask support to confirm mail policy.

FAQ

Do I need DNSSEC for good email deliverability?
No. SPF, DKIM, and DMARC affect deliverability directly. DNSSEC protects DNS integrity, which helps prevent tampering and supports trust.

Can I use the same DKIM selector forever?
You can, but rotation is easier if you treat selectors as versioned keys. Use a new selector when you replace the key.

Should DMARC start at reject?
Not on a fresh setup. Start with quarantine, confirm alignment, then move to reject once your legitimate mail passes consistently.

Can one VPS run DNS and mail together?
Yes, but only if you understand the security and uptime tradeoffs. Many teams keep authoritative DNS elsewhere and use the VPS for mail signing and outbound relay.

What if my provider blocks SMTP?
Use an authenticated relay or contact support. Some VPS plans restrict outbound port 25 to reduce abuse and protect deliverability for all customers.

Final verification checklist

From the server, confirm these commands return clean results:

systemctl is-active opendkim postfix ssh
ufw status verbose
dig +short TXT example.com
dig +short TXT mail2026._domainkey.example.com
dig +short TXT _dmarc.example.com

From a client mailbox, confirm the message shows SPF pass, DKIM pass, and DMARC pass or aligned quarantine handling. If that is true, your DNSSEC and email authentication setup is ready for production use on Ubuntu Server 24.04.

For teams planning a wider hosting move, this is also a good moment to review shared hosting migration checklist for a clean 2026 move or the managed shared hosting for agencies in 2026 guide if you are coordinating DNS changes across multiple customer accounts.