Block Spoofing in Office 365

In the past couple of weeks, we have been getting a lot of issues regarding spoofed messages in Office 365. I will try to cover the most common basic things that you can perform to block these kind of messages.

According to Wikipedia, Email spoofing is the creation of email messages with a forged sender address. It is easy to do because the core protocols do not have any mechanism for authentication. It can be accomplished from within a LAN or from an external environment using Trojan horses.

This is not spoofing:

The example above is a targeted attack, also known as spear-fishing, or whaling. These kind of attacks are usually pinpointing specific, high-value targets.

An email message contains two sender addresses, the 5321.MailFrom (used by a sending mail server to identify the sender, shown in the header as Return-Path) and the 5322.From (the address displayed as the From address by the mail client, shown in the header as From).

The following telnet SMTP transcript shows how the two addresses are defined during the SMTP conversation:


Mail from:  <– 5321.MailFrom

Rcpt to:


To: "Andrew Stobes" <>

From: "Woodgrove Bank Security"  <– 5322.From

Reply-To: "Woodgrove Bank Security" <>

Subject: Woodgrove Bank – Action required

Greetings User,


We need to verify your banking details. Please click the following link to accomplish this.




Thank you,

Woodgrove Bank


When the user receives this message they will see it is from "Woodgrove Bank Security"

Here is what the message would look like in the Outlook client:


SPF was designed to block spoofing, so we usually see this being used as a solution for these problems. It’s not!

As I have explained in my previous post regarding SPF, the SPF check is being performed on the 5321.MailFrom. A spammer will always use a domain that does not have an SPF record published, so the SPF check will most likely fail. More than this, if you configure the ASF option to use Hard-Fail you will most likely get a lot of false-positives from domains that do not have a properly configured SPF record.
Coming back to the SPF check, for the example above, you will probably get something like the following in Office 365:

Received-SPF: None ( domain of

designates as permitted sender);


The other header that records the results of SPF checks are recorded in the Authentication Results:

Authentication-Results: spf=none (sender IP is;;

dkim=none (message not signed) header.d=none;

dmarc=fail action=none;

So, having the two headers above we can see that DMARC failed for this particular message. Since DMARC uses Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to authenticate the 5322.From address, DMARC will pass if an SPF or DKIM check passes and the domain in the 5321.MailFrom and 5322.From addresses match. This means that DMARC will always fail if the domain of the 5321.MailFrom does not match the domain of the 5322.From.

Having this in mind we can block these messages using DMARC. But you will first have to publish a DMARC record that doesn’t reject any email. IN TXT "v=DMARC1; p=none; pct=100"

For more information on DMARC, you can visit Terry’s Blog that has an excellent article regarding this.

Now, that we have the DMARC record, we can create a Transport Rule that is based on the Authentication-Results header, specifically on the DMARC result, to block spoofed messages in Office 365.

The ETR should look something like this:


To make it easier, here is the copy/paste friendly syntax:

Apply this rule if 
    A message header includes…  "Authentication-Results" header includes  "dmarc=fail action=none" 

    The sender is located… Outside the organization 
Do the following… 
    Set the spam confidence level (SCL) to 9

Now, there is a different way to block this, if you do not want to use DMARC. Be warned that this is a dangerous rule if not configured correctly, but it is very effective at blocking spoofing:

GUI Version:

Text version:

Apply this rule if 

    A message header includes…  "from" header includes  "" 
    The sender is located… Outside the organization 
Do the following… 
    Set the spam confidence level (SCL) to 9

That’s the easy part. Now, you will have to add an exception to allow the IPs in your SPF record (not Office 365 ones). This is in case a different company is sending you emails in your name.

You can also have this approached from a different angle, by choosing a different action (instead of SCL:9). You can add a header “X-ETR” with the value “Test” and monitor the messages that are marked with this particular header. You can also use a PowerShell command to see which messages triggered this ETR:

Get-MailDetailTransportRuleReport -TransportRule " Blocking Spoof on From Header" -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) | Sort-Object Date | Select-Object Date, MessageID, SenderAddress, RecipientAddress, Subject, TransportRule -Unique | ft


Comments (24)

  1. T3 says:

    When can we expect DKIM support in EOP so we can fully utilize DMARC?

  2. The feature is currently rolling out from the end of September on all tenants.Currently, the Office 365 Roadmap shows us that the feature is under deployment:

  3. miro says:

    can we apply this rule on exchange 2010 edge server on premise ?

  4. Hi Miro,

    You can follow-up the following TechNet article:

  5. raghav says:

    I tried the 1st Rule. In place of setting SCL to 9 and sending emails to quarantine. However the rule is not working. Have you tested that it works for the header part "dmarc=fail action=none". Kindly confirm.

  6. @Raghav
    the rule should be created only after DMARC was published for that domain (ie:
    The rule is working and it has been implemented already in various environments, but again, it depends on the DMARC verdict.

  7. Mahesh Adate says:

    Hi Caltaru,

    First of all thanks a lot for the valuable article. I have some question regarding SPF & DMARC. We are in a migration process and currently have a hybrid setup. MX record pointed to EOP.

    1. Can we only use SPF without DKIM? What is the recommended way?

    2.If we use SPF, what server IP addresses do we have to include in SPF record. We have 6 on premise EX2010 servers (3 Mailbox, 2 HUBCAS and 1 DR) and two Hybrid servers (EX2013).

    3. Since EOP is already checking incoming DMARC, do we have to setup the rule which you’ve mentioned?

    4.In the rule I can see you have mentioned a particular domain. Will this mark only DMARC failed mails from mentioned domain as spam.

  8. @Mahesh
    1. SPF works without DKIM as well. Nothing to do between the two. You can use this article for configuring SPF:

    2. The same as above. If you are sending emails from Onprem-Internet, you will have to add your public IP address in the SPF record:
    If you are only sending through O365: v=spf1 -all

    3. The rule has to be created if you publish your DMARC with p=none. In this case, EOP does not take any action when DMARC is failing.

    4. You can setup the rule for each vanity domain that you currently own. The rule was an example for one domain so that you can avoid spoofs for that domain. You can also rule out the domain part, but this will get you a lot of false positives, since there
    are many DMARC fails out there 🙂

    Hope it helps!

  9. clab says:

    Hey Caltaru, thanks for this write up. We have SPF and DMARC configured. We do not have DKIM record configured for O365 as it’s still in development, however, we do have a DKIM record configured for mailchimp, an email marketing campaign service. Because
    we have a DKIM record configured for mailchimp and not O365, will this setup cause any problems?

  10. @Caleb
    No, you should be fine with both of them.
    DKIM public key records are stored as DNS text records in ._domainkey.. So for mulitple DKIM, you will have different selector names anyway.

  11. clab says:

    Thanks Caltaru! Any idea when DKIM will be officially supported in O365? Also, on a slight different note, do you know if there is any plans to give the option for admins to bybass Advanced Threat Protection Attachment Scanner based off who the email is
    sent from? For example, at the very least, I don’t need internal to internal email being scanned and taking 5-10min to be delivered. We would also like to be able to bypass ATP for certain senders as well. Any ideas?

  12. @Caleb
    DKIM is already enabled in O365. You can check my post over here:
    Good question regarding Safe Attachments. I will follow-up with the ATP team on this. Currently, you only have the option to scope it based on the recipients.
    To bypass ATP for recipients, you can scope it out to certain groups/domains…etc and the use the exclude option to rule out any users.

  13. jan says:

    Multiple Authentication-Results headers

    Recently I have looked into creating some ETRs similar to this. First of all to log which messages we would catch and filter out.
    Yesterday however, I got an interesting mail that was caught as a false positive.

    Problem turned out to be it had two Authentication-Results headers. One that succeeded (in this case on SPF) and one that had failed. Our mail system had received it from a permitted sender, and therefore it ought to pass. The rule I have is looking for spf=fail
    in Authentication-Results, and even though the most recent Authentication-Results header said pass it was caught.

    Question is, is it possible to make an ETR check the most recent header?
    As the oldest one was added before it came to our mailsystem, it cannot be trusted anyway.

    How did it get two Authentication-Results headers: The mail was sent from one O365 customer to another. The sending customer is using Crossware to add a signature, therefore mail is first sent to Crossware, then back to sending customers tenent (I believe).
    O365 adds the first Authentication-Results header and as Crossware is not a permitted sender for that domain spf failed.
    Next mail was sent from their tenant to mine. O365 is a permited sender and therefore second Authentication-Results header had spf=pass.

  14. @Jan
    You should not get two Auth-Results headers.
    As you have described the issue, the configuration on the sending tenant is not supported. Why? This is simple: basically, the message is sent to Crossware and then relayed back to O365. Crossware, in this case will have to deliver the message to the MX and
    not relaying back to O365.
    As you have noticed, this is the reason of you getting two Auth-Result headers.
    Hope it helps!

  15. clab says:

    Hey Caltaru – We have implemented DKIM and that is working successful, thanks for your write up. Have you heard back from the ATP regarding additional scoping options for safe attachments?

  16. @Caleb:
    There is nothing planned for the moment in this direction. Following general security policies, we have decided to block everything and then start to subtract. You will then be able to block domains that you are not aware of (ie: fake/spam domains) and also
    bypass the ones you consider safe. You also have the option of scoping the policy to specific recipients.

  17. Oli says:

    Thanks so much, I have spent a significant amount of time trying to get SPF records to work and stop people from being able to spoof customers domains and in five minutes of reading this article I had a working solution!

  18. anonymouscommenter says:

    2016 is already here and we have some new and exciting features in EOP. Right now, these features are

  19. Speedy says:

    I was just told by O365 support that: “… Even if you add 3rd party external server’s IP address in your domain’s SPF record, those emails will still be considered as external emails …”
    And that your rule under Option#2, should be like this:
    Apply this rule if
    A message header includes. “from” header includes “”
    The sender is located. Outside the organization
    Do the following.
    Set the spam confidence level (SCL) to 9
    Except if…
    The sender .Senders IP is in the range. Add the outbound IP of the external servers in the list

    Your thoughts?

    1. @Speedy: The external part is referring to the unauthenticated emails coming in O365. This is why “Outside the organization” actually means. So, as mentioned in the article, you have to specify exceptions for the 2nd ETR. The safest bet is to add the exception as a specific header found in the email, based on the connecting IP.

      1. Speedy says:

        In the article you said “…Now, you will have to add an exception to allow the IPs in your SPF record…”. So where do we specify the 3rd party external server’s IP addresses, in the SPF record or in the rule ?

  20. CS says:

    Apply this rule if

    A message header includes… “from” header includes “”

    May I know if the @ is crucial for this condition to work? Thank you.


Skip to main content