What is a DNS DKIM record?

A DNS DKIM record publishes the public key that receiving mail servers use to verify a cryptographic signature on email. DKIM stands for DomainKeys Identified Mail. A valid signature associates the message with the signing domain and confirms that the signed content passed DKIM verification. The signing domain can differ from the address shown in the From header; DMARC checks that relationship through alignment.

DKIM is not a standalone guarantee that a message is safe. It does not prove that the visible sender is trustworthy, and it does not stop all phishing. Its job is narrower and still important: it gives receivers a way to check whether a domain's signing key matches the signature attached to a message.

The DNS part matters because the public key is retrieved from a TXT record. If DNS is wrong, missing, stale, or too large for the resolver path, DKIM verification can fail even when the mail platform is signing messages correctly.

Selectors and record names

DKIM uses a selector to find the right key. A selector is a label chosen by the sending system. The receiving server reads the selector from the message's DKIM signature, then looks up a DNS name formed from that selector and the sending domain.

For a selector named s1 on example.com, the DNS name is commonly:

s1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."

The TXT value starts with v=DKIM1. The p= value contains the public key material. Some records include other tags, depending on the key type and mail platform. The private key is never published in DNS; it stays with the system that signs outbound mail.

Selectors allow a domain to use more than one key. A company may have separate selectors for a primary mail platform, a marketing system, a billing system, and a support desk. It may also introduce a new selector during key rotation while the old selector remains available for messages that are still in transit.

How verification works

When a mail server receives a signed message, it reads the DKIM-Signature header. That header identifies the signing domain, selector, algorithm, signed headers, and signature value. The receiver retrieves the DKIM public key from DNS and uses it to verify the signature.

If the message has not been altered in the signed portions and the key matches, DKIM can pass. If the message body or signed headers were modified, if the DNS key is missing, or if the signature uses a key that no longer exists, DKIM fails.

This verification is especially useful when combined with SPF and DMARC. SPF checks whether the sending IP is authorized. DKIM checks whether the message carries a valid domain signature. DMARC tells receivers how to evaluate alignment between the authenticated domain and the domain visible to the recipient, and what policy the domain owner requests when checks fail.

Planning DKIM for real mail streams

Start by inventorying every system that sends mail using the domain or a subdomain. Common senders include employee mail, password reset services, invoicing systems, marketing platforms, CRM tools, support desks, monitoring systems, and legacy application servers. Each sender needs a clear authentication path.

For each sender, identify whether it signs mail itself, delegates signing to a hosted provider, or requires the organization to publish a provider-supplied DKIM record. Hosted providers often ask for either TXT records containing keys or CNAME records that point to provider-managed DKIM records. Both patterns can be valid, but they create different ownership and rotation models.

Use separate selectors where practical. Sharing one selector across unrelated systems makes rotation harder and can increase blast radius if a key needs to be replaced. Selector names do not need to reveal sensitive internal details. A simple naming convention that identifies the provider or rotation generation is usually enough.

Common DNS problems

The most common DKIM failure is a record published at the wrong name. _domainkey is easy to miss, and some DNS dashboards automatically append the zone name while others require the full name. A record that looks right in the dashboard may resolve under the wrong hostname if the name was entered incorrectly.

Large TXT records can also cause problems. Long public keys may be split into quoted strings in DNS zone files. That is normal when done correctly, but accidental spaces, missing quotes, or broken copy-and-paste can change the key. Some old DNS tooling or resolver paths also struggle with large UDP responses, making testing from more than one network useful.

Another problem is premature deletion during key rotation. Mail can be delayed, queued, forwarded, or retried. If the old selector is removed as soon as a new key is enabled, some legitimate messages may fail DKIM because receivers still need the old public key to verify mail already sent.

Finally, not every DKIM pass is aligned for DMARC. A third-party sender might sign with its own domain rather than the organization's domain. That can produce a valid DKIM result but still fail the policy objective if the signing domain does not align with the visible From domain.

Security and deliverability implications

DKIM improves both trust signaling and message integrity, but only if the keys are managed carefully. Private signing keys should be protected, rotated when appropriate, and removed from systems that no longer send mail. DNS records for retired selectors should eventually be removed, but only after allowing enough time for delayed mail to clear.

Attackers often abuse weak email authentication by sending messages that appear to come from a trusted brand or business process. DKIM alone does not stop that abuse, but it gives receiving systems one strong signal. When DKIM, SPF, and DMARC are configured together, domain owners get better control over how receivers treat unauthenticated mail.

For operations teams, DKIM failures can affect deliverability. Important transactional mail may go to spam, be quarantined, or be rejected, depending on receiver policy and the domain's DMARC posture. A DNS typo can therefore become a customer support incident.

Rollout and maintenance checks

Before publishing a DKIM record, confirm the exact selector, domain, record name, TTL, and value from the sending platform. Query the record from authoritative DNS and at least one recursive resolver. Send a test message to mailboxes that expose authentication results, then inspect the headers for DKIM pass, signing domain, selector, and DMARC alignment.

During rollout, avoid changing many mail senders at once. Enable and verify one stream, then move to the next. Keep the previous selector available during rotation, and document when it is safe to remove. Update monitoring so authentication failures are visible before they become a broad deliverability issue.

DKIM is easy to describe but easy to break with small DNS mistakes. Treat each selector as a production credential: know who owns it, know which mail it signs, test it after DNS changes, and retire it deliberately when the sender is gone.

Related learning

• What is a DMARC DNS record?
• What is a DNS MX record?
• Common DNS issues and how to diagnose them