Email Authentication: SPF, DKIM & DMARC Explained

Anyone on the internet can send an email that claims to be from your domain. The visible From: address is just text — nothing in the core email protocol forces it to be true.

SPF, DKIM and DMARC are the three DNS-published standards that let receiving servers verify that a message really came from infrastructure you authorised, and that let you tell those servers what to do with the messages that fail. Configured together, they are what stop attackers from spoofing your domain in phishing and business-email-compromise attacks.

The guides in this cluster, at a glance

This pillar explains the concepts. The guides below are the practical, task-focused companions — provider walk-throughs and fixes for the specific findings a checker reports. Start here if you already know what you need to do.

Why does email need authentication at all?

SMTP, the protocol that moves mail between servers, was designed in an era of mutual trust. It distinguishes between the envelope sender (the MAIL FROM address used during the SMTP transaction, also called the Return-Path) and the header From (the address your recipient actually sees in their mail client). Neither is verified by the protocol itself. A spammer can connect to a mail server, announce that the message is from billing@yourbank.example, and the message will be delivered with that header intact.

This gap is the root cause of most phishing and business email compromise. Because the From header is the field humans trust, an unauthenticated domain can be impersonated by anyone, and your customers, staff and suppliers have no reliable way to tell a real message from a forgery. Email authentication closes the gap with three complementary mechanisms, all published as DNS records:

• SPF (Sender Policy Framework, RFC 7208) authorises which servers may send mail using your envelope sender domain.
• DKIM (DomainKeys Identified Mail, RFC 6376) cryptographically signs messages so a receiver can verify they were not altered and came from your domain.
• DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) ties SPF and DKIM to the visible From domain, tells receivers what to do on failure, and provides reporting.

None of the three is sufficient on its own. SPF and DKIM each authenticate a domain that the recipient may never see; only DMARC binds authentication to the From header that matters. The rest of this guide explains each layer and the order in which to deploy them.

What does SPF do?

SPF lets you publish, in DNS, the list of hosts permitted to send mail for your domain. A receiving server looks at the envelope sender domain, fetches that domain's SPF record, and checks whether the connecting IP address is authorised. SPF is published as a single TXT record at the root of the domain, beginning with v=spf1:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.10 -all"

Each term is a mechanism. include: pulls in another domain's authorised hosts (how you authorise providers like Google Workspace or SendGrid), ip4: and ip6: authorise specific addresses or ranges, and a / mx authorise the hosts named in your A or MX records. The mechanisms are evaluated left to right; the first match wins.

The all mechanism: -all vs ~all

The final mechanism is the catch-all that decides the verdict for any sender that did not match. The qualifier in front of it matters:

• -all (hard fail) — anything not explicitly listed fails SPF. This is the goal state and what you want once you are confident your record is complete.
• ~all (soft fail) — non-listed senders are marked as suspicious but not outright rejected. Useful as a transitional setting while you confirm you have not missed a legitimate sender.
• +all — authorises the entire internet. Never use this; it neutralises SPF completely.

The 10-DNS-lookup limit

RFC 7208 caps the number of DNS-querying mechanisms an SPF record may trigger at ten. Every include, a, mx, ptr and exists term counts toward this limit, including lookups nested inside the records you include.

Exceed it and the receiver must return a permerror, which under DMARC counts as an SPF failure. Because each third-party provider you add typically consumes one or more lookups, busy domains hit the ceiling quickly.

Keep the record lean: remove providers you no longer use, prefer ip4/ip6 over include where a provider publishes stable addresses, and consider SPF flattening only with a service that keeps the flattened record updated.

What does DKIM do?

DKIM (RFC 6376) attaches a digital signature to every outgoing message. Your sending server signs selected headers and the body with a private key; the matching public key is published in DNS. A receiving server reads the DKIM-Signature header, fetches the public key, and verifies that the signed content has not been altered in transit and that it was signed by a key belonging to your domain.

DKIM uses selectors so a single domain can publish several keys — one per provider, or rotated over time. The selector is named in the signature header and tells the receiver which key to fetch. The public key lives at <selector>._domainkey.<domain> as a TXT record:

s1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

The p= tag holds the base64-encoded public key. A corresponding DKIM-Signature header on the message names the selector and the signing domain:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1;
  h=from:to:subject:date; bh=...; b=...

Here d= is the signing domain and s= is the selector. Because DKIM signs the message itself rather than the connecting IP, a valid DKIM signature survives legitimate forwarding that would otherwise break SPF — one reason DMARC accepts either SPF or DKIM as a pass.

Use at least 2048-bit RSA keys where your provider supports them, and rotate keys periodically by publishing a new selector before retiring the old one.

What does DMARC do?

DMARC (RFC 7489) is the layer that turns SPF and DKIM into real spoofing protection. It does three things: it requires that an authenticated domain align with the visible From domain, it tells receivers what policy to apply when a message fails, and it asks receivers to send you reports. The policy is a TXT record at the _dmarc subdomain:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1; adkim=s; aspf=s"

The key tags:

• p= — the policy applied to mail that fails DMARC: none (take no action, just monitor), quarantine (treat as suspicious, typically deliver to spam) or reject (block outright). reject is the only policy that actually stops spoofed mail reaching inboxes.
• rua= — address for aggregate reports: daily XML summaries from receivers showing which IPs sent mail under your domain and whether they passed SPF, DKIM and alignment. This is the data you use to find your legitimate senders before enforcing.
• ruf= — address for forensic/failure reports (per-message redacted samples). Support is patchy and they can contain personal data, so many operators omit them.
• sp= — a separate policy for subdomains; pct= — apply the policy to a percentage of failing mail (useful for staged rollout); adkim / aspf — alignment strictness (r relaxed, the default, or s strict).

Alignment is the whole point

DMARC passes only if at least one of SPF or DKIM both passes and is aligned with the From domain. Alignment means the domain that SPF or DKIM authenticated matches the domain in the visible From header. Under relaxed alignment (the default) the organisational domains must match — mail.example.com aligns with example.com. Under strict alignment the domains must be identical. This alignment check is exactly what plugs the hole SPF and DKIM leave open: an attacker can pass SPF for a domain they own, but they cannot make that domain align with your From header.

A safe rollout order

DMARC enforcement can silently block your own legitimate mail if you jump straight to p=reject before you know every system that sends as your domain. The standards-aligned approach, echoed in M3AAWG deployment guidance, is to monitor first and enforce gradually:

• 1. Publish SPF and DKIM. Get a correct SPF record (with ~all to start) and DKIM signing enabled on every legitimate sending service.
• 2. Deploy DMARC at p=none with rua. This changes nothing about delivery but starts the flow of aggregate reports.
• 3. Read the reports. Use the aggregate data to find every system sending as your domain and fix their SPF/DKIM and alignment until all legitimate mail passes. This is the step that takes real calendar time.
• 4. Move to p=quarantine. Optionally ramp with pct= (e.g. 25, then 50, then 100). Watch reports for collateral damage.
• 5. Move to p=reject. Once quarantine is clean, enforce. Tighten SPF to -all and consider strict alignment.

Common mistakes

• More than one SPF record. A domain must publish exactly one v=spf1 TXT record. Two records are a permerrorand cause SPF to fail entirely. Merge them into a single record.
• Too many DNS lookups. Crossing the ten-lookup limit gives a permerror and breaks SPF, often silently. Audit your include chains as you add and remove providers.
• Ignoring alignment. A message can pass raw SPF or DKIM and still fail DMARC because the authenticated domain does not match the From domain. Many third-party senders need explicit configuration (a custom return-path or a CNAME for DKIM) to align.
• Living at p=none forever. Monitoring without ever enforcing leaves your domain spoofable. Treat p=none as temporary.
• Forgetting non-sending and parked domains. A domain that never sends mail can still be spoofed. Publish a hard-deny posture: an SPF record of v=spf1 -all, a DMARC record of v=DMARC1; p=reject;, and a null MX record (0 .) to signal it accepts no mail either.
• One DKIM key forever. Keys should be rotatable. Use selectors so you can roll to a new key without an outage, and retire weak (short) keys.

How do I check my own domain?

You can inspect the raw records yourself with dig:

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

But reading the records is only half the job — the real question is whether SPF, DKIM and DMARC align on the visible From domain, whether your SPF is inside the lookup limit, and whether your DMARC policy is actually enforcing. The SecScan Email/DMARC checker runs those checks for you and flags exactly where a spoofer could slip through. Once your email is locked down, close the rest of your external attack surface with our security headers guide and the broader website security guide.