SPF, DKIM, and DMARC for solo founders.

You've bought a domain, wired up transactional email, and sent your first marketing blast. A day later, half of it has landed in spam. The subject line was fine. The sender name was fine. The list was warm. What wasn't fine is that your mail was probably failing one — often all three — of the domain-level authentication checks that recipient mail servers run before deciding where a letter lands.

This piece is the plain-English version of SPF, DKIM, and DMARC. It assumes you are technical enough to edit a DNS record but don't want to read three RFCs to know what you're editing. Each section ends with the TL;DR that will unblock you today.

§ Why any of this exists.

The core email protocol (SMTP, circa 1982) has no concept of sender identity verification. Anyone can open a connection to a mail server and claim to be sending from ceo@your-company.com. This was fine for fifteen years, until spam and phishing made it catastrophically not fine.

SPF, DKIM, and DMARC are three layers of retrofit that together give a recipient mail server a way to answer: “is this letter actually from the domain it claims to be from?” Each covers a slightly different angle. Together, they're the difference between your mail arriving and your mail sitting in quarantine.

§ SPF, in one sentence.

SPF (Sender Policy Framework) is a DNS TXT record that lists which servers are allowed to send mail from your domain. When a recipient mail server receives a letter claiming to be from you@yourdomain.com, it looks up your domain's SPF record, sees what IP addresses are authorised, and checks whether the connecting server's IP is on that list.

A typical SPF record looks like this:

Type

TXT

Host

@ (the domain root)

Value

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

The include: entries delegate authorisation to other providers — Amazon SES in the example, Google Workspace in the second. The ~all at the end is a soft-fail: treat mail from other servers as suspicious but deliverable. -all (hard-fail) tells recipients to reject unauthorised sending outright.

SPF answers: did this server have permission to send from my domain?

The common trap is the ten-lookup limit. SPF only allows ten DNS lookups per evaluation, and each include: can chain into more. If you use Mailgun, Postmark, Mailchimp, and Workspace all at once, you can silently break your own SPF by exceeding that limit. If you see SPF failures despite a correct-looking record, this is usually why.

§ DKIM, in one sentence.

DKIM (DomainKeys Identified Mail) is a cryptographic signature, generated by the sending server, that the recipient can verify against a public key you publish in DNS. It proves two things: (1) the letter wasn't modified in transit, and (2) a server in possession of your domain's private key did the signing.

Every DKIM-signed outbound includes a header that looks roughly like this:

Header

DKIM-Signature

Selector

default or a vendor-assigned tag like amazonses

Signing domain

your domain

Value

a base64 signature over a canonicalised version of the letter body + headers

The recipient mail server fetches {selector}._domainkey.{your-domain} from DNS, finds the public key you published there, and verifies the signature. If it matches, the letter is cryptographically attested. If it doesn't, something tampered with the body in transit — or the sender was lying.

DKIM per domain matters for portfolio operators. If you have three businesses and all three sign with one shared key (or worse, the carrier's default key), a reputation hit on one domain bleeds onto the others. Per-domain DKIM is the reputation-isolation mechanism; sharing keys is the reputation-coupling anti-pattern.

§ DMARC, in one sentence.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS TXT record that tells the recipient what to do when SPF and/or DKIM fail — and asks them to send you reports about it.

A typical DMARC record:

Type

TXT

Host

_dmarc

Value

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s

The p= directive is the policy. Three values, in order of strictness:

• ·p=none — don't act, just send me reports. Useful for the first two weeks while you're making sure your legitimate senders aren't failing the checks.
• ·p=quarantine — send failing mail to the spam folder. The reasonable default once you're sure your setup is clean.
• ·p=reject — reject failing mail at the protocol level. The strictest setting; use only when you're certain every legitimate sender is authenticated.

The rua= field is where DMARC aggregate reports are sent — daily XML files from major mail providers telling you exactly which servers sent mail claiming to be your domain, and whether they passed. This is where you discover that your accountant's bookkeeping tool has been sending mail from yourdomain.com for two years and you didn't know.

SPF and DKIM are the authentication. DMARC is the policy. The first two tell a recipient whether the letter is legitimate; DMARC tells it what to do about the answer.

§ The alignment trap.

There's a subtle thing that catches everyone: alignment. SPF and DKIM can both technically pass — the letter came from an authorised server, the signature verifies — but DMARC still fails because the domains don't align.

The MAIL FROM address (envelope sender, what SPF checks) and the From: header (what your recipient sees) can be different. A marketing tool might send from bounces.mailgun.net at the envelope but hello@yourdomain.com in the header. SPF passes for Mailgun's domain, but DMARC requires that the SPF-authenticated domain align with the visible From — and mailgun.net ≠ yourdomain.com, so DMARC fails.

The fix is usually vendor configuration: most reputable ESPs let you configure a custom return-path domain like bounces.yourdomain.com that CNAME-points at their infrastructure. This keeps SPF working and aligns the domains, so DMARC is happy.

§ The field kit, in order.

If you're setting up a new domain today, here's the order of operations that works in practice:

1. 01Publish SPF first. Include every authorised sender. Start with ~all (soft-fail) while you're verifying the list.
2. 02Set up DKIM for each sending service. Most providers generate the DNS record for you; paste it into your zone.
3. 03Publish DMARC with p=none. Set rua= to an address you check. Wait a week or two for reports.
4. 04Read the reports. Identify any legitimate senders that are failing. Fix them (usually alignment or a missing DKIM key).
5. 05Tighten to p=quarantine. Monitor for another two weeks.
6. 06Tighten to p=reject only when you're confident. Not all domains need this; p=quarantine is a fine long-term resting state.

§ A note on the Folio handoff.

Every domain you bind to Folio goes through the same four-record setup: MX (inbound routing), SPF (authorises Amazon SES), DKIM (per-domain RSA-2048 key we generate), and DMARC (p=quarantine with reports routed to dmarc@emcognito.com). The wizard shows each customer-owned record as a copy-paste card and waits for them to resolve before flipping the domain to verified. Any external DMARC reporting authorization under _report._dmarc.emcognito.com is handled by Folio, not by your registrar.

The one-line version: if you don't want to read the rest of this essay again, use a provider that does all four for you, per-domain, with per-domain DKIM. Your deliverability will be fine. If you're running your own outbound, you'll be back here eventually.