← All Tools
Free Tool

Email Auth Checker

Validate SPF, DKIM and DMARC for any domain. The browser queries Cloudflare DNS-over-HTTPS directly, parses each record and grades spoofing resistance with cited reasons. No proxy, no logging, no server-side state.

Lookup target: skipped — supply a selector to test DKIM

Enter a domain to resolve its SPF, DKIM and DMARC records via Cloudflare DNS-over-HTTPS.

FAQ

What does this tool actually query?

It issues DNS-over-HTTPS (DoH) requests to Cloudflare's 1.1.1.1 resolver at https://cloudflare-dns.com/dns-query with Accept: application/dns-json. For SPF it asks for the apex domain's TXT records and selects the one starting with 'v=spf1'. For DMARC it asks for TXT records on _dmarc.<domain> and selects 'v=DMARC1'. For DKIM you supply a selector (e.g. 'selector1', 'google', 'k1') and the tool looks up <selector>._domainkey.<domain>. The browser does the resolution directly — no AxVeil backend is involved.

Why are SPF DNS-lookup limits important?

RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups (include, a, mx, ptr, exists and the redirect modifier). Receiving servers MUST return PermError once that ceiling is crossed, which means SPF effectively fails open and your domain becomes spoofable. Nested 'include:' chains are the usual culprit — Microsoft 365 alone consumes 3-4 lookups, Google Workspace 1, every transactional ESP another 1-3. The tool counts mechanisms shallowly (it does not recurse into includes) and warns at 8 to give you headroom.

What is the difference between '~all', '-all' and '?all'?

The 'all' mechanism is the terminal default. '-all' is hard-fail: mail from non-listed sources should be rejected. '~all' is soft-fail: accept but mark suspicious, which is the safer default during rollout. '?all' is neutral — equivalent to having no SPF at all and almost always a misconfiguration. '+all' explicitly authorises every IP on the internet to send as your domain and is a critical finding; we flag both '+all' and '?all' as failures.

How is DMARC policy graded?

p=reject is the only policy that actually blocks spoofed mail at the receiver; p=quarantine sends it to spam (Strong-ish). p=none is monitor-only — useful while collecting rua reports but offers no protection in production. The 'pct' tag scales enforcement (pct=100 is full, pct=10 is a soft rollout). 'sp=' covers subdomains; if missing, receivers inherit 'p='. Strict alignment ('aspf=s', 'adkim=s') requires the From: header domain to exactly match the authenticated domain — relaxed ('r') allows organisational-domain matches. We mark p=reject + pct=100 + an rua address as 'Strong'.

Why does DKIM need a selector?

DKIM keys are published at <selector>._domainkey.<domain>, where the selector is chosen by whoever signs the mail. There is no way to enumerate selectors over plain DNS — you have to know the name. Common ones: Google Workspace uses 'google', Microsoft 365 uses 'selector1' and 'selector2', Mailchimp uses 'k1', SendGrid uses 's1' / 's2', Amazon SES uses tokens from the SES console. Open a recent message from the domain, inspect the DKIM-Signature header, and the 's=' tag is the selector to test here.