In the current article, I would have to provide you a useful way, for implementing a mail security policy that relates to an event in which the result of the SPF sender verification check is “Fail.”
If we want to be more precise, an event in which the SPF sender verification test result is “Fail”, and the sender used the E-mail address, which includes our domain name.
This type of scenario, there is a high chance that we are experiencing a Spoof mail attack!
The SPF Fail policy article series, including the following three articles
- Implementing SPF Fail policy using Exchange Online rule (dealing with Spoof E-mail attack) | Introduction | Part 1#3
- Implementing SPF Fail policy using Exchange Online rule (dealing with Spoof E-mail attack) | Phase 1 – learning mode | Part 2#3
- Implementing SPF Fail policy using Exchange Online rule (dealing with Spoof E-mail attack) | Phase 2 production | part 3#3
A few clarifications regarding the Spoof mail attack and SPF
Q1: How does Spoof mail attack is implemented?
A1: A Spoof mail attack implemented when a hostile element, uses a seemingly legitimate sender identity. The sender identity can be any identity, such as the sender identity of a well-known organization\company, and in some cases; the hostile element is rude enough to use the identity of our organization for attacking one of our organization users (such as in spear phishing attack).
Q2: Why does the hostile element use our organizational identity?
A2: The purpose of using the identity of one of our organization users is because, there is high chance that the Innocent victim (our organization user), will tend to believe someone he knows versus, some sender that he doesn’t know (and for this reason tends to trust less).
Q3: What is the purpose of the SPF mechanism?
A3: To improve the ability of our mail infrastructure, to recognize the event in which there is a high chance, that the sender spoofs his identity or a scenario in which we cannot verify the sender identity.
The other purpose of the SPF is to protect our domain mane reputation by enabling another organization to verify the identity of an E-mail message that was sent by our legitimate users.
Q4: What is the meaning of “SPF = Fail”
A4: The sender E-mail address, contain information about the domain name (the right part of the E-mail address). The organization publishes an SPF record (implemented as TXT record) that includes information about the IP address of the mail server\s, which is authorized to send an E-mail message on behalf of the particular domain name.
In case that the mail server IP address that sends the E-mail on behalf of the sender, doesn’t appear as authorized IP address in the SPF record, SPF sender verification test result is “Fail.
The meaning of the “SPF = Fail” is that we cannot trust the mail server that sends the E-mail message on behalf of the sender and for this reason, we cannot trust the sender himself.
Q5: Where is the information about the result from the SPF sender verification test is stored?
A5: The information is stored in the E-mail header.
Q6: In case that the information in the E-mail message header includes results of “SPF = Fail”, does the destination recipient is aware of this fact?
A7: Technically speaking, each recipient has access to the information that is stored in the E-mail message header and theoretically, we can see the information about the “SPF = Fail” result.
In reality, it’s very rare that the recipient will access data stored in the E-mail message header, and even if they access the data, they don’t have the ability to understand most of the information that contained within the E-mail header.
In simple words, the destination recipient is not aware of a scenario in which the SPF result is “Fail”, and they are not aware of the fact that the E-mail message could be a spoofed E-mail.
Q8: Who is the “element” which is responsible for alerting users regarding a scenario in which the result of the SPF sender verification test is – “Fail”?
A8: The responsibility of the SPF mechanism is – just to “stamp” the E-mail message with the SPF sender verification test results.
The SPF mechanism is not responsible for notifying us or, to draw our attention to events in which the result from the SPF sender verification test considered as “Fail.”
The “element” which needs to be responsible for “capturing” event in which the SPF sender verification test considered as “Fail” is – our mail server or the mail security gateway that we use.
Q9: So how can I “activate” the option in which we capture events of an E-mail message that have the value of “SPF = Fail”?
A9: The answer depends on the particular mail server or the mail security gateway that you are using.
Q10: Why our mail server doesn’t automatically block incoming E-mail that has the value of “SPF = Fail”?
A10: To avoid a scenario of false-positive meaning, a scene in which legitimate E-mail will mistakenly identify as a Spoof mail. Most of the mail infrastructures will leave this responsibility to us meaning – the mail server administrator.
How to enforce SPF fail policy in Office 365 (Exchange Online) based environment
The interesting thing is that in Exchange based environment, we can use very powerful Exchange server feature named- “Exchange rule,” for identifying an event in which the SPF sender verification test result is “Fail”, and define a response respectively.
In Office 365 based environment (Exchange Online and EOP) beside of the option of using Exchange rule, we can use an additional option – the “spam filter policy“.
Exchange Online (EOP), include spam filter policy, which contains many security settings that are disabled by default, and can be activated manually based on the particular mail security policy that the organization wants to implement.
One option that is relevant for our subject is – the option named – SPF record: hard fail.
This option enables us to activate an EOP filter, which will mark incoming E-mail message that has the value of “SFP =Fail” as spam mail (by setting a high SCL value).
In the current article series, our primary focus will be – how to implement an SPF policy for incoming mail, by using the option of – “Exchange rule”, and not by using the Exchange Online spam filter policy option.
The reason that I prefer the option of “Exchange rule” is, that the Exchange rule is a very powerful tool that can be used to define a Tailor-made SPF policy that will suit the specific structure and the needs of the organization.
For example, versus the Exchange Online “spam filter policy” that marks every incoming E-mail message that has the value of “SPF = Fail” as spam mail without distinction, when using the option of Exchange rule, we can define a more refined version of this scenario, a condition in which only if the sender uses our domain name + the result from the SPF verification test is “Fail,” only, then the E-mail message will be identified as – Spoof mail.
Another distinct advantage of using Exchange Online is the part which enables us to select a very specific “response” (action), that will suit our needs such as – Perpend the E-mail message subject, Send warning E-mail, send the Spoof mail to quarantine, generate the incident report and so on.
The main two purposes of using SPF mechanism
The main purpose of SPF, is to serve as a solution for two main scenarios:
Scenario 1 – Improve our E-mail reputation (domain name).
A Spoof mail attacks scenario, in which hostile element abuses our organizational identity, by sending spoofed E-mail message to external recipients, using our organizational identity (our domain name).
The simple truth is that we cannot prevent this scenario because we will never be able to have control over the external mail infrastructure that is used by these hostile elements.
The only thing that we can do is – enable other organizations that receive an email message that has our domain name, the ability to verify if the E-mail is a legitimate E-mail message or not. In other words, using SPF can improve our E-mail reputation.
Scenario 2 – incoming mail | Protect our users from Spoof mail attack
A scenario in which hostile element spoofs the identity of a legitimate recipient, and tries to attack our organization users.
This type of mail threat appears in two flavors:
- Case 1 – a scenario in which the hostile element uses the spoofed identity of a
well-known organization such as Bank, Insurance company, a government institution.
- Case 2 – a scenario in which the hostile element uses a spoofed identity of one of our organization recipients, meaning, using an E-mail address that includes our organization domain name.
The popular misconception relating to SPF standard
In this section, I would like to review a couple of popular misconceptions that relate to SPF standard.
Misconception 1 – using SPF will protect our organization from every scenario in which hostile element abuses our organizational identity. The meaning is – a hostile element that executes spoofing or Phishing attacks, and use a sender E-mail address that includes our domain name.
This conception is partially correct because of two reasons:
- We cannot be sure if the mail infrastructure of the “other side” support SPF, and if he implements an SPF sender verification test.
- Even in a scenario in which the mail infrastructure of the “other side” support SPF, in case that the SPF verification test marked as “Fail”, we cannot be sure that the spoofed E-mail will blocked. In many scenarios, the spoofed E-mail message will not be blocked even if the SPF value marked as “Fail” because of the tendency to avoid from a possible event of false positives.
Misconception 2 – SPF mechanism was built for identifying an event of incoming mail, in which the sender Spoof his identity, and as a response, react to this event and block the specific E-mail message.
This conception is half true. The SPF sender verification can mark a particular E-mail message with a value to “SPF = none” or “SPF = Fail”.
We can say that the SPF mechanism is “neutral” to the results his main responsibility is to execute the SPF sender verification test and to add the results to the E-mail message header. The SPF mechanism doesn’t perform and concrete action by himself.
The element that should “read” this information (the SPF sender verification test result),
and “do something” about it, is the mail server or the mail security gateway that represents the organization mail infrastructure.
Misconception 3 – in Office 365 and Exchange Online based environment the SPF protection mechanism is automatically activated.
It is true that Office 365 based environment support SPF but it’s imperative to emphasize that Office 365 (Exchange Online and EOP) is not configured anything automatically!
To be able to use the SPF option we will need to implement by ourselves the following proceeds:
- Add the required SPF record
Add to the DNS server that hosts our domain name the required “SPF record,” and verifies that the syntax of the SPF record is correct + verify that the SPF record includes information about all the “entities” that send an E-mail message on behalf of our domain name.
- Instruct the Exchange Online what to do regarding different “SPF events.”
This is the main reason for me writing the current article series.
As mentioned, the SPF sender verification test just “stamp” the E-mail message with information about the SPF test result.
The responsibility of “what to do in a particular SPF scenario” is our responsibility!
For example, in an Exchange Online based environment, we can activate an Exchange Online server setting that will mark each E-mail message that didn’t pass the SPF verification test (SPF = fail) as a spam mail.
To be able to “react” to the SPF events such as “SPF = none” (a scenario in which the domain doesn’t include a dedicated SPF record) or a scene of “SPF = Fail” (a scene in which the SPF sender verification test failed), we will need to define a written policy that will include our desirable action + configure our mail infrastructure to use this “SPF policy.”
For example – in Exchange based environment, we can add an Exchange rule that will identify “SPF failed events,” and react to this type of event with a particular action such as alert a specially designated recipient or block the E-mail message.
What are the possible options of the SPF test results?
In the following section, I would like to review the three major “values” that we get from the SPF sender verification test.
The three primary SPF sender verification test results could be:
Scenario 1 – SPF = Pass
Regarding the result, in which the SPF result is “Pass”, this is a sign that we can be sure that the mail sender is a legitimate user, and we can trust this sender.
Scenario 2 – SPF = None
The decision regarding the question, how to relate to a scenario in which the SPF results define as – “None” and “Fail” is not so simple.
There is no “right answer” or a definite answer that will instruct us what to do in such scenarios.
The meaning of “SPF =none” is that a particular organization that is using a specific domain name doesn’t support SPF or in other words, doesn’t enable us to verify the identity of the sender that their E-mail message includes the specific domain name.
Can we say that we should automatically block E-mail message which their organization doesn’t support the use of SPF?
My opinion that blocking or rejecting such E-mail messages is too risky because, we cannot enforce other organizations to use SPF, although using SPF is recommended and help to protect the identity and the reputation of a particular domain.
Scenario 3 – SPF = fail
This is the scenario in which we get a “clear answer” regarding the result from the SPF sender verification test – the SPF test fail!
The obvious assumption is that this is the classic scenario of Spoof mail attack and that the right action will be to block automatically or reject the particular E-mail message.
And as usual, the answer is not so “straightforward” as we think.
The event in which the SPF sender verification test result is “Fail”, can be realized in two main scenarios
- Scenario 1 – the sender uses an E-mail address that includes a domain name of a well-known organization.
- Scenario 2 – the sender uses an E-mail address that includes our domain name.
In each of the above scenarios, the event in which the SPF sender verification test ended
with “SPF = Fail” result is not “good”.
However, there is a significant difference between this scenario.
In scenario 1, in which the sender uses the identity of a well-known organization, we can never be sure definitively that the E-mail message is indeed a spoofed E-mail.
Versus this scenario, in a situation in which the sender E-mail address includes our domain name, and also the result from the SPF sender verification test is “fail”, this is a very clear sign of the fact that the particular E-mail message has a very high chance to consider as Spoof mail.
The reason for our “confidence” that the particular E-mail message has a very high chance to consider as Spoof mail is because we are the authority who is reasonable for managing our mail infrastructure.
For example, we are reasonable for configuring SPF record that will represent our domain and includes the information about all the mail server (the Hostname or the IP address) that can send E-mail on behalf of our domain name.
Given that the SPF record is configured correctly, and given that the SPF record includes information about all of our organizations “mail server entities,” there is no reason for a scenario in which a sender E-mail address which includes our domain name will mark by the SPF sender verification test as “Fail”.
To be able to get a clearer view of the different “SPF = Fail” scenarios, let’s review the two types of “SPF = Fail” events.
Scenario 1 – SPF sender verification test fail | External sender identity
In this scenario, our mail server accepts a request to deliver an email message to one of our organization recipients.
- The E-mail address of the sender uses the domain name of a well-known bank.
The result from the SPF sender verification test is – Fail
What is the conclusion such as scenario, and should we react to such E-mail message?
The conclusion could be:
- The E-mail message is a spoofed E-mail message that poses a risk of attacking our organization users.
- The E-mail is a legitimate E-mail message. The reason for the outcome of “SPF = Fail” is related to missing configuration on the “sending mail infrastructure.”
In reality, we can never be sure in 100%, that the E-mail message is indeed spoofed E-mail message or, a legitimate E-mail message.
In this scenario, we can choose from a variety of possible “reactions.”
For example, in case that we need to Impose a “strict security policy,” we will not be willing to take the risk, and in such scenario, we will block the E-mail message, send the E-mail to quarantine or forward the E-mail to a designated person that will need to examine the E-mail and decide if he wants to “release” the E-mail or not.
In reality, most of the organization will not implement such strict security policy because they would prefer to avoid a false-positive scenario in which a legitimate mail mistakenly identified as Spoof mail.
Scenario 2 – SPF sender verification check fail | “our organization” sender identity.
In this scenario, our mail server accepts a request to deliver an email message to one of our organization recipients.
In our scenario, the organization domain name is o365info.com
- The E-mail address of the sender, uses the domain name of our organization, for example – Jeff@o365info.com
- The result from the SPF sender verification test is – Fail
What is the conclusion such as scenario, and should we react to such E-mail message?
Given that we are familiar with the exact structure of our mail infrastructure, and given that we are sure that our SPF record includes the “right information” about our mail server’s IP address, the conclusion is that there is a high chance that the E-mail is indeed spoofed E-mail!
In case that you wonder why I use the term “high chance” instead of – “definite chance” is because, in reality, there is never 100% certainty scenario.
In reality, there is always a chance that the E-mail message in which the sender uses our domain name includes and the result from the SPF sender verification test is – Fail could be related to some miss configuration issue.
What is the recommended “reaction” to such a scenario?
The answer is that as always; we need to avoid from being “too cautious” versus being “too permissive”.
A good option could be, implementing the required policy in two phases-
Phase 1 – the learning \ inspecting mode
in this phase, we are only “capturing” event in which the E-mail address of the sender uses the domain name of our organization, and also; the result from the SPF sender verification test is – “Fail”.
After examining the information that collected, and implementing the required adjustment, we can move on to the next phase.
Phase 2 – enforcing a specific policy
This phase can describe as the “active phase” in which we define a specific reaction to such scenarios.
How to deal with a Spoof mail attack using SPF policy in Exchange based environment?
As mentioned, in Exchange based environment, we can use the Exchange rule as a “tool” that will help us to capture the event of “SPF = Fail” and also, choose the required response to such as an event.
Despite that the first association regarding the “right response” to an event in which the sender uses an E-mail address that includes our organization domain name + the result from the SPF sender verification test is “fail”, is to block and delete such E-mails; I strongly recommend not doing so.
My two recommendations are as follows:
Implement the “SPF Fail policy” using a two-phase procedure – the learning \ inspection phase and the production phase.
Even when we get to the “production phase”, it’s recommended to choose a less aggressive response. Instead of immediately deleting such E-mail items, the preferred option is to “redirect” this E-mail to some isolated store such as quarantine.
In case that we want to get more information about the event or in case that we need to deliver the E-mail message to the destination recipient, we will have the option.
Phase 1 – Learning \ inspection mode
This phase described as learning mode or inspection mode because the purpose of this step has been just to identify an event of a Spoof mail attack in which the hostile element uses an E-mail address that includes our domain name + Log this information.
By analyzing the information that collected, we can achieve the following objectives:
- Learning about the characters of Spoof mail attack
From my experience, the phase is fascinating because after we are activating the “monitor process”, we will usually find a absorbing finding of:
- The amount of Spoof mail attack event.
- The “popular” organization users who are being attacked.
- The various types of Spoofing or Phishing attacks
Based on this information, we will be able to understand the real scope of the problem, the main characters of this attack and so on.
- Identify a possible miss configuration of our mail infrastructure
The most important purpose of the learning \ inspection mode phase is – to help us to locate cracks and grooves in our mail infrastructure.
For example, one of the most popular reasons for the result “fail” when using the SPF sender verification test is a problem or a miss configuration, in which the IP address of one of our mail server \services that our organization use, was not added to the SPF record.
This scenario can have two main clarifications:
A legitimate technical problem – a scene in which we are familiar with the particular mail server \ software component, that sent an email message on behalf of our domain
A “non-legitimate mail element” – a scenario in which we discover that our organization uses mail server or mail applications that send an E-mail message on behalf of our domain, and we are now aware of these “elements.”
This is where we use the learning \ inspection mode phase and use it as a “radar” that helps us to locate anomalies and other infrastructure security issues.
- Identify other problematic” events
In this category, we can “put” every event in which a legitimate E-mail message includes the value of “SPF = Fail”. The reason could be a problem with the SPF record syntax, a specific mail flow, such as
E-mail forwarding that leads to this result and so on.
Phase 2 – Production mode
After a specific period, which we allocate for examining the information that collected, we can move on to the “active phase,” in which we execute a specific “action” in a scenario that the Exchange rule identifies an E-mail message that is probably Spoof mail.
In this phase, we will need to decide what is the concrete action that will apply for a
specific E-mail message that will identify a Spoof mail (SPF = Fail).
Most of the time, I don’t recommend executing a response such as – block and delete E-mail that was classified as spoofing mail because the simple reason is that probably we will never have full certainty that the specific E-mail message is indeed spoofed mail.
To be able to avoid from a false-positive event, meaning an event in which a legitimate E-mail message mistakenly identified as Spoof mail, I prefer more refinement actions such as – send the E-mail to approval, send the E-mail to quarantine and so on.
Exchange rule logic and SPF fail evenest
The Exchange rule includes three main parts:
- The Condition
- The Actions
- The Exceptions
In our specific scenario, we will use the Exchange rule using the following configuration setting-
Phase 1 – Learning \ inspection mode | Exchange rule setting
As mentioned, in this phase our primary purpose is just to “capture” Spoof mail attack events (SPF = Fail) and creating a “log” which will be used for analyzing the information that gathered.
The Exchange tool \ option that we use for the purpose of gathering information about a particular mail flow event described as an – incident report.
The Exchange incident report, includes a summary of the specific mail flow, such as – the name of the sender, recipient, and the Exchange rule that was activated and also; we can ask to include an attachment of the original E-mail message that was “captured.”
The condition part will activate the Exchange rule when the combination of the following two events will occur:
The E-mail address of the sender includes our domain name (in our specific scenario; the domain name is o365info.com).
The result of the SPF sender verification check is “fail” (SPF = Fail).
In phase 1 (the learning mode), we will execute the following sequence of actions:
- Generate and Send an incident report to a designated recipient (shared mailbox) that will include information about the characters of the event + the original E-mail message.
- Add a predefined warning message, to the E-mail message subject. This option described as – prepend E-mail subject.
Phase 2 – Production mode
This phase implemented after we are familiar with the different scenarios of Spoof mail attacks. In this step, we want to protect our users from Spoof mail attack.
The defense action that we will choose to implement in our particular scenario is – a process in which E-mail message that identified as Spoof mail, will not be sent to the “original destination recipient.”
Instead, the E-mail message will be forwarded to a designated authority, such as IT person, that will get the “suspicious E-mail,” and this person will need to carefully examine the E-mail and decide if the E-mail is indeed spoofed E-mail or a legitimate E-mail message that mistakenly identified as Spoof mail.
Also, the “original destination recipient” will get an E-mail notification, which informs him that a specific E-mail message that was sent to him was identified as Spoof mail and for this reason didn’t automatically send to his mailbox.
Exchange Online | Using the option of the spam filter policy
In the next two articles (article Implementing SPF Fail policy using Exchange Online rule (dealing with Spoof E-mail attack) | Phase 1 – learning mode | Part 2#3 and article Implementing SPF Fail policy using Exchange Online rule (dealing with Spoof E-mail attack) | Phase 2 production | part 3#3), we will review in details the implementation of SPF fail policy by using an Exchange Online rule.
Despite my preference for using Exchange rule as preferred “tool” for enforcing the required SPF policy, I would also like to mention an option that is available for Office 365 customers, which their mail infrastructure based on Exchange Online and EOP (Exchange Online Protection).
EOP includes a default “spam filter policy,” which include a variety of options that enable us to “harden” the existing mail security policy.
One of the options that can be activated is an option named – “SPF record: hard fail.”
By default, this option is not activated.
In case that we decide to activate this option, the result is that each of the incoming E-mails that accepted by our “Office 365 mail server” (EOP) and that include SPF sender verification results
of “SPF = Fail” will is automatically marked as spam mail.
The main reason that I prefer to avoid the option of using the Exchange Online spam filter option is because, this option doesn’t distinguish between a scenario in which the sender uses our domain name as part of his E-mail address versus a scenario in which the sender uses E-mail address, which doesn’t include our domain name.
In each of these scenarios, if the SPF sender verification test value is “Fail” the E-mail will mark as spam.
This type of configuration can lead us to many false-positive events, in which E-mail message that sent from our customer or business partner can be identified as spam mail.
How to configure Exchange Online spam filter policy to mark SPF fail as spam
- Log in to the Exchange admin portal
- On the left menu bar, choose – protection
- On the top menu bar, choose – spam filter
- Choose the default spam filter policy
- Select the pencil icon for editing the default policy
- On the left menu bar, choose the advanced option menu
- Under the section names – SPF record: hard fail: select the option ON
Recap and next article
In the current article, we have reviewed the need for completing the missing part of our SPF implementation, in which we need to “capture” an event of SPF sender verification test in which the result is “fail” and, especially, in a scenario in which the sender E-mail address includes our domain name (most likely certainly a sign that this is a Spoof mail attack).
In the next article – Implementing SPF Fail policy using Exchange Online rule (dealing with Spoof E-mail attack) | Phase 1 – learning mode | Part 2#3 , we will review the step by step instruction that needed for creating an Exchange Online rule that will help us to monitor such events.
It is important for us to know your opinion on this article