Understanding the Anti-Spoofing technology in Exchange Online

In the Spring of 2018, Microsoft released some new anti-spoofing features into their Advanced Threat Protection product, which is also bundled into Microsoft & Office 365 E5 plans, as well as Microsoft 365 Business. Anti-spoofing leverages machine learning and other intelligent software to determine whether messages have been “spoofed” or not. UPDATE: Now this feature is also available to all Exchange Online organizations.

For many years now, there have been methods available that organizations can use to authenticate their email messages, such as SPF, DKIM and DMARC. Their purpose is to help combat spoofing by proving that email messages came from the “right place.” The core problem is, all of these authentication protections are optional, and a surprisingly high percentage of fortune 500 companies do not take steps, such as publishing DMARC, to properly authenticate their mail. (Source)

Therefore, spoofed domains and senders can be difficult to spot, and attackers are constantly exploiting organizations who do not take proper steps to protect their mail. SPF, DKIM and DMARC are essentially a combination of DNS records and digital signatures that “vouch” for your email messages, showing that mail really came from your organization. Using these tools is considered explicit authentication, because you are explicitly stating your domain’s identity to recipient servers. But because so few organizations out there have taken the time to setup this optional security mechanism, Microsoft has also developed an implicit authentication system known as composite authentication–and this technology is applied in their anti-spoofing technology for Exchange Online.

What is so-called “composite authentication,” and why does it matter?

“Composite authentication” or CompAuth for short, is essentially a confidence score or rating, which is applied to incoming messages. It takes into account the presence of explicit authentication records such as SPF, DKIM and DMARC, however, if no such records exist (or if not all of them exist), Microsoft will also apply some other intelligence, such as sender reputation, sender/recipient history, behavioral analysis, and other advanced techniques which add or subtract from the confidence in whether a message has been spoofed or not. Therefore, it is a “composite” of both explicit and implicit authentication, which determines whether a message is marked as spoofed, ultimately.

The result is stamped into the message header:

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

And if the CompAuth result is fail, these are the reasons why it could fail:

000 means the message failed DMARC with an action of reject or quarantine.
001 means the message failed implicit email authentication; 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).

Yes, you want this protection

The key piece to understand here, is that if your organization does not publish email authentication, then your messages will be treated as spoofed by this anti-spoofing protection, unless there are other indicators (using implicit authentication) which raise the CompAuth score enough to allow mail through.

Previously to this technology, even with zero authentication records published, most mail servers would have simply accepted mail messages from your domain (regardless of whether they really came from your organization).  Today, with this anti-spoof technology turned on, any sender who does not publish some form of email authentication such as SPF, will automatically start out with a mark against them, and the mail could be junked by Office 365 altogether. It is possible that the composite score could be rescued by machine learning, but you cannot rely on this technology to make the right decision about “legitimate” mail every time. Therefore, it is in your best interest to publish authentication (and encourage your partners/contacts in the industry to do the same).

From the other side, there are certain scenarios where email authentication mechanisms may not be enough on their own to validate the authenticity of mail, and here also the machine learning can help to detect irregular patterns in the exchange between sender and recipient, and block messages that are otherwise authenticated–so basically what I’m telling you here is:

• If you turn on anti-spoofing you should expect to see a few more messages junked than usual, AND:
• Some junked messages may be actually be legitimate (false-positives)

On the flip side, you will have a better overall protection against potentially spoofed email messages, which do not originate from a legitimate source–and this is something you will want to have in place.

Practical implementation

Since the feature is enabled by default with all ATP subscriptions (and is rolling out soon to other Exchange Online customers), please be aware that it would be up to you as an administrator to create a new anti-phishing policy and choose to turn this feature off, if you did not want the composite authentication score to come into play. Before you go and do that, however, I would actually recommend leaving it on, per Microsoft’s recommendation, in most cases. The reason is simple. If you need to make adjustments or exceptions at first, or work with partner organizations so that they improve their mail security (publish SPF, for instance), going through these initial pains is much better than exposing data or losing real money due to a spoof attack.

There is one notable exception here. If you have a situation where you are filtering your mail somewhere else, before it is delivered to Office 365, and any sort of recipient re-write is taking place, then you might want to turn the anti-spoof features to off, just as certain anti-spam settings in Exchange Online Protection (EOP) are better left to off in this scenario. There may be hybrid scenarios with very complicated mail flows as well, where the message is delivered to a third party service, then to an on-prem mail server and finally to Office 365. It is very likely you could see some adverse effects from EOP, especially when ATP anti-spoofing is enabled.

Where to find and adjust the anti-spoof settings

If you want to take a look at these features, navigate to the Security & Compliance Center. Find Threat Management > Policy and choose ATP anti-phishing.

Select the policy to edit it, or choose the Default policy, if no other policy exists. Now scroll down to where you find the spoof settings and click Edit on the right.

You will find options to turn it On or Off (I recommend leaving this set to On), and also whether to use the Junk Mail folder, or the Quarantine (I usually recommend Quarantine).

Just briefly let’s take a look at PowerShell for turning this setting on or off, at will, and adjusting the default action for composite authentication failure. Prior to running these commands, it will be necessary to connect to Exchange Online using PowerShell.

To disable anti-spoofing on your default Anti-phish policy:

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

To enable anti-spoofing on your default Anti-phish policy (this is my recommended AND the default setting):

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

To change the default action for composite authentication failure (this is my recommended setting):

Set-AntiphishPolicy -Identity $defaultAntiphishPolicy.Name -AuthenticationFailAction Quarantine

To set the default action to Junk Mail Folder (this is the default setting):

Set-AntiphishPolicy -Identity $defaultAntiphishPolicy.Name -AuthenticationFailAction MoveToJmf

It is also possible to configure “safety tips” or notifications that end users would see, when messages fail composite authentication. By default, safety tips will be enabled on all messages that fail compauth. When a message passes compauth, but with only low to medium confidence (known as “soft pass”), then by default no safety tip will be shown. It is recommended to leave these defaults in place, as users could otherwise see a lot of safety tips on legitimate messages, reducing the effectiveness of these warnings. Nevertheless, here is how you can toggle these settings:

#By default, EnableAuthenticationSafetyTip is set to $true; this is the recommended setting
Set-AntiphishPolicy -Identity $defaultAntiphishPolicy.Name -EnableAuthenticationSafetyTip <$true | $false>
#By default, EnableAuthenticationSoftPassSafetyTip is set to $false; this is also the recommended setting
Set-AntiphishPolicy -Identity $defaultAntiphishPolicy.Name -EnableAuthenticationSoftPassSafetyTip <$true | $false>

Soon, I will publish a script with all of my recommended minimum or “baseline” ATP settings, and these recommendations will be included with it.

Review senders who spoof your domains, and external domains!

Finally, know that you can navigate to Threat Management > Policy and choose Anti-spam. From this page, you can select Custom and under the Spoof intelligence policy, and choose to review senders who are spoofing your domains, or external domains.  You can come back to review this list regularly. From here you are able to allow or disallow instances of spoofing, to improve the anti-spoof intelligence within your tenant.

One last key take-away

You should setup SPF authentication at a minimum for your own domain, with the simple reason that your messages will also be hitting other customers who have these protections enabled, and you would want the best compauth result for your own domain(s). This is pretty easy to do–it is just publishing a TXT record in DNS known as an SPF record. You should also strongly consider adding DKIM and DMARC to your email authentication strategy, but SPF will allow your mail to pass most authentication checks such as those performed by ATP in Office 365. Try to include as many “legitimate” sources of email as you can in the SPF. For example, for mail that is just hosted at Office 365, with no other possible senders, you only need the following:

v=spf1 include:spf.protection.outlook.com -all

For other third party mail systems such as Constant Contact, etc., you can usually find their SPF information using a quick Google search, or by contacting their support. (Often, they will help you with DKIM, too.) For your own on-premises apps or MFP/scan to email devices, you may want to include an ip4 entry for your company’s external IP addresses. Let’s say you had a combination of Office 365 for hosted email, Constant Contact for bulk mailing/marketing emails, and an on-premises copier/scanner that routes mail via an on-premises SMTP service, with external IP of 87.65.43.21–then you would have this SPF to publish:

v=spf1 include:spf.protection.outlook.com include:spf.constantcontact.com ip4:87.65.43.21 -all

If you aren’t sure if this accounts for all your legitimate mail, you can also opt for a soft fail option, by using a “tilde” or ~all instead of a “hyphen” or -all.

I will have another article soon going into more detail on the other email authentication mechanisms.