DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) is an email authentication method using a digital signature added to the the headers of a message. The signature provides strong assurance that there was no alteration of selected headers or the body of a message at any point after it left the signer's domain.

The signature can be verified by doing a DNS query for a public key in the signer's domain. Thus DKIM security depends on the distribution of public keys through DNS, rather than through a Public Key Infrastructure.

Verification does not depend on IP addresses or the path a message followed from signer to verifier. Thus DKIM avoids the forwarding problem seen by IP-based authentication methods.

Limitations

DKIM does not prevent "replay" abuse. The advantage of path independence is also a vulnerability. A single signed message may be replayed to a million different recipients, and all will see valid signatures. Without additional evidence of complicity, the signer of a DKIM message cannot be held responsible for replay abuse.

DKIM signatures do not protect the message envelope, which includes the Return Address and the Recipient Addresses. Note, however, that the From: and To: headers can be protected. If you receive an email supposedly from your bank addressed to "Customer", asking for your password or other information that identifies you, that message is probably *not* from your bank. Rejection of such "phishing" emails could even be automated. Any signed message where the header addresses differ from the envelope addresses should at least be flagged as suspicious.

Another limitation of DKIM is that a message must be received in its entirety to complete the verification. IP-based authentications are generally much quicker, as they don't require any data transfer or processing of individual messages.

IP-based and signature-based methods should be treated as complements, not competitors. They each cover a different range of the risk spectrum. If recipients in your domain get a million ads for Viagra, you hold responsible the the domain that authorized the transmission of those messages (the last hop in a chain of relays). If you are the Treasury Secretary, and you get a message from the Bank of America saying "We agree to sell our bank for $330 billion.", but the DKIM signature fails to verify, you better make a call to confirm.

How it works

Senders that wish to use DKIM should generate one or more public/private key pairs, and publish the public keys as text records under their domain name in DNS. Each key pair should have a different "key selector" (a convenient name like key123). A typical DNS record might look like:

  key123._domainkey.example.com.    1800    IN     TXT     "k=rsa\; h=sha1\; 
    p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9QJxtJz2h7HFjbCtSoZtqhp2MXvNEE+
    5pIYzTPoS2iUw0XfDzggR7NTMLzSG+wtAm0mkW3gORdK8Jxtc5aogZOQSsDAH0pRvXIGSlfXH+
    bjsNkVbyAruThjCCvRPsUatkiYftoKWVMdR5NzLR2LOusrqXSjMvOmhBT7AyfWeqSQIDAQAB\;"

1) The signer uses the sender's private key to generate a signature of the message body and selected headers, then prepends a signature header to the existing message headers:

DKIM-Signature: v=1; a=rsa-sha1; d=example.com; s=key123; c=simple/simple;
    q=dns/txt; i=@example.com; t=1254853305;
    h=From:Subject:Date:To:MIME-Version:Content-Type;
    bh=gfX4RO+Zk2GcDhXrOb73MFSp+9A=;
    b=WorXlU7jfNMwDEGD2kWjCD3nrvgecLInaLgTRImzQfkPAFDr2izAS718CR2bow0k
    bMCMhmovbmRBpeD/BDrkZgAzL0lmqn/npatDvRrCqbJbkjqhdAgVpcfWgu17LL4d
    miAnUtcLCd62WWE1BYBxD+NIiKasRjiLcaf8AHc1QI8=;

2) The verifier extracts from the sig header, the domain (d=example.com) and the key selector (s=key123), and does a DNS query to retrieve the public key from "key123._domainkey.example.com".

3) At this point, the signature (b=WorX1...) can be verified agains the selected headers (h=From:Subject:...) and the body hash (bh=gfX4...), using the specified encryption and hashing algorithms (rsa and sha1). Note that we don't need to have the entire body yet. If the signature is invalid, we might save bandwidth by aborting the data transfer.

4) If the result was "pass", all that remains is to hash the body of the message, and comopare the new hash against the one in the sig header. If all is well, the verifier can add an authentication header to the message:

Authentication-Results: mta148.mail.re1.yahoo.com  from=mail.example.com;
    domainkeys=pass (ok); from=example.com; dkim=pass (ok)

Explanatory notes

1800 seconds is the lifetime of the DNS record after it has left the server on which it was published. This allows frequently used records to be read from a cache, instead of doing a fresh query every time.

The public key above is 216 base64 characters, so it fits easily in a 512 byte DNS packet. 216 * 6 = 1296 bits in key.

The Authentication-Results header above shows that there were actually two signatures in this message. DomainKeys was the predecessor to DKIM, so this is probably a legacy system in the senders domain.