DKIM record generator

Generates an RSA signing key pair inside your browser using the built-in Web Crypto API. The public half goes into DNS, the private half goes on your mail server. The private key is never sent to us, never stored and never logged.

The domain your mail is signed for.

A label that lets you publish more than one key at a time, so you can rotate without downtime. Common choices are default, s1, or a date such as 2026a.

Use 2048 unless your mail server cannot handle it. 1024 is considered weak.

Fill in the fields and select Generate key pair. The record for default._domainkey.yourcompany.com appears here.

What this covers in your audit

Message signing supports SOC 2 Trust Services Criteria CC6.6 and CC6.7, and ISO 27001:2022 Annex A 8.20 and A 5.14.

DKIM speaks to the integrity of messages in transit. A signature that verifies shows the message was sent by a system holding the domain's private key and was not altered on the way.

It contributes evidence toward those controls rather than satisfying them. An auditor will also look at how the private key is stored, who can reach it, and whether selectors are rotated.

What you need to know

What a selector is, and why you rotate it

A selector is a label that lets one domain publish several DKIM keys at once. The record lives at <selector>._domainkey.yourdomain.com, and every signed message names its selector in the signature header, so the receiver knows which key to fetch. Because you can publish a second selector alongside the first, you can rotate keys with no downtime: publish the new selector, switch the mail server to sign with it, confirm mail still verifies, then remove the old record. Common names are "default", "s1", or a date such as "2026a".

The private key goes on the mail server, not in DNS

Only the public key belongs in the TXT record. The private key is installed on whatever signs your outgoing mail: Postfix with OpenDKIM, Exim, an appliance, or your sending platform's configuration. Anyone who obtains the private key can sign mail as your domain, so treat it like a password: never email it, never paste it into a ticket or a chat, and never commit it to a repository. If it is ever exposed, generate a new key under a new selector and remove the old record.

Most providers generate DKIM keys for you

Google Workspace, Microsoft 365, SendGrid, Mailchimp and similar services generate the key pair themselves and show you the exact record to publish. Use theirs when you are on one of those platforms. This tool is for self-hosted mail servers and custom setups where you control the signing software and need to produce the key pair yourself.

Key length and DNS

2048 bits is the current recommendation and what you should use. 1024 is offered only for older mail servers that cannot handle a longer key; it is considered weak. A 2048-bit key produces a TXT value longer than the 255-character limit of a single DNS string, so most DNS providers split it automatically. If yours does not, split the p= value into quoted 255-character chunks; they are concatenated when read.

DKIM is one of three

DKIM proves a message was not altered and really came from your domain. It works alongside SPF, which lists the servers allowed to send, and DMARC, which tells receivers what to do when either check fails. Publishing DKIM on its own changes very little until a DMARC policy is enforcing.