Searching for Truth in DKIM: Part 4 of 5

by J.D. Falk
Director of Product Strategy, Receiver Services

Once you’ve determined that you can trust the signer of a message, as we discussed in part 3, it’s easy to extrapolate that various portions of the message are equally trustworthy. For example, when there’s a valid DKIM signature, we might assume that the From: header isn’t spoofed. But in reality, DKIM only tells us two basic things:

  1. Does the message have a valid signature? (yes or no)
  2. Which identifier signed the message? (the d= domain)

DKIM uses a cryptographic signature based on a hash of the message, so if the signature is valid, we also know that the message wasn’t changed in any way between the time it was signed and the time the signature was verified. What we don’t know, and can’t know, is what happened — intentionally or unintentionally — before it was signed.

For example, I could write a message where I claim to be Joshua Norton, Emperor of these United States and Protector of Mexico. It’ll be signed when I send it to you. But DKIM doesn’t tell you if it’s true that I’m Emperor Norton I — and doesn’t even tell you if it was actually me making that claim. All you really know is that the message has a valid signature and was signed by

That’s a fairly broad example, though, so let’s dig through some thorny specifics.

In most mail client software, the only identifier the recipient ever sees is the From: header (or, worse, all they see is the “friendly from” — but that’s another issue.)

Lacking a strong ADSP assertion, DKIM does not tell you if the domain in the From: header is truthful or not.

A common vector for phishing or malware distribution is to send a message that looks to recipients as if it’s from a known and trusted brand, and include links to that brand’s web site — except for one link, which goes to the bad guy’s site. While DKIM can tell you if the message was modified, the bad guy can apply a new signature via his own domain– after which DKIM does not tell you whether the links are truthful or not.

Similarly, phishing experts talk about “close cousin” domains — vs., vs., et cetera. DKIM does not tell you whether the domain is truthful, or is trying to fool recipients.

And DKIM itself includes an additional identifier, the “i=” value, which looks like (but isn’t) an email address. The signer can set i= to whatever they want, as long as the part after the @ is the same as the d= domain. Cisco uses this to identify individual users: [email protected] More common, I’d expect, will be use of i= to denote distinct mailstreams or internal divisions: [email protected], [email protected], [email protected]

Thing is, i= is an opaque identifier. There’s simply no way for anyone outside of the signing domain to know whether [email protected] is a mailstream, a department, a individual email address, or simply a string of randomly generated characters. DKIM does not tell you what it means, or if it’ll mean the same thing in the signature of another message. DKIM does not tell you if i= is truth; thus, reputation is more likely to accrue to the d= value.

What DKIM does do is simple, and powerful. Knowing that you have a message with a valid signature isn’t enough by itself. Knowing the d= identifier, the signing domain, isn’t enough by itself. But once we do know those things, a presumption of truth can be based on trust.

Domains like are likely to have a good reputation, both on their own and verified by programs like Sender Score Certified — which indicates that they’re trustworthy. When a message is signed by, we can (almost always) safely assume that other characteristics of the message are equally trustworthy. We can trust the From: header, and the links, and the images, as much as we trust the domain. But when a message is signed by, which would have bad or no reputation, we can safely assume that all characteristics of the message are equally untrustworthy.

In the final part of this series, we’ll make some predictions about what all this trust (or distrust) and truth (or untruth) will mean to you.

Miss parts 1, 2 or 3? Read them now!

minute read

Popular stories



BriteVerify email verification ensures that an email address actually exists in real-time


The #1 global data quality tool used by thousands of Salesforce admins


Insights and deliverability guidance from the only all-in-one email marketing solution

GridBuddy Cloud

Transform how you interact with your data through the versatility of grids.

Return Path

World-class deliverability applications to optimize email marketing programs

Trust Assessments

A revolutionary new solution for assessing Salesforce data quality


Validity for Email

Increase inbox placement and maximize subscriber reach with clean and actionable data

Validity for Data Management

Simplify data management with solutions that improve data quality and increase CRM adoption

Validity for Sales Productivity

Give your sales team back hours per day with tools designed to increase productivity and mitigate pipeline risks in real-time