DKIM Record Generator

Paste a public key above to build the record.

What DKIM signs and why selectors exist

DKIM puts a cryptographic signature on outgoing mail. The sending server hashes the body and a chosen set of headers (From is mandatory per RFC 6376, the rest is up to the signer), signs the hash with a private key, and stuffs the result into a DKIM-Signature header. The receiver reads two things out of that header: the domain (d=) and the selector (s=), fetches your public key from DNS at selector._domainkey.domain, and checks the math. Signature valid means the message wasn't altered in transit and the signing domain really vouches for it.

So why the selector indirection? Because one domain rarely has one signer. Your own mail server signs with one key, your newsletter platform with another, the CRM with a third. Each one gets its own selector, its own DNS record, its own key. Selectors are also what makes rotation painless: publish the new key under a fresh selector, switch the signer over, and the old record can sit there until cached mail stops referencing it. Without selectors you'd have one global key and every rotation would be a flag day. Pick boring selector names with a date in them, something like s2026a. You'll thank yourself during the next rotation.

The 255-character TXT gotcha that breaks long keys

Here's the trap this tool exists for. A DNS TXT record holds one or more character strings, and each string maxes out at 255 bytes. That's the protocol, not a vendor quirk. An RSA 2048 public key in base64 runs about 392 characters, so the full record value lands somewhere around 410. Too long for a single string.

The fix is old and standard: publish the value as multiple quoted strings, like "v=DKIM1; k=rsa; p=MIIB..." "...rest...", and resolvers concatenate them back into one logical value. Verifiers see the whole key. The problem is what DNS panels do with your paste. Some split automatically and you never notice. Some throw a vague validation error. The worst ones accept the value and silently cut it at 255 characters, which leaves a truncated key in DNS and a permanent DKIM fail that looks like everything else is fine. If your signatures fail and the record looks "almost right", count the characters of p=. I've lost an afternoon to exactly that, which is why the chunked output above appears automatically whenever the value crosses the limit.

Ed25519 keys dodge the issue entirely. The public key is 32 bytes, 44 characters in base64, and the whole record fits in one short string. One of several reasons people like it.

Key rotation, honestly

Every DKIM guide says "rotate your keys regularly" and most admins quietly never do. Let me be straight about the trade-off. The risk of an old key isn't that RSA 2048 gets cracked, it's that the private key leaks: a decommissioned server nobody wiped, a config backup in the wrong bucket, an employee laptop. A leaked DKIM key lets an attacker sign mail as your domain that passes DMARC. That's a phisher's dream.

The honest schedule: rotate every 6 to 12 months if you can automate it, and immediately when a signer is decommissioned or a key might have leaked. If rotation is manual and painful in your org, I'd rather see you do it once a year reliably than promise quarterly and do it never. The mechanics are easy thanks to selectors: generate the new pair, publish s2026b._domainkey alongside the old record, point the signer at the new key, wait a week or so for in-flight and queued mail to clear, then either delete the old record or, more politely, replace its p= value with an empty one (p= with nothing after it is the RFC 6376 way to say "this key is revoked").

One thing managed providers do for you: Microsoft 365 and Google rotate or manage their default selectors themselves. The keys YOU own are the ones nobody rotates.

Where DKIM fits next to SPF and DMARC

Three mechanisms, three different questions. SPF asks "is this server allowed to send for the envelope domain". DKIM asks "is this exact message signed by the domain it claims". DMARC sits on top and asks the question users actually care about: does any of that match the From address shown in the mail client, and what should happen when it doesn't.

DKIM is arguably the strongest leg of the three because the signature survives forwarding, which SPF famously doesn't. A mailing list or a forwarder re-sends your message from their own server, SPF breaks, DKIM usually holds (unless the list rewrites the body, looking at you, footer-appending listservs). That's why a domain with solid DKIM on every sender can reach p=reject with way less pain than one leaning on SPF alone.

But DKIM by itself blocks nothing. A spoofer just sends unsigned mail, and without a DMARC policy no receiver is obligated to care. The full chain is: DKIM signs, SPF authorizes, DMARC aligns both with the visible From and sets the consequences. Build the record here, then write the policy with the DMARC record generator, and check how the whole setup grades out with the email authentication posture checker.

Frequently asked questions

Should I generate DKIM keys in a browser tool or on the mail server?

On the mail server, if it's production. The private key should be born where it lives, so it never crosses a clipboard or a screen. This tool's generator runs entirely in your browser with WebCrypto and sends nothing anywhere, which makes it fine for labs, classrooms and quick tests, but a server-side openssl or opendkim-genkey is still the grown-up move.

Why does my DNS provider reject or truncate my DKIM record?

Because a single TXT string is capped at 255 characters and an RSA 2048 record value runs around 410. The value has to be published as multiple quoted strings that resolvers concatenate. Some panels split automatically, others need the chunked form this tool outputs, and a few truncate silently, which leaves a broken key in DNS.

What is a DKIM selector and can I name it anything?

The selector is the label before _domainkey in the DNS host name, and it tells verifiers which of your keys signed a given message. Names are mostly free-form DNS labels; pick something dated like s2026a so rotations stay legible. Each signing service gets its own selector and key.

RSA 2048 or Ed25519, which should I pick?

RSA 2048 for anything real, because every verifier on the planet handles k=rsa. Ed25519 (RFC 8463) has shorter keys and a record that fits in one TXT string, but receiver support still isn't universal, so deployments that use it typically dual-sign with both. For a lab, use whichever you're studying.

How do I confirm the record actually works after publishing?

Query the TXT record at selector._domainkey.yourdomain.com and check that v=DKIM1 and the full p= value come back intact, which is what the DKIM lookup tool on this site does. Then send a real message to a mailbox you control and read the Authentication-Results header for dkim=pass.

Does DKIM alone stop someone spoofing my domain?

No. DKIM proves a signed message is authentic, but it doesn't force anyone to reject unsigned mail claiming to be you. That enforcement comes from a DMARC policy that requires alignment between the DKIM domain and the visible From address. DKIM is the evidence, DMARC is the verdict.