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 2, 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. Paste the full internet header from a message that landed in Junk into the free header analyzer below. 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.

Why Microsoft 365 / Exchange Online is blocking your email

Likely causeWhat's happening
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 so`Authentication-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 message`CAT` 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 spam`SRV: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 by a mail flow rule that set the SCL. No sender-side change moves those.
You are a high-volume sender to Outlook.com and not compliantMicrosoft 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, and Microsoft's rejection for this is `550 5.7.515`.

Use the provider's own sender surface to confirm the pattern

Microsoft 365 / Exchange Online 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.

Check the public signals before changing settings

Analyze the message header gives you a fast public-DNS baseline. It does not replace the provider's private reputation or placement data, but it tells you whether an authentication problem is visible before you edit 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 at /tools/email-header-analyzer) 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 checkers at /tools/spf and /tools/dkim, 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 /tools/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, SFV:SKS and SFV:SKN 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.

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

If you send in volume: Microsoft 365 / Exchange Online'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 / Exchange Online

Bounce codes you may be seeing

Blocks in this cluster surface as specific SMTP codes. Match yours below; the linked guides cover each code's verbatim provider messages and full fix.

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 Free plan covers one domain and up to 1,000 emails per month, and the agent names every problem it finds there; applying the agent's fixes needs a paid plan, and the full product is open for a 15-day trial.

Get startedBook a demo

1 domain free up to 1,000 emails/month

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 three 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 Microsoft 365 / Exchange Online fact on this page is drawn from that provider's own documentation, last checked 2026-09-02. Provider policies change; if a detail looks off, the linked source is authoritative.

Related guides

Email deliverability, fixed: the full guide