SPF, DKIM & DMARC Setup: The Plain-English Guide (2026)

A working SPF, DKIM, and DMARC setup is the entry ticket to the inbox in 2026. All three are DNS TXT records on your sending domain, and each answers a different question.

SPF is the guest list: which mail servers are allowed to send email on behalf of your domain. DKIM is the tamper-proof wax seal: a cryptographic signature proving the message really came from you and was not altered in transit. DMARC is the instruction card for the bouncer: what receivers should do with mail that fails the first two checks — and where to send you reports about it.

Why bother? Because Google’s sender guidelines require SPF or DKIM from every sender, and require SPF and DKIM and a DMARC policy from bulk senders — Yahoo’s requirements mirror them. This guide is the setup deep-dive under our broader deliverability and compliance guide; when you are done, check your work in thirty seconds with our free email deliverability checker.

SPF (Sender Policy Framework) is a single TXT record on your domain listing every service authorized to send email as you. When a receiving server gets a message claiming to be from yourdomain.com, it looks up that record and checks whether the connecting server is on the list.

yourdomain.com   TXT   "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 list of sending servers (your email provider, your sending platform — Resend, for example, gives you the exact include during domain verification). The tail qualifier says what to do with everyone else: ~all (softfail — mark suspicious) is the common choice; -all (hardfail — reject) is stricter.

Two rules cause most SPF breakage. First, one SPF record per domain — if you add a second v=spf1 TXT record instead of merging includes into the existing one, SPF returns a permanent error and effectively fails for everyone. Second, RFC 7208 caps SPF at 10 DNS lookups per check; every include, a, mx, and redirect costs lookups, and a record that exceeds the limit fails with a permerror even though it looks fine to the eye.

DKIM (DomainKeys Identified Mail) has your sending server sign each outgoing message with a private key. The matching public key is published in your DNS under a named selector, so any receiver can verify the signature — proving the mail came from a server holding your key and that the signed content was not modified in transit (RFC 6376).

resend._domainkey.yourdomain.com   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

# "resend" is the selector — your provider picks the name and gives
# you the exact record (sometimes as a CNAME) during domain setup.

In practice you never generate DKIM keys yourself: your email provider or sending platform generates the pair, keeps the private key, and hands you the public-key DNS record to paste. Two details worth knowing: Gmail requires a DKIM key of at least 1024 bits for mail to personal accounts (2048 is the common default now, per Google’s guidelines), and a message can carry several DKIM signatures — your platform’s plus your own domain’s — which is normal and fine.

Unlike SPF, DKIM survives forwarding: the signature travels inside the message, so a forwarded email still verifies. That is exactly why DMARC lets a message pass on either SPF or DKIM.

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of the other two and adds the piece they are both missing: it checks that the domain in the visible From: header — the one humans see — matches the domain that SPF or DKIM actually validated. That match is called alignment, and it is what stops a spammer from passing SPF for their own throwaway domain while displaying yours (RFC 7489, dmarc.org).

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"

# p=       policy for failing mail: none | quarantine | reject
# rua=     where aggregate reports are emailed (daily XML summaries)
# sp=      optional separate policy for subdomains
# pct=     optional percentage of failing mail the policy applies to

The p= tag is the decision: p=none means monitor only — nothing is blocked, but you receive reports; p=quarantine asks receivers to junk-folder failing mail; p=reject asks them to refuse it outright. The rua= address receives aggregate reports: daily XML summaries from Gmail, Yahoo, and others showing which servers sent as your domain and whether they passed. Raw XML is unreadable — run it through any free DMARC report viewer.

Publishing p=reject on day one is how companies break their own invoices, calendar invites, and newsletter — any legitimate service you forgot about starts getting refused. The safe path is staged:

During the p=none phase, expect surprises: the helpdesk tool sending from your domain, an old marketing platform nobody turned off, a regional office with its own SMTP relay. Every one of them either needs to be authorized (SPF include + DKIM enabled) or retired. That inventory is the real work of DMARC — the record itself takes five minutes.

For a dedicated cold-outreach domain the calculus is simpler: only one platform sends from it, so there is little to inventory and you can usually reach p=quarantine within a few weeks. Our deliverability guide covers why outreach should live on its own domain in the first place, and our infrastructure guide covers the domain setup around it.

To check all three records — plus MX and the blocklist basics — in one pass, run your domain through our free email deliverability checker. It reads your live DNS the same way a receiving server does, entirely in your browser.

Next: the volume rules these records unlock — Google and Yahoo’s sender requirements — and the domain architecture to put them on.