Free tool
DKIM generator
Create a DKIM key and its DNS record without the key ever touching a server
Generate an RSA-2048 or Ed25519 DKIM keypair with your browser's own cryptography. Download the private key as a PEM file, copy the selector._domainkey TXT record, publish it, and start signing.
The keypair is generated in your browser by the WebCrypto API and never leaves it. This page makes no network requests during generation, so nothing is uploaded and no DNS query leaves the page. The private key exists only on this page until you download it.
Your DKIM record
Publish a TXT record at
with this value
Private key
PKCS#8 PEM, generated locally. Install it on the server that signs your mail and keep it secret — it was never sent to us, so this download is the only copy.
Download private key (PEM)Once the record is live, verify it with the DKIM checker. DKIM checker
How to set up DKIM with this generator
From nothing to signed mail in four steps: generate, publish, sign, verify.
-
1
Generate the keypair
Pick a selector name and a key type, then generate. RSA 2048-bit is the safe default; Ed25519 only if you know your receivers support it.
-
2
Publish the TXT record
Create a TXT record at {selector}._domainkey in your DNS zone with the generated value. DNS changes usually propagate within minutes to a few hours.
-
3
Install the private key
Download the PEM file and configure your mail server, OpenDKIM, rspamd, or gateway to sign outgoing mail with it, using the same selector name.
-
4
Verify the record
Run the DKIM checker on your domain and selector to confirm the published key parses, has the expected strength, and is active.
When you need your own DKIM key
Most hosted providers hand you a ready-made record or CNAME. You need to generate your own key when you:
- Run your own mail server with Postfix and OpenDKIM or rspamd.
- Configure an email gateway or appliance that signs on the way out.
- Rotate an existing key to a new selector on a schedule or after an exposure.
- Replace a weak 1024-bit key with a 2048-bit one.
- Add an Ed25519 key alongside your RSA key for receivers that support RFC 8463.
- Set up DKIM in a lab or staging environment without touching production keys.
Understanding DKIM keys
What the generated record means
A DKIM key record has three tags: v=DKIM1 declares the record version and must come first, k= names the key type (rsa or ed25519), and p= carries the public key, base64-encoded. For RSA the p= value is the DER-encoded SubjectPublicKeyInfo — the same output as openssl rsa -pubout. An empty p= has a defined meaning: the key is revoked.
Why RSA 2048-bit is the default
RFC 8301, which updated DKIM's original cryptography, sets the current rules: verifiers must reject keys shorter than 1024 bits, signers must use at least 1024 bits, and signers should use 2048 bits or longer. 1024-bit RSA still verifies everywhere but is considered weak against modern factoring; 2048-bit is the size to generate today. Longer keys work too — verifiers must handle up to 4096 bits — but gain little in practice and can complicate DNS publishing.
Ed25519 keys and where support stands
RFC 8463 added Ed25519 as a second DKIM algorithm: 256-bit keys with security comparable to much larger RSA keys, and a p= value short enough to never worry about TXT record limits. Two caveats. In the DNS record, p= is the raw 32-byte public key base64-encoded — not the DER wrapper used for RSA, a mismatch that breaks many hand-rolled setups. And receiver support is still the exception rather than the rule, so an Ed25519 key belongs alongside an RSA key, signing with both, not on its own. In the browser, WebCrypto Ed25519 generation works in current Chrome and Edge (137+), Firefox (130+), and Safari (17+); this tool detects support and disables the option where it is missing.
TXT records and the 255-character limit
A single character-string inside a DNS TXT record carries at most 255 bytes, and a 2048-bit RSA p= value pushes the record past that. This is expected: a TXT record may hold multiple strings, and DKIM verifiers concatenate them before parsing. Most DNS providers split long values automatically. If yours refuses the record, split the value into two quoted strings — the split can fall anywhere, even mid-key.
Rotating DKIM keys
Rotation means publishing a new key under a new selector, switching your signer to it, and only then revoking the old selector by emptying its p= tag. Keep the old record live until mail signed with it has cleared receivers' queues — a few days is customary. Never reuse a selector name for a new key, and never revoke the old key before the new one verifiably signs: those two mistakes cause most self-inflicted DKIM outages.
Handling the private key
The private key belongs on the signing host and nowhere else. Restrict its file permissions to the signing process, never commit it to a repository, and never paste it into DNS — the record takes only the public half. If the private key leaks, anyone can sign mail as your domain until you rotate: generate a replacement under a new selector immediately and revoke the exposed one.
Generation is half the job. After publishing, confirm the record with the DKIM checker — it fetches the record as receivers see it, decodes key type and strength, and catches truncated or mis-split values before they cost you deliverability.
Frequently asked questions
- What does this DKIM generator create?
- Two things: a private key as a PKCS#8 PEM file, which you install on the server or software that signs your outgoing mail, and the matching public key packaged as the DNS TXT record value (v=DKIM1; k=rsa; p=...) that you publish at {selector}._domainkey.{domain}.
- Is it safe to generate a DKIM key in a browser?
- The keypair is generated by your own browser's WebCrypto API, on your machine. This page makes no network requests during generation: the private key is never uploaded, beaconed, or logged, and it disappears when you leave the page unless you download it. If your policy requires keys to be generated on the signing host itself, use openssl there instead — the record format is identical.
- Should I choose RSA or Ed25519?
- RSA 2048-bit, unless you know your receivers support Ed25519. RFC 8301 requires signers to use RSA keys of at least 1024 bits and recommends 2048 bits or longer; every DKIM verifier supports RSA. Ed25519 (RFC 8463) gives equivalent security with much smaller keys, but receiver support is still limited, so it should be published alongside an RSA key rather than instead of one.
- How do I publish the generated record?
- Create a TXT record in your domain's DNS zone with the host name {selector}._domainkey (some DNS providers want the full {selector}._domainkey.{domain}) and the generated value as its content. Then configure your mail server or sending software to sign with the private key and that selector name.
- Why does my DNS provider reject the record as too long?
- A single character-string in a DNS TXT record holds at most 255 bytes, and a 2048-bit RSA public key produces a longer value. RFC 6376 handles this by splitting the value into multiple quoted strings, which verifiers concatenate. Most DNS providers split automatically; if yours does not, break the p= value into two quoted strings at any point.
- What do I do with the private key file?
- Install it on whatever signs your outgoing mail: OpenDKIM or rspamd on a self-hosted server, or the DKIM configuration of your mail gateway. Keep it secret and never publish it in DNS — only the public record goes there. If the key is ever exposed, generate a new one under a new selector and revoke the old record.
- Is this DKIM generator free?
- Yes. The generator is completely free with no signup. Because key generation runs entirely in your browser, we never see your keys — there is nothing to store even if we wanted to.
Now prove your DKIM signing works
A published record does not mean receivers accept your signatures. Create a free account to read your DMARC aggregate reports and see DKIM pass rates per sender. Paid plans alert you the moment your DKIM, SPF, DMARC, or MX record changes — including a revoked or broken key.