Varios usuarios de Outlook.com y Hotmail llevan desde hace unos días recibiendo menos correos de los que deberían, y muchos todavía no se han dado cuenta. El motivo es un fallo de autenticación SPF que hace rebotar mensajes legítimos, incluso los de remitentes con registros DNS correctamente configurados. El problema afecta tanto a cuentas personales como a dominios corporativos y sigue sin una explicación oficial de Microsoft.
El fallo empezó tras rastrear quejas similares en los foros de soporte de Microsoft y en Reddit. Los afectados describen un patrón muy concreto: el correo se envía con normalidad, pero el servidor de Outlook lo rechaza alegando que falla la comprobación SPF, aunque el dominio remitente cumpla con todos los requisitos de seguridad. Desde el 5 de noviembre se acumulan cientos de reportes, y la mayoría coincide en los mismos síntomas.
Qué pasa con la recepción de correo en Outlook
El fallo tiene una particularidad que lo hace más peligroso de lo habitual: quien no recibe el correo no se entera de que falta nada. Es el remitente quien recibe el aviso de rechazo, mientras que el destinatario de Outlook o Hotmail sigue viendo su bandeja de entrada como si todo estuviera en orden.
Según los reportes recopilados en los foros de Microsoft, muchos usuarios solo han descubierto el problema al contactar por teléfono o mensajería con alguien que llevaba días escribiéndoles sin éxito. Un usuario de Outlook.com calculó que, desde el 5 de noviembre, alrededor de la mitad de los clientes que le habían escrito recibieron un aviso de rechazo en vez de ver su correo entregado con normalidad.
Uno de los casos documentados en el foro de soporte de Microsoft 365 resulta especialmente llamativo: un cliente llevaba tres semanas intercambiando correos sin incidencias con un contacto, hasta que una respuesta fue rechazada de la nada. Al probar a escribirse a su propia cuenta de Hotmail se topó con el mismo error, mientras que tanto Gmail como un buzón de Exchange independiente aceptaron sus mensajes de prueba sin problema.
Los códigos de error, al detalle
Los avisos de rebote que reciben los remitentes no son ambiguos: apuntan directamente a un fallo de autenticación, aunque el remitente jure (y demuestre) que su configuración es correcta. Hay dos códigos que se repiten una y otra vez en los reportes.
El primero es el 550 5.7.23, que según la documentación de soporte de Microsoft indica que el servidor de destino no ha podido validar el SPF del dominio remitente, y recomienda revisar los registros DNS con el administrador de TI. El segundo es el 550 5.7.1, cuyo mensaje completo suele leerse como «Message lacks SPF/DKIM/DMARC Auth Records»: Outlook no encuentra las cabeceras de autenticación que necesita para confiar en el remitente.
Lo inusual de esta ola de rechazos es que los códigos aparecen en dominios que llevan años enviando correo sin incidencias y que mantienen sus registros DNS al día. Un usuario lo resumió así en el foro de Microsoft: «Dominios con SPF, DMARC y DKIM válidos están siendo rechazados. Solo ocurre con un pequeño porcentaje de los correos (probablemente depende de a qué servidor de Microsoft se enruta tu mensaje)».
Por qué fallan los registros de Outlook
El SPF, o Sender Policy Framework, es el mecanismo que permite a un servidor receptor comprobar si el servidor que envía un correo está autorizado por el dominio remitente. Junto al DKIM, la firma digital del mensaje, y al DMARC, la política que decide qué hacer si algo falla, forman la base de la autenticación de correo moderna. Sin estos controles, cualquiera podría enviar correo suplantando un dominio ajeno.
Lo que no encaja en esta ola de rechazos es que remitentes con los tres registros correctamente publicados también están cayendo en el filtro. Un caso ilustra bien la inconsistencia: un mensaje enviado desde Zoho a una cuenta de Outlook.com fue rechazado a las 15:50, y el mismo mensaje, reenviado a las 16:09, llegó sin problema mostrando que tanto el SPF como el DKIM habían pasado la validación. El contenido no cambió entre un envío y otro; solo el momento en que se procesó.
Otro usuario describió una situación parecida al enviar correo solo a cuentas de Hotmail: «Solo nos hemos encontrado con esto al enviar a cuentas de Hotmail. Ayer tuvimos los primeros rechazos; reenviar el correo a veces funcionaba. Hoy he tenido un correo enviado a dos destinatarios: no hubo problema con el destinatario de Gmail, pero el de Hotmail rebotó». Microsoft exige el cumplimiento estricto de SPF, DKIM y DMARC a los remitentes que envían más de 5.000 correos diarios a sus servicios de consumo, pero varios de los afectados aseguran estar muy por debajo de ese umbral, lo que descarta ese motivo en sus casos concretos.
Qué hacer mientras Microsoft no confirma una causa
Microsoft no ha emitido ningún comunicado reconociendo el fallo ni ha fijado una fecha de solución, y tampoco ha explicado si el origen está en un cambio de política de filtrado o en una incidencia puntual de sus servidores. Mientras la causa siga sin aclararse, la prioridad pasa por reducir el riesgo de que un correo importante se pierda sin que nadie llegue a enterarse, ya que el fallo no deja ningún rastro visible en la bandeja de entrada del destinatario.
No existe ningún truco que garantice la entrega al cien por cien, pero las medidas cambian según el papel que se ocupe en esta cadena de envío: quienes reciben correo en una cuenta de Outlook.com o Hotmail, y quienes envían mensajes hacia esas cuentas desde otro proveedor como Gmail, Zoho o un servidor corporativo propio. Los casos documentados en los foros de soporte muestran que ambos perfiles pueden verse afectados sin previo aviso.
Como el fallo es silencioso para quien recibe, la medida más eficaz es avisar de forma proactiva a los contactos habituales (clientes, proveedores, familia) de que existe esta incidencia desde el 5 de noviembre. Conviene pedirles que, si no obtienen respuesta en un plazo razonable, prueben a contactar por otro canal o reenvíen el mensaje pasados unos minutos, ya que varios de los casos reportados se resolvieron así.
Si gestionáis un negocio o dependéis de una cuenta de Outlook.com o Hotmail para recibir encargos, merece la pena revisar con los clientes habituales si han escrito recientemente sin obtener respuesta. Como no hay ninguna alerta visible en la bandeja de entrada, la única forma de detectar el fallo pasa por preguntar directamente o comparar fechas con quien envió el mensaje.
Cómo reaccionar si vuestros envíos a Outlook o Hotmail rebotan
Si llega un 550 5.7.23 o un 550 5.7.1, lo primero es no dar por hecho que la configuración está mal, aunque tampoco descartéis un error sutil en el DNS. Revisad los registros SPF, DKIM y, sobre todo, DMARC, porque varios de los casos resueltos en los foros pasaban precisamente por ahí.
Un usuario de Reddit contó cómo solucionó su caso: «Mismo problema, empezó ayer a las 4 de la madrugada, hora del Pacífico. Revisé el SPF, el DKIM y el DMARC, y parecía que todo estaba bien. Los volví a comprobar y resultó que al dominio de mi organización le faltaba una entrada DMARC en el DNS. Lo configuré como p=none por ahora. Y eso parece haberlo arreglado: llevo una hora haciendo pruebas y no he tenido ningún fallo».
Microsoft no ha confirmado públicamente la causa del fallo ni ha fijado una fecha de solución, así que, hasta nuevo aviso, reintentar el envío pasados unos minutos y revisar la entrada DMARC siguen siendo las únicas vías que les han funcionado a quienes ya han logrado esquivar el bloqueo.