Did Microsoft change the JMRP spam complaint report format?
Published 1 Jul 2026
Updated 2 Nov 2026
10 min read
Summarize with
Updated on 2 Nov 2026: We updated our JMRP guidance with current report evidence and checks for reliable complaint matching.
Yes. Microsoft changed the JMRP spam complaint payload in production. The breaking change is recipient redaction, not simply the presence of an ARF wrapper. The proprietary X-HmXmrOriginalRecipient header has disappeared, the To field is masked, and the original message body is no longer dependable for matching. If a complaint processor expects a usable recipient address or message body, treat that parser as broken until current samples prove otherwise.
The format change is already in production. In June 2026 operator samples, redacted reports appeared around June 11. A September operator report also described recipient removal, so do not infer a universal cutover date from one sender's samples. Historical samples can still show the old shape, so tests must use recent reports. A system can look healthy because reports still arrive while complaint matching or suppression has stopped working.
Production risk
A parser can accept a report and store a complaint event while failing to identify the subscriber. That leaves complainers active on the list and risks further unwanted mail.
- Confirm that current JMRP messages use the redacted ARF payload your parser expects.
- Make sure complaints still map to a subscriber, campaign, tenant, and message record.
- Fire an alert when a complaint arrives without a matched internal identifier.
What changed in Microsoft JMRP
Microsoft's Junk Email Reporting Program (JMRP) is a feedback loop (FBL) for spam complaints generated by Outlook.com, Hotmail, Live, and related consumer Microsoft mailboxes. It sends reports about messages users mark as junk. Many senders connect those reports directly to suppression logic.
JMRP used an ARF wrapper before this change. ARF is the Abuse Reporting Format defined by RFC 5965. Redacted samples omit the proprietary X-HmXmrOriginalRecipient header, mask the original To field as "Undisclosed Recipients <X>", and remove the message body. Opaque custom X-headers and the original Message-ID are useful correlation fields when recent samples confirm they survive.
|
|
|
|---|---|---|
Format | ARF with Microsoft-specific data | ARF with recipient and message data redacted |
Original recipient | X-HmXmrOriginalRecipient | Header removed |
To field | Usable address | Masked, for example Undisclosed Recipients <X> |
Message body | Available for token parsing | Removed |
Custom X-headers | Available | Opaque values observed in samples |
Message-ID | Available | Original Message-ID observed in samples |
Envelope sender | Available for VERP matching | Absent from some reports; not a dependable identifier |
Validate these fields against recent raw JMRP samples before changing production logic.
Microsoft SNDS and JMRP portal showing feed format and verification status
JMRP coverage also has limits. In a Microsoft Q&A thread, a sender reported receiving Hotmail and Outlook.com complaints but no report for a Microsoft 365 business domain. This is one sender's test, and JMRP should not be treated as a complete complaint feed for every Microsoft-hosted mailbox.
How to read the JMRP ARF MIME parts
- Read complaint metadata in message/feedback-report. Inspect Feedback-Type, User-Agent and Version; recipient fields are optional.
- Extract original headers from message/rfc822, including reports with an empty embedded body, or text/rfc822-headers.
- Read Message-ID and X-Complaint-ID inside the returned original headers. The outer report's Message-ID identifies the complaint report itself.
- Process folded headers with the MIME library, and preserve unknown fields for diagnosis rather than rejecting the report.
Classifying ARF does not authenticate its sender. Vet the incoming report's origin using your receiving server's authentication results and the configured JMRP feed before automatic suppression. A matching subject or From address is insufficient.
Why JMRP 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 became unsafe when the redacted payload entered production and removed the fields that legacy processors used for list matching.
Legacy parser
- Looks for the complainer in X-HmXmrOriginalRecipient, To, or body text.
- Extracts campaign tokens, account markers, or unsubscribe links from HTML.
- Stores the complaint but leaves the subscriber active when fields disappear.
Redaction-safe parser
- Reads opaque custom X-headers and Message-ID before using fallbacks.
- Maps every send event to exactly one subscriber, with campaign and tenant context.
- Raises a clear exception when no safe identifier can be matched.
Make each outbound recipient copy self-identifying through headers you control, then log those identifiers at send time. When Microsoft returns the original headers, the complaint can map to the send event without the message body or visible recipient address.
Complaint-safe outbound headerstext
Message-ID: <c2a7c43b-6337-4cba-9ea0-845971312f61@mailer.example.com> X-Complaint-ID: 7b8188a5-f452-4d67-a250-347dd32c7b8a X-Campaign-ID: camp_8f2a91 List-ID: billing-updates.example.com
Parser risk by matching method
Risk depends on whether the returned field identifies exactly one recipient.
Opaque header identifier
Low risk
Best primary match when a unique token for one recipient copy is returned.
Message-ID lookup
Medium risk
Useful when each recipient copy has a unique Message-ID recorded in send logs.
Envelope sender
High risk
Return-Path and Original-Mail-From are absent from some current samples.
Recipient address
High risk
Broken when Microsoft removes the proprietary header and masks To.
Body token
High risk
Breaks when the original body is removed.
In September 2026 JMRP samples, Mark Fletcher found no Return-Path, Original-Mail-From or Original-Rcpt-To, while Message-ID and custom X-headers survived. Validate envelope-sender fallbacks against your own feed.
How to design a redaction-safe identifier
A complaint identifier should be opaque and map to exactly one recipient copy. A campaign ID, List-ID or shared Message-ID cannot identify which subscriber complained. Do not place the subscriber's email address in a custom header. Microsoft redacts address-like values in observed reports, and exposing an address in another field defeats the privacy purpose of a blinded feedback loop.
- Generate a cryptographically random token for each recipient copy; do not reuse a campaign-wide value.
- Store the token-to-subscriber mapping and final Message-ID before the message leaves your system.
- Set an explicit lookup retention period that covers the complaint delays your operation needs to handle.
- Delete expired mappings under your send-event retention policy, and alert when delayed reports cannot be matched.
For bulk mail, generate a separate copy for each recipient and log its identifier, as described in Al Iverson's operator example. If a shared identifier leaves several possible recipients, keep the complaint unmatched for investigation. Do not suppress everyone who received the campaign.
VERP needs the same discipline
Variable envelope return path (VERP) can support matching when its opaque token is copied into a custom header. Keep only the local token, without an email address, and retain the send-time lookup. Do not depend on the full envelope sender being returned.
How to update complaint handling
Start with evidence. Pull several recent raw JMRP messages, save the full MIME source, and run them through the production parser. A passing result must return the correct subscriber and send event, including its campaign and tenant context.
- Store raw complaint MIME before parsing so samples can be replayed after code changes.
- Classify reports by MIME structure and Feedback-Type, then validate their origin before acting.
- Match a recipient-specific header token or the original Message-ID recorded at send time.
- Suppress only the uniquely matched subscriber after a validated complaint, and deduplicate repeated reports.
- Track unmatched complaints as a production metric and investigate every increase.
Minimum acceptance test
Given a raw Microsoft JMRP report with X-HmXmrOriginalRecipient removed, To masked, and the original body absent, the parser must resolve exactly one recipient's send event or route the report for investigation. Test shared Message-ID values and missing identifiers. Replaying the same report must not create another complaint or suppression event.
After parser changes, send a controlled message through the same production stream and inspect the final headers. A real inbox test shows which identifiers survive your sending path and checks authentication results. Replay an actual JMRP report separately to verify complaint matching.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Separate feed delivery from parser matching. Confirm that each sending IP range remains linked to the correct SNDS account, the JMRP feed is active, and the complaint mailbox accepts and logs incoming reports. If reports stop, check mail logs and feed status before changing enrollment. Microsoft's SNDS announcement states that network access expires 10 months after approval or migration, so include ownership reattestation in feed-health checks.
Mark Fletcher's September operator report described JMRP messages with Auto-Submitted: auto-generated being discarded by an inbound filter before parsing. Check automated-mail rules on the complaint mailbox and admit verified JMRP traffic. Treat an unexplained drop in reports as a feed-health issue until delivery is confirmed.
ARF ingestion checkstext
1. Save raw MIME. 2. Parse MIME and validate the report's origin. 3. Locate message/feedback-report and the returned original headers. 4. Match a per-recipient X-Complaint-ID or original Message-ID. 5. Suppress only a unique match; deduplicate repeat complaints. 6. Alert on missing, expired or ambiguous matches. 7. Keep samples under your defined retention policy.
How Suped supports complaint investigations
Suped is our DMARC reporting and email authentication platform. Use its reports to investigate sending-source changes and SPF or DKIM failures alongside Microsoft complaint trends. JMRP ingestion and subscriber suppression remain part of your complaint-processing workflow.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
When Microsoft complaints increase, check whether authentication results or blocklist (blacklist) status changed for the same sending stream. DMARC reports and JMRP complaints measure different events; compare them using the same time window.
- Use DMARC monitoring to inspect authentication and sending-source changes during the complaint period.
- Compare complaint trends with blocklist monitoring when a blacklist listing appears.
- Run a domain health checker to investigate SPF or DKIM configuration errors.
- Route issue alerts to a named owner.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
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 opaque send identifiers in headers and retain lookup data for delayed complaints.
Common pitfalls
Recipient-based suppression fails because Microsoft masks the address in complaint copies.
Automated-report filtering can discard valid JMRP mail before the complaint parser sees it.
A parser can accept each report while silently dropping subscriber matches after redaction.
Expert tips
Treat redacted ARF as the production format and keep legacy samples as test fixtures.
Use a unique per-recipient X-header first, then the original Message-ID as a lookup fallback.
Keep ownership clear for SNDS access, JMRP feeds, and incoming complaint mailbox routing.
Marketer view
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 view
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
Validate JMRP matching before the next campaign
Collect recent JMRP samples, replay them through the parser, and calculate the share of complaints that match exactly one subscriber without recipient data. Then alert on unmatched reports, verify SNDS account access, and require a unique identifier on every recipient copy.
Practical target state
A healthy setup accepts verified ARF, stores raw reports, matches each complaint to one subscriber, deduplicates repeat reports, and suppresses confirmed complainers. Missing or ambiguous matches trigger an alert.
Frequently asked questions
Inspect recent raw reports from your own feed. Check the MIME parts and returned original headers, then replay the reports through your parser. Confirm a unique subscriber match without relying on X-HmXmrOriginalRecipient, an unmasked To field or the original body.
No. JMRP used an ARF wrapper before the 2026 change. Recipient redaction and removal of the original message body are the changes that break address-based and body-based matching.
Yes. JMRP still sends reports for supported Microsoft consumer mailbox complaints when the feed is active. It does not guarantee coverage for every Microsoft-hosted business mailbox.
Yes, when each recipient copy carries an opaque token or unique Message-ID that maps to a subscriber in your send logs. Validate the report's origin and suppress only an unambiguous match. A campaign-wide identifier cannot identify the complainer.
Check incoming mail logs, automated-message filtering and active JMRP enrollment. Verify SNDS network access and ownership reattestation. Zero reports do not prove zero complaints; first establish that the feed still reaches the complaint mailbox.
No. Suped's product provides DMARC reporting and email authentication monitoring. JMRP feed ingestion and subscriber suppression need a compatible complaint-processing workflow.
