Email DNS explained: SPF, DKIM and DMARC

If your email keeps landing in spam — or worse, someone is spoofing your domain to send scams — the fix lives in DNS. Three record types work together to prove your mail is genuine: SPF, DKIM and DMARC. Here's what each does and exactly what to set.

The problem they solve

Email was designed without built-in authentication, so anyone can *claim* to send as your domain. SPF, DKIM and DMARC let receiving servers verify that mail claiming to be from you actually is — which both protects your reputation and lifts your deliverability. Set all three; they reinforce each other.

SPF — who's allowed to send

SPF (Sender Policy Framework) lists which servers are permitted to send email for your domain. It's a single TXT record:

Type: TXT
Name: @
Value: "v=spf1 include:_spf.google.com include:mail.example.net ~all"
TTL: 3600

Breaking it down:

• v=spf1 — this is an SPF record.
• include:... — authorise these providers' servers (your email host will give you the exact include).
• ~all — soft-fail anything not listed (mark as suspicious). Use -all for a strict hard-fail once you're confident.

Rule: you may only have *one* SPF record per domain. If you use several mail services, combine their includes into a single record.

DKIM — a cryptographic signature

DKIM (DomainKeys Identified Mail) adds a digital signature to every message, which the receiver verifies against a public key you publish in DNS. It proves the mail wasn't tampered with and genuinely came from you.

Your email provider generates a key and gives you a record to publish, usually as a TXT (or CNAME) at a *selector* subdomain:

Type: TXT
Name: selector1._domainkey
Value: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."
TTL: 3600

You don't craft this by hand — you paste what your provider supplies. The selector lets you rotate keys later without breaking mail.

DMARC — the policy that ties it together

DMARC tells receiving servers what to do when a message *fails* SPF and DKIM, and where to send reports. It's a TXT record at a fixed subdomain:

Type: TXT
Name: _dmarc
Value: "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
TTL: 3600

The key part is the policy:

• p=none — monitor only; don't act on failures. Start here and read the reports.
• p=quarantine — send failing mail to spam.
• p=reject — refuse failing mail outright. The strongest anti-spoofing stance.

The rua= address receives aggregate reports so you can see who's sending as your domain before you tighten the policy.

The rollout order

Do it in this sequence to avoid blocking your own legitimate mail:

1. Publish SPF with your sending providers, ending in ~all.
2. Enable DKIM using the key from your email host.
3. Add DMARC with p=none and a reporting address.
4. Read the reports for a couple of weeks to confirm all your real senders pass.
5. Tighten gradually to p=quarantine, then p=reject, and consider -all on SPF.

Verify your setup

Check what's published:

dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig TXT selector1._domainkey.example.com +short

The payoff

With SPF, DKIM and DMARC in place, mailbox providers trust your mail more (better inbox placement) and scammers can't convincingly spoof your domain. All three are just DNS records — and in Nxeon's DNS panel you can add them right where the rest of your domain's records live, then let propagation carry them out to the world.