The fix, in one snippet
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg…"Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
DKIM keys live at <selector>._domainkey.<domain>, and the selector is chosen by whoever signs the mail, so Scan.now cannot know it in advance. It queries TXT records for a short fixed list of selectors that major providers use by default: google, default, selector1 and selector2 (Microsoft 365), k1 (Mailchimp), s1 and s2, dkim, mail, mandrill, everlytickey1, zendesk1 and pm. A record containing v=DKIM1 or a p= tag counts as discovered; the report names the selector. For each key found it decodes the public key and flags RSA keys under 1024 bits (RFC 8301 forbids verifiers from accepting them), notes 1024-bit keys as acceptable but below the recommended 2048, flags an empty p= (a revoked key) and notes t=y test mode. Not finding a key is informational, since your provider may simply use a selector that is not on the list.
Why it matters
DKIM signs each message with a private key and publishes the public half in DNS, so a receiver can verify that the headers and body were not altered and that the signer controlled the domain. Unlike SPF it survives forwarding and mailing lists, because the signature travels with the message rather than depending on which server delivered it. That matters for DMARC: once you enforce p=reject, any legitimate message that gets forwarded will fail SPF, and if there is no DKIM signature to fall back on, it will be rejected. Key strength matters as well; in 2012 a researcher factored 512-bit DKIM keys that several large companies were using, which allowed perfect forgeries until the keys were replaced. A 2048-bit key is the current norm and every major provider supports it. Our SPF, DKIM and DMARC guide explains selectors and alignment.
How to fix it
Enable DKIM at each service that sends mail for the domain, choose 2048-bit keys, and publish the records the provider gives you. Google Workspace (Admin console > Apps > Google Workspace > Gmail > Authenticate email) produces a record like:
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."Microsoft 365 uses two CNAME records so it can rotate keys itself:
selector1._domainkey.example.com. IN CNAME selector1-example-com._domainkey.tenant.onmicrosoft.com.
selector2._domainkey.example.com. IN CNAME selector2-example-com._domainkey.tenant.onmicrosoft.com.Transactional providers (SendGrid, Mailgun, Postmark) likewise supply CNAMEs. In the Cloudflare DNS dashboard, add them with the proxy status set to "DNS only"; a proxied CNAME will break DKIM lookups. Records longer than 255 characters must be split into multiple quoted strings, which the Cloudflare UI does automatically. Verify each selector:
dig +short TXT google._domainkey.example.comThen send a message to a Gmail address and use "Show original", which reports DKIM: PASS with the signing domain. Rotate keys at least yearly and revoke old selectors by publishing an empty p=.
Where this fits
DKIM selector discovered is check 7 of 8 that the website vulnerability scanner runs under dns and email authentication, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits DNSSEC signing (low), where the domain's DNS zone is not signed with DNSSEC, so a resolver cannot verify that the answers it receives for your domain are genuine, or the zone is signed but validation is failing. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
DKIM selector discovered closes one route in. The next one down is MX records, where a review of the domain's MX records: Whether mail is deliverable, whether every mail host resolves, and whether a domain that sends no mail says so with a Null MX.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: DKIM selector discovered (info severity)
Scanner check id: dkim-recordThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
