Skip to content
Webmaster Tools
DNS & domainsDNS LookupDKIM record

DKIM record

How a DKIM record publishes your signing key at selector._domainkey: the v=, k= and p= tags, 2048-bit keys split into 255-byte strings, and finding your selector.

What it is

DKIM (DomainKeys Identified Mail, RFC 6376) lets a sending server sign each message with a private key. The matching public key is published in DNS as a TXT record at <selector>._domainkey.<domain>, and receivers use it to check that the signed headers and body weren't changed and that the domain in the signature really authorised it. The selector lets one domain have several keys at once, one per service or per rotation.

google._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5x"
                                                 "...rest of the base64 key...IDAQAB" )

The tags

Tag Meaning
v=DKIM1 Version; optional, but if present it must come first
k= Key type: rsa (the default) or ed25519 (RFC 8463)
p= The public key, base64. An empty p= means the key is revoked
t= Flags: y = testing, s = the signing domain must match exactly, no subdomains
h= Hash algorithms allowed, such as sha256

The signature in each message names the domain (d=example.com) and the selector (s=google), and the receiver looks up google._domainkey.example.com. To find your selector, open a message you sent, view the original headers and read s= from the DKIM-Signature header.

Key size and the 255-byte limit

Use 2048-bit RSA keys; RFC 8301 requires at least 1024 bits, and 1024 is now considered weak. A 2048-bit key is about 400 base64 characters, longer than the 255 bytes a single TXT string can hold. The record then has to be split into several quoted strings inside one TXT record, as above. Receivers join the strings with no separator, so split anywhere in the key but add no spaces or extra quotes inside it. Most DNS dashboards do the split for you when you paste the whole value; some don't, and a paste that gets truncated breaks every signature.

Common setups

  • Google Workspace: generate the key in the Admin console (Gmail, Authenticate email); the default selector is google, and signing starts only after you click Start authentication.
  • Microsoft 365: two CNAMEs, selector1._domainkey and selector2._domainkey, pointing at keys Microsoft hosts and rotates; then enable DKIM signing for the domain.
  • Amazon SES (Easy DKIM): three CNAMEs of the form <token>._domainkey.example.com pointing to <token>.dkim.amazonses.com.
  • Newsletter and transactional services usually give you one or two CNAMEs in the same way, so they can rotate keys without you.

How to check it

The email authentication check looks up the key when you give it the selector, alongside SPF and DMARC. From a terminal:

dig +short TXT google._domainkey.example.com
nslookup -type=TXT google._domainkey.example.com

Common mistakes

  • Wrong name. The record is at selector._domainkey.example.com, not at example.com or _domainkey.example.com. Some dashboards append the domain, so typing the full name gives ...example.com.example.com.
  • Broken key. Spaces, line breaks or a missing chunk in p= make every signature fail.
  • Published but not signing. The key alone does nothing until the sending service is switched on to sign.
  • Removing the old key too early during rotation: mail already in transit is still signed with it. Keep both selectors for a few days.
  • Signing with a vendor's domain. If d= is the vendor's domain, DKIM passes but doesn't align for DMARC. Set up custom-domain signing.