SPF, DKIM e DMARC: por que os indicadores verdes não bastam

Autenticação de e-mail: por que configurar SPF, DKIM e DMARC não basta

Você fez todo o trabalho. Passou horas no DNS copiando strings indecifráveis dos seus provedores de envio. Executou os validadores e viu indicadores verdes por toda parte. Então por que as taxas de abertura estão despencando? Por que e-mails transacionais, como redefinições de senha, faturas e alertas, caem no spam ou desaparecem por completo?

Esta é a verdade sobre autenticação de e-mail com SPF, DKIM e DMARC: uma configuração válida não significa boa reputação. Um documento de identidade válido não faz o segurança deixar uma pessoa embriagada entrar. Desde fevereiro de 2024, provedores como Google, Yahoo e Microsoft passaram a aplicar requisitos técnicos mais rigorosos, além de avaliar se a mensagem parece spam. Se o painel mostra sinais verdes, mas a receita acende alertas vermelhos, você provavelmente esbarrou em uma das barreiras ocultas que vêm depois das siglas básicas.

A armadilha do remetente em massa: o limite é menor do que parece

O equívoco mais perigoso é este: "Eu envio menos de 5,000 e-mails por dia, então as regras para remetentes em massa não se aplicam a mim".

Isso está errado por dois motivos, e acertar SPF, DKIM e DMARC não protege você dessa armadilha. Primeiro, o Google conta o volume no nível do domínio principal. Se você envia 2,000 e-mails de marketing por news.example.com, 2,000 mensagens transacionais por app.example.com e 1,500 alertas internos por corp.example.com, passa a ser um remetente em massa. O volume dos subdomínios é somado ao domínio raiz.

O segundo motivo é a marca histórica máxima. Se você ultrapassar uma única vez o limite de 5,000 e-mails, por exemplo durante uma campanha de Black Friday ou uma atualização pontual do banco de dados, o Google poderá classificar o domínio permanentemente como remetente em massa conforme as regras vigentes. Essa classificação continua valendo mesmo que o volume caia para 50 mensagens diárias, e o domínio permanece sujeito aos requisitos mais rígidos.

A Microsoft aplica critérios diferentes. Seus registros SPF, DKIM e DMARC podem estar impecáveis, mas a idade do IP também importa. Se você lançar um domínio e um IP novos e disparar imediatamente 2,000 e-mails, a Microsoft poderá limitar o tráfego com erros 4xx, independentemente do resultado de SPF. O provedor ainda não conhece seu padrão de envio, e isso pode bastar para acionar a limitação.

Falhas em SPF, DKIM e DMARC: o triângulo de ferro

Muitos administradores configuram SPF, DKIM e DMARC, validam a sintaxe e encerram o assunto. Porém, sintaxe correta não garante funcionamento. Veja onde os problemas aparecem.

SPF: o buraco negro do encaminhamento

O SPF funciona como uma lista de IPs autorizados: ele afirma que "o IP 1.2.3.4 pode enviar por example.com". Tudo funciona bem até alguém ativar o encaminhamento automático.

Você envia uma fatura para client@smallbiz.com. Esse cliente encaminha todas as mensagens para client@gmail.com. O Gmail vê a conexão saindo do IP de smallbiz.com, não do seu. Ao consultar seu registro SPF, ele não encontra smallbiz.com e a validação falha. Se você depender apenas do SPF, a mensagem encaminhada poderá cair no spam ou ser rejeitada. O DKIM é indispensável para a autenticação sobreviver a esse salto. Para ver toda a configuração, consulte nosso guia de registros SPF.

DKIM: o problema do alinhamento

O DMARC verifica duas coisas: se SPF ou DKIM, conforme a RFC 6376, foi aprovado e se os domínios estão alinhados. Alinhamento significa que o domínio do cabeçalho From corresponde aos domínios dos cabeçalhos técnicos: Return-Path para SPF e d= para DKIM.

Este é o pesadelo de uma equipe de suporte: você usa um CRM como Zendesk ou HubSpot para enviar como support@yourcompany.com. O CRM processa as devoluções, então o Return-Path é bounces.zendesk.com e o alinhamento de SPF falha. Como você não configurou um CNAME personalizado, o DKIM assina com d=zendesk.com e o alinhamento de DKIM também falha. A mensagem está tecnicamente autenticada, pois veio do Zendesk e foi assinada por ele, mas o DMARC não encontra nenhum protocolo alinhado ao seu domínio. Se a política for p=reject, a mensagem será rejeitada.

O limite de 10 consultas

O SPF, conforme definido na RFC 7208, tem um teto rígido de 10 consultas DNS por registro. Se você trabalha em uma agência com clientes que adoram ferramentas SaaS, provavelmente já viu esse problema. Só o Google Workspace pode consumir 4 consultas. Acrescente Mailchimp, HubSpot, um sistema de tickets e uma ferramenta de RH:

Cada include: exige uma consulta DNS, e essas inclusões podem conter outras inclusões. Ao ultrapassar 10 consultas no total, o servidor destinatário retorna PermError, resultado tratado como ausência de registro SPF. Na prática, a tentativa de configurar tudo acaba deixando o próprio e-mail sem autenticação.

Barreiras ocultas além de SPF, DKIM e DMARC

Além dos três protocolos principais, há requisitos técnicos sem nomes chamativos de marketing que conseguem bloquear mensagens com a mesma rapidez.

FCrDNS (DNS reverso com confirmação direta)

Todo IP de envio precisa de um registro PTR, ou DNS reverso, que resolva para um nome de host. Esse nome deve ter um registro A apontando de volta para o IP original. A verificação de ida e volta ajuda a comprovar o controle sobre a infraestrutura. Se você criar uma máquina virtual na nuvem, instalar o Postfix e enviar mensagens sem um registro PTR, o Gmail poderá tratar o servidor como parte de uma botnet e retornar 550 5.7.1 imediatamente.

RFC 8058: cancelamento de inscrição com um clique

Desde junho de 2024, um link no rodapé não basta para as mensagens de marketing sujeitas aos requisitos atuais dos grandes provedores. É necessário incluir dois cabeçalhos específicos:

O endpoint HTTPS deve aceitar uma solicitação POST, não GET. Bots antispam verificam e-mails "clicando" nos links. Se o cancelamento usar um endpoint GET, eles podem remover usuários reais por acidente. Quando a pessoa não encontra uma saída fácil, também tende a escolher "Denunciar spam", aproximando você do limite de reclamações de 0.3%.

O limite de 0.3%: a economia da reputação

Autenticação perfeita com SPF, DKIM e DMARC, FCrDNS impecável e cabeçalhos corretos não ajudam se os destinatários detestam seu conteúdo.

A métrica que domina todas as demais é a taxa de reclamações de spam. Segundo as políticas descritas na data de publicação, o limite crítico é 0.3%, ou 3 reclamações a cada 1,000 e-mails. Se ele for ultrapassado, o Google poderá bloquear o domínio por completo.

A armadilha do denominador da caixa de entrada no Yahoo

O Yahoo pode calcular a taxa de spam com base nas mensagens que chegam à caixa de entrada, não no total enviado. Você envia 1,000 e-mails. A reputação do domínio já está abalada, então 900 vão para o spam e 100 chegam à caixa de entrada. Uma pessoa reclama. A conta fica assim: 1/100 = 1.0%, uma taxa 3x acima do limite de fiscalização. Uma única reclamação pode iniciar uma espiral da qual é muito difícil sair.

O problema do vizinho barulhento

Mesmo com SPF, DKIM e DMARC configurados corretamente, em uma hospedagem compartilhada comum ou em uma plataforma barata de e-mail "ilimitado", suas mensagens saem pelo mesmo IP usado por milhares de outros clientes. Se um deles enviar um golpe com criptomoedas, a Spamhaus poderá colocar o IP em uma lista de bloqueio. Seu e-mail será barrado embora você não tenha feito nada de errado. Você divide o prédio com a origem do problema, e as consequências atingem todos os moradores.

Checklist de sexta-feira para corrigir SPF, DKIM e DMARC

1. Verifique os cabeçalhos: Envie uma mensagem para um Gmail pessoal. Abra o e-mail, clique nos três pontos e escolha "Mostrar original". Procure Authentication-Results. O SPF foi aprovado? O DKIM foi aprovado? O domínio de dkim= corresponde ao domínio de header.from? Caso contrário, existe um problema de alinhamento.

2. Verifique o FCrDNS: Execute dig -x <your-sending-ip>. O comando retorna um nome de host? Execute dig <that-hostname>. Ele retorna o IP? Se o ciclo falhar, interrompa os envios e corrija o DNS.

3. Separe o tráfego: Nunca envie marketing pelo domínio corporativo principal. Use team@company.com para conversas entre pessoas e newsletter@marketing.company.com para campanhas. Se o marketing atingir o limite de 0.3%, a direção ainda poderá escrever aos investidores pelo domínio principal.

4. Saiba mais: Para entender como recuperar a reputação, consulte nosso guia de reputação do remetente e a análise detalhada sobre reputação do domínio de e-mail.

Planos TrekMail

Segundo as condições atuais, todos os planos pagos oferecem teste de 14 dias (cartão obrigatório). O Free não exige cartão.

Conclusão

A autenticação de e-mail com SPF, DKIM e DMARC não é uma tarefa para configurar e esquecer. Trata-se de uma exigência operacional contínua. Ser aprovado nas verificações é apenas o ingresso. Para realmente permanecer na caixa de entrada, você precisa de alinhamento rigoroso, higiene impecável da rede, incluindo FCrDNS e cabeçalhos de cancelamento com um clique, e uma estratégia de reputação que proteja sua operação dos outros remetentes. Não se contente com as configurações padrão. Mantenha o controle da sua infraestrutura.

Conseguir indicadores verdes para SPF, DKIM e DMARC é o preço de entrada, não a linha de chegada. Experimente a TrekMail grátis e assuma o controle real da autenticação dos seus e-mails.