Patchkit

Free tool

DKIM Key Generator

Create a DKIM key pair for a mail server you run yourself. You get the TXT record to publish and the private key to install; both are made in your browser.

Dated by default, so the next key can use a new one.

Key type

The key pair is made in your browser with the Web Crypto API. The private key is never sent to Patchkit or anywhere else, and it isn't saved: it disappears when you leave or reload this page.

By Ahmet Karaca · Updated · Checked against RFC 6376 (DKIM), RFC 8301 (DKIM key sizes), RFC 8463 (Ed25519 for DKIM), RFC 1035 (DNS) and Amazon SES: bring your own DKIM key on

Who needs to generate a DKIM key

This tool is for mail you sign yourself: a Postfix server with OpenDKIM, a Mailcow or similar mail server suite, or any other setup where your own machine adds the DKIM-Signature header. You create the key pair, publish the public half in DNS and install the private half on the server that signs.

Hosted providers usually work the other way round. Google Workspace and Microsoft 365 generate the key themselves, keep the private half on their servers and show you the DNS records to publish, so there is nothing to generate here for them; follow their own steps instead, for example in the Google Workspace setup guide or the Microsoft 365 setup guide. Amazon SES does it by default too, but also lets you bring your own RSA key of up to 2048 bits; the Amazon SES setup guide covers its default setup. The setup guides cover the other providers.

What the generator produces

Two halves of one key. The public key goes into a TXT record at selector._domainkey.yourdomain.com, in the form v=DKIM1; k=rsa; p=…, where p= holds the key in base64. Receivers fetch that record and check each signature against it. For RSA, p= holds the key in the SubjectPublicKeyInfo form, the same form RFC 6376's own example in Appendix C produces. For Ed25519, RFC 8463 defines p= as the raw 32-byte public key, which is only 44 characters in base64, and the record says k=ed25519.

The private key comes as a PEM file in the PKCS#8 format, beginning with -----BEGIN PRIVATE KEY-----. Signing software differs in which key formats it accepts, so check your signer's documentation and convert the file if it asks for another format. Whoever has this file can sign mail as your domain: keep it on the signing server only, readable by the signing software, and never paste it into email, chat or a ticket.

If you aren't sure what a selector is or why the key lives in DNS, read what DKIM is and how it works first.

Publishing the record

  1. Create a TXT record. Its name is the selector followed by ._domainkey; if your DNS panel adds the domain automatically, the host field takes only selector._domainkey.
  2. Paste the one-line value. If the panel rejects it as too long, paste the split form with its quoted strings instead.
  3. Install the private key on your server and configure the signer with the same domain and selector.
  4. Wait for the record to appear, then run the DKIM checker with your selector to confirm receivers can read the key.
  5. Send yourself a message and look for dkim=pass in its headers. How to find your DKIM selector shows where the signature sits.

Rotating keys

Selectors exist so a domain can change keys without a gap. RFC 6376 describes the routine: publish the new key under a new selector while the old one is still in DNS, switch the signing server to the new private key, and remove the old record once mail signed with it is no longer in transit. That is why the suggested selector carries the year and month: the next key gets the next date, and the record names show which key is newer.

To revoke a key on purpose, for example after a server was compromised, you can publish its record with an empty p=. Receivers must then treat signatures made with that key as failed (RFC 6376). Deleting the record makes those signatures fail too, and RFC 6376 gives the two no different meaning; an empty p= just says openly that the selector is known and retired.

Related tools and guides

Frequently asked questions

+Is the private key sent to Patchkit?

No. The key pair is generated in your browser with the Web Crypto API. Generating it sends nothing to our servers and stores nothing anywhere: not the keys, the domain or the selector. The private key exists only in this page's memory and is gone when you reload, leave or generate a new pair, so download or copy it before you close the page. Only if you open the DKIM checker afterwards does that check send your domain and selector, never the key.

+Why is 2048 bits the only RSA size?

RFC 8301 requires signers to use RSA keys of at least 1024 bits and says they should use at least 2048 bits, so 1024 is only the floor and we don't offer it for a new key. 2048 bits meets that recommendation. A 4096-bit key would also work, because verifiers must accept keys from 1024 to 4096 bits, but its TXT value is nearly twice as long and needs three 255-character strings instead of two. Some services also cap the size: Amazon SES accepts your own DKIM key only up to 2048 bits. If your policy calls for 4096 bits, generate that key with your signer's own tool.

+Should I choose RSA or Ed25519?

Start with RSA: RFC 6376 and RFC 8301 require every DKIM verifier to support RSA keys. Ed25519 (RFC 8463) is an addition, not a replacement. RFC 8463 requires verifiers to implement it as well, but it also describes signing with both algorithms under separate selectors for backward compatibility. So publish the Ed25519 key under a second selector next to an RSA key and have your server sign each message with both. A verifier that doesn't support Ed25519 can't check that signature, but RFC 6376 has verifiers evaluate each signature on its own, so the RSA signature can still pass.

+Why is the record split into strings of 255 characters?

A single string inside a DNS TXT record holds at most 255 characters (RFC 1035), and a 2048-bit RSA key is longer than that. The record is then published as several quoted strings, which receivers join back together without spaces (RFC 6376). Some DNS panels split a long value for you; if yours rejects the one-line value, paste the split form instead.

+Which selector should I use?

Any name made of letters, digits and hyphens works, and dots can separate parts. We suggest the letter s plus the current year and month, such as s202610, because a dated selector makes the next rotation easy: the new key simply gets the next date. Use a selector that isn't already published on your domain, or you will overwrite a key that is in use.

+How do I rotate a DKIM key?

Generate a new pair under a new selector and publish its TXT record while the old one stays in place. Once the new record is live, switch your signing server to the new private key. Leave the old record published for a while so messages already on their way can still be verified, then delete it.

We use Google Analytics cookies only if you accept. Privacy policy