DKIM (DomainKeys Identified Mail, RFC 6376) is an email signature standard. The sending server signs chosen headers and the body with a private key. The receiver fetches the matching public key from DNS and checks that the signature is valid, which proves the signing domain vouched for the message and that the signed content was not altered in transit.
The signature travels in a DKIM-Signature header. Two of its tags point the receiver to the key: d= is the signing domain and s= is the selector. Together they form the DNS name selector._domainkey.domain.
Anatomy of a real key record
We read GitHub's Google Workspace key with dig +short TXT google._domainkey.github.com on 19 October 2026. The key is shortened here:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAj6T5sl/Rwd...KDSiQlhwIDAQAB"
| Tag | Value here | Meaning |
|---|---|---|
| v | DKIM1 | Version, optional but common |
| k | rsa | Key type; ed25519 is the other option (RFC 8463) |
| p | base64 data | The public key. An empty p= means the key is revoked |
The MIIBIjAN prefix is the usual sign of a 2048-bit RSA key. In the live answer the value is split into two quoted strings, because one DNS TXT string holds at most 255 characters. Receivers join them back together. Some DNS panels do this for you and some do not.
GitHub also shows the other common setup. Its s1._domainkey.github.com is a CNAME to a SendGrid host, so SendGrid publishes and rotates that key while GitHub owns the name. Selector names are free text chosen by the sender, which is why no tool can list every DKIM key a domain has. You find them in the s= tag of real message headers, or in each provider's setup screen.
Key size: the RFC 8301 rule
RFC 8301 updated the key rules in 2018. Signers must use RSA keys of at least 1024 bits and should use 2048. Verifiers must not accept signatures made with smaller keys, so a 512-bit or 768-bit key now fails outright. The same RFC retired rsa-sha1 for signing in favour of rsa-sha256.
How it fits with SPF and DMARC
SPF authorises servers by IP address and checks the envelope sender. DKIM authorises the message itself, so it usually survives forwarding, where SPF breaks. Neither one looks at the From header people read. DMARC adds that check: a DKIM pass counts for DMARC only when the d= domain aligns with the From domain. A newsletter tool that signs as d=sendgrid.net passes DKIM but fails DMARC alignment for your brand until you set up a custom signing domain.
Three common mistakes
- Signing with the provider's domain. Many platforms sign with their own
d=until you add their CNAME records. Check thed=value in a received message header, not just "DKIM: pass". - Old 1024-bit keys, or smaller. 1024 is still allowed but is the floor. Rotate to 2048 by publishing a new selector, switching signing to it, then removing the old one after a few days.
- Broken TXT values. Missing quotes, stray spaces inside the key, or a 400-character value pasted as one string all produce "key not found" or "bad signature" results.
Next step
Look up a selector with the free DKIM checker. For canonicalization, header choice, rotation and Ed25519, read the full DKIM guide.