Desde el 5 de noviembre, Outlook.com (y con él Hotmail, Live y MSN) está devolviendo parte del correo que llega desde dominios que no publican un registro DMARC. Lo ha contado Thomas A. Johnson, de MailRoute, que lo vio en sus propios logs de salida ese mismo día, y otros administradores empezaron a reportarlo a la vez.
Lo curioso es que Microsoft no ha dicho nada. Ni aviso en su portal de postmaster, ni entrada en el blog, ni incidencia en el estado del servicio. Simplemente, ha empezado a pasar.
Cómo se ve el rebote
El remitente recibe algo así:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
El primer día llegaba incluso sin el código (AS9031519) del final. El mensaje da a entender que está todo roto, y normalmente no es así: según MailRoute, la mayoría de los dominios rechazados tenían SPF funcionando, y muchos también DKIM. Lo que les faltaba era el registro DMARC que une esas dos comprobaciones con la dirección del From.
Qué tiene de distinto
Microsoft ya tenía reglas publicadas: desde mayo de 2025, quien envía más de 5.000 correos al día a Outlook.com tiene que pasar SPF, DKIM y DMARC, o recibe un 550 5.7.515 Access denied. Era una regla para envíos masivos, y casi cualquier empresa pequeña asumía, con razón, que no iba con ella.
Esto es otra cosa:
- Afecta a remitentes pequeños. Una respuesta de una línea desde una oficina puede rebotar.
- No se ha anunciado. A 6 de noviembre no había nada publicado.
- No dice qué ha fallado. El
5.7.515indica el resultado de SPF, DKIM y DMARC; este sólo dice que faltan registros. - Rechaza sólo una parte. Un correo pasa, el siguiente rebota y el reenvío puede entrar.
Ese último punto es el peligroso. Quien envía ve un rebote lleno de siglas, piensa que es un fallo puntual y sigue con lo suyo. Y al otro lado, el cliente nunca sabe que le escribieron: facturas que no llegan, confirmaciones de cita que se pierden, respuestas que parecen ignoradas.
Comprobar tu dominio
Desde cualquier terminal, cambiando example.com por tu dominio:
dig +short TXT _dmarc.example.com
Si sale una línea que empieza por "v=DMARC1, tienes registro. Si no sale nada, no lo tienes, y ese es justo el caso que Outlook está rechazando.
La solución es un registro DNS
Un registro TXT en tu proveedor de DNS:
| Campo | Valor |
|---|---|
| Nombre | _dmarc |
| Tipo | TXT |
| Valor | v=DMARC1; p=none |
p=none es el punto de partida seguro: declara que tu dominio usa DMARC, pero pide a los receptores que no hagan nada con los correos que fallen. No cambia cómo te tratan Gmail, Yahoo ni nadie más. Si además quieres recibir los informes agregados, se añade un rua=mailto: con una dirección tuya, y así ves quién está enviando en nombre de tu dominio.
Hay una condición: DMARC sólo pasa si SPF o DKIM pasan para el dominio del From, lo que se llama alineación. Si envías desde un servicio que firma con su propio dominio, el registro DMARC por sí solo no basta. El ejemplo que pone el artículo es Microsoft 365, que firma con onmicrosoft.com hasta que activas DKIM para tu dominio, y esa firma no cuenta para DMARC. Lo mismo vale para el típico formulario de la web que envía con la función mail() del servidor, o para la herramienta de newsletters que configuraste hace años y de la que ya ni te acuerdas.
Lo que me llevo
Es el patrón de siempre con el correo: los requisitos empiezan por los grandes remitentes, se anuncian con fecha y, sin hacer ruido, acaban siendo lo mínimo para todos. Gmail y Yahoo hicieron lo mismo con sus reglas de 2024, y ahora le toca a Outlook con los pequeños, esta vez sin avisar.
Si tienes un dominio propio, aunque sólo lo uses para un blog o para el correo de casa, son cinco minutos: el dig, el registro y, si te animas, revisar que SPF y DKIM están alineados. Y no es sólo para que Outlook te deje pasar: un dominio con DMARC es bastante más difícil de suplantar, y ese p=none es el primer paso para llegar algún día a p=reject.
Fuente: Outlook.com Is Quietly Rejecting Email From Domains Without DMARC, Thomas A. Johnson, MailRoute.
