Exigências do Gmail e Yahoo para remetentes em massa: checklist

O Gmail e o Yahoo exigem, desde fevereiro de 2024, que remetentes em massa autentiquem o domínio com SPF e DKIM, publiquem DMARC alinhado com o From, ofereçam descadastro de um clique em mensagens comerciais e mantenham a taxa de reclamação baixa. Segundo as diretrizes do Google, remetente em massa é quem envia cerca de 5.000 mensagens ou mais por dia para contas do Gmail, e a taxa de spam deve ficar abaixo de 0,1%, nunca chegando a 0,3%. Abaixo está o checklist completo, separado entre o que vale para todos e o que vale para quem envia em volume.

Por que essas regras importam no Brasil

Uma parte enorme das listas brasileiras é composta por endereços @gmail.com, @yahoo.com.br e @hotmail.com/@outlook.com. Mesmo quem envia para clientes corporativos esbarra em empresas que usam Google Workspace. Na prática, as regras do Gmail viraram o piso de qualidade do mercado. A Microsoft anunciou exigências semelhantes para o Outlook.com em 2025, o que reforça a tendência: autenticação e descadastro fácil deixaram de ser diferencial.

Requisitos para todos os remetentes

Mesmo que você envie poucas mensagens, as diretrizes do Google pedem:

• SPF ou DKIM configurados para o domínio de envio.
• DNS reverso válido: o IP de envio precisa de um registro PTR, e o nome do PTR precisa resolver de volta para o mesmo IP (forward-confirmed reverse DNS).
• TLS na conexão SMTP.
• Mensagens no formato da RFC 5322, com headers válidos e um único From.
• Não se passar pelo Gmail no From: usar @gmail.com como remetente através de outro servidor é rejeitado pela política DMARC do próprio Gmail.
• Taxa de spam baixa: abaixo de 0,1%, sem chegar a 0,3%, conforme medido no Postmaster Tools.

Teste o reverso assim:

dig +short -x 203.0.113.10
# mta1.example.com.br.
dig +short mta1.example.com.br
# 203.0.113.10

Requisitos adicionais para remetentes em massa

Ao passar de cerca de 5.000 mensagens por dia para o Gmail, entram as obrigações extras:

1. SPF e DKIM

Os dois, não um ou outro. O DKIM deve assinar com o seu domínio (d=example.com.br), não com o do fornecedor.

2. DMARC publicado e alinhado

_dmarc.example.com.br.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com.br"

A política pode ser none, mas o domínio do From precisa estar alinhado com o domínio que passou no SPF (Return-Path) ou no DKIM (d=). Alinhamento relaxado basta: bounces.example.com.br alinha com example.com.br.

3. Descadastro de um clique em mensagens comerciais

Mensagens promocionais e de marketing precisam dos dois headers da RFC 8058:

List-Unsubscribe: <https://example.com.br/u/9f2c1e>, <mailto:sair@example.com.br?subject=9f2c1e>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Os dois headers devem estar cobertos pela assinatura DKIM. Além disso, o pedido de descadastro precisa ser processado em até dois dias, segundo Google e Yahoo. Um link visível de descadastro no corpo da mensagem continua sendo esperado.

4. Taxa de reclamação sob controle

Para remetentes em massa, a régua de 0,1%/0,3% é o principal indicador. Ultrapassar 0,3% de forma sustentada, segundo o Google, tira o remetente da elegibilidade para mitigações quando ele pedir revisão.

O que muda no Yahoo

As regras do Yahoo foram anunciadas em conjunto com as do Google e são praticamente equivalentes: SPF e DKIM, DMARC com pelo menos p=none, alinhamento, descadastro de um clique honrado em até dois dias e taxa de reclamação baixa. O Yahoo também opera um Complaint Feedback Loop, que envia relatórios individuais de reclamação no formato ARF (RFC 5965). Vale se cadastrar: é a forma mais direta de remover quem reclamou.

Checklist consolidado

Infraestrutura

• [ ] IP de envio com PTR e forward-confirmed reverse DNS.
• [ ] TLS habilitado no MTA de saída.
• [ ] Hostname do HELO/EHLO coerente com o PTR.

Autenticação

• [ ] SPF no domínio do Return-Path, com menos de 10 consultas DNS.
• [ ] DKIM de 2048 bits com d= no seu domínio.
• [ ] DMARC publicado com rua e alinhamento verificado em envio real.

Conteúdo e lista

• [ ] List-Unsubscribe com URL HTTPS e List-Unsubscribe-Post em todo envio comercial.
• [ ] Descadastro processado em menos de 48 horas (idealmente na hora).
• [ ] Link de descadastro visível no corpo.
• [ ] Remoção automática de hard bounces.
• [ ] Base com consentimento registrado (o que também é exigência da LGPD).

Monitoramento

• [ ] Domínio verificado no Google Postmaster Tools.
• [ ] Cadastro no Complaint Feedback Loop do Yahoo.
• [ ] Alerta interno quando a taxa de spam passar de 0,1%.

Como verificar se você está em conformidade

1. Envie para uma caixa do Gmail e abra "Mostrar original". Os campos SPF, DKIM e DMARC devem aparecer como PASS.
2. Confira os headers da mensagem recebida: List-Unsubscribe e List-Unsubscribe-Post precisam estar lá, e o h= do DKIM-Signature deve listá-los.
3. Abra o Postmaster Tools e acompanhe a taxa de spam e o painel de conformidade, que mostra o status de cada requisito para o seu domínio.
4. Leia as rejeições. Mensagens fora das regras costumam voltar com respostas SMTP como:

550-5.7.26 Unauthenticated email from example.com.br is not accepted due to
550-5.7.26 domain's DMARC policy...

421-4.7.28 ... unusual rate of unsolicited mail originating from your IP address...

O 5.7.26 indica falha de autenticação; o 4.7.28 é limitação temporária por volume ou reputação. Os dois pedem ação imediata, não apenas novas tentativas.

Erros comuns

• Achar que só vale acima de 5.000 por dia. As regras básicas valem para todos; o volume só adiciona obrigações.
• Colocar o descadastro de um clique só no marketing por newsletter e esquecer campanhas disparadas pelo CRM.
• Usar a URL de descadastro com confirmação ("tem certeza?") no endpoint de POST. O POST precisa descadastrar sem interação.
• Medir reclamação pela própria ferramenta. O número que conta é o do Postmaster Tools.
• Misturar transacional e marketing no mesmo domínio e IP, fazendo uma campanha ruim derrubar a entrega de redefinição de senha.

Onde a Pidgely ajuda

A Pidgely aplica esses requisitos por padrão: DKIM por domínio, SPF alinhado via subdomínio de return-path, headers de descadastro de um clique (RFC 8058) nos envios comerciais, supressão automática e um guarda de reputação que pausa a conta antes que bounces e reclamações passem dos limites. A ideia é que estar em conformidade seja o estado normal, não um projeto à parte.