DKIM Generator

Builds a DKIM key pair and a ready TXT record that you only need to add to your domain's DNS.

A short name for the key. It goes into the record name and into message signatures.

Optional: the domain doesn't affect the key itself.

Record tags

The DKIM generator produces a key pair and a ready-made DNS record. The public key goes into the TXT record that you publish in your DNS panel; the private key is used by your mail server to sign outgoing messages. Before showing the result, the page signs a test string with the private key and verifies the signature with the public key from the finished record. You see the record only after the check passes, which the line "Key pair verified" confirms.

Where each part goes

Save the private key to a file that your mail server reads: the page offers it as a file named mail.private, where the file name repeats the selector. Keep the file away from others, because whoever holds the private key can sign mail on behalf of your domain. Publish the TXT record in DNS.

The selector is a short name for the key. One domain can have several of them, each with its own record. The record name combines the selector, the word _domainkey, and the domain: mail._domainkey.example.com. Many DNS panels append the domain automatically, in which case mail._domainkey is enough for the name field. The domain field on the page is optional: the key itself does not depend on it, it only builds the full record name.

How it works. Your server signs the message with the private key and writes the signature into the DKIM-Signature header, which among other things carries the domain in the d= tag and the selector in the s= tag. The recipient uses these two values to find your record in DNS and checks the signature against the public key. After publishing the record, look at it the way a recipient does: the DKIM check shows the record as other servers fetch it, and whether a signature is enforced without a DMARC policy is what the DMARC check tells you.

Which key to choose

By default the page generates an RSA 2048-bit key, and that is a sound choice. An RSA 1024-bit key will be accepted by every recipient, but RFC 8301 advises against going below 2048.

If your DNS panel rejects a long record, paste it in quoted chunks: the page provides them in a separate field.

RSA 4096-bit produces a record of nearly 800 characters, and not every DNS panel accepts it. Ed25519 (RFC 8463) is compact, its record takes 85 characters, but not all recipients support this key type. A server that does not understand it treats the message as unsigned, so Ed25519 is published as a second key on its own selector, while RSA stays on the old one.

Why the record comes in chunks

A single DNS TXT string is limited to 255 characters. An RSA 2048-bit key yields a 429-character record, so the page outputs it as two quoted strings. The recipient joins the strings without a separator, so the split point does not matter. Some panels split long records themselves; in that case paste it as is. Records for Ed25519 and RSA 1024-bit keys fit into one string.

How to rotate a DKIM key

Publish the new key on a new selector and point your mail server to it. Do not remove the old record right away: recipients are still processing messages sent with the old signature, and without the old record the check fails. Keep the record as long as such messages can arrive.

When the old key is no longer needed by anyone, revoke it by putting an empty p= tag in the record. After revocation, a message signed with the old key fails the check.

Rate this tool

Help us get better

Other tools