Why This Suddenly Matters
SPF, DKIM and DMARC have existed for years, but they went from "nice to have" to "required" in February 2024, when Google and Yahoo both began enforcing authentication requirements for anyone sending meaningful volume to Gmail and Yahoo inboxes. Google's own email sender guidelines require any domain sending 5,000+ messages a day to personal Gmail addresses to have valid SPF and DKIM, plus a DMARC record at a minimum of p=none, with the sending domain aligned to one of them. Yahoo enforces an equivalent set of rules. Miss any of the three and, depending on volume, your mail either lands in spam or gets rejected outright at the server level — it doesn't even make it to the junk folder.
This isn't limited to cold-email blasts or huge senders. If you run any regular newsletter, welcome sequence, or transactional email (receipts, password resets, notifications) through your own domain, these three records are now the baseline, not an advanced setting.
What Each Record Actually Does
SPF (Sender Policy Framework) is a DNS TXT record listing which mail servers are allowed to send email claiming to be from your domain. A receiving server checks the sending server's IP against this list; if it's not there, that's a red flag. SPF alone is easy to spoof around, though, which is why it's paired with the next two.
DKIM (DomainKeys Identified Mail) attaches a digital signature to each outgoing message, generated with a private key your mail server holds. The receiving server looks up the matching public key — published as a DNS TXT record at a specific "selector" address — and verifies the message wasn't altered in transit. Unlike SPF, DKIM travels with the message itself, so it survives being forwarded.
DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top of both. It tells receiving servers what to do when a message fails SPF or DKIM alignment (do nothing, quarantine it, or reject it outright) and, critically, gives you reporting — an email address that receives daily summaries of every server sending mail claiming to be from your domain, legitimate or not. The dmarc.org overview is the clearest primary-source explanation of how the three fit together, and Cloudflare's SPF, DKIM and DMARC explainer is a good plain-language companion.
Reading Your Results
The tester scores each record good, needs-attention, or missing:
- SPF ending in
-allor~all: good — hard fail and soft fail are both acceptable; hard fail is stricter. - SPF ending in
+all: critical — this authorizes literally any server to send as you, which defeats the point of having SPF at all. - DMARC at
p=rejectorp=quarantine: good — failing mail is blocked or sent to spam. - DMARC at
p=none: meets the bare Google/Yahoo minimum but only monitors — nothing is actually blocked. Treat this as a waypoint, not a destination. - DKIM not found at common selectors: a genuine ambiguous case. Many providers use custom or rotating selectors the tester can't guess. Check a real sent email's headers for the exact selector before concluding DKIM isn't set up.
Fixing the Most Common Failures
No SPF record: add a TXT record at your root domain listing every service that sends mail on your behalf — your website's contact form, your ESP, your helpdesk, your CRM. A typical record looks like v=spf1 include:_spf.google.com include:sendgrid.net ~all. Missing an include is the single most common cause of a "shouldn't have failed" SPF failure.
No DMARC record: start conservative. Publish v=DMARC1; p=none; rua=mailto:you@yourdomain.com at _dmarc.yourdomain.com first, so you start receiving reports without risking any legitimate mail getting blocked. Review a few weeks of reports, confirm every legitimate source is aligned, then move to p=quarantine and eventually p=reject.
DKIM selector not found: log in to your email service provider's dashboard — Google Workspace, Microsoft 365, Mailchimp, Klaviyo, whichever you use — and look for a "domain authentication" or "custom sending domain" section. It will give you the exact selector and TXT record value to publish. This step happens inside your ESP, not your DNS provider, though the resulting record still gets published in DNS.
Related: Email Deliverability in 2026, explained · Open & Click Rate Benchmark Checker