Searching for Truth in DKIM: Part 5 of 5

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

Throughout this series of articles we’ve been talking about DKIM, and what a valid DKIM signature actually means.

Part 1 explained that the DKIM “d=” value identifies the domain name which signed the message, which may be different from the author of the message. Part 2 described how the author domain can gain some control over whether any other domain name should ever sign a message purporting to be From: that author domain. Part 3 discussed how the reputation of a d= domain leads to a reliable determination of trustworthiness, while part 4 reminded us that truth cannot be assumed until trust is certain.

What this means for senders (of any type) is that with DKIM, you’re protected. On the internet, your domain name is a statement of your brand identity — so by signing messages with DKIM, you can finally, irrevocably tie those messages to your brand. As your brand reputation improves, so does the deliverability of your messages. And if you change IP addresses, your reputation follows.

What this means for ESPs who send on behalf of others is that you can finally send your client’s mail using your client’s reputation. I didn’t get into this earlier, but you can even sign the message with both your client’s d= domain and your own d= domain, likely resulting in a combined reputation score for that particular message. Steve Atkins goes into more detail here. This concept is so new, though, that it isn’t yet clear what the best practice will be.

What this means for receivers (of any type) is that there’s now a much more useful identifier to hang reputation on. You can stop fiddling with IP addresses, thus reducing the risk of false positives due to shared IPs, or forwarding, or a formerly bad IP being reassigned to a good sender. You can develop more complex and accurate reputation models when a message has multiple signatures, thus multiple d= identifiers. And in a few years, you’ll be able to safely assume that anyone who isn’t signing with DKIM doesn’t really care if their mail gets delivered.

What this means for users — the end recipients of all these messages — is still unclear. A few ISPs have experimented with icons or text indicating that a message is signed, but (as we know) that alone doesn’t mean it’s trustworthy. There are many other interesting ideas floating around, though. A message signed by a trusted domain will probably be delivered to the inbox, but that’s old news. It might be permitted to include rich media elements: images, video, etc. Most mail clients already indicate when a message is From: an address in your address book or contact list; I could easily imagine this feature being upgraded to only show the address book icon when the message was signed by the appropriate domain. The possibilities are endless, and I’m certain we’ll see some interesting experiments over the next few years.

Did you miss the first four parts of this series? Get caught up now:

Part 1
Part 2
Part 3
Part 4

minute read

Popular stories

Products

BriteVerify

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

DemandTools

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

Everest

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

Solutions

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