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 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. Additionally, because of the way all of our filters learn from each other, 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 firstname.lastname@example.org:
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:
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:
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:
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
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>
|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.|
|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).
011 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).
|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:
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:
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).
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
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:
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 184.108.40.206) 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 anti-spoofing, if you have Office 365 Enterprise E5, EOP, or ATP, the compauth value is stamped:
Authentication-Results: spf=none (sender IP is 220.127.116.11) 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 18.104.22.168) 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 22.214.171.124) 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 126.96.36.199) 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.
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 188.8.131.52) 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: email@example.com To: firstname.lastname@example.org
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, Outlook.com
||All Office 365 organizations, Outlook.com
||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:
If you've already created one, you can select it to modify it:
Select the policy you just created and proceed through the steps as described on Learn More about Spoof Intelligence.
To create a new policy via 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 = "domain1.com, domain2.com, domain3.com" # 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).
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.
Later on in 2018, to set up your default protection via PowerShell:
$defaultAntiphishPolicy = Get-AntiphishingPolicy -IsDefault $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-AntiphishingPolicy -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 (e.g., 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 184.108.40.206 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.
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
In the previous 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:
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 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 Intelligence 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:
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, and so on). However, later in 2018, 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:
For non-ATP and E5 customers, these reports will be available later 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 & 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 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.
Understanding how spam, phishing, and advanced phishing detections are combined
Organizations that use Exchange Online, with or without ATP, can specify which actions to take when the service identifies messages as malware, spam, high confidence spam, phishing, and bulk. With the ATP Anti-phishing policies for ATP customers, and the Anti-phishing policies for EOP customers, and the fact that a message may hit multiple detection types (for example, 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|
||Hosted content filter policy
||High confidence spam
||Hosted content filter policy
||Anti-phishing policy, Spoof intelligence
||Hosted content filter policy
||Hosted content filter policy
||Organizations with ATP only
||Organizations with ATP only
If you have multiple different Anti-phishing policies, the one at the highest priority will apply. For example, suppose you have two policies:
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 Anti-spoofing 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 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:
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 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:
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:
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:
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 220.127.116.11) 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 following 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:
However, the actual recipient is office365.contoso.net whose MX record does point to Office 365:
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 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 = "domain1.com, domain2.com, domain3.com" # Next, create the anti-phishing 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 anti-spoofing is only available via cmdlet (later in Q2 2018 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 - 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.
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 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 @ 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 anti-spoofing checks.
Check the FAQ at DMARC.org: I operate a mailing list and I want to interoperate with DMARC, what should I do?
Read the instructions at this blog post: A tip for mailing list operators to interoperate with DMARC to avoid failures
Consider installing updates on your mailing list server to support ARC, see https://arc-spec.org
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
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.
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.
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.
- 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 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:
For your domains, Set up SPF in Office 365 to help prevent spoofing
For your primary domains, Use DKIM to validate outbound email sent from your custom domain in Office 365
Consider setting up DMARC records for your domain to determine who are your legitimate senders
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 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 Outlook.com 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 Outlook.com. 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!
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.