DKIM: The Definition, the Mechanics, and the Common Mistake

DKIM (DomainKeys Identified Mail) is an email authentication standard that lets a sending domain attach a cryptographic signature to a message, so any receiving server can verify that the signed parts of that message were authorised by the domain and have not been altered in transit. The signature travels in a DKIM-Signature header; the public key that validates it is published in DNS by the signing domain. It is defined in RFC 6376.

That is the whole definition, and it is worth reading twice, because two words in it carry more weight than people expect. DKIM verifies a domain, not a person, and it verifies the parts of the message the signer chose to sign, not the message as the reader experiences it.

What actually happens on the wire

Your sending platform holds a private key. When a message leaves, the platform computes a hash over the body and over a named list of headers, signs that hash, and writes a DKIM-Signature header carrying the signing domain (d=), the selector (s=), the list of signed headers (h=), and the signature itself (b=).

The receiver reads d= and s=, then looks up a DNS TXT record at <selector>._domainkey.<domain>. RFC 6376 fixes that _domainkey label, which is why every DKIM record you will ever create sits under it. The record contains the public key. The receiver recomputes the hash over the same headers and body, checks it against the signature, and records a pass or a fail.

1. Step 1Sign

   The sending platform hashes the body and named headers and signs the hash with a private key.

2. Step 2Send

   The signature travels in the DKIM-Signature header, carrying d= (domain) and s= (selector).

3. Step 3Look up

   The receiver fetches the public key from a DNS TXT record at <selector>._domainkey.<domain>.

4. Step 4Verify

   The receiver recomputes the hash and compares. Pass or fail is recorded, and DMARC decides what it means.

Nothing in that exchange requires the receiver to contact you, and nothing requires you to know the check happened. The whole verification is a DNS query and some arithmetic, which is why DKIM scales to internet volumes and why a broken record produces silence rather than an error message.

Two properties follow from that design and explain most of what confuses people later.

The selector exists so one domain can hold many keys. Each sending platform gets its own selector, so your transactional provider, your marketing tool and your outbound platform can all sign as the same domain without sharing a private key. Rotating a key means publishing a new selector and switching the signer to it, with no window where mail is unsigned.

A DKIM pass on its own asserts almost nothing about the sender you see. The signature covers whatever domain is in d=, and d= does not have to match the address in the From: header. A message can carry a perfectly valid DKIM signature from a domain the reader has never heard of. The thing that ties the signature to the visible sender is DMARC alignment, defined in RFC 7489, which requires d= to match the From: domain before the pass counts for anything.

Where the textbook definition misleads

The textbook line is that DKIM proves a message was not tampered with. In a live sending programme, four things break that reading.

It signs what it was told to sign. The h= tag lists the headers under the signature. Headers absent from that list are unsigned, and a relay can add or change them without breaking the signature. Body length can also be limited with the l= tag, which leaves anything appended beyond that length unsigned and verifying cleanly. Both are legal and both are surprising.

A pass is not a reputation. DKIM tells a receiver which domain to hold responsible. It does not tell it that the domain is good. Once you authenticate reliably, you have made your reputation legible rather than made it positive, and a well-signed campaign from a burned domain gets filtered accurately rather than generously.

Forwarding breaks it, and that is the normal case, not the edge case. Mailing lists and forwarders that alter the subject or append a footer invalidate the body hash. This is exactly the problem ARC was designed to work around, and it is why a small stream of DKIM failures in your reports is usually a forwarding artefact rather than an attack.

The record is a text field in DNS, so it fails in text ways. Keys longer than 255 characters must be split into multiple quoted strings inside one TXT record. A provider interface that silently wraps, truncates, or double-quotes the value produces a record that looks present and never validates. The tell is a DKIM failure that persists after every credible cause has been ruled out.

There is a fifth item that is not a defect so much as a decision people never make deliberately: key length. A 1024-bit key is still widely accepted and is the default in a lot of tooling; 2048-bit is the stronger choice and is what most managed platforms now issue. The reason it matters operationally is the truncation problem above. A 2048-bit key is long enough to need splitting in a TXT record, so it is the size at which a DNS interface that mangles long values starts to bite. If you are choosing, choose the longer key and then verify the published record character by character rather than assuming the panel wrote what you pasted.

A DKIM pass establishes

• The domain in d= authorised this message
• The signed headers and body arrived unaltered
• A durable identity to attach reputation to
• One of the two ways to satisfy DMARC alignment

A DKIM pass does not establish

• That the From: address is the signing domain
• That unsigned headers are untouched
• That the sender is trustworthy or wanted
• That your mail will reach the inbox

What this means when you are sending cold email

Authentication is the price of entry, not an advantage. Google's email sender guidelines require SPF or DKIM for every sender, and both SPF and DKIM plus DMARC for anyone sending more than 5,000 messages a day to Gmail accounts. Meeting the bar buys you the right to be judged on your reputation. It buys nothing else.

For outbound programmes running many sending domains, the practical work is not understanding DKIM. It is keeping DKIM correct across an inventory that changes: every new domain signed before its first send, every platform migration re-signed under its own selector, every record verified by reading the published DNS rather than by trusting the tool that claimed to write it. That verification step is the one people skip, and it is the one that matters, because a missing record and a working record look identical from inside the sending platform.

The check is cheap. Query the TXT record at your selector, confirm the key comes back whole, and send yourself a message to confirm the header verifies at a real receiver. Then read your DMARC aggregate reports for a week and see which sources are actually signing as you.

That last step catches the failure mode nobody predicts. Aggregate reports list every source sending as your domain, with pass and fail counts per source, and they routinely surface a signing platform somebody set up two years ago and forgot. A forgotten source that fails DKIM is a live drag on the domain's reputation, and it is invisible from every dashboard you normally look at, because your own campaign tool reports only on the mail it sent.

The other habit worth building is treating a new domain's authentication as part of provisioning rather than as a launch task. A sending domain with no DKIM record has to build reputation from a standing start while receivers have no stable identity to attach that reputation to, so the early sends teach them very little. Signing from the first message means the warmup period actually accrues to something. This is the same argument for signing low-volume domains as for signing the busy ones: reputation attaches to the identity the signature creates, and an unsigned domain does not have one.

Verifying DKIM on a sending domain

• ✓Yes: A TXT record resolves at <selector>._domainkey.<domain>
• ✓Yes: The public key returns whole, with no truncation or stray quoting
• ✓Yes: d= matches the domain in the From: header, so DMARC aligns
• ✓Yes: A test message shows dkim=pass in the received headers
• ✓Yes: Each sending platform signs under its own selector
• ✕No: Treating a DKIM pass as evidence of good sender reputation

The short version

One clarification saves a lot of argument on a shared inventory: DKIM is per-domain, not per-mailbox. Every mailbox on a sending domain signs with the same key and inherits the same identity, so a single mailbox behaving badly is not isolated from its neighbours by authentication. Separation between campaigns is a domain-level decision made when the inventory is built, and no amount of correct signing substitutes for it.

DKIM is a domain-level signature and a DNS lookup. It answers one question well, which is whether a domain took responsibility for a message and whether the signed parts survived the trip. Everything people want it to answer, about the visible sender, about intent, and about whether the message lands, is answered somewhere else: by DMARC alignment, by reputation, and by what you actually send.

If you are setting the whole authentication stack up for the first time, the SPF, DKIM and DMARC setup guide covers the records in order, and why DMARC fails covers the six causes worth checking before anything else. If your records are correct and placement is still poor, the problem has moved to reputation and content, and a deliverability audit is the faster path than more DNS work.

RevenueFlow runs cold email and LinkedIn outreach for B2B teams, one message per campaign, on infrastructure we authenticate and monitor ourselves. If you would rather not own this layer, see how the campaigns work.

Standards and platform requirements verified as of August 2026 against RFC 6376 and Google's published sender guidelines. Verify current requirements with the source before relying on them.