Is X-Microsoft-Antispam a New EOP Header

Yes, yes it is, and I’m glad you noticed! X-Microsoft-Antispam is quite new and only started showing up in messages passing through EOP a few months ago. This new header currently contains two published values to help with bulk mail and phishing detection.

  • BCL – Bulk Complaint Level
  • PCL – Phishing Confidence Level

The beauty of this header is that it is stamped on incoming messages BEFORE EOP transport rules are evaluated. This means you can write EOP transport rules to trigger based on what’s in this header.

One of the goals behind the new X-Microsoft-Antispam header is to allow customers to decide how sensitive they want EOP to be when it comes to bulk mail detection. Today in the EOP Content Filter there is a bulk mail detection switch that can currently only be set to either on or off.

The problem with this switch only being on or off is that bulk mail is a very grey area. What one user considers as bulk another will not. This is why we are moving beyond the on off switch to a multi-value classification system where customers will be able to set the level that they are comfortable with.

With this new header, you can decide on a scale how sensitive you want the service to be with bulk mail detection. Eventually this will be rolled in to the Advanced Spam Filter options and replace the current bulk on off switch, but for now you can write EOP Transport Rules to take advantage of this and enforce the bulk mail detection level of your choosing.

At MEC this year there was a great presentation titled So how does Microsoft handle my spam? In this presentation, bulk mail detection is discussed between 22:30 to 28:50 and the speakers provide great insight into this topic. The entire session is great, but I would recommend at least listening to the six minutes where they discuss bulk mail.

What can I do today?

If you are experiencing unwanted bulk mail today there are some things you can start with.

  1. Take advantage of the new x-Microsoft-Antispam header by writing EOP transport rules that examine it. See Use transport rules to aggressively filter bulk email messages. This page describes three separate rules, the first of which uses the X-Microsoft-Antispam header and the other two look for text patterns and phrases. I would recommend creating only with the first rule that looks at X-Microsoft-Antispam, and if you need even more aggressive bulk mail filtering, then create the subsequent two rules.
  2. Educate yourself on the new X-Microsoft-Antispam header. See Anti-spam message headers and Bulk Complaint Level values.
  3. Educate your users on bulk mail. If a user recognizes the sender of the bulk message and does not want to receive further mail, they can click the unsubscribe link on the email. If the user does not recognize the sender, they can block the sender or domain in Outlook or OWA by adding the sender to their Blocked Senders list.
  4. Submit bulk mail and spam back to Microsoft for analysis. This allows us to continually refine our message filters. See Submitting spam and non-spam messages to Microsoft for analysis.


The following documentation was updated in July 2014 to include information about the new X-Microsoft-Antispam header.

What’s the difference between junk email and bulk email?
Anti-spam message headers
Bulk Complaint Level values
Use transport rules to aggressively filter bulk email messages

Comments (7)

  1. Hi Verne, great questions. For the location of the documentation, I don't believe we currently document that Transport Rules cannot target the X-Forefront-Antispam-Report header. I'll verify and if we don't I'll let our content team know.

    To review, when messages arrive at EOP we process them in this order: Edge Blocks –> Malware scanning –> Transport Rules –> Spam Protection (Content filter) –> Deliver to mailbox.

    When we get to the Transport Rules step, some items in the X-Forefront-Antispam-Report header have been stamped, but others haven't. Specifically, we haven't stamped the SCL or the Spam Filter Verdict (SFV) yet so a TR would not be able to trigger based on them. However, we have stamped some items like CTRY and CIP which can be identified by a transport rule since they are stamped before the rules are evaluated. 
    For the SPF checks, these take place in the Spam Protection stage, which happens after Transport Rules run. This means you can't write a transport rules to look at the EOP SPF check results (although an SPF check may be stamped in the header by a service before the message reached EOP). You could however enable the content filter option "SPF record: hard fail" which will cause our Spam Protection to mark a message as spam if the SPF check shows as failing.

    On a similar note. If you have a transport rule which safe lists a message, the Spam Protection step is totally skipped. In this case, you won't see an SPF check in the header (unless one was stamped before the message arrived at EOP). If a message is not safe listed and goes through the Spam Protection stage, you will see the SPF check result in the header.

  2. Hi Joe, it actually shouldn’t be working like that. You are correct that transport rules are evaluated first, and then the content filter is evaluated. The only time the content filter will be skipped is if a transport rule has an action of "bypass spam
    filtering." Even when a transport rule sets the SCL the content filter will still run. End user "safe senders" lists are evaluated in the content filter. So, if you have a rule that sets the SCL of a message to 5, when the message then hits the content filter,
    the SCL could change to -1 if the recipient has the sender in their safe senders list. You can tell if this happened because the message will be stamped with SFV:SFE. If you aren’t seeing this happen then I would recommend opening a ticket with us. If the
    end users mailbox is located on-prem there could be a problem with DirSync not syncing the safe senders AD attribute.

  3. Hi Byron, to prevent spoofing I would highly recommend setting up both an SPF and DMARC record. You could then create a transport rule that would be something like this.

    If sending domain is
    X-Authentication-Results header contains DMARC=pass
    Do the following
    Bypass Spam Filtering.

    For more information on using DMARC to prevent spoofing, see my previous post and take a look at the links I have at the end of that story.

    For a good example of creating a transport rule to safe list but also verify that DMARC passes, see

  4. Verne says:

    where is it documented that … Keep in mind that the X-Forefront-Antispam-Report header still gets stamped on incoming message AFTER EOP transport rules are evaluated and so cannot be targeted by the rules. …

    AND … does that before/after description apply to the two headers


  5. Joe Sutherland says:

    Is seems that setting SCL to 5 via a transport rule short-circuits the user-based Safe-Senders list (since rules are evaulated before the Content Filtering). Thus, there's no way for an end-user to whitelist his bulk-senders if we use this method. Am I missing
    something, or do we have to live with this limitation until you add granularity to the built-in bulk filtering options? Is there any hook we can use as an exception in the transport rule that will lookup the recipients' safe-senders list? I'm assuming not
    but wanted to check.

  6. Anonymous says:

    I only began this blog in June of this year and so it’s hard to believe that it is already six

  7. Byron says:

    Andrew, If i have a domain, like,, in our bypass spam list in a transport rule, how do I use SPF check to prevent someone from spoofing Is there anyway to safelist a domain, and use SPF to confirm no one spoofs it? Did I understand it

Skip to main content