Domain Keys Identified Mail (DKIM) allows the senders of an email to associate a domain name with an email message.
- A digital signature is added to a field in the message header (signing).
- A signature is generated by the sending mail transfer agent (MTA) using an algorithm. The algorithm reviews the content and creates a unique string of characters (hash value).
When the signature is generated, a public key used to generate it stores at the listed domain. After recieveing the email, the reciepent’s MTA can verify the signature by checking the public key though DNS. It then uses the key to decrypt the hash value in the header and simultaneously recalculates the hash value for the mail message it received. If the two values match, then the email has not been altered. Confirms e-mail did originate from listed domain, and it has not been modified since being sent.
KIM-Signature a=rsa-sha1; q=dns;
d=example.com;
i=user@eng.example.com;
s=jun2005.eng; c=relaxed/simple;
t=1117574938; x=1118006938;
h=from:to:subject:date;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSb
av+yuU4zGeeruD00lszZVoG4ZHRNiYzR
- b = the actual digital signature of the contents (headers and body) of the mail message
- bh = the body hash
- d = the signing domain
- s = the selector
- v = the version
- a = the signing algorithm
- c = the canonicalization algorithm(s) for header and body
- q = the default query method
- l = the length of the canonicalized part of the body that has been signed
- t = the signature timestamp
- x = the expire time
- h = the list of signed header fields, repeated for fields that occur multiple times
We can see from this email that:
- The digital signature is dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR.
This signature is matched with the one stored at the sender’s domain. - The body hash is not listed.
- The signing domain is com.
This is the domain that sent (and signed) the message. - The selector is eng.
- The version is not listed.
- The signing algorithm is rsa-sha1.
This is the algorith used to generate the signature. - The canonicalization algorithm(s) for header and body are relaxed/simple.
- The default query method is DNS.
This is the method used to look up the key on the signing domain. - The length of the canonicalized part of the body that has been signed is not listed.
The signing domain can generate a key based on the entire body or only some portion of it. That portion would be listed here. - The signature timestamp is 1117574938.
This is when it was signed. - The expire time is 1118006938.
Because an already signed email can be reused to “fake” the signature, signatures are set to expire. - The list of signed header fields includes from:to:subject:date.
This is the list of fields that have been “signed” to verify that they have not been modified.
- pass= ‘The message was signed, the signature or signatures were acceptable, and the signature(s) passed verification tests.’
This is the result you want to see. Everything worked perfectly. - fail= ‘The message was signed and the signature or signatures were acceptable, but they failed the verification test(s).’
This means that the message had a signature, and the signature was formed correctly, but didn’t match the signature of the sending domain. This probably means the message was modified somewhere along the way. - none= ‘The message was not signed’
This means that the message had no DKIM signature. This is not the same as failing. - policy= ‘The message was signed but the signature or signatures were not acceptable.’
DKIM can be configured to be more or less stringent in what is an acceptable match. A “policy” error means that the message was signed and correctly formed, but didn’t meet the policy requirements of the recipient. - neutral= ‘The message was signed but the signature or signatures contained syntax errors or were not otherwise able to be processed.’
The message was signed, but it was not formed correctly. This is possibly a configuration error on the sending domain side. - temperror= ‘The message could not be verified due to some error that is likely transient in nature, such as a temporary inability to retrieve a public key. A later attempt may produce a final result.’
This error indicates that there was a short-term problem verifying the signature. Feel free to try again. Repeated problems with this may indicate a DNS or lookup failure on the sending domain. - permerror= ‘The message could not be verified due to some error that is unrecoverable, such as a required header field being absent. A later attempt is unlikely to produce a final result.’
The signature (or some part of it) was missing from the recieved message, which caused a failure. This indicates that either the header was formed incorrectly or it was modified after being sent.
Author Details
testest testÂ