SPF, DKIM e DMARC: o mínimo para o e-mail frio chegar

Se o seu time envia 3 mil e-mails frios por semana e metade simplesmente não gera resposta, existe uma chance real de que boa parte nunca tenha sido entregue. Não voltou como erro, não caiu em spam visível, só desapareceu. Desde fevereiro de 2024, com regras ampliadas em 2025, Gmail, Yahoo e Microsoft passaram a exigir autenticação consistente de quem envia volume. Sem SPF, DKIM e DMARC configurados, o destino mais comum da mensagem é o limbo: aceita no SMTP e descartada depois.

Este texto é técnico na medida certa. Vamos ver o que cada registro faz, como publicar no DNS, como conferir de verdade e onde os times erram ao achar que "o registro não existe" quando na verdade o DNS só não respondeu.

O que cada registro resolve

Os três registros operam em camadas diferentes. Entender a função de cada um evita o erro clássico de publicar tudo de uma vez, quebrar algo e culpar a ferramenta de disparo.

SPF (Sender Policy Framework) é uma lista de IPs autorizados a enviar em nome do seu domínio. Publicado como registro TXT, ele diz ao servidor receptor: "mensagens legítimas deste domínio saem por estes IPs". Se um e-mail sai de um IP fora da lista, o SPF falha.

DKIM (DomainKeys Identified Mail) é uma assinatura criptográfica. O servidor que envia assina o cabeçalho da mensagem com uma chave privada. O receptor busca a chave pública no seu DNS e valida a assinatura. Isso prova que o conteúdo não foi alterado no caminho.

DMARC (Domain-based Message Authentication, Reporting and Conformance) é a política. Ele diz ao receptor o que fazer quando SPF ou DKIM falham: nada, mandar para spam ou rejeitar. E devolve relatórios para você enxergar quem está enviando em nome do seu domínio. Um exemplo prático: p=none monitora sem punir, p=quarantine manda para spam, p=reject bloqueia.

Por que isso virou obrigatório em 2025

Gmail e Yahoo anunciaram em 2024 exigências mais rígidas para remetentes de volume, e a Microsoft seguiu o movimento no Outlook. A regra prática: enviar acima de 5 mil mensagens por dia para contas Gmail sem SPF, DKIM e DMARC alinhados derruba a reputação do domínio rápido.

O detalhe que trava muita operação comercial: a mensagem não é rejeitada com erro visível. Ela entra na fila, passa pelo SMTP e é descartada silenciosamente. Do ponto de vista do vendedor, o e-mail foi enviado. Do ponto de vista do destinatário, nunca existiu.

Se você prospecta em volume com e-mail frio, esse comportamento é o maior inimigo oculto da métrica de resposta. Um time que roda prospecção multicanal com WhatsApp, e-mail, ligação e LinkedIn costuma perceber o problema mais rápido, porque compara taxas entre canais. Quando só o e-mail tem desempenho péssimo, a autenticação é a primeira suspeita.

Como publicar os três no DNS

Você precisa de acesso ao painel do provedor de DNS do seu domínio (Registro.br, Cloudflare, GoDaddy, Route 53 e afins). Os registros ficam todos como TXT, exceto quando o provedor oferece campos específicos.

SPF: um único registro TXT no domínio raiz, começando com v=spf1. Exemplo enxuto: v=spf1 include:_spf.google.com include:seu-provedor-de-disparo.com ~all. O ~all indica softfail, ou seja, "aceite mas marque como suspeito". Nunca publique dois registros SPF no mesmo domínio, isso invalida os dois.

DKIM: o provedor de envio gera um par de chaves e te dá um registro, normalmente em um subdomínio tipo seletor._domainkey.seudominio.com. Cole exatamente como veio, sem editar espaços.

DMARC: um TXT em _dmarc.seudominio.com. Comece com v=DMARC1; p=none; rua=mailto:[email protected]. Rode em modo monitoramento por duas a três semanas, leia os relatórios e só então suba para quarantine e depois reject.

Um cenário comum: a empresa publica SPF e DKIM corretos, mas esquece que o CRM, o ERP e o sistema de nota fiscal também enviam e-mail pelo mesmo domínio. Ao subir para p=reject, esses envios começam a falhar. Por isso o período de monitoramento não é opcional.

Como conferir de verdade

Não confie no painel do provedor. Confira no DNS público, de fora da sua rede.

• Windows: nslookup -type=txt seudominio.com no prompt de comando.
• Linux e Mac: dig txt seudominio.com +short.
• Ferramentas online: MXToolbox, dmarcian e Google Admin Toolbox fazem a checagem completa em um clique.
• Teste real: envie um e-mail para uma conta Gmail e outra Outlook suas e abra os cabeçalhos. Procure spf=pass, dkim=pass e dmarc=pass.

O teste de cabeçalho é o mais honesto dos quatro. Ele mostra o resultado visto pelo destinatário real, não pela sua infraestrutura.

"Não encontrei o registro" versus "o DNS não respondeu"

Esse é o erro que faz time publicar de novo o que já existia. Um erro de digitação no dig ou uma consulta feita no subdomínio errado devolvem a mensagem NXDOMAIN ou "no answer", que parecem dizer que o registro não existe. Não dizem.

Traduzindo os retornos:

• NXDOMAIN: o domínio ou subdomínio não existe na zona consultada. Pode ser digitação errada.
• NOERROR com resposta vazia: o domínio existe, mas aquele tipo de registro não está publicado ali.
• SERVFAIL ou timeout: o servidor DNS não respondeu. Pode ser instabilidade momentânea ou bloqueio do seu resolver.
• Registro duplicado: você publicou um segundo SPF porque achou que o primeiro não existia. Agora os dois são inválidos.

Antes de publicar qualquer coisa, cheque por três caminhos diferentes: dig direto no autoritativo, uma ferramenta online e o painel do provedor. Se os três concordam que não existe, publique. Se dois concordam em que existe, o problema não é DNS.

O impacto real na prospecção fria

Time que roda outbound com e-mail frio costuma medir taxa de abertura e taxa de resposta. Quando a entrega está quebrada, a primeira cai para valores absurdamente baixos e a segunda some. Se você já comparou os dois e a abertura está abaixo de 15% em remessas grandes, autenticação já deveria estar na mesa.

Não é só sobre autenticação. Reputação de domínio, higiene de lista e volume por hora também pesam. Uma máquina de outbound bem montada cuida dos quatro ao mesmo tempo, como descrevemos em outbound para SaaS com máquina de prospecção previsível. Autenticação é o piso, não o teto.

Cadências que misturam e-mail com outros canais tendem a sofrer menos. Se o e-mail derrapar e a ligação compensar, o pipeline sente menos. O tema aparece em cadências de prospecção que convertem 3x mais, onde o desenho de toque reduz a dependência de um canal só.

Há ainda um detalhe pouco discutido: autenticação correta também protege sua marca. Sem DMARC em reject, qualquer pessoa pode enviar phishing com o seu domínio no remetente. O estrago de reputação é maior do que a perda de respostas.

Checklist para publicar em uma tarde

1. Acesso ao painel de DNS do domínio raiz confirmado.
2. Registro SPF publicado, único, com os provedores usados listados.
3. DKIM gerado pelo provedor de envio e colado sem edição.
4. DMARC em p=none com endereço de relatório ativo.
5. Teste de dig ou MXToolbox retornando os três.
6. Envio de teste para Gmail e Outlook com cabeçalho validado.
7. Calendário marcado para revisar DMARC em 21 dias e subir a política.

O passo sete é o mais negligenciado. Sem revisão periódica, o DMARC fica em none para sempre e o time deixa de aproveitar a defesa que ele oferece.

Conclusão

SPF, DKIM e DMARC não são assunto de TI depois do expediente. São a camada que decide se o seu e-mail frio existe ou desaparece. Configurar leva uma tarde, conferir leva dez minutos, e a diferença na taxa de resposta aparece em duas semanas.

Publique os três, monitore o DMARC por três semanas e suba para quarantine antes de fechar em reject. Se o volume é grande e nada estava configurado, comece esta semana. Cada dia sem isso é dinheiro gasto em e-mail que nunca chegou.