The practical answer is: configure modern DKIM for production email, and treat old DomainKeys as a lab-only protocol. DKIM is still relevant because mailbox providers use it to verify that a message was signed by a domain that controls the matching public key in DNS. DomainKeys, the older Yahoo-originated protocol that used the DomainKey-Signature header, is obsolete for normal deliverability work.
If I were setting up a sending domain today, I would publish a DKIM TXT record at selector._domainkey, configure the 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 the same organizational domain as the visible From address.
Do not spend production effort trying to make legacy DomainKeys accepted by modern receivers. Sender adoption does not matter when receivers no longer validate the old protocol. Big senders that still emit DomainKeys headers usually have old signing code that was never removed.
Configure modern DKIM first
A clean DKIM setup has four moving parts: a private key, a public key in DNS, a selector, and a signing rule. The private key stays on the sending system. The public key goes in DNS. The selector tells receivers which DNS name to query. The signing rule tells the MTA or platform which domain and selector to use.
- Choose: Pick the signing domain, such as emails.example.com, and a selector such as default, s1, or 2026a.
- Generate: Create a private and public key pair. Use RSA 2048-bit unless your provider gives a different supported option.
- Publish: Add the public key as a TXT record at selector._domainkey.your-sending-domain.
- Sign: Configure the outbound mail system to sign with the matching selector, domain, and private key.
- Verify: Send a message and inspect the authentication result, rather than relying only on DNS.
Modern DKIM TXT recorddns
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 your outgoing message says d=emails.example.com and s=default, a receiver queries that exact DNS location for the public key.
Flowchart showing the DKIM setup path from key creation to verification.
What to publish in DNS
For DKIM, the public DNS record starts with v=DKIM1. That version tag makes the record unambiguous for modern DKIM validators. Keep the private key off DNS, off ticket comments, and out of shared docs. If the private key leaks, rotate the selector and remove the old record after mail signed with the old selector has aged out.
|
|
|
|---|---|---|
Selector | default | Key lookup |
Domain | emails | Signing scope |
Version | DKIM1 | Record type |
Key type | RSA | Crypto method |
Compact DKIM DNS labels
Most broken DKIM records are not conceptually wrong. They fail because of DNS formatting: missing quotes in a long TXT value, extra spaces inside the public key, a selector typo, or publishing the key under the wrong domain.
- Name: Use selector._domainkey plus the exact signing domain used in the DKIM header.
- Value: Keep the public key as continuous base64 text inside the TXT value.
- TTL: Lower it before a planned rotation, then raise 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 you are studying old infrastructure or testing an old MTA that still claims to sign it.
Modern DKIM
- Header: Uses DKIM-Signature on the outbound message.
- DNS: Publishes v=DKIM1 at the selector DNS name.
- DMARC: Can satisfy DMARC when the signing domain matches the visible From domain rules.
- Use: Use it for every production sending source.
Legacy DomainKeys
- Header: Uses DomainKey-Signature on older messages.
- DNS: Uses a legacy key record and optional policy record.
- DMARC: Does not solve current DMARC requirements.
- Use: Keep it to old-system labs and controlled tests.
If you still want to configure DomainKeys for learning, publish it separately from your working DKIM setup. Do not put legacy DomainKeys policy tags into your modern DKIM record and expect that to improve deliverability.
Legacy DomainKeys public key recorddns
dklegacy._domainkey.emails.example.com. TXT ( "k=rsa; t=y; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
Legacy DomainKeys policy recorddns
_domainkey.emails.example.com. TXT "t=y; o=~"
Do not reuse the same selector blindly
The tricky part is that DKIM and DomainKeys both use names under _domainkey. That does not mean you should publish two TXT values at the same selector name. Some validators dislike multiple TXT records at a DKIM key name, and operationally it creates needless confusion.
- Best: Use one selector for production DKIM and a different selector for any legacy DomainKeys lab.
- Avoid: Do not publish a DKIM1 record and a legacy DomainKeys record at the same owner name.
- Remember: 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 your sender added the header. You need a receiver or test environment that actually parses the legacy header, retrieves the matching key, checks the body hash, and reports the result.
How to test the result
Testing has two layers. First, confirm the DNS record is readable. Second, send real email and confirm the message passes authentication at the receiver. DNS validation catches selector, syntax, and key-format problems. Message testing catches signing-domain mistakes, body changes after signing, missing signatures, and key mismatches.
Google Workspace Admin Console screen showing DKIM setup controls.
Hosted mail platforms handle much of the signing configuration for you. For example, the Google setup docs and Microsoft DKIM docs both center the workflow on generating a selector, publishing DNS, and enabling signing after DNS resolves.
For a self-managed MTA, I test by sending to a mailbox that exposes authentication results and by reviewing the raw headers. The key lines are the DKIM result, the selector, the signing domain, and the 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 opens the report when the test is ready.
?/43tests passed
Preparing test address...
Why big senders still show DomainKeys
When a big sender still emits a DomainKeys header, it does not prove the old protocol has deliverability value. It usually means the sender layered DKIM on top of an older signing implementation and never removed the older header. In some environments, leaving it enabled cost less engineering time than deleting and retesting an old path.
That difference matters. Sending a header and receiving benefit are separate things. A receiver that does not evaluate DomainKeys will not reward or penalize it in the same way it treats DKIM. I have also seen old signatures fail silently because no one was watching them. The business risk was not that DomainKeys failed. The risk was that the team mistook an old header for a current authentication control.
Relevance by use case
How I classify DomainKeys work when deciding where to spend effort.
Production DKIM
High
Required for a serious sender program.
DMARC rollout
High
DKIM helps when the signing domain matches DMARC rules.
Legacy DomainKeys
Low
Useful for controlled historical testing only.
DomainKeys in production
Avoid
Adds complexity without modern receiver value.
How Suped fits into the workflow
DKIM setup is not finished when DNS resolves. I want to know which sources are sending, which ones pass, which ones fail, and whether those failures affect DMARC. That is where DMARC monitoring matters more than a one-time record check.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's product is the stronger practical choice for most teams because it connects DKIM, SPF, DMARC, blocklist monitoring, and deliverability signals in one place. The useful workflow is simple: add the domain, validate DNS, watch real traffic, get alerts when authentication changes, then follow issue-specific steps to fix the source.
For ongoing operations, Suped's product gives you automated issue detection, real-time alerts, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, and MSP multi-tenancy. The point is not to check DKIM once. The point is to keep every sending source visible after teams add new platforms, change DNS, or rotate keys.
If you need 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. I check these before assuming the cryptography is the problem.
- Selector: The selector in the message header must match the selector in DNS exactly.
- Domain: The signing domain must be the domain you published the selector under.
- Forwarding: Mailing lists and gateways can alter a signed body and break DKIM after it leaves you.
- Rotation: Keep old selectors live long enough for queued mail and delayed delivery.
- Headers: If a platform rewrites From, Reply-To, or List headers after signing, test 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 and then work through the causes covered in DKIM failures.
Views from the trenches
Best practices
Use separate selectors for DKIM and any DomainKeys lab so DNS tests stay clear later.
Validate a signed message, not only the DNS TXT value, before trusting the setup.
Keep DomainKeys testing in isolated systems because modern receivers ignore it now.
Common pitfalls
Treating a visible DomainKeys header as proof of receiver-side validation is unsafe.
Publishing legacy policy tags inside a DKIM1 record creates confusion without benefit.
Reusing one selector for multiple key formats makes DNS troubleshooting harder later.
Expert tips
Rotate DKIM with a new selector first, then remove the old key after mail queues clear.
Use DMARC aggregate data to find sources that send without valid DKIM signatures.
For DomainKeys study, build a lab receiver that verifies the old signature format.
Expert from Email Geeks says DomainKeys adds processing and message bytes, while modern receivers do not use it.
2021-10-26 - Email Geeks
Marketer from Email Geeks says a historical lab is the right place to test DomainKeys because current software rarely validates it.
2021-10-26 - Email Geeks
Use DKIM, leave DomainKeys in the lab
The correct production configuration is modern DKIM: a DKIM1 TXT record, a matching private key on the sender, a DKIM-Signature header on outbound mail, and verification through real messages. DomainKeys is not worth production time unless you are maintaining a very old closed environment that explicitly requires it.
For learning, use a separate selector and a controlled receiver that can validate DomainKey-Signature. For deliverability, spend the effort on DKIM that passes, SPF that stays within lookup limits, DMARC reporting that shows real sources, and alerts that catch drift before it becomes a policy problem.
