SHA-256 signing profile.
All tools
DKIM / LOCAL KEY CEREMONY / DNS / ROTATIONCreate the key.
Create the key.
Control the handoff.
Generate a real DKIM key pair in this browser, publish only the public half, and leave with exact DNS, fingerprints, and a rotation runbook.
- RSA + Ed25519
- Local-only private key
- Rotation evidence
READY FOR A LOCAL KEY CEREMONY
No private key exists yet.
Confirm the exact signing domain, choose a new selector, and generate. The resulting private key will exist only in this browser tab and any file you explicitly download.
DNS ownereb2026a._domainkey.example.comValid owner-name shape
Each generated chunk is at most 200 ASCII bytes.
SHA-256 over the exact decoded p= bytes.
Prepublish and overlap; never replace in place.
Public DNS artifact
Generated after key creationHost / name
eb2026a._domainkey.example.comSome DNS consoles append the zone automatically. Check their preview before saving.Type and TTL
TXT · 3600Publish one TXT resource record whose quoted character-strings concatenate exactly.TXT value
v=DKIM1; k=rsa; h=sha256; s=email; p=[generate a public key]BIND-style zone record · portability chunks
eb2026a._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; h=sha256; s=email; p=…" )
Parentheses and multiple quoted strings are zone-file presentation syntax. A web DNS console may expect only the unsplit TXT value above.
Public key evidence
Safe to publishSHA-256 fingerprint of published bytes
Generated with the key pair-----BEGIN PUBLIC KEY----- [public key appears here] -----END PUBLIC KEY-----
Private signing key
Secret · unencryptedInstall only in the authorized signer or secret manager. Never put this key in DNS, source control, tickets, chat, screenshots, or a shared download folder.
-----BEGIN PRIVATE KEY----- [private key remains concealed] -----END PRIVATE KEY-----
Rotation sequence
Overlap before retirement- 01Prepublish the new selector
Add the new TXT record without changing the signer. Resolve it from independent recursive DNS paths and retain timestamped evidence.
- 02Install the private key securely
Map this exact selector, domain, and algorithm in the signer. Restrict access and record the public-key fingerprint—not the secret—in the change ticket.
- 03Sign a narrow test stream
Deliver representative messages, inspect raw DKIM-Signature and Authentication-Results headers, and verify d=, s=, a=, body hash, and alignment.
- 04Move production and observe
Enable the new selector, monitor verification by receiver and stream, and keep the old public key available while delayed or forwarded mail may still be checked.
- 05Retire deliberately
Stop old signing first. Remove or revoke the old selector only after the organization's maximum verification window and rollback need have passed.
CHANGE HANDOFF
Export public evidence without accidentally bundling the secret.
The manifest contains DNS, algorithm, timestamp, fingerprint, and rotation notes. The private key is available only through its separate explicit export.
Read the full agent guideWHAT THE STRING DOES
A DKIM record publishes a verifier—not permission to send.
The private key signs selected headers and a body hash. A receiver retrieves the public key at selector._domainkey.domain and checks the signature. The record does not authorize an IP, encrypt a message, prove the visible From address by itself, or guarantee inbox placement.
DMARC can use a valid DKIM result when the signing domain aligns with the visible From domain. That makes the d= choice operationally important, but alignment and signature validity are separate tests.
v=DKIM1Key-record version. It must be the first tag when present.
k=rsa | ed25519How the decoded public bytes must be interpreted.
h=sha256Restricts signatures using this key to SHA-256.
s=emailRestricts the key to the email service type.
p=…Base64 public-key data. An empty value means revoked.
t=y:sOptional testing and strict-identity flags; neither repairs a broken signature.
OPERATOR QUESTIONS
Before you publish.
Key generation is the easy part. Correct ownership, signer configuration, controlled rollout, and evidence make the change safe.
Should I use RSA 2048 or Ed25519?+
RSA 2048 is the broad compatibility default. Ed25519 produces a much smaller DNS record and is standardized for DKIM, but the system that signs your mail must support it. During a transition, use separate selectors and optionally dual-sign.
Why is the RSA p= value the public PEM body?+
DKIM RSA records carry the base64 DER SubjectPublicKeyInfo bytes. A PEM PUBLIC KEY is the same DER object wrapped in labels and line breaks, so removing those wrappers yields the p= material.
Can I paste the parentheses and quotes into my DNS provider?+
Only if the provider accepts zone-file syntax. Many web consoles want one unsplit TXT value and handle storage splitting themselves. Always inspect the saved record through DNS afterward.
Does t=y make a bad key safe to deploy?+
No. Testing mode asks verifiers not to treat messages differently solely because of the testing flag, but they may ignore it. A failed signature remains failed evidence.
How long should old selectors remain published?+
Long enough for the longest plausible delayed, retried, forwarded, queued, or archived verification window in your environment, plus rollback needs. Stop signing with the old key first and use observed evidence rather than a universal timer.
Can Email Bump recover this private key?+
No. This page generates it locally and does not upload it. Once the tab is cleared, only copies you explicitly made remain.