Todo o correio externo para o Office 365 falha no SPF, marcado como lixo eletrônico pelo EOP em uma implantação híbrida

Em resumo: os emails legítimos estão chegando nas pastas Lixo eletrônico, pois o EOP (Exchange Online Protection) carimba as mensagens de email como lixo eletrônico (SCL5) e falha no SPF. Isso acontece com todos os domínios externos (por exemplo, gmail.com/hp.com/microsoft.com) para o domínio do cliente (contoso.com).

Informações de fundo:

Estamos no início da migração de caixas de correio para o Office 365 (Exchange Online). Essa é uma configuração de Implantação híbrida / Coexistência rica, em que:

• No local = Exchange 2003 (herdado) e 2010 (instalado para implantação híbrida)
• Fora das instalações = Office 365 (Exchange Online)
• O EOP está configurado para verificação do SPF.
• Os registros MX estão apontando para o local, pois não concluímos a migração de todas as caixas de correio do local para o Exchange Online.

O problema é que, quando usuários externos enviam emails para uma caixa de correio do Office 365 na organização (fluxo de email: Externo -> Gateway de Email -> servidores de email no local -> EOP -> Office 365), o EOP executa uma pesquisa SPF e mensagens com falha com o endereço IP externo do gateway de email do qual recebeu o email.

(As caixas de correio locais não mostram esse problema; somente as caixas de correio migradas para o Office 365 o fazem.)

Uma ilustração:

Exemplo 1: da Microsoft para 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

Exemplo 2: da HP para o 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

Exemplo 3: do Gmail para o 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 cabeçalhos de mensagens com o X-Forefront-Antispam-Report, consulte http://pastebin.com/sgjQETzM

Nota: 23.1.4.9 é o endereço IP público do conector do servidor Exchange 2010 híbrido no local para o Exchange Online.

Como impedir que emails externos sejam marcados como lixo eletrônico pelo EOP durante o estágio de coexistência de uma implantação híbrida?

[Atualização 12/12/2015]

Esse problema foi corrigido pelo suporte do Office 365 (a equipe escalada / de back-end), pois não tem nada a ver com nossas configurações.

Sugerimos o seguinte:

1. Coloque o IP público na lista de permissões EOP na lista de permissões (tentei. Não ajudou.)
2. Adicione registro SPF ao nosso domínio: "v = spf1 ip4: XXX.XXX.XXX.XXX ip4: AAA. AAAA. AAAA. AAAA inclua: spf.protection.outlook.com -all" (Não pense que esta sugestão é válida como o EOP não deve verificar gmail.com em relação ao nosso endereço IP SMTP, pois não está especificado nos registros SPF do gmail.com. Isso não parece o modo como o SPF funciona.)
3. Verifique se o TLS está ativado (veja abaixo)

A parte principal é o terceiro ponto. "Se o TLS não estiver ativado, o email recebido do Exchange local não será marcado como email interno / confiável, e o EOP verificará todos os registros", disse o suporte.

O suporte determinou um problema de TLS em nossos cabeçalhos de correio pela linha abaixo:

• X-MS-Exchange-Organization-AuthAs: anônimo

Isso indica que o TLS não estava ativado quando o EOP recebeu um email. O EOP não tratou o email recebido como email confiável. O correto deve ser como:

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

No entanto, isso não foi causado por nossas configurações; a pessoa de suporte nos ajudou a garantir que nossas configurações estivessem corretas, verificando os logs SMTP detalhados do servidor Exchange 2010 Hybrid.

Na mesma época, sua equipe de back-end corrigiu o problema sem nos informar o que exatamente o causou (infelizmente).

Depois de corrigi-lo, descobrimos que os cabeçalhos das mensagens tiveram algumas alterações significativas, como abaixo.

Para email de origem interna do Exchange 2003 para o Office 365:

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

• SCL = -1 (Era SCL = 5)

• SPF recebido: SoftFail (era o mesmo)

E para emails externos (por exemplo, gmail.com) para o Office 365:

• X-MS-Exchange-Organization-AuthAs: anônimo (era o mesmo)

• SCL = 1 (era SCL = 5)

• SPF recebido: SoftFail (era o mesmo)

Embora a verificação do SPF ainda sofra uma falha suave do gmail.com (externo) no Office 365, a pessoa do suporte disse que estava tudo bem, e todos os emails iriam para a Caixa de Entrada em vez da pasta Lixo Eletrônico.

Como observação lateral, durante a solução de problemas, a equipe de back-end encontrou um problema de configuração aparentemente menor - tivemos o IP do nosso Conector de Entrada (ou seja, IP público do servidor Exchange 2010 Hybrid) definido em nossa Lista de Permissões de IP (sugerida por outro suporte do Office 365 pessoa como uma etapa de solução de problemas). Eles nos informam que não devemos fazer isso e, de fato, isso pode causar problemas de roteamento. Eles comentaram que, no passe inicial, o email não estava sendo marcado como spam, então também havia um possível problema aqui. Em seguida, removemos o IP da lista de permissões de IP. (No entanto, o problema de spam existia antes da configuração da Lista de Permissões de IP. Não achamos que a Lista de Permissões era a causa.)

Em conclusão, "deveria ser um mecanismo de EOP", disse a pessoa de suporte. Portanto, tudo deve ser causado por seu mecanismo.

Para qualquer pessoa interessada, o segmento de solução de problemas com uma de suas pessoas de suporte pode ser visto aqui: https://community.office365.com/en-us/f/156/t/403396

Tem certeza de que o fluxo de mensagens vai diretamente do seu servidor Hybrid para o O365?

Quando você executou o assistente híbrido, ele deveria ter criado conectores localmente e no O365, que analisará o fluxo de mensagens entre as florestas como correio interno. Isso significa que ele ignorará as verificações de EOP / Spam e você nunca deverá ver essas mensagens SPF.

Se o seu dispositivo de borda estiver modificando os cabeçalhos, isso pode estar causando o problema - entre o servidor e o O365, nada deverá modificar os cabeçalhos da mensagem. Verifique se você não possui um conector existente que possa estar substituindo os criados pelo assistente híbrido. Você sempre pode excluir os conectores existentes que foram criados e executar novamente o assistente para recriá-los.

Verifique suas regras de transporte no Exchange e verifique se elas não estão modificando a mensagem antes de ir para o O365, se elas estiverem desativadas e teste novamente para garantir que não sejam o seu problema.

Por último (ou talvez primeiro), verifique se sua federação está configurada corretamente. Caso contrário, é por isso que seu e-mail não é tratado corretamente. É aqui que, ao executar novamente o assistente híbrido, você também pode ajudá-lo.

Não sou especialista aqui, faz muito tempo que não joguei no Exchange, mas tentarei responder da melhor maneira possível.

Vamos discutir o design por um segundo, por que você não direciona todo o tráfego primeiro para o EOP e depois para os servidores Exchange locais? você está perdendo uma boa funcionalidade lá, definitivamente facilitaria o controle de spam em um único local (suponha que você seja o Exchange local também tenha um filtro anti-spam).

Agora vamos ao problema do spam:

1. Fluxo de mensagens e conectores : Tenho a sensação de que os conectores não estão configurados corretamente, se todos os seus e-mails recebidos parecerem ser originários do mesmo endereço IP 23.1.4.9 em vez do endereço IP do servidor de email do remetente, com certeza as verificações do SPF falhariam , pois o objetivo é verificar o IP do remetente e o nome de domínio desse IP. Eu definitivamente gastaria algum tempo revisando como os conectores são configurados. Aqui está um bom link: https://technet.microsoft.com/en-us/library/ms.exch.eac.connectorselection(v=exchg.150 ) .aspx
2. Filtros de spam EOP e filtros de conexão : se a configuração de IP dos conectores for feita corretamente, talvez seja o momento em que você analise seus filtros de spam / conexão em EOP, eu criaria filtros para ignorar a verificação de e-mails recebidos do IP 23.1.4.9, mas isso faria com que todos os e-mails recebidos ignorassem as listas de verificação do filtro de spam. Isso leva ao problema mencionado no ponto anterior, verifique seus conectores e, preferencialmente, direcione o e-mail recebido para o EOP primeiro.