DKIM Tags: Everything you wanted to know

 

An Overview of DKIM and DKIM Tags

DKIM is an abbreviation for DomainKeys Identified Mail, an email authentication protocol that works by using an encrypted digital signature on outbound messages that reference back to a published TXT record for your domain. DKIM is a strong protector of email integrity and content, preventing misuse by man-in-the-middle attackers and more, but has some limits that wrapping DMARC around it compensates for.

The DKIM protocol can be implemented by configuring a specialized TXT record in the organization’s DNS, made from a combination of DKIM Tags and their corresponding values. In this article, we’ll be diving into in-depth explanations of required, optional, recommended, and discouraged DKIM signature tags with, replete with examples. 

What are DKIM Tags?

DKIM Tags are the instructions emplaced in the DKIM record specifying details about the sending domain for digital signature verification, also known officially as Domain Keys (the ‘DK’ in the DKIM). Each DKIM record will have several Tags associated with it providing precise direction on how emails from this organization should be authenticated and treated by recipients.

Properly configured DKIM Tags allow email service providers to authenticate your email messages. Major email providers like Google’s Gmail, Microsoft’s Hotmail, Live and Outlook and Yahoo’s Ymail have mandated this protocol for email senders to prevent spam, phishing and spoofing, with many private businesses starting to require DKIM-signed messages to even communicate with their employees in a bid to mitigate more email-borne attacks.

DKIM Tags are single letters, which are interpreted as commands, and each is followed by an equal sign that then provides the values. All of the letters have a DKIM Tag that designates specific values representing pieces of information about the sender. These Tags are wrapped up in each DKIM Signature which includes details about the location of the public key used to encrypt the messages.

 

How do DKIM Tags Work?

When the sending organization sends out any message, a DKIM signature is injected into the email’s header. The recipient mail server then uses this header data to cross reference the DKIM signature against the domain’s officially published DKIM record to verify the authenticity of email messages via both a private key and public key (the private key contained within the email; the public key hosted on the sending domain’s DNS). This DNS lookup for DKIM is an extremely rapid process and only takes a few seconds.

Each message’s DKIM signature possesses guidance to check the sending organization’s DKIM record, which contains further “instructions” for what the recipient mail server should check for to determine authenticity. Each Tag in the DKIM record represents details about the email that can be checked for integrity.

Whenever emails are sent from the organization’s domain, the private key in the emails should match the public key. Otherwise, the message is unlikely reach the recipient’s mailbox. Getting this to work successfully is the trick, as properly configuring the Tags and using the right ones is where DKIM configuration often falls apart.

 

DKIM Tag Types

DKIM Tags are categorized by whether they are ‘Required Tags’ or ‘Optional Tags,’ with the value of each being critically important in generating a proper DKIM record.

In the Optional Tags zone, these receive further distinctions as ‘recommended,’ ‘not required’ or ‘not recommended.’ These can be set the depending upon the requirements of each domain and any especial needs. These can be used to create far tighter or more permissive DKIM policies depending on which Tags are used and in which combinations.

Required DKIM Tags 

The Required DKIM tags are critically important for the DKIM signature header; messages without them won’t pass verification and will not make it to the recipient’s mailbox.

  • v= It is the DKIM version Tag that denotes the DKIM standard being used. Its value is always set to 1.

  • a= This DKIM Tag indicates the cryptographic algorithm used for creating the signature. The value used is rsa-sha256. Any lesser values should absolutely not be used due to the ease of cracking them.

  • s= It indicates the DKIM selector Tag used for finding the public key in a domain’s DNS. A name or number will be assigned to this field.

  • d= The DKIM domain Tag displays the domain used with the selector record to locate public keys. Its value is the same as the domain name used by the sender.

  • b= The DKIM body Tag is used for the header’s hash data. It’s usually paired with the h= tag for drafting the DKIM signature. It’s always encoded in Base64. 

  • bh= The DKIM body hash Tag has the computed hash of the email. Its value is a string of characters denoting a hash determined by an algorithm.

  • h= This Tag enlists the headers seen in the signing algorithm to generate the hash in the b=tag. Its value can neither be removed nor changed. 

Optional Yet Recommended DKIM Tags

It’s encouraged to use these recommended DKIM Tags as they can assist the recipient’s server in the verification process. 

  • g= This Tag works to create granularity with your public key and its value will the same as the local part of the i=Tag. You can also enter an asterisk (*) as a wildcard. This DKIM Tag blocks the signing addresses from using the selector records. Any email having a signing address not matching this Tag fails verification. 

  • h= The ‘h’ Tag denotes an acceptable hash algorithm and has specific values set to ‘sha1’ and ‘sha256’. Signers and verifiers both need these to validate DKIM records properly.

  • k= This Tag designates the key type. Its default value is set to ‘rsa’, which is supported nearly universally by signers and verifiers.

  • n= Administrators use this Tag to add human-readable notes for other email administrators to know whom to contact.

  • t= This is an important Tag as it works as a signature timestamp showing the time the email is sent. The format of this tag is in numbered seconds from 00:00:00 on January 1st, 1970 (UTC).

  • x= This Tag tells the signature’s expiry date. It complements the t=Tag by assigning a delivery date. 

  • t=y The t= Tag is used to specify a domain testing signature and is used by senders when DKIM is being configured for the first time. It’s suggested since some mailbox providers overlook DKIM signatures in test mode. This Tag must be removed before completing deployment of DKIM.

  • t=s is the replacement of the t=y Tag. It says that any DKIM signature using the i=Tag must have the same domain value as the primary domain. This Tag does not work with subdomains.

Not Required

These Tags are not needed for DKIM signature Tags if you’re creating a DKIM header for the first time. They can make your DKIM signature overly technical and complex. 

  • c= is a DKIM record Tag that works as the canonicalization algorithm and describes the modification levels of an email mid-transit to another mailbox provider. It’s used to avoid minor modifications to emails in transit. This can otherwise cause a failed verification. Changes include white space additions or line wraps.

Its value is set to either value1 or value2. Value1 is meant for the header while Value2 is for the message body. These can be set to ‘simple’ or ‘relaxed’ to specify the tolerance to modifications in the email. 

  • i= represents the user’s or agent’s identity. Its value is the email address having a domain and subdomain to your website, which is the same as the d=Tag.

Not Recommended

These DKIM DNS tags aren’t necessary for any DKIM header. These are used only to control any of the specifications mentioned below.

  • l= The DKIM length tag facilitates partial signing of the message body denoted by the number of bits to be signed. This tag is not recommended as it leaves messages vulnerable to tampering. 

  • z= This Tag enlists the original headers of messages and is used by mailbox providers for diagnosis of verification errors.

Previous
Previous

Enabling DKIM in Google Workspace (G-Suite)

Next
Next

Sender Policy Framework (SPF) Syntax