Todo el correo externo a Office 365 falla SPF, marcado como basura por EOP en una implementación híbrida

En resumen: los correos electrónicos legítimos están llegando a las carpetas de correo basura cuando EOP (Exchange Online Protection) sella los mensajes de correo electrónico como correo no deseado (SCL5) y SPF falló. Esto sucede con todos los dominios externos (por ejemplo, gmail.com/hp.com/microsoft.com) al dominio del cliente (contoso.com).

Información de fondo:

Estamos comenzando a migrar los buzones a Office 365 (Exchange Online). Esta es una configuración de implementación híbrida / coexistencia enriquecida, donde:

• En las instalaciones = Exchange 2003 (antiguo) y 2010 (instalado para la implementación híbrida)
• Fuera del local = Office 365 (Exchange Online)
• EOP está configurado para la comprobación de SPF.
• Los registros MX apuntan a las instalaciones locales ya que no hemos completado la migración de todos los buzones de las instalaciones a Exchange Online.

El problema es cuando los usuarios externos envían correos electrónicos a un buzón de Office 365 en la organización (flujo de correo: Externo -> Mail Gateway -> servidores de correo locales -> EOP -> Office 365), EOP realiza una búsqueda de SPF y hardware / software mensajes de error con la dirección IP externa de Mail Gateway desde la que recibió el correo.

(Los buzones locales no muestran este problema; solo los buzones migrados a Office 365 sí).

Una ilustración:

Ejemplo 1: de Microsoft a O365

Authentication-Results: spf=fail (sender IP is 23.1.4.9) 
smtp.mailfrom=microsoft.com; contoso.mail.onmicrosoft.com;
dkim=none (message not signed) header.d=none;
Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate
23.1.4.9 as permitted sender) receiver=protection.outlook.com; client-ip=23.1.4.9; 
helo=exchange2010.contoso.com; X-MS-Exchange-Organization-SCL: 5

Ejemplo 2: de HP a O365

Authentication-Results: spf=none (sender IP is 23.1.4.9) 
smtp.mailfrom=hp.com; contoso.mail.onmicrosoft.com; dkim=none 
(message not signed) header.d=none; Received-SPF: None 
(protection.outlook.com: hp.com does not designate permitted sender hosts) 
X-MS-Exchange-Organization-SCL: 5

Ejemplo 3: de Gmail a O365

Authentication-Results: spf=softfail (sender IP is 23.1.4.9) 
smtp.mailfrom=gmail.com; contoso.mail.onmicrosoft.com; 
dkim=fail (signature did not verify) header.d=gmail.com; 
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning 
gmail.com discourages use of 23.1.4.9 as permitted sender)  
X-MS-Exchange-Organization-SCL: 5

Para los encabezados de mensajes con X-Forefront-Antispam-Report, consulte http://pastebin.com/sgjQETzM

Nota: 23.1.4.9 es la dirección IP pública del conector de servidor híbrido de Exchange 2010 local para Exchange Online.

¿Cómo evitamos que EOP marque los correos electrónicos externos como basura durante la etapa de coexistencia de una implementación híbrida?

[Actualización del 12/12/2015]

Este problema fue solucionado por el soporte de Office 365 (el equipo escalado / backend) ya que no tiene nada que ver con nuestra configuración.

Nos sugirieron lo siguiente:

1. Incluya en la lista blanca la IP pública en la lista de permitidos de EOP (Probado. No ayudó).
2. Agregue el registro SPF para nuestro dominio: "v = spf1 ip4: XXX.XXX.XXX.XXX ip4: YYY.YYY.YYY.YYY incluye: spf.protection.outlook.com -todos" (No creo que esta sugerencia sea válida ya que EOP no debe verificar gmail.com con nuestra dirección IP SMTP ya que no está especificada en los registros SPF de gmail.com. Esa no parece la forma en que funciona SPF).
3. Asegúrese de que TLS esté habilitado (consulte a continuación)

La parte clave es el tercer punto. "Si el TLS no está habilitado, el correo electrónico entrante de Exchange local no se marcará como correo electrónico interno / de confianza, y EOP verificará todos los registros", dijo el soporte.

El soporte determinó un problema de TLS de nuestros encabezados de correo en la siguiente línea:

• X-MS-Exchange-Organization-AuthAs: Anónimo

Esto indica que TLS no estaba habilitado cuando EOP recibió un correo electrónico. EOP no trató el correo electrónico entrante como correo electrónico de confianza. El correcto debería ser como:

• X-MS-Exchange-Organization-AuthAs: interno

Sin embargo, esto no fue causado por nuestra configuración; la persona de soporte nos ayudó a asegurarnos de que nuestra configuración fuera correcta verificando los registros SMTP detallados de nuestro servidor híbrido de Exchange 2010.

Aproximadamente al mismo tiempo, su equipo de back-end solucionó el problema sin decirnos qué lo causó exactamente (desafortunadamente).

Después de que lo arreglaron, descubrimos que los encabezados de los mensajes tenían algunos cambios significativos como se muestra a continuación.

Para el correo de origen interno de Exchange 2003 a Office 365:

• X-MS-Exchange-Organization-AuthAs: interno (era "anónimo")

• SCL = -1 (Era SCL = 5)

• Received-SPF: SoftFail (Era lo mismo)

Y para correos externos (por ejemplo, gmail.com) a Office 365:

• X-MS-Exchange-Organization-AuthAs: anónimo (era lo mismo)

• SCL = 1 (Era SCL = 5)

• Received-SPF: SoftFail (Era lo mismo)

Aunque la comprobación de SPF todavía falla por error para gmail.com (externo) a Office 365, la persona de soporte dijo que estaba bien, y que todos los correos irían a la Bandeja de entrada en lugar de a la carpeta Basura.

Como nota al margen, durante la resolución de problemas, el equipo de back-end encontró un problema de configuración aparentemente menor: teníamos la IP de nuestro conector entrante (es decir, la IP pública del servidor híbrido de Exchange 2010) definida en nuestra lista de IP permitidas (sugerida por otro soporte de Office 365 persona como un paso de solución de problemas). Nos informan que no deberíamos necesitar hacer esto y, de hecho, hacerlo puede causar problemas de enrutamiento. Comentaron que en el pase inicial, el correo electrónico no se marcaba como spam, por lo que también había un posible problema aquí. Luego eliminamos la IP de la lista de IP permitidas. (Sin embargo, el problema de spam existía antes de que se hiciera la configuración de la lista de direcciones IP permitidas. No pensamos que la causa fuera la lista de direcciones permitidas).

En conclusión, "debería ser un mecanismo EOP", dijo la persona de apoyo. Por lo tanto, todo debería ser causado por su mecanismo.

Para cualquier persona interesada, el hilo de solución de problemas con una de sus personas de soporte se puede ver aquí: https://community.office365.com/en-us/f/156/t/403396

¿Está seguro de que el flujo de correo va directamente desde su servidor híbrido a O365?

Cuando ejecutó el asistente híbrido, debería haber creado conectores localmente y en O365, que pisarán el flujo de correo entre los bosques como correo interno. Esto significa que omitirá las comprobaciones de EOP / Spam y nunca debería ver esos mensajes SPF.

Si su dispositivo perimetral está modificando los encabezados, esto puede estar causando su problema: entre su servidor y O365, nada debería modificar los encabezados de los mensajes. Asegúrese de no tener un conector existente que pueda anular los creados por el asistente híbrido. Siempre puede eliminar los conectores existentes que se crearon y volver a ejecutar el asistente para volver a crearlos.

Verifique sus reglas de transporte en Exchange y asegúrese de que no estén modificando el mensaje antes de ir a O365, si están deshabilitadas y pruebe nuevamente para asegurarse de que no sean su problema.

Por último (o tal vez primero) verifique que su federación esté configurada correctamente. Si no es así, podría ser por qué su correo no se trata correctamente. Aquí es donde volver a ejecutar el asistente híbrido puede ayudarlo también.

No soy un experto aquí, ha pasado mucho tiempo desde que jugué con Exchange, pero intentaré responder lo mejor que pueda.

Analicemos el diseño por un segundo, ¿por qué no dirige todo el tráfico a EOP primero y luego a sus servidores de Exchange locales? está perdiendo una buena funcionalidad allí, definitivamente le facilitaría las cosas controlar el correo no deseado desde una única ubicación (suponga que Exchange local también tiene un filtro antispam).

Ahora pasemos al problema de spam:

1. Flujo de correo y conectores : Tengo la sensación de que los conectores no están configurados correctamente, si todos sus correos electrónicos entrantes parecen tener su origen en la misma dirección IP 23.1.4.9 en lugar de la dirección IP del servidor de correo del remitente, para asegurarse de que las comprobaciones SPF fallarían , ya que su propósito es verificar la IP del remitente y el nombre de dominio de esa IP del remitente. Definitivamente pasaría algún tiempo revisando cómo se configuran los conectores, aquí hay un buen enlace para eso: https://technet.microsoft.com/en-us/library/ms.exch.eac.connectorselection(v=exchg.150 ) .aspx
2. EOP Spam Filters and Connection Filters : si la configuración de IP de los conectores se realiza correctamente, tal vez sea hora de que mire sus filtros de spam / conexión en EOP, crearía filtros para evitar verificar los correos electrónicos entrantes desde IP 23.1.4.9, pero eso haría que todos los correos electrónicos entrantes pasen por alto las listas de verificación del filtro de correo no deseado, esto lo lleva al problema mencionado en el punto anterior, verifique sus conectores y, preferiblemente, enrute primero el correo electrónico entrante a EOP.