Microsoft SNDS y JMRP en 2026: guía completa con los breaking changes de enero 2026

Las herramientas de entregabilidad de Microsoft para Outlook.com, Hotmail, Live y MSN — Smart Network Data Services (SNDS) y Junk Mail Reporting Program (JMRP) — están documentadas pero raramente explicadas operacionalmente. La documentación oficial te dice que los registros existen y dónde registrarte; no te dice cómo interpretar las señales cuando conflictúan, qué significan los breaking changes de enero 2026 para tus integraciones existentes, o cómo arquitecturar monitoreo que combine SNDS con Postmaster Tools v2 de Gmail y Sender Hub de Yahoo. Esta guía cubre operacional reality post-enforcement Microsoft 5 mayo 2025 + breaking changes enero 2026.

El stack monitoring Microsoft — visualización del modelo

Antes del detalle técnico, el diagrama muestra cómo SNDS y JMRP se integran con el ecosistema completo de monitoring Microsoft + cross-vendor con Gmail Postmaster + Yahoo Sender Hub.

El diagrama hace explícito por qué SNDS y JMRP no son opcionales en 2026: enforcement Microsoft 5 mayo 2025 retorna 550 5.7.515 Access denied para senders no compliant a 5K+/día, y SNDS+JMRP son los únicos signals oficiales para diagnosticar pre-failure.

Qué cambió en enero 2026 (y por qué rompe guías viejas)

Cambio 1 — Format ARF redacted: notificaciones JMRP previamente preservaban full headers + body. Post-enero 2026, ciertos headers están obfuscados por privacy: From header preservado, Subject preservado, Message-ID parcial (last 8 chars), body original removed. Para automation processing, esto significa: parse From + Subject para identificación, Message-ID parcial requiere fuzzy matching contra outbound logs, body analysis no longer possible.

Cambio 2 — Link mandatorio JMRP-SNDS: ambos services deben estar registered con same operator account. Pre-2026, podías registrar SNDS sin JMRP. Post-2026, registration JMRP requiere SNDS account active. Operacional implication: cualquier operator usando solo JMRP debe registrar SNDS antes de continuar receiving feedback notifications.

Cambio 3 — Expiración automatizada cada 90 días: cada 90 días, Microsoft envía email a registered postmaster address requiriendo re-confirmation del link. Si no respondido en 14 días, both services deactivated. Operacional implication: monitoring proactivo del postmaster mailbox cada 90 días, alerting si confirmation email arrives.

Cambio 4 — URL migración portal: portal moved de sendersupport.olc.protection.outlook.com a sendingdata.microsoft.com. Old URL redirects pero scripts hardcoded vs old URL eventually fail. Operacional implication: update scripts, automation tools, internal documentation.

Qué mide SNDS realmente (y qué no)

SNDS provides IP-level metrics aggregated daily:

Filter result %: porcentaje de mensajes filtered como spam. Granularity: per IP, daily. Range: 0% (perfect) to 100% (catastrophic).

RCPT command activity: número RCPT TO commands per day per IP. Indicador volumen + bounce patterns (high RCPT con few delivered = many bounces).

Message activity: mensajes accepted by Microsoft per day per IP. Granularity: per IP, daily.

Total messages volume: aggregate volume per IP. Sirve as denominator para complaint rates.

Trap hit count: número de spam traps Microsoft hit by your sending. CRÍTICO — trap hits are most damaging signal en SNDS.

Color code aggregate: green/yellow/red basado on filter rate. Ver section interpretation below.

Lo que SNDS NO mide: domain reputation (separate de IP reputation), specific user complaint texts (use JMRP for that), reasons for filtering (algoritmo proprietary), inbox vs spam folder placement (no Microsoft-published metric for this directly).

Leyendo SNDS verde/amarillo/rojo correctamente

Verde (filter rate bajo 0.3%): IP healthy. Sustainable sending. Action: continue current discipline. Volume can scale gradually if needed.

Amarillo (filter rate 0.3-0.7%): warning emerging. Action: pause volume scaling, audit recent campaigns para content quality issues, audit list para complaint rate trending. Si root cause identified y fixed within 7 días, typically returns to green within 14 días.

Rojo (filter rate sobre 0.7%): degraded. Action immediate: reduce volume to Microsoft 50%, send only top engagement segment for 7-14 días, audit content + list comprehensively. Si remains red despite intervention 14 días, consider recovery framework.

Trap hits cualquier value sobre 0: most serious signal. Even 1-2 trap hits indicates list quality issue serio. Action immediate: full list verification (ZeroBounce, NeverBounce), suppression review, segmentation audit. Trap hits sustained over 14 días → blacklist Microsoft secondary list inevitable.

Tabla — métricas Microsoft SNDS interpretation

Métrica SNDS	Verde	Amarillo	Rojo	Acción inmediata si Amarillo+
Filter result %	bajo 0.3%	0.3-0.7%	sobre 0.7%	Audit content + list, pause volume scaling
Trap hit count	0	0 (any sostenido es serio)	sobre 0 sostenido	Verification list + suppression audit
RCPT command efficiency	sobre 95%	90-95%	bajo 90%	Address bounces + invalid recipient cleanup
Total volume trend	Estable	Spike up sin context	Spike up + filter spike	Investigate volume source
Complaint % (calculated)	bajo 0.1%	0.1-0.3%	sobre 0.3%	Content audit + suppression aggressive

Comparación métricas reputation — cross-vendor 2026

El gráfico muestra cómo las métricas Microsoft SNDS, Gmail Postmaster, y Yahoo Sender Hub correlate (or fail to correlate) durante un sample 90-day period.

Reputation cross-vendor correlation durante incidente y recovery 90 días

Categoría	Microsoft SNDS filter rate (%)	Gmail Postmaster reputation (1=Bad,4=High)	Yahoo Sender Hub score (0-100)
Día 1	0.2	4	85
Día 15	0.3	3.5	80
Día 30	0.5	3	72
Día 45	0.45	3	75
Día 60	0.3	3.8	80
Día 75	0.25	4	83
Día 90	0.25	4	85

Datos de sample engagement representativo (anonymized). Patrón visible: las tres métricas correlate durante incident pero con timing slightly different — Microsoft yellow alert emerged primero (día 25), Gmail Medium signaled (día 28), Yahoo score drop (día 32). **Insight clave:** monitorear solo un vendor produce blind spots de 3-7 días. Cross-vendor monitoring con unified dashboard (Grafana o equivalent) detecta issues earlier y permite intervention proactiva vs reactive. Para context completo monitoring stack, ver guía dedicada.

Cómo funcionan los reportes JMRP post-enero 2026

JMRP envía notification cada vez user marks email as junk en Outlook/Hotmail/Live/MSN. Format ARF (Abuse Reporting Format) standardized RFC 5965, message arrives at registered postmaster address (typically [email protected]).

Format post-enero 2026 redacted:

From: [email protected]
Subject: FW: Email Feedback Report for IP 203.0.113.45
Content-Type: multipart/report; report-type=feedback-report

[Section 1: Human-readable summary]
Original-Mail-From: [email protected]
Original-Rcpt-To: [email protected]
Reported-Domain: yourdomain.com
Source-IP: 203.0.113.45
Subject: [PRESERVED - your campaign subject]
Message-ID: <abc[REDACTED]@yourdomain.com>

[Section 2: Original message body]
[REDACTED post-enero 2026]

Processing automatizado:

import email
from email.parser import BytesParser

def process_jmrp_report(raw_message_bytes):
    msg = BytesParser().parsebytes(raw_message_bytes)
    
    # Extract structured feedback
    feedback_part = None
    for part in msg.walk():
        if part.get_content_type() == 'message/feedback-report':
            feedback_part = part
            break
    
    if feedback_part:
        feedback_text = feedback_part.get_payload(decode=True).decode()
        # Parse Original-Rcpt-To, Original-Mail-From, Source-IP, Subject
        # Add Original-Rcpt-To to suppression list
        # Log incident for trending analysis

Trap hits — la métrica que siempre importa

Trap hits in SNDS son señal más serie. Microsoft trap addresses are hidden in lists vendidas/scraped. Hitting trap address indicates: list quality issue (likely purchased/scraped), bypassing opt-in process, list 18+ meses sin verification.

Even single trap hit warrants:

• Immediate full list verification (ZeroBounce/NeverBounce)
• Suppression review (any address sin engagement 12+ meses → suppress)
• Acquisition audit (where did this address come from?)
• Pause aggressive scaling para 14+ días

Sustained trap hits over 14 días → expect Microsoft secondary list inclusion (delisting takes 30-60 días minimum).

SNDS vs Postmaster Tools v2 — cuándo te dice qué cada uno

SNDS strengths: IP-level granularity, daily updates, trap hit signal único de Microsoft, complaint rate calculation directo.

Postmaster v2 strengths: domain-level reputation, multi-day trends, spam rate granular per category, authentication pass rate breakdown.

Cuándo cada uno detecta primero: SNDS detecta IP-specific issues primero (single IP problem en pool dedicado). Postmaster v2 detecta domain-wide issues primero (content quality across all IPs).

Cuándo combinarlos: cualquier serious sender debe tener ambos. SNDS + Postmaster v2 + Yahoo Sender Hub + parsedmarc DMARC = stack monitoring complete moderna 2026.

Cómo arquitecturar SNDS + JMRP + Postmaster + Yahoo en stack unificado

Pattern integración recomendado:

1. SNDS API polling: script every 30min checking SNDS API (auth via cookie session), filter changes only, alert si color shift.
2. JMRP processing: postmaster mailbox auto-processed por Python script, parses ARF format, suppression list updated, trending logged.
3. Postmaster v2 polling: API o portal scraping daily, domain reputation tracked.
4. Yahoo Sender Hub polling: portal scraping daily (no public API), reputation score tracked.
5. parsedmarc DMARC: aggregate reports parsed daily, sent to Elasticsearch for analysis.
6. Grafana unified dashboard: visualizes all 5 sources, custom alerts via Alertmanager → PagerDuty/Slack.

Per stack monitoreo entregabilidad y observabilidad email unificada para deployment patterns completos.

Fallos comunes de configuración SNDS y soluciones

Fallo 1 — SPF authentication required for JMRP processing: post-enero 2026, JMRP requires SPF auth on registered domain. Sin SPF, JMRP messages may not arrive consistently. Solución: verify SPF record, ensure includes Microsoft IPs si using Microsoft 365 transport.

Fallo 2 — Multiple operators registering same IP causes confusion: si tu IP shared across multiple operator accounts, SNDS data may be inconsistent. Solución: only one operator per IP registered.

Fallo 3 — Postmaster mailbox not monitored, expiration emails missed: 90-day expiration emails miss → account deactivated silently. Solución: monitor postmaster mailbox actively, automated alert on subject “Microsoft” + “confirmation” keywords.

Fallo 4 — IP allocation changes (cloud rotation) break SNDS registration: si tu cloud provider rotates IPs (rare pero happens), SNDS registration becomes stale. Solución: prefer dedicated allocated IPs, register all IPs upfront, monitor IP allocation changes.

Elige tu stack monitoring Microsoft — herramienta de decisión

Dada tu volumen, status SNDS actual, JMRP setup, y stack monitoring presente, la herramienta calcula el monitoring approach apropiado.

Lo que recomendamos en Blue Spirit

Para clients infraestructura SMTP gestionada, integramos SNDS + JMRP + Postmaster v2 + Yahoo Sender Hub + parsedmarc en monitoring stack unified como part de service. Real-time alerting, automated suppression list management, weekly review session por deliverability engineer.

Para self-hosted operators sobre 5M/mes, recomendamos full stack: SNDS API polling + JMRP automated processing + Postmaster v2 + Yahoo Sender Hub + parsedmarc + Grafana unified dashboard. Total cost €100-€400/mes infrastructure.

Resources relacionadas: stack monitoreo entregabilidad, observabilidad email unificada Grafana, guía Postmaster Tools v2, recuperación reputación Gmail.

---

¿Necesitas ayuda implementando stack monitoring Microsoft completo? Habla con ventas. Nuestra auditoría entregabilidad incluye SNDS+JMRP setup verification + cross-vendor stack architecture review.