DKIM (DomainKeys Identified Mail) is an email authentication standard that adds a cryptographic signature to an outgoing message. The receiving mail system uses a public key published in the sender’s DNS to verify that a domain took responsibility for the email and that the signed parts of the message were not altered after signing. (rfc-editor.org)

DKIM DomainKeys Identified Mail in plain language

Think of DKIM as a tamper-evident seal attached to email. Before a message leaves your mail system, the sending system creates a mathematical signature using a private key. It places that signature in a DKIM-Signature header, along with information that tells the recipient where to locate the matching public key.

When a mailbox provider receives the email, it reads the signing domain and selector from the header, looks up a DNS TXT record, and uses the public key in that record to validate the signature. A successful DKIM result means the verifier could confirm that the message matched what the signing system signed and that the signature corresponds to the public key published for that domain. It does not mean that the message is welcome, safe, wanted, or guaranteed to reach the inbox.

That distinction matters. DKIM is an authentication control, not a delivery score or a reputation metric. It establishes a verifiable domain-level assertion of responsibility. Mailbox providers can then combine that assertion with other signals—such as recipient engagement, complaint rates, content, sending patterns, IP reputation, SPF, and DMARC—to decide whether to deliver, spam-folder, defer, or reject a message.

DKIM is often discussed alongside SPF and DMARC:

SPF evaluates whether the server sending a message is authorized by a domain’s SPF policy.
DKIM evaluates a cryptographic signature attached to the message and the associated public key in DNS.
DMARC uses the visible From: domain and requires alignment with a passing SPF or DKIM result, while also allowing the domain owner to publish a handling policy and request reports.

For direct email to personal Gmail accounts, Google requires all senders to set up SPF or DKIM, while higher-volume senders must set up both SPF and DKIM plus DMARC. Yahoo similarly requires at least SPF or DKIM for all senders and both for bulk senders, with DMARC alignment requirements for bulk mail. (support.google.com)

Why DKIM matters for deliverability and campaign performance

DKIM matters because email without reliable authentication is harder for receivers to attribute to a responsible sender. Modern mailbox providers are trying to separate legitimate, accountable email streams from impersonation, abuse, and poorly configured infrastructure. A valid DKIM signature gives them a durable signal that a domain is connected to the message.

DKIM makes domain identity more usable

A From: address is visible to recipients, but it is not sufficient technical proof by itself. Without authentication, an attacker can put nearly any domain in a visible From: header. DKIM lets a receiver check whether a signing domain actually authorized the message with a private key corresponding to a public DNS record.

This is especially useful for brands that send through email service providers, application platforms, support tools, billing systems, CRMs, and other third-party systems. Each system can sign mail for a domain or subdomain with a separate selector. That creates an auditable connection between the email stream and the domain that authorized it.

DKIM supports DMARC alignment

DKIM’s biggest operational value is often its relationship with DMARC. A DKIM signature can pass cryptographic verification yet still fail to satisfy DMARC if its signing domain is not aligned with the visible From: domain.

For example, consider this message:

From: invoices@example.com
DKIM-Signature: v=1; a=rsa-sha256; d=mailer.vendor.example; s=send1; ...

The DKIM signature may be technically valid. However, the visible author domain is example.com, while the DKIM signing domain is mailer.vendor.example. Unless SPF provides aligned authentication instead, DMARC will not treat that DKIM result as aligned with example.com.

A better configuration commonly signs with the organization’s own domain or a related subdomain, such as d=example.com or d=mail.example.com, depending on the organization’s DMARC alignment mode and architecture. Google states that the domain in the From: header must align with either the SPF domain or DKIM domain for DMARC alignment on direct mail, and Yahoo publishes the same core expectation for bulk senders. (support.google.com)

DKIM helps preserve authentication through forwarding

SPF is evaluated against the connecting sender, which can change when a message is forwarded. DKIM instead travels with the message as a signature header. If the forwarded message’s signed content remains intact and the recipient can retrieve the signing domain’s public key, the DKIM signature can still validate.

That does not mean every forwarded message will pass DKIM. Mailing lists, gateways, footer-insertion systems, security scanners, and other intermediaries can modify headers or body content. If they change a signed component in a way that breaks verification, the signature can fail. Still, DKIM generally gives mail a more portable, message-level authentication signal than sender-IP authorization alone.

DKIM improves operational accountability

DKIM lets teams separate mail streams without placing every system behind one undifferentiated identity. A company might use distinct selectors for transactional email, lifecycle campaigns, customer support, and a corporate mail platform. That separation can simplify diagnosis when one integration is misconfigured or one stream begins generating unexpected complaints.

A selector is not a reputation score by itself. But separate selectors can help operators identify which signer and system produced a message. This is valuable during incident response, provider migrations, key rotation, and audits of who is permitted to send mail for a domain.

How DKIM works step by step

DKIM uses public-key cryptography. The private key stays with the sender’s email infrastructure or sending provider. The public key is published in DNS so receivers can verify signatures without needing access to the private key.

1. The sender chooses a signing domain and selector

The signing domain is shown in the d= tag of the DKIM-Signature header. The selector is shown in the s= tag. Together, they identify the DNS record a receiver needs.

If an email uses:

DKIM-Signature: ... d=example.com; s=tx2026; ...

the receiver looks up this DNS name:

tx2026._domainkey.example.com

The selector enables multiple active keys for one domain. That is useful when separate providers sign mail independently or when you need to introduce a new key without immediately removing an existing one.

2. The sender canonicalizes and hashes content

Email can be modified in minor ways as it moves between systems. For that reason, DKIM defines canonicalization rules that determine how headers and body content are normalized before a signature is calculated.

The c= tag identifies the canonicalization choices for headers and body. Common values include relaxed/relaxed and relaxed/simple. Relaxed processing tolerates some non-semantic formatting changes, such as certain whitespace differences, while simple processing is stricter.

The sending system computes a body hash, then includes that value in the bh= tag. It also signs selected headers and inserts the resulting signature value in b=.

3. The sender inserts a DKIM-Signature header

A simplified illustrative header can look like this:

DKIM-Signature: v=1;
 a=rsa-sha256;
 c=relaxed/relaxed;
 d=example.com;
 s=tx2026;
 h=from:to:subject:date:message-id:mime-version;
 bh=Base64EncodedBodyHashHere;
 b=Base64EncodedCryptographicSignatureHere

This example is intentionally incomplete: real bh= and b= values are generated by the signing system and are much longer. The important operational tags are:

v=: the DKIM version, normally 1.
a=: the signing algorithm, such as rsa-sha256.
c=: header/body canonicalization rules.
d=: the signing domain.
s=: the selector that points to a DNS record.
h=: the email headers included in the signature.
bh=: the hash of the canonicalized body.
b=: the cryptographic signature itself.

4. The receiver finds the public key in DNS

The receiver queries the selector record published under _domainkey. A typical DNS TXT record is structurally similar to this example:

Host: tx2026._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL

The p= value contains the public key material. Your DNS provider may display this as one long quoted string or split it into multiple quoted segments. In DNS TXT syntax, adjacent quoted character strings form one logical record value; do not insert extra characters or unintended spaces into the key material.

The exact selector name and record value must come from the service that owns the corresponding private key. Do not guess selector names, reuse an unrelated provider’s record, or create a public key manually unless your own mail system generated the matching private key. For implementation-specific record creation and verification workflows, consult the platform’s email API setup guides.

5. The receiver validates the message

The receiver retrieves the public key, applies the specified canonicalization, recalculates the relevant hashes, and verifies the signature. A receiver can report results in an Authentication-Results header, although the exact formatting and available details vary by mailbox provider and receiving system.

A pass generally indicates that the cryptographic verification succeeded. A fail generally indicates a key lookup, key-policy, message-integrity, signing, algorithm, or header/body canonicalization problem. A neutral, none, temperror, or permerror-style result can point to other conditions, such as no usable signature, temporary DNS trouble, or permanent configuration errors.

DKIM is not a rate or a score

DKIM is sometimes mistaken for a deliverability metric because dashboards may show a DKIM pass percentage. Strictly speaking, DKIM itself is a protocol and an authentication result, not a rate.

A team may calculate a DKIM pass rate for monitoring:

DKIM pass rate = messages with a passing DKIM result / messages evaluated for DKIM × 100

For example, if a monitoring sample contains 48,750 messages with a DKIM pass result out of 50,000 messages evaluated, the DKIM pass rate is:

48,750 / 50,000 × 100 = 97.5%

That 97.5% figure is not a universal inbox-placement score. It is an operational signal that 1,250 messages in the sample did not produce a passing DKIM result. The next question is why: perhaps a particular provider is signing with the wrong domain, a DNS record is missing, an intermediary is breaking signed content, or one campaign tool has not completed domain authentication.

What to measure instead of treating DKIM as a vanity metric

A useful DKIM monitoring program separates outcomes by domain, selector, sending source, recipient provider, and message type. Aggregate success rates can hide a critical failure in a lower-volume but high-value stream, such as password resets or invoices.

Track at least the following:

DKIM pass rate by sender and selector. This reveals whether one platform or key is failing.
DMARC pass rate. A cryptographically valid DKIM signature is not enough if it does not align with From:.
Authentication failures by recipient domain. DNS, algorithm, or content-handling differences may surface at specific destinations.
Delivery outcomes after an authentication change. Look for deferrals, bounces, spam-folder placement, and complaint changes.
Selector and key inventory. Know every active selector, the system that owns it, and when it was last used.

Google’s Postmaster Tools includes message-authentication information alongside reputation, spam-rate, and delivery-error data for eligible domains. Use authentication data to locate a configuration issue, but do not use DKIM passing alone as proof that campaigns are healthy. (support.google.com)

Common reasons DKIM fails

DKIM failures often appear after a domain setup, provider migration, template change, DNS update, or mail-routing change. The most efficient troubleshooting approach is to identify the exact sender, selector, signing domain, and receiver result before changing anything.

Missing, malformed, or incorrect DNS records

The most common problem is that the receiving server cannot retrieve the correct public key. Causes include a missing TXT record, a selector typo, publishing the record at the root domain instead of under _domainkey, truncating the public key, or pasting a record with invalid characters.

A common conceptual error looks like this:

Wrong host: example.com
Right host: tx2026._domainkey.example.com

Another is publishing the key for marketing.example.com while the email header says d=example.com, or vice versa. The receiver constructs its DNS lookup from both s= and d=, so the published record must match those tags exactly.

DNS propagation, caching, and duplicate records

DNS changes are not always visible everywhere immediately. A selector record may resolve correctly in one environment while a receiving resolver still has an earlier answer cached according to its TTL. During a migration, this can create intermittent-looking failures.

Duplicate or conflicting TXT records at the same selector can also cause unexpected results. Before replacing a record, confirm whether more than one mail provider is using that selector. Deleting an old record prematurely can break delayed mail, retry queues, or messages still being processed by recipient systems.

The message changed after it was signed

DKIM protects the specific headers and body content chosen by the signer. If a later system modifies a signed field or body content in a way that canonicalization does not tolerate, the signature can fail.

Typical examples include:

A mailing list adding a footer to the body.
A gateway rewriting the Subject: line after it was signed.
A security appliance altering MIME boundaries or encoded content.
An outbound relay adding, removing, or rewriting signed headers.
A template or tracking process being applied after signing rather than before it.

The fix is architectural, not cosmetic: apply all content transformations before the final DKIM signing step, or configure the signing strategy so signed content remains stable during downstream handling.

Wrong signing domain for DMARC alignment

A dkim=pass result can coexist with dmarc=fail. This occurs when DKIM validates but the d= domain does not align with the visible From: domain and SPF does not provide aligned authentication.

This is especially common when a third-party tool signs using its own service domain. The message is technically signed, but the signature does not establish an aligned identity for the brand shown in From:. Configure custom domain authentication in the sending tool so it signs with your domain or appropriately related subdomain.

Weak or unsupported algorithm choices

DKIM implementations have evolved. RFC 8301 updated the cryptographic requirements because earlier DKIM algorithm and key-size expectations were no longer adequate; it also moved away from RSA-SHA1. RFC 8463 added ed25519-sha256 as an additional DKIM signing algorithm. (rfc-editor.org)

For practical interoperability, use the algorithm and key format your sending platform documents and your target receiving ecosystem supports. RSA with SHA-256 remains a broadly deployed choice. If you use newer signing options, test actual receiving results before making them the only signature on production mail.

Private key and public key do not match

A public key is useful only when it corresponds to the private key that created the signature. This failure can occur if a team regenerates a key, changes an email provider, restores an old configuration, or accidentally publishes a record for the wrong environment.

Never copy a public key from another domain or selector just because it appears similar. Generate and publish a matching pair through the signer that will use the private key, then verify with real messages.

How to set up DKIM correctly

The exact screens and DNS values depend on your email provider, but the deployment sequence is consistent.

Step 1: Inventory every source that sends as your domain

Start with a sending inventory. Include transactional email, marketing campaigns, support systems, billing tools, HR platforms, product alerts, developer environments, and corporate mail. Any system that sends with your domain in From: may need authentication and alignment planning.

For each source, document:

The visible From: domain.
The envelope sender or return-path domain, if known.
The DKIM d= signing domain.
The selector or selectors in use.
Who controls the DNS record.
Whether SPF and DKIM align with the visible From: domain.
The owner responsible for renewal, migration, and incident response.

This avoids a common failure mode: a company successfully authenticates its main marketing platform but forgets that receipts, support replies, or application notifications are sent through a different system.

Step 2: Generate or obtain the provider’s DKIM records

If a provider manages signing for you, it normally generates the public-key DNS record and retains the private key. If you operate your own MTA, your system generates the key pair and you publish the public half.

Use distinct selectors for distinct keys. A naming pattern such as tx2026, mkt2026, and support2026 can make records easier to identify, but selector names do not create security by themselves. Avoid exposing sensitive operational details in selector names if that would conflict with internal policy.

Step 3: Publish the DNS TXT record precisely

Publish the host name and TXT value exactly as provided. Check the following before saving:

The host includes selector._domainkey in the correct DNS zone.
The provider has not automatically appended your domain twice.
The record type is TXT, unless your sender specifically provides a different verified DNS method.
The p= public key is complete.
Quotation marks and split-string formatting follow your DNS provider’s accepted syntax.
No old, conflicting record remains at the same selector unless your provider explicitly supports it.

Do not add a proxy, redirect, or URL to a DKIM record. DKIM public keys are DNS data, not web content.

Step 4: Enable signing only after DNS is available

A sender can create a DKIM-Signature header before the public key is live, but receivers cannot validate it without the DNS record. Publish the record, allow for DNS propagation and caching, verify resolution independently, and then activate or confirm signing.

If your provider performs automated verification, wait for it to complete before treating the configuration as finished. A DNS record existing in your zone editor is not the same as a record resolving correctly from public DNS.

Step 5: Send real test messages and inspect headers

Send test mail to multiple mailbox providers and inspect the original message source. Look for the DKIM-Signature header, then find the receiver’s authentication result where available.

You are checking at least four things:

The message is actually signed.
The d= domain is the intended domain.
The s= selector resolves to the expected DNS record.
DKIM passes and, where required, aligns for DMARC.

Test more than one message type. A plain-text transactional message, an HTML campaign, a reply, an attachment, and an automated notification may travel through different systems or transformations.

How to fix and improve DKIM results

A good DKIM remediation process starts with evidence. Do not rotate keys, change canonicalization, or modify DNS randomly because doing so can make an intermittent problem harder to diagnose.

Use a structured troubleshooting sequence

Capture a failing message in raw form. Record the full DKIM-Signature header and relevant Authentication-Results header.
Identify d= and s=. These determine the DNS name the receiver should query.
Query the expected selector record. Confirm that it exists publicly and has the expected key value.
Confirm the sender owns the matching private key. Verify the mail platform configuration, not just the DNS record.
Check whether post-signing changes occur. Compare a message just after signing with the message received by the destination if your infrastructure makes that possible.
Check DMARC alignment separately. A DKIM pass may still be operationally insufficient when d= does not align with From:.
Deploy a fix to one stream first. Validate with live tests before applying it to every sender.

Rotate keys without breaking mail

Key rotation is a routine security and operations practice. The safe pattern is to create a new selector rather than overwrite the old selector immediately.

For example:

Publish a new record at tx2027._domainkey.example.com.
Configure the sending platform to sign new mail with s=tx2027.
Confirm that new messages pass DKIM at representative recipient providers.
Keep the old tx2026 public key published while old signatures and queued mail may still be validated.
Retire the old selector only after you are confident it is no longer needed.

This overlap is important because messages can sit in queues, be retried after temporary delivery errors, or be processed by systems that do not query DNS at exactly the same time.

Separate authentication from sender reputation work

Fixing DKIM is necessary, but it does not erase poor list quality, unwanted frequency, misleading message content, or high complaint rates. If a campaign has weak engagement or generates complaints, simply adding a valid signature will not transform it into inbox mail.

Yahoo explicitly recommends timely, relevant mail sent to an active and engaged audience and asks senders to keep spam complaint rates below 0.3%. Google likewise advises keeping the spam rate reported in Postmaster Tools below 0.3%. Authentication is foundational; recipient experience and sending behavior remain decisive. (support.google.com)

Treat third-party senders as part of your authentication perimeter

Every vendor allowed to send as your domain is part of your email identity system. Review each one during onboarding and periodically afterward. Ask which domain it uses in d=, how it provides DNS records, whether it supports custom domain signing, how it handles key rotation, and whether its implementation can support your DMARC alignment goals.

The practical goal is not to maximize the number of signatures. It is to ensure that every legitimate stream has reliable, aligned authentication and that unauthorized streams cannot credibly impersonate your visible domain.

DKIM, SPF, and DMARC: what each one proves

These protocols overlap, but they do not replace each other.

Protocol	Primary question	Typical data source	Key limitation
SPF	Was this sending server authorized by the envelope domain?	DNS SPF record and connecting IP	Forwarding can change the apparent sending server.
DKIM	Does this message have a valid signature from the signing domain?	`DKIM-Signature` header and DNS public key	A pass alone does not guarantee visible `From:` alignment.
DMARC	Does the visible `From:` domain align with a passing SPF or DKIM result, and what policy applies?	SPF, DKIM, visible `From:`, DMARC DNS policy	DMARC depends on correctly configured underlying authentication.

A resilient sending setup uses all three deliberately. SPF authorizes infrastructure. DKIM signs the message. DMARC ties authentication to the domain recipients see in the From: header.

For many transactional senders, the strongest operational pattern is to use a dedicated sending subdomain, such as mail.example.com, for the mail infrastructure while preserving a clear, aligned visible From: identity. The correct design depends on your organization’s DMARC policy, brand requirements, vendor capabilities, and mail streams—not on a one-size-fits-all DNS template.

Advanced DKIM considerations for developers and email teams

Sign important headers deliberately

The h= tag lists headers that are signed. Signers commonly cover headers such as From, To, Subject, Date, Message-ID, and MIME-related headers. The From: header is particularly important because it expresses the author identity recipients see.

If a header is not signed, a downstream system may be able to alter it without invalidating the signature. Conversely, signing too aggressively can make signatures fragile if a legitimate intermediary regularly rewrites those fields. The correct balance depends on your mail flow.

Understand body-length limits and partial-body signing

DKIM supports an optional body-length tag, l=, that can limit the amount of the body covered by the signature. This can have specialized uses, but it should be treated carefully because it can create ambiguity around appended content. If you did not intentionally configure partial-body signing, investigate any unexpected l= usage with the owner of the signing system.

Multiple DKIM signatures can be normal

An email can carry more than one DKIM signature. This may occur when a message passes through multiple authorized systems or when an organization signs with more than one algorithm or domain during a transition.

Multiple signatures do not automatically improve delivery. What matters is whether a receiver can validate at least one relevant signature and whether a passing signature aligns with the visible From: domain for DMARC. Extra signatures that are broken or unrelated can complicate troubleshooting, so document why each signer exists.

DKIM does not encrypt email

DKIM validates signed content; it does not make the message confidential. Email content is not encrypted simply because a DKIM-Signature header is present. Transport encryption, such as TLS between mail servers, is a separate concern, and end-to-end email encryption is a different technology entirely.

DKIM does not stop every spoofing attempt by itself

An attacker cannot create a valid DKIM signature for your domain without access to the private key, but DKIM alone does not tell all receivers how to treat unauthenticated mail claiming to be from your visible domain. That is why DMARC matters: it introduces domain alignment and a published policy framework.

A practical DKIM checklist

Use this checklist when launching a new sender, migrating a provider, or investigating an authentication problem:

Conclusion

DKIM DomainKeys Identified Mail is a core email authentication mechanism that lets a receiver verify a cryptographic assertion from a sending domain. It is not an inbox-placement guarantee, but it is essential infrastructure for accountable sending, DMARC alignment, domain protection, and reliable delivery operations.

The most effective DKIM setup is not merely a DNS record that exists. It is a maintained system: every sender is known, selectors are documented, signatures are validated in real received mail, signing domains align with the visible brand domain where needed, and key changes are rolled out safely. Combine that authentication foundation with permission-based sending, low complaint rates, clear unsubscribe behavior, and useful message content to build a healthier email program.

FAQ

What does DKIM stand for?

DKIM stands for DomainKeys Identified Mail. It is an email authentication standard that uses a message signature and a DNS-published public key to verify a signing domain’s assertion of responsibility for a message. (rfc-editor.org)

Is DKIM required for email deliverability?

DKIM is not an absolute guarantee of inbox placement, but it is a baseline authentication requirement or expectation for major mailbox providers. Gmail requires SPF or DKIM for all direct senders to personal Gmail accounts and requires both SPF and DKIM for senders above its bulk-sender threshold; Yahoo has similar sender requirements. (support.google.com)

What is a DKIM selector?

A DKIM selector is the identifier in the s= tag of the DKIM-Signature header. Together with the d= signing domain, it tells receivers which DNS record to query, such as selector._domainkey.example.com.

Can DKIM pass while DMARC fails?

Yes. DKIM can pass cryptographic validation but fail DMARC alignment if the DKIM d= domain does not align with the domain in the visible From: header and SPF does not provide aligned authentication.

Does DKIM encrypt email content?

No. DKIM signs selected message content to support authenticity and integrity checks. It does not encrypt the message body or make the email confidential.

DKIM (DomainKeys Identified Mail): What It Is and How It Works