allow the signing domain to claim responsibility for an email. It seperates the question of the identity of the signer of the message from the
purported author of the message. The cryptographic signature is validated by the public key store in DNS and explained here: Domain Keys
Internet Standard: RFC 6376
This standard is designed to support the extreme scalability requirements that characterize the email identification problem. There are currently over 80 million domains and a much larger number of individual
addresses. DKIM seeks to preserve the positive aspects of the current email infrastructure, such as the ability for anyone to communicate with anyone else without introduction.
Example of a DKIM Signature
The image above was take from the headers of an email that we sent out. Let’s break down the DKIM signature
into simpler terms.
- v = The version of this specification that applies to the signature record.
- a = The algorithm used to generate the DKIM signature.
- c = The type of message canonicalization used, which can be simple or relaxed.
- d = The domain sending the email.
- s = The name of the selector used in DNS.
- h = A colon-separated list of header field names. In this example we only have one.
- bh = The hash of the canonicalized body part, referred to as Body Hash.
- b = The Signature Data.
I understand. Now how do I set up my DKIM Signature?
If you did the legwork of setting up your Domain Keys
setting up DKIM Signatures will take place in your email server software. The software should allow you to enable DKIM Signatures
and set some of the basic configuration on how it will be used. If your
software doesn't have DKIM capabilities, it's time to look for a different software package that is up to date with current email standards.
You can check your configuration by
sending an email to "email@example.com"
and it will return the results letting you know the status of SPF, Domain Keys, DKIM, Sender ID, and Spam Assassin checks.