Anti-spoofing protection in Office 365

This article describes how Office 365 mitigates against phishing attacks that use 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 was implemented to reduce the number of phishing attacks to which organizations in Office 365 are exposed.

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 was initially deployed to its organizations that had an Office 365 Enterprise E5 subscription or had purchased the Office 365 Advanced Threat Protection (ATP) add-on for their subscription. As of October, 2018 we extended the protection to organizations that have Exchange Online Protection (EOP) as well. Additionally, because of the way all of our filters learn from each other, 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

Phishing message impersonating

The above did not actually come from, 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

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 from examining a message's sender. That is, the sender that users see in their email client (in the examples above it is,, and Furthermore, users can also see that the domain has passed SPF or DKIM, which means that the domain 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 article.

However, the problem is that email authentication records are optional, not required. Therefore, while domains with strong authentication policies like and 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.

  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).
002 means the organization has a policy for the sender/domain pair that is explicitly prohibited from sending spoofed email, this setting is manually set by an administrator.
010 means the message failed DMARC with an action of reject or quarantine, and the sending domain is one of your organization's accepted-domains (this is part of self-to-self, or intra-org, spoofing).
1xx, 2xx, 3xx, 4xx, and 5xx Correspond to various internal codes for why a message passed implicit authentication, or had no authentication but no action was applied.
6xx Means the message failed implicit email authentication, and the sending domain is one of your organization's accepted domains (this is part of self-to-self, or intra-org, spoofing).

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 ( Spaces are inserted into the email address to prevent spambot harvesting on this page):

From: sender @

To: recipient @

The following has the sender and recipient domains aligning with the organizational domain (

From: sender @

To: recipient @

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

From: sender @

To: recipient @

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 anti-spoofing 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 anti-spoofing protection relies on 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 back-end intelligence that says the message is legitimate.

For example, prior to anti-spoofing 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;; dkim=none
  (message not signed) header.d=none;; dmarc=none
From: sender @
To: receiver @

After anti-spoofing, if you have Office 365 Enterprise E5, EOP, or ATP, the compauth value is stamped:

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

If 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;; dkim=none
  (message not signed) header.d=none;; dmarc=bestguesspass
  action=none; compauth=pass reason=109
From: sender @
To: receiver @

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;; dkim=pass
  (signature was verified);; dmarc=bestguesspass action=none; compauth=pass reason=109
From: sender @
To: receiver @

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 published DMARC records, this would not be marked as a spoof using DMARC:

Authentication-Results: spf=pass (sender IP is;; dkim=pass
  (signature was verified);; dmarc=none action=none;
From: sender @
To: receiver @

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, but actually came from

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;; dkim=pass
  (signature was verified);; dmarc=none action=none;
  compauth=fail reason=001

Thus, Office 365 anti-spoofing 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 is 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 organizations in 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 Anti-phishing > Anti-spoofing policy. If one is not defined, it will be moved to a 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 changed, see Changing your anti-spoofing settings).

There are multiple different ways a message can be spoofed (see Differentiating between different types of spoofing earlier in this article) but as of March 2018 the way Office 365 treats these messages is not yet unified. The following 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,
All Office 365 organizations,
Office 365 Advanced Threat Protection and E5 customers

Changing your anti-spoofing settings

To create or update your (cross-domain) anti-spoofing settings, navigate to the Anti-phishing > Anti-spoofing settings under the Threat Management > Policy tab in the Security & Compliance Center. If you have never created any anti-phishing settings, you will need to create one:

Anti-phishing - create a new policy

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

Anti-phishing - modify existing policy

Select the policy you just created and proceed through the steps as described in Learn more about spoof intelligence.

Enable or disable anti-spoofing

Enable or disable anti-spoofing safety tips

To create a new policy by using PowerShell:

$org = Get-OrganizationConfig
$name = "My first anti-phishing policy for " + $org.Name
# Note: The name should not exclude 64 characters, including spaces.
# If it does, you will need to pick a smaller name.
# Next, create a new anti-phishing 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 = ",,"
# Next, create the anti-phishing rule, scope it to the anti-phishing rule
New-AntiphishRule -Name $name -AntiphishPolicy $name -RecipientDomainIs $domains

You may then modify the anti-phishing 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).

Default policy for Anti-phishing

Unlike a policy that you create, you cannot delete the default policy, modify its priority, or choose which users, domains, or groups to scope it to.

Anti-phishing default policy details

To set up your default protection by using PowerShell:

$defaultAntiphishPolicy = Get-AntiphishPolicy | ? {$_.IsDefault -eq $true}
Set-AntiphishPolicy -Identity $defaultAntiphishPolicy.Name -EnableAntispoofEnforcement <$true|$false>

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

$defaultAntiphishPolicy = Get-AntiphishiPolicy | ? {$_.IsDefault $true}
Set-AntiphishPolicy -Identity $defaultAntiphishPolicy.Name -EnableAntispoofEnforcement $false 


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 (that is, legitimate messages marked as spoof), we do NOT recommend disabling anti-spoofing 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 anti-spoofing 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 Customers of Office 365.

Method 2 - Use Spoof intelligence to configure permitted senders of unauthenticated email

You can 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 whose PTR record is, and this would show up as for the sending infrastructure).

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

Setting up anti-spoofing 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 from Powershell

In the previous image, additional line breaks have been added to make this screenshot fit. Normally, all the values would appear on a single line.

Edit the file and look for the line that corresponds to and, and change the AllowedToSpoof entry from No to Yes:

Setting spoof allow to Yes in 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 to send unauthenticated email from *

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 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 article.

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 anti-spoofing policy is enabled, you can use threat investigation and response capabilities to get numbers around how many messages are marked as phish. To do this, go into the Security & 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 investigation and response.

You can't yet split out which messages were marked due to spoofing as opposed to other types of phishing (general phishing, domain or user impersonation, and so on). However, later, you will be able to do this through the Security & Compliance Center. 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 following 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 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 & Compliance Center.

Predicting how many messages will be marked as spoof

Once Office 365 updates its settings to let you turn the anti-spoofing 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 anti-spoofing 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 anti-spoofing

Possible UX for allowing a spoofed sender

Legitimate scenarios to disable anti-spoofing

Anti-spoofing better protects customers from phishing attacks, and therefore disabling anti-spoofing 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 anti-spoofing false positives than to disable anti-spoof protection.

However, there is a legitimate scenario where anti-spoofing 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-premises 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 anti-spoofing because Office 365 looks up your receiving domain's MX record and suppresses anti-spoofing 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 anti-spoofing 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 anti-spoofing. The most common example is through the use of a recipient rewrite:

Routing diagram for recipient rewrite

The domain's MX record points to the on-premises server, while the domain's MX record points to Office 365 because it contains *, or * 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;; dkim=fail
  (body hash did not verify);; dmarc=none action=none; compauth=fail reason=001

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

To: Example Recipient <recipient @>

Perform an MX-record lookup of the actual recipient domain. If it contains *,, *, or, 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 following says that, 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-premises server

However, the actual recipient is 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 *, instead rewrite it to *

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 anti-spoofing.

Remember, you don't want to disable anti-spoofing 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 Anti-phishing 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 anti-phishing policies, you can create one and then disable it (even if you don't have a policy, anti-spoofing 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 anti-phishing policy for " + $org.Name
# Note: If the name is more than 64 characters, you will need to choose a smaller one
# Next, create a new anti-phishing 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 = ",,"
# Next, create the anti-phishing rule, scope it to the anti-phishing rule
New-AntiphishRule -Name $name -AntiphishPolicy -RecipientDomainIs $domains
# Finally, scope the anti-phishing policy to the domains
Set-AntiphishPolicy -Identity $name -EnableAntispoofEnforcement $false

Disabling anti-spoofing is only available via cmdlet (later it will be available in the Security & 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 anti-spoofing 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 anti-spoofing safety tip. However, there are several things you can do to resolve common scenarios.

Common scenario #1 - Discussion lists

Discussion lists are known to have problems with anti-spoofing 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 @, and you are interested in Bird Watching and join the discussion list birdwatchers @ When you send a message to the discussion list, you might send it this way:

From: John Doe <user @>

To: Birdwatcher's Discussion List <birdwatchers @>

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 @>

To: Birdwatcher's Discussion List <birdwatchers @>

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 @ 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 anti-spoofing 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 in this article.

  2. 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.

  1. Optionally, 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 anti-spoofing protection

If you are an administrator who currently sends messages to Microsoft, either Office 365 or, 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-premises 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: IN TXT "v=spf1 ?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 #1 - 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 filters email, see the 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 are 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 and non-Advanced Threat Protection customers of Office 365?

Microsoft's anti-spoofing technology was initially deployed to its organizations that had an Office 365 Enterprise E5 subscription or had purchased the Office 365 Advanced Threat Protection (ATP) add-on for their subscription. As of October, 2018 we've extended the protection to organizations that have Exchange Online Protection (EOP) as well. In the future, we may release it for However, if we do, 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 anti-spoofing 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 anti-spoofing.

Does enabling anti-spoofing 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, anti-phishing 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 more 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 anti-spoofing?

No, this option is no longer required because the anti-spoofing feature not only considers SPF hard fails, but a much wider set of criteria. If you have anti-spoofing enabled and the SPF Hard Fail option enabled, you will probably get more false positives. We recommend disabling this feature as it would provide 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 anti-spoofing 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.