Quick fix
Correct loops and misspelled provider targets.
What this finding means
Hosted mail platforms commonly delegate selectors with CNAME records. SecuTest follows the chain within a strict depth and reports loops, unresolved targets, and unsafe chain behavior.
Interpretation boundary
Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, or business intent when those cannot be proven remotely.
Why it matters
Security impact
A broken, looping, or excessively long DKIM CNAME chain can prevent receivers from retrieving the signing key.
Step-by-step fix
Where to make the change
- The authoritative DNS zone for the domain.
- The outbound mail platform or email-security gateway when signing or sender authorization is involved.
- The DMARC reporting mailbox or reporting service when aggregate reports are required.
Remediation procedure
- Correct loops and misspelled provider targets.
- Remove obsolete intermediate aliases.
- Keep the chain short and ensure the final target publishes one valid DKIM key.
- Confirm the provider tenant still owns the final resource.
Commands and configuration examples
Replace example values with the hostname, selector, IP address, port, or provider values shown in your SecuTest evidence.
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
dig +short TXT selector._domainkey.example.com
Verify the fix
- Run: dig +trace selector._domainkey.example.com
- Resolve every CNAME hop externally.
- Confirm the final TXT key is valid.
- Send signed mail and verify dkim=pass.
Confirm the externally visible result
Re-scan your domain
After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.
Common mistakes
- Adding a CNAME where a TXT record already exists.
- Pointing to a provider hostname from a deleted tenant.
- Testing only with an internal split-horizon resolver.