What Is a DKIM Record? Format, Examples and How to Check It

Introduction

DKIM is the part of email authentication that survives forwarding, proves a message was not altered in transit, and is often the only way a third-party sender can pass DMARC for your domain. All of that depends on one DNS record most people never look at.

This guide explains what a DKIM record is, what each part of it means, what real records look like for the common providers, and how to do a DKIM lookup to check yours.

What Is a DKIM Record?

DKIM (DomainKeys Identified Mail, RFC 6376) works with a key pair:

• Your sending service keeps a private key and uses it to sign every outgoing message
• You publish the matching public key in DNS, in the DKIM record
• The receiving server fetches the public key and checks the signature

If the signature verifies, the receiver knows two things: the message was signed by someone holding the private key for your domain, and the signed headers and body were not changed after signing.

The DKIM record is that public key, published as a TXT record.

Where the DKIM Record Lives

A DKIM record is not published on your domain itself. It sits under a name built from a selector:

<selector>._domainkey.<domain>

For a domain example.com using Google Workspace, whose default selector is google:

google._domainkey.example.com

The selector lets one domain have several keys at once: one per sending service, or an old and a new key during rotation. Each service tells you which selector it uses.

Anatomy of a DKIM Record

A typical DKIM record looks like this (the key is shortened):

google._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5f...IDAQAB"

It is a list of tag=value pairs separated by semicolons.

Tag	Required	Meaning
v	Recommended	Version. If present, must be DKIM1 and come first
k	No	Key type. rsa (default) or ed25519 (RFC 8463)
p	Yes	The public key, base64-encoded. Empty means the key is revoked
h	No	Accepted hash algorithms, for example sha256
t	No	Flags. y = testing mode, s = strict domain matching
s	No	Service type. email or * (default)
n	No	Notes for humans; ignored by receivers

In practice, almost every record you see is v=DKIM1; k=rsa; p=.... The interesting part is p.

t=y deserves a warning. It tells receivers the domain is testing DKIM. Some treat signatures from a testing key less strictly, others ignore the flag. Providers sometimes leave it in their default records; remove it once DKIM works.

The Other Half: the DKIM-Signature Header

The record is only half of DKIM. Every signed message carries a DKIM-Signature header that tells the receiver which record to fetch:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=google;
    t=1761868800; h=from:to:subject:date:message-id;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=Ht6LVd3sL...

Tag	Meaning
d=	Signing domain. The receiver looks up the key under this domain
s=	Selector. Combined with d=, gives google._domainkey.example.com
a=	Algorithm, usually rsa-sha256
c=	Canonicalization for headers/body. relaxed/relaxed tolerates whitespace changes
h=	The headers covered by the signature
bh=	Hash of the body
b=	The signature itself

The d= domain matters for DMARC. A signature with d=esp-provider.net can be perfectly valid and still not help your DMARC result, because it does not align with example.com in the From address. For DMARC, you want the signature to carry your own domain.

DKIM Record Examples

TXT record published by you

Google Workspace generates a key and shows you a TXT value to publish:

Name:   google._domainkey
Type:   TXT
Value:  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5f...IDAQAB

You own the record, so key rotation means generating a new key and updating DNS yourself.

CNAME delegated to the provider

Most email platforms ask for CNAME records instead. The CNAME points to a TXT record the provider hosts, so they can rotate keys without asking you:

Name:   s1._domainkey.example.com
Type:   CNAME
Value:  s1.domainkey.u1234567.wl123.sendgrid.net

Microsoft 365 uses two CNAMEs, selector1._domainkey and selector2._domainkey, so it can rotate between them. Amazon SES Easy DKIM uses three CNAMEs with random selectors. The exact values come from each provider's admin panel; copy them from there, not from a blog post.

The Email Services Directory lists the selector and setup steps for the common providers, and the DKIM Setup Guide walks through publishing the record at your DNS host.

A revoked key

To revoke a key, keep the record but empty p:

v=DKIM1; p=

Receivers then fail any signature made with that selector. This is cleaner than deleting the record, which looks like a misconfiguration.

How to Do a DKIM Lookup

1. Find the selector

You cannot list a domain's DKIM selectors from DNS. Get the selector from a message you sent: open the headers, find DKIM-Signature, and read s= and d=.

The Email Header Analyzer also helps here: paste the headers and it shows whether DKIM passed for that message, next to the SPF and DMARC results.

2. Query DNS

dig +short TXT google._domainkey.example.com

For a CNAME setup, check both the CNAME and the record it points to:

dig +short CNAME s1._domainkey.example.com
dig +short TXT s1._domainkey.example.com

On Windows:

nslookup -type=TXT google._domainkey.example.com

If you get nothing back, see DKIM Selector Not Found.

3. Check the record

The DKIM Checker fetches the record for a domain and selector, decodes the key and reports its type and length, so you can see at a glance whether it is a valid 2048-bit key.

Common DKIM Record Problems

The domain is doubled. Many DNS panels add your domain to the name automatically. Entering google._domainkey.example.com creates google._domainkey.example.com.example.com. Enter only google._domainkey.

The key is broken across strings. A 2048-bit key is longer than the 255-character limit for a single TXT string, so it must be split into several quoted strings. Some panels do this for you; others need you to paste it as-is. Spaces or line breaks added inside the key break it.

The key is truncated. Copying from a narrow admin panel sometimes cuts the end of p=. A valid RSA key from most providers ends in IDAQAB.

The key is too short. Keys under 1024 bits are considered insecure. Use 2048-bit RSA, as RFC 8301 recommends.

DKIM was never switched on. Publishing the record is not enough with some providers; Microsoft 365, for example, needs signing enabled after the CNAMEs are in place. The record exists but no message is signed with it.

The signature verifies but DMARC still fails. The message is signed with the provider's domain (d=esp-provider.net), not yours. Set up custom DKIM for your domain in the provider's settings. DKIM Signature Invalid and DMARC Alignment Failed cover the variations.

Rotating DKIM Keys

Keys should not live forever. A safe rotation with selectors looks like this:

1. Publish a new key under a new selector (google2._domainkey, for example)
2. Switch your sending service to sign with the new selector
3. Wait several days, so messages still in transit can be verified with the old key
4. Revoke the old key with an empty p=

Providers that use CNAME delegation do all of this for you.

Checklist

• Every service that sends as your domain signs with DKIM
• Each signature uses d= with your domain, not the provider's
• Records resolve at selector._domainkey.yourdomain
• Keys are 2048-bit RSA
• t=y is removed once DKIM works
• Old keys are revoked, not left active

Next Steps

1. Look up and decode a DKIM record: DKIM Checker →
2. Publish a record at your DNS host: DKIM Setup Guide →
3. Find the selector in a real message: Email Header Analyzer →
4. See which senders sign with your domain: Start free → — DMARC aggregate reports show DKIM results and signing domains per source, so you can tell which services still sign with their own domain.

---

Related Articles:

• SPF, DKIM, and DMARC: The Complete Guide
• DKIM Selector Not Found: Causes and Fixes
• SPF Record Syntax Explained, With Examples