Anti-spoofing protection in Office 365

This article describes how Office 365 mitigates against phishing attacks that uses forged sender domains, that is, domains that are spoofed. It accomplishes this by analyzing the messages and blocking the ones that cannot be authenticated using standard email authentication methods, nor other sender reputation techniques. This change is being implemented to reduce the number of phishing attacks customers are exposed to.

This article also describes why this change is being made, how customers can prepare for this change, how to view messages that will be affected, how to report on messages, how to mitigate false positives, as well as how senders to Microsoft should prepare for this change.

Microsoft's anti-spoofing technology is initially deployed to its Office 365 Advanced Threat Protection (ATP) and E5 customers. However, because of the way all of its filters learn from each other, non-ATP customers and even Outlook.com users may also be affected.

How spoofing is used in phishing attacks

When it comes to protecting its users, Microsoft takes the threat of phishing seriously. One of the techniques that spammers and phishers commonly use is spoofing, which is when the sender is forged, and a message appears to originate from someone or somewhere other than the actual source. This technique is often used in phishing campaigns designed to obtain user credentials. Microsoft’s Anti-spoof technology specifically examines forgery of the ‘From: header’ which is the one that shows up in an email client like Outlook. When Microsoft has high confidence that the From: header is spoofed, it identifies the message as a spoof.

Spoofing messages have two negative implications for real life users:

  1. Spoofed messages deceive users

    First, a spoofed message may trick a user into clicking a link and giving up their credentials, downloading malware, or replying to a message with sensitive content (the latter of which is known as Business Email Compromise). For example, the following is a phishing message with a spoofed sender of msoutlook94@service.outlook.com:

    Phishing message impersonating service.outlook.com

    The above did not actually come from service.outlook.com, but instead was spoofed by the phisher to make it look like it did. It is attempting to trick a user into clicking the link within the message.

    The next example is spoofing contoso.com:

    Phishing message - business email compromise

    The message looks legitimate, but in fact is a spoof. This phishing message is a type of Business Email Compromise which is a subcategory of phishing.

  2. Users confuse real messages for fake ones

    Second, spoofed messages create uncertainty for users who know about phishing messages but cannot tell the difference between a real message and spoofed one. For example, the following is an example of an actual password reset from the Microsoft Security account email address:

    Microsoft legitimate password reset

    The above message did come from Microsoft, but at the same time, users are used to getting phishing messages that may trick a user into clicking a link and giving up their credentials, downloading malware, or replying to a message with sensitive content. Because it is difficult to tell the difference between a real password reset and a fake one, many users ignore these messages, report them as spam, or unnecessarily report the messages back to Microsoft as missed phishing scams.

To stop spoofing, the email filtering industry has developed email authentication protocols such as SPF, DKIM, and DMARC. DMARC prevents spoofing examining a message's sender – the one that the user sees in their email client (in the examples above, this is service.outlook.com, outlook.com, and accountprotection.microsoft.com) – with the domain that passed SPF or DKIM. That is, the domain that the user sees has been authenticated and is therefore not spoofed. For a more complete discussion, see the section "Understanding why email authentication is not always enough to stop spoofing" later on in this document.

However, the problem is that email authentication records are optional, not required. Therefore, while domains with strong authentication policies like microsoft.com and skype.com are protected from spoofing, domains that publish weaker authentication policies, or no policy at all, are targets for being spoofed.As of March 2018, only 9% of domains of companies in the Fortune 500 publish strong email authentication policies. The remaining 91% may be spoofed by a phisher, and unless the email filter detects it using another policy, may be delivered to an end user and deceive them:

DMARC policies of Fortune 500 companies

 
The proportion of small-to-medium sized companies that are not in the Fortune 500 that publish strong email authentication policies is smaller, and smaller still for domains that are outside of North America and western Europe.

This is a big problem because while enterprises may not be aware of how email authentication works, phishers do understand and take advantage of the lack of it.

For information on setting up SPF, DKIM, and DMARC, see the section "Customers of Office 365" later on in this document.

Stopping spoofing with implicit email authentication

Because phishing and spear phishing is such a problem, and because of the limited adoption of strong email authentication policies, Microsoft continues to invest in capabilities to protect its customers. Therefore, Microsoft is moving ahead with implicit email authentication ­– if a domain doesn’t authenticate, Microsoft will treat it as if it had published email authentication records and treat it accordingly if it doesn’t pass.

To accomplish this, Microsoft has built numerous extensions to regular email authentication including sender reputation, sender/recipient history, behavioral analysis, and other advanced techniques. A message sent from a domain that doesn’t publish email authentication will be marked as spoof unless it contains other signals to indicate that it is legitimate.

By doing this, end users can have confidence that an email sent to them has not been spoofed, senders can be confident that nobody is impersonating their domain, and customers of Office 365 can offer even better protection such as Impersonation protection.

To see Microsoft’s general announcement, see A Sea of Phish Part 2 - Enhanced Anti-spoofing in Office 365.

Identifying that a message is classified as spoofed

Composite authentication


While SPF, DKIM, and DMARC are all useful by themselves, they don’t communicate enough authentication status in the event a message has no explicit authentication records. Therefore, Microsoft has developed an algorithm that combines multiple signals into a single value called Composite Authentication, or compauth for short. Customers in Office 365 have compauth values stamped into the Authentication-Results header in the message headers.

Authentication-Results:
  compauth=<fail|pass|softpass|none> reason=<yyy>

CompAuth result

Description

fail

Message failed explicit authentication (sending domain published records explicitly in DNS) or implicit authentication (sending domain did not publish records in DNS, so Office 365 interpolated the result as if it had published records)

pass

Message passed explicit authentication (message passed DMARC, or Best Guess Passed DMARC) or implicit authentication with high confidence (sending domain does not publish email authentication records, but Office 365 has strong backend signals to indicate the message is likely legitimate)

softpass

Message passed implicit authentication with low-to-medium confidence (sending domain does not publish email authentication, but Office 365 has backend signals to indicate the message is legitimate but the strength of the signal is weaker)

none

Message did not authenticate (or it did authenticate but did not align), but composite authentication not applied due to sender reputation or other factors

Reason

Description

0xx

Message failed composite authentication.

- 000 means the message failed DMARC with an action of reject or quarantine

- 001 means the message failed implicit email authentication. This means that the sending domain did not have email authentication records published, or if they did, they had a weaker failure policy (SPF soft fail or neutral, DMARC policy of p=none)

All other codes (1xx, 2xx, 3xx, 4xx, 5xx)

Corresponds to various internal codes for why a message passed implicit authentication, or had no authentication but no action was applied

By looking at the headers of a message, an administrator or even an end user can determine how Office 365  arrives at the conclusion that the sender may be spoofed.

Differentiating between different types of spoofing

Microsoft differentiates between two different types of spoofing messages:

Intra-org spoofing

Also known as self-to-self spoofing, this occurs when the domain in the From: address is the same as, or aligns with, the recipient domain (when recipient domain is one of your organization’s Accepted Domains); or, when the domain in the From: address is part of the same organization.

For example, the following has sender and recipient from the same domain (contoso.com). Spaces are inserted into the email address to prevent spambot harvesting on this page):

From: sender @ contoso.com
To: recipient @ contoso.com

The following has the sender and recipient domains aligning with the organizational domain (fabrikam.com):

From: sender @ foo.fabrikam.com
To: recipient @ bar.fabrikam.com

The following sender and recipient domains are different (microsoft.com and bing.com), but they belong to the same organization (that is, both are part of the organization’s Accepted Domains):

From: sender @ microsoft.com
To: recipient @ bing.com

Messages that fail intra-org spoofing contain the following values in the headers:

X-Forefront-Antispam-Report: ...CAT:SPM/HSPM/PHSH;...SFTY:9.11

The CAT is the category of the message, and it is normally stamped as SPM (spam), but occasionally may be HSPM (high confidence spam) or PHISH (phishing) depending upon what other types of patterns occur in the message.

The SFTY is the safety level of the message, the first digit (9) means the message is phishing, and second set of digits after the dot (11) means it is intra-org spoofing

There is no specific reason code for Composite Authentication for intra-org spoofing, that will be stamped later in 2018 (timeline not yet defined).

Cross-domain spoofing

This occurs when the sending domain in the From: address is an external domain to the receiving organization. Messages that fail Composite Authentication due to cross-domain spoofing contain the following values in the headers:

Authentication-Results: … compauth=fail reason=000/001
X-Forefront-Antispam-Report: ...CAT:SPOOF;...SFTY:9.22

In both cases, the following red safety tip is stamped in the message, or an equivalent that is customized to the recipient mailbox’s language:

Red safety tip - fraud detection
 
It’s only by looking at the From: address and knowing what your recipient email is, or by inspecting the email headers, that you can differentiate between intra-org and cross-domain spoofing.

How customers of Office 365 can prepare themselves for the new antispoofing protection

Information for administrators 

As an administrator of an organization in Office 365, there are several key pieces of information you should be aware of.

Understanding why email authentication is not always enough to stop spoofing 

The new antispoofing protection relies upon email authentication (SPF, DKIM, and DMARC) to not mark a message as spoofing. A common example is when a sending domain has never published SPF records. If there are no SPF records or they are incorrectly set up, a sent message will be marked as spoofed unless Microsoft has backend intelligence that says the message is legitimate.

For example, prior to antispoofing being deployed, a message may have looked like the following with no SPF record, no DKIM record, and no DMARC record: 

Authentication-Results: spf=none (sender IP is 1.2.3.4)
  smtp.mailfrom=example.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=example.com;
From: sender @ example.com
To: receiver @ contoso.com

After antispoofing, if you are an Advanced Threat Protection or E5 customer, the compauth value is stamped (non-ATP and non-E5 customers are not affected):

Authentication-Results: spf=none (sender IP is 1.2.3.4)
  smtp.mailfrom=example.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=example.com; compauth=fail reason=001
From: sender @ example.com
To: receiver @ contoso.com

If example.com fixed this by setting up an SPF record but not a DKIM record, this would pass composite authentication because the domain that passed SPF aligned with the domain in the From: address: 

Authentication-Results: spf=pass (sender IP is 1.2.3.4)
  smtp.mailfrom=example.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=example.com; compauth=pass reason=109
From: sender @ example.com
To: receiver @ contoso.com

Or, if they set up a DKIM record but not an SPF record, this would also pass composite authentication because the domain in the DKIM-Signature that passed aligned with the domain in the From: address: 

Authentication-Results: spf=none (sender IP is 1.2.3.4)
  smtp.mailfrom=example.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.example.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=example.com; compauth=pass reason=109
From: sender @ example.com
To: receiver @ contoso.com

However, a phisher may also set up SPF and DKIM and sign the message with their own domain, but specify a different domain in the From: address. Neither SPF nor DKIM requires the domain to align with the domain in the From: address, so unless example.com published DMARC records, this would not be marked as a spoof using DMARC: 

Authentication-Results: spf=pass (sender IP is 5.6.7.8)
  smtp.mailfrom=maliciousDomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousDomain.com;
  contoso.com; dmarc=none action=none header.from=example.com;
From: sender @ example.com
To: receiver @ contoso.com

In the email client (Outlook, Outlook on the web, or any other email client), only the From: domain is displayed, not the domain in the SPF or DKIM, and that can mislead the user into thinking the message came from example.com, but actually came from maliciousDomain.com.

Authenticated message but From: domain does not align with what passed SPF or DKIM

For that reason, Office 365 requires that the domain in the From: address aligns with the domain in the SPF or DKIM signature, and if it doesn’t, contains some other internal signals that indicates that the message is legitimate. Otherwise, the message would be a compauth fail. 

Authentication-Results: spf=none (sender IP is 5.6.7.8)
  smtp.mailfrom=maliciousDomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousDomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: sender@contoso.com
To: someone@example.com

Thus, Office 365 antispoofing protects against domains with no authentication, and against domains who set up authentication but mismatch against the domain in the From: address as that is the one that the user sees and believes is the sender of the message. This is true both of domains external to your organization, as well as domains within your organization.

Therefore, if you ever receive a message that failed composite authentication and marked as spoofed, even though the message passed SPF and DKIM, it's because the domain that passed SPF and DKIM are not aligned with the domain in the From: address.

Understanding changes in how spoofed emails are treated

Currently, for all customers of Office 365 – ATP and non-ATP - messages that fail DMARC with a policy of reject or quarantine are marked as spam and usually take the high confidence spam action, or sometimes the regular spam action (depending on whether other spam rules first identify it as spam). Intra-org spoof detections take the regular spam action. This behavior does not need to be enabled, nor can it be disabled.

However, for cross-domain spoofing messages, before this change they would go through regular spam, phish, and malware checks and if other parts of the filter identified them as suspicious, would mark them as spam, phish, or malware respectively. With the new cross-domain spoofing protection, any message that can’t be authenticated will, by default, take the action defined in the Antiphishing > Antispoofing policy. If one is not defined, it will be moved to users Junk Email folder. In some cases, more suspicious messages will also have the red safety tip added to the message.

This may result in some messages that were previously marked as spam still getting marked as spam but will now also have a red safety tip; in other cases, messages that were previously marked as non-spam will start getting marked as spam (CAT:SPOOF) with a red safety tip added. In still other cases, customers that were moving all spam and phish to the quarantine would now see them going to the Junk Mail Folder (this behavior can be change, see Changing your antispoofing settings).

There are multiple different ways a message can be spoofed (see "Differentiating between different types of spoofing" earlier in this document) but as of March 2018 the way Office 365 treats these messages is not yet unified. The below table is a quick summary, with Cross-domain spoofing protection being new behavior:

Type of spoof

Category

Safety tip added?

Applies to

DMARC fail (quarantine or reject)

HSPM (default), may also be SPM or PHSH

No (not yet)

All Office 365 customers, Outlook.com

Self-to-self

SPM

Yes

All Office 365 customers, Outlook.com

Cross-domain

SPOOF

Yes

Office 365 Advanced Threat Protection and E5 customers

Changing your antispoofing settings

To create or update your (cross-domain) antispoofing settings, navigate to the Antiphishing > Antispoofing settings under the Threat Management > Policy tab in the Security and Compliance Center (SCC). If you have never created any Antiphishing settings, you will need to create one:

Antiphishing - create a new policy

If you’ve already created one, you can select it to modify it:

Antiphishing - modify existing policy

Select the policy you just created and proceed through the steps as described on Learn More about Spoof Intelligence.

Antispoofing - modify settings

Antispoofing - modify actions

To create a new policy via PowerShell: 

$org = Get-OrganizationConfig
$name = "My first antiphishing policy for " + $org.Name
# Note: The name should not exclude 64 characters, including spaces.g
# If the name is, you will need to pick a smaller name

# Next, create a new antiphishing policy with the default values
New-AntiphishPolicy -Name $Name

# Select the domains to scope it to
# Multiple domains are specified in a comma-separated list
$domains = "domain1.com, domain2.com, domain3.com"

# Next, create the antiphishing rule, scope it to the anti-phishing rule
New-AntiphishRule -Name $name -AntiphishPolicy $name -RecipientDomainIs $domains

You may then modify the antiphishing policy parameters using PowerShell, following the documentation at Set-AntiphishPolicy. You may specify the $name as a parameter:

Set-AntiphishPolicy -Identity $name <fill in rest of parameters>

Later in 2018, rather than you having to create a default policy, one will be created for you that is scoped to all the recipients in your organization so you don’t have to specify it manually (the screenshots below are subject to change before the final implementation).

Antiphishing with default policy

 
Another change planned for later in 2018 is the option to Enable or Disable antispoofing protection, and choose Basic or High protection (currently you only have the option between Default and Strict, neither of which disables Antispoofing. Default roughly maps to High, Basic has no analogous behavior, and Strict has no analogous behavior either):

Antiphishing with Basic and High
 
Later on in 2018, to set up your default protection via PowerShell:

$defaultAntiphishPolicy = Get-AntiphishingPolicy -IsDefault $true
Set-AntiphishPolicy -Identity $defaultAntiphishPolicy.Name -AntispoofEnforcementType <Basic|High>

You should only disable antispoofing protection if you have another mail server or servers in front of Office 365 (see Legitimate scenarios to disable antispoofing for more details). 

$defaultAntiphishPolicy = Get-AntiphishingPolicy -IsDefault $true
Set-AntiphishPolicy -Identity $defaultAntiphishPolicy.Name -EnableAntispoofEnforcement $false 

Recommendation 
 

If the first hop in your email path is Office 365, and you are getting too many legitimate emails marked as spoof, you should first set up your senders that are allowed to send spoofed email to your domain (see the section "Managing legitimate senders who are sending unauthenticated email").


If you are still getting too many false positives (e.g., legitimate messages marked as spoof), we do NOT recommend disabling antispoofing protection altogether. Instead, we recommend choosing Basic instead of High protection.

It is better to work through false positives than to expose your organization to spoofed email which could end up imposing significantly higher costs in the long term.

Managing legitimate senders who are sending unauthenticated email

Office 365 keeps track of who is sending unauthenticated email to your organization. If the service thinks the sender is not legitimate, it will mark it as a compauth failure. This will be classified as SPOOF although it depends on your antispoofing policy that was applied to the message.

However, as an administrator, you can specify which senders are permitted to send spoofed email, overriding Office 365’s decision.

Method 1 – If your organization owns the domain, set up email authentication

This method can be used to resolve intra-org spoofing, and cross-domain spoofing in cases where you own or interact with multiple tenants. It also helps resolve cross-domain spoofing where you send to other customers within Office 365, and also third parties that are hosted in other providers.

For more details, see the section "Customers of Office 365".

Method 2 – Use Spoof Intelligence to configure permitted senders of unauthenticated email 

You may also use Spoof Intelligence to permit senders to transmit unauthenticated messages to your organization.

For external domains, the spoofed user is the domain in the From address, while the sending infrastructure is either the sending IP address (divided up into /24 CIDR ranges), or the organizational domain of the PTR record (in the screenshot below, the sending IP might be 131.107.18.4 whose PTR record is outbound.mail.protection.outlook.com, and this would show up as outlook.com for the sending infrastructure).

To permit this sender to send unauthenticated email, change the No to a Yes.

Setting up antispoofing allowed senders
You can also use PowerShell to allow specific sender to spoof your domain: 

$file = "C:\My Documents\Summary Spoofed Internal Domains and Senders.csv"
Get-PhishFilterPolicy -Detailed -SpoofAllowBlockList -SpoofType External | Export-CSV $file

Getting spoofed senders via Powershell

In the above image, additional line breaks have been added to make this screenshot fit, but in actuality all the values would appear on a single line.

Edit the file and look for the line that corresponds to outlook.com and bing.com, and change the AllowedToSpoof Entry from No to Yes:

Setting spoof allow to Yes via Powershell
 
Save the file, and then run: 

$UpdateSpoofedSenders = Get-Content -Raw "C:\My Documents\Spoofed Senders.csv"

Set-PhishFilterPolicy -Identity Default -SpoofAllowBlockList $UpdateSpoofedSenders

This will now allow bing.com to send unauthenticated email from *.outlook.com.

Method 3 – Create an allow entry for the sender/recipient pair

You can also choose to bypass all spam filtering for a particular sender. For more details, see How to securely add a sender to an allow list in Office 365.

If you do use this method, it will skip spam and some of the phish filtering, but not malware filtering.

Method 4 – Contact the sender and ask them to set up email authentication

Because of the problem of spam and phishing, Microsoft recommends all senders set up email authentication. If you know an administrator of the sending domain, contact them and request that they set up email authentication records so you do not have to add any overrides. For more information, see "Administrators of domains that are not Office 365 customers" later in this document.

While it may be difficult at first to get sending domains to authenticate, over time, as more and more email filters start junking or even rejecting their email, it will cause them to set up the proper records to ensure better delivery.

Viewing reports of how many messages were marked as spoofed

Once your antispoofing policy is enabled, you can use Threat Intelligence to get numbers around how many messages are marked as phish. To do this, go into the Security and Compliance Center (SCC) under Threat Management > Explorer, set the View to Phish, and group by Sender Domain or Protection Status:

Viewing how many messages are marked as phish

You can interact with the various reports to see how many were marked as phishing, including messages marked as SPOOF. To learn more, see Get started with Office 365 Threat Intelligence.

You cannot yet split out which messages were marked due to spoofing vs other types of phishing (general phishing, domain or user impersonation, etc). However, later in 2018, you will be able to do this through the SCC. Once you do, you can use this report as a starting place to identify sending domains that may be legitimate that are being marked as spoof due to failing authentication.

The below screenshot is a proposal for how this data will look, but may change when released:

Viewing phishing reports by detection type

For non-ATP and E5 customers, these reports will be available later on in 2018 under the Threat Protection Status (TPS) reports, but will be delayed by at least 24 hours. This page will be updated as they are integrated into the Security and Compliance Center.

Predicting how many messages will be marked as spoof

Later in 2018, once Office 365 updates its settings to let you turn the antispoofing enforcement Off, or on with Basic or High enforcement, you will be given the ability to see how message disposition will change at the various settings. That is, if antispoofing is Off, you will be able to see how many messages will be detected as Spoof if you turn to Basic; or, if it’s Basic, you will be able to see how many more messages will be detected as Spoof if you turn it to High.

This feature is currently under development. As more details are defined, this page will be updated both with screenshots of the Security and Compliance Center, and with PowerShell examples.

"What If" report for enabling antispoofing
Possible UX for allowing a spoofed sender

Understanding how spam, phishing, and advanced phishing detections are combined

Exchange Online customers – both ATP and non-ATP – are able to specify the actions to take when the service identifies messages as malware, spam, high confidence spam, phishing, and bulk. However, with the introduction of new Antiphishing policies for ATP customers, and the fact that a message may hit multiple detection types (e.g., Malware, Phishing, and User Impersonation), there may be some confusion as to which policy applies.  

In general, the policy applied to a message is identified in the X-Forefront-Antispam-Report header in the CAT (Category) property. 

Priority

Policy

Category

Where managed?

Applies to

1

Malware

MALW

Malware policy

All customers

2

Phishing

PHSH

Hosted content filter policy

All customers

3

High confidence spam

HSPM

Hosted content filter policy

All customers

4

Spoofing

SPOOF

Antiphishing policy,
Spoof intelligence

ATP only 

5

Spam

SPM

Hosted content filter policy

All customers

6

Bulk

BULK

Hosted content filter policy

All customers

7

Domain Impersonation

DIMP

Antiphishing policy

ATP only 

8

User Impersonation

UIMP

Antiphishing policy

ATP only 

If you have multiple different Antiphishing policies, the one at the highest priority will apply. For example, suppose you have two policies:

Policy

Priority

User/Domain Impersonation

Antispoofing

A

1

On

Off

B

2

Off

On

If a message comes in and is identified as both spoofing and user impersonation, and the same set of users is scoped to Policy A and Policy B, then the message is treated as a spoof but no action is applied since Antispoofing is turned off, and SPOOF runs at a higher priority (4) than User Impersonation (8).

To make other types of phishing policy apply, you will need to adjust the settings of who the various policies are applied to.

Legitimate scenarios to disable antispoofing

Antispoofing better protects customers from phishing attacks, and therefore disabling antispoofing protection is strongly discouraged. By disabling it, you may resolve  some short-term false positives, but long term you will be exposed to more risk. The cost for setting up authentication on the sender side, or making adjustments in the phishing policies, are usually one-time events or require only minimal, periodic maintenance. However, the cost to recover from a phishing attack where data has been exposed, or assets have been compromised is much higher.

For this reason, it is better to work through antispoofing false positives than to disable antispoof protection.

However, there is a legitimate scenario where antispoofing should be disabled, and that is when there are additional mail-filtering products in the message routing, and Office 365 is not the first hop in the email path:
Customer MX record does not point to Office 365

The other server may be an Exchange on-premise mail server, a mail filtering device such as Ironport, or another cloud hosted service.

If the MX record of the recipient domain does not point to Office 365, then there is no need to disable antispoofing because Office 365 looks up your receiving domain’s MX record and suppresses antispoofing if it points to another service. If you don’t know if your domain has another server in front, you can use a website like MX Toolbox to look up the MX record. It might say something like the following:

MX record indicates domain does not point to Office 365

This domain has an MX record that does not point to Office 365, so Office 365 would not apply antispoofing enforcement.

However, if the MX record of the recipient domain does point to Office 365, even though there is another service in front of Office 365, then you should disable antispoofing. The most common example is through the use of a recipient rewrite:

Routing diagram for recipient rewrite

The domain contoso.com’s MX record points to the on-premise server, while the domain @office365.contoso.net’s MX record points to Office 365 because it contains *.protection.outlook.com, or *.eo.outlook.com in the MX record:

MX record points to Office 365, therefore probably recipient rewrite

Be sure to differentiate when a recipient domain’s MX record does not point to Office 365, and when it has undergone a recipient rewrite. It is important to tell the difference between these two cases.

If you are unsure whether or not your receiving domain has undergone a recipient-rewrite, sometimes you can tell by looking at the message headers.

a) First, look at the headers in the message for the recipient domain in the Authentication-Results header: 

Authentication-Results: spf=fail (sender IP is 1.2.3.4)
  smtp.mailfrom=example.com; office365.contoso.net; dkim=fail
  (body hash did not verify) header.d=simple.example.com;
  office365.contoso.net; dmarc=none action=none
  header.from=example.com; compauth=fail reason=001

The recipient domain is found in the bold red text above, in this case office365.contoso.net. This may be different that the recipient in the To: header:

To: Example Recipient <recipient @ contoso.com>

Perform an MX-record lookup of the actual recipient domain. If it contains *.protection.outlook.com, mail.messaging.microsoft.com, *.eo.outlook.com, or mail.global.frontbridge.com, that means that the MX points to Office 365.

If it does not contain those values, then it means that the MX does not point to Office 365. One tool you can use to verify this is MX Toolbox.

For this particular example, the below says that contoso.com, the domain that looks like the recipient since it was the To: header, has MX record points to an on-prem server:
MX record points to on-prem server

However, the actual recipient is office365.contoso.net whose MX record does point to Office 365:

MX points to Office 365, must be recipient rewrite

Therefore, this message has likely undergone a recipient-rewrite.

b) Second, be sure to distinguish between common use cases of recipient rewrites. If you are going to rewrite the recipient domain to *.onmicrosoft.com, instead rewrite it to *.mail.onmicrosoft.com.

Once you have identified the final recipient domain that is routed behind another server and the recipient domain’s MX record actually points to Office 365 (as published in its DNS records), you may proceed to disable antispoofing.

Remember, you don’t want to disable antispoofing if the domain’s first hop in the routing path is Office 365, only when it’s behind one or more services.

How to disable anti-spoofing 

If you already have an Antiphishing policy created, set the EnableAntispoofEnforcement parameter to $false: 

$name = "<name of policy>"
Set-AntiphishPolicy -Identity $name -EnableAntiSpoofEnforcement $false 

If you don’t know the name of the policy (or policies) to disable, you can display them: 

Get-AntiphishPolicy | fl Name

If you don’t have any existing antiphishing policies, you can create one and then disable it (even if you don’t have a policy, antispoofing is still applied; later on in 2018, a default policy will be created for you and you can then disable that instead of creating one). You will have to do this in multiple steps: 

$org = Get-OrganizationConfig
$name = "My first antiphishing policy for " + $org.Name
# Note: If the name is more than 64 characters, you will need to pick a smaller one
# Next, create a new antiphishing policy with the default values
New-AntiphishPolicy -Name $Name

# Select the domains to scope it to
# Multiple domains are specified in a comma-separated list
$domains = "domain1.com, domain2.com, domain3.com"

# Next, create the antiphishing rule, scope it to the anti-phishing rule
New-AntiphishRule -Name $name -AntiphishPolicy -RecipientDomainIs $domains

# Finally, scope the antiphishing policy to the domains
Set-AntiphishPolicy -Identity $name -EnableAntispoofEnforcement $false 

Disabling antispoofing is only available via cmdlet (later in Q2 2018 it will be available in the Security and Compliance Center). If you do not have access to PowerShell, create a support ticket.
Remember, this should only be applied to domains that undergo indirect routing when sent to Office 365. Resist the temptation to disable antispoofing because of some false positives, it will be better in the long run to work through them.

Information for individual users

Individual users are limited in how they can interact with the antispoofing safety tip. However, there are several things you can do to resolve common scenarios.

Common scenario #1 – Mailbox forwarding

If you use another email service and forward your email to Office 365 or Outlook.com, your email may be marked as spoofing and receive a red safety tip. Office 365 and Outlook.com plan to address this automatically when the forwarder is one of Outlook.com, Office 365, Gmail, or any other service that uses the ARC protocol. However, until that fix is deployed, users should use the Connected Accounts feature to import their messages directly, rather than using the forwarding option.

To set up connected accounts in Office 365, select the Gear icon in the top right corner of the Office 365 web interface > Mail > Mail > Accounts > Connected accounts.

Office 365 - Connected accounts option

In Outlook.com, the process is the Gear icon > Options > Mail > Accounts > Connected accounts.

Common scenario #2 – Discussion lists

Discussion lists are known to have problems with antispoofing due to the way they forward the message and modify its contents yet retain the original From: address.

For example, suppose your email address is user @ contoso.com, and you are interested in Bird Watching and join the discussion list birdwatchers @ example.com. When you send a message to the discussion list, you might send it this way:

From: John Doe <user @ contoso.com>
To: Birdwatcher’s Discussion List <birdwatchers @ example.com>
Subject: Great viewing of blue jays at the top of Mt. Rainier this week

Anyone want to check out the viewing this week from Mt. Rainier?

When the email list receives the message, they format the message, modify its contents, and replay it to the rest of the members on the discussion list which is made up of participants from many different email receivers.

From: John Doe <user @ contoso.com>
To: Birdwatcher’s Discussion List <birdwatchers @ example.com>
Subject: [BIRDWATCHERS] Great viewing of blue jays at the top of Mt. Rainier this week

Anyone want to check out the viewing this week from Mt. Rainier?

---
This message was sent to the Birdwatchers Discussion List. You can unsubscribe at any time.

In the above, the replayed message has the same From: address (user @ contoso.com) but the original message has been modified by adding a tag to the Subject line, and a footer to the bottom of the message. This type of message modification is common in mailing lists, and may result in false positives.

If you or someone in your organization is an administrator of the mailing list, you may be able to configure it to pass antispoofing checks.

If you do not have ownership of the mailing list:

  • You can request the maintainer of the mailing list to implement one of the options above (they should also have email authentication set up for the domain the mailing list is relaying from)

  • You can create mailbox rules in your email client to move messages to the Inbox. You can also request your organization’s administrators to set up allow rules, or overrides as discussed in the section Managing legitimate senders who are sending unauthenticated email

  • You can create a support ticket with Office 365 to create an override for the mailing list to treat it as legitimate

Other scenarios

  1. If neither of the above common scenarios applies to your situation, report the message as a false positive back to Microsoft. For more information, see the section "How can I report spam or non-spam messages back to Microsoft" later on in this document.

  2. Additionally, you may also contact your email administrator who can raise it as a support ticket with Microsoft. The Microsoft engineering team will investigate why the message was marked as a spoof.

  3. Additionally, if you know who the sender is and are confident they are not being maliciously spoofed, you may reply back to the sender indicating that they are sending messages from a mail server that does not authenticate. This sometimes results in the original sender contacting their IT administrator who will set up the required email authentication records.

    When enough senders reply back to domain owners that they should set up email authentication records, it spurs them into taking action. While Microsoft also works with domain owners to publish the required records, it helps even more when individual users request it.

  4. Optionally, you may add the sender to your Safe Senders list. However, be aware that if a phisher spoofs that account, it will be delivered to your mailbox. Therefore, this option should be used sparingly.

How senders to Microsoft should prepare for antispoofing protection

If you are an administrator who currently sends messages to Microsoft, either Office 365 or Outlook.com, you should ensure that your email is properly authenticated otherwise it may be marked as spam or phish. 

Customers of Office 365

If you are an Office 365 customer and you use Office 365 to send outbound email:

Microsoft does not provide detailed implementation guidelines for each of SPF, DKIM, and DMARC. However, there is a lot of information published online. There are also 3rd party companies dedicated to helping your organization set up email authentication records.

Administrators of domains that are not Office 365 customers

If you are a domain administrator but are not an Office 365 customer:

  • You should set up SPF to publish your domain’s sending IP addresses, and also set up DKIM (if available) to digitally sign messages. You may also consider setting up DMARC records.

  • If you have bulk senders who are transmitting email on your behalf, you should work with them to send email in a way such that the sending domain in the From: address (if it belongs to you) aligns with the domain that passes SPF or DMARC.

  • If you have on-premise mail servers, or send from a Software-as-a-service provider, or from a cloud-hosting service like Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services, or similar, you should ensure that they are added to your SPF record.

  • If you are a small domain that is hosted by an ISP, you should set up your SPF record according to the instructions that is provided to you by your ISP. Most ISPs provide these types of instructions and can be found on the company’s support pages.

  • Even if you have not had to publish email authentication records before, and it worked fine, you must still publish email authentication records to send to Microsoft. By doing so, you are helping in the fight against phishing, and reducing the possibility that either you, or organizations you send to, will get phished.

What if you don’t know who sends email as your domain?

Many domains do not publish SPF records because they do not know who all their senders are. That’s okay, you do not need to know who all of them are. Instead, you should get started by publishing an SPF record for the ones you do know of, especially where your corporate traffic is located, and publish a neutral SPF policy, ?all:

example.com IN TXT "v=spf1 include:spf.example.com ?all"

The neutral SPF policy means that any email that comes out of your corporate infrastructure will pass email authentication at all other email receivers. Email that comes from senders you don’t know about will fall back to neutral, which is almost the same as publishing no SPF record at all.

When sending to Office 365, email that comes from your corporate traffic will be marked as authenticated, but the email that comes from sources you don’t know about may still be marked as spoof (depending upon whether or not Office 365 can implicitly authenticate it). However, this is still an improvement from all email being marked as spoof by Office 365.

Once you’ve gotten started with an SPF record with a fallback policy of ?all, you can gradually include more and more sending infrastructure and then publish a stricter policy.  

What if you are the owner of a mailing list? 

See the section "Common scenario #2 – Discussion lists"

What if you are an infrastructure provider such as an Internet Service Provider (ISP), Email Service Provider (ESP), or cloud hosting service? 

If you host a domain’s email, and it sends email, or provide hosting infrastructure that can send email, you should do the following:

  • Ensure your customers have documentation detailing what to publish in their SPF records

  • Consider signing DKIM-signatures on outbound email even if the customer doesn’t explicitly set it up (sign with a default domain). You can even double-sign the email with DKIM signatures (once with the customer’s domain if they have set it up, and a second time with your company’s DKIM signature)

Deliverability to Microsoft is not guaranteed even if you authenticate email originating from your platform, but at least it ensures that Microsoft does not junk your email because it is not authenticated. For more details around how Outlook.com filters email, see the Outlook.com Postmaster page.

For more details on service providers best practices, see M3AAWG Mobile Messaging Best Practices for Service Providers.

Frequently Asked Questions

Why is Microsoft making this change?

Because of the impact of phishing attacks, and because email authentication has been around for over 15 years, Microsoft believes that the risk of continue to allow unauthenticated email is higher than the risk of losing legitimate email.

Will this change cause legitimate email to be marked as spam?

At first, there will be some messages that were marked as spam. However, over time, senders will adjust and then the amount of messages mislabeled as spoofed will be negligible for most email paths.
Microsoft itself first adopted this feature several weeks before deploying it to the rest of its customers. While there was disruption at first, it gradually declined.

Will Microsoft bring this feature to Outlook.com and non-Advanced Threat Protection customers of Office 365?

Antispoofing protection will be initially rolled out to ATP/E5 customers, and may in the future be released to its other users. However, if it does, there may be some capabilities that are not applied such as reporting and custom overrides.

How can I report spam or non-spam messages back to Microsoft?

You can either use the Report Message Add-in for Outlook, or if it isn’t installed, Submit spam, non-spam, and phishing scam messages to Microsoft for analysis.

I’m a domain administrator who doesn’t know who all my senders are!

Please see Administrators of domains that are not Office 365 customers.

What happens if I disable antispoofing protection for my organization, even though Office 365 is my primary filter?

We do not recommend this because you will be exposed to more missed phishing and spam messages. Not all phishing is spoofing, and not all spoofs will be missed. However, your risk will be higher than a customer who enables antispoofing.

Does enabling antispoofing protection mean I will be protected from all phishing?

Unfortunately, no, because phishers will adapt to use other techniques such as compromised accounts, or setting up accounts of free services. However, antiphishing protection works much better to detect these other types of phishing methods because Office 365’s protection layers are designed work together and build on top of each other.

Do other large email receivers block unauthenticated email?

Nearly all large email receivers implement traditional SPF, DKIM, and DMARC. Some receivers have other checks that are strict than just those standards, but few go as far as Office 365 to block unauthenticated email and treat them as a spoof. However, most of the industry is becoming more and more strict about this particular type of email, particularly because of the problem of phishing.

Do I still need the Advanced Spam Filtering option enabled for “SPF Hard Fail” if I enable antispoofing?

No, this option is no longer required because the antispoofing feature not only considers SPF hard fails, but a much wider set of criteria. If you have antispoofing enabled and the SPF Hard Fail option enabled, you will probably get more false positives. We recommend disabling this feature as would provides almost no additional catch for spam or phish, and instead generate mostly false positives.

Does Sender Rewriting Scheme (SRS) help fix forwarded email? 

SRS only partially fixes the problem of forwarded email. By rewriting the SMTP MAIL FROM, SRS can ensure that the forwarded message passes SPF at the next destination. However, because antispoofing is based upon the From: address in combination with either the MAIL FROM or DKIM-signing domain (or other signals), it is not enough to prevent forwarded email from being marked as spoofed.

Get support
Contact us
Expand your Office skills
Explore training

Was this information helpful?

Thank you for your feedback!

Thank you for your feedback! It sounds like it might be helpful to connect you to one of our Office support agents.

×