DKIM Record Generator

You need an RSA key pair. The public half goes into DNS as a TXT record at selector._domainkey.yourdomain.com, and the private half goes into the system that sends your mail, which uses it to sign every outgoing message. The generator above makes the pair with your browser's built-in Web Crypto implementation, so the private key is created on your machine and never sent anywhere. The traditional alternative is openssl on a command line, which produces the same thing with more steps.

No, and this is the most common wasted hour in DKIM setup. Google Workspace generates the DKIM key itself in the Admin console and gives you the resulting public record to publish. Microsoft 365 generates two key pairs when you enable DKIM for a custom domain, keeps the private keys inaccessible, and has you publish CNAME records that point at Microsoft's own selectors rather than a TXT record you control. Neither accepts an imported key. A key from this generator is for a mail server or platform that asks you to supply one: Postfix with OpenDKIM, an appliance, or your own application.

2048-bit. It is the stronger key and the one Google describes as preferred where the DNS provider supports it. 1024-bit exists as a fallback for panels that cannot store the longer record value, and Microsoft 365 still defaults to 1024 with 2048 available when you rotate. If you have to start at 1024 because of a DNS limitation, treat it as temporary and rotate up once the provider allows the longer value.

A label that lets one domain hold several DKIM keys at the same time. The selector appears in the DNS host name (selector._domainkey.yourdomain.com) and in the s= tag of every signature you send, so receivers know which published key to check. Because the selector is part of the lookup, you can publish a new key under a new selector, switch your signing system over, and retire the old one without a gap in signed mail. That is what makes rotation possible. Different services usually get their own selector.

The key here is produced by the Web Crypto API, the same cryptographic implementation the browser uses for TLS, and it is never sent over the network: there is no API call behind this page and nothing is stored. It is also not saved anywhere, so closing the tab destroys it. What you control is what happens next. Move the key straight into your mail server's secret store, and never paste it into a support ticket, a chat message, or a shared document. If your organization requires keys to be generated on a hardened machine under its own policy, use openssl there instead.

A 2048-bit public key encodes to roughly 400 characters, and a single DNS character-string is capped at 255. The record itself is fine; it just has to be stored as several quoted strings that the DNS server joins back together. Most panels do this automatically when you paste the whole value. A few require you to split it yourself. If a DKIM checker reports the key as truncated or invalid after publishing, that split is almost always the cause.

Rotate on a schedule your team will actually keep, and rotate immediately if a private key is ever exposed. The mechanism is the selector: publish the new public key under a new selector, wait for DNS to propagate, switch the signing system to the new selector, then remove the old record once no mail is signed with it. Microsoft rotates its own keys for you when DKIM is enabled on a custom domain. For keys you manage yourself, rotation is manual unless something automates it.

v=DKIM1 declares the version. k=rsa names the key type. p= carries the public key itself, base64-encoded. Those three are all a working record needs. Two optional tags show up in the wild: t=y marks the key as being tested, which tells receivers not to treat failures harshly, and h= restricts which hash algorithms may be used with the key. Leave both off unless you have a specific reason.

No. DKIM proves a message was signed by a key published for a domain and was not altered in transit. It does not tell receivers what to do when a message fails, and it does not require the signing domain to match the From address a recipient sees. DMARC adds both: alignment between the signing domain and the visible From domain, and a policy receivers act on. Publish DKIM, add SPF, then set a DMARC policy.