How to implement DKIM without a TXT record?
Updated on 21 Oct 2026: We clarified CNAME-based DKIM setup and added DNS checks for hosted public keys.
You implement DKIM without publishing the public key as a TXT record in your own DNS by publishing a CNAME record at the DKIM selector host when your email provider supports this setup. That CNAME points to a hostname controlled by your email provider, and the provider publishes the final DKIM TXT record there. Your domain still participates in DKIM, but you do not store the long public key directly in your zone.
DKIM still depends on DNS. RFC 6376 defines dns/txt as a key query method that all DKIM implementations must support. When selector._domainkey.example.com is a CNAME, DNS follows the alias during that TXT query and retrieves the public key at the target. The CNAME delegates the lookup; it does not become a DKIM key record itself. This setup is common when a third-party sender manages signing and key rotation. See RFC 6376 for the DKIM key lookup rules.
- Direct answer: Use a DKIM CNAME record such as selector1._domainkey pointing to the sender's DKIM host.
- What changes: Your DNS contains a CNAME, not the long v=DKIM1 TXT value.
- What stays true: The final destination must still return a valid DKIM public key.
- Best use case: Provider-managed DKIM where the sender controls signing and key rotation.
How CNAME-based DKIM works
DKIM has two halves: the sender signs the message with a private key, and the receiving server verifies that signature with the matching public key in DNS. The signature header contains the selector in the s= tag and the signing domain in the d= tag. The verifier combines those values to query DNS.
For example, if an email has d=example.com and s=selector1, the receiver queries selector1._domainkey.example.com. If that name is a TXT record, the receiver reads the DKIM key directly. If that name is a CNAME, DNS follows the alias and reads the TXT record at the destination.
DKIM verification follows the selector CNAME to retrieve a hosted TXT public key.
Typical CNAME-based DKIM setupdns
s1._domainkey.example.com. CNAME s1.dkim.sender.example. s2._domainkey.example.com. CNAME s2.dkim.sender.example.
In that setup, your DNS zone has only the two CNAME records for these selectors. The sender's DNS zone contains the final DKIM TXT values. This avoids copying long public keys and reduces customer DNS changes during provider-managed key rotation, provided the CNAME targets stay the same.
A DKIM CNAME is not a shortcut around authentication. It is DNS delegation at the selector hostname. The receiving server still verifies the message against a public key, and DKIM still fails if the final TXT record is missing, malformed, or mismatched.
When a DKIM CNAME is the right choice
DKIM CNAMEs fit when a third-party sender owns the signing infrastructure and has a stable pattern for delegated keys. This includes business mail platforms, help desk systems, billing tools, event platforms, and marketing senders. The sender generates the DKIM pair, signs outbound mail, hosts the public key, and tells you which CNAME records to publish. If the provider supplies only a TXT public key, publish that record unless it explicitly supports hosted DKIM keys. An invented CNAME target will not host the matching key. Keep the private key on the signing platform and never publish it in DNS. For RSA signing, prefer 2048-bit keys with rsa-sha256, following RFC 8301.
The strongest reason to use a CNAME is operational control. If a provider rotates a key, upgrades key length, changes signing infrastructure, or needs to recover from a private key exposure, they can update the target TXT record. You do not need to edit your domain's DNS each time if the provider keeps the same CNAME targets.
Direct TXT
- Ownership: You publish the full public key in your own DNS zone.
- Change process: You update DNS whenever the DKIM key changes.
- Failure mode: Long TXT values can be split incorrectly by DNS panels.
CNAME delegation
- Ownership: You publish a short alias to the sender's DKIM host.
- Change process: The sender can rotate the hosted public key.
- Failure mode: The CNAME target must remain live and valid.
A CNAME gives the provider control over the public key returned for that selector. Give each independent sender its own selectors. When retiring a sender, remove its selector CNAMEs after signing has stopped and messages in transit no longer need those keys, so the old provider no longer controls those selectors.
|
|
|
|
|---|---|---|---|
Direct key | TXT | Self-managed mail | Manual rotation |
Hosted key | CNAME | Third-party sender | Provider dependency |
Delegated zone | NS | Many selectors | Control of the delegated subtree |
Common DKIM publication models
How to set up DKIM with CNAME records
Use the exact selector hostnames and targets supplied by the sender. Publish them at the authoritative DNS provider for the signing domain. Adding records only to a web host or mail server that does not control public DNS will not affect receiver lookups.
- Confirm the signing domain: Make sure the provider's DKIM signing domain meets the visible From domain's DMARC matching rules. Strict alignment requires an exact domain match; relaxed alignment allows the same organizational domain.
- Get the selectors: Collect every selector the provider requires, often two records for rotation.
- Publish CNAME records: Add each selector under _domainkey and enter the provider's exact target hostname, not a URL or a public-key value.
- Enable signing: Turn on DKIM in the sender's admin panel after both the selector CNAME and the hosted public key resolve.
- Send a real test: Inspect the delivered message headers and confirm dkim=pass with the expected domain.
- Monitor DMARC: Watch aggregate reports to confirm the new source is passing DKIM with DMARC alignment at scale.
Example DKIM CNAME recordsdns
s1._domainkey.example.com. CNAME s1.domainkey.u12345.sender.example. s2._domainkey.example.com. CNAME s2.domainkey.u12345.sender.example.
Some DNS providers want the host field without the domain, such as s1._domainkey. Others want the full hostname. Some add the root domain automatically. If you enter the full hostname into a panel that appends the domain, you can accidentally create s1._domainkey.example.com.example.com, which will never validate.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
After publishing the records, check the selector with a DKIM checker. A good result should show that the selector resolves, follows the CNAME if present, and returns a valid DKIM key record with a nonempty p= public-key value.
Do not put a CNAME and TXT record at the same selector hostname. A CNAME cannot coexist with ordinary TXT data at that name. If the TXT selector is active, use a new selector for the CNAME or coordinate a signing migration before replacing it. Keep old public keys available while messages signed with them are still in transit.
Verify the CNAME and hosted DKIM key
Use the selector and signing domain in a real message's DKIM-Signature header. These example commands inspect the CNAME, request its TXT answer, and query the target directly. Replace the example names with the actual selector and provider target.
Look up the selector alias and public keybash
dig CNAME s1._domainkey.example.com +noall +answer +comments dig TXT s1._domainkey.example.com +noall +answer +comments dig TXT s1.domainkey.u12345.sender.example +noall +answer +comments
The CNAME answer should match the provider target, and the final TXT answer must contain a usable public key. The v=DKIM1 tag is recommended but optional. An empty p= value means the key is revoked, not ready for use. These key-record rules are defined in RFC 6376.
- NXDOMAIN: The selector or a target in the CNAME chain does not exist. Check each hostname separately.
- NOERROR without a TXT answer: Query the target directly and confirm that the provider has published its key.
- SERVFAIL or a timeout: Investigate DNS resolution, including nameserver availability and DNSSEC validation.
After a DNS change, cached records and earlier 'not found' responses can persist until their TTLs expire. Compare authoritative DNS with your resolver's answer before repeatedly editing correct records. Negative caching follows RFC 2308.
Verify DKIM and DMARC in message headers
Receivers do not care whether the public key started as a direct TXT record or behind a CNAME. They care that the DNS query returns a valid public key and that the cryptographic signature matches the message body and signed headers.
The visible result appears in the receiving server's Authentication-Results header. Check dkim=pass and the expected signing domain. For DMARC, compare the DKIM d= domain with the visible From domain. Default relaxed alignment allows the same organizational domain, such as d=mail.example.com with From: sender@example.com. Strict alignment (adkim=s) requires identical domains. The CNAME target is not the domain used for this comparison. See RFC 9989 for DMARC matching rules.
DMARC domain matching with a DKIM public key reached through a CNAME.
Authentication result after CNAME DKIM workstext
Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=s1; spf=pass smtp.mailfrom=bounces.example.com; dmarc=pass header.from=example.com
That header tells you the receiver found the DKIM key and verified the signature. It does not tell you whether the key was directly published as TXT or reached by CNAME. For troubleshooting, query the selector hostname and inspect the DNS chain.
CNAME-based DKIM satisfies DMARC through DKIM when a passing signature has the required domain match. A signature using an unrelated provider domain does not satisfy that check. The message can still pass DMARC through SPF if SPF passes with the required domain match.
Set up DKIM CNAME records in Microsoft 365
Microsoft 365 is a familiar example of DKIM without a customer-hosted TXT key. For a custom domain, Microsoft asks you to publish two CNAME records under your domain. Those records point to Microsoft-controlled hostnames, and Microsoft hosts the final DKIM public keys.
Microsoft Defender portal showing selector1 and selector2 CNAME records for DKIM.
The pattern places selector hostnames under your domain and the target hostnames under Microsoft's DKIM infrastructure. The Microsoft DKIM guide documents the required CNAME setup for custom domains.
Microsoft introduced an updated target format for new custom domains in May 2025. It contains a generated partition character and ends under dkim.mail.microsoft. Existing custom domains can retain the older target format under onmicrosoft.com.
Current Microsoft-style DKIM CNAME patterndns
selector1._domainkey.example.com. CNAME selector1-example-com._domainkey.exampletenant.r-v1.dkim.mail.microsoft. selector2._domainkey.example.com. CNAME selector2-example-com._domainkey.exampletenant.r-v1.dkim.mail.microsoft.
The tenant prefix and partition character in this example are illustrative. Copy both targets from the admin console or retrieve Selector1CNAME and Selector2CNAME with Exchange Online PowerShell. Follow Microsoft's recommended minimum TTL of 3600 seconds and verify DNS before enabling signing.
Retrieve the exact Microsoft 365 DKIM targetspowershell
Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
Common mistakes that break CNAME DKIM
CNAME-based DKIM is easier than managing long TXT keys, but it has a few sharp edges. Most failures come down to the wrong hostname, the wrong target, an old record at the same name, or assuming that a DNS pass means emails are actually signed.
- Wrong selector: The record exists, but the email is signed with a different selector in the DKIM header.
- Double domain: The DNS panel appends the root domain after you already entered the full hostname.
- Coexisting records: A CNAME is added where an old TXT record still exists, causing invalid DNS.
- Target typo: A copied target has a missing character, extra domain suffix, or wrong tenant value.
- Unsigned mail: The DNS is valid, but the sending platform has not enabled DKIM signing for the stream.
- No DMARC alignment: DKIM passes, but the signing domain does not have alignment with the visible From domain.
DNS providers can also complicate CNAME setup when proxying, flattening, or UI-specific host fields alter the published answer. Keep DKIM CNAME records DNS-only and turn off CNAME flattening for those records so the alias remains visible. If the record appears correct but will not validate, compare the requested hostname with the actual DNS name and record type returned by lookup. A related provider-specific issue is covered in Cloudflare CNAME DKIM.
A valid DKIM DNS record does not prove your outbound mail is DKIM-signed. Always send a real email and inspect the delivered headers. If the DKIM-Signature header is missing, check signing in the sending platform and any intermediary that removes signatures; publishing DNS records does not add a signature to a message.
If you cannot find the selector, look at the DKIM-Signature header from a delivered message. The selector is the value after s=. If there is no DKIM-Signature header, check signing settings and any gateway that processes the message. The separate problem of finding keys without a known selector is covered in find DKIM selector.
How CNAME-based DKIM affects deliverability and DMARC
CNAME-based DKIM does not hurt deliverability by itself. Receivers evaluate the final DKIM result, domain alignment, sender reputation, message content, complaint rate, bounce rate, and prior engagement. A CNAME behind the key is normal and accepted.
The deliverability risk appears when teams assume DKIM is done after DNS validates. A domain can have correct selector records but no signed outbound mail, or DKIM can pass with a provider domain that does not satisfy DMARC alignment. If no other passing DKIM signature has the required domain match, DMARC must rely on SPF with the required domain match. Forwarding often breaks SPF; DKIM survives forwarding when the signed content remains unchanged.
DKIM rollout checkpoints
Use these checkpoints before relying on CNAME-based DKIM to satisfy DMARC.
DNS resolves
Required
The selector follows the CNAME and returns a valid key.
Mail is signed
Required
Real outbound messages include a DKIM-Signature header.
DKIM passes
Required
Receivers report dkim=pass for delivered messages.
DMARC alignment
Required
The DKIM signing domain has alignment with the visible From domain.
Suped's DMARC reporting platform shows authentication results for reported sending sources. Use those reports to identify DKIM failures after a selector goes live and check whether provider-managed signing continues to meet DMARC requirements after key rotation.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Use Suped's DMARC monitoring to track whether the source consistently passes authentication with the required domain match across reporting receivers.
Check the domain as a whole after a DKIM change. A selector can be correct while the domain still has weak SPF, missing DMARC reporting, or another sender failing alignment.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A full domain health check is useful after you change DKIM because it also catches SPF, DMARC, and related DNS issues that affect the same sending domain.
Can you avoid both TXT and CNAME records?
For normal DKIM on a domain you control, no. A receiver must be able to discover the public key through DNS. If there is no TXT record, no CNAME to a TXT record, and no delegated DNS zone serving the selector, the receiver cannot verify the signature.
The closest alternative is NS delegation for _domainkey or for a selector subtree. That hands authority for part of your DNS namespace to another DNS service. It works, but CNAME records are easier to audit for most hosted senders and limit delegation to individual selector names.
Example delegated _domainkey zonedns
_domainkey.example.com. NS ns1.sender-dns.example. _domainkey.example.com. NS ns2.sender-dns.example.
NS delegation is more useful when a platform needs to manage many selectors under the same domain, or when a large organization has a separate DNS workflow for email authentication. For single sender onboarding, CNAME records are usually cleaner. More detail on this pattern is available in DKIM aliasing.
|
|
|
|---|---|---|
CNAME | Yes | Sender hosts keys |
NS delegation | Yes | Many selectors |
No DNS key | No | Never for DKIM |
Options when you do not want a long TXT key
Frequently asked questions
Yes. The selector hostname can be a CNAME that points to a provider-hosted DKIM TXT record. The final DNS target still needs to return a valid public key.
Yes, when DKIM passes and the signing domain has alignment with the visible From domain. DMARC does not require the key to be directly published in your DNS zone.
No. A CNAME cannot coexist with ordinary TXT data at the same hostname. Use a new selector or coordinate the signing migration before replacing an active TXT record. Keep old keys available while messages signed with them are still in transit.
Two selectors let the provider rotate DKIM keys with less risk. One selector can remain active while the other is prepared, changed, or retired.
Check that the final CNAME target returns a usable key and that the message uses the expected selector and signing domain. Confirm signing is enabled, then inspect failures for changes to signed headers or the body, such as a gateway adding a footer after signing.
A DNS administrator must publish the required TXT, CNAME, or delegation records unless a working setup already exists. A provider can sign using its own domain, but that signature does not satisfy DKIM-based DMARC alignment for your unrelated From domain.
