[ DNS & domains ]

Dangling DKIM CNAMEs after a supplier is offboarded

Retire supplier-managed DKIM aliases with checks for active selectors, standby rotation, delayed messages, target control and remaining access.

By the EmailAuth research team · 8 min read

[ Key points ]

  • A DKIM alias, signing configuration and supplier credentials are separate dependencies.
  • Check standby selectors and in-flight messages before retiring public-key lookups.
  • Do not infer target claimability or instant global revocation from a DNS change.
On this page
  1. Key points
  2. Takeaway
  3. By role
  4. Frequently asked questions
  5. Sources
  6. Glossary
  7. Related guides

[ Takeaway ]

Close the actual signing relationship, preserve only justified message dependencies, and verify DNS retirement and replacement authentication separately.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Retire selectors by evidence

Recent message samples do not reveal every rotation or queue dependency.

Next steps

  1. Inventory exact d=/s= and alias targets.
  2. Check standby selectors and scheduled or delayed messages.
  3. Verify the replacement signer and retirement DNS state.

CISO / SecOps

Review continuing key control

An external public-key target remains a trust dependency until properly retired.

Next steps

  1. Validate provider lifecycle controls without claiming targets.
  2. Coordinate access retirement and any urgent revocation decision.
  3. Avoid asserting that cached keys disappear immediately.

Founder / Non-technical

Finish supplier offboarding across teams

Contract closure does not automatically stop workflows or delete DNS records.

Next steps

  1. Confirm which applications still depend on the supplier.
  2. Approve migration and a justified retirement deadline.
  3. Require owner closure of DNS, configuration and access tasks.

[ FAQs ]

Frequently asked questions

Does deleting a supplier account remove its DKIM CNAMEs?

Do not assume so. Customer DNS publication and provider account configuration are separate responsibilities; verify both sides of the offboarding relationship.

RFC6376

Is a selector absent from recent mail safe to delete?

Not necessarily. Microsoft 365 documents active and rotation-standby selectors. Check the actual supplier’s supported model and other workflows before retirement.

Microsoft: Configure DKIM for custom domains

Does a CNAME itself let someone sign mail?

No. Signing requires a private key. The alias directs public-key discovery, so control of its target remains a dependency that must be assessed separately.

RFC6376

Does a missing target prove a reclaimable DKIM service?

No. A missing key or target does not establish provider reassignment or ownership-validation behavior. Retain that uncertainty and seek authoritative provider evidence.

Microsoft: Prevent dangling DNS entries and avoid subdomain takeover

How long should the old key stay published?

There is no universal interval in this guide. Base the decision on actual queued and already signed messages, service behavior, and the security owner’s risk decision.

RFC6376

Must a compromised key stay available for delayed messages?

No. A security incident may justify faster revocation despite delivery disruption. The accountable security owner must decide and coordinate that response.

RFC6376

Does deleting the CNAME revoke it everywhere instantly?

No. Recursive resolvers may retain cached alias or key data. Verify authoritative removal and record cache observations without promising immediate global disappearance.

RFC1034

What proves the replacement route is ready?

Retain a controlled received message with the intended signing identity and a passing path aligned with the visible From. A DNS save or provider badge alone is insufficient.

RFC9989

[ Sources ]

Sources

  1. RFC1034

    Sections §3.6 Aliases and canonical names · §4.2 How the database is divided into zones · §4.3.4 Negative response caching

  2. RFC2308

    Sections §2. Negative Responses · §5. Caching Negative Answers

  3. RFC9989

    Sections Identifier Alignment · DMARC Policy Discovery

  4. RFC6376

    Sections §3.5 DKIM-Signature Header Field · §3.6 Key Management and Representation · §5. Signer Actions · §6. Verifier Actions

  5. Microsoft: Prevent dangling DNS entries and avoid subdomain takeover

    Sections What is subdomain takeover? · Prevent dangling DNS entries · Remediate dangling DNS entries

  6. Microsoft: Configure DKIM for custom domains

    Sections Syntax for DKIM CNAME records · Rotate DKIM keys · DKIM signing configuration for custom domains

[ Glossary ]

Glossary

Selector
The DKIM signature value used with the signing domain to locate the applicable public key.

RFC6376

Standby selector
A selector retained for a provider’s supported future key rotation rather than current signing.

Microsoft: Configure DKIM for custom domains

Retirement deadline
The approved point for removing an obsolete lookup after message dependencies and security risk are reviewed.

RFC6376

Key-discovery dependency
The DNS lookup relationship through which a receiver obtains the public key for a DKIM signature.

RFC6376

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base