The key is made in your browser, not on our server
The key pair is made by your browser, which is why this page needs JavaScript. Nothing is generated on our server, and the private key is never sent to us.
A DKIM private key is the secret that signs your mail. Anyone holding a copy can sign messages that receivers will treat as genuinely yours, which is why a generator that makes the key on its own server is asking you to trust a stranger with exactly the thing you are trying to protect. Even with the best intentions the key would travel across the network, pass through a web server and sit in memory on a machine you do not control.
This page does none of that. The key pair is created by your browser with WebCrypto, the same interface it uses for TLS keys, and the private half never leaves the tab. There is no request carrying it, so there is nothing for us to log, cache or back up, and nothing we could hand over if we were asked. That is also why the page needs JavaScript: the work happens on your side, and there is no server side fallback on purpose.
The key is held in memory only. Once you close the page it is gone, so copy the private key before you leave. If you lose it, nothing breaks, you simply generate another pair and publish the new record.
What each half is for
DKIM works with a pair. The public half is published in DNS so that every receiver in the world can read it, and the private half stays on the machine that sends your mail.
- The public key goes into a TXT record at selector._domainkey.example.com, in the form v=DKIM1; k=rsa; p= followed by the key.
- The private key goes on the mail server, in a file that only the mail server may read.
- The selector is only a name. It lets one domain publish several keys at once, one per service that sends for it.
Publishing the record on its own changes nothing. Mail is signed by the sending server, so until you point that server at the private key there is no signature for anyone to check, and the published key just sits there unused.
Where the private key goes
The private key is saved as a file on the machine that signs, owned by the user the signing service runs as and readable by nobody else. On Linux that means chmod 600 and the right owner. It does not belong in a git repository, a ticket, a chat message or a shared drive.
OpenDKIM is pointed at the file with KeyFile, or through KeyTable when one server signs for several domains, and the selector is named alongside it. Rspamd takes a path per domain in its DKIM signing settings. A hosted mail service usually has no place to paste a key at all: it generates its own pair and gives you a record to publish, and then this page is not what you need.
The private key here is in PKCS#8 PEM form, which OpenDKIM, rspamd and other signers built on OpenSSL read directly. A tool that insists on the older format with a BEGIN RSA PRIVATE KEY header can convert the file with openssl rsa.
Making the same key with openssl
Nothing about the key is specific to this page. If you would rather do it on your own machine, or you need it inside a script, three commands produce the same thing:
openssl genrsa -out mail.private 2048 chmod 600 mail.private openssl rsa -in mail.private -pubout -outform der | openssl base64 -A
The first command writes the private key, the second stops everyone else on the machine from reading it, and the third prints the base64 string that goes after p= in the DNS record. Put it into v=DKIM1; k=rsa; p= and publish that as the TXT record.
Publishing, checking, and rotating later
After the record is published, wait for it to reach the resolvers and then read it back with the DKIM record check. That is the other half of this job: this page creates a key, that one reads what the world can actually see, and only the second one can tell you whether the record survived being pasted into a control panel.
A signature that verifies is still not protection on its own. DKIM proves a message was signed by a key published under some domain, and it takes DMARC to say that the domain in the visible From address has to be the one that signed. Check what you have with the SPF record check and the DMARC record check before you tighten a policy.
Rotation follows the same order, and never the reverse. Generate a pair under a new selector, publish the new record, wait for it to be visible, switch the mail server to the new private key, and only then remove the old record. Messages already on their way were signed with the old key and still need it to verify.