DNS / email · Check
DKIM selectors not found — verify via Authentication-Results before assuming a problem
Common DKIM selector probes (`default`, `google`, `selector1`, `selector2`, `k1`, `mail`, `s1`, `s2`, `pm`, `key1`, `key2`, `dkim`) returned NXDOMAIN. Several mainstream ESPs — Amazon SES, SendGrid, Mailgun, Postmark — sign with auto-generated random selectors that no external DNS scan can enumerate. To verify DKIM definitively, paste any outbound email's `Authentication-Results:` header into the [Authentication-Results parser](/tools/email-auth-checker). If you see a passing aligned DKIM signature for your domain, you can ignore this finding. If you don't, configure DKIM at every ESP that sends mail in your name.
Real-world risk
If DKIM is genuinely not configured, DMARC alignment is weaker and message tampering in transit is harder to detect. If DKIM IS configured under a non-standard selector (typical for Amazon SES, SendGrid, Mailgun, Postmark), this finding is inconclusive — verify via an outbound email header.
Fix steps (in order)
- First confirm whether DKIM is actually configured: paste any outbound email's Authentication-Results header into the parser at /tools/email-auth-checker — if it shows a passing aligned DKIM signature, you can ignore this finding.
- If DKIM is not yet configured: enable it at your mail provider (Google Workspace, Microsoft 365, Amazon SES Easy DKIM, etc.) and publish the records they give you.
- Major ESPs use auto-generated random selectors that no DNS-scan can enumerate — Scorifya checks the standard provider selectors only.
Topic explainer
DMARC, SPF, and DKIM explained: the email authentication trio →
A practical guide to email authentication: what SPF, DKIM, and DMARC each do, why all three are needed, and how to roll out a DMARC policy that actually blocks spoofed mail.
Verify the fix in 30 seconds
Run a Scorifya scan on the affected host after deploy. The same finding id (dns_dkim_not_found) clears once the externally-observable signal is in place.