Contents
Why Microsoft monitoring matters
Microsoft consumer mail (Outlook.com, Hotmail, Live, MSN) represents a substantial share of most senders' recipient bases, and Microsoft makes filtering decisions based heavily on sender reputation. The two free tools Microsoft provides, SNDS and JMRP, give senders direct visibility into how Microsoft perceives their sending and direct feedback when recipients complain. An operator running PowerMTA who has not integrated SNDS and JMRP is flying blind on a major portion of their traffic.
This guide exists because Microsoft's tools changed meaningfully in 2025 and 2026, and operators running setups configured before those changes may have stale or broken integrations. JMRP went through a modernization that rebuilt the service and standardized reports to ARF format; the relationship between JMRP and SNDS changed so feeds now link to SNDS accounts; SNDS added authentication requirements for network access approval. An operator who set up SNDS and JMRP years ago needs to verify the integration is still current. The structure: the distinction between SNDS and JMRP, what SNDS actually shows, the enrollment process, the 2026 JMRP modernization in detail, reading SNDS reputation data including the color system, processing JMRP reports into PowerMTA suppression, handling blocked IPs through the support form, the authentication signals Microsoft weighs, and the diagnostic workflow for Microsoft deliverability incidents.
SNDS versus JMRP
SNDS and JMRP are complementary tools serving different functions.
| Aspect | SNDS | JMRP |
|---|---|---|
| Full name | Smart Network Data Services | Junk Mail Reporting Program |
| Function | Reputation monitoring | Complaint feedback loop |
| What it gives you | Aggregate IP reputation data | Individual complaint reports |
| Direction | You pull data from the portal | Microsoft pushes reports to you |
| Granularity | Per-IP aggregate | Per-message individual |
| Cost | Free | Free |
SNDS is the visibility tool: it shows how Microsoft scores your sending IPs, the aggregate picture of reputation, complaint rates, traffic volume, trap hits, and the SmartScreen filter verdict. It is your direct line of sight into how Microsoft perceives your sending behavior, with raw data no third-party platform can replicate.
JMRP is the feedback loop: when an Outlook.com or Hotmail user marks one of your messages as junk, JMRP forwards a copy of that message to a reporting address you control, identifying the complaining recipient so you can suppress them.
The two work together. SNDS shows you the aggregate signal (complaint rates are rising); JMRP shows you the specific instances (these individual recipients complained). An operator uses SNDS to spot trends and JMRP to act on individual complaints. As of the 2026 modernization the two are administered together, with JMRP feeds linked to SNDS accounts.
What SNDS shows
SNDS displays several categories of data per registered IP:
| Data category | What it shows |
|---|---|
| Reputation / filter result | SmartScreen verdict, color-coded |
| Complaint rate | Rate of recipients marking mail as junk |
| Traffic volume | Messages and RCPT commands per IP |
| Spam trap hits | Mail sent to known spam trap addresses |
| IP status comments | Notes like Abuse Reported or JMR Block |
| HELO value | The identifier your server sends at SMTP start |
The filter result is the headline metric: it shows how Microsoft's SmartScreen content filter views your mail, color-coded to indicate the percentage receiving a spam verdict.
The traffic data includes RCPT command counts, and a useful diagnostic is comparing RCPT commands to actual recipients; a high discrepancy can indicate sending to invalid addresses or list quality problems.
The IP status comments are direct signals: an Abuse Reported comment appears when users have submitted spam complaints; a JMR Block comment appears when an IP is blocked due to abuse complaints. A JMR Block is a serious signal requiring the delisting process.
The HELO value shown in SNDS should match your sending domain configuration; a mismatch can signal misconfiguration. For PowerMTA, the HELO corresponds to the smtp-source-host EHLO hostname configured per VMTA.
Enrolling sending IPs
Enrollment goes through the SNDS portal at the Outlook sender support site.
Step 1: sign in with a Microsoft Account. Access SNDS by logging in with a Microsoft Account.
Step 2: request access to your sending IPs. Request access for the IP addresses or IP ranges you are responsible for, the PowerMTA outbound IPs.
Step 3: complete the authorization process. Microsoft runs an authorization process to verify you control the requested IPs. Confirmation is frequently sent to the abuse@ or postmaster@ address for the IP range.
Step 4: ensure abuse@ and postmaster@ are live. Because the confirmation goes to those role addresses, they must exist and have valid MX records. If you do not receive confirmation emails, the most common cause is that abuse@ or postmaster@ for the IP range is not live.
Step 5: configure JMRP within the SNDS portal. Once IPs are registered in SNDS, navigate to the Junk Mail Reporting Program section within the SNDS portal and create a new feed, providing a complaint feedback address you control and actively monitor.
Step 6: wait for data. SNDS dashboards remain empty until you send at least 100 messages per day to Microsoft domains. Below that volume threshold there is not enough data for Microsoft to display. Data appears within a day or two of reaching the threshold, and SNDS retains 90 days of historical data.
A common confusion: after completing SNDS enrollment, the dashboards show nothing, and the operator assumes the setup failed. In most cases the setup is fine and the dashboards are empty simply because the deployment has not yet sent 100 messages per day to Microsoft domains. SNDS needs that volume threshold before it displays data. If you have completed enrollment and see nothing, check your Microsoft-domain send volume before assuming a configuration problem; the data will appear once volume crosses the threshold.
The 2026 JMRP modernization
Microsoft modernized JMRP and updated SNDS through 2025 and 2026, and operators with older setups need to account for the changes.
JMRP rebuilt on a new platform. Microsoft is modernizing JMRP by rebuilding the service on a new platform. Program announcements, updates, and guidance are shared through the SNDS website rather than separately. Operators should keep their SNDS account and contact information up to date to ensure uninterrupted JMRP participation.
JMRP feeds linked to SNDS accounts. JMRP feeds are now linked to SNDS accounts. You cannot set up the feedback loop without first registering your IPs in SNDS. Critically, JMRP feeds that are not linked to SNDS accounts are being removed; operators with old standalone JMRP feeds must recreate them from their SNDS account.
ARF format standardization. JMRP reports are now standardized to ARF (Abuse Reporting Format) on all reports, for consistency and improved processing. ARF is the standard machine-readable complaint format, so this standardization makes JMRP reports easier to process programmatically, consistent with how feedback loops work across the industry.
SNDS authentication for network access. SNDS now requires authentication when approving or denying network access, an extra security layer. The intent is to prevent bots or security scanners from accidentally approving SNDS access requests; a user must be logged in when acting on an approval link.
Complaint sample downloads discontinued. SNDS discontinued complaint sample downloads as part of the changes.
Automated data access changes. SNDS increased protections around automated data access, and automated report links expire after 30 days. Operators using automated SNDS data access should verify their links remain valid and be prepared to recreate them.
URL change. SNDS announced it will move to a new URL as part of an upcoming service update. Operators should watch the SNDS homepage for the updated URL.
The practical implication: an operator who set up SNDS and JMRP before 2025 should log in, verify the JMRP feed is linked to the SNDS account (recreate it if it is a stale standalone feed), confirm contact information is current, and check that any automated data access links are valid.
Reading SNDS reputation data
The SNDS filter result uses a color system indicating the SmartScreen spam verdict:
| Color | Meaning | Response |
|---|---|---|
| Green | Less than 10% of mail flagged as spam | Content filter not the problem |
| Yellow | Middle range, partial spam flagging | Investigate, trend monitoring |
| Red | Over 90% of mail filtered as spam | Immediate action required |
A red result is a serious deliverability problem: SmartScreen is classifying over 90 percent of your mail as spam. The immediate response:
- Check the complaints data to analyze which specific campaigns or messages are causing complaints.
- Review the traffic data, looking for discrepancies such as a high ratio of RCPT commands to actual recipients, which can indicate sending to invalid addresses or list quality problems.
- Verify SPF, DKIM, and DMARC authentication, because Microsoft weights these in evaluating sender trustworthiness.
- Examine the IP status comments for Abuse Reported or JMR Block notes.
An important caveat in the other direction: a green filter result is good news but does not guarantee inbox placement. SmartScreen's verdict is one factor among many, and user behavior, such as recipients moving mail to the junk folder or ignoring messages, can override the filter's decision. Green means the content filter is not the problem, not that everything is fine.
The complaint rate data in SNDS is the early-warning signal. Microsoft, like Gmail and Yahoo, treats complaint rate as a primary reputation input. A rising complaint rate in SNDS, even before it produces a red filter result, is the signal to investigate before deliverability degrades.
Processing JMRP reports into PowerMTA
JMRP forwards a copy of each junk-marked message to your designated complaint feedback address. These reports, now standardized to ARF format, need to be processed so the complaining recipients are suppressed.
The processing pipeline:
Step 1: receive JMRP ARF reports. The complaint feedback address you configured in JMRP receives the ARF reports. This should be a monitored mailbox.
Step 2: parse the ARF reports. ARF is a structured machine-readable format. The report identifies the original message and the complaining recipient. A processing script or the application's feedback-loop handler parses the ARF to extract the complaining recipient address.
Step 3: suppress the complaining recipient. The extracted recipient is added to the suppression list so future sends skip them. This should happen promptly, within roughly 48 hours, which is the expected behavior for compliant senders.
Step 4: feed PowerMTA accounting. PowerMTA can also process FBL reports and write f-type records to accounting, giving the operator complaint data in the accounting log alongside delivery data. Many operators run both: PowerMTA captures FBL for accounting and reputation alerting, the application layer captures FBL for subscriber suppression.
For deployments using MailWizz, the MailWizz feedback-loop-handler can process the JMRP mailbox; configure the JMRP complaint address as a feedback loop server in MailWizz, and the handler cron job polls it and processes the ARF reports into subscriber suppression.
The ARF standardization in the 2026 modernization makes this processing more reliable: with all JMRP reports in consistent ARF format, parsing is straightforward and consistent rather than needing to handle format variations.
Blocked IPs and the support form
When SNDS shows a JMR Block comment, the IP is blocked due to abuse complaints, and mail to Microsoft domains from that IP is being rejected.
SNDS itself does not process delisting requests; it only displays the data. For a blocked IP, the delisting process goes through the Outlook.com Deliverability Support form, sometimes called the Microsoft Sender Support Form. The operator submits a delisting request and provides remediation details, explaining what caused the problem and what has been done to fix it.
The delisting request should be substantive. Microsoft expects to see that the operator has identified the cause (a complaint spike, a list quality problem, an authentication failure) and addressed it. A delisting request that just asks for unblocking without remediation details is less likely to succeed than one that demonstrates the underlying problem has been fixed.
While a delisting is pending, the operator should pause or substantially reduce sending to Microsoft domains from the blocked IP, and may route Microsoft-bound traffic through other IPs in the VMTA pool. PowerMTA's pmta pause queue with the appropriate domain or VMTA pattern handles this.
The SNDS team explicitly does not process deliverability support requests; for urgent deliverability issues the person most familiar with the issue and the email infrastructure should contact sender support through the proper channel, which is the deliverability support form, not the SNDS portal.
Authentication and Microsoft trust signals
Microsoft considers SPF, DKIM, and DMARC when evaluating sender trustworthiness, so authentication is foundational to Microsoft deliverability.
SPF. The sending domain's SPF must authorize the PowerMTA outbound IPs. Microsoft checks SPF as part of its trust evaluation.
DKIM. Messages should be DKIM-signed. PowerMTA signs via the domain-key directive. DKIM gives Microsoft a verifiable sender identity.
DMARC. A valid DMARC record for the sending domain is expected. Microsoft, like Gmail and Yahoo, has tightened DMARC expectations as part of the broader bulk sender requirements.
HELO/EHLO consistency. The HELO value SNDS displays should match the sending domain configuration. For PowerMTA this is the smtp-source-host EHLO hostname per VMTA, and it should have proper forward and reverse DNS.
When SNDS shows a red filter result or rising complaints, verifying authentication is a standard early step, because authentication problems contribute to Microsoft's negative trust evaluation. An operator whose SPF does not include all PowerMTA outbound IPs, or whose DKIM signing is misconfigured, gives Microsoft a reason to distrust the mail regardless of content quality.
Microsoft incident diagnostic workflow
The procedure when Microsoft delivery degrades:
Step 1: check SNDS. Log into the SNDS portal. What is the filter result color? What are the complaint rates? Are there Abuse Reported or JMR Block comments on any IPs?
Step 2: check PowerMTA accounting for Microsoft codes. Query the accounting log for t-type and b-type records to Microsoft domains. Microsoft codes like S3140, S3150, and OU-002 indicate throttling or filtering; specific error text identifies the problem.
Step 3: correlate SNDS and accounting. A red SNDS filter result plus S3140 codes in accounting points to a content or reputation problem. A JMR Block comment plus 5xx rejections points to an IP block requiring delisting.
Step 4: check JMRP complaint data. Review the JMRP ARF reports for the recent complaint pattern. A complaint spike explains a reputation degradation. Confirm complaints are being processed into suppression.
Step 5: check authentication. Verify SPF, DKIM, DMARC, and HELO consistency for the affected sending domain and IPs.
Step 6: check traffic data for list quality signals. In SNDS, look at the RCPT command data for discrepancies suggesting invalid addresses or list quality problems.
Step 7: take corrective action. For a red filter result, address content and list quality, reduce volume, process complaints. For a JMR Block, submit the deliverability support form with remediation details and pause sending from the blocked IP. For authentication issues, fix the authentication.
Step 8: monitor recovery. Watch the SNDS filter result and complaint rate over the following days. SNDS retains 90 days of history, so the recovery trend is visible. Improvement in the filter color and declining complaint rate confirm the corrective action is working.
An operator we worked with reported a gradual Microsoft deliverability decline with no obvious cause. Their SNDS showed a yellow filter result trending toward red and a complaint rate that had crept up over several months. The puzzle was that they believed they were processing JMRP complaints and suppressing complainers, so the complaint rate should not have been climbing. The investigation revealed the cause in the 2026 JMRP modernization. They had set up JMRP years earlier as a standalone feed, before JMRP feeds were linked to SNDS accounts. When Microsoft modernized JMRP and began removing feeds not linked to SNDS accounts, their old standalone feed had stopped delivering reports. For months they had been receiving no JMRP complaints, not because nobody complained, but because the feed was dead. Complainers were never suppressed, kept receiving mail, kept complaining, and the complaint rate climbed. The fix was straightforward once identified: recreate the JMRP feed from within the SNDS account so it was properly linked, point it at the monitored complaint address, and resume processing. Within weeks the complaint rate stabilized as complainers were once again being suppressed. The lesson: the 2026 JMRP modernization is not optional housekeeping. Operators with pre-2025 JMRP setups must verify their feed is linked to their SNDS account, because an unlinked feed silently stops working and the first symptom is an unexplained reputation decline.
Microsoft SNDS and JMRP integration gives PowerMTA operators essential visibility and feedback for a major portion of their recipient base. SNDS shows the aggregate reputation picture; JMRP delivers the individual complaints. The 2026 modernization changed how the two relate, standardized JMRP to ARF format, and added authentication requirements, so operators with older setups must verify their integration is current, particularly that JMRP feeds are linked to SNDS accounts. Properly integrated, SNDS provides the early-warning signal that lets operators catch Microsoft deliverability problems before they escalate, and JMRP provides the complaint data that drives suppression and keeps complaint rates down. For PowerMTA operators sending meaningful volume to Outlook.com and Hotmail, SNDS and JMRP are not optional extras; they are the instrumentation that makes Microsoft deliverability manageable rather than mysterious.