dkim.record_syntax Reviewed July 2026

Quick fix

Correct malformed tags and ensure the record uses supported DKIM syntax.

What this finding means

SecuTest parses the DKIM version, key type, flags, public-key value, separators, and duplicate tags. The check evaluates DNS publication, not whether every outgoing message is signed.

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 verification failure and DMARC degradation

How the attack or failure scenario works

A receiver parses the selector record before validating a signature. Invalid tags or structure can make the key unusable, causing `dkim=permerror` or fail. This removes one authentication path and can let spoofed mail face weaker DMARC enforcement when SPF is also absent or misaligned.

Conditions and limitations

  • A message is signed with the malformed selector.
  • The receiver queries and parses the defective record.
  • No alternative aligned DKIM signature or SPF pass satisfies DMARC.

Why it matters

Security and business impact Malformed DKIM tags can make a published key unusable and cause signature verification failures.

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. Correct malformed tags and ensure the record uses supported DKIM syntax.
  2. Publish one logical TXT value even if the DNS provider splits long quoted strings.
  3. Remove duplicate or unsupported tags and verify the declared key type.
  4. Test signatures from every outbound platform before completing the rotation.

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.

Valid RSA record
selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"

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

Verify the fix

  1. Query the selector externally and reconstruct the full TXT value.
  2. Decode and validate the `p=` public key.
  3. Send a message and confirm `dkim=pass` and DMARC alignment.
  4. Repeat the scan after DNS 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

  • Copying PEM headers such as `BEGIN PUBLIC KEY` into `p=`.
  • Publishing multiple conflicting TXT records for one selector.
  • Adding literal quote characters to the key value.

Authoritative references