Understanding DKIM Authentication

Understanding DKIM Authentication

Understanding DKIM Authentication

Email Authentication Series

Part 1: Why Email Authentication Matters to Your Email Program
Part 2: Understanding SPF Authentication
> Part 3: Understanding DKIM Authentication
Part 4: Understanding DMARC Authentication
Part 5: Understanding BIMI

How DKIM helps to protect content

If you’ve been following our email authentication series—it’s time to get your wetsuit on—we’re about to dive deep into DKIM (DomainKeys Identified Mail) and how it works to protect your content.

If you haven’t, you might want to read Why Authentication Matters to Your Email Program and Understanding SPF before jumping into DKIM.

In part one, we covered the basics of email authentication and how malicious senders use email’s inherent flexibility for abuse. And how email authentication was born to help fight spoofing and create proper sending identities for mailbox providers.

In our article on SPF (Sender Policy Framework), we started to introduce the idea of DKIM as a partner to SPF. We discussed how SPF covers the sending domain and what IPs are permitted to mail. So why do we need DKIM? And how do it work together with SPF to prevent email abuse?

By the end of this article you’ll have a greater understanding of DKIM, what it protects (it’s more than just your domain), how it works, its gaps, plus tips for troubleshooting and implementation.

What is DKIM and what does it protect?

SPF verifies the domain and IP sending identity. However, as we covered in our first article, a lot is passed over in the DATA command, where the message resides. Malicious senders want to hide amongst legitimate senders, so they figured out how to get their deceptive content to the inbox by exploiting limitations inherent to how SPF works.

Mailbox providers and senders needed more signals and protection to validate both headers and content, ensuring that what was sent was not modified in transit. So a big next step in protecting the flow is to focus on the content itself.

DKIM or DomainKeys Identified Mail is an email author’s digital signature confirming, “Yes, I did send this exact message.” An email author is the person or entity taking responsibility for the content. In most cases, the email author is known as the sender.

DKIM is like the old wax stamps added to letters. The seal identifies who sent the message and if the seal is broken, the contents were likely tampered with.

DKIM’s origin started in 2004 and is the combination of two prior protocols: Yahoo’s Domain Keys and Cisco’s Identified Internet Mail. What we have today is a signature that is intended to take a snapshot of a message at a given point in time. As the message passes through the internet to its final destination, if the signature verifies and the message remains unchanged, DKIM passes.

DKIM signatures are created using public-key cryptography. If you want to learn more about public-key encryption, Cloudflare has a great article explaining how public-key encryption works.

The digital signature created is added to a message by the MTA (mail transfer agent—the mail server sending your message). The signature added is built using a private key stored on the sending MTA.

This key should NEVER be shared publicly or between organizations. If there is a compromise when passing the DKIM information to another party, the DKIM key could be used to send mail on your behalf and the signature would be legitimate. And the mail sent won’t be good for you or anyone receiving the message. Plus, if keys are shared amongst providers, it’s much harder to identify what happened if there is a security issue with the signature at any point.

In addition to the private key created and stored on the MTA, a public key is given to the author (sender) of the message. The key is then stored in a publicly accessible location. As with SPF, DKIM shares its public information via the DNS (Domain Name System). This methodology is a type of “public-key cryptography.”

When all is said and done, the keys are used to not only identify who generated the content, but lock in the original message so it can be flagged if anything has been changed by the time it was received. How? That’s up next!

How does DKIM protect content and content identity?

Now the fun part—HOW DKIM works to protect your content. The DKIM signature is attached to an email message (in a hidden header) and sent within the DATA command. The signature goes with the content.

When the content is received, it’s reviewed by the receiver who runs the content through a multitude of checks (reputation, URLs, malicious content, etc.) along with the verification of the DKIM signature.

The DKIM signature is not only an authentication check, but is a strong reputation signal that carries a lot of weight.

A typical DKIM record looks like this:

v1._domainkey.email.kickbox.com IN TXT “v=DKIM1; k=rsa; p=OIUEKNasdfi+asfi8uw822…

This is where the public key is stored. The bolded sections are those that need to be defined for each domain. Now let’s quickly define what these sections mean. Note: although there are a number of additional attributes that can be added to the record, we’ll focus on the required ones (technically, k= can be optional as the default value is rsa).

._domainkey. IN TXT “v=DKIM1; k=; p=

: This value is flexible, but most sending platforms use predefined ones for their customer base. Selectors allow a sender to define multiple DKIM keys for a domain, thereby creating unique DNS records for a single domain, each holding its own public key.

This allows for different use cases like using different sending platforms simultaneously and changing what signature a given sender or platform uses periodically.

Think of the selector as a channel in your TV lineup. You use one service (domain), but the content viewed from the channel (selector) is unique to that network (sending platform).

: this is the domain that signs the message with the DKIM signature.

DKIM1: The v= field contains the DKIM specification version the DNS record and policy is following. As of today, the value can only be DKIM1. This is a required field.

: There are a couple of ways you can encrypt your signatures. This field, k=, defines the encryption method used so the receiver can process the signature for authentication checks. The default is rsa. Another encryption method being published is ed25519. But as of this writing, you’re not likely to see ed25519 broadly implemented.

: The p= field contains the public key receivers use to unlock the digital signature added to the message by the sending MTA.

A typical DKIM signature in a message looks like this:

DKIM-Signature: v=1; a=rsa-sha256; s=v1; d=email.kickbox.com; h=X-Mailer:Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type: Feedback-ID:List-Id:; t=1645731614; x=1645732814; bh=9Aq44LedH/753GxbZdoxJM/WwKMz2rsmT1IH9TKRSng=; b=gi/simxEGoL78Iz8KXAn01Yg1ujh0UByvZyKDWKwkefmLoo1bdRrR7eRc/i
ONOEfVoxrpY8BYmuXXuFyrW2xJEeoNiXgMEGYPlUR4mX26alfCfiUEfHsEm
/cMdjPU8VtQPPQQ2CLVKQ3nf/au2bI/mtAd7lJdb7XgSGwNo8Td4N00vHJF
FxnWX8EwJmxBjN6CUbR8Ul3k36N30DfmJsgGTLp0B/krETu+dJ1ZtYqKRw8
QuTv2bosnB4XSVHAC8Dj+Iv/KbVjiLQ823CQxBGqS4ON0f7kmu+sZeZ2J6bjV
04dB+b/kYQPLGKkmQGhhNsIZgbQGt9utPJOsAAZHo1IS1A==

This is the digital signature that the private key stored on the MTA creates and signs into a message. As with the DKIM record, we’ll define some of the key attributes.

v: Matching up with the v= tag in the DKIM DNS record, the v= field contains the DKIM specification version to follow. As of today, the value can only be 1. This field and value are required.

a: This attribute defines the algorithm to use to compute the signature and content. As with the above, the most widely used algorithm is rsa-sha256. If ed25519 is used, then the a= value would be ed25519-sha256.

s: The selector value here is tied to the attribute entered into the DNS record above.

d: This is the domain claiming responsibility for the message. When looking up the DKIM record, you will look in the DNS for this domain ( above).

h: The entries here are the header fields that are being captured and “frozen” in time when the message was sent from the originating system. The values defined here will be used by the receiver to “recreate the message,” which confirms if the message received is unchanged. And if this is a little confusing, don’t worry. We’ll walk you through it.

bh: This is the body hash. The message is turned into a cryptographic hash using a mathematical computation and displayed here.

b: This is the domain’s (author’s) digital signature created using the private key on the MTA. It includes the body hash (bh=) as well as a cryptographic hash of the header (h=) values.

t: This is the timestamp when the message was signed.

x: This timestamp defines when the current signature expires. Not widely used.

Without DKIM, receivers are limited in their ability to identify domains and domain reputation, and are forced to fall back to IP-based methodology (including SPF). This can be more prone to problems in certain scenarios, such as automated forwarding of email messages. And they can’t as easily confirm the person behind the curtain created the message. Remember, an author or sender doesn’t always match up with the sending platform or sending identity shared in the MAIL FROM.

The majority of the time, the IP is tied to your ESP and if your MAIL FROM also points to your ESP, what ties the message to you? DKIM.

When a DKIM signature isn’t present, there’s a key reputation and identification factor missing and this can cause filtering algorithms to scratch their heads.

A simplified version of the process mailbox providers use to process DKIM:

  1. Take the domain from the d= in the DKIM signature as well as the selector s=
    The domain included in the signature claims responsibility for the content, “I sent this, and you can confirm by authenticating my signature.” This is checked by using the public key posted in the DNS. In other words, does the signature on paper match the signature on your ID card?

  2. Lookup the DKIM public key in the DNS for the d= domain

    Understanding DKIM Authentication

    Over time this domain gains reputation and a sending history. IPs can change, but domains remain a stable signal.

    Without the private key to create the initial signature, a malicious sender is unable to create a digital signature with your domain that receivers can unlock with the public key. This means they can’t pass it off as your content, nor can they use your reputation.

  3. Use the public key to decrypt the DKIM signature (b=) in the message

    Understanding DKIM Authentication

    If the key doesn’t “unlock” the signature, the sender may be trying to impersonate your domain.

  4. Use the algorithms to determine if the original message is intact or if it was tampered with while in transit

    Understanding DKIM Authentication

    When a message is signed, the MTA selects and signs a specific set of headers (the header values defined in the h= attribute above) and the message (bh=). This essentially takes a snapshot in time of the message. This is stored in the DKIM signature (b=).

    When the content is received, the receiver takes the header values defined in the header attribute (h=) as well as the body and recreates the header and body hashes using the algorithm defined.

    If the hashes created by the receiver match the hashes pulled from the decrypted DKIM signature (b=), the content is intact and unchanged. If they are different, something along the way has changed.

    This portion of verifying the DKIM signature is like sending a bunch of puzzle pieces in a locked box to a friend with a picture of the final product. First, your friend has to use their key to unlock the box. Then they have to put the puzzle back together. Once recreated, if the puzzle doesn’t match the original picture, something tampered with the pieces enroute.

  5. Accept or reject the message
    If the signature doesn’t pass or there isn’t congruence between the content at send time and received time, the receiver can choose to reject, block, or bulk the mail.

Note: the values you see in the above visuals are not real and are for demonstration purposes only.

An important note about DKIM (and all authentication protocols). The DKIM record is designed to confirm the identity of the author (sender) and verify the message is unchanged. But it’s up to the mailbox providers to determine if and how they want to honor the results. This brings us to why there are gaps in DKIM.

DKIM gaps and vulnerabilities

Forwarding can break DKIM

Sometimes DKIM breaks. And usually, when it does legitimately, it’s because of forwarding. This is not unheard of to happen with Microsoft. It doesn’t happen enough to be noticeable, but it happens enough to be known. Somewhere in the process the headers or content are adjusted as they pass through the system. These adjustments prevent the hashes from matching and therefore break DKIM.

This is one reason why it’s nice to have an authentication partner in SPF and why ARC (Authenticated Received Chain) was developed. ARC is a way for the receiver to document the authentication results when it first receives the message. Then as the message is passed on, it can include those results, resign and send the message. The subsequent receivers can then review those results and lean on the reputations of the forwarder as well as the original sender to determine what to do with a message.

Sometimes receivers can break DKIM

Although usually this isn’t intentional. And it’s typically due to something small.

Receivers like Microsoft are known for adjusting content to fit the needs of their system. In some cases, it could be swapping a tab for a space, or translating a non-ASCII character into an ASCII character or some other translated output.

When this does happen, the adjusted version is used to create the DKIM hashes. However, the resulting hash won’t be the same as the original hash because, technically, the content is not exactly the same.

In a similar vein, sometimes line breaks are inserted when line lengths are too long. Both examples are innocent enough. But, regardless, they count as changes to the content. Which means the recreated hashes will not match the originals.

Although you can’t undo a campaign that was sent, testing ahead of time (especially using tools that check email infrastructure like kbxscore.com can identify these issues. You can then troubleshoot to see if you can find what is causing the translation to fail.

Steve Atkins from Word to the Wise has a great article on how DKIM Canonicalization can help with situations like this. In short, it talks about setting the canonicalization algorithm (not introduced in this article) for the signature to ‘relaxed/relaxed’ to force the receiver to do specific transformations of the content, ensuring the end result is the same.

Trusted systems can be abused to take advantage of DKIM

There’s a particular type of spam/security attack called a “DKIM replay attack,” where a legitimate message is received and passed on, but before it is, additional header fields are added and possibly content beyond what is signed. Because DKIM is only checking the original headers and the specified section of content signed, additional values can slip in and take precedence in what is displayed to the email recipient.

SocketLabs has a fantastic article on DKIM replay attacks if you want to get into the nitty-gritty.

Malicious senders use authentication to get in the door

As with SPF, DKIM can be used legitimately, but for malicious purposes. For example, a malicious sender could buy a domain that looks like a well-known brand, set up authentication, and mail with it. If the IPs aren’t flagged and the domain doesn’t hold an immediate reputation risk, it may pass SPF and DKIM without much concern.

The malicious actor can then do one of two things. Send their authenticated mail, but display a different From address to the email recipient. OR they can send as is and hope the email recipient doesn’t notice the slight change in the domain.

The former can be combated with DMARC (soon, folks, we’ll get to DMARC soon enough). The latter can’t always be addressed, but some techniques could involve domain parking, expectation setting upon email collection about where the mail is coming from, and asking your customers to add you to their safe-sender list. If mail comes in outside of the known address, they can flag it for review.

Reputation also helps to address this issue. Bad guys can authenticate their mail, but their mail is still unwanted and will be reported as such by end users. Authenticated mail with a low or bad reputation is much less likely to get delivered to the inbox.

DKIM tips

When troubleshooting a DKIM record or thinking about how to implement it (RFC 6376), here are 11 recommendations and best practices to keep in mind:

  1. Research DKIM authentication issues at the DNS level and the MTA level
    Monitoring your DKIM success through DMARC reporting is the first step in identifying when an issue arises that needs to be researched.

    Once identified, you can address the issue. Does the DNS need to be updated or refreshed? Do old entries need to be discontinued? Do new keys need to be rotated in or was there a rotation without a DNS update? Does the DMARC policy need to be changed?

    You may also need to look at the DKIM key on the MTA. It would not be unheard of to have the DKIM record correct, but the MTA private key with a typo or accidentally deleted.

  2. Use 2048-bit encryption at minimum
    The minimum encryption level should be 1024, but best practices recommend the longer key length of 2048 for better security. Eventually computers will get fast enough to easily “break” a 1024-bit DKIM signature (they nearly are today) – make sure you’ve moved on to better encryption long before that happens!

  3. Don’t share DKIM keys between providers or services
    If you ever get asked by someone on your team to share your current private key with another provider. RUN.

    This is extremely risky and dangerous. If a malicious party were to get a hold of that key, they can effectively sign any mail with your domain and it would pass authentication.

    Each provider should have their own (separate) private key installed on their MTA.

  4. Rotate DKIM keys regularly
    By rotating your keys, you can help combat replay attacks and other abuse. Your provider should own updating the private key. They will provide you with updated public keys to make sure all new mail being sent will sign successfully. Three things to keep in mind when rotating keys.

    • DKIM rotation timeline is often defined by your provider, but that doesn’t mean you couldn’t (or shouldn’t) ask for shorter time frames.

    • Domain delegation or delegation through CNAME can be used to limit the turnaround time needed to rotate a key. Often providers have scripts they can use to update the DNS on their end. If you are pointing to their system through delegation or CNAME, they can loop in the backend updates to include your DNS record.

    • Create multiple DKIM records. Use at least one as a placeholder. The DKIM records are defined by the selector. So while you begin rolling out a new DKIM key, you can double sign with your older one.

      This gives you time to make sure what was changed is working and to test out any issues along the way. Inevitably there is always that one stream you forgot about.

  5. Use CNAMES for delegation
    For the same reasons discussed in our SPF article, CNAME is a sure-fire way to quickly adapt to changes on the provider side.

  6. Expire key signatures using x= attribute
    The RFC states the expiration date is not intended to combat replay attacks, but it may still help reduce replay attacks depending on how restricted you want to get for ‘live’ content. And it may even help for some older content that may be repurposed.

    It also helps make sure a message fails delivery if it’s not accepted in a specified amount of time, perhaps for time-sensitive messaging.

  7. Use flat ” ” and not curly “ ”
    As we mentioned in the SPF article, be cautious with copy and paste in your DNS tools. Word, for example, will change flat quotes to curly quotes automatically. If that is pasted into your DNS record, it can create lookup and authentication issues.

  8. Limit values in a single ” ” text to 255 characters or less
    1024-bit encryption records will fit nicely into the 255 characters or less that TXT records require. However, 2048-bit encryption generates more than 255 characters. You’ll need to break up the public key into more than one text string. Each should be surrounded by quotes (” “). Lookups will automatically concatenate the values so that the full record can be utilized.

  9. Consider new encryption methods
    RSA is the default and the standard for many. But there is an emergence of users using ed25519, which is seen as a stronger and faster option by some. However, it’s not accepted universally—yet. Test before sending any mail out to your entire user base.

  10. Oversign
    Sign your DKIM signature with additional header entries that are blank. This is to combat replay attacks by failing additional header entries that are included by a malicious sender. Otherwise, any additional headers outside of the DKIM signature may be overlooked, while still passing DKIM authentication checks.

  11. Match your DKIM domain with your From domain
    Best practices recommend that the return-path domain (bounce domain) match the brand’s sending identity seen by the email recipient. But depending on the platform used and its configuration, this isn’t always possible. And that’s ok. It’s one of the reasons DKIM and SPF make such a nice pairing and are recommended together versus alone.

In closing

DKIM’s ability to provide a still picture in time of a message alongside a sending identity helps to stamp out malicious abuse tied to legitimate content. The one thing DKIM and SPF have not been able to solve yet is how to ensure the authenticated sending identities match the identities seen by the email recipient.

Like Voltron, SPF, DKIM and DMARC come together to form a stronger authentication path that not only identifies senders, but prevents spoofing. Our next article will introduce you to DMARC and how these three protocols work together.

via GIPHY

Up Next: How DMARC thwarts spoofing and alerts senders to authentication issues.

Click to rate this post!
[Total: 0 Average: 0]

Check Also

do-friendly-from-names-impact-deliverability?-and-if-so,-how?

Do Friendly From Names impact deliverability? And if so, how?

Friendly From Names (also known as the “From Name”) are one of the first things a user sees when looking at their inbox. And they are an important part of the first, second, third, and even last impression a sender can make in the inbox. Getting those impressions right is a key part in making sure your campaign is successful. But can they also be

>