SPF, DKIM and DMARC explained, with record examples

The short version

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.

SPF: who is allowed to 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.

DKIM: proving the 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.

DMARC: what to do when checks fail, and who to tell

RFC 7489 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.

Putting it together: a rollout order that won’t break your mail

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.

Checking 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.