If SPF is a guest list, DKIM is a wax seal. Every email you send gets a cryptographic signature stamped into its headers; receivers fetch your public key from DNS and verify the seal is intact. If the message was tampered with in transit — or never came from you at all — the seal breaks.

Unlike SPF, DKIM survives forwarding. The seal travels with the message, no matter which servers relay it. That’s why receivers weight it heavily, and why Google, Yahoo and Microsoft all require it from bulk senders.

What actually gets signed

Your sending server takes selected headers (From, Subject, Date…) plus a hash of the body, signs them with a private key only it holds, and adds the result as a DKIM-Signature header. The receiver looks up the matching public key in your DNS and checks the math. Pass means two things at once: the message wasn’t modified, and whoever sent it controls the DNS of the signing domain.

Selectors: how one domain holds many keys

Look at a real DKIM-Signature header and you’ll find two tags that matter:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...

d= is the signing domain.
s= is the selector — a label that points at one specific key.

The receiver combines them and queries mail2026._domainkey.yourdomain.com for the public key. Selectors exist so a domain can hold many keys at once: one per provider, one per key rotation, old and new overlapping during a changeover.

Don’t know your selector? Send yourself an email and read the s= tag in the signature header — our Email Header Analyzer pulls it out for you, along with the SPF/DKIM/DMARC verdicts on that message. Once you have the selector, our DKIM Record Checker fetches the published key and tells you what you’re actually working with.

Key size: 1024 bits is on borrowed time

DKIM keys are mostly RSA, and RSA strength is all about length:

512 bits — factorable on rented hardware for pocket money. Was used to forge signed mail from real companies over a decade ago. If you find one of these, treat it as an incident.
1024 bits — the long-standing default, now the floor. Still common because rotating keys is friction, but the industry guidance has moved on, and “we kept the old key because rotating is annoying” is not a sentence you want in a postmortem.
2048 bits — the current standard. Set it and forget it for years.

There’s also Ed25519, a newer, smaller, faster signature scheme the RFC supports — elegant, but receiver support is still uneven, so the practical play in 2026 is RSA-2048, optionally dual-signing with Ed25519.

The catch: you can’t tell key strength by looking at the DNS record — it’s a wall of base64 either way. The DKIM Checker measures the real key strength with WebCrypto, in your browser, and flags anything below 2048.

Generating and rotating keys

Need a key pair? Our DKIM Generator creates one in your browser — the private key never touches our servers, which is exactly how you should treat private keys generally. Publish the public half under a new selector, configure the private half in your sender, and once mail flows with the new signature, delete the old selector’s record.

Rotation cadence: every 6–12 months is the common guidance. The mechanism is painless precisely because selectors let old and new keys coexist during the switch.

The alignment detail that bites later

For DMARC (the policy layer on top), the d= domain in your DKIM signature must match the From: domain your recipient sees. Plenty of providers sign with their domain by default — the seal is valid, but it’s their seal, not yours, and DMARC won’t count it. When you set up any sending tool, do the custom-domain DKIM step. It’s always there, usually under “advanced,” always worth it.

Where does this leave you? Twenty minutes of setup: generate or request a 2048-bit key, publish it under a clean selector, verify with the checker, confirm alignment. Then it’s infrastructure — and you can spend your attention on the part of email that actually needs it: what you write.