Email Authentication Checker

Type a domain that sends its own email (transactional or marketing) and this looks up its SPF, DKIM, DMARC, and BIMI DNS records over public DNS-over-HTTPS and reports what each one says and why it matters -- too many SPF DNS-lookup mechanisms (the single most common real-world SPF bug), a +all catch-all that authorizes anyone to send as your domain, a missing or monitor-only DMARC policy that leaves you spoofable while looking configured, and revoked or missing DKIM keys. Every finding names the exact record it read. This is evidence about your DNS, not a verdict -- never "your domain is secure", always "here is what your records say and what that means."

Check a domain

Runs directly from your browser to Cloudflare's public DNS resolver. Nothing is uploaded to this site.

Prefer the command line, or want to gate CI on it?

The Node CLI runs the identical checks with no dependencies to install, and its exit code (0 = no danger-severity finding and every lookup completed; 1 otherwise) is usable as a regression gate for your own domain's mail configuration:

node cli.mjs yourdomain.com
node cli.mjs yourdomain.com --json

Get cli.mjs, lookup.mjs, and analyze.mjs from the repo -- plain Node, nothing to install. It queries the same public DNS resolver as this page, straight from your own machine; nothing goes through this site either way.

Common questions

Why is my email going to spam?

The most common technical causes are a missing or misconfigured SPF record, no DKIM signing, or a missing/monitor-only (p=none) DMARC record -- mailbox providers use all three as spam and spoofing signals. This tool reads exactly what your domain's DNS currently says for each one and names what to fix. It cannot see reputation, content, or sending-volume factors, which also affect spam placement.

What does "too many SPF DNS lookups" mean, and why does it break everything?

RFC 7208 caps SPF evaluation at 10 DNS lookups (each include:, a, mx, ptr, exists mechanism and each redirect= modifier counts, and include: chains recursively). Go over 10 and the result is a permanent error (PermError) -- meaning SPF fails for every message from your domain, for every receiver, whether or not the message is legitimate. This is usually caused by stacking one include: per marketing or support tool over time until the total quietly crosses 10.

What is DMARC p=none and why is it a problem?

p=none means DMARC is in monitor-only mode: receivers are asked to take no action even on a message that fails alignment. It is the most common real-world gap, because a domain with SPF, DKIM, and DMARC all present looks fully configured while still being completely spoofable. p=none is a reasonable first step while you review the aggregate reports it generates; moving to p=quarantine or p=reject is what actually stops spoofed mail.

Does a clean report mean my email is fully secure?

No. This reads SPF, DKIM, DMARC and BIMI DNS records and reports what they say -- it is evidence about your domain's mail-authentication configuration, not a determination that your email is secure or that mail will reach the inbox. Deliverability also depends on sender reputation, content, list hygiene, and each receiver's own policies, none of which live in DNS.

Why check nine DKIM selector names instead of just looking up DKIM directly?

DKIM keys are published at a selector-specific name (<selector>._domainkey.yourdomain.com), and the selector is chosen by whichever provider sends your mail -- there is no single fixed name to look up. This tool checks the selector names commonly used by Google Workspace, Microsoft 365, Mailchimp/Mandrill, SendGrid, and a few generic defaults (google, selector1, selector2, k1, s1, s2, default, dkim, mail). If none of those resolve, that is not proof DKIM is missing -- check a sent message's own DKIM-Signature header, or your provider's dashboard, for the exact selector it uses.