DKIM demystified

DomainKeys Identified Mail (DKIM) allows a person or organisation to claim responsibility for an email message by associating a domain name with the message.

The purpose of DKIM is to authenticate that the content of any DKIM-signed email message is not modified during the transfer between sender’s or ISP (Internet Service Provider) and receiver’s mail servers.

DKIM signatures are produced using a private key by the sender’s mail server. They’re then verified by the receiver’s mail server by fetching public key via DNS query (illustrated below).

Why use DKIM for your domain(s)?

There are two major reasons to use DKIM for your domain:

• make it harder for spammers to spoof your domain and using it for sending malicious spam or phishing campaigns
• build a reputation for your domain over time with major ISPs and ESPs (Email Service providers)

It’s important to understand what DKIM does and what it doesn’t.

Using DKIM will make sure your message hasn’t been changed during the transfer, but it doesn’t encrypt or change the contents of your message in any way.

Many ESPs use TLS (Transport Layer Security) encryption to encrypt messages as they move between sender and recipients, but it’s still possible to send unencrypted messages if an email server refuses a TLS handshake. Once a message has been delivered, the DKIM signature will remain in the email (SMTP) headers.

The approach taken by DKIM differs from previous approaches to message signing (e.g., Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751], OpenPGP [RFC4880]) in that:

• the message signature is written as a message header field so that neither human recipients nor existing MUA (Mail User Agent) software is confused by signature-related content appearing in the message body
• there is no dependency on public- and private-key pairs being issued by well-known, trusted certificate authorities
• there is no dependency on the deployment of any new internet protocols or services for public-key distribution or revocation
• signature verification failure does not force rejection of the message
• no attempt is made to include encryption as part of the mechanism
• message archiving is not a design goal

DKIM:

• is compatible with the existing email infrastructure and transparent to the fullest extent possible
• requires minimal new infrastructure
• can be implemented independently of clients in order to reduce deployment time
• can be deployed incrementally; and
• allows delegation of signing to third parties

How DKIM works

Here’s an illustration explaining the process:

DKIM uses a two-phase process, as follows:

1.Signing Phase

• takes place on sender’s mail server
• contains digital signatures of headers and body of the message
• requires the private key for the authorised domain for signing
• and adds the DKIM signature as a special email header.

2.Verifying phase

• takes place on receiver’s mail server
• fetches public key for sender’s domain from DNS record
• extracts the DKIM signature from the email headers
• validates the signature using the domain’s public DomainKeys

It’s important to note that failing DKIM signature validation doesn’t mean that the email message will be blocked.

Examining the DKIM code

Let’s have a deeper look at the process. If you’re only interested in the basic setup in My20i, you can skip this section!

Each email message is signed with your private key (stored securely on our mail servers).

We create hashes (encoded message digests) of both message headers and body, and then use your private key to sign the hashes. The signature itself contains everything a recipient server needs to validate the signature.

A DKIM signature header might look like:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=20iisawesome.co.uk; s=s1; h=Message-ID:Subject:To:From:Date:Content-Type:
 MIME-Version:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=3zHAZOM3ZC2Xnw6cIsUoqMayPLB+3ctDAb0TU/ZVneE=; i=@20iisawesome.co.uk;
 t=1572341960; x=1572428360;
 b=WkWIVcElG0eCkeAXG+eT6Tq+eAZgOvg9PL422L82/ETTsJd
 hnywMKnzKiVckU4d2OfKjEFhK4ctoPhubXv72iDSwJPatCRSutCFjgO4q0G/fO1YDCuOnnWlcZZxs
 gcVBXWIOQfVlvRFTDDyy+HMk2YdgG6SX+2O/GOGoZTdBaWZ/cs3GnNLUXu1hDmRukl0YEWbX6uvad
 G1kxBkLUQodeaqhxo9/Bt+GI1/LNqoPgaPM2R4K53uztI/GM9TZlfGjB31tBuAvsNEjuJyQgwh68p
 ZIQrU3eByl0ocdoiOIduxWn9aTTIbtNs19EwBsN2KfV3XbDW205p5Pun2FBzuVhA==;

To break this down:

DKIM-Signature:

= Header name.

v=1;

= Version of DKIM protocol used.

a=rsa-sha256;

= Hashing (message digest) algorithm used to generate the hashes.

q=dns/txt;

= Query type used to fetch the public key.

c=relaxed/relaxed;

= Canonicalisation of algorithm for headers and body.

This last element is there because some mail systems modify email messages in transit, potentially invalidating a signature.

For most Signers, mild modification of an email is immaterial to validation of the DKIM domain name’s use. The “simple” header canonicalization algorithm does not change header fields in any way.

There are two canonicalized algorithms. simple doesn’t allow any changes, and relaxed allows common changes to whitespace and header line wrapping. Canonicalization in the header and body can be managed individually, and uses a header/body format.

d=20iisawesome.co.uk;

= The email domain which signs the message. It’s used to build the domain reputation regardless of the Email Service Provider you use.

s=s1;

= The Key Selector. It’s used as a unique identifier for the public key. As the domain could have more than one DKIM key, the selector is used to fetch the necessary public key for validation to happen.

h=Message-ID:Subject:To:From:Date:Content-Type:MIME-Version:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;

=  A colon-separated list of header field names that identify the header fields presented to the signing algorithm.

bh=3zHAZOM3ZC2Xnw6cIsUoqMayPLB+3ctDAb0TU/ZVneE=;

= The hash of the canonicalized body part of the message before the message headers are signed.

i=@20iisawesome.co.uk;

= Identity of the signer. This could be empty (any sender) or a particular email address (concrete sender).

This takes part in strict DKIM validation. If Strict DKIM is used then any DKIM-Signature header fields using the “i=” tag must have the same domain value on the right-hand side of the “@” in the “i=” tag and the value of the “d=” tag.

That is, the “i=” domain must not be a subdomain of “d=”. Use of Strict DKIM is recommended unless subdomaining is required.

t=1572341960;

= The Signature Timestamp – the time that this signature was created. The format is the number of seconds since 00:00:00 on January 1, 1970 in the UTC time zone.

x=1572428360;

= The Signature Expiration. Signatures may be considered invalid if the verification time at the Verifier is past the expiration date. Again, the format is the number of seconds since 00:00:00 on January 1, 1970 in the UTC time zone.

b=WkWIVcElG0eCkeAXG+eT6Tq+eAZgOvg9PL422L82/ETTsJd
 hnywMKnzKiVckU4d2OfKjEFhK4ctoPhubXv72iDSwJPatCRSutCFjgO4q0G/fO1YDCuOnnWlcZZxs
 gcVBXWIOQfVlvRFTDDyy+HMk2YdgG6SX+2O/GOGoZTdBaWZ/cs3GnNLUXu1hDmRukl0YEWbX6uvad
 G1kxBkLUQodeaqhxo9/Bt+GI1/LNqoPgaPM2R4K53uztI/GM9TZlfGjB31tBuAvsNEjuJyQgwh68p
 ZIQrU3eByl0ocdoiOIduxWn9aTTIbtNs19EwBsN2KfV3XbDW205p5Pun2FBzuVhA==;

= The signature data of all the preceding information from the DKIM-Signature field.

The DNS record which contains the public key looks like:

s1._domainkey.20iisawesome.co.uk IN TXT "v=DKIM1;k=rsa;h=sha256;g=*;n=here-be-dragons;s=email;t=s;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAos7io0sGmoEEfpLGwwUGYj5YQpV5bsGsqi2XZx8y56W+NpHQDLS5nnyUftFBf3NaOMNzmKqycaLAviFSqtp7uztXuTj8lEr0KxwP6oDNIVojka+xzpMuXzUd4fXszGSJwsJbAd7CPDW1o4DVZlz3XRze" "1BJOpbRqF44+fv14XTHDUxrjl8jhjSKa02nXSdthWtRWHXzV8qwriFeaovb682O+2Ye6jGXRfsS3IPv0ybTmqgw/uDEBBM2eJyfzkej8Xw3zOUqwvewVfQAcuLlmOML0+Rf6bfoirOoDYvPJUJYDVYVqWgOnCN7+m2lrWvIYOmq0uoLJrUJ3IQeqfnjMWwIDAQAB"

How to set up DKIM with My20i

It’s fairly simple to implement DKIM with My20i:

• Navigate to ‘DKIM Signatures’ in the control panel, as shown below

• Fill in the value of Selector for your new DKIM Signature; and
• Select ‘Add Signature’ button

You can then start building your domain reputation right away.

Advanced features

On the other hand, My20i provides fine-grained control over the DKIM signing process if it’s required by you.

To do this, you need to activate the advanced options by clicking on ‘Advanced Options’ link, and you’ll see this:

Here you can set up:

• Granularity / Identity = Granularity of the key.

This value MUST match the Local-part of the “i=” tag of the DKIM-Signature header field (or its default value of the empty string if “i=” is not specified). Optional, default is “*”.

• Note

Notes that might be of interest to a person. Optional, the default is empty.

• Service Type

A colon-separated list of service types to which this record applies. Verifiers for a given service type must ignore this record if the appropriate type is not listed. Currently defined service types are as follows:

* – matches all service types

email – electronic mail (not necessarily limited to SMTP).

Again, this is optional, default is “*”.

• Canonicalization

Message canonicalization. This tag informs the verifier of the type of canonicalization used to prepare the message for signing. This is also optional, but the default is “relaxed”. You can find out more info on this dkim.org.

• Expiry Time

Signature Expiration. Signatures may be considered invalid if the verification time at the verifier is past the expiration date. The recommended default is 86400 seconds (1 day). 

• Flag

Flags, represented as a colon-separated list of names. Optional, the default is empty.

The defined flags are as follows:

y – This domain is testing DKIM. Verifiers must not treat messages from signers in testing mode differently from unsigned email, even should the signature fail to verify. Verifiers may wish to track testing mode results to assist the signer.

 s – Any DKIM-Signature header fields using the “i=” tag must have the same domain value on the right-hand side of the “@” in the “i=” tag and the value of the “d=” tag. That is, the “i=” domain must not be a subdomain of “d=”. Use of this flag is recommended unless subdomaining is required.

• Strict DKIM

Flag for signing policy. Use with caution: if you choose strict signing policy and there is any error when signing – the message will be deferred! Optional, default is not checked.

As you could have more than one DKIM key pair per domain – you have to choose which one will be used for signing. This could be done with ‘Set Default’ option:

So, to be able to sign your outgoing email you have to set a DKIM signature both as Default and Enabled.

Frequently asked questions

Why should I use DKIM signatures?

DKIM, or DomainKeys Identified Mail, is an important part of email security and spam protection. It provides a way to validate a domain name identity associated with a message through cryptographic authentication. Here are some reasons why you should use DKIM:

1. Authentication: DKIM allows the recipient to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain. This is done using a digital signature linked to the domain name.
2. Phishing and spoofing protection: Because DKIM verifies that an email was actually sent from the domain it claims to be sent from, it’s much harder for phishers and spoofers to pretend to be sending from a different address. This helps protect users from malicious emails.
3. Improved deliverability: Many email service providers check for DKIM. If you don’t have it, your emails may end up in the spam folder or may not be delivered at all. Using DKIM can help ensure that your emails end up in your recipients’ inboxes.
4. Reputation: If your domain is known to use DKIM, it’s less likely to be blacklisted or considered a source of spam. This can be beneficial for your brand’s reputation.
5. Non-repudiation: Because the DKIM signature is linked to the domain name, it provides a form of non-repudiation. This means the sender cannot reasonably deny having sent the email.

When will my DKIM signature become active?

DKIM signing will start right after you set your signature as Default and Enabled. There is no waiting time for signature to become active.

How could I disable DKIM signing?

Just set your signature as ‘Disabled’. Your email messages will no longer be signed.

Could I use more than one signature for signing?

No, you have to use only one signature. The one which is set as ‘Default’ is used for signing.

What is the key length for DKIM signatures?

We’re using 2048 bit RSA keys.

Could I use DKIM signatures with different DNS provider?

Yes, you could. Just use DNS controls to obtain the DNS record value, as shown in the image above.

 Could I use my own key/pair for DKIM signing?

We wouldn’t advise to do so, as the private key should be stored without the secret passphrase. But if you have valid reasons to do so – please contact our Support team for further instructions how to use your own key pair.

 How often DKIM keys should be rotated?

DKIM keys should be rotated at least twice per year. It will reduce the risk of being compromised. In My20i, to rotate your keys, go in to Email > Domain Keys (DKIM) > Options > Rotate Keys.

Need to know more? Feel free to contact our Support team or add any questions/comments below.

Top photo by Chunlea Ju on Unsplash.