Adequando o servidor às exigências do Google e yahoo: SPF, DKIM e DMARC na prática

Quem envia e-mails a partir de servidores próprios ou gerencia disparos de notificações e newsletters percebeu a mudança clara nas regras do jogo. O que antes era tratado apenas como sugestão ou boa prática passou a ser critério eliminatório: sem autenticação completa e registros alinhados, as mensagens caem direto na caixa de spam ou são rejeitadas logo no handshake SMTP pelo Google e Yahoo.

Quando as novas diretrizes entraram em vigor para remetentes em massa (especialmente acima de 5.000 mensagens por dia), revisei a configuração de todos os domínios do servidor. A seguir, mostro o passo a passo prático do que foi implementado para garantir a entrega limpa na caixa de entrada.

Os requisitos centrais do Google e yahoo#

Os provedores estabeleceram três frentes principais para combater spam e falsificação de identidade:

1. Autenticação completa: SPF e DKIM válidos e alinhados com o domínio do remetente (From: visível).
2. Registro DMARC ativo no DNS: Presença obrigatória de uma política DMARC publicada.
3. Controle de cancelamento e taxa de spam: Taxa de reclamações no Google Postmaster Tools abaixo de 0,3% (idealmente abaixo de 0,1%) e cabeçalhos de cancelamento de inscrição em um clique (One-Click Unsubscribe) para mensagens em lote.

1. Ajustando a base: SPF e DKIM#

O DMARC depende diretamente do SPF e do DKIM. Se a base estiver descalibrada, a política de proteção vai descartar seus próprios envios legítimos.

Registro SPF#

No DNS de dominio.com.br, o registro SPF deve ser único (nunca crie dois registros TXT começando com v=spf1) e autorizar explicitamente os IPs de saída do seu servidor ou serviços de envio:

dominio.com.br.  IN  TXT  "v=spf1 ip4:192.0.2.10 include:_spf.google.com ~all"

• O qualificador ~all (SoftFail) é o padrão mais seguro durante a fase de transição, permitindo que o DMARC tome as decisões com base nos relatórios.

Registro DKIM#

Chaves curtas de 1024 bits estão sendo descontinuadas por motivos de segurança criptográfica. O recomendado é gerar chaves RSA de 2048 bits no seu MTA (Exim, Postfix ou painel de hospedagem) e publicar a chave pública no seletor correspondente:

default._domainkey.dominio.com.br.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

2. Implementando o DMARC em fases#

Adotar o DMARC de uma vez com bloqueio total (p=reject) sem antes analisar o tráfego é arriscado, pois ferramentas externas (como sistemas de faturamento, CRM ou formulários do site) podem estar enviando em nome do seu domínio sem a assinatura correta.

A abordagem segura é iniciar em modo monitoramento:

_dmarc.dominio.com.br.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@dominio.com.br; pct=100; sp=none; aspf=r; adkim=r"

O que cada parâmetro significa:#

• v=DMARC1: Versão do protocolo DMARC.
• p=none: Política inicial que apenas monitora e solicita relatórios, sem descartar mensagens com falha.
• rua=mailto:...: Endereço de e-mail que receberá os relatórios agregados diários em formato XML.
• pct=100: Aplica a checagem a 100% dos fluxos de e-mail.
• aspf=r e adkim=r: Alinhamento relaxado para SPF e DKIM, aceitando subdomínios organizacionais.

Evolução gradual da política:#

1. Fase 1 (p=none): Monitore os relatórios XML por 2 a 4 semanas para identificar todos os remetentes autorizados.
2. Fase 2 (p=quarantine): Direciona e-mails não autorizados para a pasta de spam dos destinatários.
3. Fase 3 (p=reject): Bloqueia sumariamente qualquer tentativa de envio não autorizado no servidor de destino.

3. Cabeçalhos de descadastramento (one-click unsubscribe)#

Para newsletters, avisos promocionais ou notificações transacionais em grande volume, o Google e o Yahoo exigem o mecanismo de cancelamento em um clique direto na interface do cliente de e-mail.

Isso é feito adicionando os seguintes cabeçalhos RFC 8058 na mensagem enviada pelo seu aplicativo ou script:

List-Unsubscribe: <https://dominio.com.br/unsubscribe?token=abc123xyz>, <mailto:unsubscribe@dominio.com.br?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Quando o usuário clica no botão "Cancelar inscrição" no topo do Gmail, o Google envia uma requisição POST com o corpo List-Unsubscribe=One-Click para a URL informada, processando o cancelamento imediatamente sem pedir confirmação adicional.

4. Validação pelo terminal#

Depois que os registros DNS propagam, você pode testar a resposta das entradas diretamente no terminal:

# Validar registro DMARC
dig +short TXT _dmarc.dominio.com.br

# Validar registro SPF
dig +short TXT dominio.com.br

# Validar chave pública DKIM no seletor
dig +short TXT default._domainkey.dominio.com.br

# Testar se o IP reverso (rDNS/PTR) do servidor responde corretamente
dig -x 192.0.2.10 +short

Monitorando a entrega no dia a dia#

Depois de publicar os registros e ajustar as chaves:

• Cadastre seu domínio no Google Postmaster Tools para acompanhar a reputação do IP, a taxa de spam reportada pelos usuários e a taxa de sucesso da autenticação.
• Utilize analisadores de relatórios DMARC (como DMARCian, Valimail ou ferramentas de código aberto) para processar os arquivos XML recebidos na sua caixa rua.
• Certifique-se de que o IP reverso (PTR) do seu servidor aponte exatamente para o hostname configurado no banner SMTP (HELO/EHLO).

Configurar essa tríade protege a reputação do seu domínio contra tentativas de falsificação e garante que suas mensagens legítimas continuem chegando sem atrito à caixa de entrada.

Veja também

Infraestrutura Gmail rejeitando e-mails do DirectAdmin: como autenticar o hostname com SPF e DKIM

E-mail Whitelist de Domínio vs. Bloqueio RBL no cPanel e Exim: Por Que Liberar o Domínio Falha e Como Funcionam as DNSBLs

E-mail O buraco negro do Exim, falhas de alinhamento DMARC e como recuperar a reputação de IP

Este post está licenciado sob CC BY-NC.