In the current article, we will review how to implement an SPF Policy for incoming mail by using an Exchange rule.
In our scenario, we want to identify an event, in which hostile element tries to execute a Spoof mail attack by presenting himself, as a legitimate recipient who uses an E-mail address that includes our domain name.
In this case, the result from the SPF sender verification test will be “fail” (SPF = Fail).
By using the Exchange rule, we will be able to “capture” such events and respond appropriately.
Note – the underlying assumption is that we have already configured the SPF record that includes the information about our organization authorized mail meaning, the mail server that is allowed to send an E-mail message on behalf our domain.
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
SPF Policy | Implementing the first phase – learning \ inspection mode
As mentioned in the former article, the “project” in which we will use an Exchange Online rule for implementing our desired “SPF Fail policy,” will be implemented in two different phases:
Phase 1 – Learning \ inspection mode
Our primary goal during this phase is, just to collect information about events about email messages that have a high chance of being spoofed E-mail (spoofed sender) meaning,
E-mail messages that the header includes the value “SPF = Fail” and that the sender
E-mail address includes our domain name.
The information that we collect will help us to learn about:
- The characters of the Spoof mail attack that are executed by hostile elements.
- About “entities” that send an E-mail message on behalf of our domain name that was not registered in the SPF Record and lead to a scenario of “SPF = Fail.”
In this phase, we will not block such as E-mail message, but instead, just send a copy of the original E-mail message to a designated recipient.
Also, we will add a “warning” to each of the E-mail messages that were “captured” by the Exchange rule.
The warning is implemented by adding a predefined text, to the subject of the E-mail that sent to the user mailbox.
Phase 2 – Production mode
In the next article, we will review how to implement “Phase 2”, in which we prevent E-mail message that identified as a Spoof mail from reaching the user mailbox.
The spoofed E-mail message will be forwarded to a designated recipient, who will need to examine the E-mail and decide if the E-mail is a legitimate E-mail message or not.
The business needs | Guidelines for our SPF Fail policy
The business needs and the goals that we need to accomplish are as follows:
- We want to identify events in which E-mail messages that sent to our organization recipient have a high chance of being spoofed E-mail (spoofed sender).
The E-mail will be considered as Spoof mail, in case that the sender E-mail address uses our domain name (o365info.com) and also, the SPF sender verification test result is “Fail.”
- We don’t want to intervene in the mail flow because our primary purpose is just to collect information about “Spoof E-mail events”. In other words, use the Exchange Online rule for gathering information about a possible Spoof E-mail event (“learning mode” or “inspection mode”).
- Each time that the Exchange Online rule “capture” event of Spoof mail, the Exchange rule will add a warning text to the E-mail subject (prepend E-mail subject).
- Each time that the Exchange Online rule “capture” the specific event, Exchange will generate and send, an incident report to the designated recipient.
The incident report will include a summary report + a copy of the original E-mail message.
- The “designated recipient” will be implemented by creating a dedicated shared mailbox for this purpose named – spoof E-mail Mailbox. This mailbox will contain the incident reports that will be sent by the Exchange Online rule.
- We want that only an authorized person (such as the Exchange Online administrator), will be able to access the shared mailbox that stores the incident reports, so he could inspect and analyze the spoofed E-mail message.
Our specific scenario characters
To be able to demonstrate the way that we use Exchange Online rule for capturing the events of Spoof mail, in which the SPF sender verification test result is “Fail”, we will use the following scenario:
Our company public domain name is – o365info.com
The condition | Identify an event of SPF = fail + sender domain is our domain
Our Exchange Online rule will be configured to “catch” event, in which the sender E-mail address includes the domain name – o365info.com and also; the SPF sender verification test result is a Failure (SPF = Fail).
The Exchange Online rule “action.”
The “response” of the Exchange Online rule will include two “steps”:
1. Prepend the E-mail subject
The Exchange Online rule will be configured to add a “text warning message” to the E-mail header (the E-mail that identified as Spoof mail).
2. Send an incident report
Exchange Online will generate and submit an incident report, to a designated mailbox.
In our scenario, we have created a shared mailbox name – spoof E-mail Mailbox.
The incident report will include a summary of the E-mail message that considers as Spoof mail + the original E-mail message.
The logic of the Exchange Online rule
A summary of the Exchange Online rule “logic” is presented in the following diagram:
Configuring Exchange rule to identify SPF Fail Event – Generates An Incident Report + prepend the email subject
In the following section, we will provide “step by step” instructions for creating the required “Exchange Online Spoofed E-mail rule” that will answer our business needs.
Part 1#2 – configuring the “condition part” of the Exchange SPF Fail rule
- Log in to the Exchange admin portal
- On the left menu bar, choose – mail flow
- On the top menu bar, choose – rules
- Click on the plus icon
- Choose – Create a new rule…
- In the Name: box, add a descriptive name for the new rule.
In our specific scenario, we will name the rule – Detect SPF Failure events | Phase 1 – learning mode.
- Click on the –More Options… link
(by default, the interface of the Exchange Online rule includes only a limited set of options. To be able to display the additional options, we will need to “activate” the More Options…).
- In the section named –Apply this rule if… click on the small black arrow
- Choose the primary menu – The sender…
- In the submenu, select the option – domain is
- In the Specify domain window, add the required domain name that represents your organization. In our specific scenario, the public domain name is – o365info.com
- Click on the plus icon to add the domain name to the list
- Click on the OK option to save the Exchange Online rule settings.
In the second condition, we instruct Exchange Online to look at each E-mail header and look for an event in which the SPF sender verification check is “SPF = Fail.”
- Click on the add condition
- In the box named – and, click on the small black arrow
- Select the main menu named – A message header…
- Select the submenu named – includes any of these words
General information – the E-mail message header includes many “mail fields”.
The specific mail field that contains the result of the SPF sender verification test is a mail field named – Authentication-Results
- Select the menu – *Enter text…
- Provide the name of the mail field that contains the result of the SPF sender verification test, in our scenario, the mail field name is – Authentication-Results
- Select OK to save the information
General note – in this step, we add the “text string” that we look for information
- Select the menu – *Enter words…
The information about the SPF sender verification test result can appear in three different text style option:
We will add each of these options
- Write down the first option – SPF: Fail and click on the plus sign
- Continue to enter the additional two SPF string values – spf=fail and Received-SPF: Fail,spf=none.
- Select OK to save the information that was entered
Part 2#2 – Configuring the “action part” of the Exchange SPF Fail rule
In this phase, we will configure the “second part” of the Exchange Online rule.
The second part used for defining the specific response (actions), executed by the Exchange rule.
The Exchange Online rule response, will include two distinct steps:
- Generate + send an incident report to a designated recipient
- Prepend the E-mail message subject
Action 1#2 – Generate and send an incident report to a designated recipient
In our scenario, we wish to instruct Exchange Online to respond to the event in which E-mail message is identified as Spoof E-mail by creating an incident report and send it to a designated recipient: a shared mailbox named – Spoof E-mail mailbox.
- In the section named – *.Do the following… click on the small black arrow.
- Choose the menu option –Generate incident report and send it to…
The settings of the incident report include two parameters:
- The name of the “destination recipient” which will get the incident report.
- The information fields that will be included in the incident report.
- To add the required “destination recipient” name, click on the link –Select one…
- In our scenario, the recipient who will get the incident report is Spoof E-mail Mailbox.
To select the information that will be included within the incident report, click on the link named-*include message properties
In our scenario, we will choose to include all the available message properties in the summary report + a copy of the “original Spoof E-mail message”.
- Select the option –Select all
In the following screenshot, we can view the available options:
- Part A – relates to the info that will appear in the incident report summary.
- Part B – relates to the option of “attaching” copy of the original E-mail message to the incident report.
Action 2#2 – prepend the E-mail message subject
As mentioned, we don’t want to block the E-mail message that has a value of “SPF = Fail”, but instead, we would like to inform the destination recipient, that the E-mail considered as a “problematic E-mail message.”
The warning implemented by adding a predefined text to the E-mail subject.
- Click on the option add action
- Choose the option – Prepend the subject of the message with…
- In the text box, add the required notification text. Notice that the number of characters that we can use for the prepend text is limited.
- Click OK to save the settings
In the following screenshot, we can see the “final result” – the Exchange Online “SPF Fail rule” that includes the two parts:
- The condition part
- The action part
Verifying that the Exchange Online SPF Fail rule is working properly
In this phase, we would like to test the Exchange Online rule that was created in the former step, and verify that the rule is working properly.
The expected results from the Exchange Online “SFP = Fail” rule
Our desired results are – that the Exchange rule will be activated when the following condition fulfills:
- Incoming mail that needs to be sent to one of our organization recipients didn’t pass the SPF sender verification test meaning; the SPF result is “Fail.
- The sender uses the E-mail address with our domain name (the domain name o365info.com)
As a response, the Exchange rule will execute that following sequence of actions:
- Generate and send an incident report to the designated recipient. In our scenario, we ask to send the incident report to the shared mailbox named – Spoof E-mail Mailbox.
- Prepend the E-mail message subject with a predefined warning notification message.
Simulate a Spoof E-mail attack | Scenario characters
To be able to test the Exchange Online “SPF = Fail” rule is working properly, we will simulate a spoof E-mail attack that has the following characters:
We will send an E-mail message to one of our organization recipients, using a mail client that uses a public IP address that doesn’t consider as an authorized IP address.
Our expectation, that the result from the SPF sender verification test will be “Fail”.
In the following screenshot, we can see the information about the SPF record that is used by the organization – o365info.com
In our scenario, the organization mail infrastructure is hosted at Office 365 (Exchange Online) mail infrastructure.
Only Office 365 mail server consider as “authorized mail servers” that can send an E-mail message on behalf of o365info.com recipients.
The source and destination recipient whom we will use are as follows:
- A “hostile element,” is trying to spoof the identity of a legitimate organization recipient named –Jeff, which uses the E-mail address – [email protected]
- The spoofed E-mail message will be sent to a legitimate organization user named Angelina, which use the E-mail address – [email protected]
In the following screenshot, we can see the mail client that (jbmail) we use for simulating the spoof mail attack.
1#2 – verifying that the Spoof E-mail was sent to the destination recipient.
As mentioned, we don’t want to intervene in the mail flow.
Our primary purpose is just to collect information about an event in which the SPF sender verification test result is “Fail”, and the sender E-mail address includes our domain name.
The E-mail message that includes the value – “SPF = Fail”, will be sent to the original destination organization recipient mailbox ([email protected] in our scenario).
In the following screenshot, we can see that the E-mail reaches to Angelina’s mailbox.
In our scenario, the E-mail was sent to the junk mail folder because Exchange Online (EOP) recognizes that there is some problem with the E-mail, but from the user perspective (Angelina), there is no indication of the fact that the sender spoofed his identity.
In our scenario, the Exchange Online rule implements the option of “prepend E-mail subject” and in the following screenshot, we can see that the E-mail subject that sent to Angelina, includes a
warning message – “Be careful!! Probably spoof mail.”
2#2 – verifying that an incident report sent to the designated recipient
A quick reminder, when the Exchange Online rule captures the event of “SPF = Fail”, Exchange will generate + send an incident report to the recipient named
– “spoof E-mail Mailbox.”
Our Exchange Online administrator – Brad, have full access to the shared mailbox – “spoof E-mail Mailbox ” and he can view the content of the mailbox.
In the following screenshot, we can see the Exchange Online rule generates the incident report and sent it to the destination recipient.
In the following screenshot, we can see an example of the incident report E-mail.
When we look at the incident report, we can see that the incident report includes two parts:
- The copy of the original E-mail message (A).
- The incident report summary (B).
The incident report summary includes details such as:
- Information about the generator of the incident report E-mail message – “This email was automatically generated by the Generate Incident Report action” (number 1).
- The sender (the “source recipient”) that claim to be a legitimate organization recipient named – [email protected] (number 2).
- The recipients (the destination recipient) is – [email protected] (number 3)
- Rule Hit – the Exchange Online rule the “capture” the spoof E-mail event, and the action that was executed by the Exchange Online rule –”Hit: Detect SPF Failure events | Phase 1 – learning mode, Action: PrependSubject, GenerateIncidentReport” (number 4).
Examining the E-mail message header content
The Exchange Online rule is “activated” or “trigger” from an event in which the E-mail message includes an SPF sender verification test that his result is “Fail”.
In the following section, I would like to demonstrate briefly, how we can view the “behind the scenes” of the E-mail message meaning, the content of the E-mail header.
Technically speaking, there a couple of free web-based tool that serves as mail header analytical.
My favorite mail analyzer tool is the Microsoft Web-based tool named – ExRCA (Exchange remote connectivity analyzer) tool.
In our specific scenario, we will analyze the E-mail message header that was sent to Angelina
- Choose the specific E-mail message that you want to check her E-mail message header
- Choose the File menu
- Choose the Properties option
In the section named- internet headers, we can see the content of the E-mail header.
To be able to analyze the data, we will copy the information.
- Select all the information by using the Keyboard key combination – CTRL + A
- Copy the information by using the Keyboard key combination – CTRL + C
Now, we will access the ExRCA (Exchange remote connectivity analyzer) tool.
- Choose the tab – Message Analyzer
- In the white space, paste the information that was copied in the former step by using the Keyboard key combination – CTRL + V or Right click on the empty white space and choose paste
- Choose the option – Analyze headers
In the following screenshot, we can see the results.
In the section named – Authentication-Results, we can see the result of the SPF sender verification test.
The result is – spf=fail
The information that appears – (sender IP is 126.96.36.199), relates to the IP address of the “entity” that send the E-mail message to the recipient.
Any additional information about the SPF sender verification test appears in the mail failed – Received-SPF
The information is “Fail (protection.outlook.com: domain of o365info.com does not designate 188.8.131.52 as permitted sender)”
In our scenario, the recipient is hosted at Office 365 (Exchange Online mail infrastructure).
The Office 365 mail security gateway meaning, the EOP server (represented by the hostname – protection.outlook.com) inform us that the sender mail server doesn’t appear as an authorized mail server. In other words, the mail server that sends the E-mail doesn’t have the “permission” to send an E-mail on behalf of o365info.com domain name.
The next article
In the next article – Implementing SPF Fail policy using Exchange Online rule (dealing with Spoof E-mail attack) | Phase 2 production | part 3#3, we will review the implementation of the second phase, in which we move to the “production mode”.
It is important for us to know your opinion on this article