It occurred to me that DKIM verified emails, from major players (e.g., GMail), could open the door to more modern OpenPGP robot key signing authorities.

The idea would be to ask people to send a key singing request to a known address (e.g., [email protected]), and to sign their request with their OpenPGP key. The DKIM signature of that email would then be checked so as to verify that the requester has control over the claimed account (i.e., that GMail, for example, asserts that the email was sent by a valid / authenticated user). If everything checks out, the bot would sign the corresponding identity in the sender's public key, and send it back.

My understanding is that DKIM makes it much more difficult to spoof an email address when the "From: " header is included in the DKIM signature.

So, I ask the community here, what are some weaknesses or limitations of this approach? Here are some of the issues that I've considered:

  • In the past, DKIM keys were much too short (< 1024 bit RSA). This has been resolved.
  • DKIM public keys are hosted as DNS records, and plain-old DNS can be spoofed (perhaps pinning can be used for major players)
  • DKIM keys are perhaps less protected than other security credentials, as their primary purpose is to combat spam and phising (no solution?).

Are there other dangers I'm overlooking?

NOTE: For what it's worth, it would appear that keybase.io is toying with this idea (https://github.com/keybase/keybase-issues/issues/373)

2 Answers 2


This is an interesting idea, and I had to consider for a few moments whether there would be flaws, but there are.

(plain) DNS is insecure

You already realized this, but you could verify DNSSEC signatures to prevent faked DNS entries. Pinning might be viable, but what to do in case of keys changed in purpose?

DKIM signs the domain, not users

Quoating RFC 6376, DomainKeys Identified Mail (DKIM) Signatures,

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message.

Lots of mail servers only verify user's credentials when accepting submitted mails, and not the sender address. This means for the mail provider example.net, you can sign in as [email protected] and send mails as [email protected] (which would result in a correct DKIM signature), often also for other domains like [email protected] (which would result in a broken or none DKIM signature). You can set the From: field rather arbitrarily, and that's not even something mail servers are supposed not to be allowing.

DKIM only guarantees valid sending servers, not permitted sending users. It is meant to prevent fake servers to send mails, which is the most common source of spam messages.

Multiple users might be able to send from a given mail address

There are use cases where multiple people can sent from a given address, but are not allowed to receive messages. Use cases might for example be:

  • support systems, where a unique sender address is used, but internally tickets are routed to the specific operators
  • newsletter systems and similar operation modes where there are operators allowed to send mail (and have valid DKIM records for their own servers), but should not receive feedback
  • mailing lists

If DKIM would verify users, the proposed schema would allow those senders to get keys signed, although they are not intended recipient. This might be an issue, and might not be, but would require further definition of what the certification describes. The common understanding is rather a validation of recipients.

  • 1
    These are all great points. There may yet be some value to this approach -- it would, perhaps, be an improvement over the identity verification done by the PGP Global Directory (keyserver.pgp.com) or by other free S/MIME services. Nevertheless, it's good to understand the limits of such a verification scheme.
    – afourney
    Commented Dec 6, 2015 at 21:07

DKIM only makes the promise that a specific mail server processed the mail. Only DMARC creates is an association between the From header in the mail and the DKIM signature. But this association is restricted only to the domain part of the address, or even only the organizational domain depending on the restrictions in the DMARC record.

There is no proof that the mail address set in From-header of the mail is actually used in the MAIL FROM part of the SMTP dialog. I.e. it might be that the first is [email protected] while the second is [email protected]. Because the domain part of the From address still fits the DKIM signature everything looks fine.

It might be that the mail server will make sure that the sender given in the SMTP dialog and the From header will be the same. But I can find nothing about this in DKIM or DMARC specification. And while gmail and yahoo seem to rewrite From if it does not match the SMTP envelope there is no guarantee that others will do it too. This means, that you cannot use a DKIM signature to validate an E-mail address as long as you don't know how this case is handled by a specific mail provider now and also in the future.

  • Yes. I hadn't considered that the SMTP dialog is separate from the mail headers.
    – afourney
    Commented Dec 6, 2015 at 20:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .