dkim.selector_resolvable Reviewed July 2026

Quick fix

Inspect outbound `DKIM-Signature` headers to identify selectors actually in use.

What this finding means

SecuTest tests bounded known, configured, common, or provider-inferred selectors. A failed candidate does not prove the domain never signs mail; the finding applies only to the selector represented in the evidence.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Email signature verification failure and spoofing opportunity

How the attack or failure scenario works

DKIM signs selected message headers and body content with a private key. Receivers retrieve the matching public key from `selector._domainkey.example.com`. If that DNS name cannot resolve, signatures using the selector cannot validate, which may cause DMARC failure and reduce resistance to spoofed mail.

Conditions and limitations

  • A legitimate or forged message references the unresolved selector.
  • The receiver cannot retrieve a valid public key.
  • DMARC impact depends on whether SPF supplies an aligned pass or another valid DKIM signature exists.

Why it matters

Security and business impact A configured DKIM selector that does not resolve prevents receivers from retrieving the public key needed to verify signatures.

Step-by-step fix

Where to make the change

  • The authoritative DNS zone for the registrable domain.
  • The outbound or inbound mail platform when sender authorization, signing, or routing is involved.
  • The DMARC reporting mailbox or reporting service when aggregate reports are required.

Remediation procedure

  1. Inspect outbound `DKIM-Signature` headers to identify selectors actually in use.
  2. Publish the required TXT key or correct the provider CNAME target at the selector hostname.
  3. Remove retired selectors from sender configuration before deleting their DNS records.
  4. Allow DNS propagation before switching all traffic to a new selector.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Inspect selector
dig +short CNAME selector._domainkey.example.com
dig +short TXT selector._domainkey.example.com

Microsoft 365 selectors
dig +short CNAME selector1._domainkey.example.com
dig +short CNAME selector2._domainkey.example.com

Verify the fix

  1. Run `dig +short TXT selector._domainkey.example.com` and follow CNAMEs.
  2. Send a signed message and inspect `Authentication-Results` for `dkim=pass`.
  3. Confirm the `s=` selector and `d=` signing domain match the intended DNS record.
  4. Repeat SecuTest with any explicit selector configuration required.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Treating an undiscovered selector as proof that DKIM is absent.
  • Publishing the key at the root domain instead of `_domainkey`.
  • Switching senders before the new selector has propagated.

Authoritative references