guide · dkim setup

How should a product team implement DKIM setup safely?

Set up DKIM by choosing an organizationally owned signing domain and a unique selector for each provider or signing system, generating the key pair in a protected service, publishing only the public key at selector._domainkey.example.com, and configuring the actual outbound path to sign every intended message. Verify the signature against the original message bytes from an external mailbox, confirm the d= domain aligns with the visible From domain when DMARC depends on it, then roll out gradually. Document selector ownership, rotation, revocation, and rollback before production traffic moves.

Map every real outbound path before generating a key

Begin with an inventory, not a DNS record. List each system that can emit mail using the organization's visible From domains: application workers, transactional providers, marketing platforms, support tools, identity systems, ticketing software, relays, and emergency paths. For each one, record its owner, message classes, envelope sender, visible From domain, current DKIM d= domain, selector, signing component, and whether another relay modifies the message afterward. A DKIM key published for one provider does nothing for a different path that never uses its private key. Likewise, a generic provider dashboard showing one verified domain does not prove every tenant, region, stream, template, or fallback is signed. Use controlled samples from every path and preserve their original headers. Decide which paths are authorized before enabling signing; DKIM authenticates a domain's responsibility for a signature, not recipient consent or the truth of the message content.

Choose a signing domain that supports DMARC alignment

The DKIM d= tag identifies the signing domain. Choose a domain the organization controls and can govern over the life of the mail stream. When DMARC will rely on DKIM, the d= domain must align with the domain in the visible RFC 5322 From field under the applicable relaxed or strict alignment rule. A provider-owned signing domain can produce a valid DKIM result yet remain unaligned for the organization's From domain. Decide whether the apex or a purpose-specific subdomain should sign each stream, considering ownership, reputation separation, delegated DNS, and incident isolation. Do not invent extra domains merely to evade a reputation or policy problem. Record the organizational-domain relationship and intended DMARC mode. Test alignment from the final received headers; never infer it only from a selector lookup because the message might use another d= value.

Allocate selectors as operational identities

A selector lets a domain publish multiple keys and change them without replacing one global record. Create a deterministic selector policy that identifies a provider or signer and a rotation generation without leaking secrets. For example, product-a-2026q3 may be clearer than default, but keep names within DNS conventions and your tooling limits. Never reuse one private key across unrelated providers, environments, or tenants merely to reduce DNS records. Maintain a registry with selector, d= domain, purpose, signing service, owner, creation time, algorithm, public-key fingerprint, deployment state, rotation deadline, and retirement evidence. Check the exact selector name before publication: the lookup is `selector._domainkey.signing-domain`. An accidental record at the visible From domain, return-path domain, or wrong DNS zone will not verify the intended signature. Avoid deleting an old selector until delayed mail and retries signed with it have aged out.

Generate and protect the private key

Generate the key pair inside a managed key service or tightly controlled signing system when the provider supports it. The private key must never enter public DNS, source control, browser code, CI output, analytics, ordinary logs, tickets, documents, prompts, or shared chat. Grant signing access only to the mail component that needs the key, separate production from lower environments, and record administrative access. RFC 8301 updates DKIM cryptographic requirements and says signers must use RSA keys of at least 1024 bits and should use at least 2048 bits; it also notes operational DNS constraints around larger keys. Use the current capabilities and recommendations of the selected signer and receiver population rather than copying an obsolete example. If Ed25519 is considered, RFC 8463 defines its DKIM use, but interoperability must be tested and a compatible signature strategy retained where required. Rotation must be possible without exporting the private key.

Publish the public key precisely

Publish a TXT record at the exact `selector._domainkey.signing-domain` owner name. The DKIM key record carries tags such as v=DKIM1, a key type when needed, and p= containing the public-key material without private key wrappers. Follow the signer's exact record format and your DNS provider's quoting behavior. Before saving, check whether the DNS interface automatically appends the zone, splits long strings, or escapes characters. Query the authoritative name servers directly after publication, then query independent recursive resolvers and reconstruct the full TXT value. Multiple character strings in one TXT record are concatenated by DNS clients, while multiple competing resource records can create ambiguity. Preserve the previous answer and TTL for rollback. Do not lower security by publishing a broader key or leaving a test flag in production simply to silence a checker. A visible record proves DNS publication, not that the sender uses the matching private key.

Configure the final signer and signed fields

Configure the component that hands the final message to the outbound transport, or ensure no later component changes signed content. A DKIM signature covers a body hash and the header fields named in h=. RFC 6376 requires the From header field to be signed for a valid signature. Include identity-critical headers appropriate to the product, understand how repeated headers are selected, and avoid signing fields that a necessary downstream system must rewrite unless that transformation is controlled. Choose canonicalization deliberately. Relaxed canonicalization tolerates defined whitespace and header formatting changes, but it does not permit arbitrary body edits. Simple canonicalization is more fragile. Footer insertion, link rewriting, MIME boundary changes, transfer-encoding conversion, subject tags, and line-ending normalization after signing can break verification. Sign the fully rendered message after approved transformations, and prevent untrusted users from selecting d=, s=, header lists, or keys.

Verify original received messages end to end

Send controlled messages through each real production-shaped path to external test mailboxes operated by the team. Preserve the raw original message, not a copied body or reserialized ticket attachment. Inspect the DKIM-Signature d= and s= values, signed-header list, body hash, algorithm, canonicalization, timestamp, and any expiration. Query the public key from an independent network and run a standards-aware verifier against the original bytes. Compare the trusted receiver's Authentication-Results header with your verifier, while respecting RFC 8601 trust boundaries. Test plain text, multipart alternative, expected attachments, Unicode subjects, long headers, templates, tracking transformations, retries, and relay paths. Negative tests should include a deliberately changed signed header in a fixture, a missing selector, an expired or retired selector, and a path that bypasses signing. Never tamper with real customer mail to create a test.

Evaluate DKIM, DMARC, and delivery as separate results

A DKIM pass means the verifier found a valid signature for the identified signing domain over the signed fields and body. It does not authenticate every unsigned header, confirm a human author, prove recipient consent, establish legal compliance, or guarantee acceptance and inbox placement. DMARC separately evaluates whether a passing DKIM or SPF domain aligns with the visible From domain and applies the domain owner's policy. Record at least DKIM result and reason, d= domain, selector, visible From domain, alignment result, SPF result, DMARC result, receiver, and timestamp for controlled tests. Keep full recipient addresses and content out of routine metrics. SMTP provider acceptance, recipient-server acceptance, later bounce, mailbox-folder placement, and engagement are later states. If DKIM passes but mail is rejected or filtered, investigate DMARC alignment, SPF, IP and domain reputation, complaint rate, message policy, rate, and receiver guidance instead of repeatedly rotating keys.

Rotate without creating a verification gap

Use overlapping selectors. First generate a new protected key and publish its public record under a new selector. Verify authoritative and recursive DNS, configure the signer to use the new selector, and send controlled tests through every path. Monitor the proportion of signatures using old and new selectors and their verification outcomes. Keep the old public key available through the maximum queued-message age, retry window, and DNS cache period, plus an explicit safety margin. Then stop all signing with the old selector, confirm no active configuration references it, and retire its record according to policy. Emergency revocation after private-key exposure may require faster removal, traffic pause, provider credential rotation, and incident communication; document that tradeoff in advance. Do not overwrite one selector in place during routine rotation because cached old public keys can fail verification for messages signed with the new private key.

Diagnose failures from the signature outward

For a missing signature, identify whether the message used an unsigned stream, unauthorized From domain, fallback relay, or template path. For key-not-found, check the exact s= and d= lookup, zone delegation, authoritative answer, DNSSEC or resolver errors, and propagation. For body-hash mismatch, compare the pre-signing and received raw MIME to find post-signing transformations. For signature mismatch, verify the published public key matches the active private key and inspect canonicalization and signed headers. For a DKIM pass with DMARC fail, evaluate alignment with the visible From domain. Classify temporary DNS lookup errors separately from persistent configuration faults, and use bounded transport retries only where the SMTP response is transient. Pause the affected stream on cross-domain signing, unknown keys, widespread verification failure, or suspected key exposure. Preserve privacy-minimized evidence and change one variable per controlled retest.

Use your sending system's DKIM documentation

Set up DKIM in the actual sending systems and DNS authority, validate original received messages, and rely on current IETF standards and provider-specific documentation.

Frequently asked questions

Where is a DKIM public key published?

Publish it as a TXT record at selector._domainkey.signing-domain, using the exact selector and d= domain that the outbound signature will contain.

Should a DKIM private key be placed in DNS?

No. DNS contains only public-key material. Keep the private key inside a managed signer or secret boundary with narrowly scoped access and rotation controls.

Can one DKIM selector be reused for every email provider?

Avoid that design. Separate selectors and private keys by provider, signer, environment, or risk boundary so rotation and compromise do not affect unrelated paths.

Does DKIM pass mean DMARC passes?

Not necessarily. DMARC requires the passing DKIM d= domain to align with the visible From domain, unless an aligned SPF pass satisfies DMARC instead.

Why does DKIM fail after a footer or tracking rewrite?

DKIM covers selected headers and a body hash. A downstream modification outside the selected canonicalization rules can invalidate the signature after it was created.

How should DKIM keys be rotated?

Publish and verify a new selector first, switch controlled signing to it, monitor results, retain the old public key through retry and cache windows, then retire it.

Does DKIM determine inbox placement?

No. DKIM supplies scoped domain-signature evidence. Receivers still evaluate DMARC, SPF, reputation, complaints, content, sending rates, and mailbox policy independently before choosing a delivery outcome.

Does a public DNS record prove DKIM signing is active?

No. Validate original received messages against the published key and confirm the d= and s= values in the DKIM-Signature header.

Sources

Continue learning

How to Check DKIM for Application EmailCheck DKIM by inspecting a real signature, querying its selector and domain, verifying the message, reading receiver results, and testing alignment.How to Run a DMARC Check for Application EmailCheck DMARC record discovery, syntax, SPF and DKIM alignment, policy, reports, and real application messages without confusing a DNS lookup with delivery.How to Check an SPF Record for Application EmailCheck the correct SPF domain, syntax, mechanisms, nested DNS budget, source-IP authorization, result, and DMARC alignment for application email.How to Evaluate an Email Deliverability ServiceEvaluate email deliverability services by scope, evidence, authentication, feedback loops, suppressions, privacy, portability, and operational fit.SMTP Mail Protocol: How Application Email MovesLearn how SMTP submission, relay, envelopes, response codes, TLS, retries, and message content shape an application email workflow.