An IP address is an important clue, but it is not a complete description of a message. Microsoft Smart Network Data Services can show patterns associated with sending IPs. The administrator's task is to connect that evidence to the applications, tenants and time windows actually using those addresses.
Begin at the current portal
The current Microsoft portal replaces the older sendersupport location and includes JMRP management. SNDS access is granted for IP space the requester is authorized to administer. Its current announcement also explains periodic network reattestation. Use the current access page and recorded expiration rather than treating an old successful login as permanent permission. SNDS portal.
If an email service owns a shared pool, work with that service for the relevant evidence. Knowing that a message used an IP does not itself establish authority to view all traffic associated with it. Avoid exporting other tenants' data into a broad incident ticket.
Preserve the scope of the observation
Microsoft's FAQ describes IP-level activity and notes that low-volume IP data may be absent. It also explains that NAT can hide multiple machines behind one visible address. Record the exact IP, the reported activity period and its time convention, along with the retrieval time. SNDS FAQ.
Convert time zones carefully before joining this data to application logs. Keep the original timestamp and timezone as well as a normalized representation. An incident that crosses midnight can fall into different daily buckets in two systems, creating a false impression that a dashboard event preceded the send that caused it.
Join IP telemetry to route ownership
Maintain a dated map of outbound IPs to sending services and pools. Include changes in allocation, NAT and provider routing. A current routing map is insufficient for an incident from last week if the provider moved traffic yesterday. Where the pool is shared, label the limit: you may know your own submissions without seeing every other sender's contribution.
Compare actual SMTP diagnostics, authenticated identities and complaint-processing evidence. SNDS does not replace a message-level authentication check or establish a final mailbox folder. Nor is it a universal picture of every enterprise Microsoft tenant. Keep the receiving service and incident scope explicit.
Examine the local attribution example
The synthetic fixture maps two streams, receipts and promotions, to the documentation IP 192.0.2.42 during one invented activity window. A degraded IP-level observation is attached to that address. The result lists both streams as candidates for investigation, not just the campaign nearest in time.
A later route record moves promotions to 192.0.2.43. The model keeps the historical mapping intact, so a later export does not rewrite ownership of the earlier event. This is an executed join over invented data, not a Microsoft dashboard export or a reputation judgment on those reserved example addresses.
Escalate with a bounded incident packet
Provide sender support or the service owner with the relevant date range, IP, exact SMTP diagnostic, affected destination service and steps already checked. Redact recipient content and tokens not needed to diagnose the issue. Keep registration trouble separate from deliverability support; the FAQ directs these questions through different paths.
A good closure record identifies the defective route or preserves the remaining uncertainty. An IP trend can justify investigation, but it cannot by itself prove that a particular subscriber complained, that a specific message failed authentication or that every message went to spam.
Read a field dictionary before joining the data
Microsoft's current FAQ supplies the field meanings below. IP address is the visible source, potentially shared or behind NAT. Activity period is the first and last activity hour of the Pacific day; the documentation says PST including daylight-saving adjustments, so retain the actual date and Pacific offset rather than applying a fixed UTC subtraction. RCPT count describes recipient commands; DATA count describes message-data commands; message recipients describes recipients on messages actually transmitted. None is a count of people who read the mail.
Filter result summarizes spam-filter verdicts over IP traffic and does not directly describe inbox or junk-folder placement. Complaint rate uses complaints divided by message recipients, with complaints recorded on the day reported rather than moved back to the original send date. A late complaint can therefore appear against a different day's sending population. Low-volume data may be absent; the FAQ specifically cautions about IPs below one hundred messages on a day. A trap indicator is not present in the current field list used here: retain it as unavailable, not zero, and do not import an old field definition.
In the invented worked row, 120 RCPT commands, eighty DATA commands and one hundred message recipients produce a twenty-command RCPT/recipient difference. Two reported complaints divided by one hundred gives 2% for that synthetic row, not a measurement of current-campaign dissatisfaction. The next action is a recipient-hygiene and historical-route review, followed by complaint correlation if available. Yellow filtering prompts review of the aggregate observation; it does not establish a folder. Retain the Pacific activity window and original-send timestamps separately when assembling the incident packet.