DKIM Key Generator & Record Builder

Generates a DKIM key pair in your browser and hands you a copy-ready TXT record. The private key is created locally with the Web Crypto API and never touches our servers.

Used to build the full record name. Leave blank and we'll use a placeholder.
Short label (e.g. s1, mail, 2026a). Used for rotation — bump it, don't reuse it.
RSA 2048 is the safe pick. Every receiver verifies it.

How this DKIM key generator works

DKIM (RFC 6376) needs two halves of a key pair. The private half sits on whatever signs your outbound mail. The public half goes into DNS as a TXT record at <selector>._domainkey.<domain>. This page produces both, then hands you a copy-ready record. Once it's published, verify it with the DKIM checker.

Does the private key ever leave my browser?

No. The key pair is generated locally with the Web Crypto API (crypto.subtle.generateKey). No request is made to our servers during generation. Open DevTools, watch the Network tab while you click Generate, and you'll see nothing fire.

Our take: any DKIM generator that posts to a backend is the wrong shape. The private key should never touch a wire it didn't have to.

RSA-2048, RSA-1024 or Ed25519?

RSA-2048 is the safe pick. RFC 8301 raised the floor from 1024 to 2048 bits in 2018, and every receiver in production handles it. RSA-1024 only exists here for legacy gear that still chokes on a 2048-bit modulus — Google has been silently soft-failing 1024-bit signatures for years. RSA-4096 isn't on the list on purpose: the public-key blob gets long enough that the DKIM TXT response can overflow common EDNS0 buffer sizes and fall back to TCP. Plenty of receiver-side resolvers still drop the retry instead of completing it, and the signature reads as missing rather than weak.

Ed25519 (RFC 8463) is smaller, faster, and cryptographically fine. The catch is receiver support, which is still patchy. An Ed25519-only signature can read as no signature at all to receivers that don't understand it.

What to do: pick RSA-2048. If you want Ed25519 anyway, dual-sign — publish an RSA-2048 selector and an Ed25519 selector side by side, and have your platform sign with both.

What should I name the selector?

The selector is just a DNS label. The convention that survives rotation is a short identifier you can increment: 

s1._domainkey.example.com       ← current
s2._domainkey.example.com       ← next rotation
2026a._domainkey.example.com    ← date-stamped variant

Avoid reusing a selector name with a new key. The whole point of selectors is that you can publish the new one, switch your signer over to it, and only retire the old TXT record once nothing in-flight still references it.

My DNS host rejects the value as too long

A single TXT character-string is capped at 255 characters (RFC 1035), and an RSA-2048 public key blows past that. Cloudflare, Google Cloud DNS and Azure split automatically. AWS Route 53 and most BIND-style zones do not. The result panel hands you a pre-split version for that case: 

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..." "...G9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

If your host wants the split form pasted as a single field, the Route 53 / TXT splitter does the same job on any string you paste in.

Where to go next

After publishing, confirm the record with the DKIM checker. If your sender is fronted by a managed provider that publishes its selector as a CNAME, the CNAME checker resolves the chain. Once DKIM is signing, line up alignment with the DMARC checker — DKIM passing in isolation doesn't satisfy a p=reject policy unless the signing domain aligns with the header From. If you're rotating an existing platform key rather than minting a fresh one, the Google Workspace and Microsoft 365 walkthroughs cover the rotation mechanics for each.

Frequently Asked Questions

Common questions about generating a DKIM key pair.

No. Generation happens in your browser through crypto.subtle.generateKey. The private key isn't transmitted, logged, or stored on our side. Open DevTools, switch to the Network tab, and click Generate — no request fires.

If you close the tab without copying the private key, it's gone. Generate a new pair under a new selector rather than trying to recover the old one.

RSA-2048. Every receiver in production verifies it, and it's what RFC 8301 set as the minimum back in 2018.

Ed25519 (RFC 8463) is smaller and faster, but receiver coverage is still uneven. Some receivers treat an Ed25519-only signature as no signature at all. If you want Ed25519, dual-sign: publish an RSA-2048 selector and an Ed25519 selector and let your platform sign with both. Receivers verify whichever one they understand.

RSA-1024 is here only for legacy gear that refuses larger keys. Google has been silently soft-failing 1024-bit signatures for years.

The selector is just a DNS label. Keep it short and lower-case so it's easy to bump. s1, s2, mail, 2026a all work.

To rotate, generate a fresh pair under a new selector, publish the new TXT record, switch your sending platform to sign with the new selector, then delete the old TXT record once you're confident nothing in-flight still references it. Don't reuse a selector with a new key — receivers and any cached signatures will get confused.

A single TXT character-string caps at 255 characters (RFC 1035) and an RSA-2048 public key exceeds that. Cloudflare, Google Cloud DNS and Azure split it for you. Route 53 and BIND-style zones don't.

Use the "Split into 255-character strings" toggle above the Value field, or paste the value into the Route 53 / TXT splitter if your host wants the split form as a single field.

A 4096-bit public-key blob can push the DKIM TXT response past common EDNS0 buffer sizes and force a fallback to TCP. Some receiver-side resolvers still drop the retry instead of completing it, so the signature reads as missing rather than weak. RSA-2048 sits comfortably under the threshold, verifies everywhere, and is the floor every modern receiver expects.