January 2026 Microsoft SNDS Updates (So far)

If you use Microsoft’s SNDS (Smart Network Data Services) online reputation portal to monitor for deliverability and reputation indicators for mail you’re sending to Microsoft OLC (Outlook Consumer, aka Hotmail/Outlook.com) mailboxes, you might have noticed this already.

Clearly, folks at Microsoft are working on making improvements to SNDS. I first noticed this back in October, but it looks like things have changed even more, since then.

What has changed so far

On the front page of the SNDS website, Microsoft notes an update date of December 4th and indicates that they have made the following changes:

• SNDS will now require authentication when approving or denying network access, adding an extra layer of protection.
• JMRP Feeds are now standardized on all reports to ARF format for consistency and improved processing.
• SNDS has discontinued complaint sample downloads.
• SNDS is increasing protections around "Automated Data Access". If you're experiencing issues with an "Automated Data Access" link, please login with the account that created the link to verify it's still listed on the Automated Data Access page.

My recollection is that Microsoft already required authentication when approving or denying network access; maybe they mean that a user must be logged in when clicking on an approval link (to prevent bots or security scanners from accidentally approving SNDS access requests). That seems reasonable to me.

JMRP (Junk Mail Reporting Program) is Microsoft’s ISP feedback loop and standardizing to ARF format makes sense as well; it’s the way people do things nowadays.

For SNDS sample complaint downloads, I vaguely recall that you could click on a complaint rate and get a sample message being complained about. This included the original recipient’s email address, which I assume to be a privacy concern nowadays.

The increased protections around automated data access might end up giving some deliverability folks heartburn. Read on to learn why.

More Changes Coming

The SNDS website, as of the time I write this, says the following changes are to come:

• We are updating the ARF feedback format to include only the original message headers from the complaint email, plus selected authentication headers (for example, Authentication‑Results and Received‑SPF). The sender address will be redacted. Previously, the ARF included the full complaint email body, under the new format, that content is no longer appended.
• SNDS will move to a new, more secure URL.
• Automated report links will expire after 30 days to reduce risk and enhance security.
• JMRP feeds that are not linked to SNDS accounts will be removed. You will be asked to create new ones from your SNDS account and keep the network access up-to-date.

The big change, part one: JMRP (ISP feedback loop) complaints will no longer contain full, raw email messages; only certain headers, and other bits will be missing or redacted. No sender address will be included, but what about the recipient address? Best to assume that neither will be included. Most savvy email marketing platforms encode both sender and recipient information in other headers and/or the return-path; please keep an eye out for changes here and make sure you’re still able to decode sender, recipient and other message details (like sender account ID and so forth). Be prepared to update what you store in what header as needed.

The big change, part two: Automated report links expiring after 30 days, this could cause some folks some pain. For those of you who have linked up SNDS data feeds into deliverability tool platforms or have built scripts to capture and store this data; the one-time access links are now going to expire. Meaning you’re going to have to get a new link every 30 days. That’ll drive some significant new administrative overhead, depending on your configuration.

Finally, removing JMRP feeds not linked to SNDS accounts seems like a non-issue to me; I think most people manage JMRP feeds using SNDS logins today. Or at least they should. The mention of this suggests that there could be some legacy configurations in place that pre-date the most current process or were an exception to the process.

I never found it hard to manage ISP feedback loop setup via this interface; approximately a million years ago, there was a bug in the CIDR math that resulted in coverage gaps if you had IP ranges larger than a /24; I worked around this by simply breaking down our ranges into /24 blocks and registering them with SNDS and JMRP as such.

Beyond that, the only other issue I can recall from my days managing JMRP feeds here was that when giving clients’ direct access to SNDS upon request, they’d have access to modify the JMRP feed, and if they did, it could break things. Not sure if/how that relates here in any way, or if that’s something that needs to be considered.

Stay tuned; I’ll share more if/when I learn it.