Mudanças nas Políticas de Spam do Gmail em 2024

Políticas de E-mail do Gmail a Partir de Fevereiro de 2024

A partir de fevereiro de 2024, Yahoo e Gmail passarão a exigir a implementação da política DMARC nos domínios, uma mudança significativa que pode impactar diretamente a entregabilidade de seus envios de e-mail.

A política DMARC, estabelecida mediante uma configuração no DNS de seu domínio, tem em vista validar as configurações de SPF e DKIM.

É crucial garantir que seus domínios adotem essa política o mais rápido possível para evitar possíveis problemas de rejeição e classificação como spam.

Compreendendo os requisitos do Gmail e do Yahoo DMARC

Em 3 de outubro de 2023, o Google e o Yahoo anunciaram requisitos para que remetentes em massa tenham o DMARC em vigor a partir de fevereiro de 2024.

Como parte da nossa missão de tornar o DMARC acessível a todos, estamos aqui para ajudar. Este guia fornecerá orientação, independentemente do tamanho ou da complexidade da sua infraestrutura de e-mail.

Vá para os requisitos técnicos

Quem é afetado?

Se você enviar 5.000 mensagens por dia ou mais para qualquer um dos maiores provedores de caixa de correio do mundo, a partir de fevereiro de 2024, seu domínio de e-mail deverá ter uma política DMARC em seu DNS. Essas mensagens devem passar pelo alinhamento DMARC ou não serão entregues. Isso inclui mensagens enviadas em nome da sua organização por provedores de serviços de e-mail (ESPs) terceirizados, como Constant Contact e MailChimp, que usam seu domínio de e-mail.

Observação: se você também hospeda seu domínio no Google Workspace, o volume de mensagens internas provavelmente será contabilizado nesse limite diário.

Por que isso está acontecendo?
O Google e o Yahoo reconhecem a importância do e-mail e estão tomando medidas para torná-lo mais seguro e protegido. Ao se concentrarem na validação de e-mail, eles ajudam a evitar que spam indesejado e possíveis malfeitores cheguem às caixas de entrada de seus clientes.

Enviar de um domínio que possui DMARC tem o benefício adicional de melhorar o posicionamento da caixa de entrada. Um registro DMARC ajuda os ISPs a identificá-lo como um remetente que leva a sério os padrões de e-mail estabelecidos e reduz sua responsabilidade por spam.

Como me preparo para essa mudança?
Um bom lugar para começar é determinar o status dos seus domínios de e-mail. Nosso verificador de domínio gratuito verificará o status da sua conformidade com o DMARC, juntamente com os protocolos de código aberto nos quais ele foi desenvolvido, SPF e DKIM . SPF é uma lista de servidores e serviços autorizados a enviar e-mail através do seu domínio, e DKIM é um selo à prova de falsificação que verifica se o conteúdo do seu e-mail não foi alterado.

O DMARC ensina ao mundo como lidar com e-mails não autorizados enviados através do seu domínio, gerando relatórios à medida que seu e-mail chega ao destino. Esses relatórios podem ser enviados para a poderosa plataforma de gerenciamento DMARC do dmarcian , que oferece visibilidade e controle sobre como seus domínios de e-mail são usados. Ele fornece insights acionáveis ​​em cada etapa do caminho em direção à conformidade com o DMARC e muito mais.

Se você possui um recurso de TI interno (ou externo) responsável pelo gerenciamento de seu e-mail e DNS, a dmarcian está aqui para ajudar em cada etapa do processo com ferramentas robustas e uma vasta biblioteca de recursos.

Se você não possui recursos de TI na equipe, temos uma rede de MSPs (provedores de serviços gerenciados) e parceiros que utilizam a melhor plataforma e conhecimento técnico da dmarcian para implantar o DMARC de maneira eficaz e precisa.

Requerimentos técnicos
Para qualquer pessoa que envie mais de 5.000/dia para qualquer um dos maiores provedores de caixa de correio do mundo, eis o que você precisa fazer:

Você deve ter uma política DMARC em seu DNS . Embora uma política de modo monitor de p=none seja suficiente para o Google e o Yahoo, este é apenas o primeiro estágio para aproveitar ao máximo o controle de segurança.

Primeiro, verifique se você possui um registro DMARC com nosso Inspetor DMARC .
Se você não tiver um registro DMARC, use nosso Assistente de registro DMARC para criar um.
Quase todos os projetos DMARC começam com um modo somente monitor de p=none . A seleção padrão do nosso assistente é este valor.
O registro DMARC deve então ser publicado em seu DNS.
Habilitar o monitoramento DMARC é o primeiro passo para obter insights sobre se você tem alguma fonte de e-mail que esteja fora de conformidade.
É provável que você precise de uma ferramenta de visualização para ajudar a entender os dados. Você pode iniciar um teste gratuito conosco para obter informações sobre seus domínios e ser orientado durante o processo.
Suas mensagens devem passar pelo DMARC . As mensagens podem passar pelo alinhamento DMARC de duas maneiras.

Suas mensagens passam pelo DKIM, usando o mesmo domínio da sua mensagem From: header ; este é o valor d= nos cabeçalhos de e-mail.
Suas mensagens passam pelo SPF, usando o mesmo domínio da sua mensagem From: header . Este é o valor Return-Path nos cabeçalhos de e-mail. Esse valor de cabeçalho às vezes é chamado de “domínio de devolução”, “envelope de” ou “MailFrom”.

Destas duas opções, o DKIM tende a ser um método mais fácil e confiável, pois sobrevive ao encaminhamento. Assim como os postmasters do Google e do Yahoo promoveram, dmarcian também recomenda uma abordagem DKIM-first. No entanto, um registro SPF válido deve estar presente.
Os IPs de envio devem ter um registro PTR. Também conhecido como “DNS direto e reverso” ou “nome de host”.

Se você mantiver algum de seus próprios servidores de e-mail, deverá validar se cada endereço IP possui um registro PTR correspondente em seu DNS.
Se você não mantém nenhum de seus próprios servidores de e-mail, essa responsabilidade recai sobre os fornecedores de e-mail que você utiliza. Como o DMARC é um meio de observar quem, o quê e como seu domínio está sendo usado para enviar e-mails, o monitoramento básico do DMARC (p=nenhum) pode ajudar a validar se seus fornecedores de e-mail estão em conformidade.
É raro que servidores de e-mail legítimos não tenham um registro PTR. Os bandidos aprenderam a comprometer outros dispositivos conectados (dispositivos inteligentes, modems residenciais, etc.) para enviar e-mails. A ausência de um registro PTR é um sinal claro para o destinatário de que este endereço IP não está configurado corretamente para enviar e-mail.
Não envie spam :

O Yahoo pede que você envie mensagens apenas para destinatários que tenham optado por recebê-las. Você respeita a frequência estabelecida no momento do registro e não compra listas.
O Gmail exige que você mantenha sua taxa de reclamação de spam abaixo de 0,3%. Eles ainda oferecem um serviço de reputação gratuito para ajudá-lo a controlar suas taxas de spam.
Formate corretamente suas mensagens: Os e-mails devem atender aos padrões estabelecidos pela RFC 5322 .

Não falsifique gmail.com ou yahoo.com: Google e Yahoo começarão a implementar suas próprias políticas DMARC. Se você estiver usando um serviço de e-mail que permite enviar “como seu endereço @gmail.com ou @yahoo.com”, provavelmente terá problemas substanciais de entrega. A melhor aposta é abrir um ticket de suporte com seu provedor para entender de forma mais adequada o que exatamente está em jogo para você.

Incluir cancelamento de assinatura com um clique: você precisará instituir um cancelamento de assinatura com um clique até junho de 2024 para que seus e-mails sejam entregues. O Yahoo diz que o cancelamento da assinatura com um clique deve atender às solicitações do usuário dentro de dois dias. O Google acrescenta que um link de cancelamento de assinatura claramente visível deve estar no corpo da mensagem.

Datas de aplicação das diretrizes do remetente
O Yahoo relata que a aplicação das diretrizes do remetente será implementada gradualmente à medida que eles monitoram a conformidade durante o primeiro semestre do ano:

A partir de fevereiro de 2024, o Yahoo aplicará certos padrões para todos os remetentes , incluindo:
Autenticando adequadamente seu e-mail
Manter baixas as taxas de reclamação
A partir de fevereiro de 2024, os requisitos para remetentes em massa serão mais rigorosos, incluindo:
Permitindo o cancelamento fácil da assinatura com um clique a partir de junho de 2024
Autenticação com SPF e DKIM
Publicando uma política DMARC
As datas de aplicação do remetente “ graduais e progressivas ” do Google são as seguintes:

Em fevereiro de 2024, os remetentes em massa que não atenderem aos requisitos de envio começarão a receber erros temporários (com códigos de erro) em uma pequena porcentagem do tráfego de e-mail não compatível. Esses erros temporários têm como objetivo ajudar os remetentes a identificar o tráfego de e-mail que não atende às nossas diretrizes, para que os remetentes possam resolver problemas que resultem em não conformidade.
Em abril de 2024, o Google começará a rejeitar uma porcentagem do tráfego de e-mail não conforme e aumentará gradualmente a taxa de rejeição. Por exemplo, se 75% do tráfego de um remetente atender aos nossos requisitos, o Google começará a rejeitar uma porcentagem dos 25% restantes do tráfego que não esteja em conformidade.
Os remetentes em massa têm até 1º de junho de 2024 para implementar o cancelamento de assinatura com um clique em todas as mensagens comerciais e promocionais.

Traduzido eletronicamente
Referencia: https://dmarcian.com/yahoo-and-google-dmarc-required/

O que é SPF (Sender Policy Framework) e por que devo configurar corretamente?

O SPF (Sender Policy Framework) é um mecanismo para combater a falsificação de endereço de e-mails, o mecanismo permite:

1 – o administrador de um domínio: definir e publicar uma política SPF, onde são designados os endereços das máquinas autorizadas a enviar mensagens em nome deste domínio;

2 – o administrador de um serviço de e-mail: estabelecer critérios de aceitação de mensagens em função da checagem das políticas SPF publicadas para cada domínio.

Ao publicar uma política de SPF, o administrador de um domínio está autorizando determinados MTAs a enviar e-mails em nome deste domínio. O objetivo é evitar que terceiros enviem mensagem indevidamente em nome de seu domínio, e que mensagens de erro (bounces) causadas por spam com envelope falso sejam enviadas para o seu servidor.

O administrador de um MTA que consulte a política SPF do domínio do remetente de um e-mail, como definido no envelope, poderá rejeitar ou marcar como suspeita uma mensagem que não satisfaça à política SPF daquele domínio.

A especificação completa de como expressar uma política SPF pode ser encontrada no site de referência do SPF (https://www.openspf.org/) e na RFC 4408: “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1” (http://tools.ietf.org/html/rfc4408).

Exemplo:

example.com.   IN            TXT        “v=spf1 a mx ip4:192.0.2.32/27 -all”

Neste caso a política estabelece que pode enviar mensagens em nome do domínio example.com uma máquina que satisfaça um dos seguintes critérios:

seu endereço IP deve ser um RR tipo A do domínio example.com (a);
seja designada como MX do domínio example.com (mx); ou
pertença ao bloco de endereços IP 192.0.2.32/27 (ip4).
A cláusula “-all” diz que devem ser recusados (“-“, prefixo Fail) e-mails partindo de qualquer outro endereço IP (all).

Todas as opções de prefixos são:

“+” Pass
“-” Fail
“~” SoftFail
“?” Neutral

O prefixo é opcional, e se omitido o valor utilizado é o “+” (Pass).

A cláusula “all” deve ser sempre a cláusula mais à direita. Ela define qual resposta será retornada em uma consulta SPF, caso nenhuma das outras cláusulas se aplique.

A configuração para e-mails do Google é importante para que suas mensagens são sejam identificadas como SPAM e sejam entregues ao destinatários corretamente, segue as configuração para o Google Apps:

Para criar um registro SPF para um domínio:

Faça login no console administrativo do seu domínio.

Localize a página a partir da qual você de deseja atualizar os registros DNS.

Talvez seja necessário ativar configurações avançadas.

Crie um registro TXT contendo este texto: v=spf1 include:_spf.google.com ~all

Você pode introduzir o IP diretamente: v=spf1 ip4:83.206.106.17 ~all

Publicar um registro SPF usando -all em vez de ~all pode gerar problemas de entrega. Consulte Intervalos de endereço IP do Google para detalhes sobre os endereços de servidores de e-mail do Google Apps.Para autorizar mais um servidor de e-mail, adicione o endereço IP do servidor antes do argumento ~all usando o formato ip4:endereço ou ip6:endereço.

Se seu registro também exigir uma configuração de host, como @, consulte os registros TXT para uma lista de instruções precisas de provedores de domínios específicos.

Salve suas alterações.

As alterações em registros DNS podem levar até 48 horas para serem propagadas pela Internet.

Referencias:

Registro.br: https://www.antispam.br/admin/spf/

Open SPF (Sender Policy Framework): https://www.openspf.org/

 

Configurar registros SPF para funcionar com o Google Apps

Para criar um registro SPF (Sender Policy Framework) para um domínio:

  1. Faça login no console administrativo do seu domínio.
  2. Localize a página a partir da qual você de deseja atualizar os registros DNS.
    Talvez seja necessário ativar configurações avançadas.
  3. Crie um registro TXT contendo este texto: v=spf1 include:_spf.google.com ~allPublicar um registro SPF usando -all em vez de ~all pode gerar problemas de entrega. Consulte Intervalos de endereço IP do Google para detalhes sobre os endereços de servidores de e-mail do Google Apps.Para autorizar mais um servidor de e-mail, adicione o endereço IP do servidor antes do argumento ~all usando o formato ip4:endereço ou ip6:endereço. Consulte Sender Policy Framework para mais detalhes sobre o formato SPF.
  4. Se seu registro também exigir uma configuração de host, como @, consulte os registros TXT para uma lista de instruções precisas de provedores de domínios específicos.
  5. Salve suas alterações.
    As alterações em registros DNS podem levar até 48 horas para serem propagadas pela Internet.
Observação: vários registros SPF não são recomendados e podem causar problemas de entrega e de classificação de spam. Consulte Vários registros SPF para mais informações.

Se você tiver dificuldade para criar um registro SPF, entre em contato com seu provedor de domínio para receber ajuda.

Vários registros SPF

Vários registros SPF não são recomendados e podem causar problemas de entrega e de classificação de spam. De acordo com as especificações do RFC, um nome de domínio não pode ter vários registros, pois isso pode fazer com que a verificação de autorização selecione mais de um registro.

Se precisar autorizar mais de um servidor de e-mail para seu domínio, recomendamos que você atualize o registro SPF existente em vez de criar vários registros.

Exemplo

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

Esse texto fará a verificação de SPF falhar porque há vários registros. Em vez disso, adicione o endereço IP do servidor de e-mail antes do argumento ~all usando o formato ip4:address ou ip6:address para adicionar o servidor ao registro SPF existente:

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

Para mais detalhes sobre de como configurar registros SPF para funcionar com o Google Apps, consulte Sender Policy Framework.