DomainKeys is a mechanism for validating both the email sender and the integrity of a message. It works by cryptographically signing the headers of the message upon sending with its domain public key. The key is published with a DNS record, so the receiving MTA that performs the end validation can retrieve it for later checking. Here's the Gmail DomainKey record:
<Verbatim listing 19>
# dig -t txt beta. domainkey.gmail.com
; <<>\> DiG 9.3.0 <<>\> -t txt beta. domainkey.gmail.com ;; global options: printcmd ;; Got answer:
;; ->\>HEADER<<- opcode: QUERY, status: NOERROR, id: 23202
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;beta. domainkey.gmail.com. IN TXT ;; ANSWER SECTION:
beta. domainkey.gmail.com. 300 IN TXT "t=y\; k=rsa\;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6 9TURXN3oNfz+G/m3g5r t4P6nsKmVgU1D6cw2X6BnxKJNlQKm10f8tMx6P6bN7juTR1BeD8ubaGqtzm2r
The signature is added in a DomainKey-Signature header and is computed against the mail body and headers. The signature is not computed against envelope headers like Return-Path and message recipients (which are likely to be modified). Every header added by other MTAs before the DomainKey-Signature header is ignored. Validation results are placed in a custom header. Here's a DomainKeys example:
Authentication-Results: mail.isecom.org [email protected] gmail.com; domainkeys=pass (testing)
Received: from wr-out-050 6.google.com (wr-out-050 6.google.com [18.104.22.168]) by mail.isecom.org (8.13.8/8.13.8) with ESMTP id k9BGCr61014526 for <[email protected]>; Wed, 11 Oct 2006 16:12:53 GMT Received: by wr-out-0506.google.com with SMTP id i22so47129wra for <[email protected]>; Wed, 11 Oct 2006 09:12:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
b=Qx4ESEmusvAHn7RJDXJBt7bVAQrHuYhQUOcvrxPYW1vM3BZSpKgkBpPWMky cUGZE0TFZcFyjd/fkY5UwTZXL3QtCPtkvmvN7KGqx1bX7iP0YP0 9l3jKUQxAF NZPndioRoysm3muHXb6WPIX3UUeIhYMMETmF45X5T9HDYn3aMDE= Received: by 10.35.49.15 with SMTP id b15mr1110643pyk;
Wed, 11 Oct 2006 09:12:40 -0700 (PDT) Received: by 10.35.10.8 with HTTP; Wed, 11 Oct 2006 09:12:39 -0700 (PDT) Message-ID: <7543482b0 610110 912l4c85e2d5x4 9a6a44 44 01c8 [email protected]> Date: Wed, 11 Oct 2006 18:12:39 +020C From: "Andrea Barisani" <[email protected]> To: [email protected] </Verbatim listing>
The signature verification fails if headers are rearranged or the body of the message is altered, a common scenario for all mailing list software (which typically adds a footer at the end of every message) and anti-SPAM/antivirus filters that add custom headers. Message body conversion and line wrapping can also constitute a problem.
The proposed solution is that mailing list software should re-sign the message when sending it, while anti-SPAM and antivirus filters should parse the message after
DomainKeys validation is performed. Additionally, the sender can specify in the DNS record which headers are going to be computed to limit these kind of problems.
As with SPF, these issues make DomainKeys a mechanism that should be trusted for true positives and whitelisting only. Additionally, since cryptographic checksums are computed, the CPU workload is increased when processing each message.
Other than DNS record publishing, DomainKeys can be implemented as a milter or with specific applications for your MTA.
DomainKeys is most notably being used by Yahoo! (which originally developed the protocol) and Google's Gmail.
Was this article helpful?