If you only remember one sentence: SPF says which servers may send, DKIM proves the message wasn’t forged, and DMARC checks that at least one of them aligns with your visible From: domain and then enforces a policy. All three live in DNS as TXT records, all three are free, and all three are checkable in about a minute. This guide walks through what each does, how to publish it correctly, the alignment rules that decide whether DMARC passes, and how to roll out enforcement without blackholing your own mail.

SPF — authorise your sending IPs

SPF (Sender Policy Framework, RFC 7208) is a single TXT record on your domain listing the servers permitted to send mail on its behalf. A receiver checks the sending IP against that list and records a pass or fail. A typical record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Each mechanism authorises a source: include: pulls in a provider’s IPs, ip4:/ip6: list your own, and the final all sets the default — ~all (soft fail) or -all (hard fail). Two rules trip people up constantly:

One SPF record only. Publishing two v=spf1 records is a permerror and voids SPF entirely. Merge every sender into a single record.
The 10-DNS-lookup limit. Every include, a, mx and redirect costs a lookup, and the total must stay at or below ten or SPF returns permerror. Stack up a few marketing platforms and you blow the budget silently.

SPF’s big weakness: it authenticates the envelope sender (the Return-Path), not the visible From, and it breaks on forwarding — when a mailing list or a “forward to my other account” rule relays your message, the new hop’s IP isn’t in your record and SPF fails. That’s exactly why DKIM and DMARC exist. Build a clean record with the SPF Generator and confirm it resolves and stays under ten lookups with the SPF Checker.

DKIM — sign the message itself

DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to every message. You publish a public key in DNS at a named selector; your mail server signs outgoing messages with the matching private key, and receivers verify the signature against the published key. The DNS record lives at selector._domainkey.yourdomain.com and looks like:

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

Because the signature travels inside the message and covers the body and key headers, DKIM survives forwarding where SPF doesn’t — the signature is still valid on the second hop. Two practical notes: use a 2048-bit key (1024 is weak and increasingly distrusted), and rotate selectors periodically rather than reusing one key forever. Most providers hand you the exact record to paste; if you’re self-hosting, generate a keypair with the DKIM Key Generator and, once it’s live, confirm the published key matches what you’re signing with using the DKIM Checker.

DMARC — alignment and policy

DMARC (RFC 7489) is the record that makes SPF and DKIM mean something to the human reading the From line. It does two jobs. First, it requires alignment: SPF or DKIM must pass and the domain that passed must match the visible From: domain. Second, it publishes a policy telling receivers what to do with mail that fails — and where to send aggregate reports. The record sits at _dmarc.yourdomain.com:

_dmarc.example.com  TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

The tags that matter:

p= — the policy: none (monitor only), quarantine (spam-folder failures) or reject (bounce them).
rua= — the mailbox that receives daily aggregate XML reports. Without this you’re flying blind.
adkim= / aspf= — alignment mode, r (relaxed, allows subdomains) or s (strict, exact match). Relaxed is the sane default.

Alignment is the concept that trips up nearly everyone. Passing SPF or DKIM is not enough — the passing domain has to line up with your From. Generate a correct record with the DMARC Generator and validate it with the DMARC Checker.

How alignment actually decides a pass

Here is the scenario behind the most confused support tickets. You send through a marketing platform. SPF passes — but for the platform’s bounce domain. DKIM passes — but signed by the platform’s domain. Both green, yet DMARC fails, because neither passing domain matches the From: your subscribers see. DMARC needs alignment on at least one:

SPF alignment — the Return-Path domain matches (or is a subdomain of) the From domain. Fix it by setting a custom Return-Path, usually a CNAME your provider supplies.
DKIM alignment — the d= domain in the signature matches the From domain. Fix it by configuring the platform to DKIM-sign as your domain, again via a DNS record they give you.

You only need one of the two to align for DMARC to pass, so aligned DKIM is the more robust target since it also survives forwarding. To see what your real mail does end-to-end — the actual SPF/DKIM/DMARC result and whether they align — send a live message through the Email Deliverability Test.

Rolling out enforcement: none → quarantine → reject

Never jump straight to p=reject — you’ll blackhole legitimate mail from a sender you forgot about. Stage it:

Start at p=none. This changes nothing about delivery; it just turns on reporting. Collect aggregate reports for two to four weeks and inventory every service sending as your domain.
Fix alignment for each legitimate source until the reports show them all passing DMARC. This is the real work, and where DMARC monitoring pays for itself — the XML reports are unreadable by hand at any volume.
Move to p=quarantine, optionally with pct=25 to apply it to a fraction first. Watch for anything unexpectedly landing in spam.
Graduate to p=reject once quarantine is quiet. This is the policy Gmail, Yahoo and Microsoft reward, and the prerequisite for a BIMI logo.

Troubleshooting the common failures

SPF permerror. Either two SPF records exist, or you’ve exceeded ten DNS lookups. Consolidate to one record and flatten or drop unused includes.
DKIM fails after “it was working.” Usually a rotated key that wasn’t re-published, a truncated p= value (long keys split across TXT strings), or signing with a selector that isn’t in DNS.
SPF and DKIM pass but DMARC fails. Almost always alignment — the passing domain doesn’t match From. Fix Return-Path or DKIM d= as above.
Gmail 5.7.26 / Outlook 550 5.7.515. The provider is enforcing bulk-sender auth and your mail isn’t aligned. See why newsletters fail and the bulk sender requirements.
Everything passes but you’re still in spam. Authentication is necessary, not sufficient — check list hygiene, complaint rate and reputation. Start with repairing sender reputation and verify your list with the Email Verifier so you’re not mailing dead addresses.

Verify all three at once

When the records are live, run the Email Health Check to confirm SPF, DKIM and DMARC together, then keep DMARC monitoring running so a broken sender surfaces in a report rather than in a wave of bounces. The authoritative references are the RFCs linked above and each mailbox provider’s own guidance — Google’s sender guidelines and Yahoo’s best practices. To watch real-world results over time, enrol your domain in Google Postmaster Tools.

SPF, DKIM & DMARC: the complete setup guide