d= for data

A few ISPs use the d= value in the DKIM signature as a way to provide FBL and reputation data to senders. This has some good bits, in that senders can get FBLs and other information regardless of the IP address they’re using and whether or not they have sole access to it.

magician's hat with stars exploding out the top

There are also some challenges with using the d= as a data identifier. One of them is that ESPs may not be able to get a full picture of what their overall customer base is doing if their customers are signing with their own d= value.

Some ESPs have solved this by adding two DKIM signatures to the email. The first signature is with their own d= value, one that is shared across all their customers. The second is with the individual d= for that particular customer.

There are a couple questions that regularly come up when I discuss double DKIM signing with folks. One of them is how much weight is given to the shared DKIM signature? There is some, but if the domains are signed in the correct order, the ESP domain seems to fade into the background of reputation.

Another question of the questions related to double DKIM signing is will signing twice reveal information about the sending infrastructure to the receivers or the end users. The answer to this is not in the vast majority of cases. Most ESPs provide IP addresses for their customers to use. These IPs are identified as belonging to the ESP and ownership can be determined using standard tools. While many end users probably may not be able to easily figure out who the ESP is experts and ISPs can.

But what happens for ESPs that use one of the API based providers? For instance, an ESP that uses Sendgrid or Amazon SES may want to allow customers to sign with their own d= but also monitor all their customers. In this case, they should be able to sign with their own shared d= before handing the message off to the ESP. The ESP can then sign with their own key and then, finally, sign with the customer specific key.

There is theoretically no limit to the number of DKIM signatures you can add to a message. You just need to be careful about which of the headers you sign, to avoid having them altered during future steps. Of course in practice there are unlikely to be cases where quadruple DKIM signing is necessary. But I say that now and someone will point out a case where it makes sense.

In any case, there are no technical reasons to limit DKIM signatures to one or two. This is very helpful for those cases where DKIM is being used in ways unrelated to reputation.

Related Posts

Are they using DKIM?

It’s easy to tell if a domain is using SPF – look up the TXT record for the domain and see if any of them begin with “v=spf1”. If one does, they’re using SPF. If none do, they’re not. (If more than one does? They’re publishing invalid SPF.)
AOL are publishing SPF. Geocities aren’t.
For DKIM it’s harder, as a DKIM key isn’t published at a well-known place in DNS. Instead, each signed email includes a “selector” and you look up a record by combining that selector with the fixed string “._domainkey.” and the domain.
If you have DKIM-signed mail from them then you can find the selector (s=) in the DKIM-Signature header and look up the key. For example, Amazon are using a selector of “taugkdi5ljtmsua4uibbmo5mda3r2q3v”, so I can look up TXT records for “taugkdi5ljtmsua4uibbmo5mda3r2q3v._domainkey.amazon.com“, see that there’s a TXT record returned and know there’s a DKIM key.
That’s a particularly obscure selector, probably one they’re using to track DKIM lookups to the user the mail was sent to, but even if a company is using a selector like “jun2016” you’re unlikely to be able to guess it.
But there’s a detail in the DNS spec that says that if a hostname exists, meaning it’s in DNS, then all the hostnames “above” it in the DNS tree also exist (even if there are no DNS records for them). So if anything,_domainkey.example.com exists in DNS, so does _domainkey.example.com. And, conversely, if _domainkey.example.com doesn’t exist, no subdomain of it exists either.
What does it mean for a hostname to exist in DNS? That’s defined by the two most common responses you get to a DNS query.
One is “NOERROR” – it means that the hostname you asked about exists, even if there are no resource records returned for the particular record type you asked about.
The other is “NXDOMAIN” – it means that the hostname you asked about doesn’t exist, for any record type.
So if you look up _domainkey.aol.com you’ll see a “NOERROR” response, and know that AOL have published DKIM public keys and so are probably using DKIM.
(This is where Steve tries to find a domain that isn’t publishing DKIM keys … Ah! Al’s blog!)
If you look up _domainkey.spamresource.com you’ll see an “NXDOMAIN” response, so you know Al isn’t publishing any DKIM public keys, so isn’t sending any DKIM signed mail using that domain.
This isn’t 100% reliable, unfortunately. Some nameservers will (wrongly) return an NXDOMAIN even if there are subdomains, so you might sometimes get an NXDOMAIN even for a domain that is publishing DKIM. shrug
Sometimes you’ll see an actual TXT record in response – e.g. Yahoo or EBay – that’s detritus left over from the days of DomainKeys, a DomainKeys policy record, and it means nothing today.

Read More

Four things to check before your next mailing

Like many bits of technology, email is often set-and-forget. Everything is checked and rechecked during setup, and then no one goes back and looks at it again. But mail programs are not static, and people make changes. These changes don’t really break things, but over time they can create their own set of problems.
Setting aside some time every quarter or even every year to check and make sure all the bits of mail are configured correctly is a good idea.

Read More

Don't just follow the HOWTO

speakingIconForBlogThere are so many moving parts to ensure good email deliverability. Email marketers need to know marketing, they need to know email and they need to know design. The technical bits of email can be a challenge to learn, and many folks who write tutorials and How-Tos write them for a different audience than marketers.
One of the things I’m trying to do is demystify the technical end of email for marketers. Today I talked about authentication in the Only Influencers newsletter. Check it out!
Understanding the technical: Authentication
Authentication in general

Read More