Securing your Email traffic and avoid spoofing and/or phishing with EOP

In his article Pavel shares with us ways and tips to avoid Email spoofing and phishing by maximizing the Office 365 EOP service.

by | Published: | Updated:

Lately there is an outburst in spoofing and phishing emails that attack organizations on daily basis with analytic precision which makes it harder to recognize the spoof and take action.

The standard methods widely known and acknowledged as a working solution for these kind of malicious emails are no longer enough, only because the attacks became more sophisticated in the core level of the email headers.

We all familiar with Sender Policy Framework (SPF) method to help us deal with imposters but what not all are aware of is that there are two ways to designate the sender:

In addition, you may see a header “X-Sender” which also gives information about the sender.

Here is an example of such a header:

The problem here is this: even though we placed an SPF record on our domain (i.e., the domain that is going through this check is spoofer’s domain and, awkward enough, will display the following header:

In other word, this is a legitimate email as long as SPF goes because it checks the Envelope address for SPF, and this domain does not have an SPF record at all. Bummer.

To fight this kind of spoofing techs we can implement several methods:

  1. DKIM – Signing emails that are sent from my organization
  2. DMARC – Match the 5322.From and 5321.MailFrom fields by checking SPF and DKIM
  3. Mail Flow Rules – Advanced transport rules

Domain Keys Identified Mail (DKIM)

The foremost concern should be your own domain, mainly because of the reason you have received a spoofed email as your domain by your domain. This proved that SPF isn’t enough.

DKIM method signs an email. This signature, when validated, represent the fact that the email was actually from your domain and wasn’t altered in the middle.

Signed email headers look like this:

When an email is signed, the receiving organization performs signature validation by decrypting this signature using public DNS records that hold the public key for this encryption.

These CNAME records will look like this:

If the email passed validation, then we can know for sure that it come from a respectful domain.

To be more specific, lets breakdown the header:

As far as this goes everything is fine, but what if your company were using a mail enrichment. In this case you cannot use DKIM, because your emails may fail to deliver if the receiving organization checks your DKIM signature.

This method ensures that my domain is signed and stands correct if front of the receiving party but doesn’t save from spoofing.

You also have to keep in mind that in order to use this method in Office 365 you have to relay through EOP when EOP is the last hop.

After you’ve set up the records in DNS you should enable DKIM on your domain by going to your Exchange Admin Center in Office 365, selecting Protection and then DKIM. Then select your domain and click on Enable.

Domain-based Message Authentication, Reporting & Conformance (DMARC)

DMARC is meant to check both the SPF and DKIM. This means that it ensures that the domain in the Envelope (5321.MailFrom) matches the displayed domain (5322.From).

Let’s examine a DMARC header:

The DMARC in Office 365, without a DNS record, use analytic system to guess the result as if the DMARC record was set. In other words, if the DMARC DNS record was set for the domain it would pass DMARC eventually.

This also mean that if you have enabled DKIM and implement SPF, an email that spoofed your domain will probably get blocked. However, for better assurance and customization it is good practice to create a DMARC record

DMARC Record:

DMARD record is a TXT record in public DNS which instructs the receiving email organization to perform a DMARD check on an incoming email by parameters specified in the TXT record.

For example: sends an email to will start by checking the SPF and DKIM and finally, if has a DMARC record, it will check DMARC parameters.

Let’s breakdown the DMARC record for domain

The record in the DNS should look like this:

The value of the record is built the following way:

_dmarc IN TXT “v=DMARC1 p=quarantine sp=quarantine adkim=r aspf=s pct=100 fo=0 rf=iodef ri=3600”

Here’s a table explaining each of the parameters:

It is also good to note that Exchange Online Protection is not treating p=reject value as reject. Instead, it will quarantine the message. This behavior is by design and was created for legal purpose in case of false positive emails. This also means the EOP treats p=reject as though it was p=quarantine.

In this case we will see the following header:

Notice that the action has the value oreject. This behavior is unique to Office 365 whereas in other mail relays it will reject the email with NDR to the sender.

If you were to configure notification reports on your DMARC record it will look something like this:

DMARC Scenarios:

Let’s cover some scenarios as to how to configure DMARC in certain situations:

Bulk Mail solution

When using a 3rd party bulk mail senders it is important to acknowledge that DKIM signing may not be possible.

In this case you may consider to create a sub-domain for these emails, for example:, and you should create an SPF record for this domain.

The following table explains the email security configurations for this scenario:

The DMARC record will implement action p=reject for the root domain and ps=quarantine for subdomains. The aspf parameter has to be ‘s’ for strict while adkim parameter is relaxed with the value ‘r’.

Here’s an example of this record:

_dmarc IN TXT “v=DMARC1 p=reject sp=quarantine aspf=s fo=0 rf=iodef ri=3600”

The receiving organization will see the following header example:

Email modification by a 3rd party (i.e. Mail Enrichment)

At the end of DKIM section I’ve explained a shortcoming of this method in case your organization is using a mail enrichment product. In this scenario the DKIM will fail for your domain because the email gets modified after it is signed.

The decision should be using SPF and disregarding DKIM, thus the DMARC record will look the same as in the previous example.

In both these cases the anti-spoofing will lack all the necessary components and in many cases will not be enough for the receiving party. However, if you wish to secure your own organization from spoofed emails while implementing partial DMARC you should continue to the Advanced Rules section.

Mail Flow Rules – Advanced Transport Rules:

As previously stated, when using partial DMARC, you may still be subject to spoof attacks from your own domain, and this is because your domain doesn’t align with both RFCs (5321.MailFrom & 5322.From).

The chances for an external organization to get spoofed emails, imposing as your own domain, are much less than getting these emails in your domain, for the main reason that the evil actions of the spoofer are to retrieve valuable information from your domain and/or instruct the target person (the recipient) to perform an action that will bring damage to your organization.

Let’s start with the rule creation.

Follow these steps to select ‘Create a new rule’ wizard:

In the next window please notice ‘More options…’ link at the bottom of the windows and click it.

This option will expand the tree of possibilities in the condition, exclusion and action fields.

The first thing we shall do is create a rule that will inspect the emails, but will not take action except writing an incident report to a designated mailbox and indicating a hit on the rule.

Doing so, for a short period of time, may give you some perspective on what your organization is sending to itself.

Here’s a short example of this rule:

The logic of this rule goes as follows:


Whenever an email is hitting this rule, the person that is indicated as the receiver of incident reports will know how and why this email was blocked.

After a period of time, when you are aware of all the false positives, you can enter the second phase of this procedure by placing exclusions for legitimate emails and redirecting bad ones to quarantine.

This rule should look like this:

I hope this article was useful to your organization.

To further dive into the specifics of SPF, DKIM and DMARC please refer to these sources:






Pavel Rozenberg

About the Author

Pavel Rozenberg - Infrastructure Consultant at U-BTech Solutions


comments powered by Disqus