Como conferir se SPF, DKIM e DMARC do seu domínio estão corretos

Publicar um registro DNS não é garantia de que ele está funcionando — sintaxe errada, registros duplicados e propagação incompleta são invisíveis até alguém checar de fora. Antes de aprovar uma campanha de outreach B2B, vale menos de dez minutos rodar uma verificação completa de SPF, DKIM e DMARC do domínio de envio, usando ferramentas gratuitas que qualquer pessoa da equipe de vendas consegue interpretar sem depender de TI.

Por que checar antes de disparar, não depois

Um erro de SPF ou DKIM não derruba a campanha inteira de forma óbvia — ele reduz silenciosamente a taxa de entrega, fazendo parecer que o problema é o copy do email ou a lista de contatos, quando na verdade é técnico. Times de vendas B2B costumam gastar dias reescrevendo o assunto e o corpo do email antes de suspeitar da autenticação do domínio.

Para outreach direcionado — poucas dezenas de emails por dia, para decisores específicos — cada mensagem perdida em spam representa uma oportunidade concreta perdida, não só um número numa planilha. Checar a configuração antes de começar a campanha é o passo de menor esforço com maior retorno em todo o processo de prospecção.

A boa notícia é que checar não exige conhecimento técnico profundo. As ferramentas gratuitas fazem a consulta técnica e traduzem o resultado em pass, fail ou avisos claros.

Verificando SPF: o que olhar no resultado

Um verificador de SPF consulta o DNS do domínio e mostra o registro TXT publicado, além de indicar se ele é válido segundo a sintaxe do padrão. O ponto mais importante a checar é se existe apenas um registro SPF — se a ferramenta apontar dois ou mais registros TXT começando com v=spf1, isso invalida o SPF inteiro, mesmo que cada um pareça correto isoladamente.

O segundo ponto é conferir se todos os serviços que efetivamente enviam email pelo domínio estão incluídos: a caixa principal (Google Workspace ou Microsoft 365), qualquer ferramenta de outreach ou automação de sequência, e sistemas auxiliares como notas fiscais eletrônicas ou plataformas de agendamento que também disparam email em nome do domínio.

O terceiro ponto, menos óbvio, é o número de consultas DNS (lookups) que o SPF gera. O padrão limita a 10 lookups por verificação — domínios com muitos includes aninhados (um serviço que inclui outro, que inclui outro) podem ultrapassar esse limite e o SPF passa a falhar silenciosamente, mesmo com sintaxe aparentemente correta.

Verificando DKIM: o seletor importa

Diferente do SPF, que fica num único lugar previsível no DNS, o DKIM é publicado sob um nome de host específico chamado seletor — algo como google._domainkey.seudominio.com.br ou selector1._domainkey.seudominio.com.br. Sem saber o seletor certo, o verificador não encontra o registro, mesmo que ele exista.

O seletor é definido pelo provedor de envio (Google, Microsoft, ou a ferramenta de outreach) no momento em que o DKIM é ativado. Ele geralmente aparece na tela de configuração de autenticação de email do próprio provedor — vale anotar esse valor exato ao configurar, porque será necessário para qualquer verificação futura.

A forma mais confiável de checar o DKIM sem saber o seletor de antemão é olhar os cabeçalhos técnicos de um email realmente enviado pelo domínio: o cabeçalho DKIM-Signature traz o seletor usado naquele envio específico, no campo identificado como s=.

Verificando DMARC: leitura da política publicada

A verificação de DMARC é mais direta: o verificador consulta o TXT em _dmarc.seudominio.com.br e mostra a política ativa (none, quarantine ou reject), o percentual de tráfego coberto e o endereço de email configurado para receber relatórios agregados.

É comum encontrar domínios sem nenhum registro DMARC publicado, mesmo depois de SPF e DKIM configurados — é o registro mais esquecido dos três porque não é estritamente necessário para o email sair, só para ele ser tratado com mais confiança pelo provedor de destino.

Vale também checar, depois de algumas semanas com DMARC ativo, os relatórios agregados que chegam no endereço de rua configurado. Eles mostram, por origem de IP, quantos emails passaram e quantos falharam na autenticação — um jeito indireto de auditar se todos os serviços de envio da empresa estão realmente cobertos pelo SPF e pelo DKIM.

O teste definitivo: enviar um email real

Nenhuma ferramenta externa de verificação substitui o teste com um envio real. Mande um email de teste do domínio de outreach para uma conta pessoal em Gmail e outra em Outlook, e abra os cabeçalhos completos da mensagem recebida (a opção geralmente se chama mostrar original ou exibir origem da mensagem).

Nesses cabeçalhos aparece uma linha de Authentication-Results, que traz explicitamente spf=pass ou spf=fail, dkim=pass ou dkim=fail, e dmarc=pass ou dmarc=fail para aquele envio específico. Esse é o resultado que mais importa, porque reflete exatamente o que o servidor de destino avaliou, sem depender de interpretação de ferramenta terceira.

Um erro comum é confiar só no verificador externo e nunca fazer esse teste de envio real — é possível ter todos os registros tecnicamente corretos e ainda assim ter algum problema específico de configuração do servidor de envio que só aparece num teste de ponta a ponta.

• Rodar verificador de SPF e conferir se existe apenas um registro TXT
• Rodar verificador de DKIM usando o seletor correto do provedor de envio
• Rodar verificador de DMARC e conferir a política e o endereço de relatórios
• Enviar email de teste para Gmail e Outlook e checar Authentication-Results
• Revisar relatórios agregados de DMARC depois de duas a três semanas ativos
• Repetir a checagem sempre que trocar de ferramenta de outreach ou provedor de email

Quando envolver o time técnico e quando resolver sozinho

A maioria das correções de SPF, DKIM e DMARC não exige um desenvolvedor — é edição de registro TXT ou CNAME no painel de DNS, algo que qualquer pessoa com acesso administrativo ao domínio consegue fazer seguindo o valor exato fornecido pelo provedor de envio. O ponto onde vale chamar o time técnico é quando o domínio tem múltiplos serviços de infraestrutura crítica dependendo do mesmo DNS, como sistemas de faturamento ou integrações internas, e existe risco de uma mudança mal feita afetar outro serviço.

Vendedores e times de growth que rodam outreach B2B geralmente têm autonomia para pedir só a criação de um registro específico, sem precisar entender toda a árvore de DNS da empresa — nesse caso, o ideal é levar ao time técnico o valor exato a publicar, já validado numa ferramenta de verificação, em vez de pedir para investigar do zero.

Vale registrar também que mudanças de DNS ficam ativas por tempo indeterminado até serem removidas manualmente — não é como um envio de campanha que termina sozinho. Isso significa que, uma vez corrigido, o registro continua protegendo todos os envios futuros pelo domínio, o que torna esse investimento inicial de tempo particularmente eficiente comparado a outras otimizações de deliverability que precisam ser repetidas a cada campanha.

Perguntas frequentes