Learn Mailserver - DNS: MX, SPF, DKIM & DMARC

#Introduction

Your mail server is standing, but not yet "connected" to the world. The bridge is DNS. Without a correct MX record, no other server will accept your email. Without complete SPF, DKIM, and DMARC, your email is suspected of being fake and ends up in spam.

This episode covers the four main records: MX (route), SPF (authorization), DKIM (signature), and DMARC (policy), plus rDNS/PTR as a reputation complement. We'll also learn how to verify everything with dig.

#MX Record: Pointing the Way In

MX (Mail Exchanger) tells other MTAs: "to receive email for this domain, send to this host". Its syntax contains the destination host and a priority — a lower number means higher priority:

example.com.  IN MX  10 mail.example.com.

If there are two records, say priorities 10 and 20, other servers try 10 first, then fall back to 20 when the first is down. For our lab, one record is enough.

Add it in your DNS panel, then verify:

dig MX example.com +short
host -t MX example.com

If the output shows 10 mail.example.com, the inbound route is open. Remember: MX must point to a host, not directly to an IP.

#SPF: Who Is Allowed to Send

SPF (Sender Policy Framework) answers the question: "which servers are legitimate to send email on behalf of this domain?" The answer is written as a TXT record at the domain root:

dig TXT example.com +short

A complete SPF record looks like this:

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

This means: only the server listed as MX and IP 203.0.113.10 may send on behalf of example.com; anything else is rejected (-all). You may have at most one SPF record per domain — more than one will trigger an error.

#DKIM: Cryptographic Signatures

DKIM (DomainKeys Identified Mail) gives every email a cryptographic signature. The sender signs the headers and body with a private key; the recipient verifies with the public key published as a TXT record. The key is stored under a selector, for example:

mail._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIGfMA0...abc123"

We'll build the full signing setup with OpenDKIM in episode 17. For now, what you need to understand: whenever you see a name like mail._domainkey, it's the DKIM public key belonging to the mail selector for your domain. Signing happens on the sender's side, while verification happens on the recipient's side — two sides that must never be confused.

#DMARC: Policy When Authentication Fails

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells recipients what to do if SPF and DKIM fail or don't align. The record lives on the _dmarc subdomain:

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

The p value defines the policy:

rua is the address that receives aggregate reports. The staged escalation strategy none → quarantine → reject is something you'll execute in episode 17.

#rDNS/PTR: The Reverse Face of Your IP

The PTR record (reverse DNS) maps an IP back to a hostname — the reverse of an A record. Major receiving servers check PTR to assess reputation. The common requirement: PTR 203.0.113.10 must point to mail.example.com, and mail.example.com must have an A record back to that IP (forward-confirmed reverse DNS / FCrDNS).

PTR is usually configured in the VPS provider's panel, not the registrar. Verify:

dig -x 203.0.113.10 +short
dig A mail.example.com +short

If both queries return values that match each other, your FCrDNS is complete.

#Full Verification with dig

The habit of checking all DNS records in one line will save you during deliverability debugging:

dig MX example.com +short
dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig TXT mail._domainkey.example.com +short
dig -x 203.0.113.10 +short

Also practice with host and nslookup — each is useful in different scenarios. Once all records return the expected values, test with online tools like mail-tester or dmarctester; episode 19 explains how to read the scores.

#Conclusion

Episode 5 is done. Key takeaways:

• MX points to the receiving server with priority; use a host, not an IP.
• SPF restricts the servers allowed to send; at most one record per domain.
• DKIM publishes the public key under a selector; signing is covered in episode 17.
• DMARC defines the none → quarantine → reject policy plus rua reports.
• Correct PTR/FCrDNS is a prerequisite for IP reputation.

DNS is now complete. In episode 6 we secure every path: TLS — Let's Encrypt certificates, configuration in Postfix and Dovecot, and TLS enforcement on all ports. See you in episode 6!