DKIM DNS Record Generator

DKIM sits at the point where email authentication meets DNS. When a mail system signs a message, it adds a DKIM signature header that names a signing domain and a selector. A receiving server then uses those two values to find a public key in DNS and check whether the signed parts of the message still match the signature.

The DNS record is not the signature, and it does not prove that a message is wanted, safe, or allowed by policy. It publishes the public key that lets verifiers test a signature created somewhere else. That distinction matters during setup because the DNS value, the private key in the signer, and the selector in live mail all have to describe the same key pair.

A selector lets one domain publish more than one DKIM key at the same time. That is useful for rotating keys, separating vendors, staging a canary rollout, or retiring a compromised selector without breaking every other sender for the domain. The selector is placed before the reserved _domainkey label, so a selector such as mail2026 on example.com is published at mail2026._domainkey.example.com.

A DKIM key record is a tag list inside a DNS TXT record. The p= tag carries the public key. Other tags can name the key algorithm, limit acceptable hash algorithms, restrict the service scope, or mark a selector as testing or strict identity. The private key never belongs in DNS.

A clean DKIM record is only one part of mail authentication. SPF decides whether a sending host is authorized, DMARC tells receivers how to treat aligned authentication results, and DKIM provides a cryptographic check that selected message content still matches the signing domain's key.

How to Use This Tool:

Start with the signer identity and the public key material, then use the generated owner and TXT value in the DNS interface that manages the domain.

1. Enter the signing Domain and Selector. If you paste a full selector host, confirm that Normalized DKIM Inputs separates the selector from the domain instead of duplicating _domainkey.
2. Choose Key type. RSA is the broad compatibility default; Ed25519 should match a signer that actually emits Ed25519 DKIM signatures.
3. Paste the Public key. Base64 public-key data, a PEM public key, or an existing DKIM TXT value can be normalized.
   Stop if the pasted material says PRIVATE KEY. DKIM DNS records publish public keys only.
4. Select a Deployment preset when you want a known starting posture such as RSA production, staged rollout, strict identity, Ed25519 signer, or selector revocation.
5. Use Advanced for the hash policy, service scope, testing flag, strict identity flag, RSA baseline check, or revocation mode. The visible status and review checks update after the change.
6. Read DKIM Publish Fields. Use the Record owner (FQDN) when your DNS workflow expects a full name, and use Zone host label when your provider is already scoped to the zone.
7. Open DNS Split Strings if the TXT value is long.
   Treat the displayed strings as one TXT record, not as separate records with the same owner.
8. Check DKIM Review Checks before copying. A Stop status means the record should not be published until the named domain, selector, key, or size issue is fixed.
9. After DNS is saved and propagated, send a signed test message and compare its DKIM d= domain and s= selector with the generated owner name.

Interpreting Results:

The main result is the DKIM TXT value and the owner name where it belongs. The publish status tells you whether the current inputs can form a coherent DNS record. It does not prove that the matching private key is installed, that outbound mail is signing with the selector, or that receivers already see the DNS change.

Key profile and Key strength are sanity checks, not an end-to-end mail test. A parsed 2048-bit RSA key meets the tool's production baseline, while an Ed25519 key must decode to the expected 32 raw bytes. The live message still has to use the same selector and algorithm.

Cloudflare publish fit is provider-specific guidance based on the visible owner and TXT value. Other DNS providers may accept, reject, wrap, or display long TXT content differently, so use the provider's own save and lookup behavior as the final check.

If live DKIM fails after publication, compare the signed message first. A mismatch in d=, s=, or algorithm is more common than a broken public key format.

Technical Details:

DKIM verification starts with the DKIM-Signature header. The receiver reads the signing domain from d=, the selector from s=, and the query method from q=. The DNS binding defined for DKIM stores keys as TXT records beneath _domainkey, so the selector and domain form the lookup owner.

The key record is a semicolon-separated tag list. Some tags are defaults when omitted, but explicit tags make rollout intent easier to review. The p= tag is the critical value because it contains the public key, or an empty value when a selector is deliberately revoked.

Rule Core:

Tag Map:

TXT Sizing Core:

DNS TXT RDATA is made from one or more character strings. Each TXT character string is limited to 255 octets, so long RSA key records are commonly displayed as adjacent quoted strings that DNS clients join before DKIM uses the value.

For example, a 620-character TXT value needs three quoted strings because two 255-character strings cover only 510 characters. Those strings still represent one TXT record at one owner name.

Provider limits can be stricter or expressed differently than protocol limits. The DNS Ops Runbook estimates Cloudflare-oriented per-record wire size and same-name TXT content checks from the generated owner and TXT value, but another DNS control panel may have its own editor behavior, quoting rules, or validation limits.

Safety and Privacy Notes:

DKIM setup is security-sensitive because it connects DNS, public keys, private keys, and outbound mail systems. Treat the generated record as a DNS publishing aid, not as proof that the whole domain authentication path is complete.

• Only public key material belongs in the Public key field. Private keys should stay in the mail signer or key store.
• The calculation runs in the browser, but changed field values can appear in the address bar for shareable state. Do not share draft URLs that contain key material or sensitive rollout details.
• Keep old selectors published until the old signer has stopped using them and delayed mail no longer needs them.
• Pair DKIM validation with SPF and DMARC checks before treating a domain as fully aligned for production sending.

Worked Examples:

Production RSA selector. A mail administrator enters example.com as Domain, mail2026 as Selector, chooses the RSA production preset, and pastes a 2048-bit RSA public key. Record owner (FQDN) becomes mail2026._domainkey.example.com, TXT value starts with v=DKIM1; k=rsa, and Key strength should pass the 2048-bit baseline.

Staged rollout. A canary selector uses the staged rollout preset so the TXT value includes the testing flag. DKIM Review Checks adds a testing reminder, and DKIM Rollout Reminders points to removing the flag after live signed messages validate.

Ed25519 selector. A compact Ed25519 public key should produce Key profile similar to Ed25519 32B and often fits in one entry under DNS Split Strings. If an RSA PEM is left selected with Ed25519, Key material or Key strength stops publication until the key type is corrected.

Selector retirement. A retired selector uses the selector revocation preset. Publish status changes to Revocation record ready, and the TXT value ends with an empty p=. Publish that only after confirming the signer no longer emits signatures with the selector.

Wrong host field. A DNS provider already scoped to example.com may ask for mail2026._domainkey, while a zone-file or command example may use mail2026._domainkey.example.com. Compare Zone host label and Record owner (FQDN) before saving.

FAQ:

Glossary:

Selector

The DKIM label used with a signing domain to locate a key beneath _domainkey.

Signing domain

The domain named by a DKIM signature and used in the DNS key lookup.

TXT character string

One string inside DNS TXT RDATA, with a 255-octet limit.

Public key

The publishable key material that receivers use to verify signatures.

Revocation

A DKIM key record state where p= is empty so the selector no longer validates signatures.

Strict identity

A DKIM selector flag that asks verifiers to require exact identity-domain matching.

Service scope

The s= tag that limits the selector to email service use or leaves it as any service.

Hash policy

The h= tag that advertises acceptable hash algorithms for the selector.

References:

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, IETF, September 2011.
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM, IETF, January 2018.
• RFC 8463: A New Cryptographic Signature Method for DKIM, IETF, September 2018.
• RFC 1035: Domain Names - Implementation and Specification, IETF, November 1987.
• Cloudflare DNS record type reference, Cloudflare Docs.