Email Authentication Explained: SPF, DKIM & DMARC

Email authentication is the set of DNS-published protocols — SPF, DKIM, and DMARC — that let a receiving mail server confirm a message genuinely came from the domain it claims. This is the protocol reference: how each one works, the exact DNS records you publish, and how DMARC ties the first two together through alignment. By the end you will know what every mechanism in an SPF record means, how a DKIM signature is verified, and how to roll out a DMARC policy without blocking your own mail.

Why email authentication exists

SMTP, the protocol that moves mail across the internet, was designed in an era of mutual trust. It lets any server claim to be sending on behalf of any domain — there is nothing in the base protocol that stops a spammer from putting billing@yourbank.com in the From: header. That gap is what enables spoofing and the phishing attacks built on top of it: fraudulent invoices, fake password resets, and business-email-compromise scams that impersonate executives.

Email authentication closes the gap by giving receivers a verifiable way to ask "did this message really originate from a source the domain owner authorized?" The pressure to adopt it stopped being optional in 2024. Google and Yahoo introduced a bulk-sender mandate requiring high-volume senders to publish SPF, DKIM, and at minimum a p=none DMARC record, keep spam complaint rates low, and support one-click unsubscribe. Mail that fails these checks is increasingly throttled, foldered to spam, or rejected outright. Authentication is now a precondition for reliable inbox placement, not a nice-to-have.

Authentication does not, by itself, verify that a recipient address is real — that is the job of SMTP validation and list hygiene. The two work in tandem: authentication proves you are who you say you are; verification proves the address you are mailing actually exists.

SPF: who is allowed to send

Sender Policy Framework (defined in RFC 7208) is the simplest of the three. You publish a single TXT record on your domain listing the servers permitted to send mail using your domain in the MAIL FROM (the SMTP envelope sender, also called the Return-Path). When a receiving server gets a message, it looks up the envelope sender's domain, reads the SPF record, and checks whether the connecting IP is authorized.

A typical SPF record looks like this:

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

Reading it left to right:

• v=spf1 — the version tag; every SPF record must start with it.
• ip4:198.51.100.10 — an explicit authorized IPv4 address (ip6: exists for IPv6).
• include:_spf.google.com — pull in another domain's SPF record. This is how you authorize providers like Google Workspace or a marketing platform without listing their IPs by hand.
• ~all — the catch-all mechanism that matches everything else. The qualifier in front decides the verdict.

The qualifier on all is where hard fail versus soft fail lives:

• -all (hard fail) — anything not explicitly listed is unauthorized. Receivers are told to reject it.
• ~all (soft fail) — unlisted senders are suspicious but should be accepted and marked. Most teams start here while building confidence.
• ?all (neutral) — no assertion either way; offers little protection.

SPF carries one notorious constraint: the 10-DNS-lookup limit. Every include, a, mx, ptr, and exists mechanism triggers a DNS query during evaluation, and the spec caps the total at ten. Exceed it and the record returns a permerror, which most receivers treat as an SPF failure. Teams that add several SaaS senders blow past this limit quickly, so flattening records and removing unused includes is routine maintenance. SPF also breaks on forwarding: when a mailing list or forwarder relays your message, the connecting IP changes and SPF no longer matches — which is precisely why DKIM and DMARC exist.

DKIM: a cryptographic signature

DomainKeys Identified Mail (RFC 6376) does what SPF cannot: it proves the message content and key headers were not tampered with in transit, and it survives forwarding. DKIM uses public-key cryptography. You generate a key pair; the private key stays on your sending server, and the public key is published in DNS.

When you send, the mail server hashes selected headers (typically From, To, Subject, Date) and the body, then signs that hash with the private key. The signature is attached as a DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=mail2024;
  h=from:to:subject:date;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
   VoG4ZHRNiYzR...

The two tags that matter most are d= (the signing domain) and s= (the selector). The selector lets a domain publish multiple keys at once. The receiver combines them to find the public key in DNS at selector._domainkey.domain:

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

The receiver fetches that public key, recomputes the hash from the received message, and verifies it against the signature. If they match, DKIM passes — proving the signing domain authorized the message and the signed parts arrived intact. Because the signature travels inside the message, DKIM keeps passing even after a forwarder relays it, as long as the signed content is not altered.

Key rotation is operational hygiene. Keys should be replaced periodically — quarterly is a common cadence — and immediately if you suspect compromise. The selector makes this painless: publish a new key under a fresh selector (mail2025), switch the signer to it, and once no in-flight mail references the old selector, remove it. Aim for at least a 2048-bit RSA key; 1024-bit keys are considered weak.

DMARC: alignment and policy

SPF and DKIM each authenticate a domain, but neither one checks the domain a human actually sees — the From: header. A spammer could pass SPF for their own throwaway domain while displaying From: ceo@yourbrand.com. DMARC (RFC 7489) closes that loophole with alignment: it requires that an authenticated identifier match the From: domain.

• SPF alignment — the MAIL FROM domain that SPF validated must match the From: domain.
• DKIM alignment — the d= domain in a passing signature must match the From: domain.

Alignment can be relaxed (subdomains count, e.g. mail.example.com aligns with example.com) or strict (exact match only). You publish a DMARC policy as a TXT record at the _dmarc subdomain:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100; adkim=r; aspf=r"

The key tags:

• p= — the policy receivers apply to failing mail: none (take no action, just report), quarantine (deliver to spam/junk), or reject (refuse outright).
• rua= — where to send aggregate reports: daily XML summaries of how much of your mail passed and failed, broken down by source IP. This is the data you tune the rollout on.
• ruf= — where to send forensic (failure) reports: per-message detail on individual failures. Many providers no longer send these for privacy reasons, so do not rely on them.
• pct= — the percentage of failing mail the policy applies to. pct=25 lets you ramp quarantine or reject onto a fraction of traffic first.
• adkim= / aspf= — alignment mode (r relaxed, s strict).

Aggregate reports are the heart of DMARC. They reveal every system sending mail under your domain — including shadow IT and forgotten third-party tools — long before you tighten the policy. Monitoring them is closely related to sender reputation monitoring; both depend on watching what receivers report back about your traffic.

How the three protocols work together

The mental model that trips people up is assuming all three must pass. They do not. DMARC uses a logical OR: a message passes DMARC when either SPF passes and aligns or DKIM passes and aligns. One aligned pass is enough.

That OR is what makes the stack resilient. When a mailing list forwards your message, SPF breaks because the connecting IP changes — but the DKIM signature travels with the message and still validates, so DMARC passes on the strength of DKIM alone. Conversely, a message relayed through a system that strips DKIM may still pass on aligned SPF. Publishing both gives every message two independent chances to authenticate.

A safe deployment path

The danger in DMARC is enforcing reject before you understand all your legitimate senders — you can blackhole your own invoices, ticketing system, or newsletter. The standard rollout is deliberately incremental:

1. Publish SPF and DKIM first. Get both passing and aligned for every legitimate source before touching DMARC.
2. Start at p=none. This changes nothing about delivery but turns on aggregate reporting. Let it run for two to four weeks.
3. Read the aggregate reports. Identify every IP sending under your domain. Fix or authorize the legitimate ones; the failures left over are spoofers.
4. Move to p=quarantine, optionally with pct. Begin with something like pct=25 and watch the reports, then ramp to 100%.
5. Move to p=reject. Once quarantine shows only spoofed mail failing, enforce full rejection. This is the configuration Gmail and Yahoo reward most.

Throughout, treat list quality as part of the same discipline. Authenticated mail to dead or risky addresses still hurts your reputation and complaint rate. Running your list through a bulk email cleaner before a big send removes the invalid and disposable addresses that drive bounces, and a single-email validator or the REST API catches bad signups at the point of entry. For the full operational checklist on staying out of spam folders, see our guide to avoiding spam filters — this article is the protocol reference; that one is the practical playbook.

BIMI: the visible payoff

Once you reach an enforced DMARC policy (quarantine or reject), you unlock BIMI — Brand Indicators for Message Identification. BIMI lets your verified brand logo appear next to your messages in supporting inboxes, published as yet another TXT record at default._bimi.yourdomain.com pointing to an SVG logo. Many providers also require a Verified Mark Certificate (VMC) proving you own the trademark. BIMI is not an authentication protocol in its own right; it is the reward for having SPF, DKIM, and an enforced DMARC policy in place. It both lifts brand recognition in the inbox and gives recipients a visual cue that the message is genuinely from you.

Frequently asked questions

What is DMARC, in one sentence?

DMARC is a DNS-published policy that builds on SPF and DKIM by requiring an authenticated identifier to align with the visible From: domain, and it tells receiving servers whether to monitor, quarantine, or reject mail that fails — closing the spoofing gap those two protocols leave open on their own.

Do I need all three protocols, or is one enough?

Publish all three. SPF and DKIM are the underlying checks; DMARC is meaningless without at least one of them, and a message only passes DMARC when SPF or DKIM passes and aligns. Having both SPF and DKIM gives each message two independent chances to authenticate, which matters because SPF breaks on forwarding while DKIM survives it. The 2024 Gmail and Yahoo bulk-sender rules require all three.

Why is my mail failing DMARC even though SPF passes?

Almost always an alignment problem. SPF can pass for your envelope sender (Return-Path) while that domain differs from the From: header domain — common when a third-party platform sends "on behalf of" you using its own bounce domain. Either align the envelope domain to your From: domain, or make sure the platform applies an aligned DKIM signature with your domain in the d= tag.

Does email authentication verify that an address is real?

No. SPF, DKIM, and DMARC authenticate the sending domain; they say nothing about whether the recipient mailbox exists. That requires verification — MX and DNS checks plus an SMTP probe — which is what KaijuVerifier's REST API and bulk cleaner provide. Authentication and verification are complementary layers, and you want both. See pricing, which includes a free tier to start.