JMRP — Junk Mail Reporting Program

What JMRP is and isn't

JMRP is a feedback loop in the standard email sense: a downstream provider (Microsoft) tells an upstream sender that a recipient flagged their mail as unwanted, with enough information to identify the message. The terminology around feedback loops is inconsistent across providers — Yahoo calls theirs the Complaint Feedback Loop, Comcast historically had a similar product, and "FBL" is the generic term — but the underlying mechanism is consistent: when a user clicks the spam/junk button in their webmail or client, the provider takes the offending message and forwards it back to the sender via a special channel.

JMRP is the Microsoft-specific instance of that mechanism, scoped to consumer mailboxes (Outlook.com, Hotmail, Live, MSN). It is not a reputation dashboard, not a delisting service, and not a content filter — those are different products. JMRP exists to do one thing well: get the offending message back to you so you can take action.

How JMRP works end-to-end

The mechanics from button-click to your inbox follow a predictable sequence.

The flow

1. You send a message from an IP enrolled in JMRP to a recipient at Outlook.com, Hotmail, Live or MSN.
2. The message is accepted at Microsoft's edge (passes SPF, DKIM, basic content filtering) and lands in the recipient's mailbox — Inbox or Junk depending on SmartScreen.
3. The recipient clicks "Junk" or "Report spam" in their webmail, mobile app, or desktop client.
4. Microsoft captures the event, attaches the original message and routing metadata, and forwards it to the JMRP reporting address you nominated at enrolment.
5. You receive the complaint report in a standard Abuse Reporting Format (ARF) wrapper that contains your original message plus structured headers identifying the complaint.

What you actually receive

JMRP reports arrive as multipart MIME messages with three parts: a human-readable summary, the machine-readable ARF report, and the original message that was complained about. The most useful parts in operational terms are:

• The original message body — the campaign, subject line, links, content that triggered the complaint
• The Feedback-Type header — almost always abuse for JMRP
• The Source-IP header — the IP that originally sent the message
• The Original-Mail-From header — the envelope sender (matches your bounce domain)
• The Original-Rcpt-To header — which subscriber complained (the one to suppress)
• The Arrival-Date header — when the original message arrived, useful for correlating with your send logs

Enrolling in JMRP

JMRP enrolment runs through the SNDS portal. You must have an SNDS account, must have verified IP control, and must nominate a reporting address that can receive the volume of complaints your IP generates. The standard sequence: log in using your Microsoft account credentials, provide the required details about the IP addresses you wish to register with JMRP, choose an email address associated with the domain configured in your reverse DNS settings.

The five steps

1. Log in to SNDS with your Microsoft account.
2. Click "Junk Mail Reporting Program" in the navigation.
3. Submit the IP addresses you want to enrol in JMRP (must already be verified in SNDS).
4. Nominate a reporting address. This address must be valid, deliverable, and ideally on a domain whose reverse DNS matches one of your enrolled IPs — Microsoft uses this consistency as part of the validation.
5. Select the complaint format. JMRP offers an ARF-compliant default; specialised formats exist but ARF is the right choice in 2026 unless you have a legacy system that requires a different shape.

Choosing the reporting address

The reporting address is the most consequential decision in JMRP setup. Get it wrong and you either drown a human inbox or quietly drop complaints. The right shape:

• Dedicated inbox, not a person's mail. JMRP feeds can produce hundreds of messages per day on a healthy programme and thousands when something is wrong. Send it to jmrp@yourdomain or similar — not marketing@ or anyone's personal address.
• Parsed by process, not by human. The volume justifies automation: parse the ARF report, extract the original message, look up the recipient identifier from your own tracking, suppress the subscriber, log the campaign for analysis.
• On a domain whose rDNS matches one of your enrolled IPs. Microsoft's validation prefers reporting addresses on domains you clearly control. jmrp@yourdomain.com works; jmrp@gmail.com does not.
• Avoid free webmail. Sending JMRP reports to a free Outlook/Hotmail account is technically allowed but practically a bad idea — the volume can trigger anti-abuse responses on the destination account.

Using JMRP operationally

JMRP is most valuable when it feeds an automated pipeline, not when it lands in a human inbox. The three operations every JMRP processor should perform:

1. Immediate suppression

The single most important action is removing the complaining subscriber from all future sends. A user who clicked the spam button will click it again if they receive another message. Suppress immediately, ideally within minutes of receiving the JMRP report.

2. Source attribution

Beyond suppressing the individual, the report tells you which campaign caused the complaint. Aggregating these signals across days reveals which content, which list segment, or which sender profile is generating disproportionate complaints. Tag every campaign you send with a unique identifier (X-header or unsubscribe URL parameter) and JMRP reports become a stream of campaign-level complaint events you can analyse.

3. Volume threshold alerting

Watch the rate of JMRP reports per IP per day. A normal programme has JMRP reports at the SNDS complaint-rate level — if SNDS reports 0.05% complaint rate and you sent 100,000 messages, JMRP should produce roughly 50 reports. A sudden jump from 50/day to 500/day means a campaign that just went out is causing trouble, and you have 24–48 hours before SNDS reflects the same picture (the data lag covered in our SNDS entry).

The recipient-address redaction problem

Microsoft's JMRP redacts the recipient address in the complaint report. Other major FBLs do not — Yahoo's FBL returns the full address, for example. The redaction is a deliberate privacy choice by Microsoft but creates an operational problem: you cannot suppress a recipient if you don't know who they are.

The standard workaround

Embed a per-recipient opaque identifier inside your message so that when JMRP returns the original, you can recover the identity from your own data. Two patterns:

• Custom X-header. Add X-Subscriber-ID: hash-or-token to every message. JMRP returns it verbatim. Parse it from the report and look up the subscriber in your database.
• Unsubscribe URL tokenisation. Your List-Unsubscribe URL already includes a per-recipient token for unsubscribe linking. JMRP returns the message including that URL, so you can extract the token from there.

JMRP vs other feedback loops

The two FBLs that matter most for senders to consumer audiences are JMRP (Microsoft) and Yahoo's CFL. Gmail does not offer one; Apple does not offer one. For senders whose audience is heavily Gmail-skewed, the absence of a Gmail FBL means complaint visibility depends entirely on Google Postmaster Tools, which gives aggregate rates but no message-level attribution. JMRP's per-message visibility is therefore disproportionately valuable for the Microsoft-heavy slice of any list.

Common JMRP failure modes

1. Enrolment confirmation email never arrives

The verification email goes to a role address (postmaster@, abuse@) on the rDNS domain of your IP. If that role address is unmonitored or non-existent, the enrolment stalls. Check that your abuse@ or postmaster@ addresses are live and have valid MX records.

2. No JMRP reports arriving despite enrolment

Three possible causes: traffic volume to Microsoft consumer addresses is too low to produce statistically observable complaints (under a few hundred per day to Outlook.com); your IP's reputation is clean enough that complaints are genuinely rare; or the reporting address is rejecting Microsoft's mail (anti-spam rule on your receiving server). Test by sending a campaign deliberately to a personal Outlook account, marking junk, and waiting for the report to arrive.

3. Reports arrive but lack the original message body

Microsoft occasionally produces JMRP reports with the original body stripped (truncated or omitted). This is more common for very large messages or messages with unusual MIME structure. The mitigation is to keep messages under 100 KB and to use standard MIME multipart/alternative shape (plain-text + HTML).

4. JMRP feed dropped after the May 2026 SNDS migration

Microsoft warned during the SNDS migration that JMRP feeds not linked to an SNDS account would be removed. If your JMRP enrolment predated SNDS or was created standalone, the feed may have been dropped in the cut-over. Re-enrol via the new SNDS portal.

JMRP in CSE managed infrastructure

Every managed installation we operate ships with JMRP enrolment on the dedicated sending IPs and the reports routed through our complaint-analysis pipeline. The pipeline parses each ARF report, extracts the original message, correlates the campaign ID from our X-headers, suppresses the subscriber across all the client's lists immediately, and logs the campaign-level complaint count for daily reporting.

For senders running their own infrastructure, the standalone JMRP enrolment is straightforward — the parts that get neglected in practice are the automated processing and the per-recipient identifier in outbound messages. Both are operationally mandatory at scale.

Related concepts

• SNDS — the aggregate dashboard JMRP feeds into; SNDS without JMRP gives you rates without source attribution
• Sender Reputation — the broader reputation concept that complaint rate measures one dimension of
• Complaint rate spikes — tracing the source — the operational pattern of using JMRP for source attribution
• Microsoft Outlook policy rejects 2026 — the rejection codes that pair with JMRP / SNDS data
• Spamhaus — the cross-provider blocklist counterpart to Microsoft-specific reputation feedback