Resumen para dirección. Desde el 5 de noviembre de 2026, el correo personal de Microsoft (Outlook.com, Hotmail, Live y MSN) rechaza una parte de los mensajes provenientes de dominios que no publican un registro DMARC. El remitente recibe un rebote técnico; el destinatario no se entera de nada. La corrección es un registro en el DNS y suele tomar menos de una hora, pero requiere verificar que el resto de la autenticación esté bien alineada.
Qué cambió
Los primeros reportes de administradores de correo y proveedores de seguridad apuntan al 5 de noviembre de 2026. Los dominios afectados comparten una condición: no tienen registro DMARC en su DNS. En muchos casos sí tenían SPF y DKIM válidos y alineados, y aun así el mensaje fue rechazado.
El rebote que recibe quien envía se parece a este:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth RecordsAlgunos reportes añaden un código al final, AS9031519. El texto indica que faltan registros de autenticación, pero no dice cuál prueba falló, a diferencia del error 5.7.515 que Microsoft documenta para remitentes de alto volumen.
Por qué importa a un negocio en México
Las cuentas de Hotmail y Outlook siguen siendo muy comunes entre clientes particulares, pequeños proveedores, candidatos a una vacante y contactos de empresas pequeñas. Los mensajes que más se pierden son los que más importan: cotizaciones, facturas y complementos de pago, confirmaciones de pedido, restablecimiento de contraseñas y respuestas a prospectos.
El costo real no es el rebote; es que nadie en la empresa sabe que el correo no llegó. Un prospecto que no recibe su cotización no escribe para quejarse: contrata a otro proveedor.
SPF, DKIM y DMARC en lenguaje de negocio
| Registro | Qué resuelve | Analogía |
|---|---|---|
| SPF | Declara qué servidores pueden enviar correo en nombre de su dominio | La lista de mensajeros autorizados |
| DKIM | Firma cada mensaje para demostrar que no fue alterado y que viene de su dominio | El sello de cera en el sobre |
| DMARC | Exige que SPF o DKIM coincidan con el dominio visible del remitente, indica qué hacer si no coinciden y pide reportes | La instrucción a la aduana sobre qué hacer con lo que no cuadra |
Que el sello y la lista existan no basta: DMARC es el registro que amarra ambos con la dirección que el destinatario ve en el campo De. Por eso Microsoft puede rechazar un correo con SPF y DKIM válidos si no encuentra la política que los une.
Lo que se sabe y lo que no
Conviene separar los hechos confirmados de lo que sigue en discusión.
- Observado de forma consistente: el rechazo afecta a destinatarios de cuentas personales de Microsoft, aplica a dominios sin DMARC independientemente de su volumen de envío, y es parcial: no se rechaza todo el correo de un dominio afectado, lo que lo vuelve fácil de pasar por alto.
- Regla publicada por Microsoft: desde mayo de 2025, los dominios que envían 5,000 correos o más al día a sus servicios de consumo deben pasar SPF y DKIM y publicar DMARC con al menos
p=none. Esa regla usa el error5.7.515. Lo que se observa desde noviembre de 2026 alcanza también a remitentes pequeños y no coincide con esa documentación. - Sin anuncio formal que hayamos localizado: no encontramos una comunicación oficial de Microsoft sobre este cambio. En foros técnicos hay desacuerdo sobre si fue anunciado; lo prudente es tratarlo como un cambio observado, no como una política documentada, y revisar la página de políticas del postmaster de Microsoft en las próximas semanas.
- Buzones corporativos: según los reportes, los servidores de Microsoft 365 empresarial aceptaron el correo de dominios sin DMARC. Eso puede cambiar.
También hay una discusión legítima entre especialistas sobre si un DMARC con p=none aporta seguridad real. Su valor práctico hoy es doble: cumple el requisito de existencia que exigen cada vez más receptores y habilita los reportes que permiten detectar fallas y suplantaciones. Para el negocio, la conclusión es operativa y no ideológica: el costo de cumplir es bajo; el de no hacerlo son correos perdidos.
Cómo saber si su dominio está expuesto
Paso 1. Revise si existe el registro. Desde una terminal:
dig +short TXT _dmarc.sudominio.comEn Windows puede usar nslookup -type=TXT _dmarc.sudominio.com. Si la respuesta empieza con "v=DMARC1, el registro existe. Si no hay respuesta, su dominio cumple la condición que activa estos rechazos.
Paso 2. Pruebe con una cuenta real. Envíe un correo desde una dirección de su dominio a una cuenta personal de Outlook o Hotmail y revise si regresa un rebote.
Paso 3. Revise sus sistemas de envío. Además del correo de las personas, su dominio envía correo desde su CRM, su sistema de facturación, su tienda en línea, su herramienta de boletines y formularios del sitio web. Cada uno debe estar autorizado en SPF o firmar con DKIM del dominio.
Cómo corregirlo
1. Publique el registro DMARC
En el DNS de su dominio, cree un registro TXT con estos valores:
Nombre: _dmarc
Tipo: TXT
Valor: v=DMARC1; p=none; rua=mailto:[email protected]La política p=none pide reportes sin instruir a nadie a rechazar correo, por lo que no cambia cómo otros proveedores tratan sus mensajes. Mantenga un solo registro DMARC: si el dominio tiene dos, los receptores pueden ignorar ambos.
2. Confirme que SPF o DKIM pasen alineados
DMARC solo pasa si SPF o DKIM validan para el dominio que aparece en el campo De. Un registro DMARC no ayuda si ninguno de los dos está alineado.
Google Workspace. En la Consola de administración, active la autenticación DKIM del dominio (Gmail, Autenticar correo electrónico), publique el registro TXT que genera Google y pulse Iniciar autenticación. Verifique también que el SPF del dominio incluya a Google:
v=spf1 include:_spf.google.com ~allMicrosoft 365. Active DKIM para el dominio personalizado en el portal de seguridad: publique los dos registros CNAME de selector y después active la firma.
Servicios de terceros (boletines, CRM, facturación). Cada proveedor entrega sus propios registros SPF o DKIM. Si el servicio envía con el dominio de ellos en lugar del suyo, no habrá alineación y DMARC fallará aunque todo parezca configurado.
3. Verifique y monitoree
Una vez publicado, vuelva a ejecutar la prueba del paso 2 y revise los reportes agregados que llegan a la dirección indicada en rua. Los reportes son XML poco legibles; para uso empresarial conviene un servicio que los procese y alerte cuando un flujo legítimo deja de autenticar.
Después de p=none: el camino correcto
p=none es el piso, no la meta. La ruta habitual es observar reportes durante algunas semanas, corregir los flujos legítimos que no autentican, pasar a p=quarantine y finalmente a p=reject. Ese último paso protege su marca contra suplantación, pero no debe darse sin monitoreo previo: una política estricta con un sistema de envío mal configurado hace que sus propios correos desaparezcan.
Lista de verificación
- El dominio tiene exactamente un registro TXT en
_dmarc. - El dominio tiene un solo registro SPF que incluye a todos los servicios que envían en su nombre.
- DKIM está activo para el servicio principal de correo y para cada herramienta de envío.
- Se probó el envío a una cuenta personal de Outlook o Hotmail.
- Alguien recibe y revisa los reportes DMARC, o existe un servicio que lo hace.
- El área comercial sabe que un rebote técnico puede ser la razón por la que un cliente no respondió.
Un debate de fondo
Este episodio reabrió una discusión conocida: cuando pocos proveedores concentran la mayoría de los buzones, sus reglas se vuelven las reglas de todos, y los operadores pequeños tienen pocos recursos para cuestionarlas. Entre los especialistas hay quienes consideran razonable exigir autenticación básica y quienes critican que el rechazo se haga sin aviso previo y con mensajes poco claros. Ambas posturas pueden ser ciertas a la vez. Para una empresa, la decisión práctica no cambia: cumplir lo que los grandes receptores exigen es parte de operar correo hoy.
Preguntas frecuentes
¿Por qué Outlook o Hotmail rechazan los correos de mi empresa?
Desde el 5 de noviembre de 2026 se ha observado que los servicios de correo personal de Microsoft (outlook.com, hotmail.com, live.com y msn.com) rechazan parte del correo de dominios que no publican un registro DMARC. El rebote suele indicar que el mensaje carece de registros de autenticación SPF, DKIM o DMARC.
¿Cuál es la solución más rápida?
Publicar un registro TXT de DMARC en el DNS del dominio, con la política p=none como punto de partida, y verificar que SPF o DKIM pasen alineados con el dominio del remitente. En la mayoría de los casos reportados esto detiene los rechazos en cuanto el registro es visible en el DNS.
¿Esto afecta a los correos que envío a clientes con Microsoft 365 corporativo?
Según los reportes disponibles, los rechazos provienen de los servidores de consumo de Microsoft (cuentas personales), no de los buzones corporativos de Microsoft 365. Aun así, conviene tener los tres registros configurados para todos los destinatarios.
¿Basta con tener SPF y DKIM?
No necesariamente. Varios casos reportados tenían SPF y DKIM válidos y alineados, y aun así fueron rechazados por no tener registro DMARC.
¿Publicar DMARC con p=none cambia cómo otros proveedores tratan mi correo?
No. La política p=none declara que el dominio usa DMARC y solicita reportes, pero no instruye a los receptores a rechazar ni a enviar a spam el correo que falle. Es el punto de partida seguro.
¿Necesita ayuda?
En Bvgaboo revisamos la autenticación de correo como parte de la implementación y administración de Google Workspace: auditoría de SPF, DKIM y DMARC, corrección de remitentes de terceros y monitoreo de reportes. Si sospecha que correos importantes de su empresa no están llegando, escríbanos y revisamos su dominio.
Fuentes
- MailRoute: Outlook.com rechaza correo de dominios sin DMARC
- EasyDMARC: Microsoft rechaza correos sin DMARC
- Bento: Outlook rechazó correo sin DMARC (reporte de Al Iverson, Spam Resource)
- dmarcdkim.com: Message lacks SPF/DKIM/DMARC Auth Records
- Microsoft: Corregir el error NDR 550 5.7.515 en Outlook.com
- Microsoft Outlook.com Postmaster: políticas y lineamientos