How to use it
- 1.Enter a domain such as
example.com, or paste an email address and the part after the @ is checked. - 2.Add a DKIM selector if you know it (the
s=value in theDKIM-Signatureheader of an email); otherwise the selectors of big providers are tried. - 3.Click Check. The verdict at the top sums up SPF, DKIM and DMARC; each section below shows the record, what it means and what to fix.
- 4.Open the includes under SPF to see which service uses how many of the 10 DNS lookups, and hover a domain or IP range to look it up in another tool.
What SPF, DKIM and DMARC do
Email was designed without any check of the sender, so anyone can put your domain in the From line. Three DNS records fix that. SPF (a TXT record starting with v=spf1) lists the servers allowed to send mail for the domain. DKIM signs every message with a key whose public half is published at <selector>._domainkey.<domain>, so receivers can verify the message wasn’t changed and really comes from the domain. DMARC (a TXT record at _dmarc.<domain>) ties both to the address people actually see in the From line and tells receivers what to do when neither passes: nothing (p=none), spam folder (p=quarantine) or refuse (p=reject).
A message passes DMARC when SPF or DKIM passes for a domain that matches the From domain. Forwarding often breaks SPF, which is why DKIM matters: a signature survives forwarding, the sending server’s address doesn’t. Gmail, Yahoo and Microsoft now require SPF, DKIM and a DMARC record from anyone who sends mail in bulk.
The SPF limit of 10 DNS lookups
To evaluate SPF, a receiving server may make at most 10 DNS lookups (RFC 7208). Every include, a, mx, ptr, exists and redirect costs one, including those inside the records you include. ip4, ip6 and all cost nothing. Go over 10 and the result is a permanent error (permerror): SPF fails for every message, often without anyone noticing.
Each email service you add (a CRM, a newsletter tool, a help desk) usually brings an include with several lookups of its own, and providers change theirs over time. Remove includes for services you no longer use, use the provider’s narrower include if it offers one, and send marketing mail from a subdomain with its own SPF record. Lookups that find nothing count too: more than two of them are also an error.
Moving DMARC from none to reject safely
Start with p=none and a rua address. Receivers then send daily aggregate reports listing every server that sent mail as your domain and whether SPF and DKIM passed. A report service or a free parser turns the XML into a readable list.
Fix every legitimate source that fails: add it to SPF, turn on DKIM signing in that service, or move it to a subdomain. When the reports show only your own mail passing, switch to p=quarantine, optionally with pct set below 100 for a gradual start, and after a few quiet weeks to p=reject. Keep reading the reports afterwards; a new tool that sends as your domain will show up there first.
Questions and answers
How do I fix “SPF permerror: too many DNS lookups”?
Count the lookups: this checker adds up every include, a, mx, ptr, exists and redirect across all nested records. Remove includes for services you no longer use, replace includes of your own servers with ip4/ip6 ranges, and move bulk senders to a subdomain with its own SPF record. Avoid “SPF flattening” services unless they keep the addresses up to date, because providers change their ranges.
Why doesn’t the checker find my DKIM key?
DKIM keys can only be looked up by selector, and there’s no way to list them. Without a selector, nestoo tries the names big providers use (Google, Microsoft 365, Mailchimp, SendGrid, Zoho and others). Open an email from the domain, look at the DKIM-Signature header and enter its s= value, for example s=20230601, as the selector.
Is p=none enough?
No. p=none only asks for reports; mail that fails DMARC is delivered as before, so spoofing still works. It’s the right first step. Move to p=quarantine and then p=reject once the reports show that all of your real mail passes.
Should SPF end with ~all or -all?
Both protect the domain when DMARC is in place, because DMARC decides what happens to failing mail. ~all (softfail) is the common choice and is more forgiving if you forget a sender. -all is stricter and fine once you’re sure the record is complete. Never use +all or ?all.
Does a domain that sends no email need these records?
Yes, otherwise spammers can use it. Publish v=spf1 -all, a DMARC record with p=reject, and optionally a null MX record (0 .) and an empty DKIM key at *._domainkey. Together they tell every receiver that no mail from this domain is real.