A message can authenticate successfully and still be classified as unwanted or dangerous. Conversely, a mailbox or filtering exception can affect handling without repairing the sender's authentication. When someone asks why a message went to Junk, collect authentication results and filtering evidence separately, then connect them to the actual delivery action.
Read the current Microsoft guidance
Microsoft's current header reference distinguishes Authentication-Results from X-Forefront-Antispam-Report and X-Microsoft-Antispam. It describes BCL as bulk complaint likelihood rather than domain authentication. It also says that, in cloud organizations, SCL does not determine spam classification or action; CAT and DIR provide filtering context instead. Do not apply an old SCL-to-folder table as a universal cloud decision rule. This does not mean SCL is irrelevant to configuration: Microsoft still documents mail-flow rules that request bypass or spam treatment. The stamped SCL and actual action must be investigated with the applicable rule and categorization context. Microsoft header reference.
SCL remains relevant in on-premises Exchange and some hybrid processing. Establish which product and delivery path produced the field before interpreting it. Microsoft describes SCL in its own product-specific reference, and BCL has a separate reference. Preserve the documentation date because service behavior and explanations can change. SCL, BCL.
Build an evidence table without collapsing meanings
References: RFC 8601 §5, RFC 8601 §7.
Record the receiver's SPF, DKIM and DMARC results with their evaluated domains. In a separate group, record CAT, DIR, BCL and any relevant SFV values exactly as received. Leave undocumented fields uninterpreted. Then add the actual disposition from an authorized trace, quarantine record or mailbox observation. A missing field is an unknown, not a zero or a passing result.
Authenticate the source of these observations. Untrusted messages can carry misleading header text, and a forwarded copy may add or remove information. RFC 8601 describes the need for a trust boundary around authentication results; the same investigative caution applies when someone sends a screenshot of product-specific metadata. RFC 8601 section 7.
Compare a synthetic pair of results
The supplied fixture contains a deliberately invented message with dmarc=pass, CAT:BULK, DIR:INB and BCL:7. It demonstrates coexistence of a protocol pass and a bulk classification. The parser extracts the fields independently. It does not run Microsoft's classifier, establish a real threshold, or predict the folder a recipient would see.
In an actual investigation, retrieve the policy and processing evidence applicable to that recipient at that time. Do not assume that a numeric BCL value always leads to the same action across organizations. A sender may need better audience consent, sending practices or content, while a different case needs an authentication repair. The evidence should identify which task applies.
Change only the responsible layer
References: RFC 9989 §8.
If authentication fails, correct the sending configuration and verify the same route. If authentication passes and a bulk or threat category explains handling, investigate that classification through the receiving organization's supported review process. Never treat an authentication pass as permission to bypass malware, impersonation or spam protections.
Record the old and new evidence after an approved correction. State whether the improvement was an authentication change, a policy change or a new observed disposition. Avoid promising inbox delivery from a single score or changing thresholds for all mail to solve one message.
Read the annotated sample without granting trust
References: RFC 8601 §5.
The retained annotation register lists every raw field in order with its actual generator, claimed origin and trust limit. From is an author-supplied identity; To is a displayed recipient rather than proof of the SMTP envelope. Message-ID, Date and Subject are sender-controlled context. Each Authentication-Results field claims a reporting service and result, but neither trusted.example nor untrusted.example establishes genuine receiver provenance. List-ID names the claimed list; the unsubscribe fields describe an action mechanism, not list ownership. In the classification sample, CAT, DIR, SCL and BCL are invented Microsoft-style verdicts, not observations from Microsoft. No Received chain, SPF envelope identity or connecting IP was established.
Use this map as an annotated teaching example. For a real message, replace each assumed origin with collection and receiver evidence, and leave any unverified boundary explicitly unresolved.