SPF, DKIM, DMARC explained for founders

Email has a design flaw that would never survive a modern security review: the protocol lets any server claim to be sending on behalf of any domain. Nothing in SMTP itself stops a random machine in a random data center from sending mail that says it's from your company. SPF, DKIM, and DMARC are the three retrofitted standards that patch this hole — and since 2024, the major mailbox providers effectively require all three from anyone doing outreach at scale.

You don't need to become a DNS expert to run outbound. You need a working mental model of what each record proves, because when deliverability breaks, these three are where you look first. Here is that model, minus the RFC language.

SPF: the guest list

Think of SPF as the guest list at the door. Your domain publishes a TXT record naming every server allowed to send mail for it. When a receiver gets a message from your domain, it checks whether the server that delivered it is on the list. On the list: pass. Not on the list: fail, and the receiver treats the message with suspicion or rejects it outright.

v=spf1 include:_spf.google.com include:amazonses.com ~all

Reading it left to right: v=spf1 declares the record type; each include: pulls in a provider's published list of sending servers; and ~all says "treat anything else as suspicious" (a softfail — the usual choice while you're confirming everything works, versus the stricter -all). Three rules keep SPF healthy: exactly one SPF record per domain (two records means both fail), no more than 10 DNS lookups across all your includes, and prune providers you stopped using — every stale include is both a lookup spent and an open door.

DKIM: the wax seal

SPF checks the messenger; DKIM checks the message. Your sending provider holds a private key and signs selected headers and the body of every outgoing email. The matching public key sits in your DNS at an address like s1._domainkey.yourdomain.com. Receivers recompute the signature: if it verifies, the message provably came from a server holding your key and wasn't modified in transit — like an unbroken wax seal on a letter.

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...

The practical points: the p= value is a public key your provider generates — you never write it by hand, you paste it. The s1 part is a selector, which lets multiple providers each have their own key on the same domain without collisions. And DKIM survives forwarding where SPF often breaks (a forwarded message arrives from the forwarder's server, not yours), which is why receivers treat a valid DKIM signature as the stronger of the two signals.

DMARC: the policy and the paper trail

SPF and DKIM each verify something, but neither one, alone, checks the thing the human recipient actually sees: the From address. A message can pass SPF for mailer.somebulkservice.com while displaying ceo@yourbank.com in the From header. DMARC closes that gap with a rule called alignment: at least one of SPF or DKIM must pass *and* the domain it verified must match the From domain.

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100

The p= value tells receivers what to do with mail that fails alignment, and it has exactly three settings:

The rua= address receives aggregate reports — XML summaries from receivers showing every server sending as your domain and whether it passed. This is the paper trail: it's how you discover the forgotten marketing tool still sending as you, or a spammer spoofing your name. Start at p=none, read the reports, fix what's failing, then tighten.

How the three work as a system

A useful way to hold it all: SPF authorizes the server, DKIM authenticates the message, DMARC aligns both with the From address and sets the consequences. A receiver evaluating your email runs all three checks in parallel and combines them with your sending reputation to pick a folder. Passing all three doesn't guarantee the inbox — reputation and engagement still decide that — but failing any of them near-guarantees spam, and failing DMARC alignment at a strict policy means outright rejection.

Setting up a new sending domain, in order

1. Create the mailboxes at your provider first — DKIM keys come from the provider, so it must exist before the DNS does.
2. Publish SPF with only that provider's include.
3. Enable DKIM in the provider's admin panel and publish the selector record it gives you.
4. Publish DMARC at p=none with a rua= reporting address you actually read.
5. Verify all three resolve correctly before sending anything — propagation usually takes minutes but can take hours, depending on your registrar's TTL.
6. After two clean weeks of reports, move DMARC to p=quarantine.

If you'd rather not work out which records you need, SendCanyon does that part: add a domain and the app lists the SPF, DKIM, and DMARC records to publish as copy-paste rows for your registrar, then runs live DNS verification against them. The signing key stays where it belongs — with the provider your mailboxes send through — and campaigns stay locked until all three records check out, because sending unauthenticated mail helps no one.

Three TXT records, maybe twenty minutes at your registrar. That's the entire admission price for playing cold email in 2026 — and the majority of failed outbound programs never paid it.