{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Algorithm {{ resultsReady ? keyProfileLabel : '—' }} TXT strings {{ resultsReady ? computation.values.dns_string_count : '—' }} Input {{ isDefaultSample ? 'Example only' : 'Custom' }}
Route visual unavailable
Example: example.com.
Example: mail2026. A full selector host is also accepted.
RSA has the broadest deployment support; Ed25519 requires compatible signers and receivers.
Presets change the selector, algorithm, public key, and Advanced tags shown below.
The shipped example key is for demonstration only. Revocation publishes an empty p= value.
The neutral default omits h=. DKIM signers should still use SHA-256.
The neutral default omits s=; use email to constrain this selector explicitly.
The neutral default is off. Remove t=y after the rollout validates.
{{ testing_flag ? 'On' : 'Off' }}
The neutral default is off. Enable only for exact AUID/signing-domain matching.
{{ strict_identity ? 'On' : 'Off' }}
Owner{{ ownerFqdn }}
Zone host{{ zoneHostLabel }}
TypeTXT
{{ txtValue }}

The chart renderer is unavailable. Exact tag lengths remain available in the tag ledger.

TagValueCharactersMeaningCopy
{{ row.tag }}{{ row.value }}{{ row.characters }}{{ row.detail }}
ChunkLengthQuoted DNS stringCopy
{{ row.chunk }}{{ row.length }}{{ row.quoted }}
{{ opsRunbook }}
CheckStatusDetailCopy
{{ row.label }}{{ row.status }}{{ row.detail }}
InputNormalized valuePurposeCopy
{{ row.label }}{{ row.value }}{{ row.detail }}
StepReminderWhy it mattersCopy
{{ row.step }}{{ row.label }}{{ row.detail }}
DKIM Validation Report Check a DKIM selector in public DNS and review its record count, key strength and policy tags with clear testing and resolver evidence.
DMARC DNS Record Generator Build a current or legacy DMARC TXT record with policy inheritance and reporting destinations plus DNS string splitting and rollout review.
SPF Record Generator Build an SPF TXT record from real sender paths with ordered mechanisms and lookup-budget planning plus DNS packaging and rollout checks.
Bulk Sender Requirements Checker Check bulk sender readiness for Gmail, Yahoo and Outlook using delivered headers plus DNS, complaint-rate and unsubscribe evidence before launch.

A valid DomainKeys Identified Mail (DKIM) signature depends on a public key published at exactly the DNS name named by the message's signing domain and selector. The selector lets one domain use several keys at once, which makes rotation, provider separation, and staged rollout possible without changing the domain in every signature.

The public DNS record contains a verification key, not the private key used by the mail signer. A receiving server reads the d= domain and s= selector from the message signature, queries selector._domainkey.domain for TXT data, and uses the published key to check the signature. A record at the wrong owner name is as unusable as a wrong key.

ElementPurposeCommon mistake
Signing domainNames the domain taking responsibility for the signature.Publishing under a different organizational or sending domain.
SelectorChooses one key within the signing domain.The signer uses a selector that does not match the DNS owner.
Public keyLets receivers verify the signature.Publishing a demonstration key, malformed key, or private key material.
Rollout stateSupports testing, strict identity, or revocation.Leaving testing mode in place or revoking a selector still used by active senders.

RSA remains widely deployed, while Ed25519 uses a much shorter 32-byte public key and requires compatible signing and receiving systems. Current DKIM guidance requires RSA keys of at least 1,024 bits and recommends at least 2,048 bits. SHA-256 is the current signing hash; SHA-1 is not an acceptable fallback.

Long TXT values may be split into several quoted character strings. Those strings still form one TXT record and are concatenated without inserted spaces by DNS consumers. Publishing several separate TXT records at the selector is different and can make verification ambiguous.

How to Use This Tool:

Begin with the signer configuration, because its domain, selector, algorithm, and public key must agree with DNS.

  1. Enter the signing Domain and Selector. A full selector host such as mail2026._domainkey.example.com is accepted and normalized.
  2. Select RSA or Ed25519 and paste base64 public-key data, a public-key PEM, or an existing DKIM TXT value. Never paste a private key.
  3. Choose a deployment preset or set the optional hash, service, testing, and strict-identity tags deliberately. Replace every demonstration key before publication.
  4. Review the owner name, TXT value, key-strength result, string splits, and rollout checks. Split strings belong in one TXT record.
  5. Publish the record, query the exact selector owner from DNS, and send a signed test message. Confirm its d=, s=, and a= values match the published record.

Interpreting Results:

Record ready to publish means the inputs are structurally valid and the local checks have no active review finding. It does not prove that the DNS provider accepted the record, the matching private key is installed, or a real message verifies.

  • Review before publish can indicate the demonstration key, an RSA key below the recommended 2,048-bit baseline, testing mode, strict identity, or a size concern.
  • Revocation record ready means the record contains an empty p=. Publish it only after every active sender has stopped using that selector.
  • When a provider shows several quoted strings, query the live TXT answer and join strings from the same record without spaces before comparing it with the generated value.

Technical Details:

A DKIM key record is a semicolon-separated tag list stored in DNS TXT data. The selector owner is derived from two normalized DNS names, and the key bytes are checked against the selected algorithm before the record is composed.

Transformation Core:

  1. Lowercase the domain and selector, remove trailing dots, and extract the two parts if a full selector._domainkey.domain name was entered.
  2. Reject invalid DNS labels and owner names longer than 253 display characters.
  3. Extract public-key material from base64, public-key PEM, or the p= part of an existing DKIM record. Remove encoding whitespace and normalize the key bytes.
  4. Validate the algorithm and key length, then assemble the tag list in a fixed order.
  5. Join tags with semicolon-space separators and divide the TXT value into strings no longer than 255 characters.

Rule Core:

TagEmitted valueCondition or meaning
v=DKIM1Always first.
k=rsa or ed25519Must agree with the signer's algorithm and the supplied public key.
h=sha256Included only when SHA-256-only policy is selected; otherwise omitted.
s=emailIncluded only when the selector is explicitly limited to email service.
t=y, s, or y:sy marks testing mode; s requires exact AUID and signing-domain identity.
p=Normalized base64 public keyAn empty value revokes the selector.

RSA input may be a DER RSAPublicKey or a SubjectPublicKeyInfo public key. Keys below 1,024 bits are rejected; keys from 1,024 through 2,047 bits are accepted with a review finding. Ed25519 input must decode to exactly 32 public-key bytes. Private-key PEM blocks and algorithm mismatches are rejected.

Formula Core:

TXT splitting and the displayed wire-size estimate make record length auditable before publication.

Nstrings = ⌈ LTXT255 ⌉
Brecord = Bowner +10+ ∑i=1Nstrings (Li+1)

The estimate adds the encoded owner-name length, a fixed 10-byte record allowance, and one length byte plus content bytes for each character string. The publish-fit review compares this estimate with 4,096 bytes and the complete TXT content with 8,192 characters.

Safety and Privacy Notes:

DKIM public keys are meant to be published. Private keys must stay on the signing system or in its protected key store.

  • The generator processes the entered record data locally and rejects text that looks like a private-key PEM block.
  • That rejection is a guardrail, not a key-handling system. If private material was pasted into any untrusted page, rotate the key and investigate the exposure.
  • Testing mode is temporary. Remove t=y after real message flow validates, and enable t=s only when exact identity matching is intended.
  • DNS publication is not complete until authoritative queries return one correct TXT record and a signed test message passes verification.

Worked Examples:

Production RSA selector

For domain example.com and selector mail2026, the owner is mail2026._domainkey.example.com. A valid 2,048-bit RSA public key with SHA-256 and email scope produces tags beginning v=DKIM1; k=rsa; h=sha256; s=email, followed by p= and the normalized public key. Any split strings are published together as one TXT record.

Retired selector

After senders stop using mail2026, the revocation preset emits v=DKIM1; k=rsa; p= at the same owner. The empty public-key value tells verifiers that the selector no longer has a usable key; publishing it too early breaks signatures that still name that selector.

References: