dkim.duplicate_records Reviewed July 2026

Quick fix

Identify the single active key and authoritative mail platform.

What this finding means

A selector should resolve to one effective DKIM key. SecuTest flags multiple TXT values or conflicting CNAME/TXT publication that can create non-deterministic behavior.

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 key ambiguity and verification failure

How the attack or failure scenario works

Receivers need one deterministic public key for a selector. Conflicting records can produce `permerror`, inconsistent results across resolvers, and DMARC failures. The condition does not by itself disclose a signing key or let an attacker forge mail.

Conditions and limitations

  • More than one effective DKIM key or delegation is published for the selector.
  • Receivers observe different or ambiguous answers.
  • The selector is actively used by outbound mail.

Why it matters

Security and business impact Multiple conflicting DKIM records for one selector can make key retrieval ambiguous 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. Identify the single active key and authoritative mail platform.
  2. Remove obsolete or conflicting TXT values.
  3. Do not publish both a CNAME delegation and local TXT key at the same owner name.
  4. Coordinate DNS cleanup with the sender's selector rotation schedule.

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

Verify the fix

  1. Query the selector from multiple external resolvers.
  2. Confirm one effective record or CNAME chain is returned.
  3. Send signed mail and verify consistent `dkim=pass`.
  4. Repeat SecuTest after TTL expiry.
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 quoted TXT fragments as separate logical records.
  • Deleting the active key instead of the retired one.
  • Leaving a provider CNAME beside a local TXT record.

Authoritative references