Email Authentication Setup Tutorial (2026): Configure SPF, DKIM, DMARC, and rDNS for a VPS Mail Server

Email can fail quietly. Your server says “sent,” but customers never see the message. Or it lands in spam. This email authentication setup tutorial gives you a clean, repeatable baseline for 2026: align DNS, sign outbound mail, and fix reverse DNS on a VPS mail server.

You want four pieces to line up:

Your domain publishes SPF and DMARC.
Your server signs outbound mail with DKIM.
Your sending IP has rDNS (PTR) pointing to the right hostname.
Your SMTP server presents that same hostname in HELO/EHLO.

The examples use Ubuntu 24.04 LTS with Postfix + OpenDKIM.

The DNS steps apply to cPanel, DirectAdmin, and most DNS/control panels.

What you’ll set up (and what to collect first)

Gather these four items before you edit DNS. Miss one, and you can spend hours chasing “auth=none” or “policy reject” errors.

Domain: example.com
Mail hostname (FQDN): mail.example.com (A/AAAA points to your VPS IP)
Outgoing IP: 203.0.113.10 (the IP your Postfix uses to send)
From domain: example.com (the domain in your From: header)

If you host multiple domains, start with one “primary” domain.

Once it passes reliably, copy the pattern to the rest.

Hosting note: if outbound reputation matters and you need rDNS control, use a VPS or dedicated server.

Shared hosting often blocks rDNS changes and limits SMTP tuning.

HostMyCode’s HostMyCode VPS is a straightforward starting point when you want full control of the mail stack.

Email authentication setup tutorial: Step 1 — Verify forward DNS and server identity

First, confirm your hostname resolves correctly.

Then confirm the server actually uses that hostname.

On the VPS:

hostnamectl
hostname -f
getent hosts mail.example.com

hostname -f should return mail.example.com (or the hostname you picked).

If it doesn’t, set it:

sudo hostnamectl set-hostname mail.example.com

Then add the basics at your DNS provider:

A record: mail.example.com → 203.0.113.10
MX record: example.com → mail.example.com (priority 10 is typical)

Quick check from your laptop:

dig +short A mail.example.com
dig +short MX example.com

If you’re migrating mail and want low downtime, lower TTLs ahead of time.

Then stage changes in small steps. This guide pairs well with low-downtime DNS propagation planning.

Step 2 — Set reverse DNS (PTR) to match your mail hostname

Reverse DNS (PTR) lives on the IP address.

It does not live in your domain’s DNS zone.

Many receivers treat missing PTR (or a PTR that doesn’t match your mail hostname) as a strong deliverability negative.

This matters even more on new IP space.

Target state:

203.0.113.10 PTR → mail.example.com
mail.example.com A → 203.0.113.10

Check what you have now:

dig +short -x 203.0.113.10

Setting PTR depends on your provider.

On HostMyCode, request the exact mapping (IP → hostname) you want for rDNS.

If you run into mismatches or validation failures, keep this PTR troubleshooting checklist nearby.

Step 3 — Configure SPF (DNS) for controlled sending

SPF is your “authorized senders” list.

It does not sign mail. It tells recipients which IPs may send messages that claim to be from your domain.

Add a TXT record at the root (example.com):

example.com.  3600  IN  TXT  "v=spf1 a mx ip4:203.0.113.10 -all"

Notes:

a and mx authorize the IPs behind your A and MX records. Keep them only if those hosts actually send mail.
ip4: authorizes the specific sending IP.
-all is a hard fail. Use ~all only during a short migration window.

Validate:

dig +short TXT example.com

Common pitfall: don’t publish multiple SPF TXT records.

SPF evaluation can stop early and fail in confusing ways. Combine everything into a single record.

Step 4 — Install OpenDKIM and generate signing keys

DKIM adds a cryptographic signature to outbound mail.

Receivers use it to confirm two things: the message wasn’t altered, and your domain authorized the send.

On Ubuntu 24.04 LTS:

sudo apt update
sudo apt install -y opendkim opendkim-tools postfix

Create a directory for keys (one domain shown):

sudo mkdir -p /etc/opendkim/keys/example.com
sudo chown -R opendkim:opendkim /etc/opendkim
sudo chmod go-rwx /etc/opendkim/keys

Generate a 2048-bit key (recommended baseline for 2026):

cd /etc/opendkim/keys/example.com
sudo -u opendkim opendkim-genkey -b 2048 -s s2026 -d example.com
sudo -u opendkim chmod 0400 s2026.private

You now have:

s2026.private (private key, stays on the server)
s2026.txt (DNS record content for the public key)

Step 5 — Wire OpenDKIM into Postfix (milter setup)

Postfix doesn’t sign DKIM by itself.

It hands messages to OpenDKIM through a milter socket. OpenDKIM adds the signature.

Edit /etc/opendkim.conf and set these core lines (add them if missing):

Syslog                  yes
UMask                   002
Canonicalization        relaxed/simple
Mode                    sv
SubDomains              no
AutoRestart             yes
AutoRestartRate         10/1h
Background              yes
DNSTimeout              5
SignatureAlgorithm      rsa-sha256
Socket                  local:/run/opendkim/opendkim.sock

Create the supporting mapping files.

/etc/opendkim/key.table

s2026._domainkey.example.com example.com:s2026:/etc/opendkim/keys/example.com/s2026.private

/etc/opendkim/signing.table

*@example.com s2026._domainkey.example.com

/etc/opendkim/trusted.hosts

127.0.0.1
localhost
mail.example.com

Make sure the runtime directory exists and OpenDKIM can write to it.

Ubuntu usually handles this, but verify it anyway:

sudo mkdir -p /run/opendkim
sudo chown opendkim:opendkim /run/opendkim

Now point Postfix at the milter. Edit /etc/postfix/main.cf:

smtpd_milters = local:/run/opendkim/opendkim.sock
non_smtpd_milters = local:/run/opendkim/opendkim.sock
milter_default_action = accept
milter_protocol = 6

Restart and verify:

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

If OpenDKIM won’t start, check key.table paths first.

Then check permissions under /etc/opendkim/keys.

Step 6 — Publish your DKIM record in DNS

Open /etc/opendkim/keys/example.com/s2026.txt.

Copy the TXT value into your DNS provider.

It will look like this (wrapped):

s2026._domainkey IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..." )

Publish it as a TXT record for:

Name/Host: s2026._domainkey (some providers need the full s2026._domainkey.example.com)
Value: the full DKIM string

Verify it resolves:

dig +short TXT s2026._domainkey.example.com

If you need a domain-by-domain setup (including multi-domain signing), HostMyCode also has a dedicated walkthrough: DKIM setup tutorial for Ubuntu VPS.

Step 7 — Add DMARC with a safe rollout policy

DMARC ties SPF and DKIM together.

It also tells receivers what to do when authentication fails.

Start in monitor mode. Review reports.

Tighten policy only after you’ve found every legitimate sender.

Add this TXT record:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1; adkim=s; aspf=s"

Practical guidance:

p=none is monitoring only. Leave it for at least a week of normal sending.
rua is aggregate reports (recommended). ruf can be noisy and may be ignored by some receivers.
adkim=s and aspf=s require strict alignment. If you use subdomains or third-party senders, you may need relaxed alignment.

Once stable, move to:

p=quarantine (failures go to spam/junk)
p=reject (failures get rejected)

Don’t jump to reject if you send through multiple systems (WooCommerce plugins, support desk tools, marketing platforms).

Align each sender first, then enforce.

Step 8 — Ensure HELO/EHLO and Postfix headers aren’t undermining you

Many providers compare your HELO name, PTR, and connecting IP.

If they don’t match cleanly, your “passes” can still land in junk.

A solid baseline is:

PTR points to mail.example.com
Postfix uses myhostname = mail.example.com
HELO/EHLO presented as mail.example.com

Check these in /etc/postfix/main.cf:

myhostname = mail.example.com
mydomain = example.com
myorigin = /etc/mailname

Make sure /etc/mailname contains:

example.com

Reload Postfix after edits:

sudo postfix check
sudo systemctl reload postfix

Step 9 — Test end-to-end and read the authentication results

Don’t stop at “DNS looks right.”

Send a real message and read the headers.

On a major provider, you want to see spf=pass, dkim=pass, and dmarc=pass.

Send a test mail from the VPS:

echo "Auth test $(date -Is)" | mail -s "Auth test" you@gmail.com

If mail isn’t installed:

sudo apt install -y bsd-mailx

On the receiving side, open the message source.

Find “Authentication-Results”. A healthy example looks like:

Authentication-Results: ...
 spf=pass ...
 dkim=pass ... header.s=rs2026 ...
 dmarc=pass ...

If something fails, work methodically instead of guessing.

HostMyCode’s email deliverability troubleshooting tutorial walks through logs, DNS checks, and SMTP dialogue in a sane order.

Step 10 — Hardening that improves deliverability (without turning this into a mail “project”)

Authentication gets you past the obvious filters.

The items below keep the server predictable and reduce surprise failures.

Lock down firewall ports to what mail needs

Allow SSH and web ports as needed.

Only open mail ports you actually use.

If you’re relaying app mail, you may only need 25/587 outbound and 587 inbound.

UFW example (adjust to your setup):

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

If you want a safer baseline that won’t accidentally lock you out or break mail, follow this UFW configuration tutorial.

Keep your queue and logs under control

New mail servers often fail in boring ways.

A queue gets stuck, retries pile up, and logs chew through disk.

Keep an eye on these:

mailq
sudo postqueue -p
sudo journalctl -u postfix -n 100 --no-pager

If disk usage creeps up, fix it before you hit “No space left on device”.

Use a cleanup workflow like this VPS cleanup tutorial to keep the server stable.

Back up the parts that matter

For authentication, the most painful thing to lose is your DKIM private key.

Back up:

/etc/opendkim/ (especially keys/)
/etc/postfix/
Your DNS zone export (or at least a record of SPF/DKIM/DMARC values)

On HostMyCode, pair your VPS with snapshots/offsite copies.

That way you can rebuild quickly after a mistake or compromise.

If you want a restore-tested routine, follow this snapshot backup tutorial.

Troubleshooting cheat sheet (fast checks that save hours)

SPF fails: multiple SPF TXT records, wrong sending IP, or your app is sending via a third-party service not included in SPF.
DKIM fails: DNS record truncated, wrong selector name, OpenDKIM can’t read the private key, or Postfix isn’t calling the milter.
DMARC fails: SPF passes but not aligned (From domain differs), or DKIM signs with a different domain than the visible From.
rDNS mismatch: PTR points elsewhere, or A record doesn’t map back to the same IP.
Rejected with “HELO” issues: your server introduces itself as localhost, or HELO doesn’t resolve in DNS.

Tip: if you manage mail for clients, keep a small runbook.

Document your standard selector naming (like s2026) and your DMARC rollout schedule. Consistency prevents easy mistakes.

Summary: your “pass on first try” checklist

Forward DNS: mail.example.com A → your VPS IP
PTR: your VPS IP → mail.example.com
Postfix identity: myhostname=mail.example.com
SPF: one TXT record that covers your real senders
DKIM: OpenDKIM installed, milter wired, public key published
DMARC: start with p=none, then tighten based on reports
Test: confirm spf=pass, dkim=pass, dmarc=pass in headers

If you want email to stay boring (the best outcome), run it on infrastructure where you control IP reputation, rDNS, and firewall rules.

That’s exactly what a VPS is for.

If you’re setting up authenticated outbound email for WordPress, billing apps, or client mailboxes, start on a VPS you can tune and monitor. Choose a managed VPS hosting plan if you want experts handling OS and mail-stack upkeep, or pick a HostMyCode VPS if you prefer full control over Postfix, OpenDKIM, DNS, and rDNS.

FAQ

Do I need all four: SPF, DKIM, DMARC, and rDNS?

For reliable delivery in 2026, yes.

SPF and DKIM prove authorization and integrity. DMARC enforces alignment. rDNS helps show that your IP belongs to a real mail host.

What DMARC policy should I start with?

Start with p=none so you can collect reports and find legitimate senders you forgot.

Move to quarantine and then reject once you see clean alignment.

Can I reuse the same DKIM key forever?

You can, but you shouldn’t.

Rotate selectors periodically (for example annually) so a long-lived key isn’t your single point of failure. Keep old selectors published until old mail is unlikely to be verified.

My WordPress site sends mail through the VPS, but DKIM still fails. Why?

Often WordPress is using PHP mail() locally, but Postfix isn’t passing through the DKIM milter.

Another common cause is a wrong milter socket path. Check /etc/postfix/main.cf milter lines and OpenDKIM service logs.

What if I’m on shared hosting and can’t set rDNS?

You can still publish SPF/DKIM/DMARC, but you’re limited by the shared IP’s reputation and PTR.

If email is business-critical, move sending to a VPS where you control rDNS and server identity.