SPF, DKIM and DMARC explained — the three records that keep your email out of spam

Deliverability is mostly DNS. If your outbound mail keeps landing in junk folders, the cause is almost always a missing or misconfigured SPF, DKIM or DMARC record. Here's what each does and how to set them up in the right order.

The problem all three solve

SMTP was designed without authentication — anyone can claim to send as anyone. These three records retrofit trust onto that: proving a message came from a server you authorised, that it wasn't altered, and what to do when either check fails.

Since 2024, Google and Yahoo require all three from bulk senders. They're no longer optional.

SPF — who is allowed to send as you

A TXT record listing the servers permitted to send mail for your domain.

v=spf1 include:_spf.tobavamail.com ~all

• include: — authorise another provider's servers (your mail host, CRM, invoicing tool)
• ~all — soft fail: anything else is suspicious. -all is a hard fail; move to it once you're confident
• One SPF record per domain, ever. Two records is a permanent error — merge the includes into one
• The 10-lookup limit — each include: costs a DNS lookup, and exceeding ten breaks SPF entirely. Trim services you no longer use

What SPF misses: it validates the envelope sender, not the From: header your recipient sees. On its own, it doesn't stop display-name spoofing.

DKIM — a signature proving nothing changed

Your server signs outbound mail with a private key; the matching public key is published in DNS. The receiver verifies the signature.

s1._domainkey.yourdomain.com   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

The part before ._domainkey is the selector, which lets you rotate keys by publishing a new one alongside the old. Use whichever selector your provider gives you — copy it exactly rather than assuming a convention.

Copy the value exactly. The single most common DKIM failure we see is a record with stray text pasted in front of v=DKIM1 from a control panel's label, or a key split incorrectly across lines. Some receivers tolerate it; strict ones don't — so it fails intermittently, which is far harder to diagnose than failing outright.

Verify it cryptographically rather than by eye. Long base64 strings all look correct at a glance:

dig +short TXT s1._domainkey.yourdomain.com

Then compare against the key in your provider's settings.

DMARC — what to do when the first two fail

DMARC ties SPF and DKIM to the visible From: address (alignment) and tells receivers what to do on failure — plus sends you reports.

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r"

• p=none — monitor only, change nothing
• p=quarantine — send failures to spam
• p=reject — refuse them outright
• rua= — where aggregate XML reports go
• adkim/aspf — r relaxed (subdomains count) or s strict

**DMARC passes if SPF *or* DKIM passes with alignment.** You don't need both, though both is better.

The safe rollout order

1. Publish SPF. Verify with dig +short TXT yourdomain.com
2. Enable DKIM signing and publish the key. Send a test to Gmail; check Show original for dkim=pass
3. Publish DMARC at p=none. Nothing changes for recipients yet
4. Read reports for two to four weeks. You'll discover legitimate senders you forgot — the invoicing system, the booking tool
5. Move to p=quarantine, watch for a fortnight
6. Move to p=reject once reports are clean

Reading a DMARC report

Aggregate reports are XML, one record per sending source:

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>3</count>
    <policy_evaluated><disposition>none</disposition>
      <dkim>pass</dkim><spf>pass</spf></policy_evaluated>
  </row>
</record>

count is how many messages, disposition is what the receiver did. Unfamiliar source IPs sending as your domain are either a forgotten service or someone spoofing you — both worth knowing about.

Common causes of "we set it up and mail still goes to spam"

• Two SPF records (invalid — merge them)
• More than 10 SPF DNS lookups
• DKIM key mismatched after a provider change or key rotation without updating DNS
• DMARC alignment failing because a third-party tool sends from its own domain
• No reverse DNS (PTR) on your sending IP
• Reputation still building on a brand-new domain — authentication is necessary, not sufficient