PTR, SPF, DKIM, and DMARC: What They Are and Why Self-Hosted Mail Needs All of Them
If you self-host email, these four records are not optional extras. They are how receiving servers decide whether your message is legitimate or spam. Missing or broken records are the most common reason self-hosted mail lands in junk or is rejected outright.
Here is what each one actually does, in plain terms.
Why These Records Exist
The Problem
Anyone Can Claim to Be You
SMTP was designed in an era when you trusted the sender. Without extra checks, anyone can send mail claiming to be from your domain.
The Response
Prove the IP and the Message
Receiving servers now require proof that the sending IP is authorized and that the message was not altered in transit.
The Result
Inbox or Spam Folder
Gmail, Outlook, and Yahoo treat missing or failing authentication as a strong spam signal. In 2026, proper records are table stakes for delivery.
The Four Records
Reverse DNS
PTR Record
Points an IP address back to a hostname. Your mail server’s IP must reverse-resolve to the hostname it uses in EHLO/HELO. Without a matching PTR, most providers reject or heavily filter your mail.
Authorized Senders
SPF Record
A DNS TXT record that lists which IPs (or hosts) are allowed to send mail for your domain. Receiving servers check the connecting IP against this list. Keep it simple — too many includes cause failures.
Message Signature
DKIM
Your server cryptographically signs outgoing messages. The public key is published in DNS. Receivers verify the signature to confirm the message was not altered and came from a key you control.
Policy and Reporting
DMARC
Tells receivers what to do if SPF or DKIM fails (none, quarantine, or reject) and where to send reports. It also requires alignment — the domain in the From header must match the SPF or DKIM domain.
Order of Operations
They Work Together
PTR proves the IP. SPF proves the IP is allowed. DKIM proves the message is intact. DMARC ties the From domain to those checks and tells receivers what to do on failure.
Common Mistake
SPF or DKIM Alone Is Not Enough
Many setups pass SPF but fail DKIM alignment, or have a PTR that does not match the hostname. Receivers need all of them to pass cleanly.
Practical Checklist for Self-Hosted Mail
1 — Set the PTR first
Contact your VPS or datacenter provider and set the reverse DNS for your mail IP to the exact hostname your server announces (e.g., mail.yourdomain.com). Confirm it resolves both ways.
2 — Publish a minimal SPF
Start with something like v=spf1 mx a -all or include only the IPs that actually send. Avoid long chains of includes. Test with a tool before you go live.
3 — Enable DKIM and publish the key
Generate a key in Mailcow, iRedMail, or your MTA. Publish the public key as a TXT record. Send a test message and confirm the signature validates.
4 — Add a DMARC policy
Start with p=none and a reporting address so you can see failures. Once clean, move to p=quarantine or p=reject. Alignment must match your From domain.
Official Resources
Questions for the Community
Which record gave you the most trouble?
PTR, SPF includes, DKIM signing, or DMARC alignment?
How are you testing these today?
Mail-tester, MXToolbox, or something else?
Did you start with p=none or go straight to reject?
What happened?
PTR, SPF, DKIM, and DMARC are the minimum authentication stack for any self-hosted mail server that expects to reach the inbox. Get the PTR matching the hostname, keep SPF short, sign with DKIM, and publish a DMARC policy. Everything else is secondary until these pass.
Disclaimer
This content is for educational and informational purposes only. It is not technical advice. Email authentication and DNS changes can affect delivery. Test thoroughly on a non-production domain and monitor reports before tightening policies.
No replies yet. Be the first to join the discussion!
