What Is DKIM? A Developer’s Guide to Email Authentication

DKIM, short for DomainKeys Identified Mail, is one of the core technologies behind trustworthy email. If you are asking what is DKIM, the short answer is: it adds a cryptographic signature to an outgoing message so receiving mail systems can verify that an authorized sender signed it and that the signed parts of the message were not changed afterward.

DKIM is not a spam filter, an encryption protocol, or a guarantee that a message reaches the inbox. It is an authentication mechanism. Used with SPF and DMARC, it gives mailbox providers enough evidence to distinguish authorized mail from many kinds of spoofed or tampered-with mail.

What is DKIM in practical terms?

DKIM lets a domain take responsibility for an email by attaching a digital signature to it. The signer uses a private key held by the sending system. The receiving system retrieves the matching public key from DNS, then uses that key to check the signature.

A passing result means two important things:

1. The message was signed by a system that possessed the private key corresponding to the public key published for that DKIM selector.
2. The signed headers and body content still match what the signer originally signed.

It does not mean the sender is legitimate in every possible sense. A malicious organization can correctly sign mail sent from a domain it controls. DKIM proves authorization and message integrity for a signing domain; it does not independently assess whether the content is safe, wanted, or truthful.

The formal standard describes DKIM as a way for a domain owner, an operational relay, or an agent of either to claim responsibility for a message. The receiver validates that claim by checking a cryptographic signature and querying DNS for the signer’s public key. (datatracker.ietf.org)

For a developer, the everyday consequence is straightforward: whether your application sends through an SMTP relay or a REST email API, the provider should sign mail for a domain you control once that domain’s DNS authentication is configured. That signature travels inside the email headers; it is not something an end user normally sees in the message body.

Why DKIM matters for email delivery and security

Historically, SMTP was designed to move messages between servers, not to provide strong proof that a visible sender domain authorized every message. The From: header is easy to write. Without additional controls, an attacker can compose a message that appears to come from billing@example.com even when they do not operate example.com.

DKIM raises the cost of this kind of impersonation. A receiver can look at a DKIM signature that says d=example.com, retrieve a public key under example.com, and test whether the message was signed with the corresponding private key. An attacker who merely forges the visible From: address cannot produce a valid signature for your domain without access to its private key.

DKIM is part of modern sender expectations

Mailbox providers use authentication signals alongside reputation, content, engagement, complaint rates, sending patterns, and other anti-abuse controls. A DKIM pass alone will not repair poor list practices or overcome a damaged sending reputation. Conversely, a well-run sender that omits authentication is making it harder for receivers to trust legitimate messages.

Gmail’s current sender guidance requires all senders to personal Gmail accounts to use SPF or DKIM, and requires senders above 5,000 messages per day to Gmail accounts to use both SPF and DKIM plus DMARC. Google also calls for TLS, valid DNS, compliant message formatting, and low spam rates. (support.google.com)

That is why DKIM should be treated as production email infrastructure, not as an optional deliverability enhancement you add after launch. Password resets, receipts, account invitations, alerts, and campaign mail all benefit from clear domain authentication.

What DKIM does not do

It is equally important to understand the boundaries:

• DKIM does not encrypt email. Message content is still readable by systems that handle it unless you use a separate encryption approach.
• DKIM does not confirm the recipient is real. Use address validation and bounce handling for that problem; a free email verification tool can help assess an address before you send.
• DKIM does not prevent all spoofing by itself. DMARC provides the policy and alignment layer that connects authentication to the visible From: domain.
• DKIM does not guarantee inbox placement. A valid signature can still be sent to spam, deferred, throttled, or rejected for reputation or policy reasons.
• DKIM does not stop every modification. It protects the particular headers and body representation chosen by the signer. Some legitimate intermediaries can change mail enough to invalidate a signature.

How DKIM works step by step

DKIM uses asymmetric cryptography. There are two related keys: a private key and a public key. The sending platform keeps the private key secret. The domain publishes the public key in DNS, where receivers can retrieve it.

A typical signing and verification flow looks like this:

1. Your application submits an email through an API or SMTP server.
2. The outbound mail system constructs the final message and chooses a DKIM signing identity, such as example.com, plus a selector, such as s2026.
3. The mail system calculates hashes of the selected headers and the canonicalized message body.
4. It signs those values using the private key and adds a DKIM-Signature: header.
5. The receiver reads the d= domain and s= selector from that header.
6. It queries DNS for s2026._domainkey.example.com.
7. It obtains the public key, recomputes the relevant hashes, and verifies the signature.
8. It records the result in an Authentication-Results: header, often as dkim=pass, dkim=fail, dkim=neutral, dkim=temperror, or dkim=permerror.

The public key record is available to everybody; that is by design. Publishing a public key does not let someone sign as your domain. Only the private key can create a matching signature.

The DKIM-Signature header

Here is a shortened, illustrative DKIM signature header. Actual signatures are often folded across multiple physical lines because email headers can be long:

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

The most useful tags to recognize are:

• v=1 — DKIM signature version.
• a=rsa-sha256 — the signing algorithm. SHA-256 is the normal modern hash choice.
• c=relaxed/relaxed — header and body canonicalization methods.
• d=example.com — the signing domain.
• s=s2026 — the selector used to find the DNS key.
• h= — the headers included in the signature.
• bh= — the hash of the canonicalized body.
• b= — the cryptographic signature itself.
• t= — an optional signing timestamp.
• x= — an optional expiration timestamp.

The d= and s= values determine the DNS name the receiver checks: s2026._domainkey.example.com. This separation lets a domain publish multiple keys at the same time and rotate keys without a hard cutover.

DKIM DNS records: selectors, names, and syntax

A DKIM record is usually a DNS TXT record. It is not a special DNS record type named “DKIM.” The hostname is built from three pieces:

selector._domainkey.domain

For example, a sender using selector s2026 for example.com would publish this record:

Host/name: s2026._domainkey.example.com
Type:      TXT
Value:     v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...
TTL:       3600

In many DNS dashboards, the zone name is appended automatically. If your DNS zone is already example.com, the required host field may be only:

s2026._domainkey

Do not guess. Confirm how your DNS provider displays names, then use a DNS lookup after publishing. Accidentally entering the fully qualified name into a dashboard that appends the zone can create s2026._domainkey.example.com.example.com, which will not be found by receivers.

What the DNS tags mean

A basic DKIM public-key record contains a semicolon-delimited list of tag=value pairs:

v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY

The important parts are:

• v=DKIM1 identifies the record as DKIM version 1 and, when present, must appear first.
• k=rsa states the key type. RSA is widely deployed; modern DKIM registries also list Ed25519.
• p= contains the Base64-encoded public key material, with no PEM header/footer text such as -----BEGIN PUBLIC KEY-----.

The exact value after p= must come from the system that will sign your email. Do not generate an arbitrary DNS key and expect a hosted sender to use it. The provider needs the corresponding private key, or it needs you to publish the exact record it generated.

An empty p= value is a special signal used to revoke a key. It is not a valid way to “temporarily disable” DKIM while keeping mail operating normally. Because it can make existing signatures unverifiable, use it intentionally and only as part of a planned key retirement process.

TXT versus CNAME records

Many providers ask you to add a TXT record containing the public key directly. Others ask for a CNAME record at a selector hostname that points to a provider-controlled hostname. The receiver still follows the DNS chain to find the DKIM key; the difference is operational ownership of the final record.

For example, a provider may give instructions conceptually like this:

Host/name: s1._domainkey.example.com
Type:      CNAME
Target:    s1.example-com.provider-dkim.net

Do not substitute the TXT example above when your provider explicitly requires CNAME. Likewise, do not create a CNAME where a provider gave you a TXT value. A hostname cannot normally have both a CNAME and other record types, so mixing instructions can lead to DNS conflicts.

RSA, Ed25519, and DKIM key length

The security of DKIM depends partly on protecting the private key and using an appropriate signing algorithm. RSA with SHA-256 remains common, while Ed25519 support is defined for DKIM and appears in the current DKIM parameter registry. SHA-1 is listed as historic and should not be selected for new deployments. (iana.org)

For RSA, 1024-bit keys are legacy and can be rejected or treated unfavorably by some receivers. A 2048-bit RSA key is the practical baseline for new configuration unless your sending platform specifies an alternative. A larger public key also means a longer DNS TXT value, so DNS providers may display it as multiple quoted strings.

That display is normal. In DNS zone-file syntax, adjacent quoted TXT chunks are concatenated into one logical record. Do not add extra semicolons, spaces, quote characters, or line breaks into the key unless your DNS provider’s editor requires its own formatting. The public key must resolve as the exact Base64 data the sender expects.

Ed25519 keys are substantially smaller than RSA keys, which can simplify DNS publication. But compatibility depends on your sending platform and receiving ecosystem. Use the signing method supplied by your provider rather than manually changing k=rsa to k=ed25519 in DNS; the algorithm in DNS must match the algorithm and private key used to sign messages.

DKIM canonicalization and why signatures can fail

Email is often altered in transit. Some systems wrap long lines, add footers, rewrite MIME boundaries, change whitespace, or modify headers. DKIM accounts for limited, predictable formatting changes through canonicalization.

The c= tag has two values: one for headers and one for the body. The two standard modes are simple and relaxed.

• Simple header canonicalization preserves the header field more literally.
• Relaxed header canonicalization normalizes some whitespace and header-field-name differences.
• Simple body canonicalization is strict about the body representation.
• Relaxed body canonicalization normalizes certain whitespace behavior and ignores trailing empty lines.

A common setting is c=relaxed/relaxed, because it offers tolerance for harmless formatting changes while retaining meaningful integrity protection. It does not make the signature invulnerable to modification. If an intermediary adds a disclaimer to the body, rewrites a link, changes a signed subject line, or changes a MIME part after signing, the message can fail DKIM verification.

Mailing lists and forwarding

Mailing lists are a classic DKIM edge case. A list server might add [List Name] to the subject, add a footer, modify recipients, or repackage the message. Those changes can break the original author’s DKIM signature.

Forwarding presents another distinction. Traditional forwarding often changes the SMTP envelope sender, which can break SPF because SPF evaluates the connecting sender and envelope identity. DKIM can survive forwarding when the forwarded message is not altered, making it especially useful in the broader authentication stack.

However, “can survive” is not “always survives.” A forwarder that changes the body or signed headers may still invalidate DKIM. This is why robust DMARC deployments generally aim for both aligned SPF and aligned DKIM rather than relying on only one mechanism.

DKIM, SPF, and DMARC: how they fit together

DKIM is frequently discussed alongside SPF and DMARC, but the three standards answer different questions.

SPF is tied to the SMTP envelope identity, commonly shown as Return-Path: after delivery. DKIM is tied to the d= signing domain in the message header. DMARC looks at the visible RFC 5322 From: domain that recipients see and requires an SPF or DKIM pass with an appropriately aligned domain.

For example, consider this message:

From: Acme Support <support@acme.example>
Return-Path: bounces@mailer.vendor.example
DKIM-Signature: d=acme.example; s=s2026; ...

SPF may pass for mailer.vendor.example, but that domain is not necessarily aligned with acme.example. If DKIM passes for d=acme.example, it can provide the aligned authentication DMARC needs. This is one reason custom DKIM signing domains are so important when applications send through an external provider.

The current DMARC specification, RFC 9989, supersedes RFC 7489 and defines a DMARC pass as requiring both an authentication pass and domain alignment under relaxed or strict rules. (datatracker.ietf.org)

Relaxed and strict alignment

Under relaxed alignment, an organizational domain and its subdomain may align. For instance, news.acme.example can generally align with acme.example when the organizational domain matches. Strict alignment requires an exact domain match.

The right mode depends on your domain structure. Relaxed alignment is often practical when separate teams send from subdomains such as notify.example.com and marketing.example.com. Strict alignment can be appropriate where domain boundaries need tighter control. Either way, plan your From: domain, envelope domain, and DKIM d= domain deliberately instead of accepting a provider default blindly.

How to set up DKIM for an application or email provider

The exact screens differ by provider, but a safe implementation process is mostly universal. Your platform might send mail through a REST API, an SMTP relay, or both; DKIM is normally configured at the sending-domain level, not separately in every API call.

A reliable setup checklist

1. Choose the domain or subdomain used in your visible From: address. If users receive mail from alerts@example.com, authenticate example.com or a clearly aligned subdomain such as mail.example.com.
2. Add the domain in the sending platform. The platform generates one or more DKIM DNS records or CNAME targets.
3. Publish exactly the records supplied. Copy the host and value without changing selectors, punctuation, or key fragments.
4. Wait for DNS propagation based on your TTL and authoritative DNS updates. Do not assume a dashboard’s immediate “saved” state means every resolver can see the record.
5. Verify the domain in the sending platform. Providers commonly perform a DNS lookup before enabling custom signing.
6. Send a real test message. Deliver it to a mailbox you control and inspect the full headers.
7. Confirm both verification and alignment. Look for dkim=pass and make sure the header.d= domain aligns with the visible From: domain if you use DMARC.
8. Document the selector and record owner. That makes later troubleshooting and rotation far easier.

If you are integrating a sending service for the first time, its email API reference and setup guides should show the domain-authentication requirements separately from the request used to submit individual messages. A successful API response or an SMTP 250 acceptance only means the provider accepted the message for processing; it does not prove every downstream mailbox will see dkim=pass.

A real-world DNS example

Imagine that your email provider provides this key information:

Selector: prod1
Domain:   example.com
Record:   v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

At your DNS host, the resulting record is:

prod1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

The trailing dot in example.com. is zone-file notation indicating a fully qualified domain name. Browser-based DNS dashboards typically do not require it. Your DNS host might instead have separate fields called Name, Type, Content, and TTL. The labels vary, but the required technical data do not: selector hostname, TXT record type, and exact public-key value.

How to test DKIM correctly

Testing should happen at two levels: DNS publication and actual message verification. A published key does not prove messages are being signed; a signed message does not prove the correct key is publicly reachable from DNS.

Check the DNS record

From a terminal, query the selector record directly:

dig +short TXT prod1._domainkey.example.com

On Windows, you can use:

nslookup -type=TXT prod1._domainkey.example.com

You should see the expected DKIM value or the expected CNAME chain. If you get NXDOMAIN, the hostname does not exist. If you see an unexpected selector, a malformed key, or the wrong domain appended twice, correct the DNS entry before investigating the email application.

MXToolbox offers a DKIM lookup that checks a specified domain and selector for a published key record. mail-tester.com also provides SPF and DKIM checking tools. These are useful independent checks when a provider dashboard reports a vague DNS verification error. (mxtoolbox.com)

Inspect the received email headers

Send a fresh test message after configuration, then view the original or full message source in the recipient mailbox. Search for both DKIM-Signature: and Authentication-Results:.

A healthy result may resemble:

Authentication-Results: mx.recipient.example;
       dkim=pass header.i=@example.com header.s=prod1 header.d=example.com;
       spf=pass smtp.mailfrom=bounces@example.com;
       dmarc=pass header.from=example.com

Exact formatting varies by receiver. The critical fields are the DKIM verdict, the signing domain (header.d), and the selector (header.s). If you use DMARC, inspect dmarc=pass too; a DKIM pass from an unrelated provider domain may not align with the visible From: domain.

Understand failures and temporary errors

A DKIM result has more nuance than pass or fail:

• dkim=pass means the signature verified.
• dkim=fail means the signature was found but did not verify.
• dkim=neutral means the receiver could not make a positive assertion in a non-error case.
• dkim=temperror usually points to a temporary issue such as DNS lookup trouble.
• dkim=permerror generally indicates a permanent problem, such as malformed tags or an invalid key record.

These are authentication outcomes, not SMTP response codes. In contrast, an SMTP response like 250 2.0.0 generally confirms that the next SMTP server accepted a message for delivery processing. A later recipient system can still classify it as spam or reject it based on policy. Permanent SMTP policy rejections are commonly in the 5xx range, while temporary deferrals are commonly 4xx; exact enhanced status text is chosen by the receiving provider.

Common DKIM mistakes and how to fix them

Publishing the record at the wrong hostname

The selector is part of the lookup name. If the signature says s=prod1; d=example.com, the receiver queries prod1._domainkey.example.com. Publishing the key at _domainkey.example.com or at example.com will not work.

Fix: copy both s= and d= from an actual sent message or from the provider’s domain setup instructions, then query the resulting hostname with dig or nslookup.

Altering the public key

A single missing character, pasted line break, added quote, or copied PEM marker invalidates the record. DNS editors may split long strings visually, but the resolved record must concatenate to the correct Base64 public key.

Fix: re-copy the complete provider value. Avoid manually wrapping or unwrapping the public-key string unless your DNS provider explicitly requires quoted chunks.

Signing with a provider-owned domain only

A message can pass DKIM with d=provider.example while showing From: you@yourdomain.example. That may establish that the provider signed it, but it may not satisfy DMARC alignment for your brand domain.

Fix: configure custom domain authentication so that at least one valid signature has a d= domain aligned with the domain in your visible From: address.

Changing message content after signing

Some custom mail pipelines sign a message and then append a footer, rewrite URLs, or modify headers downstream. That can cause signature failures.

Fix: make signing the last content-changing step where possible. If a downstream gateway must modify mail, test its impact on DKIM and ensure the final sender adds a valid aligned signature.

Removing an old selector too quickly

Mail can be queued, retried, forwarded, or delivered later than expected. Deleting the old public key immediately after switching to a new selector can make still-in-flight mail fail verification.

Fix: publish the new key first, begin signing with it, verify live messages, and retain the old selector record for a conservative overlap period appropriate to your mail flow and operational policy.

Treating a DKIM pass as an inbox guarantee

DKIM validates a technical assertion. It does not cure high complaint rates, sudden volume spikes, deceptive content, broken unsubscribe handling, or low recipient engagement.

Fix: treat authentication as a foundation. Monitor bounces, complaints, recipient engagement, API or SMTP failures, domain reputation, and DMARC reports alongside it.

DKIM key rotation and operational hygiene

Key rotation means introducing a new key and selector, moving signing traffic to it, and eventually retiring the old key. The selector exists largely to make this possible without abruptly replacing a record that older messages still reference.

A safe rotation sequence is:

1. Generate or request a new selector and key from the sending system.
2. Publish the new DNS record while the old selector remains active.
3. Confirm independent DNS lookups return the new record.
4. Configure or allow the sender to begin using the new selector.
5. Send test messages and verify dkim=pass with the new header.s value.
6. Monitor production mail for failures.
7. Retire the old key only after its planned overlap period.

The private key deserves the same care as other production secrets. Do not commit it to a repository, include it in a client application, send it in support tickets, or expose it in logs. In a managed email platform, the provider often generates and protects the private key while you publish the public DNS record. If you self-host signing, key storage, access controls, backups, and rotation become your direct responsibility.

Separate selectors can also improve incident response. If you suspect a particular private key was exposed, stop signing with that selector, introduce a new key, and eventually revoke or remove the old public record after the transition. Do not assume that changing a DNS record alone revokes a private key already held by an attacker; the receiving ecosystem needs to see the new state, and you need a deliberate plan for affected mail streams.

Choosing domains and subdomains for DKIM

A single root domain can work, but subdomains often provide cleaner operational boundaries. For example:

Transactional From: receipts@mail.example.com
Marketing From:     news@updates.example.com
Support From:       support@example.com

Each stream can have separate DKIM selectors, providers, reputations, and DMARC reporting visibility while remaining recognizably part of the same organization. This is useful when product mail, promotional campaigns, and corporate mailbox traffic have different owners or risk profiles.

The tradeoff is complexity. Every sending domain must be authenticated, monitored, and aligned correctly. A message sent from news@updates.example.com needs DKIM and DMARC arrangements that make sense for updates.example.com; configuring only example.com may not be enough depending on the sender and your alignment policy.

Avoid using a domain you do not control in the visible From: field. Avoid rotating between many unrelated From: domains just to chase deliverability. Stable, authenticated domains with consistent sending behavior make it easier for recipients and receivers to understand who is responsible for the mail.

A practical DKIM troubleshooting workflow

When DKIM is not passing, work from evidence rather than dashboard status alone.

1. Get the raw source of a newly delivered message. Find DKIM-Signature and Authentication-Results.
2. Record d= and s=. Build the exact DNS lookup name as selector._domainkey.domain.
3. Query public DNS. Use dig, nslookup, MXToolbox, or another resolver outside your DNS provider account.
4. Compare DNS with the provider-provided record. Confirm record type, hostname, target/value, and key material.
5. Check for CNAME conflicts. A selector hostname that should be a CNAME should not also contain a TXT record.
6. Check alignment. Compare header.d with the visible From: domain and inspect the DMARC result.
7. Check for downstream modification. Compare a message before and after gateways, list servers, CRM connectors, or footers are applied.
8. Look for timing issues. A recently changed DNS record, cached resolver response, or provider verification job can create temporary mismatches.

This method separates the main fault classes: no signature, wrong selector, missing DNS, malformed key, invalid signature, non-aligned signature, and post-signing message modification. Each one has a different fix, so treating them all as “DKIM is broken” wastes time.

The bottom line: DKIM is necessary infrastructure

DKIM gives receiving systems cryptographic evidence that an authorized domain signed an email and that the signed portions have remained intact. It is one of the essential building blocks of authenticated email, especially for application-generated transactional messages and high-volume campaign mail.

Set it up before sending meaningful production volume, verify it with real message headers, and ensure the signing domain aligns with your visible From: domain under DMARC. Then maintain it: monitor authentication outcomes, preserve old selectors during rotations, and keep every sending stream under deliberate domain control.

The outcome is not merely a green DNS check. Correct DKIM configuration gives mailbox providers a stronger basis for trusting your mail, gives DMARC a domain identity it can evaluate, and makes simple impersonation of your sending domain substantially harder.

FAQ

What is DKIM in one sentence?

DKIM is an email authentication method that adds a cryptographic signature to a message so receivers can use a DNS-published public key to verify the signing domain and message integrity.

Is DKIM the same as SPF?

No. SPF authorizes sending servers for an SMTP envelope domain, while DKIM verifies a signature embedded in the message. They complement each other and are commonly used together with DMARC.

Does DKIM improve email deliverability?

It supports deliverability by giving receivers a reliable authentication signal, but it does not guarantee inbox placement. Sender reputation, complaint rates, content, recipient engagement, and policy compliance still matter.

What does a DKIM DNS record look like?

A common direct record is a TXT record at selector._domainkey.example.com with a value such as v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY. Some sending platforms instead require a CNAME at that selector hostname.

How do I know whether DKIM passes?

Send a test email, open its full headers, and look for an Authentication-Results: line containing dkim=pass. Also confirm that the header.d signing domain is aligned with the domain in the visible From: header if you use DMARC.