What is Get-AntiPhishPolicy TreatSoftPass AsAuthenticated?
While reviewing Get-AntiPhishPolicy I wondered about the TreatSoftPassAsAuthenticated option.
The TreatSoftPassAsAuthenticated parameter specifies whether or not to respect the composite authentication softpass result. Valid values are:
$true: This is the default value.
$false: Only use this value when you want to enable more restrictive antispoofing filtering, because this value might cause false positives.
Note: This parameter corresponds to the Strict filtering value in the Office 365 admin center.
source: https://docs.microsoft.com/en-us/powershell/module/exchange/advanced-threat-protection/set-antiphishpolicy?view=exchange-ps
This then made me wonder about composite authentication and what a softpass is.
While SPF, DKIM, and DMARC are all useful by themselves, they don’t communicate enough authentication status in the event a message has no explicit authentication records. Therefore, Microsoft has developed an algorithm that combines multiple signals into a single value called Composite Authentication, or compauth for short. Customers in Office 365 have compauth values stamped into the Authentication-Results header in the message headers.
Authentication-Results: compauth=<fail|pass|softpass|none> reason=<yyy>
| CompAuth result | Description |
|---|---|
| fail | Message failed explicit authentication (sending domain published records explicitly in DNS) or implicit authentication (sending domain did not publish records in DNS, so Office 365 interpolated the result as if it had published records). |
| pass | —————————————— Message passed explicit authentication (message passed DMARC, or Best Guess Passed DMARC) or implicit authentication with high confidence (sending domain does not publish email authentication records, but Office 365 has strong backend signals to indicate the message is likely legitimate). |
| softpass | ——————————————Message passed implicit authentication with low-to- medium confidence (sending domain does not publish email authentication, but Office 365 has backend signals to indicate the message is legitimate but the strength of the signal is weaker). |
| none | ——————————————Message did not authenticate (or it did authenticate but did not align), but composite authentication not applied due to sender reputation or other factors. |
Source:https://support.office.com/en-us/article/anti-spoofing-protection-in-office-365-d24bb387-c65d-486e-93e7-06a4f1a436c0
So essentially, a pass is softpass is when there are no DMARC records, but Office 365 is pretty sure that this domain is the appropriate sender. A pass is when either a DMARC record is published and it passes, or Microsoft is very sure the email is legitimate.
By default, softpass is not marked as junk. I think this is a pretty good setting since not a lot of domains have DMARC setup.