DKIM Record Generator

This tool runs an RSA-2048 keypair generation entirely in your browser using the Web Crypto API. Nothing is uploaded - the private key is created, displayed, and offered for download without a network round trip. The output has two halves: a TXT record value in the form `v=DKIM1; k=rsa; p=<base64 public key>` that goes into DNS, and a PEM-encoded private key that you load into your mail server or sending platform to sign outgoing messages.

RFC 6376 defines the DKIM signature mechanism itself but leaves key generation to implementers, so there is no single mandated tool or format for creating the keypair - only requirements for what the published record has to contain once the key exists.

• Public key → DNS TXT record at `<selector>._domainkey.<yourdomain>`
• Private key → loaded into the mail server / ESP that signs your mail
• Key generation happens locally; the private key is never transmitted

The selector is the label before `._domainkey` in the record name, and RFC 6376 places almost no restriction on it beyond being a valid DNS label - it can be a word, a date, or a version number. What matters in practice is that the selector be unique enough not to collide with another signing system on the same domain, and stable enough that you can tell at a glance which sending platform or key generation it belongs to.

A common convention is to fold a date or purpose into the selector, such as `2026a` or `mailgun`, rather than leaving it at the default `default` - this makes rotation and multi-provider setups easier to audit later, since every selector visible in DNS reads as self-documenting instead of requiring a lookup table kept elsewhere.

• Any DNS-label-valid string works: letters, digits, hyphens
• One selector per sending source keeps signatures traceable to their origin
• Avoid reusing a selector another platform already occupies on the same domain

RFC 8301 updates the original DKIM specification to require a minimum RSA key size of 1024 bits for verification but recommends 2048 bits for signing, and deprecates SHA-1 in favor of SHA-256 for the signature hash. 2048-bit RSA is the size major mailbox providers expect today; going smaller risks a receiving server treating the signature as weak or invalid, and going larger runs into a separate constraint described below.

Ed25519 keys are defined for DKIM in RFC 8463 and produce a much shorter public key, but support among receiving mail systems is inconsistent enough that RSA remains the safer default unless you have confirmed your recipients validate Ed25519 signatures.

The record name follows the fixed pattern `<selector>._domainkey.<domain>`, and the value is the single string this generator produces, starting with `v=DKIM1`. Most DNS providers accept the value as one long string; because a single TXT string is limited to 255 bytes per RFC 1035, resolvers and DNS software split a longer value across multiple quoted strings that concatenate back into one at query time - check your provider's interface if it truncates a 2048-bit key's base64 output rather than continuing it.

There is no fixed TTL requirement in the DKIM RFCs, but a shorter TTL on a newly published or about-to-be-rotated record shortens how long a stale cached copy can linger at resolvers if something needs correcting.

The private key this generator produces is the only copy - closing the tab without downloading it means generating a new keypair and republishing the TXT record from scratch. Store the downloaded PEM file the same way you would any credential: outside version control, restricted to the service account that needs it, and never pasted into a chat, ticket, or shared document. Anyone holding the private key can produce signatures that verify against your published selector, which is indistinguishable at the protocol level from your legitimate mail server signing.

If a private key is ever exposed - committed to a public repository, logged in plaintext, or shared over an insecure channel - treat it as compromised immediately and follow the rotation steps below rather than waiting for evidence of misuse.

RFC 6376 frames the selector itself as the unit of rotation: generate a new keypair under a new selector, publish its TXT record, switch your sending system to sign with the new private key, and only remove the old selector's DNS record once you are certain no queued or delayed mail is still being signed with it. Removing the old record too early causes valid mail signed just before the cutover to fail verification at the recipient.

To revoke a key without deleting the record outright, publish an empty `p=` value at the same selector - RFC 6376 defines this as an explicit revocation, distinct from a missing record, and it takes effect as soon as a resolver fetches the updated TXT value rather than waiting out whatever TTL a deleted record might still be cached under.