Defaults.Exposed

Defaults.Exposed › Setup walkthroughs › DKIM › Cloudflare

Set up DKIM on Cloudflare

Cloudflare is one of the two places this job touches, and it is the second one. The key is made somewhere else, by whoever runs your mailboxes, and Cloudflare’s part is to publish it where receiving mail servers will look. Two things about this particular DNS (Domain Name System) screen decide whether that works: what goes in the Name field, and, for a CNAME (Canonical Name), whether the cloud beside the row is orange or grey.

Cloudflare publishes, your mail platform signs

Your mail platform, whichever one it is, generates a key pair inside its own admin console. It keeps the private half and signs every outgoing message with it. What reaches you is the public half plus a short label called a selector. When a receiving server gets one of your messages it reads that selector from the DKIM-Signature header, queries <selector>._domainkey.yourdomain.com, and tests the signature against the key that comes back.

Cloudflare publishes exactly the row you type and adds nothing of its own beyond appending the domain to the Name field. It does not generate DKIM (DomainKeys Identified Mail) keys, does not hold a private key for your domain, and cannot rotate one. Cloudflare does touch mail in one narrow sense: Email Routing forwards messages arriving at your domain on to another mailbox. Forwarding is not sending, no message leaves signed as you on the back of it, and so Email Routing issues no DKIM key of its own. Whichever platform sends your mail is the one holding the key you are about to publish. The DKIM guide covers the signing side in full.

The two shapes the value can take

A TXT (Text) record is the common case. Its value opens v=DKIM1; k=rsa; p= and continues with hundreds of characters of base64, no spaces anywhere in it, and that p= tag carries the actual key. Cloudflare splits a long value into segments internally when it stores it; that is ordinary handling for long DNS strings and receivers reassemble it without difficulty. What matters is that nothing is truncated on the way in.

A CNAME is the other case, and Microsoft 365 is the platform that most often hands a Cloudflare customer one. The name is still <selector>._domainkey, but the content is a hostname on the platform’s own servers that holds the key on your behalf, which is what lets the platform rotate keys without you logging in here again. Publish whichever type you were given. Turning a CNAME target into a TXT value puts a hostname where the receiver expects a key, and the record will never verify.

The selector itself is exact. Receivers build the lookup from the s= tag in the signature, so selector1 and selector2 point at two different keys, and google and google1 are not interchangeable. Copy it from the platform’s page rather than retyping it.

Is Cloudflare actually answering for this domain?

A DKIM record only counts where the domain’s nameservers point. Open the domain in Cloudflare and look at the Overview page, which states whether Cloudflare is active for it. If the nameservers at your registrar still point somewhere else, the record has to go to that provider instead, because nothing added here will be read.

This is worth thirty seconds, because registrar and DNS host are separate roles and a domain can sit in a Cloudflare account without the nameservers ever having been switched over. Cloudflare answers DNS for 52,173,900 domains in the October 2026 census, 15.98% of the domains that have nameservers, so it is a common place for the record to belong. The Overview page is what settles it for yours.

Add the record in Cloudflare

Copy both pieces from the platform’s DKIM or email authentication page and keep that tab open until the check at the end passes. Laid out the way Cloudflare expects it, the record looks like this:

google._domainkey     v=DKIM1; k=rsa; p=<the long public key string the mail provider issued>

Type takes TXT for most DKIM keys, or CNAME when the mail provider specifies it, such as Microsoft 365. The Name field takes the selector part alone, for example google._domainkey or selector1._domainkey, because Cloudflare appends the domain automatically, so typing the full host such as selector1._domainkey.yourdomain.com produces a doubled, broken host. The Content field takes the key value pasted exactly as the provider gave it, or the target host for a CNAME entry. TTL (Time to Live) stays on Auto unless you have a reason to set it yourself.

  1. Sign in to Cloudflare and select the domain from the account’s domain list.
  2. In the left-hand menu, open the DNS section, labelled DNS / Records.
  3. Click Add record to start a new entry.
  4. Set Type to TXT for most DKIM keys, or to CNAME only when the mail provider specifically says so.
  5. In the Name field, enter only the selector part, such as google._domainkey or selector1._domainkey, and leave the domain off the end.
  6. In the Content field, paste the long key value exactly as the mail provider gave it, or the target host for a CNAME record.
  7. For a CNAME record, set the proxy status toggle to the grey cloud, DNS only, rather than the orange proxied cloud.
  8. Click Save to publish the record.

Compare the last dozen characters of what you pasted against the platform’s page before you save. A copy that stopped early looks perfectly healthy in the Cloudflare row list and will never verify.

The grey cloud, and three other traps here

The same DNS / Records screen holds your SPF record, which most platforms ask for in the same sitting. That is a separate TXT row at Name @, so keep the two apart.

Save, wait, then check

Changes at Cloudflare are usually readable within minutes, though resolvers elsewhere can hold an older answer for up to a couple of hours, so a check run immediately after saving can report nothing while the record is fine. The saved row appears on the domain’s DNS / Records page alongside its other entries.

Give it some time, then run the free scan against your domain. It performs the selector lookup exactly as a receiving mail server performs it and reports what came back.

How the scan grades this record: the DKIM check, with its pass and fail rules and how many domains pass it.

A second check covers the mail side. Send a message from the domain to an address you can read, then open its Authentication-Results header. dkim=pass with your domain in header.d= means the signature verified against the key now sitting in Cloudflare.

Reading a failure

If the scan finds nothing while the row is visibly there, work through it in order. Check the Name field for the doubled host first, since that is the failure this console produces most often. Check the selector spelling against the platform’s page second. Check that the nameservers really point at Cloudflare third. If the record is a CNAME, check the cloud is grey. Then look at the tail of the value for a truncated paste.

One more possibility can look like a failure when your record is fine: how checking works. There is no way to list the DKIM records on a domain, so any checker, this one included, has to ask for selectors by name and can only ask for the ones it knows to try. A key under a selector the checker doesn’t try is invisible to it, so this scan records that case as not determinable, never as absent. The census has the same limit: of the 76,563,365 domains where it could run the DKIM check, it found a key at a known selector on 38,666,798 (50.5%).

If you are not sure which selector is live, finding your DKIM selector shows how to read the s= tag out of the headers of a message you have already sent, which is the authoritative answer for your domain.

Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.