Aller au contenu
ecdsa.com

DKIM Record Generator — générateur d’enregistrements DKIM

Choisissez votre domaine et un sélecteur, générez une paire de clés en local (ou collez la clé publique dont vous disposez déjà), puis copiez l’enregistrement TXT à publier sous sélecteur._domainkey.domaine. La clé privée est créée dans cette page et ne la quitte jamais ; l’enregistrement est vérifié selon les règles DKIM des RFC 6376, 8301 et 8463.

Les clés sont générées dans ce navigateur ; la clé privée n’est jamais envoyée ni placée dans un lien de partage. Seul le nom de l’enregistrement (sélecteur._domainkey.domaine) est envoyé au résolveur DNS-over-HTTPS de Cloudflare, et uniquement lorsque vous appuyez sur « Vérifier le DNS ».

Chargement du générateur de clés…

Options de l’enregistrement

L’enregistrement DNS à publier

Saisissez un domaine et un sélecteur pour obtenir l’enregistrement.

Vérifier ce que publie le DNS

Saisissez un domaine et un sélecteur valides pour vérifier le DNS.

What you publish, and where

A DKIM signer holds a private key; receivers find the matching public key in DNS. The record is a TXT record at selector._domainkey.domain (RFC 6376 §3.6). The domain is the d= your signatures carry — usually the domain of the From address, so that the signature is aligned for DMARC. The selector is a name you pick; it is written into every signature as s=, and it lets one domain publish several keys at once.

The record itself is a tag list:

  • v=DKIM1 — the version; optional, but when present it must come first;
  • k=rsa or k=ed25519 — the key type (RSA is the default when k= is absent);
  • p= — the public key in base64: an RSA SubjectPublicKeyInfo, or the raw 32 bytes of an Ed25519 key (RFC 8463);
  • optional restrictions: h=sha256 refuses rsa-sha1 signatures, s=email limits the key to email, t=s requires the i= identity to be exactly the domain, and t=y marks the domain as testing, which tells receivers to treat signed mail as unsigned.

An empty p= revokes the selector: every signature made with the old key must then fail.

Which key to choose

RFC 8301 settles the minimum: receivers must not accept rsa-sha1, must not accept RSA keys under 1024 bits, and signers should use at least 2048 bits. RSA 2048 is therefore the default here, and what every receiver verifies. 3072 and 4096 bits work, but the record grows past what some DNS providers handle comfortably, for no practical gain in a key you rotate anyway.

Ed25519 keys are 32 bytes, so the record fits in a single string, and signing is fast. Not every receiver verifies Ed25519 signatures yet, though, so RFC 8463 deployments sign twice: once with RSA under one selector and once with Ed25519 under another. A receiver that does not know Ed25519 ignores that signature and checks the RSA one.

Why long records are split

A TXT record is a sequence of character-strings, and each string holds at most 255 bytes (RFC 1035 §3.3). A 2048-bit RSA key makes a record of about 410 characters, so it has to be published as two strings or more. Verifiers join them without any separator (RFC 6376 §3.6.2.2). Most DNS providers split a long value for you; in a zone file you write the strings yourself, quoted, inside parentheses — which is the BIND line the generator gives you.

The usual mistakes are a space or a line break added at the joint, a quote character left inside the value, or a value cut off at 255 characters. Each one changes p= and every signature fails with "key syntax error" or "no key". After publishing, press "Check DNS": the generator reads the record back through DNS-over-HTTPS, joins its strings as a verifier does, and compares the key with the one you generated.

Selectors and rotation

Keys should be rotated, and DKIM makes that painless if every key gets a new selector. Publish the new record first, switch the signer to the new selector, and keep the old record for a few days so that messages still in transit can be verified; then revoke it with an empty p= or remove it. Date-based selectors such as s202610 say when a key was introduced and never collide. The generator suggests them for the current month.

Configuring the signer

The private key goes to whatever signs your mail: OpenDKIM, rspamd, Postfix with a milter, or your email service's control panel. The generator writes a minimal OpenDKIM KeyTable and SigningTable and an rspamd dkim_signing.conf section for the selector and domain you entered; adjust the key path to where you install the file. The DKIM debugger then shows, step by step, whether a message signed with the new key verifies.

What stays in your browser

The key pair is generated in this page: RSA through the browser's WebCrypto, Ed25519 with the audited @noble/curves library and the browser's random number generator. The private key exists only in the page's memory. It is never sent, never stored, and never written into a share link — the link carries the domain, the selector and the options, and the Share button says when it left the key out. Download or copy the key before you leave the page.

The only request the page can make is the "Check DNS" lookup: it asks Cloudflare's resolver over DNS-over-HTTPS for the TXT record at selector._domainkey.domain. That name is public, and it is the only thing sent.