Using sender verification for identifying spoof mail spf, dkim, dmarc, exchange and exchange online part 8#9 | Eyal Doron | o365info.com

of 21 | Using sender verification for identifying Spoof mail | SPF, DKIM, DMARC,
Exchange and Exchange Online |Part 8#9
Written by Eyal Doron | o365info.com | Copyright © 2012-2016
Using sender verification for identifying Spoof
mail | SPF, DKIM, DMARC, Exchange and Exchange
Online |Part 8#9
Spoof mail attack is implemented by a hostile element the try to spoof sender identity.
The way for dealing with a Spoof mail attack is, by implementing a procedure, which check and
verify the sender identity (verify of the sender consider as a legitimate sender of a spoofed
sender).
Using SPF, DKIM And DMARC, Exchange And Exchange Online For Verifying
Sender Identity
In the current article, we will review the way that the sender verification process is implemented
by the following infrastructures:
1. Mail sender verification standards – SPF, DKIM and DMARC.

2. Exchange based environment – by using the sender authentication status.
3. Exchange Online (EOP) based environment – by using the feature of Phish filter
Our main focus in this article is to understand the “identity concept” of the sender, and the
specific mail fields that are used for “storing” the sender identity.
In the next article – our main focus we will review the “flow” of the sender verification process
that is implemented by each of the different methods.
The Major Public Mail Standard For Sender Verification + The Available
Option In Exchange Based Environment.
A general classification of the available sender verification methods that we can use could be:
1. Public mail standard that deals with sender verification.
In this “group,” we can relate to three major popular standards:
 SPF (Sender Policy Framework).
 DKIM (DomainKeys Identified Mail).
 DMARC (Domain-based Message Authentication, Reporting & Conformance).
2. Exchange based environment

In this group, we can relate to a solution that can help us to implement a sender verification
process, by using information about the sender, that includes his authentication status + his
domain name (the domain name that appears on the E-mail address).
The “Exchange method” can be used only for a scenario of incoming mail in which the sender E-
mail address includes our domain name.
In this case, we can verify the sender identity by checking his authentication status.
Internal or anonymous sender
The method which we use for deciding if the sender is “valid” is – by looking at the value that is
“stored” in the X-MS-Exchange-Organization-AuthAs mail field.
Using the above mail field is relevant to any Exchange based environment, including Office 365
that is based on Exchange Online.
The concept behind this method is implemented by looking at the status of the authentication
information about the recipient – the information that is stored in the X-MS-Exchange-
Organization-AuthAs mail field.
The basic assumption is that recipient whom their E-mail address includes our organization
domain name should appear as authenticated recipient, meaning, users who provide their user
credentials.
In case that the status of the recipient whom his E-mail address includes our domain name is
“anonymous.” This is a sign that there is some “problem” with the sender identity.
3. Exchange Online based environment (EOP – Exchange Online protection) | Phish filter
EOP (Exchange Online protection) includes a method, which described as Phish filter.
The mechanism of the EOP Phish filter, is based upon a concept in which the EOP server
verifies the sender information that appears in the MAIL FROM and in the FROM field.
 In case that the information is identical, the sender considers as “valid sender”.
 In case that the information is not identical the sender considers as “non-valid sender.”
Note – Booth of this method can be implemented only for “incoming mail.”
In other words, we cannot use this method for “protect” our recipient’s identity in a scenario in
which our recipient sends an E-mail message to external recipients.

How exactly we define the “sender”?
1. SPF and DKIM standard
SPF and DKIM standard, define the “sender identity” by relating to the E-mail address of the
sender.
If we want to be more accurate, the SPF standard relates to the “right part” of the E-mail address
meaning, the domain name, and the DKIM standard, relates to the “whole E-mail address.”
 The SPF standard relates to the sender E-mail address that appears in the MAIL
FROM mail field (the information that appears on the mail envelope).
 The DKIM standard relates to the sender E-mail address that appears in the FROM mail
field (the information that appears in the mail header).

2. DMARC
The DMARC standard relies on the SPF or the DKIM standards, as the mechanism for
implementing sender verification.
The added value to the DMARC standard regarding the subject of verifying sender identity is
implemented by using an additional “layer” of tests that relate to the sender verification. In other
words, the DMARC standard performs more stringent verification tests.
For example, when we use the DMARC standard, the DMARC will check if the E-mail message
passes the SPF check. Even if the SPF check status is “pass,” the DMARC Will performs an
additional test described as “alignment,” in which he checks if the E-mail message that appears
in the MAIL FROM field is equal to the E-mail address that appears in the FROM field
Additional reading
SPF
 Sender Policy Framework
 Sender Policy Framework
 How can I create an SPF record for my domain?
 How To use an SPF Record to Prevent Spoofing & Improve E-mail Reliability
 An Overview of the Sender Policy Framework
 Explaining SPF
 About SPF and DKIM
DKIM

 DomainKeys Identified Mail (DKIM)
 DomainKeys Identified Mail
 What is DKIM? Everything You Need to Know About Digital Signatures
 DKIM Explained: How to Set Up and Use DomainKeys Identified Mail Effectively
 DKIM – Domain Keys Identified Mail | Basic introduction | Part 1#5
DMARC
 DMARC – FAQ
 What is DMARC?
 DMARC Inspector
 DMARC: Monitor & secure your email delivery
 A brief DMARC primer
3. Exchange based environment | Recipient authentication status.
In Exchange based environment, we can use an additional “peace of information,” that appears
on the E-mail message (mail header) that tells us if the recipient considers as authenticated
recipient or not.
One of the “forms” of Spoof mail attack is realized, is when the attacker, use “our organizational
identity” (an E-mail address that includes our domain name) for attacking our users.
In this case, we can use the information that is stored in the X-MS-Exchange-Organization-
AuthAs mail field for identifying an event of a Spoof mail attack “(spoof sender).
Our basic assumption is that each of our users should provide his user credentials.
In a scenario of Spoof mail attack, the hostile element that uses the identity of one of our
organization users, doesn’t provide ant credentials.
For example – if the sender E-mail address includes our organization domain name + the sender
considers as a non-authenticated user (anonymous), this is a “sign” for a Spoof E-mail.

4. Exchange Online – Phish Filter
The term “Phish Filter,” describe a specific filter that is used by the EOP server for identifying a
possible event of Spoof mail. This is a Spoof E-mail identification mechanism, that exists for
Office 365 customers or for a customer who uses EOP (Exchange Online protection) as a
standalone version.
The Phish Filter mechanism that is implemented by EOP acts similar to the DMARC alignment
concept, that is implemented relating to SPF.
The EOP Phish Filter verifies that the E-mail address (sender identity) that appears in the MAIL
FROM field is identical to the sender identity that appears on the FROM field.

Where Is The Sender Identity Being Stored And How Does The Sender
Identity Verification Process Is Implemented?
1. SPF standard
The SPF sender identity verification is implemented in the following way:
The mail server that represents the destination recipient, “fetch” the domain name from the
E-mail address of the sender, who appears in the MAIL FROM field.
The destination mail server verifies the sender identity, by verifying if the source mail server is
authorized to send E-mail on behalf of the specific domain.
The verification process is implemented by using a dedicated SPF record (TXT record) that
includes the IP address of the authorized mail servers for a specific domain.
2. DKIM standard
The DKIM sender identity verification is implemented in the following way:
The mail server that represents the destination recipient, “fetch” the E-mail address of the
sender, who appears on the FROM field.
The destination mail server verifies the sender identity by verifying the digital signature that
appears in the mail header.

3. DMARC
The DMARC standard relies on the SPF or the DKIM standards as the mechanism for
implementing sender verification.
The purpose of the DMARC standard is to – verify the results that were accepted by performing
the sender verification by the SPF or DKIM.
In case that the results are “OK” (the sender verification status is “pass”), the DMARC sender
verification process “move on” to the next step which describes as “alignment.”
Regarding the SPF result – DMARC verifies if the E-mail address that appears in the MAIL
FROM field is identical to the E-mail address that appears in the FROM field.

Regarding the DKIM result – DMARC verifies if the DKIM selector domain name is identical to
the domain name of the sender.
Note – the DMARC standard includes additional features and components that extend the
management of sender verification tasks.
For example – the DMARC DNS record, include “instruction” to “another mail infrastructure”, in
case that they identify E-mail messages that include our domain name as spoof E-mail.
The “instruction” includes our recommendation regarding “what to do this E-mail message” such
as ignore, quarantine or block.
4. Exchange based environment | recipient authentication status.
The “sender” that addresses Exchange server could be
1. Any sender from any organization that asks to send E-mail message recipient hosted on the
Exchange server
2. An Exchange user whom his mailbox is hosted on an Exchange
In a scenario in which the “sender” use E-mail address, that includes the domain name that is
hosted on the Exchange server, the basic assumption is – that this is an “Exchange user” that has
an Exchange mailbox, and for this reason, this “user” should prove his identity by providing user
credentials.

The information about the authentication process is saved by Exchange in a dedicated mail field
named – X-MS-Exchange-Organization-AuthAs
 If the user provides his credentials, the authentication status of the recipient is “internal.”
 If the user didn’t provide his credentials, the authentication status of the recipient is
“anonymous.”
In a scenario in which a sender “claim” that he belongs to the Exchange organization, meaning
that he uses the E-mail address, that includes the domain name that is hosted at Exchange but
the sender doesn’t provide his credentials; this is a sign that the sender is probably a spoofed
sender.
In other words, the status of the sender who is saved in the
X-MS-Exchange-Organization-AuthAs field appears as anonymous.
5. Exchange Online – Phish Filter
EOP (Exchange Online protection) includes a built-in filter mechanism (Phish Filter) which was
created to identify an event of an E-mail message that has a high chance of being Spoof mail.
The EOP Phish Filter work in a similar way as the DMARC alignment concept that is implemented
relating to SPF.
The EOP Phish Filter verifies that the E-mail address (sender identity) that appears in
the MAIL FROM is identical to the sender identity that appears on the FROM mail field.
If there is a difference, the E-mail message will be “stamped” using a warning message that will
notify the user, that this E-mail message could be a Spoof mail.

Major Differences Between Sender Verification Mail Standard And Exchange
Based Solutions.
As mentioned, when we go to the “Spoof E-mail attack war,” there is a variety of weapons to
choose from.
Some of these “weapons,” are public mail standards that can be adapted by any mail
infrastructure, and some of them can be used only in the case that the mail infrastructure is
based on Exchange mail server or Exchange Online (Office 365 customers).
The major differences between the Exchange based solutions versus the “public mail standard”
are:
1. DNS configuration settings
When we use the Exchange based mechanism for identifying an event of Spoof E-mail, there is
no need for using additional configurations such as DNS records.
2. Incoming mail flow
The Exchange based solution’s mechanism for identifying an event of Spoof mail can be
implemented only regarding scenarios of – incoming mail.
The meaning is – events in which hostile element try to “attack” the Exchange recipient.
Using the SPF, DKIM and DMARC for protecting ourselves from a scenario in which hostile
element uses our identity.
Just as short reminder, the problem of “Spoof mail” can be realized in two main flavors:

 Case 1 – a scenario in which hostile element attacks our user by sending them
Spoof mail.
 Case 2 – a scenario in which hostile element, uses our organizational identity (E-mail address
that includes our domain name) for attacking other organizations.
When using a public mail standard such as SPF and DKIM, we have the ability to “announce”
other organizations, if a specific E-mail message in which the sender uses our domain name, is a
legitimate E-mail message or not.
For example, when using SPF, we can inform other organizations, which are the authorized mail
server that can send an E-mail message on behalf of our domain name.
In addition, some mail stand such as SPF and DMARC enables us to instruct another mail
infrastructure “what to do” in case that the E-mail message that sent seemingly by one of our
recipients didn’t send from an authorized mail server.
The Exchange and the Exchange Online options don’t include a mechanism that can be used in
such scenarios of outbound mail.
What Is The Best Option For Identifying Of Spoof E-Mail?
Without knowing you personally, I’m pretty sure that after reading all the above information, the
following question could appear in your mind:
Q: What is the bottom line? Which is the “right tool” for my organization?
A: The answer that I have included a couple of parts:

Better something than nothing
It’s better to start with the implementation of at least one mail sender verification standard
versus “not doing anything,” and leave your organization mail infrastructure exposed to a variety
of risk and dangers.
Using a specific sender verification mechanism versus a combination of more than one
mechanism
Theoretically, we can be satisfied with only one ” chosen” mail standard or mechanism
such as – SPF, DKIM or one the Exchange option.
In reality, the “true” solution, will need to be based on more than one standard because, the
different standard completes each other, and each of them covers other or different type Spoof
mail scenarios.
Baby step | Step by step
The best practice is to start with a simple sender verification standard, and only after we feel
comfortable, “move on” to the next step in which we implement an additional standard.
My opinion is that the simplest option is – to start with the implementation of the SPF standard
because the SPF standard can be described as a relatively easy standard to implement.
In case that your mail infrastructure is based on Exchange infrastructure, it’s recommended also
to add the “additional layer,” in which we use Exchange rule, that identifies an event in which
incoming mail includes the sender who has our E-mail address but doesn’t provide user
credentials.
Note – if you want to read more information about the way for how to implement
the “Exchange option” using a Spoof E-mail rule, you can read the article – Detect
spoof E-mail and send an incident report using Exchange Online rule (Learning
mode) |Part 2#12

So, what is the best combination of sender identification standard options?
The answer is – that there is no specific “cocktail” that can be described as the “best cocktail”.
For example – a reasonable question could be-
Q1: Why not to use all the available options?
Q2: Can we use the concept of more the better?
A: The answer is “Yes,” and “No.”
Theoretically, it’s better to use all the available options that we can use for identifying events of
Spoof E-mail, but we should not forget that each of these “standard” or “mechanism” requires
its own resources.
The resource that will need to be allocated to:
 Learning and implementing the required configuration settings for each of the “sender
verification solutions”

 The ongoing tasks such as – monitoring the events of a Spoof mail that were “captured”
by the specific standard – the need to review and examine the E-mail items that was
identified as Spoof mail and the need to decide what to do with this E-mail item.
The Secret Location Of The Sender E-Mail Address
As mentioned, the mail standard that verifies the sender identity verifies the information about
the E-mail address of the sender.
The SMTP protocol defines two mail fields, that were created for storing information about the
identity of the sender’s meaning, the E-mail address of the sender.
 One type of “information” about the sender, is kept in a mail field named – MAIL
FROM that is “located” in the mail envelope.
 One type of “information” about the sender, is kept in a mail field named – FROM that is
“located” in the mail header.
The mail envelope considers as a “temporary data store” that serves as a “logical container” for
data, in the phase of the SMTP session in which two mail servers communicate.

The mail envelope concept is very similar to a “psychical mail envelope.”
After the E-mail, the message is accepted by the destination mail server that represents the
destination recipient, and after the destination mail server reads all the required information that
is stored in the mail envelope, the mail envelope is “destroyed.”
In this phase, two optional questions can appear in our mind:
Q1: Why do we need to use two different mail field for storing the information about the sender
identity (the sender E-mail address)?
Q2: Why are you telling me all of this information? How this information related to the topic in
question?
A1:
The main purpose of the “sender information” that appears in the mail envelope
(MAIL FROM) is to serve as a “return mail” address.
“Return mail” address used by the destination mail server, in a scenario in which the E-mail
message could not be sent to the destination recipient, and the mail server will need to “return
the mail” to his original sender.
The main purpose of the “sender information” that appears in the mail header
(FROM) is to inform the destination recipient, who is the sender that “wrote” the E-mail
message.
In some scenarios, the sender who appears in the MAIL FROM (the mail envelope) can
be different from the sender identity that appears in the FROM field (the mail header).
A2: The reason that I tell you this “boring information” is, because the mail standard – SPF and
DKIM use this the information stored in this field (MAIL FROM and FROM) for getting the
information about the sender identity, and implementing the sender verification procedure.

Note- the SPF standard process is configured to verify the sender information that is 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 article – How can
hostile element execute Spoof E-mail attack and bypass existing SPF implementation? |
introduction | 1#2
The E-mail message components – mail envelope, the mail and the mail header
In the following diagram, we can see the structure of a standard E-mail message that includes
the two parts: mail envelope and the mail.
In the next diagram, we can see the structure of “mail component”, which includes also two
parts: the “mail part” that includes the mail body, and the mail header.

Mail envelope – the “mail fields” that hold the value of the sender and the
recipient
The mail envelope uses the following fields for storing information about the sender identity
and the destination recipient identity:
1. The sender identity – the Mail envelope uses a “mail field” named – MAIL FROM, for
“holding” the information about the sender identity (the sender E-mail address).
2. The recipient identity – the Mail envelope uses a “mail field” named – RCPT TO, for
“holding” the information about the recipient identity (the destination recipient E-mail
address).

Mail header– the “mail fields” that hold the value of the sender and the
recipient
Regarding the “mail component”, the part which holds the information about the sender and
recipient identities is the Mail header.
The mail header, uses the following fields for storing information about the sender identity and
the destination recipient identity:
1. The sender identity – the Mail header uses a “mail field” named – FROM, for “holding” the
information about the sender identity (the sender E-mail address).
2. The recipient identity – the Mail header uses a “mail field” named – TO, for “holding” the
information about the recipient identity (the destination recipient E-mail address).

Additional reading
 How to review and mitigate the impact of phishing attacks in Office 365
 The common types of spear phish we see today
 How antispoofing protection works in Office 365
 Email authentication should work out of the box and we should not rely upon domain owners
to do it themselves
The next article in the current article series is
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

Using sender verification for identifying spoof mail spf, dkim, dmarc, exchange and exchange online part 8#9 | Eyal Doron | o365info.com

Recommandé

Recommandé

Contenu connexe

Plus de Eyal Doron

Plus de Eyal Doron (20)

Dernier

Dernier (20)

Using sender verification for identifying spoof mail spf, dkim, dmarc, exchange and exchange online part 8#9 | Eyal Doron | o365info.com