DKIM: the signature that shows which domain sent an email
Every email from a domain that signs its mail carries a DKIM signature in its headers. Checking it tells you which domain stands behind the message and whether its signed parts changed after sending.
A new subscriber’s inbox
- 09:01:05Email arrives: “Welcome to Northwind, here’s 20% off”From: hello@northwind.example
- 09:01:05DKIM-Signature header readd=northwind.example · s=mail2026
- 09:01:06Public key fetched from DNSTXT record at mail2026._domainkey.northwind.example
- 09:01:06Body hash recomputedMatches bh= in the signature
- 09:01:06Signature verifieddkim=pass, signed by northwind.example
Northwind is an invented company. The receiver needs nothing from the sender beyond the key its DNS already publishes.
DKIM, short for DomainKeys Identified Mail, is a signature a sending domain adds to each email, which any receiver can check against a public key the domain publishes in its DNS. A pass shows that the domain named in the signature took responsibility for the email, and that the parts it signed haven’t changed since.
On this page
What a DKIM signature holds
DKIM is defined in RFC 6376, an Internet Standard published in September 2011. The sending server adds a header called DKIM-Signature to each email. It carries a hash of the body and a list of the headers that were signed. The signature over both is made with the domain’s private key.
- d= (the signing domain): the domain that takes responsibility for the email, such as northwind.example.
- s= (the selector): the name of the key that signed it. The standard lets a domain publish several keys at once, and the selector says which one to use.
- The DNS record: a TXT record at selector._domainkey.domain, for example mail2026._domainkey.northwind.example, that holds the public key.
- bh= and h=: the body hash and the list of signed headers, which the receiver recomputes and compares.
What a DKIM pass proves to a CRM or compliance team
A pass means the domain in d= claimed responsibility for the email, and the hashed content hasn’t changed since it was signed. RFC 6376 is careful about the limits. Verifying the signature asserts nothing else about the message, and a failed check doesn’t by itself force a receiver to reject it. The signing domain also needn’t match the address in the From line, so a careful reader checks d= beside From.
For a CRM lead, that means a colleague can check that a competitor’s domain sent this welcome offer, in these words, on this date. For a compliance lead, a signed renewal notice or cancel confirmation shows which company sent it and that its signed parts are exactly as sent.
How a DKIM check works
The receiving server runs the check without asking the sender anything. It reads the selector and domain from the header, fetches the TXT record from DNS, recomputes the body hash and verifies the signature with the public key. The result is a pass or a fail, with the domain that signed.
How signed emails are kept as evidence
An email forwarded inline is a new message from whoever forwarded it, and a PDF of an email drops its headers, so both lose the signature. The raw message file keeps every header, and the check can be run again for as long as the domain still publishes that key. Once a company retires the key, a later check fails, which is why the result recorded on arrival is the one worth keeping.
Obsession collects what companies show only to customers, step by step: their screens, emails and texts, member prices, trial limits, quotes and cancel offers, each dated with a screenshot. Teams and AI agents look up any company through the API or MCP, and a company not yet covered is added on request. Every email it keeps is the raw message, with its sender checked by DKIM and the time it arrived. At any company you name, a welcome offer, a price-rise notice or a cancel confirmation can be traced to the domain that sent it. An agent fetches the raw email and its DKIM result with the evidence call, over the API or MCP.
No. A pass shows which domain took responsibility for the email and that its signed parts are unchanged. It says nothing about whether the offer inside is fair or the links are safe.
The name in the s= tag that tells a receiver which of the domain’s keys signed the email. The public key sits in a TXT record at selector._domainkey.domain.
Yes, if the raw message was kept with its headers and the domain still publishes the key under the same selector. Keep the result recorded when the email arrived, because keys are retired.
See sample dataSources
In the order the page cites them. Every page was read on 11 Nov 2026.