Did Microsoft change the JMRP spam complaint report format?
Published 1 Jul 2026
Updated 2 Sep 2026
9 min read
Summarize with
Updated on 2 Sep 2026: We updated this guide for Microsoft's redacted JMRP payload and the identifiers that still support 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.
Treat this as a completed production cutover, not a future migration. The redacted payload first appeared on June 11, 2026 and became dominant quickly. Historical samples can still show the old shape, so tests must use recent reports. A system can look healthy because reports still arrive while unsubscribe matching, suppression, or campaign attribution has 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 that current JMRP messages use the redacted ARF payload your parser expects.
- 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 Microsoft JMRP
JMRP is Microsoft's feedback loop for spam complaints generated by Outlook.com, Hotmail, Live, and related consumer Microsoft mailboxes. It sends a report when a user at a supported consumer mailbox marks a message as junk. Many senders connect those reports directly to suppression logic.
JMRP used an ARF wrapper before this cutover. ARF is the Abuse Reporting Format defined by RFC 5965. The production change standardized and redacted the payload. Microsoft removed the proprietary X-HmXmrOriginalRecipient header, changed the original To field to "Undisclosed Recipients <X>", and removed the message body. Opaque custom X-headers and Message-ID remain the strongest correlation options.
|
|
|
|---|---|---|
Format | ARF with Microsoft-specific data | Standardized redacted ARF |
Original recipient | X-HmXmrOriginalRecipient | Header removed |
To field | Usable address | Undisclosed Recipients <X> |
Message body | Available for token parsing | Removed |
Custom X-headers | Available | Opaque values retained |
Message-ID | Available | Retained for lookup |
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. A Microsoft Q&A thread documents reports for Hotmail and Outlook.com complaints but not for a Microsoft 365 business domain. Do not treat JMRP as a complete complaint feed for every Microsoft-hosted mailbox.
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
- Recipient: Looks for the complainer in X-HmXmrOriginalRecipient, To, or 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.
Redaction-safe parser
- Headers: Reads opaque custom X-headers and Message-ID 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 search for the recipient address in more places. Make each outbound message 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
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 recipient and body matching as obsolete, not as primary logic.
Opaque header identifier
Low risk
Best primary match when a unique custom header is returned.
Message-ID lookup
Medium risk
Useful fallback when message IDs are unique and stored with send events.
Envelope sender
Medium risk
Usable with VERP, but its returned location is awkward to parse.
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.
A June 2026 JMRP analysis identified redaction as the material change: X-HmXmrOriginalRecipient disappeared, To became undisclosed, and the body was stripped, while opaque custom X-headers and Message-ID remained useful.
How to design a redaction-safe identifier
A complaint identifier should be unique, opaque, and free of personal data. Do not place the subscriber's email address in a custom header. Microsoft can redact values that look like addresses, and exposing an address in another field defeats the privacy purpose of a blinded feedback loop.
- Generate: Use a random or signed token that cannot be used to guess another subscriber.
- Store: Map the token to the subscriber and send event before the message leaves your system.
- Retain: Keep the lookup longer than the period in which a recipient can submit a complaint.
- Expire: Delete stale mappings under the same retention policy used for send-event data.
VERP needs the same discipline
A VERP token can still support matching, but do not assume the full envelope sender will appear in an easy-to-parse field. Copy only the opaque local token into a custom header and keep the send-time lookup as the source of truth.
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 internal subscriber, list, campaign, and message, not merely accept the report without an error.
- Capture: Store raw complaint MIME before parsing so samples can be replayed after code changes.
- Classify: Detect ARF by MIME parts, not by sender name, subject line, or mailbox folder.
- Extract: Prefer opaque custom headers and logged Message-ID values over recipient data.
- Suppress: Stop mail to the matched subscriber immediately after a confirmed complaint.
- Measure: 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 find the internal send event or fail 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 confirms that the message keeps the identifiers the complaint process needs while checking authentication results.
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 recreating the feed. Microsoft support threads document portal HTTP 500 errors, so a portal failure alone does not prove the internal setup is wrong.
ARF ingestion checkstext
1. Save raw MIME. 2. Locate message/feedback-report. 3. Read original headers when present. 4. Match an opaque X-header 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 or ingest its complaint reports. Suped's product covers the related control work: DMARC reporting, SPF and DKIM checks, hosted authentication, MTA-STS monitoring, blocklist (blacklist) monitoring, and alerts for authentication or reputation changes.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
When Microsoft complaints increase, check whether DMARC alignment, sending sources, SPF lookups, DKIM selectors, or blocklist and blacklist status changed at the same time. Suped keeps those signals in one investigation workflow while the JMRP parser handles subscriber suppression.
- Authentication: Use DMARC monitoring to check policy, alignment, and sending-source changes beside complaint trends.
- Reputation: Pair complaint trends with blocklist monitoring so a blocklist or blacklist listing is investigated promptly.
- Validation: Run a domain health checker when a new Microsoft signal appears, then fix the highest-risk records first.
- Operations: Route issue alerts to a named owner instead of relying on periodic manual checks.
Suped cannot repair a JMRP parser, but it can show whether the complaint issue coincides with an authentication or reputation change. That context helps teams separate a broken feedback-loop workflow from a broader sending problem.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For several brands, tenants, or client domains, compare unmatched complaints with DMARC alignment, DKIM pass rates, SPF health, and blocklist or blacklist changes by domain. One sending stream can expose a parser defect before the others generate enough complaints to reveal it.
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.
Portal errors can distract teams from checking whether an inactive feed needs recreation.
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 opaque X-header first, then Message-ID as a controlled lookup fallback.
Keep 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's redacted JMRP payload affects production complaint processing. Treat X-HmXmrOriginalRecipient as gone, To as masked, and body-based matching as obsolete. Build suppression around an opaque custom identifier or a logged Message-ID.
Collect recent JMRP samples, replay them through the parser, and calculate the share of complaints that match a subscriber without recipient data. Then alert on unmatched reports, verify SNDS account linkage, and require stable header identifiers on every Microsoft-facing sending stream.
Practical target state
A healthy setup accepts redacted ARF, stores raw reports, matches by opaque headers or Message-ID, suppresses confirmed complainers, and alerts when a report cannot be mapped.
