Skip to content
Control Plane Labs

DKIM record

Publishes the public key that verifies a domain's cryptographic signature on outbound mail.

Last updated July 27, 2026

Zone-file example

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

Typical uses

  • Letting receivers verify that a message was signed by the sending domain
  • Giving each sending platform its own selector and its own key
  • Rotating keys by publishing a new selector before retiring the old one
  • Providing the DKIM half of DMARC alignment, which survives forwarding

When it breaks, check

  • The record lives at selector._domainkey.example.com, not at the apex
  • A p= value with an inserted space or line break fails verification silently
  • Remove a selector too early and mail still sitting in sender queues fails to verify
  • An empty p= means the key is revoked, which is a valid published state

What the DKIM record does

Every signature carries a selector in its s= tag and a signing domain in d=. Together those name the record to fetch: <selector>._domainkey.<domain>. The selector exists so one domain can run many independent keys at once, which is what makes rotation and multi-vendor sending tractable — the mail provider gets one, the CRM another, and neither needs the other’s private key.

Because the signature travels inside the message, DKIM survives forwarding in a way SPF does not. A mailing list that rewrites the envelope sender breaks SPF outright, but a message whose signed headers arrive untouched still verifies.

TXT record syntax

The RDATA is a TXT string of semicolon-separated tag=value pairs. v=DKIM1 is the version, k= the key type (rsa or ed25519), and p= the base64 public key, which for a 2048-bit RSA key runs past the 255-octet character-string limit and must be published as several quoted chunks joined with nothing between them. Optional tags include t=y for testing mode and h= to restrict hash algorithms. A record whose p= has no value declares the key revoked.

; selector "sel1", split into 255-octet chunks
sel1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvvvvvvvvvvvvvvvvvvvv"
    "vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvIDAQAB" )

; a second selector for a different sending platform
mktg._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq...IDAQAB"

; revoked: empty p=
old._domainkey.example.com.  3600 IN TXT "v=DKIM1; k=rsa; p="

Common uses

Give every sending platform its own selector. It costs one extra record and buys the ability to rotate or revoke one vendor without touching any other, and it makes DMARC aggregate reports legible because you can see which selector signed what. Rotation has the same shape: publish the new selector, switch the signer, wait out the sender queues and TTLs, then blank the old p=. Many receivers refuse keys shorter than 1024 bits outright.

Troubleshooting

Almost every DKIM failure is the key value, not the cryptography. DNS control panels wrap, trim, and re-quote long strings, and one space at a chunk boundary changes the base64 and fails verification with no useful error anywhere. Fetch the record and compare it byte for byte against what your signer generated.

The second failure mode is timing. Mail sits in sender queues for hours, so a selector deleted the moment you cut over strands messages already signed with it. Leave the old record in place until past your longest retry window, then revoke it with an empty p= rather than removing it.

# fetch the key named by a signature's s= and d= tags
dig sel1._domainkey.example.com TXT +short

# strip quoting and whitespace to see the value a verifier reconstructs
dig sel1._domainkey.example.com TXT +short | tr -d '" ' | fold -w 72

# confirm each selector you believe exists still resolves
for s in sel1 mktg old; do
  printf '%s: ' "$s"; dig +short "$s._domainkey.example.com" TXT | head -c 40; echo
done

The defining RFC

DKIM is RFC 6376, an Internet Standard. The _domainkey namespace is section 3.6.2.1, the key record’s tag=value grammar is section 3.6.1, and the signature header it pairs with is section 3.5. Ed25519 signing came later, in RFC 8463. Tag names live in the IANA DKIM parameters registry. Retrieve a selector with the DNS lookup tool.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

Other record types