Skip to content
Email Delivery Platform
Talk to engineering

/ Free Tools — DKIM Key Generator

Your private key, born in your browser.

Generate an RSA or Ed25519 DKIM key pair with the Web Crypto API, entirely on this page — the private key never leaves your browser and no request is made. Get the private key and the exact DNS record, then watch a live demo sign, verify, and break to prove what DKIM protects.

Request infrastructure review How signing works

Generated locally with the Web Crypto API. The private key never leaves your browser — watch the network tab, no request is made.

/ What this does

DKIM works with a key pair: a private key that signs your outgoing mail and a matching public key you publish in DNS so receivers can verify the signature. This tool generates that pair with the Web Crypto API entirely in your browser — RSA-2048, RSA-4096, or Ed25519 — so the private key is created and stays on this page and no request is ever made. You get the private key to load into your mail server and the exact DNS record to publish, and then a live demonstration signs a sample message, verifies it against the public key, and breaks the signature when you tamper with the text — the clearest way to see what DKIM actually protects.

Because generation is local, this is a privacy-first alternative to server-side generators that necessarily see your key. For a production server the most defensive practice is still to generate on the server itself, and the tool says so plainly rather than pretending otherwise — but for testing, staging, learning, and dual-signing setups, generating here is both safe and fast. The output links straight to the DKIM checker so you can confirm the published record once it's live.

  • Never transmitted

    The private key is generated with the Web Crypto API and stays in the page. No key, message, or domain is sent to us — verifiable in your network tab.

  • RSA + Ed25519

    RSA-2048 for universal support, RSA-4096 for strength, Ed25519 for the modern profile — generate one of each for dual signing.

  • Record, ready

    The DNS TXT record comes ready to publish, both single-line and pre-split for panels that don't split long records themselves.

  • See it work

    The sign-verify-tamper demo turns an abstract key pair into something you can watch pass, then fail the moment the message changes.

/ How signing works

How does a key pair prove a message is genuine?

The two keys are mathematically linked and do opposite jobs. Your mail server holds the private key and uses it to sign each outgoing message — the signature is a hash of the headers and body, encrypted with the private key, attached as the DKIM-Signature header. The public key lives in your DNS, and any receiver can fetch it to check that signature. Only the private key could have produced a signature the public key validates, which is what ties the message to you.

The clever part is that the signature covers the content. If a single character of the signed headers or body changes in transit — an injected link, an altered reply-to, a rewritten subject — the hash no longer matches and verification fails. That's the tamper demo above made concrete: sign a message, verify it, then change one character and watch the same public key reject it. DKIM doesn't prove the message is good — it proves the message is unaltered and genuinely from a holder of the private key.

This is also why the selector matters. You can publish several public keys at once, each under its own selector label, which is how key rotation works without downtime: publish a new selector, switch your signer to it, confirm mail still verifies, then retire the old one. It's why generating a fresh pair — and knowing exactly which record and which private key go together — is a routine part of running email, not a one-time event.

/ Generating safely

Where should a production key really be generated?

Here's the honest answer, because a security tool that oversells itself isn't trustworthy. The gold standard for a production mail server is to generate the key on the server that will hold it — opendkim-genkey or openssl on the signing host — so the private key is born where it lives and never travels at all. That removes even the theoretical question of how it got there.

What this tool does differently from most online generators is that it never sees your key: server-side generators create the key on their machine and send it to your browser, which means their server touched your private key. Here, generation happens locally with the Web Crypto API — the same secure primitives your browser uses for HTTPS — and nothing is transmitted. You can prove it by disconnecting your network and generating anyway. That makes it a genuinely safe choice for testing, staging, learning, dual-signing experiments, and any setup where in-browser generation fits your threat model.

Wherever you generate, the discipline afterward is the same: move the private key over a trusted connection, store it with tight permissions, never paste it into a tool you don't trust, and rotate it on a schedule. A DKIM key is a long-lived credential that can sign as your domain, so it earns the same care as any other secret. Getting the key onto the right server, published, rotated, and retired cleanly across every service that signs for you is the ongoing operation behind a healthy setup — which is what we run.

/ Key generator FAQ

Is it safe to generate a private key in a browser?
The generation itself is cryptographically sound: this tool uses the Web Crypto API, the same audited primitives browsers use for TLS, seeded by the operating system's secure random source — not a JavaScript random function. Nothing is transmitted; the key is created and stays in this page's memory, which you can confirm in your network tab where clicking Generate makes no request. That said, the most defensive practice for a production mail server is to generate the key on the server itself with a tool like opendkim-genkey or openssl, so the private key is born where it lives. This generator is safe and convenient for testing, learning, staging, and setups where in-browser generation is acceptable — treat the downloaded private key like a password, move it over a trusted connection, and never paste it into a tool you don't trust.
Should I choose RSA or Ed25519?
RSA-2048 is the safe default: every mailbox provider verifies it, and it clears the 1024-bit floor that Yahoo and others reject below. RSA-4096 is stronger but produces a large DNS record that some providers handle awkwardly, so most senders stay at 2048. Ed25519 (RFC 8463) is the modern option — a tiny 256-bit key with security comparable to RSA-3072 — but as of 2026 Microsoft 365 and Yahoo still don't verify it, so signing with Ed25519 alone leaves those receivers unable to validate you. The complete answer is dual signing: publish both an RSA-2048 key and an Ed25519 key under separate selectors, and a pass from either satisfies DMARC. Generate one of each here.
What do I do with the two outputs?
You get a private key and a DNS record, and they go to two different places. The private key (the PEM block) goes on your mail server or into your sending platform's DKIM configuration — it's what signs outgoing mail. The DNS record (the public key) gets published as a TXT record at selector._domainkey.yourdomain.com, where receiving servers fetch it to verify your signatures. The selector is the label you choose; it lets you rotate keys by publishing a new one without disturbing the old. Publish the record, load the private key into your signer, send a test message, and confirm with the DKIM checker.
Why does the tool sign and verify a sample message?
To make visible what DKIM actually does. The demo signs your sample text with the private key you just generated, then verifies that signature with the matching public key — the same key you'd publish in DNS. A valid result means the pair works. Then flip the tamper switch: the tool alters one character and re-verifies, and the signature fails. That failure is the whole point of DKIM — it proves a message was signed by the holder of the private key and hasn't been altered in transit. Seeing the pass turn to a fail when the content changes is the clearest way to understand why the signature matters.
How long is a DKIM record, and why is it split?
A 2048-bit RSA public key is about 400 characters, and a single DNS TXT string can hold at most 255. So the full record has to be split into several quoted strings that DNS concatenates back together — the tool shows both the single-line value (many DNS panels split it for you automatically) and the pre-split version for panels that don't. An Ed25519 record is short enough to fit in one string. If a 2048-bit record is pasted unsplit into a panel that doesn't auto-split, it silently truncates and DKIM fails to validate, so use the split version when in doubt.
Does anything leave my browser?
No. Key generation, the PEM export, the DNS record, and the sign-verify demo all run locally with the Web Crypto API. No key, message, or domain is sent to our servers or stored. The download button writes the private key to your device directly from the page. You can run this tool with your network disconnected and it works exactly the same.

A key pair is a minute's work. Rotating it forever is the work.

Publishing a key is easy; keeping every sending service on strong, aligned, rotated keys — and retiring the old ones cleanly — is continuous. That's what we operate. Generate your pair, then bring us the rotation.

Book infrastructure review

Related capabilities