DKIM – Domain Keys Identified Mail | Basic introduction | Part 1#10

DKIM (Domain Keys Identified Mail) is a mail security standard that enables the sender to declare about his “identity” and allows the mail destination infrastructure, meaning the receiving mail server, to verify the identity of the originator.
The central paradox regarding a security standard is that most of the time, we don’t really understand what they are “doing” and we don’t really care if our infrastructure uses the “security standard” until something is happening.

Relating to mailing infrastructure and the subject of reputation and E-mail attacks, the scenario of “something happened”, could be a minor event or a very major event in which the organization’s reputation severely affected when the hostile element uses the organization identity to attack other mail systems or, a scenario of phishing attack that directed toward our organization employees.

Bottom line – Invest the required effort for learning and understand this mail security standard so, in the future, you will be able to avoid from “on desired scenarios.”

The main risks that organization facing relating to mail infrastructure

In a modern based mail environment, one of the most obvious challenges that each organization needs to face is the problem in which hostile element exploits an Inherent weakness of the SMTP mail protocol that relates to the identity of the “sender.”

When a mail server is addresses of a host, that ask for the mail server that represents the organization to deliver an email message to one of the organization recipients; the sender identifies himself by using an E-mail address.

By default, the mail server will believe the sender and will not perform the verification process in which he tries to validate the identity of the originator.

In other words, when we address mail server, we can use any E-mail address that we would like to use for “presenting our self” before the mail server.

Sound strange or too simple?

The answer is that this is a simple reality. The reason is that when the SMTP protocol created the primary concern of the people that write this protocol, was to handle the process of delivering an E-mail between two hosts efficiently.

The subjects of mail security such as – a scenario in which the sender tries to fake his identity, was not included as part of the SMTP protocol specification.

The outcome is that hostile element that understands this character of the SMTP mail protocol exploits this weakens and used the option of “faking the sender identity” for implementing two major types of E-mail attack.

• SPAM E-mail
• Phishing E-mail attack

The common denominator of spam and phishing E-mail attack is that the hostile element attempts to conceal his true identity and instead, present a false identity of a legitimate user.

Two examples of the common mail attacks

To be able to understand better the two major E-mail attacks: spam mail and phishing mail attack, let’s use the following scenario:

An organization that uses the public domain name o365pilot.com

1. Spam mail attack

In our scenario, we include two organizations:

• Organization A is represented by the domain name o365pilot.com
• Organization B is represented by the domain name thankyouforsharing.org

A hostile element wants to send spam E-mail message to a recipient from the thankyouforsharing.org organization.

The hostile element wants to achieve two goals:

1. Convince recipients from the thankyouforsharing.org that they can trust him and, for this reason, will read his spam mail.
2. Prevent a scenario in which E-mail message that was sent by the spammer will be identified and report as spam mail and by doing so, prevent his ability to continue to spread spam mail.

To be able to accomplish this goal, the hostile element uses a fake identity of a legitimate organization.

In case that the mail server that he addresses identifies his E-mail message as “spam mail”, and decides to report this information to black lists provides, the information that is reported will include information about the fake identity of the hostile element.

In other words, the element that will absorb the damage is the legitimate organization which his name used by the hostile element. In our specific scenario, the domain name o365pilot.com will be reported as an organization that sends spam mail.

In the following diagram, we can see an example of a standard spam mail attack:

A hostile element wants to send spam E-mail to recipients from an organization named – thankyouforsharing.org

The hostile element using a fake identity, in which he claims to be a legitimate recipient named – o365pilot.com

In a case that the E-mail infrastructure of the other organization (thankyouforsharing.org in our example) will manage to identify the E-mail messages as “spam mail”, and decide to report the E-mail as “spam mail”, this could lead to a scenario in which the domain name o365pilot.com will be blacklisted!

In other words – the spam activity of the hostile element could damage the business flow of a legitimate organization!

2. Phishing mail attack

The main characters of phishing attacks are that a hostile element uses a fake identity of a legitimate organization user (most of the time a VIP user such as the CIO, etc.) Addressing organization users and ask, them “to do something for him” such as – send him money, their bank account and so on.

The hostile element relies on the fact that most of the users are not able to identify this “fake E-mail” because the E-mail looks like a legitimate E-mail that sent by a legitimate organization recipient.

In our specific scenario, Suzan is the company CIO. The hostile element uses a fake mail identity in which he presents himself as “Suzan the company CIO”.

In case that the E-mail message with the fake identity will reach to one of the organization users, we can assume that the “destination recipient” will treat the E-mail as an important E-mail message because the E-mail apparently sent by the company CIO.

What can we do for dealing with this Inherent weakness of the SMTP protocol?

The “magic formal” that we are looking for is to provide our mail server, the ability and the required skills that will enable them to distinguish between good and evil.

The SMTP mail protocol was not designed from the start to deal with such scenarios.

Our wish is – to increase and extends the capabilities of our mail infrastructure so the mail server that represents our organization will be able to identify a scenario of spoof identity in which a non-legitimate recipient tries to impersonate himself and use other recipient identities vs. a legitimate recipient who tries to send an E-mail message to our recipient, and this recipient is really who he claims to be.

Existing Mail authentication mechanism \ standard

The most popular mail security standards, that deal with the ability to Identify with certainty a specific recipient and be sure that he is a legitimate recipient are: SPF and DKIM.

An additional mail security standard that completes the previous standard is the DMARC standard.

• The term DKIM stands for – Domain Keys Identified Mail.
• The term SPF stands for – Sender Policy Framework.
• The term DMARC stands for – Domain-based Message Authentication, Reporting & Conformance.

SPF and DKIM standard, enable mail server to “decide” if the identity that the sender provides can be considered as his real identity or a scenario in which there is a high chance that the host is trying to fake his identity.

In a scenario in which the identity of the sender cannot be trusted, the SPF and DKIM standard doesn’t instruct the mail server what to do.

The decision of “what to do” in the scenario of fake identity (or a scene in which, for some reason, the sender cannot provide the required information that will prove his identity). The mail server will need to decide by himself, what to do with the E-mail message.

A mail security policy will determine the ability of the mail server to determine what action will execute; that will include a set of instructions such as: don’t accept the E-mail message, don’t receive the E-mail + notify the destination recipient and so on.

The main purpose of the DMARC standard is to “fill the gap” by complete the missing part in the equation.

DMARC standard provides a way to define “mail policy” in which we help to another organization to decide what to do in a “fake identity scenario” in which some element tries to use the identity of one of our legitimate users.

In addition, the DMARC standard provides a way in which the “destination organization” which experiences the spoof E-mail event can report to the organization which the hostile element tries to use his identity.

In reality, the DMARC standard includes additional sophisticated mail protection mechanism built in the current article series will not get into a detailed description of this mail security standard.

How does the SPF and DKIM can help us to verify the identity of the sender?

The common denominator between SPF and DKIM mail identification standards is based on the “domain part” of the E-mail address.

Both of this standard, based on a concept in which the destination mail server, “fetch” the domain name from the E-mail address of the sender address and use a particular method for verifying the identity of the sender.

The solution that is provided by this mail identification standard is based on a concept
of domain authority.

When a particular host address mail server, asking him to deliver an email message to a specific recipient organization, the host must present his “identity” meaning, his E-mail address, to the mail server that he addresses.

Each E-mail address includes two parts:

• The “Left part” that represent the name of the recipient (number 1).
• The “Right part” that represent the domain name of the recipient (number 2).

In a scenario in which the mail server configures to use SPF or DKIM (or both by then), the mail server will implement a procedure in which he tries to verify the identity of the sender.

The verification process goal is to find out if the sender has really belonged to this domain and that
the E-mail message sent from the legitimate mail infrastructure that represents the particular domain name.

The main difference between SPF and DKIM

The SPF and the DKIM use a different procedure for verifying the identity of a sender.

The SPF standard and the sender identity verification concept

The SPF standard is based on a very simple concept in which organization publishes information about the “authorized mail server” that can send an E-mail message on his behalf.

The “authorization process”, is implemented by publishing information about the IP address of this “allowed” mail server.

When a mail server is the address of a sender, in reality, the element that directs the mail server is not the sender himself but instead, a mail server that represents the sender.

The destination mail server will “see” what is the IP address of the “source mail server” (the mail server that represents the sender).
The destination mail server will verify if this IP address appears on the list of “authorized mail server” that consider as a mail server that can send E-mail on behalf of the particular domain (o365pilot.com in our scenario).

The DKIM standard and the sender identity verification concept

The process that is implemented when using the DKIM standard to verify the identity of the sender is more complicated.

Technically, the current article series was written for describing in details the way that the DKIM “work” but, for the sake of our brief comparison between SPF standard vs. DKIM standard, we would provide a short description of the DKIM standard.

Given that a mail server support the DKIM standard, when he gets an E-mail, the mail server “open” the E-mail, and look for a signature that was created by the “source mail server” that should represent the domain name that appears as part of the sender E-mail address.

In our particular scenario, the destination mail server will look at the E-mail signature and try to verify if the signature created by an authority who is authorized or allowed to
represent the domain name – o365pilot.com

The question of using vs. not using mail authentication mechanism

When the most important question that each organization should ask himself is the very basic question of- what’s in it for me?

Q1: What is the risk of not using mail authentication mechanism?

Q2: What is the risk of using mail authentication mechanism?

The short answer is

A1: In a modern mail environment the results of “not using any protection” for the public mail infrastructure could be severe and even destructive.

In other words, every organization should be familiar with the common mail security standard such as SPF, DKIM, and DMARC and should consider using one of this standard or implement the use of each of the above standards.

A2: Although it sounds a bit strange, there are some risks that are involved in this scenario. When using the mail authentication mechanism because the underlying assumption is that we want to identify an event of the non-trusted sender and in response “refuse to accept” the E-mail message.

The actual reality is a bit more complex. When we “enforce” this mail security standard, it’s likely that we will experience a scenario of False positive in which a legitimate E-mail or a legitimate sender incorrectly identified as a non-legitimate sender. For this reason, we block his E-mail message that was supposed to send to one of our organization recipients.

The “answers” to the concerns from false positive could be:

1. Using a “learning mode.”

The meaning is implementing the use of the SPF and the DKIM standard but without the part of the “action” in which our mail server reacts to a scenario in which we identify a non-trusted sender.

The best practice is the use a “phased approach”.
In phase 1, we are only inspecting the events in which our mail system recognizes a non-trusted sender and starts looking for a particular pattern, recurring event and so on.

Only after a specific period in which we felt that we know and understand most of this “events,” only then, move on to the next phase in which we enforce some mail security policy, which will instruct our mail server what to do in the event of spoof sender identity.

The security policy could include instructions such as – report the event to a designated recipient, block the E-mail message, sent the email to quarantine, inform the “destination recipient” that a problematic E-mail message sent to him and so on.

2. Prepare in accordance

The recommendation is suitable for almost any scenario.
Before we “Push that button” and activated an infrastructure that can interfere with our organization mail flow, it’s highly recommended to be will prepare.
We should document the information about our mail infrastructure, the Ingredients of our mail infrastructure such as – hosts, mail servers, network, IP address ranges, business partner and so on.

Only after we have a clear view of our mail infrastructure, only then we can start with the implementation of the mail authentication mechanism, watch carefully the implemented and in an event of a problem such as false positive, have the ability to understand the causes for the problem.

What can DKIM do for me?

Technically speaking, the DKIM mail standard is implementing two different security mechanism:

1. Identity of the sender

A security mechanism in which we are able to verify the identity of a sender that addresses our mail server.

2. Data integrity
An additional security mechanism that is implemented by the DKIM standard related to a subject which described as data integrity.

The term “data integrity” defines a security requirement in which we want to ensure that the information in the message is original information.
In other words, we want to know the original information wasn’t altered or updated in any way along the way.

The ability to use data integrity is implemented by using Digital Signature.

We will review the subject of “Digital Signature” in the article – DKIM as standard that based upon the Public key infrastructure | Part 2#10

The two flavors of DKIM in Office 365 based environment

The subject of DKIM implemented can be confusing because when we describe a mail flow, there are two parties that involved in the process:

• The sender mail infrastructure
• The receiving mail infrastructure

In Office 365 base environment that uses the Exchange Online mail infrastructure, there are two flavors of DKIM:

• Inbound DKIM
• Outbound DKIM or Outbound DKIM signing

Inbound DKIM

The meaning of the term “inbound DKIM” in an Office 365 environment is that each mail that is sent to one of the Office 365 recipients is checked automatically by EOP (Exchange Online protection) server looking for DKIM data.

In other words, the DKIM standard for “incoming E-mail message” is implemented automatically in Office 365 and we as a customer doesn’t need to do or add any type of configuration settings.

In a scenario in which sender addresses the Exchange Online server and asks to deliver an email message to one of the Office 365 recipients one of the following scenarios will occur:

Scenario 1 – the sender E-mail message includes DKIM data and the DKIM verification complete successfully.

In this scenario Exchange Online read the E-mail message header, find DKIM data, implement the required DKIM verification test and if the DKIM verification processes complete successfully, Exchange Online will add this information to the original E-mail message.

The information about the successful DKIM validation test appears as – dkim=pass

Scenario 2 – the sender E-mail message includes DKIM data, and the DKIM verification didn’t complete successfully.

In this scenario Exchange Online read the E-mail message header, find DKIM data, implement the required DKIM verification test and if the DKIM verification process but this time the DKIM verification process is not successfully completed.

For example, the HASH value that was Computed by Exchange Online is different from the HASH value that appears in the E-mail message.

The information about the successful DKIM validation test appears as – dkim=fail

Scenario 3 – the sender E-mail message doesn’t include DKIM data

In this scenario, Exchange Online read the E-mail message header but doesn’t find any related DKIM data.

The information about the successful DKIM validation test appears as – dkim=none

It’s crucial to mention that, in reality, any of this result will not cause Exchange Online server “to do something.”

Exchange Online takes a “Neutral position” toward this “DKIM implementation” by the sender.

Technically, it doesn’t matter if the DKIM E-mail message status is: none, pass or fail.
Exchange Online will not block or delete E-mail message that includes the DKIM status of none or fail.

The decision what to do with each of the specified scenarios depends on the Exchange Online administrators.

For example, In the following diagram, we can see an example in which hostile element tries to fake his identity and use the identity of a legitimate organization user.

In this scenario Exchange Online read the E-mail message header, looking for DKIM data. When he find the required DKIM Data the mail server implement DKIM verification test.
even if the DKIM verification didn’t successfully completed, Exchange Online and forward to the destination recipient mailbox.

Outbound DKIM signing

The option of “outbound DKIM signing” defines the sender that uses the DKIM standard for signing an E-mail message that sent from his mail infrastructure to the “other recipients”.

In Office 365 based environment the option of “outbound DKIM” is not automatically activated.

The meaning is that E-mail message that sends from Office 365 recipients to another recipient doesn’t include any DKIM data.

The decision about “activating” the DKIM procedure for outgoing E-mail message depends on us – Exchange Online administrator.

DKIM and the “DKIM Selector”

When we say that the “sender” uses DKIM for signing outbound mail (outbound DKIM signing), the element that uses for singing the E-mail message described as “DKIM Selector”.

The term “DKIM Selector”, defines the element that is authorized to represent a specific
E-mail domain name.

Most of the time, the “DKIM Selector” will be implemented by the mail server who sends
E-mail message on behalf of the organization and consider as authoritative for the organization public domain names.

When the DKIM Selector “stamp” the outgoing E-mail message using a DKIM signature, the DKIM Selector must add his identity (his Hostname) to the E-mail message.

When the E-mail message reaches the destination mail infrastructure, the receiver mail server will fetch the name of the DKIM Selector from the E-mail message and start the DKIM verification process.

The DKIM verification process will be based on a process sin which the receiver mail server will create a DNS query looking for the DKIM Selector Hostname, who should be implemented as a TXT record that contains information about the Public Key of the DKIM selected.

We will review this process in details in the article – DKIM flow in Office 365 | Part 3#10

The next article in the current article series

DKIM as standard that based upon the Public key infrastructure | Part 2#10