Os e-mails são constantemente marcados pelo Outlook.com como SPAM

Question

Um de nossos domínios é constantemente marcado pelo Outlook como SPAM, apesar da configuração adequada que é relatada como configurada e validada corretamente por muitos usuários on-line. ferramentas de linha, entre elas, o mxtoolbox .

Por favor, note que em qualquer outra plataforma ou servidor, os e-mails são recebidos corretamente na caixa de entrada, sem qualquer intervenção do usuário.

Para ajudar você a entender e / ou fornecer uma resposta para o problema em questão:

Este domínio existe há mais de um ano.
O endereço IP está dentro de um intervalo de IPs gerenciados por nós por mais de um ano (o IP e o intervalo estão limpos). Este domínio tem um certificado SSL e envia e-mails através de SSL / TLS.

Atacar cabeçalhos de e-mail de amostra, refletindo os resultados de autenticação, de uma mensagem enviada do domínio em questão e recebida por uma conta de e-mail @ outlook.com:

Received: from SN1NAM02HT119.eop-nam02.prod.protection.outlook.com (2603:10a6:6:14::16) by DB6PR08MB2805.eurprd08.prod.outlook.com with HTTPS via DB6PR05CA0003.EURPRD05.PROD.OUTLOOK.COM; Wed, 7 Feb 2018 12:37:27 +0000

Received: from SN1NAM02FT033.eop-nam02.prod.protection.outlook.com (10.152.72.56) by SN1NAM02HT119.eop-nam02.prod.protection.outlook.com (10.152.72.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Wed, 7 Feb 2018 12:37:26 +0000

Authentication-Results:
spf=pass (sender IP is XXX.XXX.XXX.XXX)
smtp.mailfrom=EXAMPLE.COM; outlook.com;
dkim=pass (signature was verified) header.d=EXAMPLE.COM;outlook.com;
dmarc=pass action=none header.from=EXAMPLE.COM;

Received-SPF: Pass (protection.outlook.com: domain of EXAMPLE.COM designates XXX.XXX.XXX.XXX as permitted sender) receiver=protection.outlook.com; client-ip=XXX.XXX.XXX.XXX; helo=SRV-HOSTNAME.COM;

Received: from SRV-HOSTNAME.COM (XXX.XXX.XXX.XXX) by SN1NAM02FT033.mail.protection.outlook.com (10.152.72.133) with Microsoft SMTP Server id 15.20.464.11 via Frontend Transport; Wed, 7 Feb 2018 12:37:25 +0000

┌────────────────────┬───────────────────────────────────────────────────┐
│ Data               │ Refers to                                         │
├────────────────────┼───────────────────────────────────────────────────┤
│ XXX.XXX.XXX.XXX    │ The correct server IP address                     │
│                    | Proper Reverse DNS setup                          |
├────────────────────┼───────────────────────────────────────────────────┤
│ EXAMPLE.COM        │ The domain name in question                       │
│                    | Proper DNS setup                                  |
├────────────────────┼───────────────────────────────────────────────────┤
│ SRV-HOSTNAME.COM   | The server hostname                               |
|                    | (hosts multiple domains)                          |
└────────────────────┴───────────────────────────────────────────────────┘

Relacionado com este problema:

Como / onde podemos consultar o suporte técnico do Outlook sobre esse problema?
ou
Como podemos obter detalhes técnicos sobre a classificação de nossas mensagens para que possamos entender o problema e lidar com ele?

    

Answer 1

A Microsoft faz mais processamento de DNS / MX do que outros provedores, o que pode explicar seu problema. Consulte esta resposta para sugestões que podem ser úteis.

Além disso, você só tem que aceitar que, se você está tentando entregar alguma coisa aos usuários com o webmail da MS, você terá problemas. Tenho a sorte de ter algum controle sobre meus destinatários e peço que não usem contas de MS, com algum sucesso. Eu tenho que fornecer instruções detalhadas sobre a lista de permissões para aqueles que não vão mudar.

Dito isto, o MS irá realmente colocar na lista de permissões se você perguntar bem. A "equipe de suporte de fornecimento de microsoft" do Google e preencha o formulário da Web, que é atualmente aqui . O problema é que isso dura apenas um ano, então você tem que repetir com frequência e, pior, você tem que esperar até que alguém o notifique de que não está mais recebendo seus e-mails. Boa sorte.

    

Answer 2

Eu estive olhando para isso como eu tive o mesmo problema e abaixo está uma descrição do que eu pude determinar.

Em primeiro lugar, você deve fazer todas as coisas que você deve fazer de qualquer maneira como remetente de e-mail.

1. Verifique se o endereço IP do qual você está enviando tem um registro PTR ("reverse DNS") que mapeia para um nome de host que você possui e que o nome do host lista esse endereço IP como um de seus registros A. Este é um DNS reverso confirmado antecipadamente como definido pelo returnpath.com (Eu vi o FCrDNS definido de forma diferente em outro lugar, então fique atento a informações imprecisas sobre isso - na realidade, o FCrDNS é menos restritivo do que algumas pessoas pensam).

2. Verifique se seu servidor está enviando um nome de host real em seu comando HELO / EHLO e não algo genérico como "localhost" ou apenas um subdomínio sem domínio. É uma boa idéia para que este seja o host que está enviando o e-mail.

3. Verifique se o endereço IP de envio não está em nenhuma lista negra principal. A verificação em mxtoolbox.com deve retornar zero hits da lista negra - a verificação em multirbl.valli.org pode retornar um ou dois, porque algumas das listas negras no site são "questionáveis".

Mas, além disso, há algumas coisas específicas para saber sobre os servidores da Microsoft (outlook.com, hotmail.com, live.com):

1. A filtragem de spam não é em preto-e-branco - uma mensagem que a Microsoft considera spam pode ignorar tudo o que é correto, e um e-mail que não pareça spam pode passar corretamente mesmo se você cometer erros configuração do servidor. O que eles acham que parece com spam é algo que ninguém sabe, mas os tipos de URLs na mensagem podem ser um fator.

2. A própria Microsoft admite que um endereço IP novo ou de baixo volume pode ter correspondência classificado como spam até obter uma reputação melhor - ou seja, até que não seja recebido spam suficiente desse endereço. Eu gosto de pensar que as pessoas que vão para a pasta de spam e marcam seu e-mail como "isso não é spam" devem ajudar a acelerar esse processo, mas não posso confirmar. Logicamente, faria sentido que isso apenas ajudasse a entregabilidade para essa pessoa .

3. DKIM, SPF e DMARC são uma boa ideia, mas eu já vi muitos e-mails chegarem ao outlook.com que não tem DKIM (e, portanto, nenhum DMARC) ou que falha em um desses dois últimos testes . Certifique-se de que as informações do SPF estejam corretas e tente usar "? All" no final para que um resultado negativo seja indeterminado em vez de representar uma falha. Lembre-se de que as alterações na entrada do SPF em seu DNS levam tempo para se propagar e a Microsoft pode até armazená-lo em cache por até 48 horas, mesmo que isso seja mais longo que o DNS.

4. Microsoft informe que a certificação com a returnpath.com deve ajudar a entregabilidade, já que eles são parceiros com esse serviço. Infelizmente, parece que isso custa um monte de dinheiro, e também não estou convencido de que isso traga muitos benefícios aos servidores de e-mail comuns, sendo mais voltado para pessoas com grandes listas de e-mail com alto volume de e-mails enviados para assinantes.

5. A Microsoft tem um Programa de geração de relatórios de lixo eletrônico , que permite exibir informações sobre o endereço IP de envio reputação. Até agora não consegui me inscrever nesse serviço e sou cético quanto a detalhes sobre por que um e-mail pode ser classificado como spam, já que parece que é mais uma questão de saber se as pessoas realmente denunciando seus e-mails como spam.