Testar a entregabilidade de e-mail: o guia completo antes do envio
Por CaptainDNS
Publicado em 27 de março de 2026
- Um e-mail em cada cinco nunca chega à caixa de entrada, principalmente por causa de uma autenticação SPF, DKIM ou DMARC ausente ou mal configurada
- Pontuação de entregabilidade: SPF (+25), DKIM (+25), DMARC (+20), MX/PTR (+15), cabeçalhos (+15) = 100 pontos possíveis
- Desde 2024: Gmail e Yahoo exigem SPF + DKIM obrigatórios, e DMARC para remetentes em massa (> 5 000 e-mails/dia)
- Correção prioritária: um teste de 30 segundos identifica os problemas exatos, este guia detalha como corrigi-los um por um
Você acabou de lançar uma campanha de e-mail. Tudo está pronto: o conteúdo está caprichado, o design está impecável, a lista de destinatários está limpa. Três dias depois, chegam as estatísticas: 22 % dos seus e-mails nunca chegaram à caixa de entrada. Sem bounces. Sem erros visíveis. Suas mensagens simplesmente desapareceram em uma pasta de spam ou foram silenciosamente rejeitadas pelo servidor de recebimento.
Esse cenário não é um caso extremo. Segundo os dados da Validity (Sender Score), um e-mail em cada cinco enviados no mundo nunca chega à caixa de entrada de seu destinatário. Para as empresas, o custo é direto: faturas ignoradas, confirmações de pedido perdidas, leads de marketing desperdiçados, e uma reputação de domínio que se degrada silenciosamente.
A boa notícia: a maioria desses problemas é detectável antes do envio. Um teste de entregabilidade analisa sua configuração DNS (SPF, DKIM, DMARC), verifica a reputação do seu IP, controla seus cabeçalhos de e-mail e produz uma pontuação global sobre 100. Em 30 segundos, você sabe exatamente o que funciona e o que bloqueia seus e-mails.
Este guia cobre o processo completo: por que testar, como funciona um teste de entregabilidade, como interpretar cada seção da pontuação, e sobretudo como corrigir os problemas identificados para passar de 40/100 a 100/100. Seja você administrador de sistemas, desenvolvedor ou responsável de marketing, cada seção contém ações concretas.
Teste sua entregabilidade agora
Por que testar a entregabilidade antes de cada envio
O problema invisível
A entregabilidade de e-mail é um problema silencioso. Diferente de um site fora do ar (visível imediatamente), um e-mail que cai no spam não gera nenhum alerta. O remetente pensa que a mensagem foi entregue. O destinatário não sabe que um e-mail o espera na pasta de spam. Ninguém reclama porque ninguém sabe.
Os provedores de e-mail (Gmail, Outlook, Yahoo, Apple Mail) tomam decisões de filtragem em questão de milissegundos, baseando-se em centenas de sinais. E esses sinais evoluem constantemente. Um domínio que passava em todos os controles há seis meses pode falhar hoje porque um provedor adicionou um include SPF adicional, ou porque a rotação de chave DKIM não foi realizada.
Os 5 controles de um teste de entregabilidade
Um teste completo verifica cinco categorias distintas, cada uma contribuindo para a pontuação global:
| Categoria | Pontos | O que é verificado |
|---|---|---|
| SPF | 25/100 | Registro DNS TXT válido, IP do remetente autorizado, número de lookups |
| DKIM | 25/100 | Assinatura criptográfica válida, chave pública DNS acessível, alinhamento do domínio |
| DMARC | 20/100 | Política publicada, alinhamento SPF/DKIM, endereço de relatório configurado |
| MX / PTR | 15/100 | Registros MX presentes, reverse DNS configurado, IP não em blacklist |
| Cabeçalhos | 15/100 | From/Reply-To coerentes, Message-ID válido, sem campos suspeitos |
Uma pontuação inferior a 70/100 significa que seus e-mails têm uma probabilidade significativa de serem classificados como spam. Abaixo de 50/100, a maioria dos provedores rejeitará ou filtrará suas mensagens.
As exigências do Gmail e Yahoo 2024
Desde fevereiro de 2024, Gmail e Yahoo tornaram obrigatórios controles que antes eram opcionais. Essas exigências se aplicam a todos os remetentes, com regras adicionais para envios em massa:
Para todos os remetentes:
- SPF ou DKIM válido (no mínimo um dos dois)
- Registro DNS do tipo PTR (reverse DNS) configurado para o IP de envio
- Taxa de spam declarada no Google Postmaster Tools inferior a 0,3 %
Para remetentes em massa (> 5 000 e-mails/dia para Gmail):
- SPF e DKIM válidos (ambos obrigatórios)
- DMARC publicado com no mínimo
p=none - Alinhamento do domínio From com SPF ou DKIM
- Cabeçalho
List-Unsubscribecom descadastramento em um clique (RFC 8058) - Formatação conforme a RFC 5322
Não cumprir essas exigências provoca uma rejeição progressiva. O Gmail não bloqueia 100 % dos e-mails de um dia para o outro: começa adiando 4 % das mensagens (código 4xx), depois aumenta a porcentagem até a rejeição permanente (código 5xx) se o problema não for corrigido.
Como funciona um teste de entregabilidade
Um teste de entregabilidade reproduz o processo exato que um servidor de recebimento executa quando recebe seu e-mail. Aqui estão as quatro etapas, em ordem.
Etapa 1: resolução DNS e verificação SPF
O teste começa consultando o DNS do seu domínio para recuperar o registro SPF.
# Recuperar o registro SPF de captaindns.com
dig TXT captaindns.com +short | grep "v=spf1"
O registro SPF é um registro DNS do tipo TXT que começa por v=spf1. Ele lista os servidores autorizados a enviar e-mails pelo seu domínio. Aqui está um exemplo real:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all
O servidor de recebimento compara o IP do servidor que enviou o e-mail com os IPs autorizados pelo seu SPF. O processo é recursivo: cada include: dispara uma nova consulta DNS para recuperar os IPs do subdomínio referenciado.
Ponto crítico: a RFC 7208 limita a 10 o número de consultas DNS (lookups) durante a avaliação SPF. Os mecanismos include, a, mx, redirect e exists contam cada um como um lookup. Os mecanismos ip4 e ip6 não contam (são valores diretos). No 11o lookup, o servidor retorna permerror e seu SPF é considerado inválido.
# Verificar quantos lookups gera seu SPF
# Cada include gera pelo menos 1 lookup
dig TXT _spf.google.com +short
# Resultado: "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com ..."
# Cada sub-include também conta!
Etapa 2: verificação da assinatura DKIM
DKIM (DomainKeys Identified Mail) adiciona uma assinatura criptográfica a cada e-mail. O servidor de envio assina a mensagem com uma chave privada. O servidor de recebimento verifica essa assinatura recuperando a chave pública correspondente no DNS.
A assinatura DKIM está presente no cabeçalho DKIM-Signature do e-mail:
DKIM-Signature: v=1; a=rsa-sha256; d=captaindns.com; s=google;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
Os campos chave:
d=: o domínio que reivindica a assinatura (deve corresponder ao domínio From para DMARC)s=: o seletor, que identifica qual chave pública usara=: o algoritmo de assinatura (rsa-sha256oued25519-sha256)bh=: o hash do corpo da mensagemb=: a assinatura em si
O teste recupera a chave pública via DNS:
# Recuperar a chave pública DKIM
# Formato: seletor._domainkey.dominio
dig TXT google._domainkey.captaindns.com +short
A resposta contém um registro TXT com a chave pública:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
O servidor de recebimento utiliza essa chave pública para verificar a assinatura. Se o corpo da mensagem ou os cabeçalhos assinados foram modificados após a assinatura, a verificação falha.
RSA vs Ed25519: a maioria dos servidores utiliza RSA-SHA256 com chaves de 2048 bits. Ed25519 é mais rápido e gera assinaturas mais curtas, mas o suporte do lado do recebimento ainda não é universal. Google Workspace e Microsoft 365 suportam apenas RSA para a assinatura DKIM de saída em março de 2026.
Etapa 3: avaliação DMARC e alinhamento
DMARC (Domain-based Message Authentication, Reporting, and Conformance) verifica que SPF e DKIM não são apenas válidos, mas também alinhados com o domínio visível no campo From do e-mail.
# Recuperar a política DMARC
dig TXT _dmarc.captaindns.com +short
Resultado típico:
"v=DMARC1; p=reject; rua=mailto:dmarc-rua@captaindns.com; ruf=mailto:dmarc-ruf@captaindns.com; adkim=r; aspf=r; pct=100"
Vamos detalhar cada tag:
| Tag | Valor | Significado |
|---|---|---|
v=DMARC1 | obrigatório | Identifica o registro como DMARC |
p= | none, quarantine, reject | Política aplicada aos e-mails que falham |
rua= | endereço de e-mail | Destino dos relatórios agregados (estatísticas diárias) |
ruf= | endereço de e-mail | Destino dos relatórios forenses (amostras de falhas) |
adkim= | r (relaxed) ou s (strict) | Modo de alinhamento DKIM |
aspf= | r (relaxed) ou s (strict) | Modo de alinhamento SPF |
pct= | 0-100 | Porcentagem de e-mails submetidos à política |
Alinhamento relaxed vs strict: no modo relaxed (adkim=r), o domínio da assinatura DKIM (d=) deve compartilhar o mesmo domínio organizacional que o From. Exemplo: uma assinatura d=mail.captaindns.com está alinhada com um From contact@captaindns.com. No modo strict (adkim=s), os domínios devem corresponder exatamente.
A avaliação DMARC segue esta lógica:
- SPF passa e está alinhado com o From: DMARC passa.
- DKIM passa e está alinhado com o From: DMARC passa.
- Se nenhum dos dois está alinhado: DMARC falha, e a política (
p=) se aplica.
Um ponto frequentemente mal compreendido: DMARC passa se pelo menos um dos dois mecanismos (SPF ou DKIM) passa com alinhamento. Não é necessário que ambos tenham sucesso.
Etapa 4: controles complementares (MX, PTR, cabeçalhos, blacklists)
O teste verifica em seguida elementos técnicos adicionais:
Registros MX: o domínio deve ter registros MX válidos apontando para servidores de e-mail ativos. Um domínio sem MX sinaliza um domínio que não está configurado para receber correio, o que é suspeito para um remetente.
dig MX captaindns.com +short
# 10 mx1.captaindns.com.
# 20 mx2.captaindns.com.
Reverse DNS (PTR): o IP do servidor de envio deve ter um registro PTR que resolva para um hostname, e esse hostname deve resolver de volta para o mesmo IP. É a verificação FCrDNS (Forward-confirmed reverse DNS).
# Verificar o reverse DNS de um IP
dig -x 203.0.113.10 +short
# mail.captaindns.com.
# Verificar que o forward corresponde
dig A mail.captaindns.com +short
# 203.0.113.10
Blacklists: o IP de envio é verificado contra as principais blacklists (Spamhaus ZEN, Barracuda, SORBS, SpamCop). A presença em uma única blacklist importante pode ser suficiente para que seus e-mails sejam rejeitados pela maioria dos provedores.
Cabeçalhos de e-mail: o teste verifica a coerência dos cabeçalhos From, Reply-To, Message-ID, Date e a presença de campos obrigatórios segundo a RFC 5322.
Interpretar os resultados seção por seção
Uma vez executado o teste, o relatório exibe uma pontuação global e um detalhamento por categoria. Veja como ler cada seção e identificar as ações prioritárias.
Seção SPF (25 pontos)
| Resultado | Pontos | Significado | Ação |
|---|---|---|---|
pass | 25/25 | O IP de envio está autorizado pelo seu SPF | Nenhuma ação |
softfail | 10/25 | O IP não está explicitamente autorizado (~all) | Passar para -all após verificação |
fail | 0/25 | O IP está explicitamente rejeitado pelo seu SPF | Adicionar o IP ou o include faltante |
permerror | 0/25 | O registro SPF é inválido | Corrigir a sintaxe ou reduzir os lookups |
none | 0/25 | Nenhum registro SPF encontrado | Criar um registro SPF |
Erro frequente: um resultado softfail dá a impressão de que "passa mesmo assim". Na realidade, os servidores modernos tratam o softfail quase como um fail, especialmente em combinação com um DMARC em modo quarantine ou reject. O softfail deveria ser apenas uma fase transitória durante o deploy inicial do SPF.
Seção DKIM (25 pontos)
| Resultado | Pontos | Significado | Ação |
|---|---|---|---|
pass | 25/25 | Assinatura válida e chave pública encontrada | Nenhuma ação |
fail | 0/25 | Assinatura inválida (corpo modificado, chave incorreta) | Diagnosticar a causa exata |
none | 0/25 | Nenhuma assinatura DKIM no e-mail | Configurar DKIM no servidor de envio |
permerror | 0/25 | Chave pública malformada ou inacessível | Verificar o registro DNS do seletor |
O resultado dkim=fail é o mais complexo de diagnosticar porque as causas são múltiplas: hash do body alterado por um relay intermediário, chave pública ausente do DNS, assinatura expirada (tag x= ultrapassada), ou algoritmo de canonicalização incorreto. Consulte o guia de diagnóstico DKIM fail para uma árvore de decisão completa.
Seção DMARC (20 pontos)
| Resultado | Pontos | Significado | Ação |
|---|---|---|---|
pass | 20/20 | SPF ou DKIM alinhado e válido | Nenhuma ação |
fail (p=none) | 5/20 | Falha mas sem consequência (modo vigilância) | Progredir para quarantine depois reject |
fail (p=quarantine) | 0/20 | E-mails enviados para spam | Corrigir o alinhamento SPF/DKIM |
fail (p=reject) | 0/20 | E-mails rejeitados | Corrigir o alinhamento SPF/DKIM |
none | 0/20 | Nenhum registro DMARC | Criar um registro DMARC |
A armadilha do p=none: essa política é indispensável durante a fase de deploy, pois permite coletar relatórios sem impactar a entrega. Mas permanecer em p=none indefinidamente equivale a não ter DMARC em termos de proteção. Os provedores de e-mail concedem um crédito de confiança aos domínios que publicam p=quarantine ou p=reject.
Seção MX / PTR (15 pontos)
| Verificação | Pontos | Critério |
|---|---|---|
| MX válidos | 5/15 | Pelo menos um registro MX resolvendo para um IP ativo |
| PTR configurado | 5/15 | Reverse DNS do IP de envio resolvendo para um hostname |
| FCrDNS | 3/15 | Forward-confirmed reverse DNS (ida e volta IP/hostname) |
| Sem blacklist | 2/15 | IP ausente das blacklists principais |
O reverse DNS (PTR) é frequentemente negligenciado porque depende do proprietário da faixa de IP, não do proprietário do domínio. Se você utiliza um VPS ou um servidor dedicado, o PTR se configura pelo painel do seu provedor de hospedagem. Se você utiliza um serviço de envio (SendGrid, Mailgun, Brevo), o PTR normalmente é gerenciado pelo provedor nos seus IPs dedicados.
Seção cabeçalhos (15 pontos)
| Verificação | Pontos | Critério |
|---|---|---|
| From válido | 4/15 | Endereço de e-mail sintaticamente correto com domínio que resolve |
| Message-ID | 3/15 | Presente e no formato RFC 5322 |
| Date | 3/15 | Presente e dentro de um intervalo razoável (não no futuro, não > 7 dias) |
| Reply-To coerente | 3/15 | Mesmo domínio que From ou domínio de confiança |
| Sem X-Mailer suspeito | 2/15 | Sem software de spam conhecido nos cabeçalhos |
Um cabeçalho Message-ID ausente ou malformado é um sinal forte de spam para os filtros. Cada e-mail deve ter um Message-ID único no formato <identificador@dominio>. Os servidores de e-mail corretamente configurados o geram automaticamente, mas certos scripts PHP ou bibliotecas de envio personalizadas o omitem.
De 40/100 a 100/100: as correções passo a passo
Você executou o teste e a pontuação não está boa. Aqui está a ordem exata das correções, classificadas por impacto na pontuação.
Prioridade 1: criar ou corrigir SPF (+25 pontos)
Se seu SPF está ausente ou é inválido, essa é a correção que traz mais pontos imediatamente.
Caso 1: Nenhum registro SPF
Crie um registro DNS TXT no seu domínio raiz:
captaindns.com. IN TXT "v=spf1 include:_spf.google.com -all"
Adapte os mecanismos aos seus serviços de envio:
| Serviço | Include a adicionar |
|---|---|
| Google Workspace | include:_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| SendGrid | include:sendgrid.net |
| Mailgun | include:mailgun.org |
| Brevo (ex-Sendinblue) | include:sendinblue.com |
| Amazon SES | include:amazonses.com |
| OVHcloud | include:mx.ovh.com |
Caso 2: SPF PermError (lookups demais)
O limite de 10 lookups é a causa mais frequente do PermError. Cada include: conta como pelo menos 1 lookup, e os includes aninhados se acumulam. Google Workspace sozinho consome 4 lookups.
Para diagnosticar o problema:
# Contar os lookups do seu SPF
dig TXT captaindns.com +short | grep "v=spf1"
# Depois seguir cada include recursivamente
dig TXT _spf.google.com +short
# "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
# = 3 lookups adicionais apenas para este include
Soluções de redução:
- Substituir os
include:porip4:eip6:diretos quando os IPs são estáveis (SPF flattening) - Utilizar macros SPF (
%{i}eexists:) para os casos avançados - Eliminar os includes de serviços que você não utiliza mais
Para um guia detalhado sobre o PermError, consulte o guia SPF PermError.
Caso 3: Dois registros SPF no mesmo domínio
A RFC 7208 proíbe estritamente a presença de vários registros TXT que começam por v=spf1 no mesmo domínio. Se você tem dois, o servidor retorna imediatamente permerror.
# Verificar se há duplicatas
dig TXT captaindns.com +short | grep "v=spf1"
# Se duas linhas aparecem: fundir em um único registro
Funda os dois registros em um único que contenha todos os mecanismos.
Prioridade 2: configurar DKIM (+25 pontos)
DKIM requer dois elementos: uma chave privada instalada no servidor de envio (que assina as mensagens) e uma chave pública publicada no DNS (que permite a verificação).
Configuração com Google Workspace:
- Google Admin Console > Apps > Google Workspace > Gmail > Authenticate email
- Selecione seu domínio e clique em "Generate new record"
- Escolha um comprimento de chave de 2048 bits
- Copie o registro DNS CNAME ou TXT fornecido
- Publique-o na sua zona DNS com o formato
google._domainkey.captaindns.com - Volte ao console e clique em "Start authentication"
Configuração com Microsoft 365:
Microsoft 365 utiliza dois registros CNAME por domínio:
selector1._domainkey.captaindns.com CNAME selector1-captaindns-com._domainkey.captaindns.onmicrosoft.com
selector2._domainkey.captaindns.com CNAME selector2-captaindns-com._domainkey.captaindns.onmicrosoft.com
Verificação pós-configuração:
# Verificar que a chave pública está acessível
dig TXT google._domainkey.captaindns.com +short
# Deveria retornar um registro contendo "v=DKIM1; k=rsa; p=MII..."
Se o comando não retorna nada, o problema é DNS: ou o registro ainda não propagou (aguardar 24-48h), ou há um erro de nomeação no seletor.
Comprimento da chave: utilize 2048 bits no mínimo. As chaves de 1024 bits são consideradas fracas desde 2020. Alguns provedores já rejeitam assinaturas baseadas em chaves RSA de menos de 1024 bits.
Prioridade 3: publicar e endurecer DMARC (+20 pontos)
A implementação do DMARC segue um ciclo em três fases.
Fase 1: Vigilância (2 a 4 semanas)
_dmarc.captaindns.com IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@captaindns.com; pct=100"
Durante essa fase, nenhum e-mail é bloqueado. Os relatórios agregados (rua=) chegam diariamente em formato XML e contêm as estatísticas de autenticação de todos os servidores que enviaram e-mails pelo seu domínio.
Analise os relatórios para identificar:
- As fontes legítimas que falham (servidor de faturamento, CRM, ferramenta de marketing)
- As fontes ilegítimas (tentativas de spoofing)
- A taxa de alinhamento SPF e DKIM
Fase 2: Quarentena (4 a 8 semanas)
_dmarc.captaindns.com IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@captaindns.com; pct=25"
O pct=25 aplica a política de quarentena apenas a 25 % dos e-mails que falham. É uma rede de segurança: se uma fonte legítima ainda não foi corrigida, 75 % dos seus e-mails ainda passam. Aumente progressivamente: 25 %, 50 %, 75 %, 100 %.
Fase 3: Rejeição
_dmarc.captaindns.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-rua@captaindns.com; ruf=mailto:dmarc-ruf@captaindns.com; adkim=r; aspf=r; pct=100"
Neste ponto, todo e-mail que falha o alinhamento DMARC é rejeitado pelo servidor de recebimento. É a configuração mais segura e a que traz mais crédito de confiança junto aos provedores.
Prioridade 4: configurar o reverse DNS (+15 pontos MX/PTR)
Registros MX: se seu domínio não tem registro MX, adicione um apontando para seu servidor de recebimento:
captaindns.com. IN MX 10 mx1.captaindns.com.
captaindns.com. IN MX 20 mx2.captaindns.com.
Reverse DNS: conecte-se ao painel de administração do seu provedor de hospedagem e configure o PTR do seu IP de envio para que aponte para o FQDN do seu servidor de e-mail:
# Após a configuração, verifique:
dig -x 203.0.113.10 +short
# Esperado: mail.captaindns.com.
Blacklists: se seu IP aparece em uma blacklist, o procedimento de remoção depende da lista:
| Blacklist | Procedimento | Prazo |
|---|---|---|
| Spamhaus | Formulário de remoção em spamhaus.org | 24-48h após correção |
| Barracuda | Formulário em barracudacentral.org | 12-24h |
| SORBS | Remoção automática após 48h sem spam | 48h |
| SpamCop | Expiração automática em 24h | 24h |
Prioridade 5: limpar os cabeçalhos (+15 pontos)
Os problemas de cabeçalhos geralmente são causados por scripts de envio personalizados ou bibliotecas mal configuradas.
Checklist de cabeçalhos:
- O campo
Fromutiliza um endereço com seu domínio, não um domínio genérico - O
Message-IDestá presente e no formato<unique-id@captaindns.com> - O campo
Dateestá presente e correto (fuso horário incluído) - O
Reply-To, se presente, utiliza um domínio coerente com o From - Nenhum cabeçalho
X-Mailerreferenciando uma ferramenta de spam conhecida - O
Content-Typeespecifica o charset (UTF-8 recomendado)
Se você utiliza PHP mail(), passe para uma biblioteca como PHPMailer ou SwiftMailer que gera cabeçalhos conformes. Se você utiliza um framework (Laravel, Django, Rails), os cabeçalhos geralmente são corretos por padrão.
Os erros mais frequentes
SPF PermError: o limite de 10 lookups
É o erro mais difundido. Um domínio que utiliza Google Workspace (4 lookups), SendGrid (2 lookups), Mailchimp (2 lookups) e um servidor interno (1 lookup com um a:) já atinge 9 lookups. A adição de um único serviço a mais provoca o PermError.
O diagnóstico é simples:
dig TXT captaindns.com +short | grep "v=spf1"
# Conte cada include, a, mx, redirect, exists
# Siga os includes aninhados recursivamente
A correção depende da sua situação:
- Elimine os serviços não utilizados: verifique se cada include corresponde a um serviço ativo
- Utilize o SPF flattening: substitua os includes pelos IPs finais (atenção com a manutenção)
- Dedique um subdomínio: envie o marketing a partir de
news.captaindns.comcom seu próprio SPF
Se apesar dessas correções seus e-mails continuam caindo no spam, o problema vai além do SPF. Consulte o guia diagnóstico completo do spam para analisar as outras causas (reputação, conteúdo, engajamento).
DKIM fail: body hash did not verify
Esse erro significa que o conteúdo do e-mail foi modificado após a assinatura. As causas mais comuns:
- Relay intermediário: um servidor entre o envio e o recebimento adicionou um rodapé, reescreveu URLs ou injetou um pixel de rastreamento
- Antivírus ou DLP: um software de segurança modificou o corpo da mensagem
- Lista de distribuição: os servidores de listas (Listserv, Sympa) frequentemente adicionam um rodapé de descadastramento que quebra a assinatura
A correção consiste em identificar qual componente da sua cadeia de envio modifica a mensagem após a assinatura DKIM, e depois reconfigurar a ordem das operações para que a modificação seja feita antes da assinatura.
Para as listas de distribuição, o protocolo ARC (Authenticated Received Chain) permite preservar os resultados de autenticação através dos relays. Gmail e Microsoft suportam ARC desde 2019.
DMARC fail: defeito de alinhamento
O erro mais sutil. SPF passa, DKIM passa, mas DMARC falha mesmo assim. A causa: nenhum dos dois está alinhado com o domínio do campo From.
Cenário típico: você envia a partir de contact@captaindns.com, mas seu provedor de envio assina com d=sendgrid.net (DKIM não alinhado) e o envelope SMTP utiliza bounces@sendgrid.net (SPF não alinhado). Resultado: as duas autenticações passam tecnicamente, mas nenhuma está alinhada com captaindns.com.
Correção:
- Configure seu provedor para assinar com
d=captaindns.com(DKIM alinhado) - Configure o return-path (envelope SMTP) para utilizar um subdomínio do seu domínio (SPF alinhado)
A maioria dos provedores de envio (SendGrid, Mailgun, Brevo, Postmark) oferece uma opção "Domain Authentication" ou "Sender Authentication" que configura automaticamente o alinhamento DKIM e SPF.
IP em uma blacklist
Sua pontuação MX/PTR cai por causa de um IP em blacklist. As causas principais:
- IP compartilhado: se você está em um IP compartilhado com outros clientes do seu provedor de hospedagem, o spam de outro cliente pode afetar você
- Comprometimento: um script no seu servidor envia spam sem que você saiba (formulário de contato explorado, conta de e-mail comprometida)
- Histórico do IP: o IP que você acabou de receber era usado anteriormente por um spammer
A verificação é imediata:
# Verificar Spamhaus
dig +short 10.113.0.203.zen.spamhaus.org
# Se uma resposta 127.0.0.x aparece, o IP está listado
Note que o IP está invertido na consulta DNS (203.0.113.10 se torna 10.113.0.203).
Quando testar: as 5 situações críticas
Um teste de entregabilidade não é um controle pontual. Aqui estão as cinco situações em que um teste é indispensável.
1. Antes do lançamento de uma campanha de e-mail
Cada campanha de marketing deveria ser precedida por um teste. Um problema de autenticação em um envio de 50 000 e-mails significa 50 000 e-mails potencialmente perdidos. O teste leva 30 segundos e pode salvar uma campanha inteira.
Envie um e-mail de teste para o endereço fornecido pelo mail tester, consulte o relatório e corrija os problemas antes do envio em massa.
2. Após uma mudança de provedor de envio
A migração de um serviço de envio para outro é o momento mais arriscado para a entregabilidade. É preciso atualizar o SPF (substituir o antigo include pelo novo), reconfigurar o DKIM (novo seletor, nova chave), e verificar o alinhamento DMARC.
Checklist para a migração:
- Atualizar o SPF: remover o antigo include, adicionar o novo
- Configurar DKIM no novo provedor e publicar a chave no DNS
- Verificar o alinhamento DMARC com o novo provedor
- Testar a entregabilidade antes de transferir o tráfego
- Conservar o antigo include SPF durante 48h (e-mails em trânsito)
3. Após uma modificação DNS
Qualquer modificação da sua zona DNS pode impactar a entregabilidade: mudança de TTL, atualização de um registro TXT, migração de registrador, ativação de DNSSEC. Os erros de copiar e colar nos registros DNS são frequentes e o resultado é um SPF ou DKIM quebrado sem nenhuma mensagem de erro visível.
4. Quando as taxas de abertura caem
Uma queda repentina das taxas de abertura (mais de 10 % de variação em uma semana) pode indicar um problema de entregabilidade. Antes de procurar a causa no conteúdo ou no assunto dos e-mails, teste sua autenticação. Um SPF que ultrapassa repentinamente os 10 lookups (porque um provedor adicionou um include aninhado) pode provocar uma queda brusca.
5. Em um ritmo mensal, em prevenção
As configurações DNS mudam, os provedores atualizam seus registros, as chaves DKIM precisam ser renovadas. Um teste mensal detecta as regressões antes que impactem seus envios. Programe um lembrete mensal e verifique que sua pontuação se mantém em 100/100.
Plano de ação recomendado
-
Execute um teste de entregabilidade no mail tester da CaptainDNS. Envie um e-mail de teste e recupere sua pontuação detalhada seção por seção.
-
Corrija os problemas por ordem de impacto: SPF primeiro (25 pontos), depois DKIM (25 pontos), depois DMARC (20 pontos). Cada correção aumenta imediatamente sua pontuação e sua taxa de entregabilidade.
-
Verifique suas correções relançando o teste após cada modificação DNS. Aguarde a propagação DNS (5 a 60 minutos dependendo do TTL) antes de testar novamente.
-
Implemente o monitoramento DMARC: os relatórios agregados (
rua=) alertam você automaticamente quando um problema de autenticação aparece. Analise-os pelo menos uma vez por semana durante a fase de crescimento, depois mensalmente. -
Planeje um teste mensal para detectar regressões. As configurações DNS evoluem silenciosamente (provedor que modifica seus includes, chave DKIM que expira, IP que muda de blacklist). Um teste mensal custa 30 segundos e pode evitar semanas de entregabilidade degradada.
FAQ
O que é um mail tester e como funciona?
Um mail tester é uma ferramenta que analisa a entregabilidade dos seus e-mails verificando sua configuração DNS (SPF, DKIM, DMARC), a reputação do seu IP de envio, seus cabeçalhos de e-mail e a eventual presença do seu IP em blacklists. Você envia um e-mail de teste para um endereço fornecido pela ferramenta, e ela produz um relatório detalhado com uma pontuação sobre 100 e as correções a aplicar.
Qual pontuação de entregabilidade se deve alcançar?
Mire em uma pontuação de 100/100. Uma pontuação superior a 80/100 é aceitável para a maioria dos envios transacionais. Abaixo de 70/100, seus e-mails têm uma probabilidade significativa de serem classificados como spam. Abaixo de 50/100, a maioria dos provedores (Gmail, Outlook, Yahoo) rejeitará ou filtrará suas mensagens.
SPF, DKIM e DMARC são todos obrigatórios?
Desde fevereiro de 2024, Gmail e Yahoo exigem no mínimo SPF ou DKIM para todos os remetentes. Para remetentes em massa (mais de 5 000 e-mails por dia para Gmail), os três são obrigatórios: SPF e DKIM válidos, mais um registro DMARC publicado. Na prática, configurar os três é recomendado para todos os domínios, independentemente do volume.
O que é o limite de 10 DNS lookups do SPF?
A RFC 7208 limita a 10 o número de consultas DNS recursivas durante a avaliação de um registro SPF. Os mecanismos include, a, mx, redirect e exists contam cada um como um lookup. Os includes aninhados se acumulam: um include que contém por sua vez 3 includes consome 4 lookups no total. Acima de 10, o servidor retorna um PermError e seu SPF é considerado inválido.
Por que meu DMARC falha se SPF e DKIM passam?
O DMARC verifica não apenas que SPF e DKIM passem, mas também que estejam alinhados com o domínio do campo From do e-mail. Se seu provedor de envio assina com seu próprio domínio DKIM e utiliza seu próprio endereço no envelope SMTP, nem SPF nem DKIM estão alinhados com seu domínio From. Configure seu provedor para utilizar seu domínio (Domain Authentication) para resolver esse problema.
Quanto tempo leva para as correções DNS fazerem efeito?
O prazo depende do TTL (Time To Live) dos seus registros DNS. Um TTL de 300 segundos (5 minutos) significa que os servidores de recebimento verão sua modificação em menos de 5 minutos. Um TTL de 86400 (24 horas) pode levar até 24 horas. Antes de modificar um registro crítico, reduza primeiro o TTL para 300, aguarde a propagação desse novo TTL, e depois faça a modificação.
Como saber se meu IP está em uma blacklist?
Consulte as principais blacklists por meio de uma consulta DNS reversa. Por exemplo, para verificar o IP 203.0.113.10 no Spamhaus: dig +short 10.113.0.203.zen.spamhaus.org. Se uma resposta do tipo 127.0.0.x for retornada, o IP está listado. Uma ferramenta de verificação de blacklist automatiza essa verificação em várias dezenas de listas simultaneamente.
É preciso testar antes de cada envio de campanha?
Sim, para as campanhas de marketing em massa. Um teste leva menos de um minuto e pode evitar desperdiçar um envio inteiro. Para os e-mails transacionais (confirmações, faturas), um teste mensal é suficiente, exceto após uma mudança de configuração DNS ou de provedor de envio. O objetivo é detectar as regressões antes que impactem a entregabilidade.
Qual é a diferença entre alinhamento relaxed e strict no DMARC?
No modo relaxed (adkim=r, aspf=r), o domínio da assinatura DKIM ou do envelope SPF deve compartilhar o mesmo domínio organizacional que o From. Exemplo: uma assinatura d=mail.captaindns.com está alinhada com um From @captaindns.com. No modo strict (adkim=s, aspf=s), os domínios devem corresponder exatamente. O modo relaxed é recomendado para a maioria dos deploys porque tolera o uso de subdomínios.
O que fazer se minha pontuação não sobe apesar das correções?
Verifique que a propagação DNS tenha terminado (aguarde pelo menos o TTL dos seus registros). Teste cada componente individualmente: SPF sozinho (dig TXT captaindns.com), DKIM sozinho (dig TXT seletor._domainkey.captaindns.com), DMARC sozinho (dig TXT _dmarc.captaindns.com). Se os registros DNS estão corretos mas a pontuação não muda, o problema pode vir da reputação do IP (blacklist) ou do conteúdo do e-mail de teste.
Glossário
- SPF (Sender Policy Framework): protocolo de autenticação de e-mail definido pela RFC 7208 que lista os servidores autorizados a enviar e-mails por um domínio por meio de um registro DNS TXT que começa por
v=spf1. - DKIM (DomainKeys Identified Mail): protocolo de autenticação de e-mail definido pela RFC 6376 que adiciona uma assinatura criptográfica a cada e-mail, verificável por meio de uma chave pública publicada no DNS.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): protocolo definido pela RFC 7489 que verifica o alinhamento SPF e DKIM com o domínio From e define a política de tratamento das falhas (none, quarantine, reject).
- Alinhamento: em contexto DMARC, correspondência entre o domínio utilizado por SPF ou DKIM e o domínio visível no campo From do e-mail. Pode ser relaxed (mesmo domínio organizacional) ou strict (correspondência exata).
- PermError: erro permanente retornado quando um registro SPF é estruturalmente inválido (lookups demais, sintaxe incorreta, duplicatas). O registro não pode ser avaliado.
- PTR (Pointer Record): registro DNS que associa um endereço IP a um hostname (reverse DNS). Utilizado pelos servidores de recebimento para verificar a identidade do servidor de envio.
- FCrDNS (Forward-confirmed reverse DNS): verificação em duas etapas. O reverse DNS do IP retorna um hostname, e a resolução desse hostname deve retornar o IP de origem.
- Blacklist (DNSBL): lista de bloqueio baseada em DNS que registra endereços IP conhecidos por enviar spam. As principais são Spamhaus, Barracuda, SORBS e SpamCop.
- Seletor DKIM: identificador (cadeia de caracteres) que permite localizar a chave pública DKIM no DNS. O registro é publicado em
seletor._domainkey.captaindns.com. - RFC 7208: especificação oficial do protocolo SPF que define a sintaxe dos registros, o limite de 10 lookups, os void lookups e os resultados possíveis.
- ARC (Authenticated Received Chain): protocolo que preserva os resultados de autenticação de e-mail através dos relays intermediários (listas de distribuição, encaminhamentos). Suportado por Gmail e Microsoft.
- RFC 8058: especificação do mecanismo de descadastramento em um clique (One-Click Unsubscribe) via o cabeçalho List-Unsubscribe-Post, exigido pelo Gmail para remetentes em massa desde 2024.
Teste sua entregabilidade agora: utilize o mail tester da CaptainDNS para obter sua pontuação sobre 100 e a lista exata das correções a aplicar. Um teste leva 30 segundos e pode transformar suas taxas de entrega.
