Setting Up DKIM for Your Domain: DNS Records, Testing, and Troubleshooting

Setting up DKIM for your domain proves that your email was authorized by your domain and was not altered after it was signed. Whether you send application notifications through an email API, use an SMTP relay, operate your own mail server, or send from a workplace suite, the DNS and verification concepts are the same.

What DKIM does for your email

DKIM, short for DomainKeys Identified Mail, is an email authentication method based on public-key cryptography. A sending system signs selected parts of an outbound message with a private key. The receiving mailbox provider then retrieves the corresponding public key from DNS and verifies the signature.

A successful DKIM check tells the receiver two useful things:

• The message was signed by a system authorized to use the DKIM signing domain.
• The signed portions of the message, including selected headers and usually the body, were not materially changed after signing.

DKIM is not an encryption system. Recipients can still read a normal DKIM-signed message in transit just as they can read other regular email. It is also not a spam-pass guarantee. Inbox providers evaluate DKIM alongside sender reputation, SPF, DMARC alignment, message content, complaint rates, recipient engagement, IP reputation, TLS, and many other signals.

Still, DKIM is foundational. It is especially important because it can provide an authenticated domain identity that aligns with the visible From: address for DMARC. Under relaxed DMARC alignment, the organizational domain of the signing domain in DKIM's d= tag must match the organizational domain of the visible From: address. (datatracker.ietf.org)

For example, a message with this visible sender:

From: Billing <receipts@example.com>

can usually align under relaxed DKIM alignment when it is signed with either:

d=example.com

or:

d=mail.example.com

It will not align with d=some-email-vendor.example merely because that vendor delivered the message. A third-party platform may sign with both its own domain and your domain, but for DMARC purposes the signature using your aligned domain is the one that matters.

How a DKIM signature works

A DKIM-enabled mail system has a key pair:

• Private key: kept secret by the system that sends and signs email.
• Public key: published in DNS so recipient servers can verify signatures.

When the sending system processes a message, it adds a DKIM-Signature: header. A simplified example looks like this:

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

The key fields are:

• v=1 identifies the DKIM signature version.
• a=rsa-sha256 identifies the signing algorithm.
• d=example.com is the signing domain.
• s=s2026 is the selector, which identifies the particular public key to look up.
• h= lists the message headers included in the signature.
• bh= is a hash of the canonicalized body.
• b= contains the digital signature itself.
• c=relaxed/relaxed identifies the canonicalization rules used for headers and body.

The receiver combines s= and d= to determine where it should look in DNS:

s2026._domainkey.example.com

It retrieves the public key from that record, reconstructs the signed data according to the signature instructions, and checks whether the signature is valid. The core DKIM standard defines the selector and domain as the inputs used to locate the key. (datatracker.ietf.org)

This lookup mechanism is why an exact selector matters. A valid key at default._domainkey.example.com cannot verify a message signed with s=s2026. Both the DNS hostname and public-key value must match what the signing system expects.

Before you set up DKIM for your domain

DKIM setup often fails because the person configuring DNS does not know which system is actually sending mail. Start by making an inventory of every service that can send mail using your domain in the visible From: field.

Typical sources include:

1. Your transactional email provider, used for password resets, receipts, product alerts, and account notifications.
2. Your customer-support platform, which may send ticket updates or outbound replies.
3. Your workplace mail service, used by employees for normal correspondence.
4. Your marketing platform, used for newsletters, lifecycle campaigns, and promotions.
5. Your billing, invoicing, recruiting, CRM, or ecommerce tools.
6. Internal applications that submit mail directly through SMTP or an HTTP email API.

Each independent sender may need its own DKIM configuration. That does not mean you publish several values in one random DKIM TXT record. In most cases, each sender uses a different selector and therefore a different DNS hostname.

For example:

s2026._domainkey.example.com      TXT     public key for application email
marketing._domainkey.example.com  CNAME   delegation for marketing platform
selector1._domainkey.example.com  CNAME   delegation for workplace mail

Before changing DNS, collect the exact records from the mail platform that signs for each workload. Do not generate a key yourself if a managed platform explicitly provides a DNS record for you to publish. The platform holds the corresponding private key; publishing a different public key makes its signatures fail.

Also confirm that you can edit authoritative public DNS for the domain. Editing a domain registrar account is not enough if DNS is hosted elsewhere. A domain may be registered with one company but use nameservers from another provider, such as Cloudflare, Route 53, Azure DNS, or an internal DNS service.

Choose the right DKIM setup model

There are two common DKIM publication models. The DNS record type is dictated by the sending service, not by personal preference.

Model 1: Publish a TXT record with a public key

This is the traditional model. You generate or receive a DKIM public key and publish it directly as a TXT record.

Example:

Host/name: s2026._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvExampleOnly...

Depending on your DNS control panel, the full hostname may be entered as either:

s2026._domainkey

or:

s2026._domainkey.example.com

Do not guess which format your provider expects. Many DNS interfaces automatically append example.com; entering the fully qualified domain name in such an interface can create an accidental record such as:

s2026._domainkey.example.com.example.com

Use the provider's preview, record list, or DNS lookup after saving to confirm the final published hostname.

Model 2: Publish a CNAME delegation

Some email services manage the public key on their own DNS infrastructure and ask you to publish a CNAME record instead. The hostname is still usually selector-based, but the target is provider-specific.

The record might conceptually look like this:

Host/name: provider1._domainkey
Type: CNAME
Target/value: provider1.example.com.provider-dkim-service.example

Do not replace the target with an invented value or copy a target from another account. CNAME targets can include account, tenant, region, or domain-specific values. Copy the exact target supplied by the platform.

A CNAME setup is normal and valid. It delegates the DKIM lookup to the mail provider while allowing the message to retain your domain in the d= field. Microsoft 365, for example, documents custom-domain DKIM configuration using CNAME records rather than manually pasted public-key TXT values. (learn.microsoft.com)

Never mix the two models at one selector hostname

A DNS hostname cannot use a CNAME alongside other records, including a TXT record. If your provider expects:

selector1._domainkey.example.com CNAME target.example.net

do not also add a TXT record at selector1._domainkey.example.com. Use the requested CNAME exactly, or choose a separate selector for a separately managed key.

Create and publish a DKIM TXT record

If you run your own signing infrastructure, or a provider gives you a raw DKIM key record, the standard DNS form is straightforward:

<selector>._domainkey.<domain> TXT "v=DKIM1; k=rsa; p=<public-key>"

Here is a realistic structural example using the domain example.com and selector s2026:

s2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwExampleKeyMaterialOnlyForDocumentation...IDAQAB"

The actual p= value is Base64-encoded public-key material. It is not a password, but it should be copied exactly. Do not add line breaks inside it unless your DNS provider explicitly formats a long value into adjacent quoted strings for you.

Required and useful key-record tags

A DKIM key record is a semicolon-separated tag list. The p= tag contains the public key and is the critical piece. Common tags include:

• v=DKIM1 — version identifier. It is recommended and, when present, belongs first.
• k=rsa — declares an RSA key. If omitted, RSA is the default in the original DKIM key format.
• p=... — Base64-encoded public key; this is required for a usable key.
• t=s — optional flag indicating strict domain matching for the signing identity.
• t=y — optional testing flag; do not leave it enabled as a substitute for real deployment validation.
• h=sha256 — optional hash-algorithm restriction; most implementations do not need it.

A minimal but conventional RSA record is:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv...

For an Ed25519 key, the record identifies the key type differently:

v=DKIM1; k=ed25519; p=Base64EncodedEd25519PublicKey

RFC 8463 adds Ed25519-SHA256 to DKIM and specifies k=ed25519 for the verification key record. (rfc-editor.org)

DNS quoting and 255-character chunks

A 2048-bit RSA public key is long enough that DNS providers may display it as several quoted segments. This is valid DNS syntax when the strings are adjacent:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A"
"MIIBCgKCAQEAvExampleLongKeyMaterialContinuesHere"
"AndEndsHereIDAQAB"

Resolvers concatenate adjacent quoted strings into a single TXT value. Do not insert a literal space between chunks unless that space is supposed to be part of the record value. In a DNS dashboard, the safest approach is usually to paste the complete value exactly once and allow the interface to split it automatically if needed.

Avoid common formatting errors:

• Adding quotation marks when the DNS interface says it adds them automatically.
• Copying the Host/name: label into the TXT value field.
• Including a private key instead of the public key.
• Leaving a leading or trailing space in the p= value.
• Publishing the selector under the wrong domain or subdomain.
• Pasting a record from a different sending account, environment, or region.

Generate keys for a self-managed mail server

Managed delivery services typically generate DKIM keys on your behalf. If you operate your own mail transfer agent, a signing gateway, or a local relay, you must generate and protect the private key yourself.

For an OpenDKIM-based setup, a typical command is:

opendkim-genkey -b 2048 -s s2026 -d example.com

This commonly produces a private-key file and a TXT-record file for the selected domain. File names vary by tool and configuration, but OpenDKIM normally creates files based on the selector, such as s2026.private and s2026.txt.

Use a selector that makes operational sense. A selector is not a secret, so it can encode a date, environment, or sending system:

s2026
app1
prod2026q3
relay-west

Avoid selectors that force you to reuse the same key across unrelated systems. Separate selectors make key rotation and incident response more controlled. If a key is compromised or a sending service is retired, you can remove only that selector after migration instead of disrupting every sender.

RSA versus Ed25519

For broad interoperability, 2048-bit RSA with rsa-sha256 remains a practical default. RFC 8301 updates DKIM cryptographic guidance: signers must not use rsa-sha1, and verifiers must support RSA keys from 1024 to 4096 bits. (rfc-editor.org)

Ed25519 is a standards-based DKIM alternative with much smaller key material. It can be attractive when DNS record size or operational simplicity is a concern. However, confirm that your signing software, outbound relays, mail-processing gateways, and verification tooling all support it before making it your only signing method.

Do not select a 4096-bit RSA key merely because it is larger. Large keys can create DNS publication and resolver compatibility problems. A 2048-bit RSA key is usually the safer default unless your provider or security policy gives you a specific reason to choose another supported option.

Protect the private key

The public key belongs in DNS. The private key does not.

Store a private key with restrictive filesystem permissions, limit access to the service account that signs mail, keep it out of source control, and do not paste it into tickets, chat systems, or application logs. If you suspect a private key was exposed, generate a new selector and key pair, update the signer, validate the new key, then retire the old selector after traffic has moved.

Configure the sender to sign outbound mail

Publishing DNS alone does not sign any message. The system that sends your email must be configured to use the matching private key and selector.

For a transactional email platform, this usually means adding or verifying a sending domain in its account configuration and publishing the records it supplies. Your application can then send through that platform's REST API or SMTP relay, while the platform signs qualifying messages for your domain.

For a self-hosted configuration, your MTA or milter needs at least these details:

Signing domain: example.com
Selector: s2026
Private key path: /secure/path/s2026.private
Algorithm: rsa-sha256

The exact configuration syntax differs across OpenDKIM, Postfix, Exim, Rspamd, Haraka, and cloud email gateways. The diagnostic principle does not change: the selector configured on the signer must match the selector in DNS, and the private key must correspond to the public key published at that selector.

Use a domain that aligns with your visible From address

Suppose your application sends this message:

From: Acme Alerts <alerts@news.example.com>

A DKIM signature with d=news.example.com is directly aligned. A signature with d=example.com generally aligns under relaxed alignment. A signature with d=mailer.otherdomain.example does not align with news.example.com.

This distinction matters when you later publish DMARC. A message can show dkim=pass in headers and still fail DMARC if its passing signature does not align with the visible From: domain. Design your sending-domain structure before you turn on strict DMARC alignment.

Verify the DNS record before sending mail

DNS propagation is not a single timer. A record can appear in your DNS provider's dashboard immediately but remain absent from recursive resolvers until caches refresh. Check the publicly visible DNS answer, not just the control-panel confirmation.

On macOS, Linux, or Windows environments with dig installed:

dig +short TXT s2026._domainkey.example.com

To query a specific recursive resolver:

dig @1.1.1.1 +short TXT s2026._domainkey.example.com
dig @8.8.8.8 +short TXT s2026._domainkey.example.com

On Windows, nslookup can query the TXT record:

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

For a CNAME-based configuration, query CNAME first:

dig +short CNAME selector1._domainkey.example.com

Then inspect the resulting target if necessary:

dig +short TXT target-provided-by-your-email-service.example

If you use OpenDKIM locally, opendkim-testkey can help compare your local configuration with the published DNS record:

opendkim-testkey -d example.com -s s2026 -vvv

A DNS lookup confirms only that the public record resolves. It does not prove the sending platform is actually signing messages with the matching private key. Send a real message after DNS resolves.

Send a test message and inspect the headers

Send an email from the exact production path you intend to use. If your application uses an HTTP API in production, test through that API. If it uses SMTP submission, test through the SMTP relay. A test from your personal mailbox or a different platform may validate the wrong DKIM configuration.

Send to a mailbox you control, then view the full source or original message. Most mailbox providers expose this in a menu such as “Show original,” “View source,” or “View message details.” Look for an Authentication-Results: header similar to:

Authentication-Results: mx.receiver.example;
 dkim=pass header.i=@example.com header.s=s2026 header.b=AbCdEf;
 spf=pass smtp.mailfrom=bounces.example.com;
 dmarc=pass header.from=example.com

The important values are:

• dkim=pass — the signature verified against the published DNS key.
• header.i=@example.com or a related identifier — the identity carried by the DKIM signature.
• header.s=s2026 — the selector the receiver used.
• dmarc=pass — at least one aligned SPF or DKIM identifier passed under your DMARC policy.

If the message says dkim=none, the sending system did not add a DKIM signature. This is not normally a DNS failure; it indicates a sender configuration, domain-authorization, route-selection, or account-setup issue.

If it says dkim=fail, inspect the associated reason. Typical explanations include a missing DNS key, a wrong selector, an invalid key format, a mismatched private/public key pair, a signature broken by message modification, or a disabled signing configuration.

Tools such as mail-tester.com can provide a fast view of authentication results and message quality. MXToolbox offers DNS and DKIM lookup diagnostics. Treat such tools as useful checks, but make recipient-header inspection your primary evidence because it shows what an actual receiving system evaluated.

A successful API response or SMTP handoff does not prove DKIM authentication. An email API may return a successful 200 OK, 201 Created, or 202 Accepted response after accepting the request for processing. An SMTP relay may return 250 after accepting the message. Those outcomes mean the submission was accepted; recipient-side authentication is only confirmed in the delivered message headers. SMTP reply codes use the first digit to distinguish success, temporary failure, and permanent failure, with 250 commonly indicating successful completion and 550 commonly indicating a permanent delivery-related rejection. (rfc-editor.org)

While you are testing delivery, remember that a valid DKIM signature cannot make an invalid recipient mailbox deliverable. Check recipient data separately with an email address verification tool before treating a bounce as an authentication problem.

Troubleshoot common DKIM failures

DKIM issues are usually diagnosable from three sources: DNS lookup results, raw message headers, and the sending platform's delivery or event logs. Work from the signature header outward rather than repeatedly changing records without evidence.

“No DKIM record found” or key not found

The receiver used s= and d= from the message and could not find a usable key. First, copy those values from the actual DKIM-Signature: header.

If the message contains:

d=example.com; s=s2026;

the lookup must succeed at:

s2026._domainkey.example.com

Check for misspellings, unintended duplicated domains, a record in a private DNS zone, an unpropagated change, or a CNAME target copied incorrectly. Also make sure the selector contains no extra quotes or whitespace.

dkim=fail after the record appears in DNS

A record that exists can still contain the wrong key. This commonly happens when someone rotates a provider-managed key, then restores an old TXT record from a backup, or copies a key from a staging account into production DNS.

Compare the current DNS value with the exact record supplied by the signer. For a self-managed environment, verify that the private key configured in the signer is the mate of the published public key. If the signer and DNS are correct but verification still fails, investigate mail flow: a downstream relay, mailing list, security gateway, or footer-insertion tool may be changing signed content.

dkim=neutral, temperror, or intermittent results

A temporary DKIM result often points to DNS availability or resolution trouble. Check authoritative DNS, resolver responses, TTL values, CNAME chains, and whether a DNS provider has published the record in the correct zone.

Intermittent results can also occur during key rotation when different sending nodes use different selectors or different key versions. Keep the old DNS record published until you have confirmed that no mail is still being signed with the old selector.

DKIM passes, but DMARC fails

This is usually an alignment issue, not a cryptographic issue. Inspect:

From: notices@example.com
DKIM d=mail.vendor.example

The DKIM signature may be valid, but it does not align with example.com. Configure the sending provider to sign with your authenticated domain, if it supports that, or confirm whether aligned SPF can satisfy DMARC instead.

The DNS provider rejects the long value

A 2048-bit RSA key may be long enough to expose limitations in a simplistic DNS interface. Check whether the provider supports long TXT values and automatic quoted-string splitting. Do not shorten, truncate, or manually wrap the key at arbitrary points.

If the sending service supports a DKIM CNAME delegation model, use the exact CNAME records it supplies instead of trying to convert them into a TXT record. If you control the signer, evaluate whether your infrastructure supports Ed25519, which uses substantially shorter public-key material.

A mailing list or forwarder breaks signatures

DKIM protects signed headers and body content. If an intermediary changes the subject, adds a banner, modifies MIME boundaries, rewrites the body, or changes a signed header, a signature can fail after the message leaves your system.

This does not necessarily mean your original sender is misconfigured. Review the message path and compare headers from a direct recipient with headers from a message delivered through the problematic intermediary. DMARC-aware forwarding systems may use mechanisms such as ARC, but do not depend on every recipient handling every forwarded message identically.

Rotate DKIM keys without interrupting email

DKIM selectors exist partly to make rotation safe. A rotation should add a new key alongside the old one, not replace the old public key while messages signed by it may still be in transit.

Use this sequence:

1. Generate a new key pair or request a new selector from your email platform.
2. Publish the new TXT or CNAME record in DNS.
3. Confirm that the new selector resolves correctly from public DNS.
4. Update the signer or activate the new selector in the sending platform.
5. Send production-path test messages and verify dkim=pass using the new selector.
6. Monitor sending logs, bounces, and authentication results.
7. Keep the old selector published for a reasonable transition window.
8. Remove the old key only after no systems are signing with it.

For example, a safe overlap might look like this:

s2026q1._domainkey.example.com  TXT  old public key
s2026q3._domainkey.example.com  TXT  new public key

During the transition, mail signed with either selector can verify. Once all senders use s2026q3, the old selector can be retired.

Key rotation is also a useful operational review. Confirm that dormant services are not still using the domain, remove retired vendors' DNS delegations, ensure your domain ownership contacts are current, and review who can make DNS edits. Email authentication is both a deliverability practice and an access-control practice.

DKIM setup checklist

Use this checklist before considering DKIM complete:

• Identify every system that sends email with your domain in From:.
• Obtain the exact DKIM selector and DNS record from each managed provider.
• Decide whether each record must be TXT or CNAME; do not substitute one for the other.
• Publish the record in the authoritative public DNS zone.
• Confirm the final hostname is exactly <selector>._domainkey.<domain>.
• Use dig or nslookup to verify public DNS resolution.
• Ensure the sending system has DKIM signing enabled for the intended domain.
• Send a test through the real REST API, SMTP relay, or mail route used in production.
• Inspect raw recipient headers for dkim=pass.
• Confirm the DKIM d= domain aligns with the visible From: domain for DMARC.
• Document selectors, owners, key dates, and rotation procedures.
• Keep old selector records during planned rotations until all signing traffic has moved.

FAQ

What DNS record type does DKIM use?

DKIM commonly uses a TXT record at <selector>._domainkey.<domain>. Some managed email platforms instead require a CNAME record at that selector hostname, which delegates the DKIM lookup to the provider. Publish the record type the sending platform explicitly supplies.

How long does DKIM take to start working?

The sending platform may begin signing immediately after it detects the DNS record, but public DNS caching can delay verification. Check the record from external resolvers, then send a test message and inspect the recipient's full headers. Do not rely only on a DNS dashboard's “saved” confirmation.

Can I have more than one DKIM record for a domain?

Yes. Multiple DKIM selectors are normal and often necessary when different applications, departments, or providers send mail for the same domain. Each selector has its own hostname, such as app._domainkey.example.com and marketing._domainkey.example.com.

Why does DKIM pass but email still land in spam?

DKIM confirms signing-domain authorization and message integrity; it does not establish a positive sending reputation. Spam placement can still be affected by complaint rates, low engagement, suspicious content, poor list quality, missing DMARC alignment, IP reputation, sudden volume changes, or recipient-specific filtering.

Do I need DKIM if I already use SPF?

Yes. SPF and DKIM authenticate different parts of an email's delivery identity. SPF evaluates the sending IP against the envelope sender domain, while DKIM verifies a cryptographic signature. Deploying both gives DMARC more reliable aligned authentication paths and improves resilience when mail is forwarded or routed through third parties.