Los requisitos para remitentes de Microsoft (Outlook, Hotmail) en 2025

IP compartidas o dedicadas: ¿qué reputación pertenece realmente al remitente?

En un envío a través de una plataforma de enrutamiento en lugar de servidores propios, conviene tener en cuenta que Microsoft lleva dos registros distintos: la reputación de la IP de envío y la del dominio. En un pool de IP compartidas, la primera es colectiva — hereda, para bien o para mal, el comportamiento de los demás clientes de la plataforma, y la visibilidad SNDS sobre esas IP le corresponde generalmente a la plataforma, no al cliente. La reputación de dominio, en cambio, pertenece solo al remitente: se nutre de sus resultados de autenticación y de la reacción de los destinatarios al correo que lleva su nombre. Es precisamente por eso que un DKIM alineado cuenta tanto en esta configuración — es la palanca que queda enteramente bajo control propio cuando la capa de IP no lo está.

El filtrado de Microsoft: Junk Email Reporting y SCL

Microsoft usa su propio sistema de puntuación, el SCL (Spam Confidence Level), que determina dónde aterriza un mensaje: bandeja de entrada, carpeta de spam, o bloqueo puro. Esta puntuación se apoya en la autenticación (SPF/DKIM/DMARC), la reputación IP/dominio (visible en parte a través de SNDS), y el análisis de contenido — una lógica cercana a la de Gmail, pero con sus propias ponderaciones internas, no publicadas en detalle.

Una señal específica que vigilar: el Junk Email Reporting Program (JMRP), el programa por el que los usuarios de Outlook marcan un mensaje como no deseado. Como en Gmail, una tasa de quejas elevada degrada rápidamente la reputación — pero el alta en JMRP (distinta de SNDS) permite recibir directamente una copia de las denuncias del propio correo, lo que da una señal de alerta temprana que pocos remitentes explotan.

Alineación DMARC: las mismas reglas, un comportamiento a veces más estricto

DMARC funciona según el mismo estándar en Microsoft que en cualquier otro sitio — la alineación SPF/DKIM con el From: no tiene nada de específico de este ecosistema. Lo que difiere, en la práctica, es que algunos administradores informan de un tratamiento ligeramente más estricto de los fallos de alineación en Outlook comparado con Gmail, sobre todo en los casos límite. La lección práctica: una configuración DMARC «que pasa en Gmail» no es automáticamente suficiente en Microsoft — hay que verificar específicamente la alineación de cada fuente en los informes agregados de DMARC, sin perder de vista a los destinatarios outlook.com/hotmail.com en particular.

Microsoft 365 en el lado empresa: otra capa

Cuando una parte de los destinatarios usa Microsoft 365 en entorno profesional en lugar de los dominios de consumo, hay que tener en cuenta que los administradores de empresa disponen de capas de filtrado adicionales (Exchange Online Protection, reglas de transporte personalizadas, listas de bloqueo internas) que se suman al filtrado estándar de Microsoft. Una autenticación impecable no garantiza pasar una regla de bloqueo interna agresiva puesta por el administrador de un destinatario — un factor fuera del control del remitente, pero útil de conocer para no buscar un fallo en el lado de DMARC donde no lo hay.

Checklist de conformidad Microsoft

• SPF y DKIM alineados, verificados específicamente sobre tráfico hacia outlook.com/hotmail.com en los informes.
• DMARC publicado, con el objetivo de subir hacia quarantine y luego reject según el mismo método que para cualquier otro destinatario — ver alcanzar p=reject sin romper el correo legítimo.
• Alta en SNDS para la visibilidad de reputación IP, cuando las IP de envío están bajo control propio.
• Alta en el programa JMRP para recibir directamente las denuncias de spam de los propios envíos.
• Higiene de listas idéntica a la recomendada para Gmail — Microsoft observa las mismas señales de comportamiento (quejas, rebotes, engagement).
• Cancelación de suscripción funcional y visible, reduciendo el recurso al botón «marcar como no deseado».

El calendario de endurecimiento, en el lado de Microsoft

Un punto que conviene conocer al preparar una hoja de ruta: el ritmo de aplicación de Microsoft no siempre ha seguido al de Gmail y Yahoo. Allí donde Google comunicó un calendario preciso y fechado desde el anuncio inicial de 2024, Microsoft procedió durante mucho tiempo mediante ajustes progresivos de su filtrado sin un anuncio público tan estructurado. La consecuencia práctica: nunca hay que dar por hecho que «la fecha límite de Google ya pasó, así que todo está resuelto en todas partes». El filtrado de Microsoft sigue evolucionando de forma independiente, y un dominio que pasaba sin problema hace seis meses puede ver su entregabilidad en Outlook degradarse sin que ningún cambio del lado del remitente sea la causa — simplemente porque el umbral de tolerancia en el lado de Microsoft se ha movido.

Es un argumento más para tratar la vigilancia de la reputación (a través de SNDS) como un ejercicio continuo, y no como una casilla que marcar una sola vez durante la puesta en conformidad inicial.

Caso práctico: un remitente B2B español

Tomemos un ejemplo concreto para anclar estas nociones. Una pyme española que envía sus facturas y recordatorios por correo alcanza una mezcla de destinatarios profesionales — a menudo en dominios de empresa Microsoft 365 — y de particulares, más repartidos entre Gmail, Outlook.com/Hotmail y los proveedores locales (Movistar, Orange, Vodafone). Para esta pyme, ignorar la capa Microsoft no es una opción marginal: es potencialmente la mitad de su tráfico profesional el que transita por este ecosistema.

El reflejo correcto es tratar la configuración DMARC como universal (un único registro, válido para todos los destinatarios) pero la vigilancia de reputación como específica de cada ecosistema: Postmaster Tools para la parte Gmail, SNDS para la parte Microsoft, y una vigilancia sobre los informes agregados de DMARC para detectar si un destinatario particular muestra una tasa de fallo anormalmente elevada respecto a los demás. Esta vigilancia diferenciada cuesta poco tiempo una vez implantada, y evita el punto ciego más común en los remitentes españoles: una entregabilidad excelente en Gmail que enmascara una entregabilidad mediocre en Outlook, simplemente porque nadie miraba por ese lado.

Por qué no basta con la conformidad de Gmail

El error de razonamiento más frecuente: «ya soy conforme para Gmail, así que lo soy en todas partes». Técnicamente, la autenticación (SPF/DKIM/DMARC) es efectivamente la misma configuración DNS para todos los destinatarios — no hay que duplicar nada en los registros. Pero la reputación es específica de cada ecosistema: la reputación en Google y la reputación en Microsoft son dos historiales independientes, construidos sobre señales observadas por separado por cada uno. Una excelente entregabilidad en Gmail no garantiza nada en Outlook, y viceversa — ambos filtros sacan sus conclusiones de sus propios usuarios, no de un repositorio compartido entre proveedores. De ahí el interés de vigilar los dos (a través de Postmaster Tools y SNDS) en lugar de suponer que una buena puntuación en uno vale para el otro.

En resumen

Los cimientos DMARC/SPF/DKIM son universales y solo se configuran una vez. Lo que cambia en Microsoft son las herramientas de visibilidad (SNDS, JMRP) y el hecho de que la reputación se construye ahí de forma independiente de la adquirida en Gmail. Un despliegue DMARC serio cubre los dos ecosistemas desde el principio, sin esperar a un incidente de entregabilidad específico de uno de ellos para preocuparse.

Para verificar que la autenticación está correctamente configurada — el requisito previo idéntico sea cual sea el destinatario — el analizador DMARC gratuito acepta cualquier dominio. Es el punto de partida común a los dos ecosistemas; la vigilancia de reputación, en cambio, se juega después por separado en cada uno.