DKIM レコード生成ツール
ドメインとセレクターを決め、鍵ペアをローカルで生成して(または既存の公開鍵を貼り付けて)、「セレクター._domainkey.ドメイン」に公開する TXT レコードをコピーしてください。秘密鍵はこのページ内で作成され、ページの外に出ることはありません。レコードは RFC 6376、8301、8463 の DKIM の規定に照らしてチェックします。
鍵はこのブラウザー内で生成されます。秘密鍵が送信されたり、共有リンクに含まれたりすることはありません。Cloudflare の DNS-over-HTTPS リゾルバーに送信されるのはレコード名(セレクター._domainkey.ドメイン)だけで、それも「DNS を確認」を押したときに限られます。
鍵生成ツールを読み込み中…
公開する DNS レコード
ドメインとセレクターを入力すると、レコードが表示されます。
DNS で公開されている内容を確認
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=rsaork=ed25519— the key type (RSA is the default whenk=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=sha256refusesrsa-sha1signatures,s=emaillimits the key to email,t=srequires thei=identity to be exactly the domain, andt=ymarks 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.