DKIM

What the signature actually covers

DKIM, DomainKeys Identified Mail, is defined in RFC 6376. It attaches a DKIM-Signature header to a message. That header carries a hash of selected header fields and of the body, encrypted with the sending domain’s private key, plus a selector that tells the receiver where to find the matching public key in DNS. The receiver recomputes the hash over the message it received, fetches the key, verifies the signature, and adds a result to the Authentication-Results header it will use for filtering.

The important word is selected. DKIM does not sign the whole message. It signs a declared list of header fields and the body. If a field is not in the list, it can be changed without invalidating the signature, which is a feature and a risk. A message can be modified to add a header that the signature never covered, and the signature still passes. That is why policy and user-interface signals matter alongside the cryptographic check.

The body hash is the part that catches content tampering. A signature survives a change to a header it does not cover, and fails if a single byte of the canonicalised body changes. Most of the failures that senders see are not tampering at all; they are canonicalisation mismatches caused by a mail system adding a footer, rewriting a line ending or re-encoding a character set somewhere between the signer and the verifier.

What DKIM is not doing for you

DKIM is not encryption. It does not hide the content, and it does not protect the message from being read in transit if transport encryption is absent. It also does not protect the message after delivery. A signature proves integrity between signing and verification, and nothing after that.

DKIM is not SPF. SPF, defined in RFC 7208, checks the envelope sender against a list of authorised IP addresses published in DNS. It operates on the SMTP conversation rather than the message content, it breaks when mail is forwarded, and it is limited to ten DNS lookups before it fails. DKIM operates on the message and survives forwarding, which is why the two are complementary rather than alternatives.

DKIM is not DMARC either. DMARC, in RFC 7489, is a policy that tells a receiver what to do when a message claiming your domain fails authentication and alignment. It consumes DKIM and SPF results. A sender can have a technically perfect DKIM signature that passes verification and still fail DMARC because the signing domain does not align with the From domain. Confusing the three leads teams to declare authentication finished while the actual policy is doing nothing.

A fourth thing DKIM does not do is establish that the domain is reputable. Receivers combine the signature result with domain reputation, engagement history and the content of the message. A brand-new domain with perfect alignment and no sending history will still be filtered, and a long-established domain with weak authentication will often be delivered anyway. Authentication removes one reason to reject mail; it does not create a reason to accept it. Teams that treat a DKIM pass as a delivery guarantee spend the next quarter debugging placement instead of fixing content and list quality.

Canonicalisation, and why relaxed wins in practice

Before hashing, the signer normalises the message according to a canonicalisation algorithm, and the receiver must normalise it the same way. RFC 6376 defines two: simple, which changes nothing, and relaxed, which collapses whitespace, trims trailing empty lines and normalises header field names and values. Header and body canonicalisation are declared separately, so a common configuration is relaxed for headers and relaxed for the body, written as relaxed/relaxed.

Simple canonicalisation is brittle. Any mail system that rewrites a line ending, appends a footer, converts quoted-printable or adds a trailing newline will break the body hash. Since almost every message passes through at least one system that does one of those things, simple is a reliable way to produce mysterious failures that appear only for some recipients. Relaxed is tolerant of exactly those transformations and is the pragmatic default.

The l= tag, which limits hashing to the first l bytes of the body, is worse than either. It was intended to let a mailing list add a footer without breaking the signature, and it also lets an attacker append content that the signature does not cover. Modern guidance is to avoid l= entirely. If a system needs to modify the body, it should re-sign rather than rely on a length limit.

Encoding is the usual culprit behind a canonicalisation failure that only affects some recipients. A template engine that converts quoted-printable to base64, a gateway that re-encodes UTF-8 as ISO-8859-1, or a client that rewrites a long line will change the bytes that were signed. Relaxed canonicalisation tolerates whitespace and line-ending changes but not a character set conversion, because the decoded octets differ. The diagnostic is to capture the message as it leaves the signer and as it arrives, then compare the canonicalised bodies directly. When they differ, look for the middleware in between rather than the signer.

Selectors: the small label that makes rotation possible

A selector is a name that identifies which key signed a message. The signature header contains s= with the selector, and the receiver looks up the public key at selector._domainkey.yourdomain, in a TXT record. The selector is arbitrary. It can be a date, a version number, a purpose or a random string. What matters is that it is unique per key, documented, and never reused for a different key.

The indirection exists so that a domain can have several keys live at once. You can publish a new selector, start signing with it, keep the old selector published while messages signed with it are still in flight or sitting in queues, and retire the old key only after a period longer than the longest delivery delay you expect. Without selectors, rotation would mean a window in which every message fails verification, which is why domains that skip rotation eventually have a very old key or no key at all.

Two operational habits make selectors manageable. First, name them so the purpose is obvious, such as s1, s2 or a month stamp, and keep a register that maps selector to key owner, algorithm, creation date and retirement date. Second, never delete a selector on the same day you stop signing with it. Mail can sit in a queue, a greylisting server or a recipient’s deferred folder for days, and verification happens on arrival, not on send.

Documentation is the part of selector hygiene that fails silently. The selector lives in a DNS record, a signing configuration, a mail platform and often a second platform for a second stream, and when the person who set it up leaves, the mapping is lost. Keep a register with the selector, the domain, the algorithm, the key size, the creation date, the owner and the planned retirement date. Store it next to the sending infrastructure rather than in a personal notebook, and review it at the same time as the domain inventory. A rotation that takes an afternoon instead of a week is a direct return on that record.

Which headers to sign, and the traps in the list

The h= tag lists the header fields covered by the signature. From is mandatory and must be present. In practice a good list also covers To, Subject, Date, Message-ID, MIME-Version, Content-Type and Reply-To, plus any header your platform relies on for routing. The rule of thumb is to sign every header that a receiver might use to decide what the message is or who sent it.

Oversigning is the technique of listing a header more times than it appears, which prevents an attacker from adding an instance that the signature does not cover. Listing From twice, for example, means an extra From header would change the hash and break the signature. It is cheap, and it closes a class of header injection that has been used in real phishing.

The traps are less obvious. Signing a header that a downstream system routinely modifies, such as a tracking header or a subject tag added by a marketing platform, guarantees failures for that stream. Signing nothing beyond From leaves Subject open to modification. And signing with a key whose DNS record is missing a p= value, or has an empty one, tells receivers the key has been revoked, which is a deliberate way to fail every signature for that selector.

The Date header deserves a note because it interacts with signature expiry. A message signed on a host with a clock a few minutes ahead can look expired when it arrives, and a host that is behind can produce a signature the receiver treats as not yet valid. Keep signing hosts on synchronised time and avoid long queues between signing and delivery. Queueing is common in Indian campaign sending during a festival peak, and a signature that was valid at signing can expire before the message leaves the queue.

Key size, algorithms and what the standards now require

RSA keys of 1024 bits were common a decade ago and are now considered too weak for signing. RFC 8301 updates RFC 6376 to require rsa-sha256 and to deprecate rsa-sha1, and it sets a floor on RSA key size. A 2048-bit RSA key is the normal choice today, and it produces a DNS record that is long enough to cause its own problems in registrar panels.

Ed25519 signing is defined for DKIM in RFC 8463 and produces much smaller keys and signatures. Support is not universal, which means it is usually deployed alongside RSA rather than instead of it: publish an ed25519 selector and an RSA selector, sign with both, and let the receiver verify whichever it understands. That improves cryptographic strength without creating a delivery cliff for receivers that only do RSA.

Whatever the algorithm, the private key is the asset to protect. It should live in a key management service or an HSM-backed store, not in a repository or a configuration file on a web server. Access should be limited to the signing service, rotation should be possible without a code deploy, and every use should be logged. A leaked DKIM key lets an attacker sign mail that passes authentication for your domain, which is worse than not signing at all.

Storage of the private key deserves the same attention as its length. A key generated in a control panel and pasted into an environment variable tends to end up in a screenshot, a support ticket or a repository history. Generate it inside the key service, export only the public half, and give the signing service an identity that can use the key without reading it. If the platform cannot do that, rotate more often and treat the key as a short-lived secret rather than a fixture.

Rotation: a runbook, not an annual scramble

Rotation is the practice of replacing a signing key on a schedule and after any suspected compromise. A three to six month cadence is common for marketing streams; a shorter cadence is reasonable for high-value transactional mail. The cadence matters less than the procedure, because a rotation done badly causes an outage and an outage teaches a team to avoid rotation.

The sequence has five steps. Generate the new key pair and store the private half in the key store. Publish the new public key under a new selector and wait for DNS propagation, verified from more than one resolver. Switch the signer to the new selector and confirm that outgoing mail shows the new selector in its signature and passes verification. Keep the old selector published for at least the maximum delivery delay plus a margin. Then retire the old selector and archive the private key according to policy.

The failure mode to design against is switching the signer before the DNS record is visible. Some resolvers cache negative answers, so a receiver that looked up the new selector a minute too early may keep failing for the duration of that negative TTL. Publishing first and switching after a verified propagation check, from a resolver that is not your own, removes the race. The second failure mode is retiring the old selector too early, which breaks mail that was signed before the switch and delivered after it.

Alignment is where DKIM meets DMARC

A DKIM signature passes when the cryptographic check succeeds. DMARC alignment asks a different question: does the d= domain in the signature match the domain in the From header, under the alignment mode the domain published. Relaxed alignment allows an organisational match, so mail from marketing.example.co.in signed by example.co.in can align. Strict alignment requires an exact match. Passing without aligning is the most common reason a sender has green DKIM results and a red DMARC result.

Third-party senders create the alignment problem. When an email platform signs with its own domain, the signature is valid and worthless for your DMARC policy, because the visible From is yours. The fix is to have the platform sign with your domain, which means publishing its selector in your DNS and giving it a key, or to use a CNAME delegation that lets the platform host the key under your zone. Both are standard, and both require a DNS change that a marketing team often cannot make alone.

Subdomains are the pragmatic compromise. Sending marketing mail from a dedicated subdomain, signed by that subdomain, gives clean alignment and isolates reputation, so a bad campaign does not damage transactional mail. The trade-off is that the subdomain starts with no reputation, which is why it needs its own warm-up and its own monitoring rather than inheriting the parent’s standing automatically.

Indian DNS pitfalls that break otherwise correct setups

The signing logic is usually right and the DNS is usually wrong. The most common Indian problem is a registrar or hosting panel that splits a long TXT value into chunks incorrectly, inserting spaces or quoting each chunk separately. A 2048-bit RSA public key produces a value long enough that the panel’s character limit forces chunking, and a malformed record produces a permanent key lookup failure that looks like a signing problem.

The second is the underscore label. DKIM records live at s1._domainkey.example.in, and some older Indian registrar panels reject or silently drop labels beginning with an underscore, or refuse to create the CNAME that a delegated setup needs. The third is propagation. A change made at a registrar with a long TTL and a slow zone update can take hours, and a rotation scheduled without accounting for that window will fail on the first attempt and be diagnosed as a key problem.

Smaller traps are just as disruptive. A trailing dot added by a panel turns the record into an absolute name that does not resolve. A wildcard TXT record catches the lookup and returns the wrong value. DNSSEC, where enabled, can cause a signed zone with a broken delegation to return SERVFAIL for the key query, which receivers treat as a temporary error rather than a failure. And a selector documented nowhere means the next engineer cannot rotate the key without guessing.

Testing, reading failures and a worked example

Test from the outside. Send to a seed panel that covers Gmail, Outlook, Yahoo and at least two Indian providers, and read the Authentication-Results header rather than a dashboard summary. The header shows dkim=pass with the domain and selector, which confirms both the cryptographic result and which key was used. A pass with an unexpected selector usually means a rotation landed in the wrong environment.

Learn the four common failure strings. body hash did not verify means the body changed after signing, which is usually a footer injector or a re-encoding step. no key for signature means the DNS lookup failed, which is usually the selector name, the underscore label or propagation. signature expired means the timestamp is outside the receiver’s tolerance, which is usually a clock skew on the signing host. key revoked means p= is empty, which is deliberate and should never appear by accident.

A Jaipur retailer with about 400,000 messages a month had DKIM passing for transactional mail and failing intermittently for campaigns. The seed test showed the campaign stream adding a footer image after signing, which changed the body. The team moved the footer into the template before signing, switched to relaxed/relaxed canonicalisation, and published a second selector so the next rotation could run without a gap. Campaign DKIM pass rates went from 71% to 99.6% over a week, and the DMARC aggregate reports stopped showing a third of the volume as unauthenticated.

Keep a small, permanent record of authentication results per stream. A table with the date, the sending domain, the selector, the DKIM and SPF results, the DMARC disposition and the provider turns a vague complaint about deliverability into a trend line. When a rotation goes wrong, the table shows the exact day the selector changed, which is faster than reading logs. It also gives you evidence for a client review that does not depend on anyone remembering what happened in March.