SPF, DKIM e DMARC para e-mail frio: checklist de configuração

Por que cold emails falham quando a autenticação DNS está errada\n\nA autenticação de e‑mail é como uma caixa de entrada verifica se sua mensagem realmente tem permissão para vir do seu domínio. Não se trata de escrever uma copy melhor. Trata‑se de provar identidade.\n\nQuando você envia um cold email, o servidor receptor olha para o domínio no endereço From e executa três verificações principais:\n\n- SPF: um servidor autorizado enviou isto?\n- DKIM: a mensagem está assinada pelo domínio?\n- DMARC: o que o receptor deve fazer se essas verificações falharem, e os domínios estão alinhados?\n\nDomínios novos de envio são julgados com mais rigor porque não têm histórico. Um domínio recém‑criado com sinais DNS fracos ou quebrados parece arriscado, mesmo que sua intenção seja legítima. Por isso erros de autenticação prejudicam outreach frio mais rápido do que prejudicam marcas estabelecidas.\n\nRegistros DNS incorretos geralmente causam problemas de três maneiras silenciosas: seu e‑mail é aceito mas cai no spam, é rejeitado à vista (bounces ou bloqueios), ou às vezes chega mas seu domínio começa a construir uma reputação ruim.\n\nPequenos erros são frequentemente a causa. Dois registros TXT de SPF separados podem disparar uma falha. Uma chave DKIM colada com um caractere a menos não vai verificar. DMARC definido com uma política agressiva antes de tudo estar alinhado pode bloquear envios normais.\n\nEsta checklist foca em SPF, DKIM e DMARC em termos práticos: o que publicar, o que evitar e como verificar resultados antes de escalar envios. Não cobre copywriting, qualidade de listas, ajuste de oferta ou conformidade local.\n\n## O modelo simples: o que é verificado quando você envia\n\nQuando você envia um cold email, normalmente há dois domínios envolvidos, e confundi‑los causa muita confusão.\n\nO domínio de envio é o que o destinatário vê no endereço From (você@seudominio.com). O domínio da mailbox (às vezes diferente) é o domínio que realmente envia a mensagem nos bastidores, como um subdomínio de envio dedicado ou um domínio pertencente ao provedor. Para boa entregabilidade, esses domínios devem ser consistentes ou pelo menos claramente conectados.\n\n### Do domínio From até a caixa de entrada: as três checagens\n\nA maioria das caixas de entrada segue o mesmo fluxo básico:\n\n1. SPF verifica o Return‑Path oculto (também chamado envelope sender) e pergunta se este servidor tem permissão para enviar por esse domínio.\n2. DKIM verifica a assinatura DKIM e pergunta se o domínio que assinou corresponde ao que foi enviado.\n3. DMARC olha para o domínio visível no From e pergunta se SPF e/ou DKIM estão alinhados com ele, então aplica sua política.\n\n### Alinhamento, sem jargões\n\nAlinhamento é simplesmente “os domínios batem?”. Há três lugares a observar:\n\n- From: o que os humanos veem (exemplo: @seudominio.com)\n- Return‑Path: o que o SPF usa (pode ser @mail.seudominio.com ou outro)\n- DKIM d=: o domínio que assinou a mensagem (exemplo: d=seudominio.com)\n\nO DMARC passa quando o domínio From se alinha com SPF (domínio do Return‑Path) e/ou com DKIM (o domínio d=). Nem tudo precisa ser idêntico, mas deve ser intencional.\n\n### O que acontece quando as checagens falham\n\nOs provedores não reagem todos da mesma forma, mas os desfechos são previsíveis:\n\n- p=none (monitoramento): o e‑mail geralmente ainda chega e você coleta relatórios.\n- p=quarantine: o e‑mail tem mais chance de cair em spam.\n- p=reject: o e‑mail é bloqueado.\n\nMesmo antes do DMARC ficar rígido, falhas repetidas reduzem a entregabilidade ao longo do tempo.\n\nExemplo: você envia de [email protected], mas o SPF só autoriza outro domínio e o DKIM assina como d=outrodominio.com. A mensagem pode parecer “sem dono”, então filtros ficam cautelosos.\n\n## Antes de tocar no DNS: prepare‑se para uma configuração limpa\n\nA maioria dos problemas de entregabilidade começa antes de alguém adicionar um registro DNS. Prepare‑se bem e sua configuração será mais rápida, limpa e mais fácil de depurar.\n\nComece decidindo qual domínio aparecerá no endereço From. Muitas equipes usam um domínio de envio dedicado (ou um subdomínio) para que o domínio principal da empresa não fique em risco caso algo dê errado.\n\nEm seguida, escolha como você vai enviar e colete os valores exatos de registro que precisa. Seu provedor de e‑mail vai fornecer um valor SPF específico, nomes de selectors e chaves DKIM, e uma sugestão de registro DMARC. Não adivinhe nem reutilize registros de outro domínio.\n\nAntes de fazer alterações, confirme quatro pontos básicos: qual domínio From exato você usará, quais provedores enviarão e‑mail, onde o DNS é realmente gerenciado e quem tem permissão para publicar registros TXT e CNAME.\n\nTambém certifique‑se de estar no painel correto. Pessoas costumam comprar um domínio em um lugar, hospedar o DNS em outro e editar registros no local errado. Se estiver em dúvida, verifique quais nameservers o domínio usa e faça login no provedor que os controla.\n\nUm plano de mudanças simples ajuda a evitar edições “úteis” que quebram e‑mail existente. Tipicamente você atualizará o SPF (com cuidado, especialmente se já existir), adicionará DKIM e publicará DMARC em modo de monitoramento. Deixe registros MX, A e do site intactos a menos que saiba por que os está alterando.\n\n## SPF: adicione os remetentes corretos e evite limites de lookup\n\nSPF é um registro TXT DNS que diz aos provedores quais servidores estão autorizados a enviar e‑mail pelo seu domínio. Em cold outreach, SPF é uma das primeiras checagens que decide se sua mensagem parece normal ou suspeita.\n\nUm bom registro SPF é uma pequena lista de permissões cobrindo todos os lugares que podem enviar como seu domínio: seu serviço de cold email, Google Workspace ou Microsoft 365 (se você os usa) e qualquer ferramenta de suporte ou CRM que envie e‑mail em seu nome.\n\n### O que colocar no seu registro SPF\n\nA maioria dos domínios novos precisa de poucos itens:\n\n- include: quando um provedor diz para incluir o SPF deles. Mantenha includes no mínimo porque elas custam consultas DNS.\n- ip4:/ip6:: quando você tem um IP de envio fixo. Isso evita consultas, mas só funciona se os IPs forem realmente estáveis.\n- a e mx: somente se o servidor próprio do seu domínio ou o seu mail exchanger enviar e‑mail diretamente (muitos setups de cold email não precisam disso).\n\nAqui está um exemplo de forma limpa (seus valores vão diferir):\n\ntxt\nv=spf1 include:YOUR-SENDER-SPF ip4:203.0.113.10 ~all\n\n\n### Escolha o final certo: -all vs all\n\nA última parte é sua regra padrão para qualquer coisa não listada.\n\nall (soft fail) é uma opção mais segura enquanto você testa e pode ter esquecido um remetente. -all (hard fail) é melhor quando você está confiante, porque diz claramente aos provedores para rejeitar remetentes não autorizados.\n\nPara domínios de outbound novos, comece com ~all durante a configuração e envios iniciais, depois mude para -all depois de verificar que nada legítimo está falhando.\n\n### Fique abaixo do limite de 10 lookups\n\nSPF tem um limite rígido de 10 consultas DNS. Muitas includes podem quebrar o SPF e prejudicar silenciosamente a entregabilidade.\n\nPara ficar abaixo do limite, mantenha as includes baixas, evite cadeias de includes aninhadas, remova ferramentas antigas que você não envia mais e garanta que publique apenas um registro SPF TXT por domínio. Múltiplos registros SPF podem causar um permerror.\n\n## DKIM: publique chaves corretamente e mantenha selectors organizados\n\nDKIM adiciona uma assinatura digital a cada e‑mail que você envia. Servidores receptores usam a chave pública no seu DNS para verificar que a mensagem não foi alterada e que seu domínio tem permissão para assinar o e‑mail. DKIM costuma ser o que faz um domínio novo parecer consistente ao longo do tempo.\n\n### Como os selectors funcionam (e por que os nomes importam)\n\nUm selector DKIM é um rótulo que aponta para uma chave pública específica. Seu sistema de envio assina e‑mails com esse selector, e o receptor procura um registro DNS em:\n\nselector._domainkey.seudominio.com\n\nSelectors permitem rotacionar chaves sem quebrar o envio, mas também podem criar confusão. Se você reutilizar o mesmo selector para sempre, rotações ficam arriscadas. Se criar um selector novo o tempo todo, seu DNS vira bagunça.\n\nUma abordagem simples é usar um selector estável e descritivo como s1, mail ou 2026q1, e rotacionar de forma intencional quando necessário.\n\n### TXT vs CNAME: o que você verá no DNS\n\nAlguns provedores publicam DKIM como um registro TXT contendo a chave completa. Outros dão um CNAME que aponta para um registro de chave hospedada. Ambos funcionam se (e somente se) você publicar exatamente o que seu provedor espera.\n\nOs problemas mais comuns de DKIM são diretos: tipo de registro errado (TXT vs CNAME), aspas extras ou quebras de linha ocultas, colar só parte da chave, colocar o registro no domínio raiz em vez de selector._domainkey, ou deixar selectors antigos ativos com registros conflitantes.\n\nSe a verificação DKIM falhar, não adivinhe. Recopie o valor do provedor, republice corretamente e teste novamente após as atualizações de DNS.\n\n## DMARC: comece com monitoramento e depois endureça a política\n\nDMARC é a camada “o que os receptores devem fazer sobre falhas?”. SPF e DKIM dizem ao Gmail ou Outlook o que checar. DMARC adiciona uma política clara (none, quarantine, reject) e exige alinhamento com o domínio visível no From.\n\nUma forma prática de começar é com monitoramento. Publique DMARC com p=none para que você veja o que passa e o que falha sem arriscar quedas de entregabilidade por uma política muito rígida. Deixe rodar por alguns dias enquanto envia volumes pequenos, depois endureça aos poucos.\n\nAqui está um padrão de registro inicial seguro (ajuste e‑mails e domínio):\n\n\n_dmarc.example.com TXT \"v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100; fo=1\"\n\n\nMantenha as opções simples. Alinhamento estrito (adkim=s e aspf=s) é um bom padrão para domínios dedicados de outbound onde você controla o emissor. pct=100 mantém o comportamento consistente. fo=1 é uma configuração razoável para receber relatório quando algo falha.\n\nCuidado com endereços de relatório. Relatórios agregados (rua) podem ser úteis, mas só se alguém os verificar. Relatórios forenses (ruf) frequentemente são bloqueados e podem gerar questões de privacidade e ruído, então geralmente é melhor pular ruf completamente.\n\n## Passo a passo: autenticar um domínio novo de envio\n\nTrate um domínio novo como uma sala limpa. Seus registros DNS devem bater com seu remetente real, então decida desde o início de onde vai enviar.\n\n### 1) Limpe a zona DNS primeiro\n\nNo host DNS, procure por registros TXT existentes que mencionem SPF, DKIM ou DMARC. Domínios novos às vezes têm registros iniciais, testes antigos ou duplicados de uma tentativa anterior. Remova o que você não reconhece e garanta que tenha apenas um registro SPF TXT para o domínio raiz.\n\n### 2) Adicione autenticação em ordem segura\n\nAdicione um tipo de registro por vez e confirme que está visível antes de seguir:\n\n1. SPF: publique um único registro SPF TXT que inclua apenas os serviços que vão enviar e‑mail por esse domínio.\n2. DKIM: adicione os registros DKIM que seu remetente fornece (frequentemente CNAMEs, às vezes um TXT). Certifique‑se de que o selector corresponda às configurações de assinatura do seu remetente.\n3. DMARC: publique um registro DMARC TXT em _dmarc.seudominio com p=none para começar.\n\n### 3) Aguarde e verifique os valores exatos\n\nMudanças de DNS nem sempre são instantâneas. Depois de publicar registros, verifique o que está realmente visível. Confirme que existe apenas um registro SPF, que o DKIM corresponde exatamente e que o DMARC está no subdomínio _dmarc.\n\n### 4) Envie e‑mails reais e verifique “pass” nos headers\n\nEnvie alguns e‑mails simples (sem anexos, HTML leve) para contas que você controla, como Gmail e Outlook. Abra os detalhes da mensagem e procure por Authentication‑Results. Você quer spf=pass, dkim=pass e dmarc=pass.\n\nSe o SPF falhar, geralmente é um include errado ou múltiplos registros SPF. Se o DKIM falhar, geralmente é mismatch de selector ou um erro de digitação no valor DNS.\n\nQuando você obtiver passes consistentes, passe para o warm‑up e aumente o volume com cuidado.\n\n## Erros comuns de DNS que silenciosamente prejudicam a entrega\n\nA maioria dos problemas com um domínio novo não é uma falha dramática. São detalhes pequenos de DNS que ainda permitem enviar, mas fazem os receptores confiaren menos em você.\n\nDuas questões aparecem constantemente:\n\nPrimeiro, publicar dois registros SPF no mesmo domínio. Um domínio deve ter apenas um registro SPF TXT. Se precisar do Google mais uma ferramenta de envio, junte tudo em um único registro v=spf1 e mantenha um só final (~all ou -all).\n\nSegundo, atingir permerror de SPF por causa de muitos lookups. Includes geram lookups, e includes aninhadas geram ainda mais. Corte ferramentas não usadas, mantenha o registro curto e evite empilhar provedores “só por via das dúvidas”.\n\nNo lado do DKIM, a falha mais comum é mismatch de selector. Seu provedor assina com um selector específico (tipo s1 ou default). Se seu DNS publica um selector diferente, os receptores não conseguem verificar DKIM mesmo que exista um registro.\n\nFalhas de DMARC costumam confundir porque o SPF pode passar e o DMARC ainda falhar. DMARC exige alinhamento com o From visível. Se você enviar de [email protected] mas o Return‑Path for marca-mail.com e o DKIM assinar como d=marca-mail.com, pode acabar com SPF pass e DMARC fail.\n\n## Checklist rápido: verificação final de 10 minutos\n\nAntes de enviar volume real, faça uma verificação rápida para garantir que os registros estão limpos e suas mensagens realmente autenticam.\n\nConfirme que há exatamente um registro SPF TXT no domínio raiz. Confirme que o DKIM está publicado para o domínio que você envia e que o selector corresponde ao que sua ferramenta usa. Confirme que há exatamente um registro DMARC em _dmarc.example.com e comece com p=none.\n\nSe você acabou de mudar registros, espere um pouco. Muitos momentos de “ainda falha” são caching de DNS.\n\nEntão envie um e‑mail de teste real para uma caixa que você possa inspecionar e verifique Authentication‑Results. Você quer ver SPF=pass, DKIM=pass e DMARC=pass.\n\nCorreções rápidas quando algo falha:\n\n- SPF falha: include errado, domínio errado (raiz vs subdomínio) ou dois registros SPF.\n- DKIM falha: mismatch de selector, espaços/aspas extras ou assinatura desligada.\n- DMARC falha: registro DMARC ausente, publicado na raiz em vez de _dmarc, ou SPF/DKIM não alinhados com o domínio From.\n\n## Exemplo e próximos passos para um novo domínio de cold email\n\nUma configuração simples é esta: você compra um domínio novo só para outbound e cria algumas caixas (alex@, sam@, info@). Mantém seu domínio principal separado para que um erro não afete o e‑mail cotidiano.\n\nUm cronograma realista:\n\n- Dia 0: publique SPF, DKIM e DMARC em modo de monitoramento (p=none).\n- Dia 1: envie e‑mails de teste e verifique SPF/DKIM/DMARC. Corrija erros de digitação e hostnames errados.\n- Dias 2‑3: comece com volume muito baixo enquanto o warm‑up inicia.\n- Final da semana 1: revise relatórios DMARC e bounces, e corrija qualquer desalinhamento.\n- Semana 2+: se tudo estiver estável, mova para p=quarantine e depois p=reject.\n\nSe você vê SPF passando mas DMARC falhando, geralmente significa que o alinhamento está quebrado, não que o DNS esteja completamente errado. A correção mais rápida costuma ser garantir que o DKIM esteja habilitado e assinando com o seu domínio de envio, já que o alinhamento DKIM tende a ser mais estável que o SPF quando ferramentas mudam.\n\nDepois que a autenticação estiver correta, os resultados vêm do comportamento, não apenas dos registros. Aqueça devagar, mantenha volume inicial baixo, documente mudanças de DNS, evite trocar de provedor no primeiro mês e monitore bounces e descadastros de perto.\n\nSe quiser reduzir o número de ferramentas envolvidas, LeadTrain (leadtrain.app) combina configuração de domínio, configuração de SPF/DKIM/DMARC, warm‑up, sequências multi‑etapas e classificação de respostas em uma plataforma, o que pode facilitar manter o alinhamento consistente ao adicionar domínios e caixas de correio.