SPF, DKIM e DMARC: checklist para autenticar e-mails de campanha
Identifique remetentes, valide autenticação e alinhamento de e-mail e prepare mudanças de DMARC sem bloquear mensagens legítimas da empresa.
Autenticação de e-mail depende do domínio e dos serviços que enviam em nome da empresa. SPF, DKIM e DMARC têm funções diferentes e precisam ser configurados conforme os provedores reais. Copiar um registro DNS genérico pode deixar um remetente de fora ou interromper mensagens legítimas.
Faça um inventário dos serviços que enviam
Liste plataforma de campanha, sistema de pedidos, atendimento e outros remetentes autorizados. Para cada um, anote domínio visível no remetente, domínio técnico usado no envio e orientação oficial de autenticação. Inclua serviços menos frequentes, como faturamento e notificações.
Inventário ilustrativo: campanhas usam um provedor; confirmações de pedido usam outro; a equipe envia por uma suíte corporativa. Os três precisam ser considerados antes de alterar a política do domínio.
Use os valores fornecidos pelo serviço responsável. Este guia não traz registros DNS prontos, porque hosts, seletores e mecanismos dependem da conta e da arquitetura. Registre quem tem autorização para alterar DNS e como reverter uma mudança.
Confira a função de cada mecanismo
SPF indica quais fontes podem enviar para o domínio usado nessa verificação. DKIM associa uma assinatura ao domínio configurado pelo remetente. DMARC verifica alinhamento com o domínio visível no campo From e comunica uma política para mensagens que falham na avaliação.
Alinhamento não significa apenas existir um registro no DNS. É necessário conferir a mensagem enviada pelo caminho real. Em DMARC, autenticação e alinhamento válidos por SPF ou DKIM podem permitir aprovação; revise o resultado nos cabeçalhos de uma mensagem de teste.
- DNS publicado conforme o provedor.
- Mensagem de teste enviada pelo serviço real.
- SPF e DKIM verificados no recebimento.
- Alinhamento com From conferido.
- Alterações documentadas por serviço.
Planeje DMARC sem começar por uma rejeição cega
Antes de endurecer a política, observe os remetentes legítimos e corrija falhas. Uma política restritiva aplicada com inventário incompleto pode afetar confirmações e atendimento. Defina responsáveis pela leitura dos relatórios e um plano para casos inesperados.
Caso ilustrativo: campanhas passam na autenticação, mas um sistema antigo de pedidos não está alinhado. A equipe corrige esse caminho antes de adotar uma política que poderia rejeitar suas mensagens.
A escolha da política precisa considerar a situação do domínio e apoio técnico quando necessário. Uma mudança de DNS pode levar tempo para ser observada conforme cache e TTL. Teste novamente os caminhos importantes depois da publicação.
Revise também autorização e cancelamento
As diretrizes do Gmail incluem requisitos de autenticação e outras condições de envio. As exigências variam conforme o tipo e o volume do remetente. Confira a documentação oficial aplicável, inclusive cancelamento de assinatura, em vez de tratar autenticação como garantia de caixa de entrada.
Uma mensagem autenticada ainda pode ser indesejada ou falhar por conteúdo, reputação ou audiência. No Zapi Send, valide o provedor de e-mail configurado e a origem dos contatos. Mantenha descadastro e supressão operacionais e examine devoluções sem reenviar indefinidamente.
Perguntas frequentes
Passar em SPF garante entrega na caixa de entrada?
Não. Autenticação é uma parte da avaliação; audiência, reputação, conteúdo e regras do destinatário também influenciam o resultado.
Posso publicar DMARC com rejeição imediatamente?
Antes, inventarie e teste os remetentes legítimos. Uma política restritiva sem essa revisão pode interromper mensagens necessárias.
Fontes e referências
Exemplos são ilustrativos. As regras e capacidades dos canais podem mudar; confira as fontes e teste a operação antes de publicar.