Franck Martin on the Future of DKIM and Domain-Based Reputation

So my friend, Fred Tabsharani of Port25 Solutions, ran an interesting interview Franck Martin from on the future of DKIM and Domain-Based Reputation. This has been in the works for a few weeks now and really came out nice.

5 Questions with Franck Martin on the Future of DKIM and Domain-Based Reputation 

Below is my interview with Franck Martin, Email Deliverability Services Engineer at, and contributing group member of the Internet IETF, in its effort to standardize the use of DKIM.  This interview was conducted via Skype since Franck just happens to live in Suva, Fiji. 

Q:FT – RFC 4871 (DKIM) essentially makes RFC 4870 (DomianKeys) obsolete.  In your opinion, what’s the future of DKIM and its overall traction in email industry thus far?

A:FM – The greatest thing that has come from the Internet Engineering Task Force (IETF) is that when an organization or an individual develops an Internet communication protocol, such as DKIM, the IETF makes it rock solid.  Essentially they look at it from all angles, strengthen it, and put their stamp of approval on it to basically say it has the quality of a standard. This shows its maturity and robustness as well as acceptance throughout the industry.  DKIM is not here to solve the spam problem, it’s just here to validate the domains that are taking ownership for sending the email.  DKIM is often times confused with signing.  Yes, DKIM signs some email headers as part of its process, but it does not sign the whole email.  PGP, and S/MIME are protocols that sign emails and are more complex to implement than DKIM because they require user participation.  DKIM requires only the mail administrator participation (and he/she is supposed to understand emails better than any other classic user).  DKIM also helps mitigate some phishing attacks, but here too, it will not solve phishing.  An email cannot claim to be from say, have a DKIM signature related to and not be validated back to, providing that ebay states, via Author Domain Signing Practices (ADSP) or other means, that all their email will have their own DKIM validation. Unfortunately, it is not that simple, because the recipient mail server needs to perform various checks with the information that DKIM, ADSP and other tools provide.  I could send an email claiming to be from and be DKIM validated back to, and a lot of users may not recognize that is not the same domain as

Q:FT – Have we reached an inflection point with DKIM?

A:FM – For the moment it’s the big players that are implementing DKIM.  If you want to have a FBL through any of the ISPs, then DKIM is a requirement.  For the smaller players, the value will come through the implementation of tools like SpamAssassin.  SpamAssassin is adding rules so that emails which pass the DKIM signature may be whitelisted.  A recent study done by Cisco shows there has been a strong growth of emails using DKIM.  It is more complex to identify DKIM use, because it is not like SPF, querying domains does not indicate the potential use of DKIM like SPF does.  Author Domain Signing Practices (ADSP), another IETF initiative, is a complement to DKIM.  It essentially adds information to the validation process to specify the policy of using DKIM for a domain name. If you receive an email that does not include a DKIM signature, you can check the domain name.  If it states that all emails will have DKIM, then you can safely drop/trash that email.   SpamAssassin is also implementing such rules.  There is another value of DKIM.   For instance when a bank sends you an email, you can validate the domain of the bank, but how do you know it truly is a bank?  A well-known industry association could include their DKIM validation as a third party which would provide a more influential path for reputation.  Finally with IPv6, IP based reputation has some serious challenges to overcome due to the database size required to contain all possible IPs. Domain based reputation may be the only way to have email work over IPv6.  At we strongly support the adoption of DKIM (we use it too of course), and personally, when I was on the board of the Internet Society (which is strongly linked to the IETF), I supported its Trust and Identity initiative (which includes promoting DKIM adoption).

Q:FT – We’ve noticed that email headers from large companies utilize multiple modes of email authentication.  Some in fact are using all four—DKIM, SPF, Domain Keys, and SenderID. Is this redundant? Can we now officially call DKIM the standard?

A:FM – DomainKeys is becoming obsolete. Since Yahoo is moving to DKIM, there is no more reason to use DomainKeys.  Organizations such as MAAWG and ESPC require at least one form of signing and DKIM is one recommended method.  It is likely to become a requirement quickly because of various industry reputation organizations.  SenderID does not seem to have traction anymore, but SPF is a different story.  First for a sender, SPF is very easy to implement because all you need is to add one record to your DNS, and SPF provides a unique functionality in that if you want to know all the servers that a particular domain is sending from, you can use SPF to acquire a list of IP addresses. This is helpful when you try to figure out if you are blocking any IPs when a customer complains he is not receiving emails from the email address of his mother.  This shows there is a need for this type of information.

Q:FT – Regarding the early adoption with domain-based reputation by ISPs, where in the email header will these reputation effects be based?   

A:FM – My understanding is that it’s in the d= string, where the domain reputation will be based.   Organizations will use this domain as a reputation filtering mechanism when checking against DNS records (ADSP) and past behavior.  Essentially, what do we know about this sender (or domain)? As I understand, per IETF RFC, only the d= should be the criteria for reputation analysis.  Again, each ISP may treat this differently, and ongoing testing is taking place.  Because each ISP has different business rules with domain-based reputation, the IETF is trying to confirm to various implementers what is the intent of the standard.

Q:FT – Will there still be a need to warm-up IPs and establish a reputation through ISPs before sending large quantities of email?

A:FM – Since each ISP has its own filtering systems, warming up IPs would probably still be required to a certain extent.  Since DKIM naturally links to domain reputation, and since DKIM will help domain-based reputation, it will be faster to warm up IPs but we still have to exercise caution given that each ISP has its own set of business policies.  Now, on a side note, because we move to domain reputation, it will be useful to know who is behind each domain. On its side, ICANN is trying to limit bad behavior with domain registration such as “domain tasting.”   Domain tasting it is a practice where you can register a domain and drop it within the grace period without having to pay for it.   It allows people to use domains to send emails from and switch to another domain after a few days, making it difficult to track the source of the emails and which entity is responsible for that domain. There are other concerns with domain registration, but that's another issue. However, we have be certain that DKIM does not become an ICANN issue, because too many people are trying to bloat ICANN's mission. DKIM is an email administrator tool and may become a requirement but I don't think we will see in the future any major player, dare to drop any emails which does not include DKIM.

Franck has gone on record to say that when I visit Fiji, he will have an exotic Fijian cocktail waiting ☺

Fred Tabsharani



Don't Just Send, Deliver!

Dennis Dayman

More posts by

Oracle | Eloqua

Don’t Just Send, Deliver!

Follow Dennis Dayman


5 Responses to “Franck Martin on the Future of DKIM and Domain-Based Reputation”

  1. Deirdre Baird
    September 22, 2009 at 11:05 am #

    Based on conversations directly with the ISPs, AOL & Yahoo are using DKIM and moving to domain-based reputation to augment IP. However, Hotmail is sticking to SenderID at the moment and other ISPs such as Verizon have yet to implement or enforce authentication. DKIM + SPF are the preferred authentication models and, where possible, should be implemented together. Hotmail is the lone top isp relying on SenderID – but since they'll default back to the spf1 record (the classic SPF vs. senderid record), a mailer implementing SPF can still achieve authentication via Hotmail. (for a summary of our ISP interviews see:

  2. Franck Martin
    September 22, 2009 at 3:08 pm #

    Deirdre, this is a nice document, a must read.

    However I'd like to point out, my understanding is that Yahoo will not base the reputation on the s= field (the selector). The s= field is for easy key management and not for reputation, several people in the IETF DKIM WG have pointed out that s= should not be used for reputation.

  3. Jim Fenton
    September 22, 2009 at 5:10 pm #

    Excellent summary of DKIM and reputation. A couple of small points I'd like to clarify:

    1. ADSP practices saying that all emails are signed (dkim=all) don't imply that it's safe to drop/trash email without a valid signature, because of the potential for signatures to be broken in transit. A different ADSP practice, dkim=discardable, says that the author domain requests the verifier to drop/trash email without a valid signature, even though signature breakage may cause some messages to be lost.

    2. While it is likely that reputation systems will use d=, DKIM stops short of specifying that because the working group's charter excluded the design of reputation systems. My feeling is that reputation systems will use whatever they find useful, and right now d= seems the most useful. But I agree that s= is not a good choice because it interferes with key management, and makes periodic rotation of keys difficult. It wouldn't be a good situation if it became necessary to "warm up" a new key before using it heavily.

  4. Franck Martin
    September 22, 2009 at 9:50 pm #

    I'd like here to say thanks to Dave Crocker for his mentoring on DKIM and his advice. I would not be here without his help.

  5. Eric Gillette
    October 14, 2009 at 4:02 pm #

    Well, I think using both methods combined will net the kind of results we can all expect to help validate e-mails properly.

    I also think "backscatter" has to be limited as well using the same policies, or an application like SpamDyke to prevent the junk in the first place.

    Of course opinions will vary, and courses of action will differ, but I think we're on the right track to a solution that will work for everyone.