This is a rough description of how the Phishing Confidence Level (PCL) works in Office 365.

Way back in the olden days - 2007 or so - Exchange server used to have its own spam filter, Smartscreen. This was more-or-less the same spam filter running in Outlook.com. But whereas Smartscreen in Outlook.com (then known as Hotmail) updated multiple times per day, the spam filter in Exchange only updated periodically.

Smartscreen on Exchange was designed to communicate with Outlook the email client. When Smartscreen set the Spam Confidence Level (SCL), this was propagated to Outlook who would move messages SCL 5 and higher to the Junk Email folder. The SCL was stamped in the following header:

X-MS-Exchange-Organization-SCL: 5

Smartscreen could also detect if a message was phishing, and if so, it would set the Phishing Confidence Level (PCL) to 8. It would stamp this in the following header:

X-MS-Exchange-Organization-PCL: 8

Or, perhaps this:

X-MS-Exchange-Organization-PCL: Suspicious

That comes from Antispam Stamps, our documentation from Exchange on-prem's filtering (I'm also not totally sure on the format, I rarely work with the phishing filter for on-prem because I'm all about the Office 365 and Outlook.com services).

But it's not enough to store these values in headers, Exchange also stores them in MAPI properties. Not every X-MS-Exchange-Organization-* header corresponds to a MAPI property, but these ones do (MAPI is a database-backed mailstore for Exchange; I've been working with it for years and still don't fully understand it). So, Outlook has access to those headers but also to those MAPI properties.

Whenever Outlook sees PCL 8 in a MAPI property, it displays the following pink bar in the email client:

You may have seen this in Outlook; if you do, it's because PCL 8 has been set.

A couple years ago, we moved away from the native Outlook phishing bar because... well, it's aesthetically unpleasing and hard to update (we have to update the code and then get our users to update their software. That's an uphill battle.) In its place, we moved to Safety Tips. Where's what the new Safety Tip looks like for phishing:

This new-and-improved Safety Tip is only available in Outlook.com and Office 365. It is not available in Exchange on-prem. Doesn't this look way better? The "Learn more" link can be controlled dynamically, that is, we can change where it points to.

The problem is that all the code to show the pink bar still exists in Outlook, which means that if Office 365 (or Outlook.com) ever sees a phishing message and tries to set PCL 8, which is how we've defined phishing previously, that native pink bar will show up in the client. We don't want that, we only want to show the new Safety Tip.

To solve this problem, we decided that we would reserve a new value for phishing: -9990. That way, we would always know that it was Office 365 that identified a message as phishing and not some other service, and Outlook would never show the native pink bar. It allows us to instead show only the newest Safety Tip.

The PCL is supposed to be stamped in two places, the first is the X-Microsoft-Antispam header in the PCL property, and then additionally in the X-MS-Exchange-Organization-PCL header. But it also gets stamped sometimes in the X-Exchange-Antispam-CFA-Test header which is an internal header.

But sometimes a message still gets PCL 8, despite my best efforts to purge PCL 8 from the system.

1. Exchange on-prem still sets the PCL value

If you are running Exchange on-prem in front of Office 365, and it detects a message as phish and sets PCL 8, and you have a set of connectors to connect to Office 365 which propagates message properties forward, Office 365 will inherit and promote the previously existing PCL the same as it does a previously set SCL. In a case like this, PCL 8 will appear in the message headers. However, the X-MS-Exchange-Organization-PCL header will have a bunch of other properties that Office 365 does not use, and that allows us to differentiate between Exchange on-prem and Office 365's antiphishing.

2. Corner cases in our code

Despite my super-best efforts, sometimes messages get PCL 8 because they have a "Mark as phish" rule somewhere in the system that does not have PCL -9990 assigned, and instead gets a default PCL 8. This one drives me crazy. Usually, although not always, when a message is marked as phish in our system, it's because the SFTY value is 9.x, and 9.1 is the most common reason (this property is not documented). But sometimes even in a default case, 9.1 is stamped. Those are difficult to track down. Fortunately, this doesn't happen that much anymore.

The Phishing Confidence Level is a little more complicated than that, because we have machine learning and some other technologies, and I don't quite know how they interact with the SFTY and PCL. I haven't worked on those features and I'm not so familiar with them. Still, this description - as of this writing - covers the majority of PCL and phishing cases that I have seen.

I hope you find this useful.