Freigeben über

How antispoofing protection works in Office 365

  • Artikel

Update: This blog post is being deprecated and information has been moved to docs.microsoft.com: Antispoofing protection in Office 365

Exchange Online Protection (EOP), the email filtering component of Office 365, is rolling out, or has already rolled out, full antispoof protection for all of its customers. Most of our customers already have this protection, and now we are preparing to roll it out to everyone else.

[tzink 2016.11.03 - This is rolled out for everyone]

What is the spoofing problem EOP is solving?

Over the past several months, EOP (along with the rest of the industry) has seen a massive increase in targeted spear phishing attacks where the attacker spoofs an employee high up in the organization such as the CEO, and emails another high ranking employee such as the CFO, asking them to perform a wire transfer, or similar behavior. There are no attachments or links in the message, only regular language instructions asking the target to comply with the demands.

For example:

 From:  Rudy Bosive (the CEO) <rudy@woodgrovebank.com>
 To:  Tom Amtir (the CFO) <tom@woodgrovebank.com>
 Subject:  Can you make this wire transfer for me? 

Tom, we just closed on an acquisition of a new service but we’re trying to keep it quiet. 
Could you wire over $50,000 to them? The account number is below and we need to get this 
taken care of today.

Thanks.

Rudy

Sent from Outlook for iPhone

These types of messages are sent in low volume, and contain language that is grammatically correct without spelling errors, but are fraudulent. They also can cause a lot of financial damage to an organization if the targeted recipient is not aware that the message is malicious.

EOP already has antispoofing technology including SPF, DKIM, and DMARC [1]. However, many organizations don’t have either the expertise or resources needed to set these up or maintain them. Yet, they still need antispoofing protection – these types of messages must be detected and users protected even if you don’t have the required authentication records published.

This Exact DomainSpear Phishing Protection (aka, Business Email Compromise) is the new feature that EOP has rolled out for many of its existing customers, and will roll out for the rest over the next few weeks – the detection of spoofing for your domain even without the standard SPF, DKIM, or DMARC records.

You don’t have to do anything to receive this protection, you get it for free automatically. Furthermore, you can customize it to make it more or less strict by permitting others to send on your behalf.

 

How is EOP solving it?

First, EOP checks to see if the message is destined to your organization and comes from any of your provisioned domains, or a subdomain of any of your provisioned domains. For example, any of these may be potential spoofs:

 From:  Rudy Bosive (the CEO) <rudy@woodgrovebank.com>
To:  Tom Amtir (the CFO) <tom@woodgrovebank.com> 

From:  Rudy Bosive (the CEO) <rudy@foo.woodgrovebank.com>
To:  Tom Amtir (the CFO) <tom@woodgrovebank.com>

From:  Rudy Bosive (the CEO) <rudy@woodgrovebank.com>
To:  Tom Amtir (the CFO) <tom@bar.woodgrovebank.com>

From:  Rudy Bosive (the CEO) <rudy@foo.woodgrovebank.com>
To:  Tom Amtir (the CFO) <tom@bar.woodgrovebank.com>

If the From and To domains align, EOP checks to see if the message is legitimate. Is it a message that originated internally within the organization? That’s okay. Are they authorized to send email on your behalf? That’s also okay. Is it a known good bulk sender? That’s okay. EOP also uses the sending domain reputation (or lack of reputation), sending IP reputation, recipient reputation (how many messages do you receive from this sender? how is your email routed through the EOP service?), and also makes use of machine learning.

EOP uses of all of this data to make sure that the service marks malicious email as spoofs, and not any legitimate email. 2015_02_23_Antispoofing_infographic

How to tell if EOP thinks a message is a spoof

When EOP thinks a message “from” your domain to any of your domains is a spoof, it marks it as spam and adds the following header:

X-Microsoft-Antispam: …;SFTY:9.5

The X-Microsoft-Antispam header is already used by EOP to indicate various other spam filtering components. The SFTY:9.5 or SFTY:9.11 refers to the Safety Level of a message. This header property has other values but are reserved for internal use by EOP.

You can double check this by looking at the From: address and the To: address. Both domains will be the same, subdomains of each other, or part of your Accepted-Domains.

By the end of the second quarter of 2016, EOP will start adding Safety Tips to the message. Safety Tips are visual indicators letting you know that the message is fraudulent or may be a phishing scam. These Safety Tips are viewable when using Outlook on the web to view your email. image

How much email will be marked as spam because of this change?

Note: This is an upcoming feature and is not yet available as of Feb 22, 2016

In order to view how much email this feature marks as spam, EOP will also give you the ability to see who is sending email with your domain in the 5322.From header (the one that shows up in the email client) to your organization’s domains. For example, suppose you had all of the following domains provisioned:

contoso.com
fabrikam.com
woodgrovebank.com

This report would tell you all combinations of:

From: To:
contoso.com contoso.com
contoso.com foo.contoso.com
contoso.com fabrikam.com
foo.contoso.com bar.woodgrovebank.com

And so forth.

To view this report using Powershell (note: the *-PhishFilterPolicycmdlets are only available if you have purchased the E5 license or the Advanced Threat Protection license):

  1. Connect to Exchange Online using Powershell

  • Run the following cmdlet:Get-PhishFilterPolicy –SpoofAllowBlockList | Export-CSV "SpoofingSenders.csv" Or, to get more details:

    Get-PhishFilterPolicy –SpoofAllowBlockList –Detailed | Export-CSV "DetailedSpoofingSenders.csv"This cmdlet will export all data sending to your organization over the past 30 days.

  • Open and review the downloaded *.csv file. The column names are detailed below, with the ones that will be marked as spam bolded in purple:

    Column Description  
    PSComputerName Used internally by EOP
    RunspaceId Used internally by EOP
    PsShowComputerName Used internally by EOP
    True Sender The organizational domain of the PTR record of the sending IP address that is spoofing your organization. If no domain is found, the sender IP is shown.
    Mail Volume Number of messages sent to your organization from this sender in the past 30 days
    User Complaints Number of junk submissions from your users corresponding to this sender in the past 30 days
    Allowed to Spoof Indicates whether this entity is allowed to spoof your organization. There are 3 possible values:Yes: All spoofed addresses from this spoofing sender will be allowed to spoof your organizationNo: No spoofed addresses from this spoofing sender will be allowed to spoof your organization. Messages from this sender will be marked as spam when the feature is enabled. Partial: Some spoofed addresses from this spoofing sender will be allowed to spoof your organization, the rest will be marked as spam. Add –Detailed parameter to see the specific addresses.
    Spoofed Sender(only included with–Detailed parameter) The visible spoofed sender that the message appears to be sent from (in the From: address in your email client, also known has the header.from)
    Authentication Result (only included with –Detailed parameter) This shows Passed if the sender passed EOP sender authentication checks (such as SPF or DKIM), Failed if the sender failed EOP sender authentication checks, or Unknown if the result is not known
    Source of Allowed to Spoof (only included with –Detailed parameter) Indicates if the Allowed to Spoof verdict was automatically determined by the phish filter or set by the administrator.

 

Integration with the Office 365 Admin Portal is not available at this time, but will be by the end of Q2 2016. When that occurs, this blog post will be updated.

How can you exclude certain senders from being marked as spam?

Even though EOP attempts to exclude all legitimate senders from being marked as spam, it is possible that the service does not have enough history to make that determination.  This can happen if a new sender starts sending email as you, or the volume of email is too small to generate a positive reputation, or the sender comes a set of IPs that are known to send spam or phish. EOP does self-correct in cases where it has enough data to make a decision, but other corner cases may continue to be marked as spam.

To eliminate the chance of false positives, we recommend administrators use one of the following four options to exclude senders from being marked spam by our antispoofing filter:

1. Add the sender’s IP addresses to your SPF record, or have them authenticate with DKIM

You can use either SPF or DKIM to have a 3rd party send email on your behalf (see note [2] at the end of this blog post for examples). However, it's not sufficient for a message to simply pass SPF or DKIM; the domain in the From: address must align with the domain that passed SPF or DKIM (either be an exact match, or be a sub-domain).

Whichever method you choose, or ideally picking both methods, this will allow EOP to authenticate emails from these 3rd party services sending as your domain to your domain.

However, it also allows others (for example, Yahoo, Gmail, Comcast, and so forth) to verify email to them sending as you. This is beneficial because it allows your customers to build trust with your domain no matter where their mailbox is located, and at the same time EOP will not mark a message a spam due to spoofing because it passes authentication of your domain.

Advanced users: For more information on getting SPF records to work around the 10 DNS lookup limit, and automating your SPF records, see the blog post Email authentication should work out of the box and we should not rely upon domain owners to do it themselves.

2. Use the spoof policy in Powershell or UX in the Exchange Admin Center to exclude the sending IP address from Antispoofing enforcement

This functionality is not yet available as of Feb 22, 2016 but will be released by the end of Q2 2016.

Alternatively, if you want to permit various senders to send email on your behalf to your domain (but still undergo spam filtering), you can explicitly set this up.

To allow a specific IP address to send email as your domain to your domains using Powershell (this is only available if you have an E5 license or you have purchased an Advanced Threat Protection license):

a) Connect to Exchange Online using Powershell

b) Download the spoofed senders list, as above, with either basic or detailed view.

Get-PhishFilterPolicy –SpoofAllowBlockList | Export-CSV "SpoofingSenders.csv"

Or

Get-PhishFilterPolicy –SpoofAllowBlockList –Detailed | Export-CSV "SpoofingSenders.csv"

 

c) Open up your favorite text editor (such as Notepad or Notepad++) and look for the IPs you want to specify overrides and type either Yes or No in the Allowed to Spoof column.

- Specifying ‘Yes’ in the Standard view will allow all detected sender addresses from that IP address to send as your domain. Specifying ‘No’ will prevent it (that is, if EOP may believe it is a good sender but you can override it). Future sender addresses detected by the phish filter may or may not be blocked or allowed

- Specifying ‘Yes’ or ‘No’ in the Detailed view will allow or block the detected sender address from the true sender sender spoofing your domain.

- If there are spoofing senders you would like to proactively allow or block that do not currently appear in the Detailed view, you can specify the “True Sender”, “Spoofed Sender”, and the “Allowed to Spoof” verdict.

Save the file with a new name UpdatedSpoofingSenders.csv.

d) Update the changes you made in the "Allowed to Spoof" column by running the following two commands in this order:

$UpdatedSpoofingSenders=Get-Content -Raw UpdatedSpoofingSenders.csv

Set-PhishFilterPolicy –SpoofAllowBlockList $UpdatedSpoofingSenders

Senders who you did not allow will be blocked.

e) To verify your changes:

Get-PhishFilterPolicy –SpoofAllowBlockList

Or

Get-PhishFilterPolicy –SpoofAllowBlockList –Detailed

Integration with the Office 365 Admin Portal is not available at this time, but will be later on in 2016. When that occurs, this blog post will be updated.

Bonus: Office 365 is planning to give you insights into Intelligence Data. This encompasses a whole range of signals from our various platforms. These spoofing senders – many of whom are malicious – will in this Intelligence Data set. It is not the only set of signals we will provide, but is an important one. This Intelligence Data will be available later this year (2016).

3. Add the sender’s IP address to an IP Allow List in the Exchange Admin Center

Alternatively, if you don’t want to add the sender’s IP addresses to your SPF record but also don’t want email to be marked as spam due to spoofing, you can add the IP or IPs to your IP Allow List. This will skip any spam filtering from these IP addresses and mark the message as SCL –1, which delivers the message to your inbox unless an Exchange Transport Rule (ETR) deletes or quarantines the message.

 

If a message bypasses filtering due to an IP Allow list entry, you will see the following properties inserted into a header in the message:

X-Forefront-Antispam-Report: IPV:CAL;…SFV:SKN;…SCL:-1

The IPV:CAL means “IP Filtering Verdict: Customer Allow List”.

For more information on managing IP Allow lists, see Configuring the connection filter policy in EOP.

4. Add the sender’s IP addresses plus sending domain to an Exchange Transport Rule (ETR) which bypasses filtering

Alternatively, if you don’t want to skip filtering on all email from a specific set of IP addresses into your organization because those IPs are shared by more than just your domain, you can create an ETR. The ETR should look for a combination of sending IP addresses and a sending domain. You should never create an ETR that only looks for your domain because this can be easily exploited by spammers.

The ETR syntax should be:

 Name: Antispoofing Allow rule to bypass filtering

If the message…
 sender ip addresses belong to one of these ranges: ‘1.2.3.0/24’
 and sender’s address domain portion belongs to any of these domains: ‘contoso.com’

Do the following…
 Set the spam confidence level (SCL) to ‘-1’
 and set the header ‘X-ETR’ with the value ‘Antispoofing allow rule set SCL –1’

You can add as many IP addresses as you want to the rule, you can add other domains to protect, you can modify the text of the header to stamp to make it more descriptive, and you can even specify Exceptions to the rule.

The result is that email from these IP ranges sending email as your domain will bypass spam filtering and get delivered to your users’ inboxes except if the user has the sender on their personal Blocked Sender list, and there are not other ETRs running at higher priority than this rule that take action on the message (for example, a rule that sends email to the Admin Quarantine).

If a message bypasses filtering due to an ETR like the above, you will see the following header inserted into the message:

X-Forefront-Antispam-Report: SFV:SKN;…SCL:-1
X-ETR: Antispoofing allow rule set SCL -1

For more information on ETRs, see

Managing Transport Rules.

Once the Allow/Block functionality above is released, you don’t need to do this ETR and instead should use that.

Remember – is important to never, ever allow only your domain in an ETR by itself with no other criteria. If you do, a spammer can spoof your domain and it will get a free pass to the inbox.

Can antispoofing protection be turned off?

No, antispoofing protection cannot be disabled.

Instead, if you get false positives, you should use any of the workarounds above to bypass filtering for these senders. This ensures that rather than leaving you exposed to phishing messages, you instead block the most dangerous types of spoofs and allow in only authorized senders.

EOP has done a great job at minimizing potential false positives and so this change will cause minimal disruption to legitimate mailflow.

Is there anything else I should know about?

Yes.

  1. In order to get full antispoofing protection, your domain’s MX record must point to EOP as its primary MX record. If it does not, antispoof protection will not be implemented for your domain.
    .
  2. Antispoof protection does not override IP Allow rules, ETR allow rules, or end user safe senders, all of which bypass spam filtering. This may change in the future.

What about mailing lists?

Mailing lists are the instances where you are most likely to see false positives. This is because of the way the message is routed:

Office 365 customer (on-prem or fully hosted) -> Office 365 -> out to mailing list (passes SPF, DKIM, DMARC) -> back to Office 365 (passes SPF, but original DKIM fails, and DMARC would fail, too)

When the message is replayed back to Office 365, if the message has been modified in transit (e.g., the subject line has been changed to put [Topic] in it, or a footer has been added with unsubscribe information), this will pass SPF (because the list's SPF check passes) but fail our antispoofing checks. This is a known problem with mailing lists even with DMARC.

The industry solution is a new standard called the Authentication Received Chain, or ARC. This is a way to pass authentication results securely between mail servers. However, ARC is still a few months away.

For customers, you should do the following:

a) Make sure you are signing with DKIM -> this will fix issues where email is not modified, but not where email is intentionally modified

b) Use one of the above workarounds - either an IP allow for the mailing list, or an ETR allow based upon the sending IP + sending domain OR an ETR based upon the sending domain (of the mailing list) + 'Authentication-Results' header contains 'spf=pass'

c) You can also open up a support ticket with us. We're working on inventorying mailing lists to exclude them from antispoofing checks. If you do that, you won't need to do (b). When ARC is released, and if you control the mail server, it will also help in delivery.

Conclusion

These changes to EOP’s spam filtering will help protect your organization from some of the most malicious phishing messages that we see today. The feature is intended to minimize any false positives while also giving you the ability override the filter decisions when necessary.

As always, let us know how it works for you so we can continue to improve it!

Footnotes

[1] EOP supports DMARC for inbound email, which is a technology to stop spoofing of the From: domain. The main difference between DMARC and EOP’s Antispoofing solution is that DMARC requires certain DNS records to be published, whereas EOP’s Antispoofing solution does not. The second difference is that DMARC sends failure reports back to the forensic and aggregate reporting email addresses, whereas for EOP’s Antispoofing that information is only available via Powershell or through the Exchange Admin Center.

For more information, see these blog posts:

[2] For setting up 3rd party services to send on your behalf (as your domain) and have it authenticate using the regular antispam authentication methods:

a) SPF Authentication

If you are sending from an on-premise mail server, or a cloud-hosted service, and you have a dedicated IP address, you should add them to your SPF record. For example, before updating your SPF record, it might look like this:

contoso.com IN TXT "v=spf1 include:spf.protection.outlook.com –all"

After adding the dedicated IP address (or CIDR address range), your SPF record might look like this:

contoso.com IN TXT "v=spf1 include:spf.protection.outlook.com ip4:1.2.3.4 –all"

If you are using a larger service like a bulk email service provider or software-as-a-service provider, they may ask you to include all of their servers which is much more manageable:

contoso.com IN TXT "v=spf1 include:spf.protection.outlook.com ip4:1.2.3.4 include:bulkEmailProvider.com –all"

If you do this, your email that sends as you from this service will now authenticate with SPF.

For more information:

b) DKIM authentication

Some bulk email service providers, or software-as-a-service providers, let you set up DKIM keys for email originating out of their service. This requires co-ordination between yourself and them to set up the necessary DNS records, and it is dependent on the organization. This is also a useful method for email authentication.
The message might look like the following:

Return-Path: <communication@bulkemailprovider.com>
From: <sender@contoso.com>
DKIM-Signature: s=s1024; d=contoso.com
Subject: Here is a message from Bulk Email Provider’s infrastructure, but with a DKIM signature authorized by contoso.com

In this example, Bulk Email Provider gave Contoso a public DKIM key to publish in their DNS record, and then signs with the corresponding private key when sending email and putting the resultant DKIM signature into the message. Third parties can then authenticate against the DKIM d= domain and compare it to the domain in the From: address.

For more information:

* * * * * *

With either SPF or DKIM, when sending to EOP, a header is inserted into the message with the authentication results, and either the smtp.mailfrom or the header.d should match the domain in the header.from. In this case, contoso.com in the header.d in the DKIM-Signature header aligns with the domain in the From: address. In the absence of a DMARC record, EOP stamps dmarc=bestguesspass.

Authentication-Results: spf=pass (sender IP is 1.2.3.4)
smtp.mailfrom=bulkemailprovider.com; contoso.com; dkim=pass
(signature was verified) header.d=contoso.com; dmarc=bestguesspass
action=none header.from=contoso.com;

Comments

  • Anonymous
    February 23, 2016
    Great news! Will the previously recommended ETR for DMARC check be redundant with the improved antispoofing protection or do you still recommend using that? Best regards, Anders

  • Anonymous
    February 23, 2016
    @Anders: The previous ETR for DMARC is redundant, you don't need both. This feature does implicitly what that ETR for DMARC did explicitly.

  • Anonymous
    February 23, 2016
    When can we expect the safety tips to make their way into Outlook proper?

  • Anonymous
    February 24, 2016
    This is really good news. However just wanted to let you know that the previous DMARC and Transport rule combination that you suggested was giving lot of false positive in the form of OOF/Automatic replies and email from Postmater. I have a ticket open with Microsoft T3. And so far i understand that it is due to header Return-path:<>. Not sure how much true. Have you tested that in your environment.

  • Anonymous
    February 24, 2016
    Safety Tips look interesting. When you say, "These Safety Tips are viewable when using Outlook on the web to view your email" does that mean they won't show in Outlook 2013/2016?

  • Anonymous
    February 24, 2016
    The comment has been removed

  • Anonymous
    February 24, 2016
    Phishing emails when sender is pretending to be from domain are not even "that" bad. Properly implemented DMARC rule deals with a great majority of it. The real issue starts when the email looks like this: From: Rudy Bosive (the CEO) <secure.smtp.relay@gmail.com> or From: Rudy Bosive (the CEO) <ceo.office@outlook.com> or Some other combination with multiple addresses in the 'display' part of the address, or combinations of the 'on behalf' emails. (all of these are real examples) Sometimes people just don't look at the address. They get an email from the CEO, they get stressed and do weird things. Since these emails come from 'valid' existing accounts, they pass all the checks (SPF, DMARC, DKIM). These are the ones that are hard to deal with. As for the feature itself, it is great that you are doing this. I imagine some organizations do not have time/resources/knowledge to do that themselves and will benefit from this. And one tiny tip. Calendar invitations forwarded in Outlook have incorrect headers (From: and Sender: headers are switched). These emails always fail DMARC and they look like spoofing when checking the headers. You might want to investigate these, (or better make the Outlook team fix that). We had to exclude them from our DMARC rule. I was also wondering when will Microsoft publish DMARC record for onmicrosoft.com domain ? At least the 'None' record would be very useful. Spam/phising using the onmicrosoft.com domain is real.

    • Anonymous
      May 19, 2016
      I agree with @Grzegorz Wierzbicki. It's easy to spoof an employee name and email signature, the domain name could be anything. The UI view on the web or Outlook show the first name and last name so at a quick glance you think this is your co-worker and if the verbiage and signature in the email are business as usual you may not think to look at the message headers. What I would like to see is something similar to EV SSL. If the email is internal it has a green bar. If the email first name or last name matches a regex compare on any employee name and it's not from your domain it's a red bar. You should be able to mark the red's as safe senders only if their domain has SPF / DKIM.
      • Anonymous
        August 04, 2017
        Agree with these two . The real threat is people from an external domain (often gmail) copying the display name only. These are not phishing but impersonating. Some third party mail filters are capable of stopping this (eg Mimecast Impersonation Protect) but it would be great to have this function in O365 or ATP. I've seen a banner saying "you don't receive email from "joe.bloggs@gmail.com" very often" which would do the trick, or the green / red banner for internal / external emails.

  • Anonymous
    February 25, 2016
    This information is really useful...

  • Anonymous
    June 22, 2016
    Hi Terry,Can you please let us know if the deployment of "Exact Domain Spear Phishing Protection" has been started worldwide? If yes, by when the deployment of this new feature expected to complete. Currently, we don't see the cmdlet "Set-PhishFilterPolicy" for our tenant. Also can you please explain the backend processing/logic behind of/the "Exact Domain Spear Phishing Protection"?

    • Anonymous
      June 23, 2016
      Your domain should already be enabled for this protection. We rolled it out to everyone except a handful of very large customer domains with complex configurations.The Set-PhishFilterPolicy may be reserved for Advanced Threat Protection customers only.
      • Anonymous
        July 20, 2016
        Hi Terry,Thanks for your reply.I have E5 license enabled and I am a global administrator. However, I can't see any of the phishfilter cmdlet. I have also created ticket with MS but they have directed me to you.Please suggest me on this.
      • Anonymous
        July 21, 2016
        Hi Terry,Thanks for your reply. I have enabled E5 license for myself and I am a global admin from my tenant. However, my tenant o365 module still doesn't have get-phishfilterpolicy. I have also reached MS in this regards and they have directed me to you. Can you please help me out?
        • Anonymous
          July 25, 2016
          It's not out yet, there's a bug that we need to fix that is preventing global deployment. It should be ready soon.
          • Anonymous
            July 26, 2016
            Thanks for confirming! Appreciate it!Regards,KMT
          • Anonymous
            September 06, 2016
            Hi Terry, do you have any updates on the rollout of Exact Domain Spear Phishing Protection? We are an E4 customer running hybrid on-premises + Office365, transitioning to EOP. SPF and DKIM are already set up. It appears that the former is not yet operative?
            • Anonymous
              September 07, 2016
              It should be, it rolled out several months ago. If it isn't working please open a support ticket.

  • Anonymous
    June 30, 2016
    The comment has been removed

  • Anonymous
    July 20, 2016
    Yet we still get inbound malware triggering outbound malware alerts. The messages are spoofed.

  • Anonymous
    September 01, 2016
    How do you measure reputation? Is it internal calculation or you use 3rd party like Bordarware and Senderbase?

    • Anonymous
      September 01, 2016
      We use a variety of sources - some third party, some is our own that we maintain internally. The two sites you mention are not used.
    • Anonymous
      September 28, 2016
      It's all determined internally with a combination of data from Outlook.com, Office 365, and some manual heuristics.

  • Anonymous
    October 10, 2016
    The comment has been removed

    • Anonymous
      October 10, 2016
      Yes, those settings have been in Outlook for a long time and they are on by default. I personally turn them off, as I talk about here: https://blogs.msdn.microsoft.com/tzink/2015/11/18/how-i-personally-use-outlook-with-office-365/Turning them off by default requires careful planning, because not everyone uses Office 365 with Outlook. Some use Exchange, and others use 3rd party services like Yahoo Mail or Gmail. If we turn these settings off by default for Outlook, we first need to understand what the future impact will be on those other services.

  • Anonymous
    October 11, 2016
    The comment has been removed

    • Anonymous
      October 11, 2016
      The Exact-Domain spear phishing protection executes when the domain in the From: address matches (or aligns with) the recipient domain. Your example above is hard to troubleshoot without posting the Authentication-Results header, and you've also posted a partial snippet of the X-Forefront-Antispam-Report header. Without those two it's hard to see what is going on. Usually if the From==To, and the message still gets through, it's due to user or admin configuration. This is stamped in the headers in clear text, see https://technet.microsoft.com/en-us/library/dn205071(v=exchg.150).aspx.
      • Anonymous
        October 12, 2016
        The comment has been removed
        • Anonymous
          October 12, 2016
          I realise it isn't your job to troubleshoot my exact issue, so I've raised it with Office 365 and referred to this page in the service call. However, it may be helpful to others if you could clarify whether all Office 365 users are getting the Exact Domain Spear Phishing protection, and if not, what to do about it.
          • Anonymous
            October 12, 2016
            Replacing your domain with example.com and dmarcian.com makes it harder for me to troubleshoot. But:a) Your domain has antispoofing enabledb) Looks like this was sent from a bulk sender (mandrillapp.com), that may be used by our system to override the antispoofing since it's common for many of our customers to use that service but not add them to their SPF record.

  • Anonymous
    October 21, 2016
    Hi,a customer was attacked and received a fake email.sender_address: dhaval@dhavalgroup.comreturn_path: johnthangpham@deltaexports.usoriginal_client_ip: 173.201.192.164The question is, how to prevent not to receive these fake emails?Some transport rule would help?Thank you.

    • Anonymous
      October 26, 2016
      If the From/To domains are the same the antispoofing protection should work (per this blog post) unless the end user or admin has an override to allow the message through.

  • Anonymous
    October 28, 2016
    We are new to O365 and interested in this protection. The article says it will be in place for all users by end of Q2, 2016, yet the PhishFilterPolicy Cmdlets don't appear to exist for us. Is this feature active?

    • Anonymous
      October 28, 2016
      Sorry for the delay, it's still rolling out.

  • Anonymous
    November 16, 2016
    Hi Terry,Checking in for “Get-PhishFilterPolicy" and "Set-PhishFilterPolicy" cmdlet enabling. We are almost half-way through FY17. But I still don't see "Get-PhishFilterPolicy" cmdlet populating for our tenant.Our tenant have E5 license.Can you please let us know when can we expect the deployment of "Exact Domain Spear Phishing Protection” for our tenant.Regards,Akshara M

    • Anonymous
      November 16, 2016
      Should roll out over the next few weeks. We made a change last week to enable this network-wide, and builds take a few weeks to deploy.
      • Anonymous
        January 08, 2017
        The comment has been removed
        • Anonymous
          January 09, 2017
          It should be rolled out, if you can't get it to work please open a support ticket. Just remember it's only for ATP and E5 customers.

  • Anonymous
    December 05, 2016
    Terry -Outside of manually setting "Allow to Spoof" to yes on the Get-PhishFilterPolicy listings, is there any other mechanism in place that's enabling "Allow to Spoof" for some senders and not others? We've got 1400+ "Yes" hosts and around 530 "No" hosts, but we aren't doing anything to change these attributes, so I'm guessing EOP is using it's own calculus for determining what hosts are allowed to Spoof and which ones aren't, even though all hosts have a 'Failed' Authentication result. Can you shed some light on this? Does EOP automatically update those values periodically?

    • Anonymous
      December 05, 2016
      EOP does keep track of its own list of whose allowed to spoof and who is not, but doesn't update the Get-PhishFilterPolicy AllowedToSpoof entries. Some of this list is network-wide overrides, others are just for your domain. You will still see the message fail authentication (in the Authentication-Results header, or perhaps have no authentication result) but not necessarily get marked as spam.Specifying the AllowedToSpoof is for adding a few more senders that EOP missed.

  • Anonymous
    December 16, 2016
    Hi,I have a question. Would it not actually be easier for a spammer to spoof emails if you used an SPF as its kind of advertising what services you are using? What if you used an SPF and used a third party product to send messages from your domain, could a spammer not work out what the service was, sign up for that service and theoretically spoof your users?

    • Anonymous
      December 16, 2016
      Presumably, you would only use services that don't let others sign up and use your domain to send out spam.

  • Anonymous
    January 09, 2017
    An informative read, thanks! A quick question: will Office365 cloud-wide policies prevent a mail server for domain A residing in one subnet listed in the security.outlook.com SPF "tree" be denied mailing on behalf of domain B residing in another listed subnet? By including the security.outlook.com SPF record, of course, that would be a "no" (I should think?) as the SPF check hits a permitted network and returns okay, but I'd assume there was some mechanism in place at the cloud level to keep track of these things.

    • Anonymous
      January 09, 2017
      No, there's nothing that prevents that.However, we are clamping down on the ability for organizations to send from domains that they have not provisioned. That is supposed to go out in Feb 2017 (i.e., next month). That would alleviate the need to do what you have suggested above.
      • Anonymous
        January 10, 2017
        That's quite interesting - please let us know when it rolls out so we can take a look at the details! Thank you for taking the effort to maintain this very useful blog.
      • Anonymous
        March 24, 2017
        This appears to affect the use of web based systems, we are suffering at the moment. We use docebo as an LMS and wish to have emails sent from the LMS to the students using our Office tenant domain. So we did not provision (and never could) the originating domain as it is a web service hosted on a cloud infrastructure.Any advice as this only appears to have started recently, related to your Feb 2017 release?

  • Anonymous
    March 08, 2017
    I have a client on office 365, and the very close to the example of the CEO, contacting the CFO occurred and was not prevented by Office 365 and this occurred in February 2017. Looking at the sender it the originating message came from a GODADDY server, and the SPAM score in the header read -1. Which indicates trusted sender or trusted something... I am concerned that the GoDaddy server might also be hosting Office365 services and might have been considered a "trusted" sender and was not checked for SPAM/Spoofing... Who can I talk to about this? I have tried calling a number of people and they all seem to pass the buck.

  • Anonymous
    July 05, 2017
    This was a very interesting read.Thanks for sharing this.

  • Anonymous
    August 09, 2017
    Working with customers who use O365 services. These customers have 3rd party services for different apects and spf records reflect this. Even though the messages pass this they fail this feature and see the safety tip associated with their email whether it comes to them from the 3rd party or forwarded back by another account. Customers are looking for a way to bypass the safety tips for these messages that come from specific senders. Is there a way to use transport rules to eliminate this tip from appearing?

  • Anonymous
    October 02, 2017
    Well, it's October of 2017 and I am still getting spoofing emails pretending to come from outlook.com on my Office365 account.This never happens on our Gmail accounts. I am really disappointed at Microsoft over their terrible spam and phishing filters. MICROSOFT, FIX THIS !!

  • Anonymous
    December 07, 2017
    Thanks for your article, I have done DKIM configuration in my client system, but still my client is getting Spoofing mails on users accounts as well as group mail accounts, we have also configured transport rule but still issue remain same.