Skip to Main Content

Provider deliverability · Microsoft 365 / Exchange Online

What does the X-Microsoft-Antispam-Message-Info header mean?

Samuel Chenard

By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed September 19, 2026

X-Microsoft-Antispam-Message-Info is an encoded diagnostic value Microsoft 365 stamps on mail, and Microsoft publishes no decoder for it. It cannot tell you why your message was junked. The published verdict lives in X-Forefront-Antispam-Report (CAT, SFV, SCL, DIR) and in the compauth result inside Authentication-Results.

The 30-second check

You do not need to decode the message-info blob, because the fields that carry a documented meaning sit in the same header block. Open the free email header analyzer and paste in the full internet header from a message that landed in Junk. It parses the Authentication-Results line and the X-Forefront-Antispam-Report fields, which is where Microsoft records what actually happened.

Check your domain now

Enter your sending domain and the check runs instantly on the next page. Free, no signup.

What Microsoft 365's anti-spam headers do and don't tell you

FindingWhat it means
The message-info value is not a readable spam scoreMicrosoft's anti-spam header reference describes X-Forefront-Antispam-Report field by field, and describes exactly one field of X-Microsoft-Antispam: BCL. It states that other fields in that header "are used exclusively by the Microsoft anti-spam team for diagnostic purposes". X-Microsoft-Antispam-Message-Info is not documented as a readable field anywhere in that reference, and Microsoft publishes no decoder for it (checked 2026-09-02).
Composite authentication failed, and compauth says soAuthentication-Results carries a compauth value with a three-digit reason code, which is the field a sender should read first. Microsoft documents 001 as implicit authentication failure where the sending domain published no authentication records or only weak ones (SPF ~all or ?all, or DMARC p=none), and 000 as a DMARC fail against a p=quarantine or p=reject policy.
The CAT field names what filtered the messageCAT records the threat policy category applied, with documented values including SPM (spam), HSPM (high confidence spam), PHSH (phishing), HPHSH or HPHISH (high confidence phishing), SPOOF (spoofing), and BULK. Microsoft's own guidance is to use CAT and DIR to understand how a message was filtered, because those values, not the message-info blob, reflect the verdict.
It was graded bulk rather than spamSRV:BULK in X-Forefront-Antispam-Report means spam filtering identified the message as bulk email against the bulk complaint level threshold. BCL in X-Microsoft-Antispam carries the value: 0 means not from a bulk sender, 1 to 3 few complaints, 4 to 7 a mixed number, 8 and 9 a high number. The default threshold is 7 in the default and new anti-spam policies, 6 in Standard preset, 5 in Strict preset.
A recipient-side list or mail flow rule decided itSeveral SFV values mean the recipient organization made the call rather than the filter: SFV:SKB for a match on the blocked senders or blocked domains list in an anti-spam policy, SFV:BLK for a user's Blocked Senders list, and SFV:SKS for a message marked as spam before filtering, either by a mail flow rule that set the SCL or by a spam decision passed in from on-premises Exchange in a hybrid deployment. No sender-side change moves those.
The headers name nothing, and you send over 5,000 a day to Outlook.comMicrosoft counts a sender as high volume at 5,000 or more messages a day to its consumer services using the same domain in the 5322.From address. Those senders must pass SPF and DKIM, publish a DMARC record, and have SPF or DKIM aligned with the From domain. Non-compliant mail is junked with nothing in the headers to distinguish it, and Microsoft's rejection for this is 550 5.7.515; the bulk-sender section below has the full requirement.

Confirm the pattern in Microsoft 365's own sender data

Microsoft 365 publishes its own sender data separately from your DNS. Use it to confirm the provider-side symptom after you have checked the public authentication records below.

Microsoft Smart Network Data Services public landing page with sender IP data and access options.
Source: Microsoft, “Smart Network Data Services”, checked 2026-07-29. Public live-tool capture, reused unchanged with attribution.

Read the verdict Microsoft 365 recorded

The header analyzer above reads the verdict Microsoft 365 already recorded. It will not tell you what Microsoft 365's private reputation data says about your domain, but it names which of its checks this message actually failed, before you change anything on a sending platform.

Palisade Email Security Score result showing public DMARC, SPF, DKIM, MX, and reputation checks for a non-sensitive test domain.
Source: Palisade, “Email Security Score”, checked 2026-07-29. First-party public tool result for a non-sensitive test domain; it checks public DNS and reputation signals, not private mailbox placement.

How to fix it, step by step

  1. Paste the full header into the analyzer and ignore the message-info blob

    Use the free tool above, or open the email header analyzer page directly with the complete internet header from a message that went to Junk. In Outlook you get it from File then Properties then Internet headers; in new Outlook and Outlook on the web, More actions then View then View message details.

  2. Read compauth and its reason code first

    In Authentication-Results, compauth=fail with reason=001 means the sending domain published no authentication records or only weak ones. reason=000 means a DMARC fail against a p=quarantine or p=reject policy. A 1xx reason means composite authentication passed and the junking came from somewhere else.

  3. Read CAT and SFV in X-Forefront-Antispam-Report

    CAT names the category that acted (SPM, HSPM, PHSH, SPOOF, BULK and others). SFV says whether filtering was skipped, honored a rule, or made the decision itself. Together they separate a filter verdict from a recipient-side list, which are different problems with different owners.

  4. Fix the authentication the compauth result points at

    Add every sending service to your SPF record and sign with DKIM using your own domain, then confirm the passing domain aligns with your From address. Verify both with the free SPF and DKIM checkers, since alignment is what DMARC and Microsoft's composite check both evaluate.

  5. Check the sending domain against Microsoft's high-volume bar

    Run the domain through the Microsoft compliance checker. It checks SPF, DKIM and DMARC against the requirements Microsoft applies to senders of 5,000 or more messages a day to Outlook.com, Hotmail and Live addresses.

  6. Separate a bulk verdict from a spam verdict

    If SRV:BULK is present or BCL is at or above the recipient's threshold, the message was graded gray mail, not spam. That is a list hygiene, consent and frequency problem. Cleaning content or adding DNS records will not move a BCL.

  7. Escalate recipient-side blocks to the recipient's admin

    SFV:SKB, SFV:BLK and SFV:SKS are decisions inside the recipient's tenant. Send the timestamp, the sending IP from CIP, and the SFV value to their email admin, who can see the matching policy or rule. There is no sender-side fix for these. SFV:SKN is the opposite and worth knowing: Microsoft documents it as a message that bypassed spam filtering because of a mail flow rule, so if you see it, the junking did not come from the spam filter at all.

Related free tools: Microsoft compliance checker · DMARC checker · SPF checker · DKIM checker

If you send in volume: Microsoft 365's published rules

Microsoft defines a high-volume sender as one sending 5,000 or more messages to its consumer email services using the same domain in the 5322.From address. Those senders must have SPF and DKIM both passing for the domain, must publish a DMARC record with a valid policy (Microsoft's own example is v=DMARC1; p=none), and must have at least one of SPF or DKIM aligned with the domain in the 5322.From address. Microsoft's support article for the resulting bounce quotes the string "550 5.7.515 Access denied, sending domain <domain> does not meet the required authentication level." The Outlook.com Postmaster site records the change as effective 5 May 2025, with non-compliant mail routed to the Junk folder. Per Microsoft's documentation, checked 2026-09-02.

Check your standing with Microsoft 365

If it bounces instead: the codes Microsoft 365 returns

Spam placement returns no SMTP error, so these are the readings and codes you see when Microsoft 365 refuses the mail instead. Match yours below; where a code has a full guide, it is linked.

The real root cause: unenforced authentication

Reading Microsoft's headers is diagnosis, not repair. Once you skip past the opaque message-info value and read compauth, the same answer keeps appearing: the sending domain is not authenticated in a way Microsoft can verify against the From address. SPF passes for a service you forgot to list, DKIM signs with a vendor's domain instead of yours, or DMARC sits at p=none where Microsoft's reason code 001 treats it as a weak policy. Fixing that is a DNS and vendor-configuration job, not a content job. Collect DMARC aggregate reports, authenticate every service the reports reveal, then move the policy from p=none through quarantine to p=reject so mail forged in your name never reaches an Outlook filter to be scored in the first place. Monitoring shows you which senders fail; enforcement is what makes the header read compauth=pass and stay that way.

DMARC software that does the work

Palisade's AI agent takes domains all the way to enforcement: hosted SPF, DKIM, DMARC, and MTA-STS records on paid plans, DMARC reports monitored continuously, and every policy step drafted for your approval on the way to p=reject. The full product is open for a 15-day trial, and nothing is charged until it ends.

Get startedBook a demo

15-day full-product trial. Nothing is charged until it ends.

Fixing this across every client domain

Every client domain gets its own composite authentication verdict at Microsoft, so header triage across a fleet is the same investigation repeated per tenant, usually starting from a helpdesk ticket that says nothing more than "our email goes to junk". Palisade collapses that into one view: it hosts and manages the SPF, DKIM, DMARC and MTA-STS records for each client domain, reads the aggregate reports to name the senders that are failing before anyone opens a ticket, and proposes the next policy step for each domain with your team approving each change. Native ConnectWise, HaloPSA and Autotask integrations put the tickets where your techs already work, pricing is per client domain with rates that improve as the portfolio grows, and your own MSP domain is a free NFR domain to run the process on first.

Questions readers ask

Frequently asked questions

Can I decode X-Microsoft-Antispam-Message-Info?

No public decoder exists for X-Microsoft-Antispam-Message-Info. Microsoft's anti-spam header reference documents the fields of X-Forefront-Antispam-Report and the BCL field of X-Microsoft-Antispam, and says the remaining fields are used only by its own anti-spam team. Treat the message-info value as opaque and read the documented fields instead.

Is X-Microsoft-Antispam-Message-Info documented anywhere by Microsoft?

X-Microsoft-Antispam-Message-Info appears in one place in Microsoft's documentation: the requirements for user-reported messages sent to a reporting mailbox, where it is listed as a required header alongside Message-Id, X-Ms-Exchange-Organization-Network-Message-Id and X-Ms-Exchange-Crosstenant-Id, with the note that it "should be a valid header".

What is the difference between X-Microsoft-Antispam and X-Forefront-Antispam-Report?

X-Microsoft-Antispam carries additional information about bulk mail and phishing, and Microsoft documents only its BCL field. X-Forefront-Antispam-Report carries information about the message and how it was processed, and Microsoft documents many fields including CAT, SFV, SCL, DIR, CIP, CTRY, IPV, SRV and SFTY.

Which header field tells me why Microsoft junked my email?

CAT in X-Forefront-Antispam-Report names the category that acted on the message, and SFV says whether filtering was skipped or honored a rule. Microsoft's own guidance is to use CAT and DIR to understand how a message was filtered. Then read compauth in Authentication-Results for the authentication verdict.

What does compauth=fail reason=001 mean?

compauth=fail with reason=001 means the message failed implicit authentication: Microsoft documents this as the sending domain having published no email authentication records, or having published a weaker failure policy such as SPF ~all or ?all, or a DMARC policy of p=none. It is the most common result behind sender-side junking.

Does a BCL value mean my email was marked as spam?

No. BCL is the bulk complaint level, which Microsoft uses to identify gray mail rather than spam. A message meeting or exceeding the recipient's BCL threshold gets the bulk action from their anti-spam policy, which is delivery to Junk by default. The defaults are 7 in the default policy, 6 in Standard preset and 5 in Strict preset.

How do I get the full internet header from Outlook?

Microsoft documents two paths. In classic Outlook, open the message in its own window, then File, then Properties, and read the Internet headers box. In new Outlook and in Outlook on the web, use More actions, then View, then View message details. Copy the whole block, not just the first lines.

Sources and last verified

Every claim about Microsoft 365 on this page links to the source it came from, each with the date it was last checked. Provider policies change; if a detail looks off, the linked source is authoritative.

Related guides