How to configure DomainKeys DKIM for email authentication and is it still relevant?
Updated on 25 Oct 2026: We clarified DKIM setup and receiver checks, including how to rotate keys and revoke a leaked key.
Configure DomainKeys Identified Mail (DKIM) for production email, and keep legacy DomainKeys in controlled tests. DKIM uses a digital signature to verify the signing domain and detect changes to signed message content. It does not encrypt email or establish that the content is trustworthy. DomainKeys, the older Yahoo-originated protocol that used the DomainKey-Signature header, is obsolete for normal deliverability work.
For a new sending domain, publish the TXT record or CNAME delegation supplied by the email platform at selector._domainkey.example.com, configure the mail transfer agent (MTA) or email platform to add a DKIM-Signature header, send a real message, then verify the DNS key and the signed message. A quick DNS-only check can start with a DKIM checker, but the final proof comes from a real message that passes DKIM and then passes DMARC using a signing domain that matches the visible From domain under DMARC rules.
Current bulk sender requirements for personal Gmail and Yahoo Mail accounts include both SPF and DKIM, plus a published DMARC policy with at least p=none. DKIM must also match the visible From domain under DMARC alignment rules when it supplies the passing authentication path for DMARC. A valid DKIM signature supports authentication, but it does not guarantee inbox placement.
Do not spend production effort trying to make legacy DomainKeys satisfy modern DKIM requirements. The Historic DomainKeys specification was obsoleted by DKIM in 2007. A DomainKey-Signature header does not satisfy DKIM or DMARC authentication requirements.
Configure modern DKIM first
A clean DKIM setup has four moving parts: a private key, a public key available through DNS, a selector, and a signing rule. The private key stays on the sending system or with the email platform. The public key is published directly in a TXT record or reached through a provider-supplied CNAME. The selector tells receivers which DNS name to query. The signing rule tells the MTA or platform which domain and selector to use.
- Pick the signing domain, such as emails.example.com, and a selector such as default or 2026a.
- Create the key pair in the sending platform or generate it locally for a self-managed server. For RSA, use RSA-SHA256 and prefer a 2048-bit key. RSA keys below 1024 bits and RSA-SHA1 signatures fail the DKIM cryptographic requirements.
- Add the public key as a TXT record at selector._domainkey.your-sending-domain, or publish the exact CNAME records supplied by a managed platform.
- Configure the outbound mail system to sign with the matching selector, domain, and private key. Enable signing after the platform confirms that the DNS records resolve.
- Send a message and inspect the authentication result, rather than relying only on DNS.
Modern DKIM TXT record (illustrative)dns
default._domainkey.emails.example.com. TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
The DNS name above means the selector is default and the signing domain is emails.example.com. If the outgoing message says d=emails.example.com and s=default, a receiver queries that exact DNS location for the public key. The abbreviated p= value is a placeholder; publish the complete public key supplied by your sending platform.
DKIM configuration steps: create keys, publish DNS, configure signing, send a test, and verify the result.
Plan DKIM for every sending source
DKIM is configured per sending source and signing domain, not once for an entire organization. Inventory every system that sends as the domain, including the primary mail platform, transactional systems, support platforms, and marketing platforms. Each source needs a provider-supported signing setup and a signing domain that works with the visible From domain.
- Map each sending source to its visible From domain, DKIM signing domain, selector, DNS record type, and owner.
- Publish the exact TXT value or CNAME target supplied by that source. Do not convert one record type into the other.
- For relaxed DMARC alignment, the DKIM d= domain and visible From domain must share the same organizational domain. Strict alignment requires an exact domain match.
- Give independent platforms different selectors and key pairs so each key can be rotated or removed without affecting another source.
A message can show dkim=pass and still fail DMARC when the passing d= domain does not match the visible From domain under DMARC rules. Messages can also contain multiple DKIM signatures. One valid signature with the required domain match is enough for DKIM to supply the passing DMARC authentication path.
A dedicated subdomain can separate a third-party mail stream from the main domain while keeping relaxed DMARC alignment. For example, a visible From address at example.com can match a DKIM signing domain at mail.example.com under relaxed alignment when example.com is their shared organizational domain. Confirm the exact domain plan before publishing records because a provider-controlled d= domain outside example.com will not match.
What to publish in DNS
When the public key is published directly, the DKIM TXT value normally starts with v=DKIM1. This recommended tag must be first when present; DKIM1 is also the default when it is omitted. A managed platform can instead provide CNAME records that point the selector to keys it hosts. Keep a self-managed private key out of DNS and shared documents. If the private key leaks, revoke it promptly and use a replacement key under a new selector, even if delayed messages fail. For a directly published key, an empty p= value revokes the key; for a hosted key, use the provider's revocation process. Cached keys remain usable until their cached TTL expires.
|
|
|
|---|---|---|
Selector | default | Key lookup |
Domain | emails.example.com | Signing scope |
Version | v=DKIM1 | Recommended first tag; defaults to DKIM1 |
Key type | k=rsa | Public-key algorithm; key size comes from the key data |
Public key | p=... | Complete base64-encoded public key |
DKIM DNS names and record tags
A long TXT value can contain multiple quoted strings within one TXT record. Each string is limited to 255 octets, and receivers concatenate them without adding spaces. Do not create separate TXT records for the chunks of one key. DNS editors that append the zone automatically usually need default._domainkey as the host within the emails.example.com zone, rather than the complete domain name. Follow the DNS host's input format.
DKIM DNS failures include truncated key data, selector typos, multiple key records at one name, the wrong record type, or publication under the wrong signing domain.
- Use selector._domainkey plus the exact d= signing domain from the DKIM header. Confirm that the DNS editor has not appended the domain twice.
- Publish the complete TXT value or the provider's exact CNAME target. A CNAME and a TXT record cannot coexist at the same DNS name.
- Allow for DNS propagation and cached negative answers before enabling a new selector. For routine rotation, lower TTL at least one existing TTL period beforehand, then restore it after the new selector is stable.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Where legacy DomainKeys fits
DomainKeys and DKIM share similar concepts, but they are not the same protocol. DKIM uses the DKIM-Signature header. Legacy DomainKeys used DomainKey-Signature. DKIM is the standard that matters for production authentication and DMARC. DomainKeys is useful only when studying old infrastructure or testing an old MTA that still claims to sign it.
Modern DKIM
- Uses DKIM-Signature on the outbound message.
- Uses a selector key record, normally beginning with v=DKIM1.
- Can satisfy DMARC when the signing domain matches the visible From domain rules.
- Use it for every production sending source.
Legacy DomainKeys
- Uses DomainKey-Signature on older messages.
- Uses a legacy key record and optional policy record.
- Cannot supply the DKIM authentication path for DMARC.
- Keep it to old-system labs and controlled tests.
If you still want to configure DomainKeys for learning, publish it separately from the working DKIM setup. Do not put legacy DomainKeys policy tags into a modern DKIM record and expect that to improve deliverability. The legacy t=y flag enables testing, and o=~ in a DomainKeys policy permits unsigned mail; neither replaces DMARC. The abbreviated public key below must be replaced before use.
Legacy DomainKeys public key record (illustrative)dns
dklegacy._domainkey.emails.example.com. TXT ( "k=rsa; t=y; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
Legacy DomainKeys policy recorddns
_domainkey.emails.example.com. TXT "t=y; o=~"
Use one DKIM key record per selector
DKIM and DomainKeys both use names under _domainkey. The DKIM specification requires a unique TXT key record for each selector name; results are undefined when multiple key records are returned. Multiple quoted strings within a single TXT record are different from multiple TXT records.
- Use one selector for production DKIM and a different selector for any legacy DomainKeys lab.
- Do not publish a DKIM1 record and a legacy DomainKeys record at the same owner name.
- The selector in the message header must match the selector in DNS.
A visible DomainKeys header is not proof that DomainKeys works. It only proves that a header was added. A receiver or test environment must parse the legacy header, retrieve the matching key, verify the signature over the selected headers and message body, and report the result. DomainKeys does not use DKIM's separate bh= body-hash field.
Test DKIM DNS and delivered messages
Testing has two layers. First, confirm the DNS record or delegated CNAME is readable. Second, send real email and confirm the message passes authentication at the receiver. DNS validation catches selector, syntax, record-type, and key-format problems. Message testing catches signing-domain mistakes, body changes after signing, missing signatures, and key mismatches.
Google Workspace DKIM setup with a selector field, DNS TXT record, and Start authentication controls.
Hosted mail platforms handle much of the signing configuration. For example, the Google setup docs and Microsoft DKIM docs describe generating or assigning selectors, publishing the supplied DNS records, and enabling signing after DNS resolves. Google Workspace uses a TXT record, while Microsoft 365 supplies CNAME records. Use the values shown in the platform rather than constructing targets from an example.
For every sending platform or self-managed MTA, send to a mailbox that exposes authentication results and review the raw headers. Check the DKIM result, selector, signing domain, and DMARC result. If the record exists but messages are not signed, use a targeted guide for DKIM not signing before changing DNS again.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Read DKIM headers and authentication results
Open the delivered message's raw headers or "Show original" view. A DKIM-Signature header contains signing data, not a pass/fail verdict. Use the Authentication-Results header added by your receiving provider, rather than an untrusted result supplied by the sender. The Authentication-Results specification defines the result values.
Illustrative signature fields and receiver resultstext
From: sender@emails.example.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emails.example.com; s=default; h=from:to:subject:date; bh=...; b=... Authentication-Results: mx.receiver.example; dkim=pass header.d=emails.example.com header.s=default; dmarc=pass header.from=emails.example.com
The values above are abbreviated for illustration. The d= and s= tags identify the signing domain and selector. The h= tag lists signed headers, bh= contains the body hash, and b= contains the signature. The c= tag selects canonicalization; relaxed/relaxed tolerates specified formatting changes, not substantive edits to signed content. None of these fields contains the private key.
|
|
|---|---|
dkim=pass | The signature verified. Confirm that its signing domain meets DMARC domain requirements. |
dkim=none | The message was not signed. Check that signing is enabled for this sending source. |
dkim=fail | Signature verification failed. Compare the key and signer settings, and check for changes after signing. |
dkim=temperror | A temporary error prevented verification, such as a DNS timeout. Check DNS availability and retry. |
dkim=permerror | A permanent error prevented verification, such as a missing required header field. Correct the reported cause before retesting. |
Common DKIM results reported by a receiver
What a legacy DomainKeys header tells you
When a big sender still emits a DomainKeys header, it does not prove the old protocol has deliverability value. An older signing component is one explanation, but the header alone does not establish why it remains enabled. Check the sender's configuration and current DKIM results before treating the legacy header as a working authentication control.
Relevance by use case
A practical classification of DomainKeys work by operational value.
Production DKIM
High
Current standard for signing outbound messages.
DMARC rollout
High
DKIM helps when the signing domain matches DMARC rules.
Legacy DomainKeys
Low
Useful for controlled tests or explicitly required old systems.
DomainKeys in production
Avoid
Does not satisfy modern DKIM or DMARC requirements.
How Suped fits into the workflow
DKIM setup is not finished when DNS resolves. Ongoing checks need to show which sources are sending, which ones pass, which ones fail, and whether those failures affect DMARC. DMARC monitoring helps track those results across sending sources.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's DMARC reporting and email authentication platform shows reported sending sources and their authentication results. Add the domain, configure aggregate reporting, then review sources with DKIM failures or DMARC domain mismatches before changing DMARC enforcement.
Use Suped's authentication alerts to investigate changes after adding a sending platform, editing DNS, or rotating keys. DMARC aggregate reports arrive on a reporting schedule, so use a newly delivered test message to confirm an authentication change immediately.
For a broader snapshot before setting policy, run a domain health check and review DKIM, SPF, and DMARC together. A DKIM pass alone is useful, but it does not tell the whole authentication story.
Common DKIM mistakes to avoid
Most DKIM failures come from small mismatches. Check these before assuming the cryptography is the problem.
- The selector in the message header must match the selector in DNS exactly.
- The key lookup must use the d= signing domain, and that domain must match the visible From domain under the selected DMARC alignment mode when DKIM supplies the DMARC pass.
- SPF checks the sending IP against the envelope sender domain and often fails after forwarding. DKIM can survive forwarding when signed content remains intact, but mailing lists and gateways that change a signed header or add a footer can break the signature.
- For routine key rotation, publish the new selector before switching, confirm a signed message passes, and retain the old public key long enough for queued or delayed mail. Revoke a leaked key promptly instead of using this overlap procedure.
- If a platform rewrites a signed header or the message body after signing, test the final delivered message again.
When a failure persists, troubleshoot the message header and DNS record together. The fastest route is to compare the header values with the live TXT record or CNAME chain and then work through the causes covered in DKIM failures.
Frequently asked questions
No, not for production email. DKIM is the relevant standard. DomainKeys is useful only for historical learning, old closed systems, or a controlled lab where both sender and receiver support it.
No. Keep the modern DKIM record as a DKIM1 selector record. For legacy DomainKeys testing, publish its key and policy records separately.
Some old software used compatible RSA key material, but that does not make the protocols the same. For production isolation, use separate selectors and key pairs rather than sharing a key with a legacy test.
An older signing component is one explanation, but a header alone does not establish the sender's reason. It also does not prove that receivers validate DomainKeys or that the header improves current deliverability.
Check the DNS selector, send a real message, inspect the receiving provider's Authentication-Results header, and confirm DKIM passes for the expected signing domain. Also confirm that the domain meets DMARC requirements when DKIM supplies the DMARC pass.
Yes. DKIM can pass for a d= domain that does not match the visible From domain under DMARC alignment rules. In that case, DKIM does not supply a DMARC pass, although SPF that passes and meets DMARC domain requirements can still satisfy DMARC.
