DKIM Verification Best Practices – Bringing Trust Back to Email
Trusting Email – One of the key challenges for a receiver of email today is to know whether they can trust that email s/he receives is not a scam. Phishing, the fraudulent use of email for the purposes of acquiring personal information from the receiver in order to perpetrate identity theft, is a huge problem. Financial services firms are reluctant to release figures on the scale of losses due to email fraud, but in 2009 Forbes magazine estimated that the cost of identity theft to a consumer dropped, which indicates that financial services firms are absorbing a larger share of the cost than in the past.
In this column, I’ve provided best practices that enterprises around DKIM verification and why it’s important for organizations to consider these best practices in order to trust email and prevent phishing. Email fraud is so easy to perpetrate, because when SMTP, the protocol that is used to send email on the Internet, was created the users of the Internet were considered to be trusted implicitly. In those early days of the Internet (originally the Arpanet) only research institutions and a few select businesses like IBM and DEC were on the network. Commercialization of the Internet is what created the problem.
DKIM Explained
DKIM (DomainKeys Identified Mail) was created as an Internet standard method of instilling trust back in email. DKIM is cryptographic sender authentication scheme that allows a receiver to know that a message comes from where it claims to come from. In short, a receiver can trust that the email was not forged. It works by digitally signing the email message header and body with a signature stored in a message header. The signature is a cryptographic hash of the message and a body. The signature relies on public key cryptography. The message headers and body are signed with the sender’s private key. The receiver verifies the signature with a public key.
Public key cryptography has been around for many years, like PGP and S/MIME, but it has never received wide adoption, because there was no global public key infrastructure (PKI) – i.e., there was no way of distributing the public keys necessary to make it work universally. The problem of PKI was solved for DKIM by relying on a universal Internet infrastructure that already exists, DNS. The Domain Name System is the glue that makes the Internet work. Its primary function is to allow matching domain names to IP addresses (pogonip.net -> 192.168.2.10) so that all the applications that reference things by name will work. It is like a giant distributed phone book. DKIM public keys are distributed in DNS using a specially formatted entry within a special subdomain (_domainkey.pogonip.net).
When a receiver receives a message, the receiver can check for the existence of a DKIM signature, based on data in the signature, look in DNS for the public key, and verify that the message headers and body have not been modified. Success or failure of the DKIM verification is put in a special standard email message header called Authentication-results. Success means that the headers and body of the message have not been modified, and therefore the sender of the message in the From: header can be trusted as the origin of the message and that the body was unmodified in transit.
Best Practices for DKIM Verifiers (Receivers)
The following best practices are relevant to receivers of email:
• Respect the testing flag: There is a built in method in DKIM for a sender to let a receiver know that they are testing the signing process and that the receiver should not rely on the success or failure of the signature in making a policy decision.
• Expose the Authentication-results: to the end user: As a best practice, verifiers should in some way highlight to end users that a message has succeeded in DKIM verification. Industry leading ISPs highlight the messages that succeeded in DKIM verification in the Webmail user interface that their subscribers use.
• Do not assume that success means it isn’t spam: DKIM is a way of trusting that an email came from the sender that is in the From:. It does not tell you anything about whether that sender is a spammer or not. At best, DKIM becomes one tool in the effort to fight spam, primarily by allowing white listing to avoid false positives work more effectively. If the DKIM verification succeeds and the message is from a known good sender, then content-based anti-spam filtering could be bypassed to avoid the chance of a false positive. Do not skip and virus checking, however, as the sender may be inadvertently sending malware.
• Do not respect ADSP discardable email unless you want risk dropping email and blaming the sender: ADSP, Author Domain Signing Practices, is a new Internet standard that allows a DKIM sending signer to let receivers know what policy to implement on their email. The sender may specify one of three conditions in their ADSP record in DNS:
o unknown (I don’t know if I sign all my email)
o all (I sign all my email)
o discardable (I sign all my email and if DKIM fails you can safely discard the message)
Monitoring conducted by dkim.org has determined that many signers in fact have problems with their DKIM implementations or email with DKIM signatures are being mangled by email mailing lists, which cause DKIM verification to fail. If an ADSP record is listed as discardable, it is highly likely that some fraction of good email messages will be lost. If you are OK with blaming the sender, then go ahead and do it, but if you do not want to risk losing email, then do not take the discard action even though the sender said it was OK.
