Did Microsoft change the JMRP spam complaint report format?
Published 1 Jul 2026
Updated 1 Jul 2026
9 min read
Summarize with
Yes. Microsoft has changed the JMRP spam complaint report format for at least some senders, and the change is bigger than a cosmetic MIME rearrangement. The practical shift is a move toward ARF complaint reports, with less dependable access to the original recipient address and original message body. If your complaint processor expects the old Microsoft format, or expects a usable recipient address in the forwarded copy, treat that parser as broken until you test it.
I would treat this as a production change with phased rollout behavior. Some senders have still seen the old format while their account was set to ARF, while others have seen the newer ARF-style output and missing recipient details. That mixed state is exactly why silent failures are dangerous. A system can look healthy because reports still arrive, while unsubscribe matching, suppression, or campaign attribution has already stopped working.
Production risk
The dangerous failure mode is not missing email. It is a parser that accepts the report, stores a complaint event, and fails to identify the subscriber. That leaves complainers active on the list, which damages Microsoft reputation and makes later debugging much harder.
- Check: Confirm whether your current JMRP messages are ARF, old Microsoft-style copies, or a mix.
- Verify: Make sure complaints still map to a subscriber, campaign, tenant, and message record.
- Alert: Fire an alert when a complaint arrives without a matched internal identifier.
What changed in the Microsoft JMRP feed
JMRP is Microsoft's feedback loop for spam complaints generated by Outlook.com, Hotmail, Live, and related consumer Microsoft mailboxes. A good plain-language JMRP definition describes it as the mechanism that sends complaints back when a Microsoft consumer mailbox user reports a message as spam. That matters because JMRP was often wired directly into suppression logic.
The old implementation often gave teams enough original-message material to identify the complainer by parsing headers, the forwarded copy, or body markers. The new behavior pushes senders toward ARF, short for Abuse Reporting Format. ARF is a standard feedback report structure, but Microsoft's current rollout has removed or redacted fields that many legacy processors used for attribution.
|
|
|
|---|---|---|
Format | Microsoft copy | ARF parts |
Recipient | Visible address | Redacted |
Body | Parse markers | Unavailable |
Automation | Static pulls | Token expiry |
Feed setup | Legacy feeds | Relinking |
The exact data can vary by sender during rollout, so validate with real inbound JMRP samples.
Microsoft SNDS and JMRP portal showing feed format and verification status
There is also confusion about what JMRP covers. A Microsoft Q&A thread shows a sender receiving complaints for Hotmail and Outlook.com but not for Outlook for Business domains. That matches the operational reality I plan around: JMRP is useful, but it is not a complete complaint feed for every Microsoft-hosted mailbox.
Why parsers started failing
Most failures come from one bad assumption: the complaint report will contain the original message in the same shape it used to. That assumption was fragile even before this change. It became unsafe once Microsoft started sending ARF-style reports and redacting fields that were convenient for list matching.
Legacy parser
- Recipient: Looks for the complainer in To, Delivered-To, or forwarded body text.
- Body: Extracts campaign tokens, account markers, or unsubscribe links from HTML.
- Failure: Stores the complaint but leaves the subscriber active when fields disappear.
ARF-aware parser
- Headers: Reads stable custom headers and message identifiers before using fallbacks.
- Indexes: Maps every send event to subscriber, campaign, tenant, and provider.
- Failure: Raises a clear exception when no safe identifier can be matched.
The fix is not to chase the recipient address in more places. The fix is to make the outbound message self-identifying through headers you control, then log those identifiers at send time. If Microsoft sends back enough of the original headers, you can suppress correctly without needing the body or the visible recipient address.
Complaint-safe outbound headerstext
X-Campaign-ID: camp_8f2a91 X-Message-ID: msg_4c19e0 X-Subscriber-ID: sub_71392 X-Tenant-ID: tenant_42 List-ID: billing-updates.example.com
Parser risk by matching method
Treat body and recipient matching as emergency fallbacks, not primary logic.
Header identifier
Low risk
Best primary match when custom headers are returned.
Message-ID lookup
Medium risk
Useful fallback if message IDs are unique and logged.
Recipient address
High risk
Unsafe when the report uses undisclosed or redacted recipients.
Body token
High risk
Breaks when the original body is removed.
A public SNDS change note also described the early 2026 changes as a move to fully ARF-standardized JMRP reports, with original body content removed and more governance around SNDS-linked feeds. I would not build new complaint processing around body parsing after that.
How to update complaint handling
Start with evidence, not assumptions. Pull a handful of raw JMRP messages, save the full MIME source, and run them through the same parser used in production. I care less about whether the parser returns a green status and more about whether it returns the right internal person, list, campaign, and message.
- Capture: Store raw complaint MIME before parsing so you can replay samples after code changes.
- Classify: Detect ARF by MIME parts, not by sender name, subject line, or mailbox folder.
- Extract: Prefer custom headers, message IDs, and logged send IDs over visible recipients.
- Suppress: Stop mail to the matched subscriber immediately after a confirmed complaint.
- Measure: Track unmatched complaints as a first-class production metric.
Minimum acceptance test
Your parser should pass this test: given a raw Microsoft JMRP report with no usable To address and no original body, it still finds the internal send event or fails loudly enough for an operator to act.
After parser changes, send a controlled message through the same production stream and inspect the final headers. A real inbox test helps confirm that the message keeps the identifiers your complaint process needs, while also checking authentication results.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
The other side of the fix is operational. Check that JMRP feeds are still linked to the right SNDS account, that the mailbox receiving reports is not filtering them, and that automated data pulls have renewal ownership. Public Microsoft support threads have shown 500 and 503 errors around the portal, so keep a manual support path ready instead of assuming a portal failure means your internal setup is wrong.
ARF ingestion checkstext
1. Save raw MIME. 2. Locate message/feedback-report. 3. Read original headers when present. 4. Match X-Message-ID or Message-ID. 5. Suppress the matched subscriber. 6. Alert when the match is missing. 7. Keep the sample for replay tests.
Where Suped fits
Suped does not replace Microsoft JMRP. JMRP is Microsoft's complaint feed, and the sender still needs a parser or platform workflow that can consume those reports correctly. Suped's product is strongest around the broader control plane: DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist (blacklist) monitoring, and alerts that show when authentication or reputation starts moving in the wrong direction.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
This matters because complaint spikes rarely happen in isolation. A Microsoft complaint problem often sits beside authentication drift, a new sending source, SPF lookup pressure, DKIM selector mistakes, or an IP/domain listing on a blocklist or blacklist. Suped gives teams one place to monitor those related signals instead of treating each symptom as a separate investigation.
- Authentication: Use DMARC monitoring to see policy, alignment, and sender-source changes before they become deliverability problems.
- Reputation: Pair complaint trends with blocklist monitoring so a listing does not sit unnoticed while complaint volume rises.
- Validation: Run a domain health checker when a new Microsoft signal appears, then fix the highest-risk records first.
- Operations: Use alerts and issue steps so someone owns the fix instead of relying on periodic manual checks.
For most teams, Suped is the most practical overall DMARC platform because it turns authentication and reputation data into concrete fixes. That does not remove the need to update a JMRP parser, but it reduces the chance that a complaint-feed change is discovered late, after Microsoft reputation has already taken the hit.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If you manage several brands, tenants, or client domains, the multi-domain view is also important. A phased Microsoft rollout means one domain can break before another. I would watch unmatched complaints, DMARC alignment, DKIM pass rates, SPF health, and blocklist or blacklist changes together until the JMRP feed has been stable for several report cycles.
Views from the trenches
Best practices
Save raw JMRP MIME before parsing so changed report structures can be replayed safely.
Track unmatched complaints as production incidents, not as low-priority reporting noise.
Put stable send identifiers in headers and keep lookup tables long enough for late reports.
Common pitfalls
Recipient-based suppression fails when Microsoft hides the address in the complaint copy.
Portal errors can distract teams from checking whether old JMRP feeds need relinking.
A parser can look healthy while silently dropping subscriber matches after format changes.
Expert tips
Treat ARF as the target format and make old Microsoft copies a compatibility fallback.
Monitor old and new JMRP output side by side until every sender stream is verified.
Keep support ownership clear for SNDS access, JMRP feeds, and complaint mailbox routing.
Marketer from Email Geeks says Microsoft appears to be moving JMRP toward ARF, but some accounts still receive older report shapes during the rollout.
2026-06-13 - Email Geeks
Marketer from Email Geeks says there was no clear public notice for the exact parsing impact, so internal alerts and raw sample checks matter.
2026-06-13 - Email Geeks
What to do now
Microsoft changed JMRP in a way that affects real complaint processing. The safest position is to assume ARF is the target, recipient visibility is no longer dependable, and body-based matching is no longer acceptable for production suppression.
The fastest useful audit is simple: collect recent JMRP samples, replay them through your parser, and count how many complaints match a subscriber without using the visible recipient address. Then add alerts for unmatched reports, verify SNDS account linkage, and make header identifiers mandatory for every Microsoft-facing sending stream.
Practical target state
A healthy setup accepts ARF, stores raw reports, matches by stable headers or message IDs, suppresses quickly, and monitors authentication and reputation signals beside complaint volume.
