Un sysadmin reporta fallos de SPF tras añadir un segundo registro MX

Un administrador de sistemas ha contado en un foro técnico un problema que arrancó justo después de tocar el DNS de su dominio: una tanda de correos rechazados por fallos de SPF en el portal de su servicio antispam. Su hipótesis es incómoda y la lanza en forma de pregunta: que Microsoft haya empezado a enrutar el correo de sus remitentes desde otro pool por haber detectado un cambio en la configuración del destinatario. Nadie lo ha confirmado.

El montaje que describe

El dominio tenía un MX apuntando al filtro antispam externo, que solo procesa tráfico entrante, y otro hacia domain.mail.protection.outlook.com. En Exchange Online había dos piezas: un conector de entrada que identifica la organización asociada verificando el dominio del remitente y rechaza lo que no llegue desde el rango de IP del antispam, y una regla de transporte que fija el SCL a -1 cuando el emisor cae dentro de ese rango. El skip listing, el filtrado mejorado, nunca estuvo activado, según su relato.

Después añadió un MX más apuntando al antispam y actualizó conector y regla con la IP nueva. Ahí empezaron los fallos de SPF: el emisor salía desde una IP de Microsoft que no figura en el registro SPF de Outlook. El autor sospecha que esa dirección pertenece a un pool de relé o de riesgo alto.

Todo esto es su lectura de los hechos. No hay respuesta de Microsoft, ni capturas, ni la configuración completa. Falta saber qué remitentes fallaban, qué cabeceras llevaban los mensajes rechazados y si el problema va más allá de su dominio.

Lo único comprobable por ahora es lo que ve su antispam: el registro SPF que publica Microsoft lista un conjunto concreto de rangos y la IP desde la que llegaban esos envíos no estaba entre ellos. Que la causa sea el cambio de MX, que haya coincidido en el tiempo o que sea un efecto lateral de otra cosa queda abierto. Para quien administre correo con conector de entrada y reglas de transporte, el aviso es concreto: tocar los MX obliga a revisar después qué IPs y qué registros de autenticación llegan de verdad al conector, y no solo los que uno esperaba ver.