How to Configure DKIM: The Complete Setup Guide

Do not index

A campaign can have a clean list, strong copy, and a healthy sending process, yet still land in spam. When that happens, missing DKIM, a selector mismatch, or a signature domain that fails DMARC alignment is often the silent cause. This guide shows how to configure DKIM, publish the right DNS record, enable signing across common mail platforms, rotate keys without interrupting delivery, and troubleshoot failures that damage inbox placement, sender reputation, conversions, and brand trust.

Table of Contents

Why DKIM Configuration Determines Inbox Placement What the DKIM record actually does Why misalignment costs more than a failed test Generating Keys and Publishing Your DNS Record Generate a 2048-bit RSA key pair Publish the selector record accurately Keep propagation testing controlled Enabling DKIM Signing Across Major Mail Platforms Google Workspace Microsoft 365 A typical ESP Common DKIM Mistakes That Break Deliverability Alignment can fail while DKIM passes Canonicalization must match the mail path Empty keys and malformed DNS values Key Rotation and Signature Verification Use a four-phase rotation Audit key strength before changing selectors How DKIM Fits With SPF and DMARC

Why DKIM Configuration Determines Inbox Placement

DKIM adds a cryptographic signature to outgoing email. The sending server hashes selected headers and the message body. It encrypts that hash with a private key and places the result in the DKIM-Signature header. The receiving server retrieves the public key from DNS, decrypts the signature, and checks whether the message remains intact.

A valid signature doesn't guarantee inbox placement, but a broken signature creates a clear authentication problem for filtering systems. Gmail, Microsoft, and Yahoo evaluate authentication alongside reputation, recipient engagement, content, and sending behavior. A technically valid DKIM signature can still fail DMARC if the signing domain doesn't align with the visible From domain.

What the DKIM record actually does

DKIM follows the selector plus domain plus public key architecture established by RFC 6376, published on 2011-09-01. The selector identifies which public key a receiver should retrieve, while the d= value identifies the domain that signed the message. The public key lives at a hostname such as selector1._domainkey.example.com, not at the domain root. (RFC 6376)

RFC 6376 requires verifiers to support RSA keys from 512 bits through 2048 bits and notes that signers should use long-lived keys of at least 1024 bits. Current configuration practice uses 2048-bit RSA as the sensible default, while RFC 8301 states that verifiers must handle RSA keys from 1024 through 4096 bits. (RFC 8301)

Why misalignment costs more than a failed test

A signature can pass cryptographic verification while failing the policy that controls the visible From address. For example, a message may display From: billing@example.com while carrying d=mailer.vendor.example. The receiver can verify the signature, but DMARC may still fail alignment because the authenticated signing domain doesn't match the organizational domain used by the recipient.

That distinction matters because spam placement reduces the number of people who see and act on a message. Lost visibility can reduce conversions, weaken customer trust, and make future campaigns harder to deliver. Readers who need broader context on reputation and inbox placement can review this practical guide on how to land emails in inbox.

Generating Keys and Publishing Your DNS Record

DKIM setup starts with two assets: a private key held by the signing system and a public key published as a DNS TXT record. A managed mail service may generate and store the key pair for you, but the DNS architecture remains the same. The selector in the message header must point to the record containing the matching public key.

Generate a 2048-bit RSA key pair

For a self-hosted signer, OpenSSL can create the pair:

openssl genrsa -out dkim-private.pem 2048

openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem

Restrict the private file to the mail-signing process. Convert the public key into the base64 value required by the TXT record. With managed DKIM, the provider generates the key internally, while the administrator publishes the selector and public value it supplies.

Selectors should identify the mail stream or rotation generation. Examples include google, s1, mailo1, and k1-2024. Separate marketing and transactional streams should use different selectors when they have different owners, sending paths, or rotation schedules. This separation makes troubleshooting easier and prevents a key change for one stream from affecting another.

Publish the selector record accurately

A zone-file entry can look like this:

selector1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

The tags have distinct jobs:

Tag	Purpose	Example Value	Required
`v`	Identifies the DKIM record version	`DKIM1`	Yes
`k`	Identifies the key type	`rsa`	No, but recommended
`p`	Holds the base64-encoded public key	`MIIBIjANBgkqhkiG9w0BAQE...`	Yes

The p= tag contains the public key receivers use to verify signatures. An empty p= value revokes the key, so it differs from a missing DNS record. See this DKIM p= tag reference.

Long keys may need multiple quoted strings in a zone file:

selector1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=FIRSTPART..." "SECONDPART..."

DNS joins adjacent quoted strings when serving the TXT value. Keep the key continuous, without spaces, line breaks, or changed characters. Check the DNS provider's hostname behavior as well. If the interface appends example.com automatically, entering the full hostname can create an incorrect record such as a duplicated domain.

Provider-specific CNAME records require the same care. Some services expect only the selector as the host, while others provide a complete target and host value. Copy each field according to that provider's format rather than assuming every DNS editor handles names identically.

Keep propagation testing controlled

A short TTL makes initial corrections easier. After the record resolves correctly and stays stable, the DNS owner can raise the TTL under the organization's change-management policy.

Use a dkim checker to confirm that the selector resolves and the public key is parseable. DNS validation proves publication only. Send a test message to verify that the signer uses the same private key, selector, and d= domain required for alignment. During rotation, publish the new selector before changing the signer, so existing mail can continue using the previous record while cached DNS data expires.

Enabling DKIM Signing Across Major Mail Platforms

The DNS record differs by provider, but the operational sequence stays consistent: generate or obtain the key, publish the required record, verify DNS, activate signing, and inspect a received message. Skipping the DNS verification step is a common cause of failed activation and unsigned mail.

Platform	DNS Record Type	Key Management	Activation Method
Google Workspace	TXT	Generated through the administration interface	Activate signing after DNS publication
Microsoft 365	CNAME for two selectors	Managed through the platform's selector infrastructure	Enable per custom domain
Typical ESP	CNAME delegation	Managed by the sending platform	Complete domain authentication in the ESP

Google Workspace

The administrator generates the DKIM configuration inside the Google Workspace administration interface. The interface supplies the selector and public-key TXT value, commonly generates a 2048-bit key, and provides the record that belongs in the domain's DNS.

The sequence is straightforward:

Open the email authentication area in the administration console.

Select the sending domain.

Generate the DKIM record and copy the selector and TXT value.

Publish that value at the exact selector hostname.

Wait for DNS propagation, which Google's guidance describes as potentially taking 48 hours.

Return to the administration console and activate email signing.

Send a test message and inspect Authentication-Results.

The propagation wait matters because activation before resolvers can retrieve the public key leaves receivers unable to validate new signatures. Google Workspace can also sign mail for a domain while another system sends from the same visible From address. That creates a fragmented setup, so each sending stream should have an explicitly assigned selector.

Microsoft 365

Microsoft 365 uses a CNAME-based selector model with selector1 and selector2. The records point to Microsoft's DKIM infrastructure, and the platform uses the selector pair to support signing and operational changes without requiring administrators to publish the private key.

Provider-specific mistakes are common here. Microsoft Learn identifies failures involving the wrong CNAME hostname format, a missing selector2 record, publishing TXT instead of CNAME, a domain mismatch in the CNAME target, and trailing-dot handling. The record must match the exact hostname and target supplied for the custom domain.

Signing is enabled through the Defender portal or PowerShell. Each custom domain requires separate DKIM enablement, even when domains share the same tenant. A DNS lookup that returns a record doesn't prove the domain is active for signing, so the received header remains the final check.

A typical ESP

A typical email service provider uses CNAME delegation. It may request three CNAME records, including a selector hostname and additional records for domain authentication. The provider then serves the public key from its own infrastructure while retaining control of the private key.

The dangerous mistake is appending the root domain to a target that already contains a fully qualified domain name. Some DNS interfaces automatically append the zone name to relative targets, producing a target different from the one supplied by the ESP. The result can be a persistent dkim=fail or an activation screen that never detects the records.

Before enabling the stream, check each CNAME independently, confirm the target resolves, and send a message from the exact authenticated domain. A platform can report that domain authentication is configured while a separate subdomain or mail stream remains unsigned.

Common DKIM Mistakes That Break Deliverability

A DKIM signature can verify successfully while the message still fails DMARC. The usual causes are mismatched domains, altered DNS values, or signing at the wrong point in the mail flow. These problems often stay hidden until a receiving system checks alignment strictly.

Alignment can fail while DKIM passes

Consider this received header:

From: invoices@example.com

DKIM-Signature: v=1; d=mailer.example.net; s=selector1; ...

Authentication-Results: dkim=pass header.d=mailer.example.net; dmarc=fail header.from=example.com

The signature is valid for mailer.example.net, while the visible From domain is example.com. DKIM therefore passes, but the domains do not align for DMARC. Configure the sending service to sign with the visible From domain or an aligned organizational domain. Then inspect a received message and confirm that header.d contains the expected value.

Check alignment for every sending stream, not only the primary domain. A subdomain, transactional route, or separate marketing configuration can produce a valid signature with the wrong signing domain.

Canonicalization must match the mail path

DKIM uses header and body canonicalization as a pair separated by a slash. If only one algorithm is specified, it applies to headers and the body defaults to simple, as defined in the RFC 6376 canonicalization specification.

A message signed with relaxed/simple can tolerate some header whitespace changes but remains sensitive to body formatting. relaxed/relaxed permits more normalization in both areas, though it cannot make arbitrary rewriting safe. Mailing lists, footer systems, tracking layers, and forwarding services may modify the body after signing, causing an error such as:

dkim=fail (body hash did not verify)

Identify the system that changed the message and place DKIM signing after the final expected content transformation where the mail architecture allows it. Signing too early leaves every later body change capable of invalidating the hash.

Empty keys and malformed DNS values

This DNS record revokes the selector's usable public key:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p="

A blank p= value gives receivers no key with which to verify the signature. Other quiet failures include truncated public keys, line breaks inserted into a base64 value, trailing whitespace, and DNS interfaces that append the root domain twice.

Use diagnostic commands that identify both the selector and signing domain:

dig TXT selector1._domainkey.example.com +short

opendkim-testadsp -d example.com

The first command shows what DNS serves. The second can help inspect policy behavior in an OpenDKIM environment. For a production test, compare the s= selector and d= domain in the received header with the DNS hostname queried for the public key.

Mistake	Symptom	Root Cause	Fix
Wrong `d=` domain	DKIM passes, DMARC fails	Signing domain isn't aligned	Sign with the visible or aligned From domain
Missing selector	`dkim=none` or key-not-found error	Header selector has no DNS record	Publish the exact selector hostname
Empty `p=`	Verification fails or key is revoked	Public key value is blank	Restore the complete public key
Body hash mismatch	`dkim=fail` after relay	Message body changed after signing	Sign after the final expected modification
Incorrect CNAME	Provider can't validate domain	Target or hostname was altered	Recreate the exact CNAME values

Key Rotation and Signature Verification

Key rotation protects the signing system without requiring a disruptive change to the visible From address. The safe pattern is to introduce a new selector before removing the old one, allowing messages signed under the old selector to continue validating while caches and queued mail clear.

Use a four-phase rotation

A self-hosted system can generate a new key with:

opendkim-genkey -b 2048 -d example.com -D /etc/opendkim/keys/example.com -s k1-2024 -v

The production sequence is:

Generate the new private and public key files under a fresh selector.

Publish the new selector's TXT record alongside the existing record.

Wait for DNS propagation and verify the new record from independent resolvers.

Switch the signing configuration to the new selector, then retain the old record until no legitimate mail depends on it.

Separate selectors for marketing and transactional streams reduce operational coupling. Guidance also commonly recommends rotating keys every 6 to 12 months to limit exposure and simplify incident response. (DKIM selector and rotation guidance)

Audit key strength before changing selectors

A 1024-bit key still appears in legacy configurations because RFC 6376 established support for it and RFC 8301 requires verifiers to handle it. New deployments should use 2048-bit RSA where the provider supports it. A key-length audit should inspect the public key returned by DNS and the key configured on the signing server, not just the provider's dashboard label.

For every rotation, confirm:

DNS visibility: The new selector returns the complete public key.

Header match: New mail contains the intended s= selector.

Domain alignment: The d= value aligns with the visible From domain.

Cryptographic result: The receiver reports dkim=pass.

Old-mail coverage: The former selector remains available while older messages may still be evaluated.

Configuration cleanup: The old private key is removed only after the safe retention period.

A received message provides the strongest evidence. Inspect DKIM-Signature for d=, s=, c=, and bh=, then inspect the receiver's Authentication-Results header. A body hash mismatch points toward transit modification, while dkim=fail (no key for signature) points toward selector publication or DNS formatting.

How DKIM Fits With SPF and DMARC

SPF checks whether the sending IP is authorized by the envelope domain's DNS policy. It helps identify unauthorized sending hosts, but forwarding can change the connecting IP, and SPF doesn't authenticate the visible From address. SPF remains useful, but it can't replace DKIM.

DKIM authenticates message integrity and associates the message with a signing domain. It can remain useful through forwarding when the message isn't modified, although intermediaries that rewrite headers or bodies can invalidate the signature. DMARC then evaluates whether SPF or DKIM passes and aligns with the visible From domain, applies a policy such as none, quarantine, or reject, and provides aggregate reports that expose unauthorized or misconfigured senders.

The protocols cover different failure modes, so a deployment should test all three. The SPF, DKIM and DMARC explained guide provides a broader authentication reference, while BIMI can use DMARC enforcement as a foundation for displaying a verified brand logo in supported inboxes.

DKIM configuration is only one part of deliverability. If signatures pass but mail still reaches spam, the remaining causes may include reputation, complaint rates, list quality, content, forwarding behavior, or provider-specific enforcement. A structured review of headers, DNS, and DMARC reports is more reliable than repeatedly changing records.

MailAdept combines subscription-based email deliverability consulting with AI agents and human experts who can review DKIM alignment, selector rotation, SPF, DMARC, domain routing, and sender reputation together. Still facing deliverability issues? Get a free deliverability audit through Mailadept.