Office 365 para Empresas – Envío de Correos Reenviados o Retransmitidos desde un Pool de IP No Definido por su Registro SPF – Tampa, Clearwater, St Petersburg Florida

Un usuario se quejó de no recibir un correo en su cuenta de Gmail; su dirección de correo 365 estaba configurada para enviar una copia (CC) a su cuenta de Gmail en todos los correos entrantes. Al investigar esto, encontramos que el correo sí llegó a su cuenta 365, pero la regla de transporte para enviar una copia a su cuenta de Gmail falló debido a que la verificación SPF/DKIM no pasó.

La imagen de arriba muestra lo que vimos en el rastreo de mensajes (con los dominios cambiados a «example» por seguridad). Como se puede ver, el mensaje a «example.com», que es el correo de 365, llegó.

Pero el mensaje a «gmail.com», que es el destino del relay en una regla de flujo de correo CC, no logró pasar.

Hicimos clic en el mensaje que falló para ver más detalles al respecto, aquí está el resultado de este ejemplo de falla:

Estado

Office 365 recibió el mensaje que especificaste, pero no pudo entregarlo al destinatario (example@gmail.com) debido al siguiente error:

Error: 550 5.7.26 Este mensaje no pasa las verificaciones de autenticación (SPF y DKIM ambos 550-5.7.26 no pasan). La verificación SPF para [example.com] no pasa con ip: 550-5.7.26 [40.95.31.57]. Para proteger mejor a nuestros usuarios del spam, el mensaje ha 550-5.7.26 sido bloqueado. Por favor, visita 550-5.7.26 https://support.google.com/m. OutboundProxyTargetIP: 74.125.137.27. OutboundProxyTargetHostName: gmail-smtp-in.l.google.com

Así es como se ve en el rastreo de mensajes:

EXPLICACIÓN Y RESOLUCIÓN:

Ignorando la sección «Cómo solucionarlo» en la foto anterior, esto es lo que necesitas saber:

Microsoft publica un conjunto de direcciones IP en su registro SPF (spf.protection.outlook.com), cuando incluyes el registro SPF de Microsoft en tu DNS, estás incluyendo esas IPs como remitentes verificados de servidores de correo.

Lo que es menos conocido es que Microsoft también tiene un rango de IPs que NO están incluidas en su registro SPF. Algunas personas en los foros han especulado que Microsoft cometió un error con esto, pero en realidad es intencional y la razón se explica en este artículo de Microsoft:

Artículo de Microsoft

Para resumir los puntos clave de esa publicación de Microsoft:

Las IPs que Microsoft utiliza para retransmitir correos o enviar lo que consideran correos de «alto riesgo» estarán en la subred 40.95.0.0/16.

Puedes saber si un mensaje fue enviado a través de este pool de retransmisión localizando la IP de salida utilizada para enviar (rastro de mensajes) o buscando «rly» en el nombre del servidor de salida (también rastro de mensajes).

Esto se aplica a los correos retransmitidos o reenviados.

El correo entrante a 365 necesita pasar su propia verificación, es decir, el dominio del remitente y el contenido del correo necesitan pasar las verificaciones SPF y de spam. Si no lo hace, esto puede causar que la regla de transporte de retransmisión falle porque el servidor de correo receptor (no Microsoft, sino el servidor de correo al que Microsoft está retransmitiendo) lo rechaza. Cuando un correo no seguro no pasa estas verificaciones, 365 utiliza un servidor de correo del pool de retransmisión para transportar el correo y el servidor de correo receptor puede rechazarlo.

Microsoft también filtra el correo saliente regular (no retransmitido) y si determina que el correo es de «alto riesgo» (spam, malicioso, etc.) lo enviará desde un servidor de correo no publicado. Esto es para evitar que sus IPs regulares sean incluidas en listas negras. Microsoft no indicó en su artículo si el pool de IPs de alto riesgo es la misma subred que el pool de retransmisión.

Por lo tanto, si estás viendo problemas de fallo de mensajes en tu tenant de 365 al retransmitir correos fuera de 365 a través de una regla de transporte, como una regla de CC por ejemplo, revisa el Rastro de Mensajes (https://admin.exchange.microsoft.com/#/messagetrace) y probablemente verás un mensaje de error explicando que el servidor de correo remitente (msft) no pasó la verificación SPF o DKIM o algo por el estilo.

También deberías ver la IP del servidor de correo remitente listada en ese aviso que caerá en la subred 40.95.0.0/16.

Finalmente, llegamos a la resolución, que es agregar la subred del pool de retransmisión a tu registro SPF. Esto permitirá que los correos enviados a través de ese pool de retransmisión pasen las verificaciones SPF, ya que el rango será incluido en tu DNS.

Post original en inglés