Understanding the information in an email header can reveal why a message was marked as junk (spam) or placed in quarantine by Exchange Online. Email headers in Exchange Online contain specialized “X-” fields that record spam filtering results and policy actions, allowing administrators to decipher which policies were applied and what the outcome was[2]. Below, we explain key header fields, how to interpret them, and a step-by-step guide to analyse an email header to determine why a message ended up in Junk or Quarantine. We also discuss tools and best practices for using header information in troubleshooting.

---

Key Header Fields and What They Mean

Exchange Online (part of Microsoft 365) adds several anti-spam and policy-related fields to message headers. The most important ones for diagnosing junk/quarantine issues are listed below:

• X-Forefront-Antispam-Report – Contains detailed spam filtering diagnostics. This single header includes many field:value pairs (separated by semicolons) about how the message was processed[2]. Key sub-fields include:

  • SCL (Spam Confidence Level) – A numeric score from -1 to 9 indicating spam likelihood[4]. Higher values mean the message is more likely spam. For example, SCL 5 or above typically means the message was flagged as spam, whereas SCL -1 means the sender was whitelisted (skipped spam filtering)[1][4].
    

  • SFV (Spam Filter Verdict) – A code summarising what the spam filter decided to do. For example: SFV:NSPM means “not spam” (message is clean)[2]; SFV:SPM means the filter classified it as spam[2]; SFV:SKQ means the message was quarantined and later released to the mailbox[2][2]; SFV:SKS means it was flagged as spam by a mail flow rule before normal filtering[2][2]. Many other codes exist (e.g. SFE for Safe Sender, SKB for blocked sender) which indicate if users’ safe/block lists or admin allow/block policies affected the mail[2]. (See Table 1 below for a summary of common SFV values.)
    

  • CIP (Connecting IP) – The IP address of the sending server[2]. This can indicate if the sender is on a blocked IP list or allowed list. For instance, IPV:CAL in the header means the IP was on the admin’s IP Allow List (skipping spam filtering)[2], whereas IPV:NLI means the IP had no negative listing (not on known blocklists)[1][2].
    

  • CAT (Category) – Indicates which protection policy category was triggered[2]. Examples: CAT:SPM for spam, CAT:PHSH for phishing, CAT:HPHISH for high-confidence phishing, CAT:BULK for bulk mail, etc.[2]. This helps identify what type of threat (spam, phishing, malware, etc.) the system associated with the message. If multiple filters flag the email, multiple categories might appear here (though only the highest priority policy ultimately determines the action)[2].
    

  • Other fields – There are many other fields in X-Forefront-Antispam-Report (such as DIR for direction, CTRY for country of origin, PTR for reverse DNS, LANG for message language, etc.) which provide context[2][2]. These can sometimes help (e.g. a foreign language or unusual country source might slightly affect spam scoring), but the SCL, SFV, CAT, and IPV are usually most directly relevant to junk/quarantine decisions.

• X-Microsoft-Antispam – Provides additional spam filtering info, notably about bulk mail and phishing confidence[2][4]. It commonly includes:

  • BCL (Bulk Complaint Level) – A score from 0 to 9 indicating how likely the message is bulk mail that recipients might consider unwanted “gray mail.” Higher BCL means more people have complained about similar messages. For example, BCL 0 means not bulk, 3 means a bulk sender with few complaints, and 9 means a bulk sender with a high complaint rate[4]. Administrators set a threshold (default around 7) above which Exchange Online will treat the mail as spam. If a message’s BCL exceeds your tenant’s bulk mail threshold, it can be sent to junk.
    

  • PCL (Phish Confidence Level) – A 0 to 9 score for how likely the email is a phishing attempt[4]. Lower is better; e.g. PCL 2–3 is neutral (likely not a phish), while PCL 4–8 suggests suspicious elements (possible phishing)[4]. A very high PCL might indicate the phishing filters strongly suspect the message.
    

  • Additional info – The X-Microsoft-Antispam header may contain internal identifiers or flags related to spam filtering. Often, however, admins focus on BCL and any mentions of specific filter flags here. (Note: There is also X-Microsoft-Antispam-Message-Info, which is an encoded string of data used by Microsoft – not human-readable – and X-CustomSpam headers added if an Advanced Spam Filter (ASF) rule was triggered[2].)

• Authentication-Results – Shows the results of email authentication checks: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication Reporting & Conformance)[2]. For example, it might contain entries like spf=pass or spf=fail, dkim=pass, dmarc=pass/fail for the sending domain[7]. Failed or missing authentication can increase spam score. For instance, if SPF or DKIM fails, and especially if DMARC policy is reject/quarantine, Exchange Online is more likely to mark the message as spam or quarantine it. Authentication-Results also may include a compauth=pass/fail (composite authentication) which is Microsoft’s overall assessment of authentication (considering SPF, DKIM, and ARC)[7].

• X-MS-Exchange-Organization-SCL and X-MS-Exchange-Organization-PCL – These might appear as separate headers (especially in Outlook.com/Office365 consumer or internal routing) showing the numeric SCL and PCL values in plain form[4]. For example, you might see X-MS-Exchange-Organization-SCL: 5 indicating the spam confidence level is 5 (borderline spam)[7]. These values correspond to the ones in the composite X-Forefront header.

• X-Microsoft-Antispam-Mailbox-Delivery – This header is added when the message reaches the mailbox and informs how it was finally delivered. It indicates if user-level filtering or mailbox rules moved the message to Junk. Key fields within this header include:

  • dest: – The destination folder: usually I for Inbox or J for Junk[4]. If you see dest:J, it confirms the message landed in the Junk folder.
    

  • ucf: – User Controlled Filtering. A value of 1 here can mean the user’s own Safe Senders/Blocked Senders or client-side rules had an effect. For instance, ucf:1 might show the user had a block rule or sender on blocked list, contributing to Junk delivery.
    

  • jmr: – Junk Mail Rule verdict (Outlook’s client-side heuristic spam filter). jmr:1 would indicate the Outlook client (or OWA) junk filter algorithm believed the message was spam. In modern Exchange Online scenarios this is often 0 (since server-side filtering usually dominates).
    

  • auth: – If authentication influenced mailbox delivery. For example, auth:1 could indicate the message passed authentication checks; auth:0 might hint authentication was not satisfied.
    

  • OFR: / RF: – These codes (e.g. OFR:SpamFilterAuthJ or RF:JunkEmail) are internal codes for which spam/filter rule caused the message to go to Junk. They are not well-documented publicly, but they can hint at the reason (such as Outlook’s filtering vs. Exchange Online policy)[7].

Table 1: Common Spam Filter Verdict (SFV) Codes in Headers

SFV Code
Meaning and Action

NSPM
Not Spam – The message passed filtering as non-spam[2]. It was delivered to Inbox (unless something else moved it).

SPM
Spam – The content was flagged as spam by EOP’s content filter[2]. Typically, such messages get SCL 5-9 and go to Junk or Quarantine based on policy.

SKB
Spam (blocked sender) – The message was marked spam because the sender/domain is in a block list (tenant block list in anti-spam policy)[2]. Action is usually Junk or Quarantine per policy.

SFE
Allowed (Safe sender) – Filtering was Skipped because the sender is in a Safe Senders list (user or tenant)[2]. The message is delivered normally.

SKA
Allowed (Admin allow) – Spam filter Skipped because sender/domain is in an allowed list in the anti-spam policy[2]. Delivered to Inbox.

SKN
Non-spam (Bypass) – Message was pre-marked safe (SCL -1) by a rule or previous verdict, so spam filtering was bypassed[2]. Delivered to Inbox.

SKQ
Quarantined – The message was initially quarantined by EOP (e.g. high confidence spam), then later Released from quarantine to the recipient[2][2]. (If you see SKQ, the copy you are inspecting was delivered after a manual release.)

SKS
Spam (via rule) – Marked as spam before normal filtering, e.g. by a mail flow rule that set SCL to spam[2][2]. Treated as spam (Junk).

BLK
Blocked – Filtering skipped because recipient blocked the sender (user’s blocked senders list)[2]. The message was dropped (not delivered to inbox).

SRV:BULK
Bulk mail – The message was identified as bulk mail by EOP and exceeded the bulk threshold, so it was marked spam (usually SCL 6)[2].

Note: These header values reflect what policies were applied. For instance, seeing SFV:SKB (spam due to blocked sender) tells us an anti-spam policy’s block list was applied[2]. Seeing SRV:BULK shows the bulk mail filter policy classified it as spam[2]. In this way, the header lets us infer which filtering mechanism or policy list influenced the decision (content vs. safe/blocked sender lists vs. bulk filter, etc.).

---

Interpreting Headers to Identify Applied Policies

Yes – it is possible to decipher the header to track policies applied and their results. By examining the fields above, you can determine why Exchange Online took a certain action:

• Spam Filtering Policies: The combination of SCL and SFV (and sometimes CAT) reveals the spam filter’s verdict. For example, SCL 9 with SFV:SPM and CAT:HPHISH would indicate the message was judged as high confidence phishing by the anti-phishing policy, likely causing it to be quarantined (since by default high phish is quarantined)[2][2]. If you see SFV:SRV:BULK, it means the bulk mail filter policy (part of anti-spam) marked it as spam[2]. A SFV:SKB result indicates an organization’s Blocked Senders policy blocked it[2]. In each case, the header’s codes map to a specific policy action:

  • Content-based Spam Filtering: indicated by SFV:SPM (spam) vs NSPM (not spam) and the SCL rating[2][2].
    

  • High confidence spam/phish: indicated by very high SCL (usually 9) and possibly category tags like HSPM or HPHISH[2].
    

  • Blocked/Allowed Sender Policies: indicated by SFV:SKB (blocked sender/domain) or SFV:SKA/SFE (allowed sender/domain)[2][2].
    

  • Bulk mail threshold: indicated by SRV:BULK and a BCL value in X-Microsoft-Antispam header[2][4].
    

  • Mail Flow (Transport) Rules: If an admin-created rule set an action, its effect may appear in headers. For example, a rule that sets spam confidence will show an SCL in the header (often along with SFV:SKS if it set SCL 5+)[2]. Some mail flow rules add custom headers or comments; if present, those are visible too. (E.g., a rule could stamp “X-Company-Rule: AutoEncrypted=Yes” or similar – these would be visible if configured, though not default.)

• Authentication Policies: The Authentication-Results header indicates whether SPF, DKIM, and DMARC checks passed. Exchange Online’s spam policy heavily favors authenticated email. If, for instance, SPF and DKIM both failed and DMARC policy was “quarantine/reject,” EOP will likely treat the mail as untrustworthy (often raising the SCL to spam). A header showing spf=fail or dmarc=fail aligns with DMARC enforcement policies being applied. For example, if DMARC says to quarantine and the message fails DMARC, it may go to Quarantine – the header will show DMARC fail, and the SFV might be SPM (spam) as a result. Conversely, compauth=pass with SPF/DKIM pass suggests authentication wasn’t the issue[7], so the spam verdict must have come from content or other filters.

• Anti-Phishing Policies: Exchange Online’s Defender for Office 365 provides anti-phishing protection (impersonation protection, etc.). If those policies trigger, the header may show CAT:HPHISH, CAT:PHSH, CAT:UIMP (user impersonation) or similar categories[2]. There is also a field SFTY (safety) that, when present with values like 9.20 or 9.19, indicates user or domain impersonation was detected by anti-phishing policies[2]. These would correspond to actions like delivering to Junk with a safety tip or even quarantine if configured. For example, SFTY:9.20 combined with a high SCL implies an anti-phishing policy saw user impersonation and likely caused the message to be treated as phish[2].

• Malware/Safe Attachments Policies: Malware detection usually results in outright rejection or quarantine before delivery. If an email was quarantined due to malware, you typically wouldn’t see normal headers in the user’s mailbox (since it never got delivered). However, if you retrieve the header from the quarantine portal or an admin tool, you might see CAT:MALW (malware) or references to the Safe Attachments scanner (ATP) in the X-Forefront-Antispam-Report (CAT:SAP for Safe Attachments policy)[2]. Additionally, an X-Exchange-Organization-AV stamp might indicate malware scan results. These are less commonly examined via header by end-users (since such messages are in quarantine, not in the Junk folder).

In summary, each header field provides clues about which filter or policy acted on the message. By piecing together SCL/SFV (spam filter outcome), CAT (category of threat), authentication results, and other flags, you can often trace the decision path. For example, “Header shows CAT:BULK, BCL:8, SCL:6, SFV:SPM” – this tells us the Bulk mail policy identified it as spam (bulk complaint level high), resulting in spam verdict and Junk delivery. Or “Header shows SPF fail and SFV:SPM” – suggests the message failed authentication and was marked spam by policy (possibly due to failing an anti-spoof or DMARC policy).

Important: The headers do not usually name a custom policy by name (e.g., “Contoso Spam Policy”), but they show the effect. For exact policy names or rule names that triggered, an admin would use the Message Trace or Explorer (discussed below). However, for most purposes the header’s codes are enough to deduce the cause (content, sender reputation, authentication failure, etc.) behind the Junk/Quarantine decision.

---

Step-by-Step Guide: How to Analyze an Email Header in Exchange Online

Follow these steps to examine an email’s header and determine why it went to Junk or Quarantine:

1. Retrieve the Full Message Header:
In Outlook on the web or Outlook client, view the message options to get the internet headers. For example, in Outlook desktop: open the email, go to File > Properties > Internet Headers. In OWA: open the email, click “⋯” (More actions) > View message details. Copy the entire header text.

2. Use a Header Analyzer Tool (Optional):
To make the header more readable, you can use Microsoft’s Message Header Analyzer tool[2]. Microsoft provides an online analyzer (in the Microsoft 365 Defender portal, or via tools like Outlook Message Header Analyzer). Paste the header text into the analyzer – it will format the header into a table and highlight key values (like the SPF/DKIM results and SCL). This is recommended for convenience[2], but you can also read it manually.

**3. Check *Authentication-Results***:
Early in the header, find the *Authentication-Results* line. Examine whether SPF, DKIM, and DMARC passed or failed[7].

• If you see “spf=fail” or “dkim=fail”, that indicates the sender’s domain failed authentication – a red flag for spam/phishing. A DMARC fail (especially with p=quarantine/reject) is even more likely to result in spam or rejection.
  

• If all are “pass”, then you know the decision to junk the email was not due to standard authentication failure (it passed the identity checks).

**4. Locate *X-Forefront-Antispam-Report***:
This header might be long. It usually starts with X-Forefront-Antispam-Report:. Look inside it for key fields:

• SCL: Note the number after SCL:[2]. This is the Spam Confidence Level. Use the value to gauge spam likelihood (-1 means trusted, 0-1 not spam, 5+ likely spam[4]). For instance, SCL 5 or 6 means it was probably sent to Junk, 9 often means quarantined (if high confidence spam/phish).
  

• SFV: Find the SFV: code[2][2]. Use Table 1 (and the definitions above) to interpret the verdict. Key outcomes: NSPM (not spam, should go to Inbox), SPM (spam content), SK codes (indicate skipped or pre-marked by safelist/block or rules), BLK (blocked by user). This tells you why the filter classified it as it did. For example, SFV:BLK means a user blocked the sender[2]; SFV:SKB means your tenant block list caught it[2]; SFV:SPM means it simply looked like spam to the filter[2].
  

• CAT (Category): If present, see what category tag is there (SPM, PHSH, BULK, etc.)[2]. This shows the type of filter/policy. E.g. CAT:PHSH would hint a phishing policy trigger.
  

• Other values: Check for IP reputation indicators like IPV:. If it’s IPV:CAL (IP allowed) or IPV:NLI (not on blocklists)[2], that tells you the sending IP wasn’t blacklisted in connection filtering[1]. If neither CAL nor NLI is present, the IP might have a poor reputation (which can contribute to spam scoring). Also note PTR (reverse DNS) and CTRY (country) if relevant, though these are just informational.

**5. Examine *X-Microsoft-Antispam*** (and related):
Look at X-Microsoft-Antispam and potentially X-MS-Exchange-Organization-SCL/PCL lines if they exist:

• Note the BCL value in X-Microsoft-Antispam (e.g., BCL:8). If BCL is high (above ~7) it means Microsoft considered it bulk mail with many complaints[4]. This often causes the mail to go to junk if your spam policy is set to mark bulk mail as spam (which is default). A low BCL (0-3) means bulk mail but low complaints[4].
  

• If present, note the PCL (Phish Confidence Level) header or value. A higher PCL (like 4-8) suggests the content resembled phishing[4], which may have contributed to a higher SCL.
  

• Check for X-Microsoft-Antispam-Mailbox-Delivery header and find dest:. If it says dest:J, that confirms the message ended in Junk folder[4]. This header also shows if user’s Safe Senders/Blocked Senders had any effect (ucf: field) or if Outlook’s client filter (jmr) was involved. For example, ucf:1 means the user explicitly blocked the sender or domain in their mailbox settings, which would send even a benign email to Junk. On the other hand, ucf:0; jmr:0; auth:1; dest:J (as in a sample above) means the system (server) decided on Junk despite no user rule, likely due to server spam verdict[7].

6. Identify the Trigger:
With the above information, deduce which policy or mechanism “tipped the scales.” For instance:

• If authentication failed (Step 3) and you see a spam verdict, then the lack of proper auth might be the key reason (especially if SFV=SPM with no other obvious cause, or SFV has an “Auth” related code like OFR:SpamFilterAuthJ in mailbox delivery[7]).
  

• If SFV indicates a safelist/blocked list, then a user or admin safe/blocked sender policy applied. E.g., SFV:SKA or SFE means it bypassed spam filtering due to safelist[2], whereas SKB means a block list caught it[2].
  

• If BCL is high and SRV:BULK is present, then the Bulk mail filter policy marked it as spam due to being bulk mail[2].
  

• If CAT or SFTY indicates phishing (or SCL = 9 with PCL high), it’s likely an anti-phishing policy triggered (like impersonation protection).
  

• If none of these stand out except a moderately high SCL (e.g. 5 or 6) and SFV:SPM, it might just be the general content filter (Spam Filter Policy) that decided the email content looked spammy (common for typical junk mail). Microsoft’s filters consider many things (keywords, links, sender reputation, etc.) to assign SCL.

7. Consult Message Trace (if needed):
The header analysis usually tells the story. However, for further confirmation, an Exchange Message Trace or the Microsoft 365 Defender “Threat Explorer” can be used by an admin. These tools can show the exact policies and actions applied to the message (e.g., “Anti-spam policy ‘Default’ applied, action: Moved to Junk”, or “High Phish detected, action: Quarantined”). Message Trace isn’t a header, but it’s a complementary step if header info is unclear. (For example, if you saw a header with SCL 5 but aren’t sure why, the trace might say “Spoof intelligence: Phish” or similar reason.)

8. Verify Quarantine Scenarios:
If the email was quarantined (never reached the mailbox), you typically won’t have the header in your inbox. Admins can view the header via the quarantine portal by previewing the message details. The analysis approach is similar: check the same fields there. Often quarantine happens for higher-severity threats: e.g., malware (virus), high confidence phishing, or admin policies set to quarantine certain spam. In such cases, the header’s SFV might not be visible (since it didn’t go through to the mailbox), but the admin portal will directly state the malware or phish policy that acted. For Junk vs Quarantine: by default, Exchange Online will send most spam to Junk, but “High confidence spam” or certain phish gets quarantined. So an SCL of 9 with PHISH category likely equals quarantine. Understanding this default behavior helps interpret the header’s implications.

9. Summarize the Findings:
After parsing the header, you should be able to answer: Why was this email marked spam? Perhaps the SPF failed and the domain had no reputation (so it got SCL 5), or the sender was on a blocklist, or the content was suspicious. Document the specific indicators from the header:

• e.g., “The header shows SCL:6 and SFV:SPM, meaning Exchange Online’s spam filter flagged the content as spam[2]. Additionally, PCL:5 in the X-Microsoft-Antispam header suggests it had phishing-like content. Therefore, the email was sent to Junk by the spam/phishing content filter.”
• Or “SFV:SKB is present, which indicates our tenant’s Blocked Senders policy blocked the email[2]. The sender’s address or domain must be in the block list, causing the message to be routed to Junk.”
• Or “Authentication-Results show SPF failure, and the header has CAT:SPOOF – this suggests the anti-spoofing policy kicked in and spam-filtered the message (possible DMARC/anti-spoof enforcement).”
• If multiple factors appear (e.g., bulk mail that also failed SPF), note all contributing factors.

By carefully stepping through these checks, you can decipher the header and pinpoint the reason for the spam/junk verdict or quarantine.

---

Tools and Methods for Header Analysis

Microsoft provides several tools to help interpret message headers and track policy actions:

• Microsoft 365 Message Header Analyzer: As mentioned, this tool can parse raw headers into a readable format[2]. It’s available through the Microsoft 365 Defender portal (Security Center) under Threat Analysis tools, or via standalone web tools. It will highlight fields like SCL, spam verdict, and authentication results, saving time. Using it can directly answer questions like “was this marked as spam and why” without manually decoding every acronym.

• Exchange Admin Center – Message Trace: The Exchange Message Trace utility allows administrators to trace an email’s journey. A message trace for the email in question will show events and policies, e.g., “Delivered to Junk Folder” or “Quarantined by policy”, along with any transport rule actions. While not as detailed as headers in terms of spam score, it can list which Anti-Spam policy (content filter policy) applied and what action it took. Message Trace also shows if a mail flow rule was triggered.

• Threat Explorer (Microsoft Defender for Office 365): If your organization has Defender for Office 365 (Plan 2 or E5), the Threat Explorer (or real-time detections) tool can be very insightful[3]. It can show why a message was categorized as it was (e.g., it might explicitly say “Phish confidence high” or “User impersonation detected”). Threat Explorer surfaces the same info contained in headers but in a user-friendly way, and is great for investigating phishing/spam incidents[3]. It even allows viewing the headers and some content of the message in a secure way.

• PowerShell (Get-MessageTrace / Get-QuarantineMessage): For advanced admins, PowerShell cmdlets can retrieve trace details or quarantine info, which might include some header fields or policy names.

• Third-Party Header Analyzers: Tools like MXToolbox’s header analyzer or other online parsers can also decode routing and spam headers. They might not understand every Microsoft-specific field, but they will list them out clearly and flag obvious issues (like a large time gap in a Received chain, or a fail in SPF).

Note: Standard email clients (Outlook) don’t interpret these headers for you – they simply act on them (e.g., if SCL>=5, Outlook will put it in Junk automatically). So, the above tools are needed for humans to decode the headers.

---

Common Reasons Emails Go to Junk/Quarantine (Shown by Headers)

By reviewing many such headers, administrators find recurring causes for legitimate emails being misclassified. Some common reasons (and how they appear in headers) include:

• Failed Authentication: A legitimate sender’s email fails SPF or DKIM (e.g., due to misconfigured DNS records or sending on behalf of another domain). The header shows spf=fail or dkim=fail, and often the spam filter reacts with SFV:SPM or CAT:SPOOF. For example, if an email from [email protected] comes through an unexpected server, SPF might fail and Exchange Online thinks it could be a spoof. Ensuring SPF/DKIM are set up correctly for all sending services will prevent this.

• IP or Domain Reputation Issues: Even if authentication passes, the sender’s IP or domain may have a poor reputation. In the header, you might see no IPV:NLI (meaning the IP could be on a watchlist) and a high SCL. Or the BCL could be high, indicating many recipients marked messages from that sender as spam in the past[4]. Also, X-Forefront-Antispam-Report sometimes has an SFS field (Spam Filter Score) internally reflecting rules matched. Solution: The sender might need to improve their sending practices, or you may add them to a safe senders list if you trust them.

• Bulk (Graymail) Filtering: The email might be a newsletter or bulk notification that isn’t strictly malicious but is considered unwelcome. Headers will show a high BCL and SRV:BULK with SCL around 6[2]. By default, Exchange Online will send bulk mail above the threshold to Junk. Solution: If this bulk sender is desired, the admin can raise the bulk threshold or add that sender to the allowed list; individual users can also add to Safe Senders (which would give future messages SCL -1, bypassing spam filter[1]).

• Content Triggers (Spam Keywords/Patterns): The email content might contain phrases or styles that the spam filter flags (e.g., too many marketing phrases, suspicious links, formatting resembling phishing). This results in SFV:SPM with a moderate SCL (5-7) and no special safe/blocked indicators. Essentially, the filter’s AI said “this looks spammy.” Solution: If you control the sending content, avoid spam-like features; if you’re the recipient admin and it’s false positive, you might loosen the spam filter aggression slightly or create a rule to trust that sender/content.

• Phishing Detection: If an email tries to impersonate your organization or a VIP, the anti-phishing policies might catch it. The header could show SFTY:9.20 (user impersonation) or CAT:UIP (user impersonation) and an SCL of 8 or 9[2]. It will almost certainly go to Junk or quarantine. Example: an attacker impersonates your CEO’s name – Defender for O365 flags it. Solution: Ensure anti-phishing policies are tuned (so they don’t false-positive on legitimate emails) and educate users. If it’s a false positive (e.g., a vendor coincidentally has the same name as your CEO), you might need to adjust allowed sender lists in the anti-phish policy.

• User/Administrator Filtering Rules: Sometimes the cause is outside of EOP’s automatic filters. A user might have accidentally added the sender to their Blocked Senders list, which forces even genuine emails to Junk. In the header, SFV:BLK will appear in such a case[2]. Alternatively, an admin might have created a mail flow rule that flags certain content and sets SCL to 9 or redirects to quarantine. In these cases, the header can still reveal it: a mail flow rule can add an identifiable header or you might see SFV:SKS (spam via rule)[2]. Solution: Check user’s Outlook junk settings and admin transport rules if a particular pattern of false positive keeps occurring.

• Spoofing and Safety Tips: Exchange Online has anti-spoof measures. If an external email claims to be from your domain or a similar domain, it might get flagged (CAT:SPOOF or an SFV:SPM with compauth=fail). Additionally, first-contact safety tips (SFTY:9.25) don’t directly junk a message, but indicate the system’s caution[2]. Such headers show the protective features at work.

By recognizing these patterns in the headers, administrators can address the root cause (whether that’s fixing the sender’s SPF record, or updating a safe sender list, or modifying a rule, etc.).

---

Using Headers for Troubleshooting and Improvement

Email headers are invaluable for troubleshooting delivery issues. An administrator can use them to answer: “Was my email blocked by a policy? Or was it something about the content?” Here are some best practices and tips:

• Always start with header analysis for spam issues: When a user says “Email from X is going to Junk,” grab the header from that junk email. The header provides a transparent view of Exchange Online’s verdicts[2]. This is often quicker than guessing which policy might be responsible.

• Correlate header info with policy settings: For example, if the header shows BCL 7 and got marked as spam, check your tenant’s Anti-Spam policy Bulk mail threshold. If your threshold is 5, that explains it – maybe you’ll decide to bump it higher if too many wanted newsletters are going to Junk. If the header shows SFV:SKB (blocked sender by organization)[2], you know to check the tenant block sender list in your spam policy settings.

• Authentication issues: If you see the sender failing SPF or DMARC, you might reach out to that sender to inform them, or as a temporary measure add them to the allow list if you trust them (to bypass spam filtering until they fix their SPF). But be cautious – only bypass if you are confident it’s a false alarm and not a genuine threat.

• False Positives vs. False Negatives: Headers help with both. For a false positive (good email marked spam), the header tells you why, so you can adjust filters or add an exception. For a false negative (spam delivered to Inbox), a header might show a low SCL and SFV:NSPM – meaning the system thought it was fine. In such cases, you might tighten policies or add specific block rules. (For instance, if phishing got through with PCL 3 and SCL 1, maybe enable stricter anti-phishing measures.)

• Improving filtering: Over time, track headers of spam that got through and legit mail that was junked. You may spot patterns – e.g., many false positives have a particular link or triggering content: you could adjust the allowed domains or train users to use the “Not Junk” button which sends feedback to Microsoft. Microsoft’s filtering AI does adapt to feedback and to widespread trends, but tenant-level tweaks are sometimes needed.

• User education: Encourage users to use the “Mark as not junk” option for legitimate emails in Junk. This action in Outlook not only moves the mail but also can inform the system (especially if you have the user submission feature enabled)[6]. The header of a user-reported message can then be reviewed by Microsoft to adjust tuning. On the flip side, remind users not to indiscriminately trust emails just because they passed SPF – show them how to read the warnings (Exchange will sometimes include a warning in the message if it suspects phishing, via a safety tip banner).

• Limitations of header analysis: While headers are powerful, be aware of their limits. Encrypted emails (e.g., using end-to-end encryption) might not have full scanning results if they weren’t scanned. Also, some advanced threats might only be identified by attachment sandboxing or time-of-click URL detonation (these results might not reflect in the header at delivery time – e.g., an email could be delivered, then later a Safe Attachments scan finds malware and quarantines it after delivery, which wouldn’t retroactively change the original header). For those scenarios, you rely on the Defender portal alerts rather than header. Additionally, as noted, headers won’t name custom policies; they just show outcomes. If you have multiple spam policies (say different ones per domain), the header won’t tell you which one applied – you infer it based on the recipient or you check message trace.

• Document and reference: When solving a spam issue, it’s helpful to copy the header fields into your helpdesk notes. That way, if a similar issue arises, you can compare. For example, “Last month, company X’s emails were getting SCL 5 due to SPF fail – we added them to allowed senders as a workaround.” This builds organisational knowledge on filtering quirks.

• Keep learning and updating policies: Microsoft’s filters evolve (they release updates frequently), so what was once delivered might suddenly start going to Junk if new spam rules catch something in the content (as was likely the case in a Spiceworks forum example where Office 365 started blocking previously accepted emails[5]). Thus, ongoing monitoring of headers and updating of allow/block lists, spam policy thresholds, etc., is part of email administration. Use headers to verify if a change in Microsoft’s filtering is affecting you, and then adjust accordingly or contact Microsoft support with evidence if needed.

Finally, if in doubt, leverage Microsoft resources: The Microsoft documentation on anti-spam headers provides reference for each field[2], and communities (Microsoft TechCommunity, forums) often have discussions decoding specific header codes. With practice, reading an Exchange Online header becomes second nature and is a reliable way to track the policies and filters at work on any given email.

---

Additional Resources

• Microsoft Learn – Anti-spam message headers in Microsoft 365[2] – Official documentation listing all the X-Forefront-Antispam-Report and related header fields and their meanings (great for reference).
  

• Nylas Guide – Deciphering spam headers for Office 365[1] – A practical tutorial on reading spam header values (with common codes like IPV, SCL, SFV explained in plain language).
  

• Spam Resource Blog – Decoding hidden spam headers[4] – An article explaining SCL, PCL, BCL, and the X-Microsoft-Antispam-Mailbox-Delivery fields, with examples.
  

• Practical 365 – Tracing Junk Mail in Exchange Online[3] – Discusses tools like message trace and Explorer for investigating spam/junk issues.
  

• Microsoft Tech Community forums/Q&A – There are Q&A posts where Microsoft engineers or experts have explained specific header lines (for example, the meaning of OFR:SpamFilterAuthJ or other cryptic flags). These can be useful if you encounter an unfamiliar code in a header.
  

• Exchange Online Protection Overview – For understanding the overall spam filtering and policy configuration that leads to these headers (Microsoft Docs on Anti-spam and Anti-phishing policy setup). Knowing what options admins have (like adjusting thresholds or actions) helps interpret why an email went to Junk versus Quarantine.

By leveraging the information in email headers and the resources above, administrators can confidently decipher why an email was classified as spam and take appropriate action – whether that’s adjusting a policy, informing the sender to fix their setup, or simply reassuring the user that the system is working as intended to filter threats. The header is essentially the “log file” of the email’s evaluation, and with the guidelines in this report, you can read that log to track the policies applied and their results. [2][1]

References

[1] Deciphering spam headers for Office365 recipients – Nylas

[2] Anti-spam message headers – Microsoft Defender for Office 365

[3] Using Advanced Message Tracking to identify Junk-Mail and Spoof …

[4] Microsoft: Decoding hidden spam-related headers

[5] email getting filtered as spam on 365 all of a sudden. Advice?

[6] (False Positives) How to handle legitimate emails getting blocked from …

[7] My emails are marked as SPAM in Outlook and Office365