Nossos Diferenciais

Os e-mails que envio vão para a caixa de SPAM do destinatário…. O que fazer?

Esta é uma situação complexa de se resolver. E é tudo baseado com a reputação do servidor de email que está enviando o conteúdo.

Existem técnicas, desenvolvidas ao longo dos anos, para verificar se um e-mail é legitimo – e empresas que cadastram IPs de servidores que não seguem as regras (é um pouco mais complexo do que isto, mas vamos deixar assim por enquanto).

quando você escreve um e-mail (pelo cliente desktop, celular ou webmail), ele entrega no servidor do seu serviço de para que seja entregue ao destinatário. Aqui começam as regras anti-spam. Vamos falar um pouco das mais utilizadas (cada provedor implementa níveis mais rígidos do que outros). 

SPF: Sender Policy Framework. Esta é a primeira verificação que é feita. O servidor que está recebendo a mensagem verifica se quem está enviando está usando um servidor autorizado para isto. Ele “pega” a parte do dominio (tudo que vem depois do @) e vai até o serviço de DNS do dominio para ver se aquele IP está listado como autorizado. Se não estiver cadastrado, ele falha no SPF. Na mesma resposta, o servidor fala qual a política que pode ser aplicada neste caso:

Não existe SPF: neste caso, não é possível determinar se o endereço IP está ou não autorizado a enviar e-mails em nome do domímio sendo consultado.

Pass(“+”): significa que o IP está autorizado a enviar mensagens em nome do domínio, sendo que o domínio consultado pode, então, ser considerado responsável pelo envio da mensagem.

Fail(“-“): significa explicitamente que o IP não está autorizado a enviar mensagens em nome do domínio consultado. Este resultado pode ser utilizado para rejeitar a mensagem ou para marcá-la para ser avaliada mais rigorosamente.

SoftFail(“?”): deve ser tratado como um resultado intermediário entre os níveis fail e neutral. Neste caso, o domínio consultado informa que acha que o IP não está autorizado, mas que não pode fazer uma afirmação taxativa. A mensagem não deve ser rejeitada apenas com base neste resultado, mas é recomendável submetê-la a outros testes. Softfail também tem sido usado para indicar uma situação transitória, em que o SPF está sendo adotado por um domínio.

Neutral(“?”):  o dono do domínio não tem como ou não quer definir se um determinado endereço IP está ou não autorizado a enviar mensagens em nome do domínio. Este resultado deve ser tratado exatamente como se não existisse um registro SPF, não devendo ser avaliado de forma mais rigorosa devido a isto.

Vamos pegar, por exemplo, o SPF do Google:

v=spf1 include:_spf.google.com ~all

A política do Google, neste caso é a SoftFail (~all), para os IPs que estão relacionados _spf.google.com.

Com esta informação tenho a primeira orientação do que fazer com a mensagem: mais testes.

A segunda validação que é feita é com o registro DKIM. Este processo é mais elaborado, pois o servidor que está enviando coloca um cabeçalho (não visível nos clientes de e-mail) com uma chave criptográfica gerada no servidor e que pode ser verificada por quem está recebendo.

Ou seja, o servidor que está enviando inclui a informação a ser verificada por quem está recebendo. Isto é feito com uma segunda consulta ao DNS, procurando pela chave DKIM.

Aqui a política anti-spam pode tomar alguns rumos:

OK. Ele não tem SPF, mas tem o DKIM: Através do uso do DKIM, uma organização assina digitalmente as mensagens que envia, permitindo ao receptor confirmar a autenticidade da mensagem. Pode ser um servidor de e-mail marketing e vou deixar passar (“ou não, para ele aprender a configurar corretamente” – este sou eu em um dia de fúria).

Mas aí, surge a dúvida: Devo deixar passar em uma situação destas? pode ser alguém se passando pelo remetente e vou deixar SPAM na caixa de entrada do usuário.

Para estas situações, surgiu o DMARC: Ele representa exatamente o que deve ser feito nestas situações. DMARC é uma sigla em inglês para “Mensagem Baseada em Domínio de Autenticação, Relatório e Conformidade”.

Com a configuração correta do DMARC, é muito mais simples e eficaz, determinar se uma mensagem é legitimamente enviada a partir de um remetente; mas não apenas isso: DMARC permite definir o que fazer se a mensagem realmente não for do remetente.

Um proprietário do domínio que tem implantado a autenticação de e-mails pode começar a usar DMARC em “modo de monitor”, para recolher dados de destinatários participantes.

Como os dados mostram se o tráfego está passando nas verificações de autenticação, eles podem mudar sua política para solicitar que as mensagens de falha sejam colocadas em quarentena, por exemplo.

Se for detectado uma quantidade consistente de e-mail falsos, eles podem adotar a política de indicar aos remetentes a rejeição das mensagens.

Depois destas validações de autenticidade da mensagem, iniciam-se as regras internas de anti-SPAM, que são ainda mais rigidas, onde verifica-se o conteúdo da msg em busca de palavras-chave, como “Viagra”, “Enlarge”, etc.

Uma coisa importante que o DMARC fornece é o relatório de conformidade. Os provedores que adotam o DMARC publicam um e-mail para onde os relatórios devem ser enviados. Com estes relatórios, temos condições de corrigir as informações para que as mensagens sejam entregues corretamente na caixa de entrada.

Nosso Diferencial:

Nós nos preocupamos com a entrega do seu e-mail corretamente na caixa de entrada do seu cliente. Temos alguns robôs que analisam os relatórios enviados e alertam em caso de problemas.

Ao receber o alerta, analisamos se é causado por por alguma configuração errada da nossa parte (acontece, ninguém é perfeito!) ou outro motivo qualquer.

Quando isto ocorre, se for algo que possamos resolver, atuamos na mesma hora; Se precisar de intervenção do proprietário do domínio, conversamos com ele para ajustarmos.

O Problema mais comum de todos (95% dos casos) é quando o proprietário contrata um Active Campain, Mailchimp ou alguma empresa de e–mail marketing e não nos avisa.

Estas empresas possuem seus próprios servidores de disparo e recomendam aos clientes as configurações de DKIM e SPF que precisam de inclusão no DNS…. Mas o cliente não nos informa.

Com isto, todas as campanhas dos clientes são colocadas diretamente na caixa de spam do usuário ou simplesmente “jogadas fora”, de acordo com a Política de DMARC.

 
 
Ao receber o alerta de problemas de entrega, nossos analistas começam analisando com a nossa ferramenta de análise de DMARC. Na tela acima, vocês podem verificar as últimas linhas: A política de DMARC que adotamos é REJECT e em 100% dos casos. Isto informa aos provedores para não aceitarem mensagens que não possuam DKIM correto, nem SPF para os domínios.
 
Acima destas linhas linhas temos os casos dos clientes que não nos passam informações das empresas de e-mail marketing e temos que buscar os dados para garantir a entregabilidade.
 
Todas estas informações estão em fase de implementação em nosso dashboard. 
 
Quer saber como está a entregabilidade de seu e-mail? Fale com a gente! Podemos preparar um relatório sem custos de uma semana de análise para você.
 

Quero Saber Mais

Leave a comment

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *