SPF, DKIM and DMARC explained, with record examples

Key takeaways

• SPF, DKIM and DMARC are three DNS TXT records, each defined in its own RFC, that together make it hard to send mail in your domain’s name.
• SPF checks where a message came from, DKIM checks whether it was changed, and DMARC checks that either result matches the visible From domain and says what to do if not.
• DMARC is also a reporting channel: the rua reports show every source sending as your domain, including ones you forgot.
• Roll out in order — SPF, DKIM, DMARC at p=none, then tighten — so legitimate mail isn’t blocked on the way.

What do SPF, DKIM and DMARC each do?

These three DNS-published records work together to stop someone from sending email that claims to be from your domain:

• SPF — a list of servers allowed to send mail for your domain.
• DKIM — a cryptographic signature proving a message came from your domain and wasn’t altered in transit.
• DMARC — a policy telling receivers what to do when a message fails SPF and DKIM, and where to send reports about it.

Each is published as a DNS TXT record, each is defined in its own RFC, and each only helps if the other pieces around it are set up too — SPF without DMARC, for example, doesn’t stop anyone from spoofing your domain; it just gives receivers a signal they may or may not act on. Together they’ve largely superseded older anti-spam techniques like greylisting, which only delayed an unfamiliar sender rather than verifying who it actually was.

How does SPF decide who may send as you?

RFC 7208 defines SPF as a TXT record published at your domain’s root that lists the mail servers and services authorized to send mail claiming to be from that domain. A receiving mail server checks the connecting server’s IP against this list.

example.com.  TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.10 -all"

Reading this record left to right: v=spf1 marks it as an SPF record, include:_spf.google.com authorizes Google Workspace’s sending servers, ip4:203.0.113.10 authorizes one specific server by IP, and -all (“hard fail”) says any other source should be treated as unauthorized. A softer ~all (“soft fail”) asks receivers to flag unauthorized senders as suspicious rather than reject them outright — useful while you’re still confirming every legitimate sender is listed.

Common SPF mistakes: forgetting a sending service when you add a new one (newsletter tools, CRM, invoicing software all need their own include), and exceeding SPF’s 10-lookup limit on nested include mechanisms, which causes the entire check to fail (a PermError) regardless of whether the real sender was authorized.

Check your own SPF setup with AdminKit’s SPF check, which reads the record and flags common issues like a missing all mechanism or too many DNS lookups — see what an SPF check result means for how to read the output.

How does DKIM prove a message wasn’t altered?

RFC 6376 defines DKIM, which works differently from SPF: instead of checking where a message came from, DKIM checks whether it arrived unchanged. Your mail server signs each outgoing message with a private key; the public key needed to verify that signature is published in DNS.

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq...AQAB"

The default part of that hostname is the selector — a label your mail provider chooses so multiple keys can exist at once (for key rotation, or because you use more than one sending service, each with its own selector like google._domainkey or mandrill._domainkey). The receiving server reads the DKIM-Signature header on an incoming message to find which selector and domain to look up, fetches that TXT record, and uses the public key (p=) to verify the signature.

Because DKIM verifies the message content itself, it survives being forwarded through intermediate servers in a way SPF often doesn’t (SPF checks the connecting IP, which changes on forwarding; a valid DKIM signature usually stays valid). Check your DKIM setup, selector and key with AdminKit’s DKIM check — see how to read a DKIM check result for what each field in the output means.

What does DMARC tell receivers to do when checks fail?

RFC 7489 (also on the IETF Datatracker) defines DMARC, published at a fixed location, _dmarc.example.com, which ties SPF and DKIM together and adds two things neither has on its own: an explicit policy (what should receivers do with mail that fails?) and reporting (send me data about what’s passing and failing).

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

• p=none — take no action, just collect reports. The right starting point for any new DMARC deployment.
• p=quarantine — treat failing mail as suspicious (usually routed to spam).
• p=reject — refuse failing mail outright. The strongest setting, appropriate once you’ve confirmed every legitimate source passes.
• rua=mailto:... — where to send daily aggregate reports summarizing pass/fail volume by source, which is how you discover senders you forgot to authorize before moving to a stricter policy.
• pct=100 — apply the policy to 100% of mail that fails; lowering this during rollout applies it to only a sample, useful for a cautious, gradual move to reject.

As dmarc.org’s overview puts it, the goal is to let “senders and receivers collaborate to improve mail authentication practices” — DMARC is deliberately a feedback loop, not a one-time switch. Check your current DMARC policy and see it explained in plain terms with AdminKit’s DMARC check — see how to read a DMARC check result for the aggregate-report fields, or audit SPF and DMARC with an AI agent to run the same check from a chat prompt via AdminKit’s MCP server. Whatever a receiver decides about a given message, it typically writes the combined SPF, DKIM and DMARC verdicts into the message’s Authentication-Results header so any downstream system can read what was checked without repeating the work.

What does DMARC alignment actually compare?

SPF and DKIM each check a domain, but not necessarily the one your reader sees. SPF checks the envelope sender (the MAIL FROM or Return-Path address), which the recipient normally never sees. DKIM checks the domain in the signature’s d= tag, which can be any domain that holds the signing key. The address people see in their mail client is the From: header, and neither SPF nor DKIM looks at it on its own.

DMARC closes that gap. RFC 7489 calls it identifier alignment: a message passes DMARC only if SPF or DKIM passes and the domain it passed for matches the From: domain. By default the match is relaxed, which means the two only need to share the same organizational domain (mail.example.com aligns with example.com). Setting aspf=s or adkim=s in the DMARC record asks for an exact match instead.

Check	Domain it verifies	Where that domain comes from	Survives plain forwarding?
SPF	Envelope sender	MAIL FROM / Return-Path	Usually not — the forwarder’s IP isn’t in your SPF record
DKIM	Signing domain	d= tag in DKIM-Signature	Usually yes, if the forwarder doesn’t change the signed content
DMARC	Visible sender	From: header	Passes if at least one aligned SPF or DKIM pass survives

This is why a newsletter platform can pass SPF and DKIM for its own domain and still fail DMARC for yours: both checks passed, but for the platform’s domain, not the one in From:. The fix is to set up the platform’s custom return-path and DKIM signing for your own domain, so its passes align. DMARC alignment: relaxed vs strict goes through the two modes in detail.

In what order should you roll out SPF, DKIM and DMARC?

1. Publish SPF first, listing every service that currently sends mail for your domain. Use ~all initially rather than -all while you confirm the list is complete.
2. Enable DKIM signing in your mail provider’s settings and publish the resulting selector record. Most providers (Google Workspace, Microsoft 365, mail platforms like Mailgun or SendGrid) generate this for you — you just publish the TXT record they give you.
3. Publish DMARC at p=none with a rua address you actually monitor. Review the aggregate reports for two to four weeks.
4. Fix any legitimate source that’s failing — usually a forgotten SPF include or a sending service that isn’t DKIM-signing.
5. Move to p=quarantine, then eventually p=reject, once reports show only your legitimate mail passing.

Skipping straight to p=reject without the monitoring step is the most common way a DMARC rollout breaks legitimate mail, since any sender you forgot to authorize gets silently dropped instead of just flagged.

How do you check your own domain right now?

All three checks are free and read only public DNS — nothing is sent through your mail server, and no account is required: SPF check, DKIM check, DMARC check. If you’re also troubleshooting where mail is routing in the first place, MX lookup confirms which servers are configured to receive mail for your domain.

If mail from your domain is already landing in spam or your IP has been flagged, see our guide on why IPs get blacklisted — a missing or broken DMARC policy makes spoofed mail easier to send in your name, which can itself contribute to blacklisting.

Where can you go deeper on each record?

Each record has its own common real-world failure mode worth a dedicated page: fixing SPF “too many DNS lookups” (PermError), reading DMARC aggregate reports and rolling out to p=reject safely, and DKIM selector and record mistakes that break signing. Once DMARC is enforced, see also BIMI, MTA-STS and TLS-RPT explained for the related records that build on it. Switching mail providers entirely is a different, riskier event than any single-record fix above — see migrating email providers without breaking SPF, DKIM or DMARC for the cutover order that keeps all three records (and MX) in sync through the transition.

Forwarded mail is a separate, common failure mode: a forwarder relays mail without becoming the authorized sender, so SPF fails on the forwarded copy unless the forwarder rewrites the envelope sender via SRS or the receiving system honors an ARC chain recording the original pass. See why email forwarding breaks SPF, and how SRS and ARC fix it for the full explanation.

If you’re maintaining all three records across many sending domains and IPs as an ongoing program rather than a one-time setup, AdminKit for email deliverability teams brings these checks together with MX and reverse-DNS lookups for that recurring workflow.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.