DKIM DNS Record Generator

A DKIM public-key record tells receivers where to find the key that matches a mail signer's selector. The owner name usually looks like selector._domainkey.example.com, and the TXT value carries tags such as v=DKIM1, k=, h=, s=, t=, and p=.

Generating the record correctly matters because a small DNS formatting mistake can make otherwise signed mail fail verification. Long RSA keys may need quoted DNS character-string splitting, selector labels must not accidentally include the _domainkey suffix twice, and rollout flags should match the signer's real behavior.

This generator builds publish fields, a DKIM tag ledger, split DNS strings, nsupdate and dig guidance, review checks, normalized inputs, and rollout reminders. It can model RSA, Ed25519, staged testing, strict identity, service scope, hash policy, and selector revocation.

The safest workflow is to treat the generated TXT value as a draft that still needs live DNS verification and a signed-message test. DKIM failures often come from mismatched selectors, stale DNS, wrapped key material, or a signer using a different private key than the one represented by the public key record.

Technical Details:

DKIM key records are DNS TXT records below the _domainkey namespace. The selector chooses the DNS owner name, while the domain identifies the signing domain. The public key belongs in the p= tag after being normalized to the selected key type.

DNS TXT data is carried as one or more character strings, each with a 255-octet ceiling. The generator splits long content into quoted strings and also estimates provider fit so very long RSA records are not pasted as one oversized string.

RSA keys are parsed far enough to estimate key size and flag weak or malformed input. Ed25519 records follow the DKIM Ed25519 key-type convention. Revocation intentionally publishes an empty p= value at the selector owner name.

Everyday Use & Decision Guide:

Use the RSA production preset for a conventional rollout, the staged preset when you want the testing flag, and the revocation preset when a selector should stop validating. Paste only the public key, not a private key. If a signer gives you a full TXT value, compare it with the tag ledger before publishing.

• Keep selectors short, descriptive, and dated enough to support future rotation.
• Use the strict identity flag only when the signer and receiver policy actually require it.
• Prefer sha256-only hash policy unless a legacy signer explicitly needs another option.
• Use Ed25519 only when both the signer and receiving ecosystem support it for your mail flow.
• After publishing, run the generated dig command and send a signed test message that uses the same selector.

Do not publish a record until the owner name matches the zone editor's expectations. Some providers want the full name. Others want only the host label before the zone apex. The publish fields show both forms to reduce that mistake.

Step-by-Step Guide:

1. Enter the signing domain and selector, or paste a selector host and let the fields normalize.
2. Select RSA or Ed25519 and paste the public key material.
3. Choose a deployment preset or set hash policy, service scope, testing mode, strict identity, RSA baseline enforcement, and revocation manually.
4. Review publish fields and split strings before pasting into DNS.
5. Use the DNS ops runbook to verify the TXT record after propagation.

Interpreting Results:

A ready status means the input can produce a syntactically useful DKIM TXT record under the selected options. It does not prove the private key is installed in the mail signer or that outbound mail is signing with that selector.

Key-size warnings should be handled before production use. A short RSA key may still parse, but many receivers and administrators expect stronger keys. Split-string warnings mean the DNS interface, not DKIM itself, may be the first publishing obstacle.

Revocation output is intentionally different from a normal public-key record. An empty p= tag tells verifiers that the selector no longer has a valid public key.

Worked Examples:

Production RSA selector. Domain example.com and selector mail2026 produce owner mail2026._domainkey.example.com with an RSA p= value, sha256 policy, and service scope for email.

Canary rollout. A selector such as mail-canary with testing mode lets administrators publish and verify a new key path before making it the main production signer.

Selector retirement. When a key is compromised or a signer is decommissioned, the revocation preset emits an empty p= value for the same selector owner so stale signatures stop validating.

FAQ:

Can I paste a private key? No. DKIM DNS records publish only the public key. Keep private keys inside the signing system.

Why split the TXT value? DNS TXT records are made of character strings. Long RSA records often need multiple quoted strings even though receivers join them logically.

Does a valid record mean DKIM will pass? Not by itself. The signer must use the matching private key, selector, domain, canonicalization, and headers in the actual message.

Glossary:

Selector

The label that lets a domain publish multiple DKIM keys under _domainkey.

p= tag

The public-key material in a DKIM TXT record.

t=y

Testing flag used during staged DKIM deployment.

Strict identity

A flag that constrains how the key may be used with signing identity.

References:

• RFC 6376 DKIM Signatures
• RFC 8463 Ed25519 for DKIM