Log inTry the sandbox free

Email authentication

DKIM key generator

Generate a DKIM keypair in your own browser and get the record to publish.

Free, no accountIn your browser

Generated with your browser’s own Web Crypto. Nothing is sent anywhere - open your browser’s network panel and press Generate to check for yourself.

The same base64 value DKIM’s "p=" tag needs - no "BEGIN PUBLIC KEY" header.

Give this to your mail server or ESP’s DKIM setup. Never paste it anywhere else.

Try

Result

The result appears here once you press Generate keypair.

What this is

This DKIM key generator makes the keypair in your own browser with Web Crypto, so the private half never leaves the tab: the code that generates it is handed no network of any kind, which you can confirm by opening your browser’s network panel before you press the button.

DKIM signs each outgoing message with a private key held by whatever sends your mail, and publishes the matching public key as a TXT record - RFC 6376 §3.6.2.1 builds its name from the signature’s own tags, so a selector of "foo.bar" on the domain "example.com" is looked up at "foo.bar._domainkey.example.com". The keypair here is those two halves: one to install, one to publish.

RSA at 2048 bits is what RFC 8301 §3.2 tells signers to use. 1024 bits is the floor it still permits - below that, §3.2 says a verifier must not treat the signature as valid at all - which is why it is offered here to reproduce an existing key and flagged for anything else. Ed25519, added by RFC 8463, carries a 256-bit key in 44 base64 characters, short enough that §3 notes the record generally fits one TXT string.

How to read the result

The record is shown at "<selector>._domainkey.<yourdomain>" because neither name is this tool’s to guess: the selector is whatever label your mail provider assigns when it sets up signing, and the domain is yours. Swap both in and leave the "v=DKIM1; k=…; p=…" value itself exactly as it is.

A red verdict is about the key rather than the record. A 1024-bit key builds a perfectly well-formed record and is still a failure here, because what RFC 8301 §3.2 asks of a signer making a new key is stricter than what a parser will accept from an old one.

Common mistakes

What goes wrong most often, and how to tell.

  • Sending the private key through email or a support ticketThe private half is the one thing that proves a message came from you; a copy in an inbox, a chat or a ticket queue is a copy outside your control. Generate it where it will be installed, paste it straight into the provider’s setup field, and generate a fresh pair if it ever goes anywhere else.
  • Turning signing on before the record resolvesMail signed with a key that is not published yet fails verification exactly like mail signed with the wrong key, and DNS does not publish instantly. Publish, confirm the record is readable, and only then let the sender start signing.
  • Publishing the PEM text instead of the base64A public key pasted with its "BEGIN PUBLIC KEY" lines and line breaks still looks right to a person and is not what "p=" takes: the tag holds the base64 on its own. This tool strips the headers if you paste a PEM block, but a DNS editor will not.
  • Switching a live selector to Ed25519 to shorten the recordThe record is shorter and that is the only part this tool can promise. Whether the mailbox providers your mail actually reaches verify an Ed25519 signature is not something checked here, so move a selector that is already signing only after your provider confirms it, or publish the new key at a new selector first.

How it works

  1. 1. Choose a key type and generateRSA 2048 unless your provider asks for something else. The keypair is made in this tab; both values appear in the fields, and you can press the button again for a different pair before you publish anything.
  2. 2. Publish the public half firstCopy the TXT record, replace the selector and domain placeholders with the real ones, and publish it. Check it resolves before the next step - a signature is checked against DNS, so a key that is not there yet fails like a wrong one.
  3. 3. Install the private half, then verifyPaste the private key into your mail server or ESP’s DKIM setup and turn signing on. Then read the published key back with the DKIM checker and send yourself a message to confirm a signature arrives.

Questions

What people ask about this tool.

  • Yes, by your browser’s own Web Crypto. The generate step is a function of the form’s values and nothing else - it is handed no network client at all, so there is nothing in it that could upload a key. Open the network panel and press the button: no request is made.

  • RSA 2048 is the safe default: RFC 8301 §3.2 tells signers to use it and every verifier supports it. Ed25519 produces a much shorter record, and RFC 8463 §5 says verifiers must implement it, but that is a specification requirement rather than evidence about any particular mailbox provider - check with yours first.

  • No interval is stated here because none was found in the standards. RFC 6376 §3.3.3 says only that keys can be replaced on a regular basis and their lifetime can be relatively short. Pick a schedule with your mail provider, publish the new key at a new selector, and retire the old record once nothing signs with it.

  • Yes. A single TXT character-string tops out at 255 octets and a 2048-bit key record is longer than that, so the record is published as more than one string - RFC 6376 §3.6.2.2 says those strings are concatenated with no whitespace before use. RFC 8301 §1 notes that some DNS configuration software handles only one string, which is the practical problem, not a protocol limit.

  • That is the DER SubjectPublicKeyInfo header, the same thing "openssl rsa -pubout" writes. RFC 6376 §3.6.1 describes the "p=" value for RSA as an RSAPublicKey, while the sample record in RFC 8463 Appendix A.2 is a SubjectPublicKeyInfo - and that is what deployed verifiers accept, so it is what this generates.

Sources

Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.

Use it from the API

The same check, as one request.

Request
curl -X POST https://resellerhq.com/api/tools/dkim-key-generator \
  -H "Content-Type: application/json" \
  -d '{"keyType":"rsa-2048","publicKey":"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAquFSbqKbe5ja/GSNxuh/3xObx6gVd5X/aZM1vDaMsteu862FWqgk2CMAszZJNjdppqYcTNAI9LC43XEBX5WY1eUEvDSZ7Yor9vEAn9pZzJO5SUusSRY32dqztMIOB2VDuMJ05+KvU97vbwrkVSvPYGE9LY9RgT0V6Ugh4jPsXZkkZUvnq2tkqREQjrQ7/rNMq822GS/PzUcs/RBJzRsVZCutcVXOb4BIVobHpWXSgI5TPVvGnw5nrRNZYrwMoWM+PfjbroT7XGQFRNvLAkn4XCc+saur37ElPt6RCBaYdJ067YYDEy+RdK6KfFpFOC1LoHeHsUfkTnAkVFf1KoXJFQIDAQAB","privateKey":""}'
Response
{
  "tool": "dkim-key-generator",
  "input": {
    "keyType": "rsa-2048",
    "publicKey": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAquFSbqKbe5ja/GSNxuh/3xObx6gVd5X/aZM1vDaMsteu862FWqgk2CMAszZJNjdppqYcTNAI9LC43XEBX5WY1eUEvDSZ7Yor9vEAn9pZzJO5SUusSRY32dqztMIOB2VDuMJ05+KvU97vbwrkVSvPYGE9LY9RgT0V6Ugh4jPsXZkkZUvnq2tkqREQjrQ7/rNMq822GS/PzUcs/RBJzRsVZCutcVXOb4BIVobHpWXSgI5TPVvGnw5nrRNZYrwMoWM+PfjbroT7XGQFRNvLAkn4XCc+saur37ElPt6RCBaYdJ067YYDEy+RdK6KfFpFOC1LoHeHsUfkTnAkVFf1KoXJFQIDAQAB",
    "privateKey": ""
  },
  "result": {
    "verdict": {
      "tone": "success",
      "headline": "2048-bit RSA key, ready to publish",
      "summary": "Publish the TXT record below, then give the private key to whatever sends your mail."
    },
    "findings": [
      {
        "id": "publish-before-signing",
        "severity": "info",
        "title": "Publish the record before you turn signing on",
        "detail": "A verifier fetches the key out of DNS using the selector in the message it is checking (RFC 6376 §3.6.2.1), so mail signed before the record resolves is mail signed with a key nobody can find - which fails exactly like a wrong key."
      },
      {
        "id": "key-ready-to-publish",
        "severity": "pass",
        "title": "2048-bit RSA key ready to publish",
        "detail": "The modulus read back out of this key is 2048 bits, which meets what RFC 8301 §3.2 asks a signer to use, and it signs with rsa-sha256 as §3.1 requires."
      }
    ],
    "parts": [
      {
        "kind": "record",
        "title": "DKIM TXT record to publish",
        "value": "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAquFSbqKbe5ja/GSNxuh/3xObx6gVd5X/aZM1vDaMsteu862FWqgk2CMAszZJNjdppqYcTNAI9LC43XEBX5WY1eUEvDSZ7Yor9vEAn9pZzJO5SUusSRY32dqztMIOB2VDuMJ05+KvU97vbwrkVSvPYGE9LY9RgT0V6Ugh4jPsXZkkZUvnq2tkqREQjrQ7/rNMq822GS/PzUcs/RBJzRsVZCutcVXOb4BIVobHpWXSgI5TPVvGnw5nrRNZYrwMoWM+PfjbroT7XGQFRNvLAkn4XCc+saur37ElPt6RCBaYdJ067YYDEy+RdK6KfFpFOC1LoHeHsUfkTnAkVFf1KoXJFQIDAQAB",
        "note": "Swap in the selector your mail provider assigns and your own domain. If your DNS provider splits a record this long into several strings, that is fine - RFC 6376 §3.6.2.2 says a verifier joins them with no whitespace before use, so it is still one key.",
        "at": {
          "name": "<selector>._domainkey.<yourdomain>",
          "type": "TXT"
        }
      },
      {
        "kind": "facts",
        "title": "What was generated",
        "rows": [
          [
            "Key type",
            "2048-bit RSA"
          ],
          [
            "Record tag",
            "k=rsa"
          ],
          [
            "Public key",
            "392 base64 characters"
          ],
          [
            "Record",
            "410 characters"
          ]
        ]
      }
    ],
    "limits": [
      "Only you can install the private key on the server or ESP that sends your mail - this tool cannot tell whether it ever is, or whether anything is signing with it. Read the published key back with the DKIM checker once your provider says signing is on.",
      "The two fields are read as text, not as a pair: nothing here proves the private key above belongs to this public key, so a pasted half from somewhere else still produces a record."
    ]
  }
}

Resell mailbox licences for the domains you just checked, under your own brand.

Get started

Company names and logos are trademarks of their owners, shown only to identify each service.