When mail starts slowing down, landing in Junk, or getting rate-limited at Outlook.com, many teams look at SPF, DKIM, and DMARC first. That is still the right first pass, but it is often not enough. Microsoft's own sender tooling is where the investigation becomes practical.
Smart Network Data Services (SNDS) shows how Microsoft views the health and reputation of your sending IPs. The Junk Mail Reporting Program (JMRP) gives you copies of mail that Outlook.com users marked as junk or phishing, including headers. Used together, they tell you two different but complementary things:
That combination is what makes them useful. SNDS answers "how does Microsoft see this IP?" JMRP answers "what mail are users complaining about?"
If Outlook deliverability is getting worse, use this order:
Microsoft is explicit that Outlook deliverability is reputation-based, and its Postmaster troubleshooting guidance also says complaint rate is one of the principal factors that drives reputation down.
Microsoft describes SNDS as a free service that provides high-level insight into how Outlook.com users are rating the mail they receive and the health of your IP space as viewed by Outlook.com systems.
In practice, that makes SNDS the "IP view" of the problem.
Use it when you need to answer questions like:
SNDS is especially useful when the team only says "Outlook started junking us" without separating domain issues from IP issues. If only one dedicated IP or one shared pool looks bad, that narrows the investigation immediately.
Microsoft describes JMRP as a free service that returns the full message with headers for mail that Outlook.com users marked as junk or phishing. Microsoft also says senders typically begin receiving feedback within about 72 hours after enrollment.
That makes JMRP the "recipient feedback" side of the problem.
Use it when you need to answer questions like:
JMRP is not just a reporting convenience. It is a way to find the exact mail that is damaging your Outlook reputation.
It helps to think of them this way:
Neither one replaces the other.
An IP can look weak in SNDS because complaints rose, because the traffic pattern changed sharply, or because the IP is new and untrusted. JMRP then helps explain which mail caused those complaints. The reverse is also true: JMRP may show a complaint problem before your team fully understands the reputation impact showing up in delivery outcomes.
This fits Microsoft's broader explanation that inbound decisions use not only traditional SPF, DKIM, and DMARC checks, but also sender reputation, sender history, recipient history, and behavioral analysis in Email authentication - Microsoft Defender for Office 365.
This sounds obvious, but it is where many Outlook investigations go wrong.
Make sure the IPs you add to SNDS and JMRP are the IPs actually delivering the affected mail to Outlook.com addresses. That might be:
Do not assume the same IPs are used for transactional and marketing mail. Do not assume the IP shown in one log sample represents the whole stream.
If you are on Microsoft 365 or a hosted ESP, also remember that authentication and visible identity still matter even when the current problem looks reputation-related. Microsoft's authentication documentation explains that it uses composite authentication (compauth) alongside other signals, so header review still belongs in the workflow.
Look at whether Outlook is:
Microsoft's Postmaster troubleshooting page documents several common codes that matter here:
421 RP-001, 421 RP-002, 421 RP-003: rate or connection limiting related to IP or domain reputation550 SC-001 and 550 OU-002: rejection that may relate to spam-like content or IP/domain reputation550 SC-004: Microsoft says complaints concerning mail from that IP triggered a block550 DY-001: dynamic IP mail is not generally acceptedThose codes do not replace SNDS, but they tell you what kind of problem you are trying to explain.
Before treating this as a pure reputation event, confirm:
From: domainMicrosoft's troubleshooting guidance explicitly calls out reverse DNS and correct DNS setup, and its authentication guidance explains that identity checks still feed the overall decision. If this layer is broken, SNDS and JMRP can still be useful, but they will not rescue bad authentication.
After you enroll and gain access to the sending IPs, look for change over time rather than staring at a single day.
Ask:
This is where SNDS becomes more valuable than ad hoc guesswork. If only one IP looks bad, do not treat the entire domain as the problem yet. If every IP in the stream looks weak at the same time, that points toward a broader audience, content, or list-quality issue.
Use JMRP feedback to group complaints by:
Read the headers. Do not only read the subject line.
In practice, JMRP often exposes one of these patterns:
If JMRP keeps showing the same class of mail, that is not a Microsoft filtering mystery. It is a sender-behavior problem with Microsoft-visible consequences.
This is the step teams skip.
Do not rotate IPs, move vendors, or submit support requests before checking whether the complaint stream and the SNDS deterioration line up. If both point to the same dates and the same campaigns, the fix is usually list quality, targeting, cadence, or stream separation, not "try another IP."
If SNDS looks weak but JMRP is quiet, investigate other possibilities:
Most Outlook reputation problems fall into a few repeatable buckets.
Microsoft says IPs not previously used to send mail typically have no reputation in its systems and can experience deliverability issues until they build one. It also says new IPs authenticated under existing SPF records may inherit some domain reputation and may fully ramp within a couple of weeks or sooner, depending on volume, list accuracy, and complaint rate.
That means SNDS trouble right after an IP migration does not automatically mean the IP is "bad." It may simply be cold. But if JMRP complaints rise during the ramp, the warm-up is not clean and reputation damage can compound quickly.
For that scenario, DMARC and sender domain warm-up is a useful companion read.
This is the classic JMRP case.
Mail is technically authenticated. Delivery may even look fine at Gmail or Yahoo. But Outlook users are hitting Junk often enough that Microsoft starts trusting those signals. Then you begin seeing junk placement, throttling, or blocks tied to reputation.
When this happens, the highest-value fixes are usually:
If SNDS looks bad for one subset of mail and JMRP points to a specific stream, do not keep transactional and promotional traffic blended. Reputation isolation matters more at Outlook than many teams expect.
This is also where a seemingly "clean" domain can still perform badly because the current IP path is carrying the wrong kind of mail. Email sender reputation explained covers that domain-versus-IP split in more detail.
Sometimes the reputation investigation exposes a deeper identity problem.
Examples:
From: domain changed during a migrationAuthentication-Results shows weak or inconsistent alignment outcomesThat does not make SNDS or JMRP irrelevant. It means the complaint and reputation outcomes are being amplified by weak sender identity.
Several common reactions make Outlook problems last longer:
Microsoft is clear that reputation is the sender's responsibility, and its filtering uses more than one signal. A clean-looking DNS setup is necessary, but it does not override unwanted mail.
Microsoft's SNDS site says urgent deliverability issues should be raised through sender support by the person most familiar with the issue and the email infrastructure.
That is usually appropriate after you have already done the basics:
Support is more useful when the case includes precise evidence instead of a general claim that "Outlook is blocking us."
If Outlook deliverability is slipping, SNDS and JMRP are the two Microsoft tools that turn vague suspicion into a usable diagnosis.
SNDS shows whether the sending IP path is losing trust. JMRP shows which messages recipients are pushing away. Together they help you separate cold-IP issues from complaint-driven issues, shared-pool issues from audience issues, and real reputation problems from generic authentication guesswork.
The key is to read them together, not separately. When SNDS deterioration and JMRP complaints point at the same stream, the fix is usually already in front of you.