# DKIM Record Generator and Key Rotation Kit

> Generate a real RSA or Ed25519 DKIM key pair locally in the browser, publish only the algorithm-correct public key, and carry the result through DNS, signer installation, verification, rotation, and retirement.

- **Canonical page:** [https://emailbump.com/tools/dkim-record-generator](https://emailbump.com/tools/dkim-record-generator)
- **Interactive tool:** [Open the DKIM record generator](https://emailbump.com/tools/dkim-record-generator)
- **Category:** email authentication, DNS, cryptographic key management, and deliverability operations
- **Updated:** July 2026
- **Default:** RSA 2048 with SHA-256
- **Additional choices:** RSA 3072, RSA 4096, and Ed25519 where the browser and signing system support it
- **Privacy:** Key generation, encoding, fingerprinting, and exports happen in the browser
- **Network boundary:** The tool does not upload keys, query DNS, change a zone, configure a signer, send mail, or verify a delivered signature
- **Secret boundary:** The public manifest deliberately excludes the private key; the separate private export is unencrypted PKCS#8 PEM
- **Decision boundary:** A syntactically correct record is not proof that DNS is live, the signer is configured, a signature verifies, DKIM aligns for DMARC, or a message will reach the inbox

## What this tool produces

The generator creates one asymmetric key pair and turns it into several artifacts with different handling requirements.

The public artifacts are:

- the complete DNS owner name formed from the selector, the literal _domainkey label, and the signing domain;
- one DKIM TXT value containing version, key type, SHA-256 restriction, email service restriction, optional flags, and public-key data;
- a BIND-style zone presentation split into conservative 200-character strings;
- a public SubjectPublicKeyInfo PEM file;
- a SHA-256 fingerprint of the exact bytes carried by the decoded p= value;
- a JSON deployment manifest that excludes the secret;
- and a plain-text change runbook.

The secret artifact is:

- one unencrypted PKCS#8 private-key PEM file intended only for the authorized DKIM signer or an approved secret-management path.

The distinction matters. DNS receives the public TXT value. The signing service receives the private key. A change ticket can receive the public fingerprint and manifest. Source control, chat, screenshots, shared folders, analytics, and browser telemetry should receive none of the private material.

The page does not create a certificate. DKIM does not require a certificate authority. A receiver learns which public key to use by reading DNS at the selector named in a message's DKIM-Signature header.

## The three identities to keep separate

A reliable deployment begins by distinguishing three related values.

### Signing domain

The signing domain is the value the signer will place in the d= tag of the DKIM-Signature header. The generator labels this input “Signing domain (d=).”

This domain does not have to be the organizational apex. A sender might sign with example.com, mail.example.com, or a provider-controlled domain. The choice affects DMARC alignment and operational ownership. Enter the value the production signer will actually use, not a domain selected only because it looks familiar.

### Selector

The selector is the s= value in the DKIM-Signature header. It identifies a key within the signing domain. Examples include eb2026a, transactional-2026-07, and a provider-assigned token.

A selector is not a security secret. It enables key discovery and key rotation. Use a fresh selector for a replacement key. Reusing a live selector for different public-key data creates ambiguous verification during DNS caching and removes the clean overlap that selectors were designed to provide.

### DNS owner name

The public key is queried at:

selector._domainkey.signing-domain

For selector eb2026a and signing domain example.com, the full owner is:

eb2026a._domainkey.example.com

DNS control panels represent owner names differently. A console scoped to the example.com zone may expect only eb2026a._domainkey and append example.com. Another may accept the full name. Some show an explicit trailing root dot and some do not. Inspect the provider's preview and then resolve the saved record independently. Accidentally publishing example.com twice is a common operational failure.

## Algorithm choices

### RSA 2048

RSA 2048 is the default because it has broad DKIM signing and verification compatibility while meeting the current minimum recommendation in RFC 8301. The signing algorithm is RSA-SHA256, the key record uses k=rsa, and the public-key p= data is the base64 DER SubjectPublicKeyInfo object.

RFC 8301 says DKIM signers must not use RSA keys below 1024 bits and should use at least 2048 bits. It also says SHA-1 must not be used for DKIM signatures. This generator therefore does not offer 512-bit, 768-bit, 1024-bit, or SHA-1 options.

### RSA 3072

RSA 3072 increases the modulus and the resulting public key, private key, signature size, CPU cost, and DNS record length. It can be a reasonable policy choice when every signer, DNS system, and operational process can support it. It is not automatically more deliverable.

The longer p= value will require multiple DNS character-strings. Correct DNS software concatenates those strings before returning the TXT RDATA, but some provisioning interfaces mishandle long records. Test the actual route.

### RSA 4096

RFC 8301 requires verifiers to handle RSA keys from 1024 through 4096 bits. RSA 4096 nevertheless creates a very large DKIM TXT record, larger signatures, more signing work, and more chances to encounter deficient DNS provisioning software.

Choose it because of an owned cryptographic policy and tested infrastructure, not because the largest menu item appears universally safest. The generator warns that key creation can take longer and exposes the resulting string count.

### Ed25519

RFC 8463 adds Ed25519-SHA256 to DKIM. Ed25519 provides a compact 256-bit public key whose base64 form is 44 characters. The DNS key record uses k=ed25519, and the p= value is the base64 raw 32-byte Ed25519 public key.

That encoding differs from RSA. The generator exports an Ed25519 public SubjectPublicKeyInfo PEM for ordinary tooling, but it does not place that complete SPKI object in p=. It exports the raw public key from Web Crypto and uses those exact 32 bytes for DNS and the published-key fingerprint.

RFC 8463 describes Ed25519-SHA256 as a DKIM signing algorithm and supports transition through multiple signatures with different selectors. Real signing products do not all expose it, so confirm current support in the system that will hold the private key and sign the message. Browser support also varies. If the current Web Crypto implementation rejects Ed25519 generation, the tool presents an explicit error and RSA remains available.

For an algorithm transition, publish RSA and Ed25519 under different selectors. A message can carry independent DKIM signatures for both. Do not try to store two key types at one selector.

## What is inside the DNS value

The generator emits tags in this order:

1. v=DKIM1
2. k=rsa or k=ed25519
3. h=sha256
4. s=email
5. optional t= flags
6. p= followed by base64 public-key data

Tag order is generally not significant except that RFC 6376 requires v= to appear first when it is present. The explicit tags make the intended policy reviewable.

### v=DKIM1

The version identifies a DKIM key record. It is optional in the base specification but, when present, must be the first tag. The generator includes it to make the record self-describing.

### k=

The key type tells a verifier how to interpret the decoded p= bytes. RSA is the historical default, but the generator includes k=rsa explicitly. Ed25519 records require k=ed25519.

### h=sha256

The h= tag restricts the acceptable hash algorithms for signatures using this key. The generator emits only SHA-256. It does not offer SHA-1 because RFC 8301 says signers must not use it.

### s=email

The service-type tag restricts the key to email. DKIM defines an asterisk default meaning all service types. Explicit s=email narrows the generated key to its intended use.

### p=

The p= value is required and contains base64 public-key data. Whitespace is not part of the decoded key. An empty p= value indicates that the key has been revoked.

For RSA, p= is base64 DER SubjectPublicKeyInfo. This is the same DER object represented by the body of a PEM file labeled PUBLIC KEY. It is not an X.509 certificate, a private key, a PKCS#1 RSA PUBLIC KEY object, an SSH key, or a hash.

For Ed25519, p= is the base64 raw 32-byte public key defined by RFC 8463, not the complete SPKI wrapper.

### t=y

The y flag indicates that the domain is testing DKIM. RFC 6376 says a verifier must not treat messages differently solely because of this flag, although it may use the flag to assist diagnosis.

That is not a safe-deployment switch. Receivers can ignore it. It does not make a bad signature pass, change DMARC alignment, repair a body hash, or excuse a missing key. Use narrow test traffic and evidence rather than relying on t=y.

### t=s

The s flag requires the domain in the DKIM identity i= to be the same as d=. Without it, the i= domain may be the same domain or a subdomain of d=. This is a DKIM identity constraint, not the “strict” mode of DMARC alignment.

Do not enable it merely because “strict” sounds safer. Confirm how the signing system constructs i= and whether downstream uses rely on a subdomain identity.

## DNS TXT strings and the 255-octet boundary

DNS TXT RDATA is composed of one or more character-strings. RFC 1035 limits one character-string to 255 octets. A long RSA DKIM record therefore needs multiple strings at the DNS representation layer.

Those strings form one resource record. Resolvers concatenate the character-strings in order for DKIM processing. There must be no invented space between adjacent pieces.

The generator uses 200-character chunks. All generated DKIM characters are ASCII, so one character is one octet. The conservative size stays below the protocol limit and can be easier to carry across zone tooling than an exact 255-character split.

The BIND-style output places multiple quoted strings inside parentheses. Parentheses, line breaks, indentation, and quote marks are presentation syntax. They are not part of the DKIM value.

Provider interfaces differ:

- a raw zone editor may accept the complete BIND-style record;
- a form may ask separately for host, type, TTL, and one unsplit value;
- a provider may automatically split the value into character-strings;
- a form may require manually quoted chunks;
- and a deficient interface may silently insert spaces, escape characters, or truncate the record.

Use the full unsplit TXT value when the console asks for “value” or “content” and its documentation says it handles TXT storage. Use the zone form only where zone syntax is accepted. After saving, query authoritative DNS and at least one independent recursive resolver. Compare the reconstructed value and decoded key, not the visual line wrapping in the console.

Multiple character-strings in one TXT record are not the same as multiple DKIM TXT records at the same selector. The output is one resource record.

## Browser-local key generation

The interactive page uses the Web Crypto API.

For RSA it requests:

- RSASSA-PKCS1-v1_5;
- the selected 2048, 3072, or 4096-bit modulus;
- public exponent 65537;
- SHA-256;
- an extractable signing and verification key pair.

For Ed25519 it requests an extractable Ed25519 signing and verification key pair. It then exports:

- SubjectPublicKeyInfo for the public PEM;
- PKCS#8 for the private PEM;
- and raw public bytes for the Ed25519 DNS value.

Extractability is necessary because this page must let the operator install the private key in a separate signing system. That convenience changes the security model. A non-extractable key held by a managed signing service can offer stronger key custody, rotation controls, and audit trails. If a provider or hardware-backed key-management system can create and retain the private key internally, prefer its native ceremony.

Local means the JavaScript operation occurs on the user's device. It does not mean the device is trusted. A compromised browser, extension, operating system, clipboard manager, screen recorder, crash reporter, or download-sync folder can expose the key.

Use a trusted managed workstation and a private session. Close unrelated extensions where policy requires it. Move the key immediately into the approved secret destination. Remove transient downloads through the organization's recoverable disposal process. Do not generate production secrets on a shared device.

The private PEM is not encrypted with a passphrase. File permissions, a secret manager, signer access control, encryption at rest, and audit policy must protect it after export.

## Fingerprints and evidence

The generator computes SHA-256 over the exact bytes represented by p= after base64 decoding.

For RSA, those bytes are DER SubjectPublicKeyInfo. For Ed25519, those bytes are the raw 32-byte public key.

It displays a colon-delimited hexadecimal fingerprint and includes both hexadecimal and base64url forms in the manifest. This fingerprint can connect:

- the generated key ceremony;
- the approved DNS change;
- the key installed in the signer;
- the public key later retrieved from DNS;
- and the key referenced in a rotation or incident ticket.

A fingerprint is not proof of private-key control and must not replace signature verification. It is a compact identity for comparing public artifacts.

When another system reports a fingerprint, confirm that it hashed the same representation. A hash of a PEM text file, a DER SPKI object, a raw Ed25519 key, a PKCS#1 RSA object, and the private PKCS#8 object will all differ even when they relate to one key pair.

## Safe deployment sequence

### 1. Inventory the existing route

Capture the current d= domain, selector, algorithm, canonicalization, signed headers, visible From domain, DMARC alignment, sending streams, owners, and public DNS. Preserve representative raw headers.

Identify every signer. Marketing, transactional, support, mailbox, regional, vendor, and forwarding systems may use different selectors. Rotating only the visible platform can leave undocumented routes behind.

### 2. Choose a new selector

Use a unique selector that communicates an epoch or system without exposing sensitive details. Record which service owns it. Avoid overwriting the old selector.

If changing algorithm, use separate selectors for RSA and Ed25519. One selector resolves to one key record.

### 3. Generate or obtain the key

Prefer the signing system's native key generation when it retains the private key securely and exposes the correct DNS record. Use this browser generator when an owned system requires operator-supplied key material and the local ceremony meets policy.

Record the algorithm, generation timestamp, selector, domain, and public fingerprint. Do not put the private PEM in the manifest or ticket.

### 4. Prepublish the public key

Publish the new TXT record before telling the signer to use it. Allow authoritative servers and recursive caches to observe the new value. Resolve the full selector from more than one path and save exact output with timestamps.

Check:

- the owner name has not duplicated the zone;
- one TXT record reconstructs to one DKIM value;
- v= is first;
- k= matches the key;
- p= decodes successfully;
- the decoded-key fingerprint matches the ceremony;
- no console-added quotes, spaces, or backslashes entered the value;
- and DNS responses remain practical over the network paths important to the sender.

### 5. Install the private key

Transfer the secret through the approved path. Configure the exact d=, s=, signing algorithm, canonicalization, signed-header list, and message streams. Restrict access to the signer identity and authorized operators.

Different products request different private formats. This tool exports unencrypted PKCS#8 PEM labeled PRIVATE KEY. If a product expects another format, transform it only in an approved local workflow and verify the resulting public fingerprint. Do not paste secrets into an online converter.

### 6. Send narrow test traffic

Send representative messages through each intended route. Retrieve the raw received message, not only a dashboard badge.

Inspect:

- DKIM-Signature a= matches rsa-sha256 or ed25519-sha256;
- d= matches the intended signing domain;
- s= matches the new selector;
- the receiver found the intended key;
- body hash verification passed;
- header signature verification passed;
- Authentication-Results reports DKIM pass;
- DMARC sees an aligned passing authentication path when required;
- and expected mutations by gateways, footers, mailing lists, security scanners, or forwarding paths have been tested.

The generator cannot perform these checks because it does not receive the signed message or operate the signer.

### 7. Move production gradually

Enable the new selector by defined streams or a controlled percentage when the signer supports it. Monitor authentication failures, temporary DNS errors, receiver differences, bounces, complaints, and business outcomes. Keep the old public key live.

If moving to Ed25519, dual-signing with independent RSA and Ed25519 selectors can provide transition evidence and compatibility. A message with two independent signatures can still verify when one algorithm is unavailable, subject to the receiver's processing and the validity of each signature.

### 8. Stop old signing before removing the old key

Change the signer so new messages no longer use the old selector. Confirm that residual and retry paths are quiet.

Leave the old public key available for the organization's verification window. Delayed queues, retries, forwarding, mailing lists, security processing, and later verification can continue to encounter old signatures. There is no universal number of hours that fits every system. Use queue lifetimes, provider behavior, archive requirements, incident rollback, TTLs, and observed traffic.

### 9. Retire or revoke

After the old signing and verification window ends, remove the old record or publish an empty p= value to signal revocation. RFC 6376 defines an empty p= as revoked and says a verifier must treat it as a failed signature.

Removal and revocation both prevent successful verification. Revocation can make intent explicit during a compromise response. Retain the operational evidence required by policy without retaining the private key longer than needed.

## Compromise response

If the private key may be exposed:

1. stop signing with it where possible;
2. preserve incident evidence without redistributing the secret;
3. generate a new key under a fresh selector through a trusted ceremony;
4. prepublish and activate the replacement;
5. revoke the compromised selector with an empty p= or remove it according to the incident plan;
6. verify new signatures and DMARC alignment;
7. search for unauthorized use and affected routes;
8. rotate credentials or systems that shared the exposure path;
9. determine whether source code, build logs, tickets, clipboard history, downloads, backups, or synced storage retained the key;
10. document the public fingerprints, timestamps, owners, and containment decisions.

The ordinary overlap advice changes during compromise. Preserving verification for old legitimate mail must be balanced against preventing continued validation of unauthorized signatures. Incident ownership makes that decision.

## DKIM, SPF, and DMARC are different controls

DKIM associates a signature with the domain in d=. It can survive forwarding when the signed content remains intact. It does not authorize a sending IP.

SPF evaluates whether the connecting client is authorized for the RFC5321 MAIL FROM or HELO identity. It can be disrupted by forwarding. It does not cryptographically bind the message body or visible From header.

DMARC evaluates whether a passing DKIM or SPF identity aligns with the visible RFC5322 From domain and applies the domain's published policy and reporting configuration.

A generated DKIM key therefore does not complete authentication by itself. The signer must use it correctly, the signature must verify, and d= must align if DMARC is intended to use the result.

## What the generator cannot prove

The tool cannot prove:

- that the entered domain is owned by the operator;
- that the selector is unused;
- that a DNS console will accept the displayed presentation syntax;
- that the record has propagated;
- that UDP, TCP, resolver, and DNSSEC behavior is healthy;
- that a provider supports operator-supplied keys;
- that a signer supports the selected algorithm or private format;
- that the signer protects the key;
- that the signer uses the displayed domain and selector;
- that headers and body canonicalize as expected;
- that a delivered signature passes;
- that DKIM aligns for DMARC;
- that every sending stream was migrated;
- that receivers support a chosen transition;
- that key rotation timing is adequate;
- or that authentication produces inbox placement.

Use the [DKIM record checker](https://emailbump.com/tools/dkim-record-checker.md) after publication, the [DNS propagation checker](https://emailbump.com/tools/dns-propagation-checker.md) during the change, and the [email header analyzer](https://emailbump.com/tools/email-header-analyzer.md) on representative delivered messages.

## Export handling

The DNS record export is public and contains the BIND-style owner, TTL, and character-strings.

The JSON manifest is public evidence and contains:

- generation timestamp;
- domain and selector;
- key and signing algorithm;
- public-key size;
- DNS owner, TTL, complete value, zone presentation, and character-strings;
- SHA-256 public-key fingerprints;
- public PEM;
- optional flag state;
- rotation steps;
- and an explicit statement that no private key is included.

The runbook is a compact public handoff for a change ticket. It excludes the secret.

The private PKCS#8 PEM export is separate and explicit. Treat the browser download name as a convenience, not an access-control boundary. Review default download folders, synchronization, backups, malware scanning, retention, and deletion behavior before generating a production key.

## Frequently asked questions

### Should every sending domain have its own key?

Use keys and selectors that preserve clear ownership and contain exposure. Several streams can deliberately share a signing domain and key, but the blast radius and rotation coordination are then shared. Separate providers or independently operated systems generally benefit from separate selectors and often separate keys.

### Can a selector contain dots?

DKIM selectors are composed of DNS labels and can contain periods that create additional labels beneath _domainkey. The generator validates each label and forms the complete owner name. Provider configuration may impose a narrower selector format.

### Can I publish two keys at one selector?

Do not use multiple key records for one selector as a rotation strategy. Publish the replacement under a new selector. RFC 8463 also requires different selectors for parallel RSA and Ed25519 signatures because one selector can have only one key record.

### Is the public key a secret?

No. It is intended for DNS. The public fingerprint and public PEM can appear in deployment evidence. Only the private key enables signing and must remain secret.

### Why does the tool export a public PEM for Ed25519 when DNS uses raw bytes?

General cryptographic tools commonly exchange public keys as SubjectPublicKeyInfo PEM. RFC 8463 defines the DKIM p= value as the base64 Ed25519 public key itself. The tool therefore supplies both representations and fingerprints the representation actually published in p=.

### Should I enable testing mode?

Only when it supports an owned test plan and the limitations are understood. It does not make failures harmless, and receivers may ignore it. Narrow traffic, raw-header evidence, and rollback controls are stronger deployment tools.

### Should I use strict identity mode?

Only if the signer constructs i= identities compatible with t=s and the organization intends to prevent subdomain i= values. It is not a DMARC strict-alignment switch.

### Does a longer RSA key improve deliverability?

No direct inbox benefit follows from choosing RSA 3072 or 4096. Authentication validity, compatibility, key custody, DNS reliability, alignment, sending practices, and receiver evaluation matter. Choose size through security policy and tested system support.

### Can this tool recover a cleared key?

No. Email Bump does not receive the key. Once browser memory is cleared, only copies explicitly exported or retained elsewhere remain.

### What if my email provider gives me CNAME records?

Follow the provider's verified configuration when it hosts and rotates the DKIM public keys. A CNAME-based delegated selector is a different operating model from publishing this generated TXT key. Do not publish a TXT record at the same owner as a CNAME.

### Is a DKIM pass enough for DMARC?

Not by itself. The passing DKIM d= domain must align with the visible From domain according to the DMARC policy's alignment mode. A valid signature from an unrelated provider domain can pass DKIM and still fail the DKIM branch of DMARC.

## Primary standards

- [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html)
- [RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM](https://www.rfc-editor.org/rfc/rfc8301.html)
- [RFC 8463: Ed25519-SHA256 for DKIM](https://www.rfc-editor.org/rfc/rfc8463.html)
- [RFC 1035: Domain Names — Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035.html)
- [RFC 8032: Edwards-Curve Digital Signature Algorithm](https://www.rfc-editor.org/rfc/rfc8032.html)

## Related Email Bump tools and guidance

- [DKIM record checker](https://emailbump.com/tools/dkim-record-checker.md)
- [DNS propagation checker](https://emailbump.com/tools/dns-propagation-checker.md)
- [Email header analyzer](https://emailbump.com/tools/email-header-analyzer.md)
- [DMARC record builder](https://emailbump.com/tools/dmarc-record-builder.md)
- [SPF record generator](https://emailbump.com/tools/spf-record-generator.md)
- [SPF record checker](https://emailbump.com/tools/spf-record-checker.md)
- [Email deliverability readiness audit](https://emailbump.com/tools/email-deliverability-readiness-audit.md)
- [Email migration checklist](https://emailbump.com/tools/email-migration-checklist.md)
- [Sending-domain documentation](https://emailbump.com/docs/domains.md)
- [Deliverability documentation](https://emailbump.com/docs/deliverability.md)
- [DKIM glossary definition](https://emailbump.com/glossary/dkim.md)
- [DMARC glossary definition](https://emailbump.com/glossary/dmarc.md)