SPF DKIM DMARC Setup Guide (Tutorial) for VPS Email Deliverability in 2026

Why your emails land in spam (and how this tutorial fixes it)

Email deliverability usually fails for unglamorous reasons. Common causes include missing DNS records, domain alignment problems, or a server IP that doesn’t clearly “belong” to your domain.

The quickest fix is to publish correct SPF, DKIM, and DMARC records. Then confirm they work with real message tests.

This SPF DKIM DMARC setup guide is for VPS and dedicated server operators who send mail from their own hostnames (Postfix/Exim, control panels, apps, or transactional tools).

You’ll create the DNS records, verify alignment, and roll out DMARC safely. No trial-and-error required.

If you’re debating whether to run mail yourself: it’s doable. But treat DNS, rDNS, and authentication as mandatory.

In 2026, major mailbox providers distrust “anonymous” server mail by default.

Prerequisites (don’t skip these)

• A domain you control in DNS.
• Access to DNS editing (registrar DNS, Cloudflare, cPanel Zone Editor, etc.).
• Your sending method: a mail server (Postfix/Exim), a control panel (cPanel/WHM), or an app sending SMTP.
• A stable sending identity: you should send from mail.yourdomain.com (or similar), not from a random hostname.

Plan to set reverse DNS for your sending IP, too. Many providers weigh rDNS heavily, especially on new or low-reputation IP ranges.

Step 1: Decide your “From” domain and your mail hostname

Before you edit DNS, lock in two identifiers. Then use them consistently.

• Visible From domain: the address users see, e.g. billing@yourdomain.com.
• Sending hostname (HELO/EHLO): typically mail.yourdomain.com.

On a VPS, your MTA (Postfix/Exim) should announce mail.yourdomain.com. Your SMTP banner should match it.

In cPanel/WHM environments, this usually corresponds to the server “Hostname” in WHM.

Step 2: Set reverse DNS (rDNS) and match it to your mail hostname

Reverse DNS maps your server IP back to a hostname. For mail, it’s a basic trust signal.

It also helps you avoid the “generic VPS” look.

Set your IP’s PTR record to mail.yourdomain.com. Then make sure mail.yourdomain.com resolves back to that same IP (forward-confirmed rDNS).

HostMyCode customers typically do this through the VPS control panel or a support workflow, depending on the plan. Follow this walkthrough: Reverse DNS setup guide for VPS and dedicated servers.

Quick check from your laptop:

# Replace with your server IP
dig +short -x 203.0.113.10

# Replace with your mail hostname
dig +short A mail.yourdomain.com

You want the PTR to return mail.yourdomain.com. You also want the A record to return the same IP.

Step 3: Create a proper SPF record (tight, minimal, and readable)

SPF tells recipients which servers are allowed to send mail for your domain. Keep it simple.

Authorize only what you actually use.

Start by listing your senders:

• Your VPS/dedicated server public IP (Postfix/Exim/cPanel)
• Any third-party senders (e.g. Google Workspace, Microsoft 365, marketing platforms)

Common SPF record (single server IP):

v=spf1 ip4:203.0.113.10 -all

If you also send via another provider that publishes an include:

v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

Where to publish it: create a TXT record at your root (often shown as @) for yourdomain.com.

Practical warnings:

• Don’t create multiple SPF TXT records at the root. SPF must be a single record; put everything inside one policy.
• Avoid ~all as a permanent setting. Use it only for short transition windows.
• SPF has a 10-lookup limit. Long include: chains can trigger “permerror”.

Verify SPF:

dig +short TXT yourdomain.com

Step 4: Enable DKIM signing (cPanel/WHM and non-cPanel options)

DKIM signs each outgoing message with a private key. Receivers validate the signature using a public key you publish in DNS.

If you send from your own server, DKIM is often the fastest improvement for inbox placement.

Option A: DKIM in cPanel/WHM (fastest for hosting and resellers)

If you run WHM, you typically enable DKIM per domain here:

• WHM → Email → Email Deliverability

WHM will show the recommended DKIM TXT record. If your DNS is managed on the same server, WHM can often install it automatically.

What you should see in DNS (example):

• Name/Host: default._domainkey (or a selector you choose)
• Type: TXT
• Value: v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY...

Tip for multi-tenant hosting: stick with a consistent selector like default.

Change it only if you’re rotating keys per app or per sender.

Option B: DKIM with OpenDKIM on Ubuntu/Debian (common on VPS)

If you manage Postfix yourself, OpenDKIM is a common approach.

Exact steps vary by distro and mail stack. The workflow is consistent.

Install OpenDKIM, generate a key, configure selector mapping, and publish the public key in DNS.

Install packages (Ubuntu 24.04/26.04 style):

sudo apt update
sudo apt install opendkim opendkim-tools

Generate a DKIM key for your domain:

sudo mkdir -p /etc/opendkim/keys/yourdomain.com
sudo opendkim-genkey -D /etc/opendkim/keys/yourdomain.com -d yourdomain.com -s default
sudo chown -R opendkim:opendkim /etc/opendkim/keys/yourdomain.com
sudo chmod 600 /etc/opendkim/keys/yourdomain.com/default.private

This creates two files:

• default.private (keep on the server)
• default.txt (contains the DNS TXT record)

Publish the DKIM DNS record: open /etc/opendkim/keys/yourdomain.com/default.txt and copy the TXT value into DNS at default._domainkey.yourdomain.com.

Basic verification once published:

dig +short TXT default._domainkey.yourdomain.com

If you can’t see it, check the basics:

• You published it under the wrong host.
• DNS hasn’t propagated yet.
• The value was pasted with extra quotes or broken lines.

Step 5: Publish DMARC (start with monitoring, then enforce)

DMARC ties SPF and DKIM together. It tells receivers what to do when checks fail.

It also provides reporting. Those reports are how you find unknown systems sending as your domain.

DMARC lives at _dmarc.yourdomain.com as a TXT record.

A safe DMARC record to start (monitor-only)

v=DMARC1; p=none; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1; pct=100

• p=none collects reports without rejecting/quarantining.
• adkim=s and aspf=s prefer strict alignment (a good default for most single-domain setups).
• rua aggregate reports; ruf forensic reports (many receivers no longer send these, but it’s still fine to publish).

Create the mailbox first: if dmarc@yourdomain.com doesn’t exist, create it (or use an alias).

Reports can be noisy. If possible, route them to a separate mailbox.

Move to quarantine, then reject (when reports look clean)

Once your legitimate sources consistently pass DMARC, tighten the policy:

# quarantine failing mail
v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.com; pct=100

# reject failing mail
v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.com; pct=100

Don’t jump to p=reject if you send from multiple systems. Confirm every source first.

A missed sender can break password resets, receipts, and ticketing mail.

Step 6: Test SPF, DKIM, and DMARC (real messages, real headers)

DNS can look perfect and still fail in practice. Send real messages to a mailbox you control (Gmail, Outlook, Fastmail, etc.).

Then inspect the headers.

Header fields to look for:

• Authentication-Results: should show spf=pass, dkim=pass, and dmarc=pass.
• DKIM-Signature: should include d=yourdomain.com and selector s=default (or your selector).

Quick on-server check (useful if you control the MTA):

# check what your server thinks its hostname is
hostname -f

# check listening services
sudo ss -lntp | egrep ':25|:465|:587'

# watch mail logs during a test send (paths vary by distro/MTA)
sudo tail -f /var/log/mail.log

Step 7: Fix the most common failures (fast troubleshooting table)

Symptom	Likely cause	Fix
SPF “permerror”	Too many DNS lookups or malformed record	Remove unnecessary includes; keep a single SPF record; re-check syntax
DKIM “fail (bad signature)”	Key mismatch, wrong selector, or mail modified in transit	Confirm selector matches DNS; re-publish key; avoid broken outbound relays that rewrite bodies
DMARC “fail (p=reject)” and mail disappears	Alignment failure: From domain differs from SPF/DKIM domain	Ensure d= in DKIM matches From; ensure SPF uses the same domain or set alignment policy carefully
Mail rejected with “no PTR” / “rDNS required”	No reverse DNS for your IP	Set PTR to your mail hostname and ensure forward-confirmed DNS
Outgoing mail rate-limited	New IP reputation or too many messages too quickly	Warm up sending; keep volumes steady; ensure authentication passes; avoid list blasts from fresh IPs

Step 8: Add the “supporting” DNS records that help deliverability

SPF/DKIM/DMARC are the core. A few extra records improve mail hygiene and reduce spoofing risk.

Set an MX record that matches your mail plan

If your VPS receives mail, publish:

yourdomain.com.  MX 10 mail.yourdomain.com.

Also create the A/AAAA records for mail.yourdomain.com.

Add an MTA-STS policy (optional but useful)

MTA-STS tells senders that your domain expects TLS for inbound delivery. It helps prevent downgrade attacks.

Some providers also treat it as a positive quality signal.

• DNS TXT at _mta-sts.yourdomain.com
• HTTPS policy at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

If you already run Nginx, hosting the policy is straightforward. If you need an SSL certificate for that host, this guide helps: SSL certificate setup for Ubuntu VPS with Nginx + Let’s Encrypt.

Consider a TLS-RPT record (reporting for TLS delivery issues)

TLS-RPT collects reports about failed TLS connections. Publish:

_smtp._tls.yourdomain.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"

Step 9: Make sure your server isn’t fighting you (firewall + ports)

You can publish perfect DNS and still fail if outbound SMTP is blocked or misrouted.

On VPSes, open only the ports you need. Then confirm they’re reachable.

At minimum for typical hosting mail setups:

• 25/tcp (server-to-server SMTP)
• 587/tcp (submission for authenticated clients)
• 465/tcp (SMTPS, optional but common)

If you’re hardening Ubuntu with UFW, use a known-good rule set so you don’t accidentally block SMTP: UFW firewall setup tutorial for hosting-friendly defaults.

Step 10: Deployment checklist (copy/paste before you flip DMARC to enforce)

• PTR (rDNS) set to mail.yourdomain.com and mail.yourdomain.com A record points to the same IP
• Server hostname matches the mail hostname (hostname -f)
• SPF published as a single TXT record at root; includes only actual senders
• DKIM enabled and signing; selector TXT record exists and matches server private key
• DMARC published at _dmarc with p=none initially and valid reporting mailbox
• Test emails show spf=pass, dkim=pass, dmarc=pass
• No unknown platforms sending as your domain (verify via DMARC reports)

Where HostMyCode fits (VPS, managed support, and mail-friendly defaults)

If you want direct control over your sending identity and DNS, a VPS is a sensible place to start.

You get a dedicated IP, consistent hostnames, and the flexibility to run the mail stack you need.

For hands-on admins, start with a HostMyCode VPS.

If you’d rather offload OS hardening and ongoing system maintenance, consider managed VPS hosting and keep your focus on application work.

FAQ

How long should I keep DMARC at p=none?

Keep p=none until DMARC reports show only your known senders and your test emails consistently pass alignment.

For many small setups, that’s 1–2 weeks of normal sending.

Can I publish SPF, DKIM, and DMARC if I use a third-party SMTP provider?

Yes. You still publish them on your domain.

Your SPF will include the provider, and your DKIM will either be configured in the provider or on your server depending on who signs messages.

What’s “alignment” in DMARC and why does it matter?

DMARC checks whether the domain in the visible From: header aligns with the domain validated by SPF and/or DKIM.

If you sign with a different domain (or send bounce mail from a different domain), DMARC can fail even if SPF/DKIM individually pass.

Do I need rDNS if SPF/DKIM/DMARC are correct?

For serious sending from a VPS or dedicated IP, yes. Many receivers score rDNS heavily, and some refuse connections without it.

Set PTR and confirm it matches forward DNS.

What’s the fastest way to improve deliverability on a new VPS IP?

Get the basics perfect (rDNS, SPF, DKIM, DMARC), then keep volume steady. Avoid large campaigns from a fresh IP.

If you must send higher volume, warm up gradually and monitor bounces and spam folder placement.

Summary: the deliverability baseline you can trust in 2026

A dependable mail setup in 2026 has a few non-negotiables: rDNS that matches your mail hostname, an SPF record that authorizes only real senders, DKIM signing that validates cleanly, and DMARC that starts in monitoring before you enforce.

If you want a predictable foundation for that workflow, run it on a HostMyCode VPS. You control DNS, identity, and server configuration.

You can also respond quickly when mailbox providers adjust how they score mail.