dkim.public_key_strength Reviewed July 2026

Quick fix

Generate a modern key supported by the sending platform and major receivers.

What this finding means

SecuTest measures the decoded public-key size rather than inferring strength from TXT length. It reports policy-level weakness and does not claim that the private key has been recovered.

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 forgery through weak cryptography

How the attack or failure scenario works

If an attacker factors a weak RSA key or otherwise recovers the private signing key, they can create messages that pass DKIM for the domain. When the signing domain aligns with the visible From domain, forged messages may also pass DMARC.

Conditions and limitations

  • The published key uses insufficient cryptographic strength.
  • The attacker obtains enough computational capability or another path to recover the private key.
  • The forged signature uses an aligned signing domain and a selector still trusted by receivers.

Why it matters

Security and business impact A weak DKIM key may not provide adequate resistance to key recovery or signature forgery over its operational lifetime.

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. Generate a modern key supported by the sending platform and major receivers.
  2. Publish it under a new selector rather than replacing an active key in place.
  3. Enable staged rotation or dual-signing when supported.
  4. Retire the old selector after DNS propagation and verification of every sender.

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 RSA size
printf '%s' 'BASE64_PUBLIC_KEY' | base64 -d | openssl pkey -pubin -text -noout

Common target
Use at least 2048-bit RSA where the provider and DNS size limits support it, or a supported Ed25519 deployment.

Verify the fix

  1. Decode the public key and inspect its actual bit length.
  2. Send signed mail through every legitimate platform.
  3. Confirm `dkim=pass` and DMARC alignment with the new selector.
  4. Monitor aggregate reports before removing the old selector.
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

  • Measuring base64 character count instead of decoded key size.
  • Replacing the DNS key without updating the sender's private key.
  • Removing the old selector before delayed mail has been processed.

Authoritative references