DKIM CNAME vs TXT record: what's the difference?

When you turn on DKIM, one provider asks you for a TXT record full of random-looking characters, and another asks for two or three CNAME records that point somewhere else. Both are correct. They are two ways of publishing the same thing, a DKIM public key, and the choice mostly decides who looks after that key. This guide explains how each works, which common providers use which, and the mistakes that break each type.

What is the difference between a DKIM TXT record and a CNAME record?

A DKIM TXT record holds the public key directly in your DNS zone, while a DKIM CNAME record is an alias that sends receivers to a name your email provider controls, where the provider publishes that key as a TXT record. The receiver ends up reading the same kind of key either way.

Some quick definitions:

• DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. The sending service signs with a private key, and receivers check it with a public key published in DNS. Our guide on what DKIM is covers the full process.
• Selector: a label that lets one domain have several keys. It appears as s= in the DKIM-Signature header. The key lives at selector._domainkey.yourdomain.
• TXT record: a DNS record that holds free text, here a string like v=DKIM1; k=rsa; p=MIIBIjANBg....
• CNAME record: a DNS alias. It says "this name is really that other name; ask there instead."

How does a receiver find a DKIM key through a CNAME?

A receiver finds a DKIM key through a CNAME by asking DNS for the TXT record at the selector name, and DNS itself follows the alias to the provider's name and returns the TXT key found there. The receiver does nothing special. It just asks for TXT and gets an answer.

RFC 6376, the DKIM standard, only defines TXT for keys: section 3.6.2.2 says the only query type defined in the base specification is txt, "indicating the use of a TXT RR", and section 3.6.2.1 places all DKIM keys in a subdomain named _domainkey. It says nothing about CNAMEs because it doesn't need to. DNS handles aliases for every record type. RFC 1034, section 3.6.2 says that when a name server finds a CNAME instead of the requested record, it "restarts the query at the domain name specified in the data field of the CNAME record". Section 5.2.2 adds that "in most cases a resolver simply restarts the query at the new name when it encounters a CNAME."

Here is what that looks like for an illustrative Microsoft 365 domain:

$ dig TXT selector1._domainkey.example.com +noall +answer
selector1._domainkey.example.com.  3600 IN CNAME selector1-example-com._domainkey.contoso.n-v1.dkim.mail.microsoft.
selector1-example-com._domainkey.contoso.n-v1.dkim.mail.microsoft. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

The first line is your CNAME. The second is the key Microsoft publishes. The signature check then works exactly as it would with a TXT record in your own zone. RFC 6376 section 3.1 even anticipates this, noting that selectors can be used "to allow delegation of a portion of the selector namespace."

Which email providers use CNAME and which use TXT for DKIM?

Microsoft 365, Amazon SES (Easy DKIM) and SendGrid (with automated security on) use CNAME records, while Google Workspace, Amazon SES BYODKIM and SendGrid with automated security off use TXT records. The table summarizes each provider's documentation at the time of writing (November 2026). Always copy the exact values from your own admin console, because tokens and host names are unique to each account.

The details behind that table:

• Microsoft 365. Microsoft Learn says the public keys "are stored in DNS records for the signing domain (CNAME records in Microsoft 365; other email systems might use TXT records)". Two key pairs are generated; one selector is active and "the other selector is inactive. It's activated and used only after any future DKIM key rotation." The private keys "are inaccessible" to you. After a manual rotation, Microsoft says "it takes four days (96 hours) for the new private key to start signing messages." Microsoft-specific errors are covered in the Microsoft 365 DKIM CNAME error guide, and our Microsoft 365 platform page shows how inbound filtering sits in front of the same tenant.
• Google Workspace. Google's Set up DKIM page says "the record type is TXT" and gives google._domainkey as the example host. You generate the key under Menu > Apps > Google Workspace > Gmail > Authenticate email, and "it can take up to 48 hours for DKIM authentication to start working."
• Amazon SES. For Easy DKIM, the SES guide tells you to "copy the three CNAME records" and says each value is "the DKIM token followed by a hosted zone domain (for example, token.dkim.us-west-2.amazonses.com)". With BYODKIM you generate your own key pair and publish the public key at your chosen selector.
• SendGrid. Twilio's documentation shows s1._domainkey.example.com and s2._domainkey.example.com as CNAMEs to SendGrid hosts when automated security is on. When it is off, you publish TXT records for SPF, DKIM and DMARC plus an MX record, and Twilio says you need to update those TXT records whenever you change your email configuration.

Our DKIM records by provider pages list the records for many more services.

Is a DKIM CNAME less secure than a TXT record?

A DKIM CNAME is not less secure for verification: receivers check the signature against the key the CNAME leads to, using the same cryptography as a key in your own zone. What changes is control and dependency. With a CNAME, you trust the provider to protect its zone and the private key, which it holds anyway because it signs your mail.

There are three real trade-offs:

1. Rotation is easier with a CNAME. The provider can publish a new key at the target name and switch signing without asking you for anything. With a TXT key, rotation means a DNS change every time. Our DKIM key rotation guide covers both cases.
2. Visibility is better with TXT. You can read the key and its length directly in your zone. With a CNAME you have to follow the alias, which tools such as the DKIM Checker do for you.
3. Leaving a provider is riskier with a CNAME. A CNAME to a service you've cancelled is a dangling record. Whether someone else could claim that target depends on the provider. The safe rule is simple: when you stop using a sender, delete its DKIM CNAMEs. Our guide to dangling DNS and subdomain takeover explains how to audit them.

For domains that never send mail, publish neither. Microsoft says parked domains shouldn't have DKIM records, because "the lack of a DKIM record ... prevents DKIM validation of forged domains." Protect those with SPF -all and DMARC p=reject instead, as in protecting parked domains.

Can I use a TXT record instead of the CNAME my provider gives me?

You can't safely swap a provider's DKIM CNAME for a TXT record unless the provider documents a TXT option, because the provider keeps the private key and expects to change the public key on its side. If you copy today's key into your own TXT record, it follows that signatures keep passing only until the provider rotates. After that, your copy no longer matches the key the provider signs with, and DKIM fails.

Some providers offer both methods officially, and then the choice is yours:

• Amazon SES offers Easy DKIM (CNAME, Amazon-managed key) or BYODKIM (TXT, your key).
• SendGrid offers automated security on (CNAMEs) or off (TXT and MX records you maintain).

Choose TXT when your DNS host can't handle CNAMEs at underscore names (Twilio says "if your DNS provider doesn't accept underscores in CNAME records, you can't use Automated Security"), when policy requires you to hold your own keys, or when you need to read the key in your own zone. Choose CNAME in every other case. It removes the 255-character splitting problem for 2048-bit keys, explained in DKIM 2048-bit key too long for a TXT record, and it lets rotation happen without you.

Why isn't my DKIM CNAME record working?

A DKIM CNAME usually fails for one of a few reasons: another record already exists at the same name, the host name has your domain twice, the target was retyped with an error, the record is in a DNS zone your name servers don't use, or a proxy is answering in place of the alias.

• A TXT and a CNAME at the same selector. RFC 1034 says "if a CNAME RR is present at a node, no other data should be present." Delete the old TXT key first.
• A doubled domain. Typing selector1._domainkey.example.com into a host field that appends the domain creates selector1._domainkey.example.com.example.com. Enter only selector1._domainkey. Amazon's SES troubleshooting page gives the same advice: "make sure that your provider didn't automatically append your domain name."
• An extra underscore. Amazon shows abc123._domainkey.domain.com as correct and _abc123._domainkey.domain.com as incorrect. Only _domainkey starts with an underscore.
• A retyped target. Copy and paste the value. Dashes, dots and partition letters are easy to get wrong.
• Cloudflare proxy turned on. Cloudflare says "proxied CNAME records are flattened by default, as they return Cloudflare anycast IPs," and that it may warn about or block proxying records used "for DKIM (email authentication) validation." Set DKIM CNAMEs to DNS only.
• Waiting too little. Microsoft says detection takes "a few minutes (or possibly longer)", Google allows up to 48 hours, and Amazon up to 72 hours.

How do I check whether my DKIM record is a CNAME or TXT?

To check your DKIM record type, find the selector in a message you sent, then query that selector name in DNS and look at the first record type in the answer.

1. Send a test message from the service to an outside mailbox and open the headers. Find DKIM-Signature and note s= (the selector) and d= (the domain). How to find a DKIM selector shows where to look in each mail app.
2. Query the name s._domainkey.d with dig TXT selector1._domainkey.example.com +noall +answer, or nslookup -type=TXT on Windows.
3. Read the answer. If the first line says CNAME, your record is an alias and the next line shows the provider's TXT key. If it says TXT directly, the key is in your zone.
4. Check the key. The DKIM Checker follows CNAMEs, shows the key length and flags a missing or empty p= value.
5. Confirm signing works. Paste the headers into the Email Header Analyzer and look for dkim=pass with a header.d= domain that matches your From domain, which is what DMARC needs. How to check if an email passed SPF, DKIM and DMARC explains the result.

Next steps

• List every service that sends as your domain and note whether each uses a DKIM CNAME or TXT record. That inventory makes rotation and offboarding far easier.
• Delete DKIM CNAMEs for any provider you no longer use.
• If you're setting up the two big platforms, follow DKIM setup for Microsoft 365 and Google Workspace, then check the result with the Microsoft 365 & Google Workspace DNS Setup Checker.
• If you run Microsoft 365 or Google Workspace behind an inbound filter, the setup guides for Microsoft 365 and Google Workspace explain how iBlockSpam's inbound filtering works with each platform. Inbound filtering doesn't change your outbound DKIM records.

Browse our other SPF, DKIM and DMARC guides.