SPF, DKIM and DMARC, explained for humans

If your legitimate email keeps landing in spam, the usual culprit isn't your subject line — it's that the receiving server can't prove the message came from you. Three DNS records do that proving, and each answers a different question. SPF lists which servers are allowed to send on behalf of your domain. DKIM puts a cryptographic signature on every message. DMARC tells receivers what to do when those checks fail, and sends you reports about it. The fastest way to see where you stand is to look up your domain's SPF, DKIM and DMARC recordsand read what's actually published — which, more often than not, is not what you think is published.

One sentence each

All three live in your domain's public DNS. Anyone can read them, including the mail server deciding your fate.

• SPF (Sender Policy Framework) is a TXT record such as v=spf1 include:_spf.google.com -all. It's an allowlist of sending servers, and the trailing mechanism says what to do about everyone else.
• DKIM (DomainKeys Identified Mail) adds a DKIM-Signature header to each outgoing message, generated with a private key only your sending server holds. The matching public key is published in DNS under a selector, like google._domainkey.example.com, as a Base64 blob — the same encoding you can pick apart with a Base64 decoder. The receiver hashes the message with SHA-256, the way any hash generator would, and checks the signature. Tamper with the message in transit and the maths stops working.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) is published at _dmarc.example.com as v=DMARC1; p=none; rua=mailto:dmarc@example.com. It sets the policy — none, quarantine or reject — and where the aggregate reports go.

Alignment: the part that trips everyone up

DMARC isn't satisfied by SPF or DKIM merely passing. It also demands alignment: the domain in the visible From header must match the domain that passed the check. For SPF, that's the Return-Path domain — not the From. For DKIM, it's the d= value inside the signature. DMARC passes if either mechanism passes and aligns.

This is why the most confusing failure looks like a contradiction: your email tool reports "SPF: pass" and DMARC fails anyway. SPF passed for the platform's own bounce domain, not yours. The fix is the custom return-path (sometimes called a custom bounce domain) that virtually every ESP offers, or DKIM signing with your own domain. In relaxed mode, the default, a subdomain like mail.example.com still aligns with example.com, so you don't need an exact string match.

What Gmail and Yahoo have required since 2024

In February 2024 Google and Yahoo rolled out matching sender requirements, and that's the bar in force today. For every sender: authenticate with SPF or DKIM, publish valid reverse DNS (PTR) for your sending IP, connect over TLS, and don't impersonate another domain in the From.

For bulk senders — Google draws the line at roughly 5,000 messages a day to Gmail addresses — the bar rises: SPF and DKIM, a published DMARC record (p=none is enough to comply), alignment on at least one mechanism, one-click unsubscribe per RFC 8058 honoured within two days, and a spam complaint rate kept under the threshold Google publishes in Postmaster Tools. Worth separating two problems while you debug: deliverability lives in DNS, attribution lives in your links, and a UTM builder keeps the second one from muddying the first.

The failures that keep recurring

• Two SPF records. A new vendor gets onboarded and someone adds a second v=spf1 TXT record instead of merging. Receivers return permerror and SPF fails for everything.
• Ending in +all. That authorises the entire internet to send as your domain — strictly worse than having no SPF at all. Use -all, or ~allwhile you're still rolling out.
• Blowing the 10-lookup limit. SPF evaluation is capped at ten DNS lookups, and every nested include: counts. Stack up five vendors over three years and you quietly cross the line into permerror. Prune includes for services you no longer use, and flatten what you can.
• Permanent p=none. Publishing DMARC in monitoring mode and never touching it again is a smoke alarm with the battery out. You get reports nobody reads while anyone can still spoof your domain.
• DMARC without rua. No reporting address means no visibility into who sends as you — which is exactly the information you need before tightening the policy.

Check your own domain in two minutes

Open the SPF, DKIM and DMARC checker, type your domain, and read four things. First, the TXT record starting with v=spf1: confirm there is exactly one and that it doesn't end in +all. Second, _dmarc: does it exist, and what policy does it declare? Third, DKIM: enter your selector — the tool ships the common presets, google, default, k1 — and confirm a public key comes back. Fourth, your MX records, to be sure inbound mail points where you think it does.

One quirk to expect: DKIM can't be discovered. There is no DNS query that enumerates a domain's selectors, so if none of the presets return anything, pull yours from the s= field of a DKIM-Signatureheader in a message you've already sent. The lookups run from your browser against a public DNS-over-HTTPS resolver — nothing passes through a Docuboxer server, and nothing is stored.

A sane DMARC rollout

Publish p=none with a rua address and let two to four weeks of reports accumulate. Sources you'd forgotten will surface: the billing system, the CRM, the website contact form, the e-signature tool. Fix alignment for each one, move to p=quarantine with pct=25, ramp to 100, and only then go to p=reject. Jumping straight to reject with unidentified sources is the quickest way to stop your own invoices from being delivered.

The honest caveat: authentication is not deliverability

SPF, DKIM and DMARC answer exactly one question — did this message come from where it claims? They say nothing about whether it's wanted. An attacker can register a lookalike domain, authenticate it flawlessly, and send phishing that passes all three checks in green. That's the same mechanic behind malicious QR codes, which today arrive mostly by email precisely because the image sails past text filters.

It cuts the other way too. Perfect records and you can still land in spam: purchased lists, addresses that no longer exist, recipients hitting the spam button, a sudden volume spike from a cold IP. The records are the ticket to the gate; the seat is decided by how you behave as a sender over months. Fix DNS first because it's cheap and binary — then accept that the rest is reputation, and reputation is earned slowly.

Frequently asked questions

Related tools

• SPF, DKIM and DMARC checker — Any domain's mail records, explained in plain English.
• Base64 encode/decode — The encoding your DKIM public key is published in.
• Hash generator — SHA-256 and friends, the arithmetic under a DKIM signature.
• UTM builder — Track email campaigns without mangling your links.

You might also like: free SEO tools that don't ask you to sign up.