Skip to content

How does sender verification work? (How we identify Spoof mail) | The five hero’s SPF, DKIM DMARC, Exchange and Exchange Online protection | Part 9#9

The process of “sender verification”, enables us to distinguish between a legitimate sender vs. an attacker who spoofs his identity and prevent a possible Spoof mail attack.

In the current article, we will review in details three sender verification standard – SPF, DKIM, DMARC and also two sender verification methods that can implement in Exchange and Exchange Online-based environment.

The five hero’s SPF, DKIM DMARC, Exchange and Exchange Online protection

SPF, DKIM, and DMARC are public mail standard that created for the purpose of verifying sender identity.

Additional options that are available for us:

  1. Using Exchange server rule that will identify an event in which hostile element uses the organization Identity to attack organization users hosted by the Exchange.
  2. Using the Exchange Online protection option of Phish filter.

How does the SPF standard protect us from Spoof E-mail scenario?

The SPF standard based on a concept in which we draw a conclusion about the sender, by verifying information about “his mail server.”

If we want to be accurate, when using SPF, we relate to the “right part” of the E-mail address meaning the domain name.

The mail server that represents the sender should be considered as an “authorized mail server” for a particular domain name (the domain name that appears in the E-mail address of the originator).

The sender verification process implemented by the destination mail server (the mail server that represents the target recipient) is performed by verifying the “integrity” of the sender mail server.

The mail server that represents the “sender” should be considered as an “authorized mail server” for the particular domain name.

The information about the authorized mail server that can send E-mail on behalf of the domain published in the SPF record (a TXT record), which include a list of IP address or hostnames of the mail server that are authorized to send E-mail on behalf of the domain.

SPF - The concept of authorized (legitimate) mail server the represent the sender

The sender identity “store”

When using SPF, the sender identity that checked is the E-mail address that appears in the mail envelope in the MAIL FROM field.

SPF - fetching the information about the sender identity from the mail header – MAIL FROM field

SPF sender verification processes flow

The SPF sender verification protocol, uses the following mechanism for verifying the identity of the sender:

When the E-mail message reaches to the destination mail server, the mail server “fetch” from the mail envelope (MAIL FROM field) the information on the sender E-mail address.

The destination mail server relates to the domain name of the E-mail address (the right part of the E-mail address).

In our specific example, the domain name of the sender is o365info.com

The mail server addresses the DNS server who hosts the domain name o365info.com and looks for information on the SPF record that is hosted “under” the o365info.com domain name.

The SPF record implemented as a TXT record that includes relevant information about the mail server that is authorized to send an E-mail on behalf of the domain o365info.com.

In our specific example, the mail server verifies if the IP address of the “source mail server” (the mail server that represents the sender) appear in the SPF record.

  • Case 1 – in case that the IP address of the source mail server, appear as listed in the SPF record, the SPF verification test result is – “Pass” meaning; the sender is a legitimate sender because his mail server considered as a legitimate mail server.
  • Case 2 – in event that the IP address of the source mail server, doesn’t appear as listed in the SPF record, the SPF verification test result is – “Fail” meaning; the sender is not a legitimate sender because his mail server is not a valid mail server.
The sender verification process that is implemented by the SPF standard -01

SPF | The scenario in which E-mail message is classified as Spoof E-mail

In the following diagram, we can see the logic of the SPF verification process regarding the scenario of Spoof mail:

In case that the mail server IP address that sends the E-mail message on behalf of the sender doesn’t appear in the SPF record for the specific domain, the conclusion that the E-mail message is a Spoof mail (spoof sender).

SPF standard ? - What is the scenario in which E-mail is classified as Spoof E-mail

The disadvantage of SPF standard

The SPF method has a significant disadvantage that relates to the mail field that is verified in the SPF verification process.

  • The SPF verification process “fetch” the E-mail address that appears in the mail envelope in the MAIL FROM
  • The SPF verification process doesn’t relate or check the E-mail address that appears in the mail header in the FROM

This method can be easily exploited by hostile elements, that can bypass the SPF verification mechanism by providing two different identities.

  1. The identity that in the MAIL FROM field will be a legitimate identity.
  2. The identity that in the FROM field will be a spoofed identity.

The SPF standard process is configured to verify the sender information stored in the MAIL FROM field only. In other words, the SPF sender verification process, will not relate to sender information stored in the FROM field. This is a built-in weakness that can be exploited by hostile elements. If you want to read more information about this vulnerability, you can read the articles:

How does the DKIM standard protect us from the Spoof mail scenario?

The DKIM method for verifying the mail sender identity legitimacy is implemented by a method, in which an “authorized entity” digitally signs the E-mail message that is sent from the sender.

The Digital signature based on existing PKI (public-key key infrastructure).

Using the option of – Digital signature enables the “other side” (the mail server that represents the destination recipient in our scenario) to be sure that a trusted authority sent the information (the E-mail message).

Because the E-mail was sent by a trusted authority (the mail server, they represent the sender), the destination mail server can be sure that the sender is a legitimate sender (the sender is who he claims to be).

DKIM standard - Digitally signing the E-mail message

The “authority” the digitally sign the sender E-mail message, is usually the mail server that delivers the E-mail on behalf of the sender.

In DKIM infrastructure, the entity that signs the E-mail message described as DKIM selector.

DKIM standard - The concept of DKIM selector

The information that is signed by the DKIM selector includes a couple of mail fields. In the context of our topic, the main thing that we ought to know is – that the mail field named FROM that contain the sender identity (the sender E-mail address) is digitally signed.

DKIM - fetching the information about the sender identity from the mail header - FROM field

If you want to read more detailed information on the DKIM standard and the implementation of DKIM in Office 365 based environment, you can read the article series DKIM – Domain Keys Identified Mail | Basic introduction | Part 1#10.

DKIM sender verification processes flow.

The DKIM sender verification protocol, use the following mechanism for verifying the identity of the sender:

The E-mail that sent from the source mail server includes.

  • The digital signature of the data that includes the E-mail address of the sender.
  • Information about the name (FQDN) of the mail server that signed the E-mail meaning the DKIM selector.

When the E-mail message reaches to the destination mail server, the mail server “fetch” from the mail header (FROM field) the information on the sender E-mail address.

To be able to get information about the “authority” that digitally signed the E-mail message, the destination mail server relates to the domain name of the E-mail address (the right part of the E-mail address).

In our specific example, the domain name of the sender is o365info.com

The mail server “fetch” from the mail header, the hostname of the DKIM selector that signed the E-mail message.

The destination mail server addresses a DNS server which hosts the particular domain name and looks for information on the DKIM record that is hosted “under” the o365info.com domain name.
The DKIM record implemented as a TXT record, which includes relevant information about the hostname of the DKIM selector.

In a DKIM scenario, the mail server will look for information about the hostname of the DKIM selector.

In case that the DKIM record includes the hostname of the DKIM selector that appears in the
E-mail message, the mail server “know” that he is authorized authority, and that he can be trusted.

Now, to the destination mail server, move on to the next phase, in which he needs to verify the Digital signature that appears in the E-mail message.

The Digital signature verification process implemented by a quite complicated process. The destination mail server calculates by himself, the HASH value of the mail field (including the mail field FROM that contain the sender E-mail address), and compare the HASH value that he got to the HASH value that appears in the E-mail.

  • Case 1 – in case that the HASH value is identical, the meaning is that the data was not altered in any way, and then we can be sure the sender is a legitimate sender.
  • Case 2 – in case that the HASH value is not identical, the meaning is that the data was altered, and for this reason, we cannot be sure the sender is a legitimate sender.
The sender verification process that is implemented by the DKIM standard -01

DKIM | The scenario in which E-mail message classified as Spoof E-mail.

From the DKIM process point of view, the verification test includes two “tests” that must complete successfully.

Test 1 – In case that the DKIM selector that appears in the E-mail message doesn’t appear in the DKIM record that hosted under the sender domain name, the verification process considers as failed meaning, the E-mail considers as Spoof mail.

Test 2 – In case that the HASH value of the digital signature is not valid (not identical), the verification process considers as failed meaning the E-mail considers as Spoof mail.

DKIM standard -What is the scenario in which E-mail is classified as Spoof E-mail

How does Exchange protect us from Spoof E-mail scenario?

Let’s start with a declaration – by default; Exchange is not configured to “protect us” from a scenario of Spoof mail (spoofed sender).

We can even say that the Exchange server is “indifferent” for Spoof E-mail attacks or to the identity of the sender.

Although that by default the Exchange server is “indifferent” towards the originator identity legitimacy, we can use an Exchange powerful option that will help us to identify legitimate senders. In a particular scenario in which we want to verify the identity of the sender that uses the domain name that hosted by the Exchange organization ( the specific domain name that the Exchange considered authoritative for).

The “Exchange verification test” is implemented by using a combination of “two parts”:

  • Information that is saved in the E-mail message header.
  • Exchange rule.

Using an Exchange rule, we can define a logical condition, which will enable us to identify a scenario of a spoofed sender (spoof mail).

When we use the term “Spoof mail” the meaning particular scenario – a scenario in which hostile element is using “our user identity,” and try to attack one of our organization users.

The Exchange rule condition that we define based on the following logic-

Each entity that uses our organizational identity (the E-mail address that includes our domain name) is supposed to be a legitimate entity, which is hosted by our Exchange server.

Each legitimate entity that addresses the Exchange server should provide user credentials, so the Exchange server will be able to know that this is a legitimate and trusted entity.

For example, when we open our Outlook and access the data stored in our mailbox, our user credentials “transferred” in the background on the Exchange server.

The information about the fact that “entities” provide or didn’t provide user credentials, is registered as part of the mail header.

  • In case that the entity provides user credentials, the entity authentication status is – internal.
  • In case that the entity didn’t provide user credentials, the entity authentication status is – Anonymous.

The “trick” that we can use, is based upon a procedure in which we “fetch” the information on the authentication status of senders, that their E-mail message includes our domain name.

For example – in our specific example, the hostile element presents himself uses the E-mail address – John@o365info.com (a false identity).

John is a “real” Exchange recipient, that has an Exchange mailbox, etc.

The Exchange mail server that considers as authoritative for the domain name -o365info.com, is expecting that the sender will provide user credentials. This is the “right” way which a legitimate recipient use for accessing their private data that stored in the Exchange mailbox.

In our scenario, the element is a hostile element that doesn’t have John’s credentials (username + password).

For this reason, his authentication status is – Anonymous but, at the same time, uses the E-mail address of “John.”

This is our sign of that fact that this is a spoofed sender (Spoof mail).

The sender verification process that is implemented in Exchange based environment -01

The be able to “tell” Exchange server that we want to identify events of Spoof mail in which the sender authentication status is – anonymous, and the sender E-mail address includes our domain name; we can create an Exchange rule that will monitor such events and “do something” when he identifies such as event.

It’s important to emphasize that this option is available only for an organization that uses Exchange mail infrastructure, and this is not a formal or public standard. Instead, a “gimmick” that we can use in our favor as a Spoof mail deduction mechanism or, as an additional layer for implementation of existing mail sender verification standard such as SPF.

Exchange based environment - Sender verification process is not a standard of a built-in feature

Exchange rule | The scenario in which E-mail message is classified as Spoof E-mail

The event of “Spoof mail” will be described by a combination of two conditions, which should happen at the same time.

The sender needs to use an E-mail address that includes the organization domain name and considers as an anonymous sender (sender that didn’t provide user credentials).

When does E-mail message considered as Spoof E-mail in Exchange based environment -02

How does Exchange Online protect us from Spoof E-mail scenario?

The feature of the Phish Filter (and Phish Filter Policy), is a relatively new feature that is available for Exchange Online customer meaning Office 365 customers.

The Phish Filter option is an EOP (Exchange Online Protection) feature. In Office 365 based environment, EOP serves as a “mail security gateway”.

The purpose of the Phish Filter is to enable Office 365 customers, to detect a typical scenario of Spoof mail, in which the attacker provides two different identities – the sender identity that appears on the MAIL FROM field (the mail envelope) + the sender identity that is displayed in the FROM field (mail header).

If you want to read more information about this method that is used by hostile elements, for bypassing existing sender verification mechanism such as SPF you can read the article How can hostile element execute Spoof E-mail attack and bypass existing SPF implementation? | introduction | 1#2.

The Phish Filter detects a Spoof mail event based on a very simple verification test:

When a sender addresses the Exchange Online mail server (if we want to be more accurate, the Exchange Online Protection), and use two sets of sender identities, the Exchange online Phish Filter Policy, will verify if the sender information in the MAIL FROM field is identical to the sender identity in the FROM mail filed.

In the case that the identities are different, this is a sign that something is “wrong” with the particular E-mail message.

The sender verification process that is implemented in Exchange Online based environment -01

Exchange Online Phish Filter Policy | The scenario in which E-mail message classified as Spoof E-mail

The event of “Spoof mail” will be described as – a scene in which the E-mail address that arrears in the MAIL FROM field is “not aligned” meaning, different from the E-mail address that appears in the FROM field.

In this case, the E-mail will be considered as High-risk E-mail message, and a warning notification will be added to the original E-mail message.

When does E-mail message considered as Spoof E-mail in Exchange Online based environment -02

How does DMARC protect us from Spoof E-mail scenario?

The DMARC standard is a special stand because he doesn’t include a “Standalone mechanism” or protocol for implementing sender verification, but instead, relies upon another sender authentication protocol – SPF and DKIM.

The “job” of the DMARC standard regarding the sender verification process is

  1. To check if – a specific E-mail message was verified by one of the sender verification standards – SPF or DKIM.
  2. To check if the result from the verification test is passed or failed.
  3. To implement an additional layer of sender verification described as alignment.

In case that we use one of these sender authentication protocols, the DKIM “expands” the verification process that is implemented by each of these protocols.

In other words, the DMARC is performing more “stricter sender verification tests” vs. the sender verification standard – SPF or DKIM.

The technical term that is used by the DMARC for describing the “additional layer” of sender verification described as – alignment.

For example, in case that we use the SPF or DKIM, from the DMARC point of view, it’s not enough that the SPF or DKIM verification test is successful, but also, the DMARC “dictate” additional condition, which needs to implement successfully.

DMARC and the Aligned concept

The DMARC standard and the SPF alignment

In a scenario, in which our mail infrastructure is using the SPF standard for implementing sender verification, each of the incoming mail will be “stamped” by the SPF verification test as fail or pass.

Note: In reality, the SPF standard includes additional status code, but in the current time, we would like to simplify the description. For this reason, we will relate only the to fail or pass status code.

When we use the DMARC standard, the first test that will be performed by the DMARC is – to verify if the SPF status is fail or pass.

In case that the SPF status is pass, the DMARC will continue to the next test, in which the DMARC verifies the required “SPF alignment.”

The SPF alignment test is implemented by checking if the E-mail address of the sender that appears on the MAIL FROM field (the information that displayed in the mail envelope) is identical to the E-mail address that shown in the FROM field (the information that appears in the mail header).

The sender verification process that is implemented by the DMARC standard - DKIM alignment -02

Case 1 – DMARC SPF alignment test pass

In the following diagram, we can see an example in which the E-mail message includes 2 sender identities. In our example, the sender identity that appears in the MAIL FROM is identical to the originator identity that is displayed in the FROM field.

In this case, the SPF alignment test was completed successfully, and the DMARC stamps
the E-mail message with the status code – dmarc=pass

DMARC - Performing SPF alignment process - comparing the sender identity in MAIL FROM field - FROM field -01

Case 2 – DMARC SPF alignment test fail

In the following diagram, we can see an example, in which the E-mail message includes 2 sender identities. In our example, the sender identity that appears in the MAIL FROM is different from to the originator identity that is displayed in the FROM field.

In this case, the SPF alignment test was not successfully completed, and the DMARC stamps
the E-mail message with the status code – dmarc=fail

The sender verification process that is implemented by the DMARC standard - SPF alignment -02

The DMARC standard and the DKIM alignment

In a scenario in which our mail infrastructure is using the DKIM standard for implementing sender verification, each of the incoming mail will be “stamped” by the DKIM verification test as fail or pass.

When we use the DMARC standard, the first test that will be performed by the DMARC is – to verify if the DKIM status is – fail or pass.

In case that the DKIM status is pass, the DMARC will continue to the next test, in which the DMARC verifies the required “DKIM alignment”.

The DKIM alignment test is implemented by verifying if the DKIM selector domain name, is identical to the domain name of the sender who appears in the FROM field (the information that is saved in the mail header).

The sender verification process that is implemented by the DMARC standard - DKIM alignment

Case 1 – DMARC DKIM alignment test pass

In the following diagram, we can see an example of the information about the DKIM selector name that signed the E-mail message. The information about the DKIM selector hostname saved as part of the E-mail.

In our scenario, the DKIM selector name includes the domain name – o365info.com

In the FROM field, we can see that the sender E-mail address uses also the domain name – o365info.com

In this case, the DKIM alignment test was completed successfully, and the DMARC stamps
the E-mail message with the status code – dmarc=pass

DMARC - Performing DKIM alignment -Comparing DKIM selector domain name to sender E-mail address domain name -01

Case 2 – DMARC DKIM alignment test fail

In the following diagram, we can see an example of the information about the DKIM selector name that signed the E-mail message. The information about the DKIM selector hostname saved as part of the E-mail.

In our scenario, the DKIM selector name includes the domain name – outlook.com

In the FROM field, we can see that the sender E-mail address uses also the domain name – o365info.com

In this case, the DKIM alignment test was not completed successfully, because the DKIM selector domain name is not identical to the sender domain name.

The DMARC stamps the E-mail message with the status code – dmarc=fail

DMARC - Performing DKIM alignment -Comparing DKIM selector domain name to sender E-mail address domain name -02
o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 4 Comments

  1. Hello to every one, the contents present at this website are genuinely awesome for people experience, well, keep up the good work fellows.|

Leave a Reply

Your email address will not be published. Required fields are marked *