DKIM — DomainKeys Identified Mail — puts a cryptographic signature on every outbound email your infrastructure sends. Receiving servers fetch your public key from DNS, verify the signature over the message headers and body, and thereby prove two things: the mail actually came from a signer authorized under your domain, and the message was not altered in transit. DKIM is the second pillar under DMARC, and — because it survives forwarding better than SPF — it's the pillar most modern email programs lean on hardest.

What DKIM signs, exactly

A DKIM signature covers two things: a canonicalized subset of headers you choose, and the message body. The signing MTA computes an RSA (or Ed25519) signature over that data with the private key, base64-encodes it, and attaches a DKIM-Signature header with metadata: the domain (d=), the selector (s=), which headers were signed (h=), the body hash (bh=), the algorithm (a=), and the signature itself (b=).

Receivers fetch the public key at <selector>._domainkey.<domain>, verify the signature, and either pass or fail the message on DKIM. Any modification to a signed header, or any body byte outside the parts covered by canonicalization, breaks the signature.

Where the public key lives

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

The selector — google in this example — is arbitrary. Google Workspace uses google, Mailchimp uses k1, Amazon SES uses a random string. You choose the selector when you generate the key. The public key material sits in the p= tag, base64-encoded, wrapped in quoted 255-character chunks if it's a 2048-bit key.

The v= tag is optional but recommended. k= defaults to rsa; ed25519 is legal but not universally supported yet, so most operators stay on 2048-bit RSA in 2026.

Selectors are the killer feature

DKIM's design gives you one enormous operational win: any domain can publish an unlimited number of DKIM keys simultaneously, each at its own selector. That's what makes zero-downtime rotation possible, and it's how you juggle multiple ESPs on the same domain without any of them stepping on each other.

Rules of thumb:

• Use a selector name that you control (avoid generic s1) so key ownership is obvious at a glance.
• Include a date component: 2026q3, 2026-jul, 202607a. Future-you will thank you.
• Never re-use a retired selector for a new key. Retire and move on.

Zero-downtime rotation with two selectors

Rotate keys quarterly using the standard two-selector dance:

1. Generate a fresh 2048-bit key with a new selector: 2026q3.
2. Publish the new public key at 2026q3._domainkey.yourdomain.com. Wait one TTL (see our propagation guide) for it to be visible everywhere.
3. Switch your MTA or ESP to sign with the new selector. Send mail.
4. Leave the old selector 2026q2 in DNS for at least a week — in-flight mail that hasn't been delivered yet may still verify against it.
5. Delete the old selector's DNS record. Rotation complete.

There is no window during which mail goes unsigned or fails verification. This is why quarterly rotation is a totally reasonable cadence, not the operational burden people imagine.

Key length: why 2048 is the floor

The DKIM RFC allows keys as short as 512 bits. 1024-bit keys were the norm for a decade, and while they're still widely accepted, cryptographers consider them within reach of nation-state-scale adversaries. 2048-bit RSA is the modern minimum. The only reason 1024 persists is that a 2048-bit public key does not fit inside a single 255-character TXT string, and some very old DNS management UIs choke on the multi-string workaround. Modern managed DNS (Cloudflare, Route 53, NS1, Google Cloud DNS) handles this transparently — just paste the value.

Common failure modes

• Body modification in transit. Mailing lists that append "unsubscribe" footers to the body break DKIM. Fix by having the list re-sign with its own DKIM (and lean on ARC downstream).
• Header rewriting. Some antispam appliances rewrite Subject with "[EXTERNAL]" tags. If Subject was in your signed h= list, the signature is now invalid.
• Missing or truncated public key. Copy-paste errors are the #1 cause of "why doesn't my DKIM verify" tickets. Use our DKIM Checker against your published selector before pointing an MTA at it.
• Wrong canonicalization. DKIM defines simple (unchanged) and relaxed (whitespace normalized) canonicalization for both headers and body. Most operators use relaxed/relaxed because forwarders and mail-store gateways love to whitespace-fold.
• Multiple keys at the same selector. DNS won't let you do this, but sometimes people try to publish an old and new key under the same label. Use different selectors.

Testing your setup

# Fetch the published public key
dig +short TXT google._domainkey.yourdomain.com

# See the DKIM-Signature header on outbound mail
# (send a test to check-auth@verifier.port25.com — it will reply with a full auth report)

Where DKIM fits in the bigger picture

SPF authenticates the envelope. DKIM authenticates the content. DMARC binds either one to the visible From: and tells receivers what to do if both fail. Together they form a complete authentication story — but only if all three are correct. Publish DKIM properly, rotate keys quarterly, and you've done the heaviest-lifting part of email authentication.

Related tools: DKIM Checker · DMARC Checker · SPF Checker · MX Lookup