What is a DKIM CNAME record and how do you set it up?

What are the requirements?

The DKIM signature identifies the lookup name

RFC 6376 defines d= as the signing domain and s= as the selector. The verifier constructs the key query from those values. In ordinary use, that query is the selector followed by ._domainkey. and the signing domain.

DKIM-Signature: v=1; d=yourdomain.com; s=selector1; ...
DNS lookup name:
selector1._domainkey.yourdomain.com

The values above are illustrative only. Your provider generates the actual selector and DNS target. Do not publish a selector, key, or target copied from another tenant.

A CNAME changes where the DNS lookup is resolved. It does not change the signature fields on the message. The provider must sign mail using the selector and signing domain that correspond to the published DNS path.

The selector hostname aliases the provider target

A provider using delegated DKIM supplies a CNAME record name under your domain and a target hostname under its DNS zone. Publish the alias exactly as supplied.

selector1._domainkey.yourdomain.com. CNAME selector1.dkim.provider.example.

This is an illustrative structural example only. Use the exact hostname and target generated in your provider's domain-authentication settings.

The DNS architecture matters. Under RFC 1034's CNAME rules, if a CNAME resource record is present at a node, no other data should be present there. In practice, do not leave a TXT record at the same selector hostname when you publish a CNAME. Check the existing DNS record set before changing it.

Replacing a live DKIM TXT record can interrupt verification for mail that still signs with that selector. Confirm which system uses the selector and retain a working validation path before removing an existing record.

The provider values must match the production sender

The CNAME record only delegates a DNS lookup. It does not prove that every message sent with your visible From: domain uses the provider, the configured selector, or a valid DKIM signature.

Follow the provider's official setup instructions for its values, verification process, and supported domain type. Provider labels and steps vary. Some services call this domain authentication, domain setup, or DKIM configuration. Use the current provider interface or its official documentation rather than a record example from another platform.

For subdomain traffic, confirm the domain in the message's d= value and the domain the provider asks you to authenticate. A subdomain can have its own DKIM configuration. See whether a subdomain needs its own DKIM setup before publishing records for a separate sending domain.

When does the requirement take effect?

There is no single industry-wide effective date for DKIM CNAME records. A CNAME is a DNS mechanism, and DKIM is an IETF standard. Whether you must use a CNAME, a direct TXT record, or another provider-specific method depends on the sending service you selected.

RFC 6376 is the controlling DKIM specification and is an IETF Standards Track RFC. It specifies how DKIM signatures and public-key retrieval work. It does not require every sender to publish a CNAME.

Provider domain-authentication requirements take effect when you enable the provider's sending feature or when that provider changes its documented process. Check the provider's current documentation before an implementation or migration. A previously verified domain status is not evidence that current DNS records still match the provider's active configuration.

How do I implement the requirement?

1. Identify the actual sending platform

List the platform that sends the mail, the domain in the visible From: address, and the domain or subdomain the platform says it will sign. Open that platform's official domain-authentication instructions.

If you use Cloudflare DNS, the Cloudflare DKIM setup guide can help with entering the provider-issued record at the DNS host. It does not replace the sending provider's DKIM instructions.

2. Generate the provider's DKIM records

Enable DKIM or domain authentication in the sending provider's current interface. Copy every record name and target exactly as generated.

Record values are account-specific. Do not substitute a generic selector such as selector1 or a target from a tutorial for the provider-generated values.

3. Inspect the existing selector hostname

Before adding a CNAME, look for an existing record at the exact selector hostname. Determine whether it is an active DKIM TXT record used by another sender.

If a TXT record exists at the same hostname, do not add a CNAME beside it. Plan a selector migration with the sender owner. A new selector is often safer than replacing a selector that may still sign production traffic.

4. Publish each CNAME in authoritative DNS

Create each provider-issued record as type CNAME. Enter the record name and target according to your DNS host's field conventions. Some DNS interfaces append the zone name automatically, so verify the fully qualified name after saving.

Do not add quotation marks around a CNAME target. Do not add a DKIM TXT key at the same hostname.

5. Complete provider verification

Use the provider's verification status after the DNS records are visible. If verification fails, compare the published fully qualified name and target against the generated values character by character.

The provider status checks its expected DNS condition. It does not prove that mail has been sent through the configured production path.

How do I validate compliance?

Validate DKIM CNAME setup at four layers.

• DNS: Query the exact selector hostname through the authoritative DNS service and a public resolver. Confirm it returns the expected CNAME target, then follow the alias to the provider-hosted DKIM key. The DKIM lookup tool is appropriate when you have the selector and sending domain. A public lookup cannot prove the production sender uses that selector, monitor later DNS changes, or predict a receiver's inbox decision.

• Vendor: Confirm the sending provider marks the authenticated domain or DKIM configuration as verified. Record the selector names the provider expects.

• Message: Send a real message through the exact production path to a mailbox you control. Inspect its raw headers. Under RFC 8601, Authentication-Results communicates authentication assessment results. Look for the DKIM result, the signing domain, and the selector where available.

Authentication-Results: receiver.example;
  dkim=pass header.d=yourdomain.com header.s=selector1

This header is illustrative only. Receiver formatting and available properties can vary. A provider dashboard is not a substitute for this delivered-message check.

• DMARC: Once aggregate reports accumulate, inspect which sources sign for the domain and whether their DKIM results align with the visible From: domain. A DKIM pass by itself may not satisfy DMARC alignment requirements.

For a single DNS question, use the DKIM lookup tool. For an ongoing estate with multiple sending platforms, Palisade can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets. It can propose the next policy step when evidence supports it, but a human reviews the evidence and applies any DNS or DMARC policy change.

Inspect the delegated DKIM record, then track the sources behind it

Start by checking the exact selector and signing domain the provider gave you.

Check the DKIM record

A successful public lookup confirms the published DNS path at that moment. It cannot prove that every production sender signs with the selector, that every signature aligns with the visible From: domain, or how receivers will handle future messages.

If your organization uses several sending services, that remaining gap is source inventory and repeated evidence from DMARC reports. Palisade is agentic DMARC software for teams that need to identify sources, investigate authentication and alignment issues, and work through prioritized remediation. It does not autonomously change your DNS or DMARC policy.

Start with Palisade