DKIM and ADSP: State of deployment

Domain Key Identified Mail (DKIM) is a new technology that allows postmasters to take responsibility for the emails they send (see my post on the future of DKIM). Associated with DKIM is a new specification called Author Domain Signing Policy (ADSP), which provides a policy hint on how the sender treats all the emails it sends.

There are three options:

  1. unknown – equivalent to no ADSP hint at all; the receiver should apply its best guess on what to do with the emails
  2. all – indicates that the sender will have a DKIM signature in all its emails but if the signature is broken or not there, then the receiver should apply its best guess on what to do
  3. discardable – the strictest level of ADSP. Indicates that the sender will add a DKIM signature to all emails they send; if the signature is not present or is broken, then the receiver should discard the email

At the moment, ADSP works in many forwarding cases. However, it breaks with some mailing lists that rewrite parts of the message (for instance adding [topic] to the subject). In such cases, the receiver should be able to identify the problem and refrain from blindly applying the ADSP hints.

While DKIM deployment is growing, where are we with ADSP?

Email domains and ADSP

One way to help track the adoption of ADSP is to investigate the number of domains having an ADSP record in their DNS. The question then becomes, which domains should we use? Alexa would seem to be a logical choice but, unfortunately they aggregate domains hosting web sites, which is not necessarily the same as domains with mail servers. Instead, we sampled 500,000 email domains known to and went to look for their MX records to make sure they are still valid domains. Then, for each domain we checked if there was a TXT record for _adsp._domainkey.(domainname).

To do this we used the simple program below against a csv file of domains:

$file = $argv[1];
$f = fopen($file,"r");
$buffer = fgets($f, 4096);
$i = 1;
while (!feof($f)) {
    $buffer = fgets($f, 4096);
    $domain = substr($buffer, 1, -2);
    echo $i ."|". $domain ."|";
    $foundMX = checkdnsrr($domain, "MX");
    if ($foundMX) {
        $record = @dns_get_record("_adsp._domainkey.". $domain, DNS_TXT);
        if (count($record) > 0) {
            echo $record[0][txt];
        } else {
            echo "noadsp";
    } else {
        echo "NoMX";
    echo "\n";

Our results show that 0.003% (150 domains) of the sampled domains currently have a valid ADSP record.

  • 123 have dkim=unknown
  • 22 have dkim=all
  • 5 have dkim=discardable

There are about 120 million domains registered under a generic Top Level Domains (gTLD), which are not registered with a country code Top Level Domains (ccTLD), as per RegistrarStats. We can expect the same amount for ccTLD domains, although it is difficult to assess as no ccTLD is required to provide statistics. While a sampling of 500,000 domains is limited, we believe it is representative because we know that all these domains are linked to email addresses.


How does it compare with SPF? Lars Eggert runs statistics against famous domain names showing that 50% of the domains have an SPF record.

One particular fact discovered is that 0.0894% (4415 domains) of the domains have used a DNS wildcard for their SPF entry. The side-effect is that DNS answers with the SPF record when queried for the ADSP record.

For instance:
* TXT "v=spf1 -all" will match

Something to think about when implementing ADSP checks.

  • Digg
  • StumbleUpon
  • Facebook
  • Twitter
  • Google Bookmarks
  • DZone
  • HackerNews
  • LinkedIn
  • Reddit
  • Jim Fenton

    The requirement that ADSP records begin with dkim= is an effort to make it as easy as possible to distinguish ADSP records from other text records such as SPF. As you point out, that’s an important check to make. I have found a few attempts at ADSP records that have other things (such as an attempt at a testing flag) first, and those are syntactically incorrect. I have even found a few domains publishing DKIM key records as ADSP records, and that’s just wrong.

    Good data, and generally consistent with what I have seen, but bear in mind that ADSP was just published as an RFC on August 12, so it’s still very early in the deployment cycle.

  • Lincoln DeCoursey

    DNS sampling might have shown a 50% penetration rate for SPF however what I suspect would be a more meaningful measurement is the percentage of domains publishing sufficiently-assertive SPF policy to permit sender address rejection as best practice. If this were to be investigated what I think a researcher would discover is that there are probably more wishy-washy policies than strong ones.

    The trend which I see with emerging anti-spoof techniques is that most designs are quite complex. In particular SPF provides so very many options (e.g. neutral, softfail) to the implementor that unless a policy maker is armed with excellent technical information, he is likely to select some unuseful policy.

    DKIM is only partly an anti-spoof technique, but it’s hard to see it as something which can increase inbound hygiene effectiveness and it’s probably not even effective at anti-spoof enforcement unless mail domains will actually publish assertive ADSP policy. Absent such policy it’s difficult for a would-be verifier to take action against the forged message which lacks DKIM headers.

    In many ways DKIM is more robust and useful than SPF. In terms of anti-spoof enforcement, DKIM protects the From: header value rather than the envelope sender and so it has greater potential to protect inboxes from the appearance of spoofing. However I think that in order for DKIM to emerge as a significant tool in the inbound hygiene toolshed, entirely more emphasis must be placed on ADSP as that thing which actually makes DKIM work. As it is, not even the top email domains are ADSP publishing. Thus DKIM just continues the trend which we see with SPF – it’s way too easy to deploy in a relatively unuseful way.