DKIM Signatures 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
Published Standard: RFC 4871
Draft Standard: RFC 6376 (obsoletes RFC 4871 and RFC 5672)
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 signature into simpler terms.
- v = The version of this specification that applies to the signature record.
- a = The algorithm used to generate the 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 Mine Up?
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
"mailtest@unlocktheinbox.com" and it will return the results letting you know the status of SPF, Domain Keys, DKIM, Sender ID, and Spam Assassin checks.