The Final Word on DKIM and Deliverability

The Final Word on DKIM and Deliverability

By: J.D. Falk of Return Path

Seems like every week, I see another industry colleague asking for a detailed list of how each DKIM option affects deliverability. Everyone who's asked for this is a smart person, generally clueful, but this question stumps me. Perhaps it's that while I learned about email technology as a way to get a message from one autonomous system to another, he learned about it in the frustrating context of trying to figure out why his mail was being blocked — so it has never before crossed his mind that new email technology might be invented that won't make delivery of his marketing messages more difficult.

See, DKIM isn't some wacky new anti-spam method intended to reduce your ability to get mail delivered (that's what that made-up word "deliverability" means, after all.) It's authentication, designed to make it easier to identify the good senders.

DKIM only answers two questions:

  1. Does the message have a valid signature?
  2. If it does, what domain signed it?

The signing domain, identified by the d= tag in the DKIM signature header, is the only part of the DKIM signature where the choices you make now will directly affect the continued deliverability of your messages. This is because d= is how you tell the receiving system who you are.

With a valid signature on the message, if the receiving system has a domain-based whitelist, and your d= is on it, the message gets in. If they have a domain-based blacklist, and your d= is on it, the message will be rejected. Few mailbox providers have either of those today — but if they have a domain-based reputation system, which we know the big mailbox providers are working on, then delivery depends on reputation. It's exactly the same as with IP addresses today.

And just as with IP addresses, consistency is critical. If you want to separate different mailstreams, then instead of sending from different IPs like you were before, you can now sign with different domains: shipping.example.com, marketing.example.com, corporate.example.com. Within the context of authentication, each of those is an entirely separate entity. Reputation assessment systems will quickly figure out that there's a relationship between everything that's part of example.com, though, so you can't use this to escape the much-deserved bad reputation of a bad mail stream.

If you send through an ESP today, chances are they sign with their own domain. This means that if you switch to another ESP, you can't take your reputation with you. However, it also means you can borrow the ESP's reputation as long as you're their customer. Work with your ESP to choose the configuration most appropriate for your situation.

So you can stop worrying, sign your mail, and get back to the important work of making sure your recipients are happy to receive the messages you send.

If you're interested, here's a rundown of all the other options in the base spec — RFC 4871 — and what effect they're likely to have on delivery of signed messages. If you haven't read the introduction and the terminology and definitions section yet, please do so now.

There's currently only one acceptable value for the version (v=) tag. If yours isn't 1, then the DKIM signature isn't valid. Effect on deliverability: none if it's 1, otherwise the message will be treated as if it wasn't signed.

The algorithm (a=) is very important to cryptography geeks, but we're not talking about ICBM launch codes here. Unless you remember why DLG2209TVX was replaced with CPE1704TKS, accept whichever algorithm and key size your mail software vendor or ESP recommends and be done with it. (Just watch, someone will comment that rsa-sha1 is insecure because someone could decrypt it in a matter of months — per message.) Effect on deliverability: none.

Canonicalization (c=) is a sneaky way to get around the fact that sometimes an intermediary mail server will make minor changes to a message, like capitalizing header field names or snipping empty lines at the end of a message. With the default "simple" algorithm, those changes would cause the signature verification to fail. With the "relaxed" algorithm, those changes may pass. Effect on deliverability: none unless the message fails.

You can choose to specify, in the h= tag, which header fields you're signing. There's a good description in the base spec of why you might or might not choose particular fields. If you use this, I'd go with the headers that users are likely to see in their mail client, plus anything you use for tracking. Effect on deliverability: none.

Similarly, you can copy all of the signed header fields into the signature with the z= tag. I'm not sure why you would, except for debugging. Effect on deliverability: none.

The selector (s=) is just a way to look up which key you're using, allowing you to use multiple keys with the same domain. You might have different keys for different offices, or systems, or create a key that you can give to your ESP to sign on your behalf. The selector is also useful for changing keys periodically, in case the private key is no longer private — for example, you could change selectors every other month, removing old ones a few months after you've stopped using 'em. Effect on deliverability: none.

A somewhat controversial option is the body length limit, designated by the l= tag. This allows the signer to say "I signed this much of the message, but there might be more content after that — and if so I'm not responsible for it." It's a reaction to discussion list software which may automatically add an informational footer to the end of a message. Thing is, these lists invariably make other changes also — new headers, et cetera — so the signature would be broken anyway. And, if your focus is on keeping the recipient safe (as it is for all mailbox providers), why would you deliver a message where the top part is from a trusted sender and the bottom part could be malware? Effect on deliverability: could be bad. Don't use this.

The q= value is easy: it can only be "dns/txt". Anything else is invalid. Effect on deliverability: none if it's dns/txt, otherwise the message will be treated as if it wasn't signed.

There are two optional tags referring to time: t= is the time the signature was created, while x= is when it expires. Both of these are designed to catch stupid criminals. If the signature was (allegedly) created after the message was received, it's not valid. Or if the message is received after the signature expires, it's not valid. While it's not entirely clear what will happen in the wild, I'd recommend skipping both of these. Effect on deliverability: none if the times match up or the tags aren't used; otherwise, the message will appear suspicious.

A formerly controversial feature is the i= tag, which looks like an email address — but probably isn't. As I explained back in March, Cisco uses this to identify individual users: i=santaclaus@cisco.com, if Santa Claus worked for Cisco. And you know, he might. More common, I'd expect, senders will use i= to denote distinct mailstreams or internal divisions for their own tracking purposes: i=transactional@example.com, i=marketing@example.com, i=nyc-office@example.com. Thing is, there's simply no way for anyone on the receiving side to know whether marketing@example.com is a mailstream, a department, a individual email address, or simply a string of randomly generated characters. As such, reputation is more likely to accrue to the d= value. Effect on deliverability: probably none.

So unless you use l= or have unrealistic expectations about i= or s=, as we discussed above, d= is the only thing that matters. See? Nothing to worry about.

————

-Dennis
Eloqua

Don't Just Send, Deliver!

Dennis Dayman

More posts by

Oracle | Eloqua

Don’t Just Send, Deliver!

Follow Dennis Dayman

Tags: ,

6 Responses to “The Final Word on DKIM and Deliverability”

  1. Andries Mooij
    December 1, 2009 at 2:25 pm #

    Great article. It's nice to get the myths cleared up.

    One addition might be the DKIM policy, the _domainkey TXT record (o=~ not all, o=- all are signed). If that's set, and it's not signed, it will hurt deliverability, of course :)

    Last thing: some Feedback Loops (e.g. Yahoo) only accept you if you're signing with DKIM, and if you're not doing those, you will hurt your deliverability.

  2. J.D.
    December 1, 2009 at 3:41 pm #

    DomainKeys used o=, but DKIM ignores it in favor of a new Author Domain Signing Policy (ADSP) record, which I described in:

    http://www.returnpath.net/blog/2009/03/searching-for-truth-in-dkim-pa-1.php

    Yahoo!'s is currently the only complaint feedback loop tagged off of the authenticated domain rather than the source IP address, but I expect to see more mailbox providers follow their lead soon; there are a lot of obvious benefits to both sides, not least of which is ease of management.

  3. Franck Martin
    December 10, 2009 at 4:07 pm #

    Great article.

    What is important to note in a DKIM sense is that if the DKIM signature fails, then the email has to be considered like if there was no DKIM signature at all. Failing does not mean anything worse than no DKIM signature.

    Personally, I think ADSP has still a lot of issues to solve to be really of any use (in particular with mailing lists). People tend to use their own reputation rules like Google do with Ebay emails rather than to rely on ADSP.

    Another point with ESPs. ESPs can do third party signing, they put their reputation on the emails you send via them. And you can give them the possibility to also do first party signing, put your reputation on your emails sent via your ESP (on top of their reputation). In this case, you can carry and build your own reputation, and take it away with you even if you are no longer a customer of the ESP.

  4. Eric Lubow
    March 10, 2010 at 4:25 pm #

    This article is outstanding. Although being who you say you are is important, I notice a lot of SPAMmers are signing their messages. Essentially saying, "I am who I say I am, but I am a SPAMmer so deal with it." Otherwise, DKIM as part of your reputation with the larger MTAs is a good thing to have.

  5. digital signatures
    January 15, 2011 at 1:22 am #

    hey Chris, you have given a wonderful article. you have blowed up my myths regarding DKIM. The various factors like canonicalization, algorithm,version never come into the knowledge of users. Looking forward to more such articles from you.

  6. electronic signatures
    January 16, 2011 at 5:34 am #

    Great post on DKIM and deliverability.especially the concepts of selector and algorithm were just too good.i would be more than happy to check out the given links viz RFC 4871,its introduction and terminology.

UA-9835597-1