SPF, DKIM and DMARC explained (in plain English) | Scanthra

Scanthra · 7 min read · Updated May 2026

The 30-second explanation

• SPF — a list of servers allowed to send mail from your domain.
• DKIM — a digital signature on every message, proving it really came from your domain and wasn't tampered with.
• DMARC — your policy telling receivers what to do with mail that fails SPF or DKIM (allow, quarantine, reject) and where to send reports.

All three are DNS TXT records. You add them once and forget about them (until you change mailbox provider).

Why a small business should care

Two concrete consequences of missing SPF/DKIM/DMARC, both common:

• Customers see "via mailer.scanthra.net" in Gmail instead of your domain. Subtle, but it kills trust on the first email.
• Anyone can impersonate you. A scammer sends "Invoice overdue — pay this account" from billing@yourshop.com to your customers. With strict DMARC, the message is rejected before it lands. Without, it lands in inbox.

Microsoft and Google now require SPF + DKIM + DMARC for bulk senders (since February 2024). If you send any volume of email — even transactional receipts from a WordPress shop — missing records will start hurting deliverability.

SPF — the allow-list

An SPF record looks like this:

yourdomain.com.  IN TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Three things to know:

• v=spf1 — always required, version marker.
• include: — points to your mailbox or transactional sender's own SPF. Each provider tells you which value to use.
• ~all — the policy for anyone else. Use ~all (softfail) while testing, -all (hardfail) once stable.

Limit: 10 DNS lookups. Each include: counts. Stacking too many providers breaks SPF silently. If you hit the limit, use an SPF flattener like the one bundled with EasyDMARC, Postmark or Cloudflare.

DKIM — the signature

DKIM signs each outgoing message with a private key that lives on the mail server, and publishes the matching public key in DNS:

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

Each provider has its own selector (selector1, google, k1, etc.). Follow your provider's instructions verbatim — they generate the exact value to paste. You can have multiple DKIM records, one per provider, side by side.

DMARC — your policy

A starter DMARC record:

_dmarc.yourdomain.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=s; aspf=s"

Key fields:

• p=none — receive reports, take no action. Always start here.
• p=quarantine — failing mail goes to spam.
• p=reject — failing mail is bounced. The target state.
• rua=mailto:... — daily aggregate reports. Pipe these into a free reader like Postmark DMARC Digests or dmarcian.

The safe rollout

1. Add SPF and DKIM for every legitimate sender (your mailbox provider, transactional sender, marketing tool, helpdesk).
2. Publish DMARC with p=none. Wait 2–4 weeks while reading aggregate reports.
3. When all legitimate sources align (no "fail" lines from your own services), move to p=quarantine.
4. After another 2–4 weeks of clean reports, move to p=reject.

This staged rollout is what every large enterprise does. Skipping straight to p=reject works — until the day Marketing buys a new tool and stops getting emails through. Then it's a fire drill.

Common mistakes

• Two SPF records on the same hostname — they don't add up, they cancel each other out. Always merge into one.
• Forgetting to add SPF/DKIM for your marketing sender (Mailchimp, Brevo, HubSpot). Those go out under your domain too.
• Wrong DMARC subdomain policy (sp=) — if you have p=reject but no sp=, subdomains inherit relaxed policy. Be explicit.
• Using ?all in SPF. It's effectively "no policy" — receivers ignore it.

How Scanthra checks these

Our Email Security module does passive DNS lookups for SPF, DKIM (common selectors) and DMARC. We flag missing records, weak policies (p=none only after grace period), SPF lookup-count overflow and SPF records with ?all or +all. You'll see the exact gap in your PDF report.