A configuração de DNS é a fundação invisível da entregabilidade de cold email. Enquanto a maioria dos profissionais de cold email foca em linhas de assunto, copy e cronogramas de envio, é a infraestrutura técnica por baixo que determina se seus e-mails sequer chegam à caixa de entrada. Registros DNS mal configurados são responsáveis por mais falhas de entregabilidade do que qualquer outro fator isolado, e ainda assim permanecem mal compreendidos pela maioria dos remetentes de cold email.
Este guia técnico oferece um mergulho abrangente e aprofundado na configuração de DNS para cold email. Vamos examinar cada tipo de registro em detalhes, explorar os protocolos de autenticação que protegem sua reputação de envio, solucionar problemas comuns de propagação e demonstrar métodos de verificação que garantem que sua infraestrutura esteja pronta para produção. Seja você alguém configurando seu primeiro domínio de cold email ou gerenciando centenas de domínios em escala, este guia lhe dará o conhecimento técnico para alcançar uma colocação consistente na caixa de entrada.
O Domain Name System (DNS) funciona como a agenda de endereços da internet, traduzindo nomes de domínio legíveis por humanos em endereços IP legíveis por máquinas. Para o e-mail, o DNS cumpre um propósito adicional e crítico: ele informa aos servidores de correio de recebimento quais servidores estão autorizados a enviar e-mail em nome do seu domínio e como autenticar essas mensagens. Compreender os quatro tipos principais de registro essenciais para o cold email é o primeiro passo em direção a uma configuração adequada.
Os registros MX especificam quais servidores de correio são responsáveis por receber e-mail para o seu domínio. Embora usados principalmente para correio de entrada, os registros MX são essenciais para a credibilidade do cold email. Os filtros de spam verificam rotineiramente se um domínio remetente possui registros MX válidos, já que domínios sem eles não conseguem receber respostas e frequentemente são associados a operações de spam.
Um registro MX consiste em dois componentes: um valor de prioridade e um hostname de servidor de correio. Números de prioridade mais baixos indicam maior preferência, permitindo que você configure servidores de correio primários e de backup.
# Exemplo de Registro MX example.com. IN MX 10 mail.example.com. example.com. IN MX 20 mail-backup.example.com. # Registros MX do Google Workspace example.com. IN MX 1 ASPMX.L.GOOGLE.COM. example.com. IN MX 5 ALT1.ASPMX.L.GOOGLE.COM. example.com. IN MX 5 ALT2.ASPMX.L.GOOGLE.COM. example.com. IN MX 10 ALT3.ASPMX.L.GOOGLE.COM. example.com. IN MX 10 ALT4.ASPMX.L.GOOGLE.COM.
Os registros SPF definem quais endereços IP e servidores de correio estão autorizados a enviar e-mail em nome do seu domínio. Quando um servidor de recebimento recebe um e-mail alegando ser do seu domínio, ele verifica seu registro SPF para confirmar que o servidor remetente é legítimo. Isso impede que spammers falsifiquem seu domínio no endereço "From".
Os registros SPF são publicados como registros TXT no seu DNS. Eles usam uma sintaxe específica que inclui mecanismos (como "ip4", "include" e "a") e qualificadores que determinam como lidar com remetentes que correspondem ou não.
# Estrutura Básica de Registro SPF v=spf1 [mechanisms] [qualifier]all # Registro SPF para Google Workspace v=spf1 include:_spf.google.com ~all # Registro SPF com Múltiplas Fontes de Envio v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.168.1.1 ~all # Qualificadores SPF: # +all = Pass (permitir tudo - não recomendado) # -all = Hard Fail (rejeitar remetentes não autorizados) # ~all = Soft Fail (aceitar mas marcar como suspeito) # ?all = Neutral (sem política)
O DKIM adiciona uma assinatura criptográfica aos seus e-mails de saída, provando que a mensagem foi realmente enviada do seu domínio e não foi modificada em trânsito. O servidor remetente assina o e-mail com uma chave privada, e os servidores de recebimento verificam a assinatura usando uma chave pública publicada no seu DNS.
Os registros DKIM são publicados como registros TXT em um subdomínio específico que inclui um seletor (um identificador arbitrário para o par de chaves). Esse sistema de seletor permite que você rotacione chaves sem interromper a entrega de e-mails e use chaves diferentes para diferentes serviços de envio.
# Localização do Registro DKIM [selector]._domainkey.example.com # Exemplo de Registro DKIM do Google Workspace google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..." # Componentes do Registro DKIM: # v=DKIM1 - Versão do DKIM # k=rsa - Tipo de chave (RSA é o padrão) # p=... - Chave pública (codificada em base64) # t=s - Opcional: modo estrito (assinatura de subdomínio) # t=y - Opcional: modo de teste
O DMARC se apoia no SPF e no DKIM adicionando uma camada de política que diz aos servidores de recebimento o que fazer quando os e-mails falham na autenticação. Ele também fornece um mecanismo de relatórios que envia a você dados sobre e-mails que alegam ser do seu domínio, sejam legítimos ou fraudulentos.
O DMARC é essencial porque introduz o conceito de "alinhamento", exigindo que o domínio no cabeçalho "From" visível corresponda ao domínio autenticado por SPF ou DKIM. Isso fecha uma brecha que permitia que spammers passassem no SPF/DKIM enquanto ainda falsificavam o endereço do remetente exibido.
# Localização do Registro DMARC _dmarc.example.com # Registro DMARC Básico (Modo de Monitoramento) v=DMARC1; p=none; rua=mailto:dmarc@example.com # Registro DMARC Recomendado para Cold Email v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc@example.com # Registro DMARC Estrito (Proteção Total) v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com # Opções de Política DMARC: # p=none - Apenas monitorar (nenhuma ação em falhas) # p=quarantine - Enviar para a pasta de spam # p=reject - Rejeitar o e-mail completamente # Tags Adicionais: # sp= - Política de subdomínio # pct= - Percentual de mensagens às quais aplicar a política # adkim= - Modo de alinhamento DKIM (s=estrito, r=relaxado) # aspf= - Modo de alinhamento SPF (s=estrito, r=relaxado) # rua= - Destino do relatório agregado # ruf= - Destino do relatório forense
Compreender como o SPF, o DKIM e o DMARC trabalham juntos é crucial para diagnosticar problemas de entregabilidade. Quando você envia um cold email, o servidor de recebimento realiza uma série de verificações em uma ordem específica, e os resultados de cada verificação alimentam a decisão geral de autenticação.
O servidor de recebimento extrai o domínio do endereço MAIL FROM (remetente do envelope) e consulta o registro SPF desse domínio. Em seguida, ele verifica se o endereço IP de conexão está autorizado pelo registro SPF. O resultado é um dentre: pass, fail, softfail, neutral, none, temperror ou permerror.
O servidor de recebimento examina o cabeçalho DKIM-Signature no e-mail, extrai o seletor e o domínio de assinatura, recupera a chave pública correspondente do DNS e verifica a assinatura criptográfica. Se a assinatura corresponder ao conteúdo e aos cabeçalhos do e-mail, o DKIM passa.
O DMARC avalia os resultados do SPF e do DKIM, mas adiciona um requisito de alinhamento. O domínio no cabeçalho "From" visível deve corresponder ao domínio autenticado por SPF ou ao domínio que assina o DKIM (dependendo das configurações do modo de alinhamento). Se pelo menos um passar com o alinhamento adequado, o DMARC passa. A política DMARC então determina o que acontece com os e-mails que falham nessa avaliação.
"Falhas de autenticação são assassinos silenciosos no cold email. Seus e-mails desaparecem em pastas de spam sem notificação de retorno, sem mensagem de erro, sem qualquer indicação de que algo está errado. Quando você percebe a queda nas taxas de resposta, semanas de prospecção podem ter sido desperdiçadas."
A propagação de DNS é o processo pelo qual as mudanças nos registros DNS se espalham pela rede de resolvedores recursivos da internet. Quando você atualiza um registro DNS, ele não aparece instantaneamente em todos os lugares. Servidores diferentes ao redor do mundo verão os registros antigos e novos em momentos diferentes, o que pode causar falhas temporárias de autenticação durante o período de transição.
O TTL é o valor (em segundos) que diz aos resolvedores de DNS por quanto tempo armazenar em cache um registro antes de verificar por atualizações. Um TTL de 3600 significa que os resolvedores armazenarão o registro em cache por uma hora. Valores de TTL mais baixos significam propagação mais rápida das mudanças, mas resultam em mais consultas de DNS. Valores de TTL mais altos reduzem o tráfego de DNS, mas tornam a propagação mais lenta.
Para os registros de autenticação de e-mail, recomendamos os seguintes valores de TTL:
Problema 1: Mudanças não aparecem após o tempo esperado Primeiro, verifique se as mudanças foram salvas corretamente no seu provedor de DNS. Depois, cheque usando várias ferramentas de consulta DNS de diferentes localizações geográficas. Se os servidores de nomes autoritativos mostram os registros corretos, mas outros resolvedores não, isso é um atraso normal de propagação.
Problema 2: Resultados inconsistentes entre resolvedores Durante a propagação, resolvedores diferentes terão versões diferentes em cache. Esse é o comportamento esperado. Evite enviar campanhas importantes imediatamente após mudanças de DNS. Aguarde pelo menos 2x o valor de TTL anterior para garantir uma ampla propagação.
Problema 3: Limites de taxa da API do provedor de DNS Ao configurar múltiplos domínios de forma programática, você pode atingir limites de taxa da API. Espace suas requisições e implemente backoff exponencial. O InboxOne lida com isso automaticamente com um enfileiramento inteligente de requisições.
# Verificar a propagação de DNS pela linha de comando # Consultar registros MX dig MX example.com +short nslookup -type=mx example.com # Consultar registro SPF (TXT) dig TXT example.com +short nslookup -type=txt example.com # Consultar registro DKIM dig TXT selector._domainkey.example.com +short # Consultar registro DMARC dig TXT _dmarc.example.com +short # Consultar servidor de nomes específico (ignorar cache local) dig @8.8.8.8 TXT example.com +short # Verificar TTL restante dig example.com +noall +answer
Antes de enviar qualquer cold email a partir de um domínio recém-configurado, você deve verificar se todos os registros de autenticação estão devidamente configurados e propagados. Pular esta etapa é uma das causas mais comuns de desastres de entregabilidade. Um único registro mal configurado pode arruinar a taxa de colocação na caixa de entrada de toda a sua campanha.
Várias ferramentas online gratuitas podem verificar sua configuração de DNS:
O método de verificação mais confiável é enviar um e-mail de teste e analisar os resultados de autenticação nos cabeçalhos do e-mail. O Gmail, por exemplo, mostra os resultados de autenticação diretamente no e-mail quando você clica em "Mostrar original". Procure por estes cabeçalhos:
# Cabeçalhos de Autenticação de E-mail a Verificar Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=selector header.b=abc123; spf=pass (google.com: domain of sender@example.com designates 192.168.1.1 as permitted sender) smtp.mailfrom=sender@example.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com # O que procurar: # dkim=pass - Assinatura DKIM verificada com sucesso # spf=pass - IP de envio autorizado pelo registro SPF # dmarc=pass - Avaliação DMARC passou (SPF/DKIM alinhados) # Indicadores comuns de falha: # dkim=fail (falha na verificação da assinatura) # spf=softfail (IP não está no SPF, mas com política de soft fail) # dmarc=fail (falha de alinhamento ou violação de política)
A verificação manual funciona para a configuração inicial, mas o monitoramento contínuo é essencial para manter a entregabilidade. Registros DNS podem ser acidentalmente excluídos, expirar ou se tornar inválidos devido a mudanças do provedor. O monitoramento automatizado detecta esses problemas antes que eles afetem suas campanhas.
As principais métricas a monitorar incluem a validade do registro SPF e a contagem de consultas (máximo de 10 consultas), a presença e validade criptográfica da chave DKIM, a consistência da política DMARC e a entrega de relatórios, e a disponibilidade dos registros MX e os tempos de resposta.
Até mesmo administradores de sistema experientes cometem erros de configuração de DNS. Esses erros frequentemente passam despercebidos por semanas ou meses porque o e-mail "meio que funciona" - as mensagens são entregues, mas a taxas reduzidas. Aqui estão os erros mais comuns e como evitá-los.
Ter mais de um registro SPF em um domínio causa falha imediata de autenticação. A especificação do SPF determina que um domínio NÃO DEVE ter múltiplos registros SPF. Se você precisar autorizar fontes de envio adicionais, adicione-as ao seu registro SPF existente usando o mecanismo "include".
Os registros SPF podem incluir referências a outros registros (via "include", "redirect", "a", "mx", etc.), mas o número total de consultas de DNS durante a avaliação do SPF não deve exceder 10. Cada mecanismo "include" conta como uma consulta, e includes aninhados contam para o total. Exceder esse limite faz o SPF retornar um erro permanente.
Chaves DKIM menores que 1024 bits são consideradas inseguras e podem causar falhas de autenticação com alguns receptores. Use chaves de 2048 bits para segurança e compatibilidade ideais. Alguns provedores de DNS mais antigos têm problemas com chaves de 2048 bits devido aos limites de comprimento dos registros TXT; nesses casos, a chave deve ser dividida em múltiplas strings.
Começar com uma política DMARC de "reject" antes de verificar seus fluxos de e-mail é uma receita para o desastre. Comece com "none" para coletar relatórios e identificar quaisquer fontes de envio legítimas que você possa ter esquecido. Avance para "quarantine" para testes e, depois, para "reject" quando estiver confiante de que todo o e-mail legítimo está devidamente autenticado.
As políticas de SPF e DMARC no seu domínio raiz não se aplicam automaticamente aos subdomínios. Se você envia a partir de subdomínios (como mail.example.com), cada subdomínio precisa de seu próprio registro SPF. Para o DMARC, você pode usar a tag "sp" para definir uma política de subdomínio, ou criar registros DMARC separados para cada subdomínio.
Embora entender a configuração de DNS seja valioso, a realidade é que o gerenciamento manual de DNS não escala. Agências que gerenciam dezenas ou centenas de domínios de cold email não podem se dar ao luxo de configurar e monitorar manualmente os registros de autenticação de cada um. É aqui que o gerenciamento automatizado de DNS do InboxOne se torna essencial.
Quando você compra um domínio através do InboxOne ou conecta um domínio existente, nosso sistema configura automaticamente todos os registros DNS necessários. Os registros SPF, DKIM, DMARC e MX são criados com configurações ideais em minutos. Não há edições manuais necessárias e nenhuma adivinhação sobre o tempo de propagação.
O InboxOne oferece suporte tanto à Cloudflare quanto à ClouDNS para gerenciamento de DNS. Nossas integrações de API com esses provedores garantem que os registros sejam criados corretamente, os valores de TTL sejam otimizados e quaisquer peculiaridades específicas do provedor sejam tratadas automaticamente.
O InboxOne Protect monitora a saúde do DNS do seu domínio 24 horas por dia, 7 dias por semana. Se um registro for acidentalmente excluído, modificado incorretamente ou falhar na validação, nosso sistema detecta o problema em minutos e o repara automaticamente. Você recebe notificações sobre quaisquer problemas, mas na maioria dos casos o problema é resolvido antes mesmo de você ver o alerta.
Para agências que operam em escala, o InboxOne oferece operações em massa que configuram o DNS de dezenas de domínios simultaneamente. Nosso sistema de enfileiramento inteligente lida com os limites de taxa da API, acompanha o status de propagação em todos os domínios e informa quando cada domínio está pronto para uso. Isso transforma o que seriam horas de trabalho manual em alguns minutos de supervisão.
"A configuração de DNS costumava ser a parte mais tediosa de colocar novos domínios de cold email no ar. Com o InboxOne, eu literalmente nunca penso nisso. Os domínios ficam prontos para aquecer minutos após a compra, com autenticação perfeita todas as vezes."
- Dono de Agência de Cold Email
Seja você quem configura o DNS manualmente ou usa ferramentas automatizadas, seguir estas melhores práticas garantirá a entregabilidade ideal para suas campanhas de cold email.
A configuração de DNS é a fundação técnica que determina se seus cold emails chegam à caixa de entrada ou desaparecem no spam. Compreender como os registros MX, SPF, DKIM e DMARC trabalham juntos lhe dá o conhecimento para diagnosticar problemas de entregabilidade e garantir que sua infraestrutura esteja devidamente configurada.
No entanto, o gerenciamento manual de DNS se torna cada vez mais impraticável à medida que você escala. O tempo gasto configurando registros, solucionando problemas de propagação e monitorando problemas é tempo não gasto na execução real das suas campanhas. É por isso que plataformas como o InboxOne existem: para lidar com a complexidade técnica para que você possa focar no que mais importa - escrever uma ótima prospecção e fazer seu negócio crescer.
Quer você opte por gerenciar o DNS manualmente ou aproveitar a automação, os princípios deste guia o ajudarão a manter a infraestrutura de autenticação que a entregabilidade moderna de e-mail exige. Seus cold emails merecem chegar à caixa de entrada. A configuração adequada de DNS garante que eles cheguem.
A propagação de DNS normalmente leva de 15 minutos a 48 horas, dependendo das configurações de TTL (Time to Live) e do provedor de DNS. Com provedores como a Cloudflare, as mudanças costumam se propagar em 5 a 15 minutos. A configuração automática do InboxOne garante configurações de TTL ideais para uma propagação mais rápida.
Não, você deve ter apenas um registro SPF por domínio. Ter múltiplos registros SPF causa falhas de autenticação porque os servidores de recebimento não saberão qual usar. Se você precisar autorizar múltiplas fontes de envio, combine-as em um único registro SPF usando o mecanismo 'include'.
O DMARC exige alinhamento, o que significa que o domínio no cabeçalho 'From' deve corresponder ao domínio autenticado por SPF ou ao domínio que assina o DKIM. Se o alinhamento falhar mesmo quando o SPF ou o DKIM passam individualmente, o DMARC falhará. É por isso que a configuração adequada dos três protocolos é essencial.
Embora os registros MX sejam usados principalmente para receber e-mails, tê-los configurados é importante para a credibilidade do cold email. Muitos filtros de spam verificam a existência de registros MX como sinal de um domínio legítimo. Um domínio sem registros MX pode ser sinalizado como suspeito, já que não consegue receber respostas.
O InboxOne configura automaticamente os registros SPF, DKIM, DMARC e MX para todos os domínios comprados ou conectados através da plataforma. Usando a integração com a API da Cloudflare ou da ClouDNS, os registros são criados em minutos, com zero intervenção manual. Nosso sistema também monitora a saúde do DNS 24 horas por dia, 7 dias por semana, e corrige problemas automaticamente.
Um soft fail (~all) diz aos servidores de recebimento para aceitarem e-mails que falham no SPF, mas marcá-los como suspeitos, enquanto um hard fail (-all) instrui os servidores a rejeitarem os e-mails totalmente. Para cold email, começar com soft fail é recomendado durante o aquecimento, e depois fazer a transição para hard fail assim que sua reputação de envio estiver estabelecida.
Você pode verificar os registros DNS usando ferramentas como MXToolbox, Google Admin Toolbox ou utilitários de linha de comando como dig e nslookup. O InboxOne oferece verificação de DNS integrada que checa automaticamente todos os registros de autenticação e alerta você sobre quaisquer problemas antes que eles afetem a entregabilidade.