Back to Learning Center Email Authentication

What does a DKIM record look like?

By Dominic LandryAugust 11, 202610 min read

Ask AI to explain

In brief

A DKIM record is a DNS TXT entry at selector._domainkey.yourdomain.com with a v=DKIM1; k=rsa; p=... tag list. See a worked example and how to check yours.

A DKIM record is a DNS TXT resource record published at a selector-based hostname, typically selector._domainkey.yourdomain.com. Its value is a short tag=value list defined by RFC 6376: it starts with v=DKIM1, names a key type with k= (usually rsa), and carries a base64-encoded public key with p=. Microsoft 365 is the main documented exception: it publishes two rotating CNAME records instead of a TXT record holding the key directly.

At a glance

Quick takeaways

A DKIM record is a DNS TXT resource record (CNAME for Microsoft 365 custom domains) at a name built from a selector plus _domainkey plus the domain.
Its value is a tag=value list defined by RFC 6376, and it always starts with v=DKIM1.
k= names the key type, rsa by default, and p= carries the required base64-encoded public key.
The selector, the part of the name before ._domainkey, lets one domain publish a separate key for every sending service it uses at the same time.
Microsoft 365 delegates key storage and rotation to its own DNS zone through CNAME records rather than publishing the key in a TXT record.
The selector name and public key are generated by whichever system signs your mail, never typed in by hand.

How a DKIM record works

RFC 6376 defines DKIM as a signature-based email authentication method, and DKIM covers how the signing and verification process works end to end. A sending system signs outgoing mail with a private key and adds a DKIM-Signature header to the message. The receiving system recovers the matching public key from DNS and uses it to verify that signature.

The record name and the record value answer two different questions. The name tells a verifier where to fetch a key. The value describes the key it finds there.

The selector identifies a particular DKIM key

That public key lives inside the _domainkey namespace RFC 6376 reserves for DKIM key records. The full record name follows this pattern: ._domainkey.. The selector is the first label in that name, a short label chosen by whichever system signs the mail, and it also appears in the s= tag of the DKIM-Signature header on outgoing messages, so a verifier knows exactly which key record to fetch. Google Workspace Admin Help confirms this pattern for its own setup: the DNS record type is TXT, the host name is built from a prefix selector plus ._domainkey, and the value starts with v=DKIM1.

A signer using the selector selector1 for yourdomain.com therefore sends every verifier to one exact DNS owner:

Technical exampletext

selector1._domainkey.yourdomain.com

The selector is not a fixed DKIM keyword. It is generated by the system that manages the signing key, which is why one provider's selector, CNAME target, or public-key value is never safe to reuse for another provider or domain. It is also what lets a single domain hold several live DKIM keys at once, one for each sending system and one for each key in a rotation.

The record value carries the public-key information

For most providers, that DNS record is a TXT resource record whose value is a tag=value list, the textual representation RFC 6376 specifies for the key record. Four tags do most of the work:

v= states the record version, normally DKIM1.
k= names the key type. RFC 6376 defaults this to rsa when the tag is absent.
p= carries the public key itself, base64-encoded. RFC 6376 requires this tag; an empty p= value signals a revoked key.
s= and t= are optional. s= restricts which service the key applies to, and t= can flag testing mode (t=y) or restrict the key to the exact signing domain (t=s).

DKIM record anatomy diagram — Source: Palisade.

Only the public half of the key pair belongs in that value. The private key stays inside the sending system, so a p= value is public-key material rather than a password, an API token, or anything that needs protecting. RFC 8301 sets the current cryptographic floor for it: signers should use RSA keys of at least 1024 bits, and the same update permits ed25519 keys as an alternative to RSA.

Not every provider publishes the key in a TXT record directly. Microsoft Learn's DKIM setup guide documents that Microsoft 365 uses CNAME records instead: each DKIM selector points to a hostname inside Microsoft's own dkim.mail.microsoft zone, and Microsoft manages key rotation on its side. The same page shows what a TXT-based record looks like on other systems for comparison, v=DKIM1; k=rsa; p=MIGfMA0GCS..., and states that if a TXT record shows up where Microsoft 365 expects a CNAME, the domain's DKIM status stays CnameMissing until the TXT record is deleted and the correct CNAME is published.

When the record format changes

A domain rarely has just one DKIM record. Because the selector is part of the record name, one domain can publish a separate key for every sending service it uses at the same time, Google Workspace, a marketing platform, a support desk, each with its own selector and its own _domainkey record. Nothing about the DNS TXT record type limits a domain to a single key.

Selectors also change over time through key rotation. Microsoft's DKIM documentation describes a two-selector rotation model: selector1._domainkey and selector2._domainkey both exist for a domain, but only one signs mail at a time. When Microsoft rotates the key, the inactive selector takes over and the previous one goes dark, a process the same documentation says takes about four days to complete. A DKIM lookup taken mid-rotation can show two valid-looking records for one domain, which is expected rather than a misconfiguration.

Subdomains used for services outside your direct control, a bulk mailer sending as marketing.yourdomain.com, for example, get their own DKIM record at their own selector rather than inheriting the parent domain's record. If that record is missing entirely, what to do when no DKIM record is found covers the diagnostic path from there.

Worked example of a DKIM record

The illustrative record below shows the shape a TXT-based DKIM record takes once a provider has generated the key pair. It is a structural example only, built with the example domain yourdomain.com.

Technical exampletext

selector1._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7...TRUNCATED...QIDAQAB"

Do not publish this exact string. The selector name and the public key are generated per domain by whichever system signs your mail (Google Workspace, Microsoft 365, or your ESP). Get the real values from that provider's admin console, not from an example.

Reading it left to right: selector1._domainkey.yourdomain.com is the full record name, built from the selector the sending system chose. IN TXT is the DNS record type. The quoted value is the tag=value list: v=DKIM1 marks it as a DKIM key record, k=rsa states the key type, and p= holds the base64-encoded public key a verifier uses to check the signature on your outgoing mail. If your DNS host limits TXT record length, the key value may need to be split across multiple quoted strings; your provider's setup instructions should say when that applies.

How to find and check the record for your domain

Start with the selector, not the DNS lookup. If you already send mail through the domain, open a message you sent to an external recipient and view its full headers. The s= value in the DKIM-Signature header is the exact selector your system is using right now, a value both Google's DKIM setup guidance and Microsoft's DKIM setup guidance point to for the same reason.

If you manage the sending system directly, the admin console usually shows the current selector and record value without needing to inspect headers at all: Google Workspace shows it under Admin console > Apps > Google Workspace > Gmail > Authenticate email, and Microsoft 365 shows it on the DKIM tab of the Defender portal's email authentication settings page.

Once you have the selector, confirm what DNS actually publishes with a DKIM record checker. A lookup against ._domainkey. shows whether a record resolves at all, and interpreting the tag values a DKIM checker returns walks through what a correctly formatted result looks like compared to a broken one. DKIM sits alongside SPF and DMARC as one of the three protocols behind email authentication; a published DKIM record confirms your public key is available, not that DMARC alignment or delivery is also working.

Check the DKIM record your domain currently publishes

The examples above use example values because a real selector and public key are specific to your domain and your sending provider. Before troubleshooting further, run your own domain through a checker to see the actual record DNS returns and compare its tags against what your provider's setup page expects.

Check the DKIM record

A DNS lookup confirms what is published, not whether your mail server is signing outgoing messages with that exact key or whether every service sending on your domain has its own correctly configured selector.

Evidence

Sources and further reading

Questions readers ask

Frequently asked questions

Where do I find my DKIM record?

A DKIM record lives in your domain's public DNS at ._domainkey., not in a single admin panel. Find your selector first, either in the s= tag of the DKIM-Signature header on a message you sent, or in your provider's admin console (Google Workspace shows it under Authenticate email; Microsoft 365 shows it on the DKIM tab of the Defender portal), then look up that exact name with a DKIM record checker.

What is an example of a DKIM format?

A typical TXT-based DKIM record value looks like v=DKIM1; k=rsa; p= followed by a base64-encoded public key, the tag=value syntax RFC 6376 defines. Microsoft 365 is a documented exception: instead of a TXT record holding the key, it publishes a CNAME record pointing to a hostname inside Microsoft's own DKIM zone, as shown in Microsoft's DKIM setup guide.

How do I write a DKIM record?

You do not write the public key by hand. The system that signs your outgoing mail, whether that is Google Workspace, Microsoft 365, or another sending platform, generates the key pair and gives you the exact selector name and record value to publish at your DNS host. Your job is limited to creating the DNS record (TXT for most providers, CNAME for Microsoft 365 custom domains) with those exact values, as both Google's and Microsoft's setup documentation describe.

What kind of record is a DKIM record?

A DKIM record is normally a DNS TXT resource record, the format RFC 6376 specifies for storing the public key. Microsoft 365 is a documented exception for custom domains, where the record type is CNAME instead, delegating key storage and rotation to Microsoft's own DNS zone rather than publishing the key directly.

What is a valid DKIM record example?

A valid TXT-based record pairs a selector-scoped hostname such as selector1._domainkey.yourdomain.com with a value that opens v=DKIM1; k=rsa; p= and continues with the sender's own base64 public key. Well formed is not the same as working, though. The record verifies signatures only when that published public key matches the private key the sending system signs with, so both the selector and the key have to come from that system rather than from any example.

How do I set a DKIM record in DNS?

Use the record type and the exact hostname your sending service supplies. Publish a TXT record when the service gives you a DKIM tag=value string, and publish a CNAME when it gives you a CNAME target, without converting either one into the other. Then confirm three things separately: that DNS resolves the record, that the sending service reports the domain as verified, and that a message sent through the production path carries the expected signature.