Mailscope
SPF, DKIM and DMARC checker
What the three records do
SPF lists which servers are allowed to send mail using your domain in the envelope sender. DKIM adds a cryptographic signature to each message, so a receiver can confirm it was not altered and really came from you. DMARC ties the two together: it tells receivers what to do when a message fails both, and where to send reports.
None of them works alone. SPF breaks when mail is forwarded; DKIM survives forwarding but says nothing about messages with no signature at all. DMARC is what turns two partial signals into a policy.
The SPF lookup limit, which catches almost everyone
An SPF record may cost at most ten DNS lookups to evaluate — RFC 7208
§4.6.4. Every include, a, mx,
ptr, exists and redirect counts, and crucially
so does everything inside the records they point at.
Exceeding the limit is a permanent error. Receivers may treat the whole record as invalid, so mail starts failing while your SPF record still looks perfectly reasonable in a text editor. This is why adding one more marketing tool can break delivery for a domain that has worked for years.
The count above follows every include recursively, so it shows the real
cost rather than the number of lines you wrote. If you are close to the limit, the fix
is usually to remove providers you no longer use, or to flatten the record to explicit
IP ranges — accepting that flattened records go stale when a provider changes address.
Why p=none is not finished
A DMARC record with p=none collects reports and instructs receivers to do
nothing. It satisfies the letter of the Google and Yahoo bulk-sender requirements that
took effect in February 2024, and it stops nobody from spoofing your domain.
The intended path is to start at p=none with a rua address,
read the reports until you are confident every legitimate sender is passing, then move
to quarantine and finally reject. Many domains stop after the
first step, which is the equivalent of installing an alarm and never switching it on.
Finding your DKIM selector
DKIM keys are published at selector._domainkey.yourdomain, and the
selector is chosen by whoever sends your mail. There is no way to discover it from DNS
— you cannot list what you cannot name.
With no selector given, this checks around twenty common ones used by the major
providers. Finding nothing does not prove there is no key; it means none of the usual
names matched. The reliable way to find yours is to look at the
DKIM-Signature header of a message you have sent, where it appears as the
s= tag.
This tool uses the util.quest server. It cannot run in your browser — the work is either impossible there or too heavy for it. What you submit is sent to this server, used to produce the result, and not stored afterwards. Requests are rate limited, and nothing about them is logged beyond what is needed to enforce that.
Check whether a domain is set up to send email that actually arrives. Reads the SPF, DKIM and DMARC records, explains what each one is telling receiving servers, and flags the mistakes that quietly send mail to spam — a too-permissive SPF policy, a DMARC record stuck on none, a missing selector.
It's one of the free tools in the util.quest collection — nothing to install, and no account needed. Found a bug or want a feature? Reach out at [email protected].
