How to implement DKIM without a TXT record?
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. 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.
The important caveat is that DKIM itself still depends on DNS. Verifiers look up a public key at selector._domainkey.example.com. A CNAME does not remove the public key lookup, it delegates it. That is why CNAME-based DKIM is common with mailbox providers, ESPs, CRMs, and marketing platforms. They manage the rotating key, while you keep a short DNS pointer.
- 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.
Flowchart showing DKIM verification following a CNAME to a hosted public key.
Typical CNAME-based DKIM setupdns
s1._domainkey.example.com. CNAME s1.dkim.sender.net. s2._domainkey.example.com. CNAME s2.dkim.sender.net.
In that setup, your DNS zone has only the two CNAME records. The sender's DNS zone contains the final DKIM TXT values. This avoids copy and paste errors, long TXT record splitting issues, and emergency DNS changes when a sender rotates keys.
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
I use DKIM CNAMEs when a third-party sender owns the signing infrastructure and has a stable pattern for delegated keys. That includes many 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.
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.
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.
The most common mistake is thinking a CNAME makes DKIM provider-agnostic. It does not. If you point your selector to one sender, that selector belongs to that sender's signing setup. A different sender needs its own selector and its own DNS record.
|
|
|
|
|---|---|---|---|
Direct key | TXT | Self-managed mail | Manual rotation |
Hosted key | CNAME | Third-party sender | Provider dependency |
Delegated zone | NS | Many selectors | Higher DNS risk |
Common DKIM publication models
Step-by-step implementation
The implementation is simple when the sender gives you the exact selector hostnames and targets. I still treat it like a change that needs verification, because DKIM failures are easy to miss until Gmail, Microsoft, or another receiver starts treating the stream with more suspicion.
- Confirm the signing domain: Make sure the provider signs with your organizational domain or an aligned subdomain, not only the provider's domain.
- Get the selectors: Collect every selector the provider requires, often two records for rotation.
- Publish CNAME records: Add each selector under _domainkey and point it to the provider's target.
- Enable signing: Turn on DKIM in the sender's admin panel only after DNS has resolved.
- 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 aligned DKIM at scale.
Example DKIM CNAME recordsdns
s1._domainkey.example.com. CNAME s1.domainkey.u12345.sender.net. s2._domainkey.example.com. CNAME s2.domainkey.u12345.sender.net.
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, finds a valid v=DKIM1 record, and exposes a usable public key.
Do not put a CNAME and TXT record at the same selector hostname. DNS does not allow a CNAME to coexist with other data at the same name. If a provider asks for a CNAME, remove any old TXT record using that exact selector.
What receivers actually see
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 authentication headers. A passing DKIM result usually shows the signing domain, selector, and result. For DMARC, the key question is alignment: does the DKIM d= domain align with the visible From domain?
Infographic showing From domain, DKIM domain, hosted key, and DMARC alignment.
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 the key was directly published as TXT or reached by CNAME. For troubleshooting, you need to query the selector hostname and inspect the DNS chain.
For DMARC, CNAME-based DKIM is fine when the d= domain aligns with the visible From domain. A perfectly valid DKIM signature can still fail DMARC if it is signed only with the provider's unrelated domain.
CNAME DKIM and 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 DKIM settings with selector CNAME records for a custom domain.
The pattern looks like this: selector hostnames live under your domain, while the target hostnames live under Microsoft's DKIM infrastructure. Their Microsoft DKIM guide documents this CNAME-based setup for custom domains.
Microsoft-style DKIM CNAME patterndns
selector1._domainkey.x.co. CNAME selector1-x-co._domainkey.x.onmicrosoft.com. selector2._domainkey.x.co. CNAME selector2-x-co._domainkey.x.onmicrosoft.com.
The exact target names depend on the tenant and domain, so do not copy a generic example into production. Copy the values from the provider's admin console, then verify DNS before you enable signing.
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.
- Unaligned DKIM: DKIM passes, but the signing domain does not align with the visible From domain.
Cloudflare and other DNS providers can also confuse CNAME setup when proxy settings, flattened CNAME behavior, or UI-specific host fields are involved. If your record appears correct but will not validate, compare the provider's requested hostname with the actual DNS name returned by lookup. The most useful related 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 you see no DKIM-Signature header, the problem is in the sending platform, not the selector DNS.
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 at all, the sender has not signed that message. The separate problem of finding keys without a known selector is covered in find DKIM selector.
How this 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. I have seen domains with perfect selector records but no signed outbound mail, or DKIM passing with a provider domain that does not satisfy DMARC alignment. In both cases, DMARC can rely only on SPF alignment. That creates fragile authentication, especially with forwarding and mailing lists.
DKIM rollout checkpoints
Use these checkpoints before treating a CNAME-based DKIM setup as complete.
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 aligns
Required
The DKIM signing domain aligns with the visible From domain.
Suped helps with this workflow by showing which sources pass SPF, DKIM, and DMARC, which ones are unverified, and which failures need action. That matters more than checking a single DNS record once, because authentication can drift when senders, selectors, and policies change.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
For a broader view, use DMARC monitoring to confirm that the source is not only configured, but consistently passing aligned authentication across real traffic.
I also 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 a part of your DNS namespace to another DNS service. It can work, but I prefer CNAME records for most SaaS senders because they are easier to reason about and have a smaller blast radius.
Example delegated _domainkey zonedns
_domainkey.example.com. NS ns1.sender-dns.net. _domainkey.example.com. NS ns2.sender-dns.net.
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
Views from the trenches
Best practices
Use CNAME records for hosted DKIM when the sender owns signing and key rotation.
Verify both DNS resolution and real message headers before calling DKIM complete.
Keep each provider on its own selector so key changes do not affect other senders.
Common pitfalls
Teams validate the selector but forget to enable DKIM signing in the sender admin.
DNS panels append the root domain, creating selector names that never get queried.
Old TXT records remain at the selector, which conflicts with the new CNAME record.
Expert tips
Check DMARC aggregate data after setup because alignment matters more than DNS alone.
Use two selectors where supported so the sender can rotate keys without downtime.
Document the owner of each selector so future DNS cleanup does not break a sender.
Marketer from Email Geeks says Gmail can react harshly when a message looks unusual, so sender authentication should be checked alongside rendering and content signals.
2025-01-21 - Email Geeks
Marketer from Email Geeks says DKIM without a visible TXT record usually means the selector points through a CNAME to a hosted public key.
2025-01-21 - Email Geeks
The practical answer
Use a DKIM CNAME when your email provider supports hosted DKIM keys. Publish the selector CNAMEs exactly as provided, wait for DNS to resolve, enable signing, send a real message, and verify that DKIM passes with an aligned signing domain.
Do not treat the absence of a TXT record in your own DNS as suspicious by itself. It is normal when the selector is delegated by CNAME. The only hard requirement is that the full DNS chain returns the correct DKIM public key and that your sender signs the mail with the matching private key.
Suped's product is the stronger practical choice for most teams after the record is live because it connects the DNS setup to real authentication outcomes. That includes automated issue detection, steps to fix, DMARC monitoring, alerts, SPF and DKIM visibility, and deliverability signals in one place.
