DKIM Record Generator generate a 2048-bit keypair and build the TXT record
Generate a DKIM keypair and a valid RFC 6376 TXT record from a guided form. Pick a selector, choose a 2048-bit RSA key, and copy a record that publishes cleanly at selector._domainkey.yourdomain. The keypair is generated locally with the WebCrypto API, the private key is never sent anywhere, and the public key is encoded straight into the record. Built for teams hardening their email authentication stack alongside SPF and DMARC.
No credit card required. Free plan available forever.
Used to build the TXT record host. The record itself is published at selector._domainkey of this domain.
A short label so a domain can publish more than one DKIM key at a time. Each sending platform picks its own.
RSA keypair
Generated locally with the WebCrypto API. The private key is never sent anywhere. Use this only for self-hosted signing (OpenDKIM, Postfix). For Google Workspace, Microsoft 365, Mailgun, SendGrid, or SES, generate the key on the platform itself.
Generated DKIM record
Generate a keypair to build the record
Key size
2048-bit
Record length
0 chars
TXT segments
0
default._domainkey.yourdomain.com.
Most DNS providers accept just default._domainkey in the host field. The fully qualified form is shown for clarity.
Click Generate keypair above to build the public key and the TXT record value.
Everything runs in your browser. The private key is never sent to a server. The public key, the record, and the host are all derived locally.
How to roll out DKIM
DKIM is a public-key signature on every outbound message. The private half lives on the sending mail platform. The public half lives in DNS. Every receiving server reads the message header, fetches the public key, and verifies the signature. The rollout that survives a hostile audit looks like this.
Inventory every system that sends email as your domain. The mailbox provider, the marketing platform, the transactional senders, the ticketing system, the help-desk integration, and any application that emails customers directly.
For each platform, follow the platform's DKIM setup wizard. Most managed senders generate the key on their own infrastructure and hand you a public key, the selector, and the host to publish. Do not generate keys yourself if the platform offers to do it.
For self-hosted Postfix, OpenDKIM, or rspamd, use this generator to produce a 2048-bit RSA keypair. Keep the private key on the sending host with strict filesystem permissions. Publish the public key as a TXT record at selector._domainkey.yourdomain.com.
Send a test message to a mailbox at a different provider. Read the Authentication-Results header. Confirm the dkim=pass result and that the d= matches your domain.
Pair DKIM with a DMARC record so receivers know what to do when alignment fails. Start at p=none, watch aggregate reports, then move to p=reject once every legitimate sender aligns.
Schedule a key rotation at least every six months. Publish the new selector first, switch the platform to sign with it, wait for in-flight mail to clear, then deactivate the old TXT record.
DKIM tag reference (RFC 6376)
Tag
Meaning
v=DKIM1
Protocol version. Always DKIM1. Recommended as the first tag for clarity.
k=rsa
Key type. RSA is universally supported. Ed25519 is defined by RFC 8463 and is gaining receiver support but is not yet a safe default.
h=sha256
Allowed hash algorithms. sha256 is the modern default. Senders that still need sha1 publish sha256:sha1 and migrate.
s=email
Service types this key is valid for. email restricts use to SMTP. Omit the tag (default *) to allow any service.
t=y
Testing flag. Tells receivers to ignore failures. Useful during rollout. Remove once verified in production traffic.
t=s
Strict mode. Forbids using this key on subdomains of the d= domain. Most operators leave this off.
p=...
Public key, base64-encoded. Required. An empty p= revokes the key without deleting the record.
n=...
Optional notes for administrators. Most operators leave this blank.
Common DKIM record examples
Modern minimal record
The shortest defensible production record: protocol version, hash, service, and the public key. Suitable for most managed senders.
Add t=y while you confirm the record is verifying in production traffic. Remove the tag once Authentication-Results consistently show dkim=pass at remote receivers.
Set the p= tag to an empty string to revoke a key without removing the TXT record. Useful when downstream systems still cache the selector.
v=DKIM1; k=rsa; p=
SPF, DKIM, and DMARC together
DKIM on its own is necessary but not sufficient. SPF authorises sending IPs. DKIM signs the message. DMARC ties them to the visible From: header and tells receivers what to do when neither aligns. Modern email authentication needs all three. The rollout order that has aged best across audits is SPF first, DKIM second, DMARC third, and DMARC enforcement (p=quarantine then p=reject) only after aggregate reports show every legitimate sender is aligning.
M3AAWG recommends rotating DKIM keys at least every six months. Rotation is most safely done by publishing a new selector, switching the sending platform to sign with the new selector, waiting long enough for in-flight mail to clear at downstream receivers, and then either deleting the old TXT record or marking it as testing. Avoid overwriting the same selector in place; any message in transit signed with the previous key will fail at receivers that fetch the new public key. For self-hosted signers, store the private key with mode 0600, never commit it to source control, and treat it as a secret on par with API keys to your billing system.
Related security resources
DKIM is one piece of a domain's email security posture. These pages cover the rest of the stack and the workflow that wraps around it.
At selector._domainkey.yourdomain.com, as a TXT record. The selector is whatever short label your sending platform uses. Most DNS providers accept just the host portion (for example default._domainkey) without the full domain suffix.
Should I use 1024 or 2048-bit keys?
2048. M3AAWG and modern guidance recommend 2048-bit RSA for new keys; 1024-bit is treated as legacy. The only time 1024 is operationally tolerable is on a DNS provider that genuinely cannot publish a TXT record longer than 255 characters in a single string and refuses to stitch segments.
Can a domain publish more than one DKIM key?
Yes, and most production domains do. Each sending platform uses its own selector, so the public keys live at different TXT names. A domain that sends through Google Workspace, Mailgun, and a self-hosted application typically has three selectors live at the same time.
How do I rotate a DKIM key safely?
Generate a new keypair under a new selector. Publish the new public key. Switch the sending platform to sign with the new selector. Wait long enough for in-flight mail to clear at downstream receivers (24 hours is a safe minimum). Then delete the old TXT record or mark it as testing. Never overwrite the same selector in place during rotation.
What if my DNS provider truncates long TXT records?
The DKIM record value is split into 255-character segments because that is the on-the-wire limit for a single TXT string. Every modern DNS provider stitches them automatically. If yours does not, paste the value with explicit quoted segments (the BIND form shown by this tool), or migrate to a provider that handles long TXT records cleanly.
How does this generator differ from a DNS analyzer?
The generator builds a record and (optionally) the keypair from scratch. TheDNS security analyzerchecks the record you have already published, including SPF, DKIM, DMARC, and the broader DNS footprint. Use the generator to write the record, then the analyzer to verify what shipped.