What the two halves of the key do
DKIM, defined in RFC 6376, has the sending server sign each message with a private key and attach the result as a DKIM-Signature header. That header names the signing domain in d= and the selector in s=. A receiver joins them into s._domainkey.d, fetches the TXT record there, reads the public key from the p= tag and checks the signature. A match proves the signed headers and the body were not altered after signing.
The pair you generate here therefore goes to two places. The public key is published in DNS for anyone to read, in a record like v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A... The private key goes onto the machine that signs your mail and nowhere else. Whoever holds it can sign mail as your domain, which is why this page creates it in the browser instead of on a server.
Choosing a selector and a key type
The selector is a label you pick. The form suggests s followed by the current year and month, such as s202610: a dated name shows how old a key is and leaves a free name for the next rotation. The field takes up to 63 letters, digits and hyphens and must start with a letter or digit.
Four key types are listed. RSA 2048-bit is marked as recommended. RSA 1024-bit is the smallest size RFC 8301 still permits. RSA 4096-bit produces a public key of about 740 characters, which some DNS hosts cannot store. Ed25519, added to DKIM by RFC 8463, has a public key of only 44 characters, but the option is greyed out when your browser cannot generate that key type.
Publishing the public key in DNS
The first result card has three copyable fields. Host / Name is the full record name, for example s202610._domainkey.example.com. Many DNS panels append the zone themselves, and there you enter only s202610._domainkey. Type is TXT. Value is the record: v=DKIM1, then k=rsa or k=ed25519, then the Base64 public key in p=. Paste it exactly, because one lost character makes the key undecodable and every signature fails.
The domain box is optional: it is not part of the key material and only sets the record name shown and the file name of the download. With a domain entered, a link under the cards opens the DKIM Checker for that selector. Use it once the record is live to confirm the key decodes to the length you chose.
Installing the private key on the mail server
The second card shows the private key as PEM text that begins with -----BEGIN PRIVATE KEY-----, the PKCS#8 container, and Download .pem saves it as selector.domain.private.pem. OpenDKIM and other signers that load keys through OpenSSL read this form directly. If a program insists on the older PKCS#1 layout (BEGIN RSA PRIVATE KEY), convert an RSA key with OpenSSL 3: openssl rsa -in key.pem -traditional -out key-rsa.pem.
Store the file where only the signing daemon can read it. OpenDKIM refuses a key that other accounts can read and logs key data is not secure, so give the file to the opendkim user with mode 600. Point the signer at the file, set its selector to the one you published and its domain to the one in your From address, then reload the service.
Rotating and retiring a key
Selectors make rotation possible without an outage. Generate a new pair under a new selector, publish its record, wait until it resolves, then switch the signer to the new key. Leave the old record in place for several days so mail already in transit still verifies. After that, revoke the old selector by publishing it with an empty p= tag, which RFC 6376 defines as a withdrawn key.
Rotate at once if the private key may have leaked: a backup copied to the wrong place, a server you no longer control, a key pasted into a ticket. A signature also does nothing for DMARC unless d= aligns with the From domain. Send yourself a test message, check for dkim=pass with your own domain in the Email Header Analyzer, then set the policy with the DMARC Generator.