Outlook rechaza emails sin DMARC: cómo arreglarlo

Outlook, Hotmail y Live empezaron a rechazar correo sin DMARC

Desde el 5 de noviembre de 2026, el correo de consumo de Microsoft —Outlook.com, Hotmail, Live y MSN— rechaza parte de los mensajes que llegan de dominios que no publican un registro DMARC. Nadie lo anunció: hasta el 6 de noviembre, la compañía no había publicado nada al respecto, ni una nota en el postmaster, ni una entrada de service health, ni un post en su blog.

El rebote que recibe el remitente es este:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El primer día llegaba sin el código entre paréntesis. El texto sugiere que algo está roto de raíz, pero en la mayoría de los casos no lo está: los dominios que se han visto rebotar tenían SPF funcionando y muchos también DKIM. Lo que faltaba era el registro DMARC que ata esas dos piezas a la dirección del remitente.

Para una startup esto no es un tema abstracto de infraestructura. Si mandas facturas, confirmaciones de turno, respuestas a candidatos o avisos de entrega a direcciones de Hotmail u Outlook, parte de ese correo puede estar cayendo ahora mismo. Y el cliente del otro lado nunca se entera de que le escribiste.

Por qué tu correo pasa a veces y a veces no

Lo peligroso de este comportamiento es su inconsistencia. Microsoft rechaza solo una parte del correo de un dominio afectado: un mensaje entra, el siguiente rebota, un reenvío puede funcionar. Quien envía ve un rebote lleno de siglas, asume una falla puntual y sigue con su día.

Windows Latest reportó el 8 de noviembre que el problema se reproduce desde al menos el 5 de noviembre y que hay cientos de quejas en foros de Microsoft y en Reddit. El medio recogió testimonios que complican el diagnóstico: hay remitentes con SPF, DKIM y DMARC válidos que igual reciben rechazos.

«Dominios con SPF, DMARC y DKIM válidos están siendo rechazados. Solo ocurre con un porcentaje pequeño de los correos (probablemente depende de a qué servidor de Microsoft se enrute el mensaje)», escribió un usuario en el foro de Microsoft, según ese reporte.

Otros casos apuntan a lo mismo. Un cliente de Microsoft 365 contó que llevaba tres semanas escribiéndole a un cliente y de pronto Outlook rechazó una respuesta; sus pruebas llegaron sin problema a Gmail y a un buzón de Exchange. Un usuario de Outlook.com dijo que la mitad de sus clientes que le escribieron desde el 5 de noviembre recibió un rechazo. Y un envío desde Zoho a una dirección de Outlook.com fue rechazado a las 3:50 p.m.; al reenviarlo a las 4:09 p.m. llegó, con SPF y DKIM en PASS.

Cómo saber en 30 segundos si tu dominio está expuesto

Tu dominio está expuesto si no tiene registro DMARC. Se comprueba desde cualquier terminal, reemplazando tudominio.com por el tuyo:

dig +short TXT _dmarc.tudominio.com

Una línea que empiece con v=DMARC1 significa que tienes registro. Sin salida, no lo tienes, y ese es exactamente el caso que este rechazo apunta.

El arreglo es un solo registro TXT

Se agrega en tu proveedor de DNS:

Nombre: _dmarc
Valor: v=DMARC1; p=none

p=none es el punto de partida seguro. Declara que tu dominio usa DMARC y pide a los receptores que te manden reportes, pero les dice que no tomen ninguna acción ante fallas. No cambia cómo Gmail, Yahoo ni nadie más trata tu correo.

Hay una condición que se pasa por alto. DMARC solo pasa cuando SPF o DKIM pasan y alinean con el dominio de tu dirección From. Si ninguno de los dos alinea, el registro DMARC por sí solo no ayuda.

El caso más común es Microsoft 365: firma con su propio dominio onmicrosoft.com hasta que actives DKIM para tu dominio, y esa firma no cuenta para la alineación de DMARC. Lo mismo pasa con herramientas de formularios, facturación o newsletters que envían con su dominio en lugar del tuyo.

Otros dos errores que rompen el arreglo, según la documentación de Google y Microsoft recopilada por el blog técnico note.com:

Tener dos registros SPF en el mismo dominio. Debe haber uno solo; los servicios nuevos se agregan como include: dentro del existente.
Pasarse del límite de 10 consultas DNS de SPF, algo que ocurre sin darse cuenta cuando se acumulan herramientas.

Qué significa esto para tu startup

Cuatro acciones concretas, en orden de esfuerzo:

Verifica hoy. Corre el comando dig sobre tu dominio o usa un checker público. Toma menos de un minuto y te dice si estás en la lista de afectados.
Publica el TXT de _dmarc con p=none. No rompe nada, no cambia la entrega en otros proveedores y te saca del problema con Outlook. Después, cuando los reportes muestren que todo alinea, se sube a p=quarantine y luego a p=reject.
Audita la alineación, no solo la existencia. Haz una lista de todo lo que envía correo con tu dominio: el correo de los empleados, el CRM, el sistema de facturación, los formularios del sitio, la herramienta de newsletter. Para cada uno, confirma que SPF o DKIM firman con tu dominio. Un registro DMARC sobre un envío que firma con el dominio del proveedor no arregla nada.
Monitorea los rebotes 550 5.7.1. Si dependes de correo transaccional para cobrar o para dar servicio, un rebote silencioso es un cliente que no recibe su factura. Vale la pena revisar los logs de envío esta semana.

El patrón que se repite: primero los grandes, después todos

Esto no salió de la nada. Google y Yahoo anunciaron en conjunto requisitos de autenticación para quienes envían 5.000 o más correos a Gmail y Yahoo Mail, y TechTarget documentó cómo los marketers tuvieron que adaptarse. Microsoft publicó reglas equivalentes para Outlook.com: desde el 5 de mayo de 2025, los dominios que envían más de 5.000 mensajes diarios a sus servicios de consumo deben pasar SPF, DKIM y DMARC o reciben un 550 5.7.515 Access denied.

Esa regla estaba dirigida a marketers y grandes remitentes, y la mayoría de las pymes asumió con razón que no le aplicaba. El rechazo que empezó el 5 de noviembre es distinto en lo que importa: alcanza a remitentes pequeños —una respuesta de una línea desde una oficina chica puede rebotar—, no fue anunciado, y no dice qué falló. Un rebote 5.7.515 lista los resultados de SPF, DKIM y DMARC; este solo dice que faltan registros.

La analista Liz Miller, de Constellation Research, le dijo a TechTarget que los actores maliciosos «realmente han descubierto cómo esquivar la gran mayoría de las iniciativas de autenticación de correo». Eso explica por qué los proveedores siguen apretando: el correo falsificado es el punto de entrada de buena parte del phishing y del fraude de correo corporativo.

Conclusión

DMARC en p=none dejó de ser una buena práctica y pasó a ser el piso. Es también el primer paso hacia p=reject, la política que le dice a los receptores que rechacen el correo que falsifica tu dominio, algo que protege a tus clientes y a tu marca.

El costo de no hacerlo es asimétrico: unos minutos de trabajo en el panel de DNS contra facturas que no llegan, confirmaciones que nunca aterrizan y clientes que creen que los ignoraste. Microsoft no avisó esta vez, y probablemente tampoco avise la próxima vez que mueva la línea.