Loading…
Loading…
Cookies and privacy
We use strictly necessary cookies to run the site. With your permission we also load Vercel Web Analytics and Speed Insights to measure traffic and performance in aggregate. See our Cookie Policy and Privacy Policy.
Paste any domain. Scorifya probes the common ESP selectors, validates the public-key format, and flags domains where DKIM isn't configured.
Free tool
DKIM keys live at <selector>._domainkey.<domain> in DNS, and there's no canonical selector — each ESP (Mailgun, SendGrid, SES, Google Workspace, Microsoft 365) uses its own. The DKIM checker probes the common selectors, reports which resolve, validates the public key format, and flags missing or expired keys that would silently fail DMARC alignment.
Paste a domain (or any URL — Scorifya extracts the apex). The scan probes the common DKIM selectors used by major ESPs, reports which resolve to valid public keys, and flags domains that have no DKIM at all (DMARC will still pass on SPF alignment alone, but losing DKIM means losing the cryptographic-proof half of email auth).
This page is written for people searching for DKIM checker—same tool as the homepage, with context for that query.
How we differ from deep TLS graders, browser-focused posture tools, and header-only checkers: read the comparison.
Illustrative snapshots of what a report can look like—paste your URL above for a live score on your site.
Example A — no DKIM selectors detected
Web posture is good and SPF is published, but no DKIM selectors resolve. DMARC has only SPF to align with — fragile against forwarding.
No DKIM selectors detected
Common selectors (default, google, mailo, k1, s1, s2, mail) returned NXDOMAIN. Configure DKIM at your ESP and publish the public key.
SPF and DMARC both present
Existing email-auth records are correct; DKIM is the missing third leg of the trio.
Example B — multiple DKIM selectors resolving
DKIM selectors for Google Workspace and Mailgun both resolve. Strong email-auth posture; DMARC alignment can use either.
DMARC at p=quarantine
Once aggregate reports stabilize, move to p=reject for full enforcement.
Configure DKIM at every ESP you use
Each marketing or transactional vendor publishes setup steps. The output is a TXT record at <selector>._domainkey.<your-domain>.
Use 2048-bit RSA keys
1024-bit DKIM keys are formally deprecated. Most ESPs default to 2048 now, but legacy setups may still publish 1024. Re-issue if you find one.
Rotate DKIM keys periodically
Annually is reasonable. Automated key rotation is supported by most ESPs and reduces long-term key-compromise risk.
Align From: with DKIM signing domain
DMARC alignment requires the d= value in the DKIM signature to match (or be a subdomain of) the visible From: domain. Misaligned third-party senders are the most common cause of DMARC failures.
Re-scan after each ESP change
Adding a new transactional vendor means a new DKIM selector. Re-scan to confirm the public key resolves and DMARC reports show alignment.
For weights and penalties behind each category, see How Scorifya works.
The most common ESP selectors: default, google, k1, k2, mail, mailo, s1, s2, selector1, selector2, mxvault, smtpapi, and a handful of vendor-specific ones. If your ESP uses a non-standard selector, point it at us via the URL or contact form and we'll add it.
Three common reasons: (1) Your ESP uses a custom selector not in our probe list. (2) The TXT record was published at the wrong path — should be <selector>._domainkey.<your-domain>. (3) The TTL hasn't propagated yet; recheck in 30 minutes.
Yes — DMARC can align on either SPF or DKIM. But running both is more resilient: SPF survives most direct delivery paths, DKIM survives forwarding. The combination is meaningfully stronger than either alone.
DKIM signs the message in transit at the sending domain level; receivers verify the signature against the public key in DNS. S/MIME signs (and encrypts) end-to-end at the user level. They serve different threat models.
Only if you forget to migrate the DKIM selector TXT records. Always export the full zone (including _domainkey records) before switching, and verify selector resolution from a public resolver after the move.
More detail on limits and billing: FAQ.
TLS, HTTPS & redirects
Valid certificates, modern TLS, and clean HTTP→HTTPS upgrades. We also probe whether legacy TLS 1.0/1.1 are still accepted.
Security headers
CSP, HSTS, and related headers reduce common browser-side attack surfaces and clickjacking risk.
DNS & email (passive)
SPF, DMARC, a few DKIM selectors, MX, and whether common subdomains resolve publicly—without port scanning.
Hygiene signals
Verbose server banners and risky defaults can raise your attack surface and erode trust.
Not a vulnerability scan
Scorifya checks public configuration signals; it does not attempt exploitation, port scans, or authenticated crawling.
If you're iterating on headers or deploying changes, you'll likely run multiple checks as you tighten config. When you're ready, Scorifya Pro removes scan limits and unlocks JSON/CSV/PDF exports.