dkim.public_key_present Reviewed July 2026

Quick fix

Inspect live messages to determine whether the selector is still active.

What this finding means

An empty `p=` value revokes a selector under DKIM. SecuTest distinguishes an empty key from an active key but cannot determine from DNS alone whether senders still use the revoked selector.

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 DKIM signature invalidation and sender-authentication outage

How the attack or failure scenario works

If a sender continues signing with a selector whose public key is empty or missing, receivers cannot verify those signatures. Legitimate mail may fail DMARC, and attackers may benefit from the reduced authentication signal, although an empty key does not itself let them forge a valid signature.

Conditions and limitations

  • Outbound mail still uses the affected selector.
  • The published record has no active public key.
  • SPF does not provide an aligned DMARC pass or receiver policy depends on DKIM.

Why it matters

Security and business impact A selector record without an active public key cannot validate signatures and may represent an incomplete or unintended revocation.

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 live messages to determine whether the selector is still active.
  2. Publish the correct public key before enabling signing with that selector.
  3. If revocation is intentional, stop every sender from using the selector first.
  4. Retain old selectors only for the period required to validate delayed or queued mail.

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 key
dig +short TXT selector._domainkey.example.com

Intentional revocation
selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; p="

Verify the fix

  1. Query the selector and confirm `p=` contains the intended active key or is intentionally empty.
  2. Send a new message and verify `dkim=pass` with the expected selector.
  3. Check DMARC aggregate reports for selector-related failures.
  4. Repeat SecuTest after propagation.
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

  • Publishing a private key instead of the public key.
  • Revoking a selector while senders still use it.
  • Assuming an empty `p=` value is the same as NXDOMAIN.

Authoritative references