Testar a entregabilidade de e-mail: o guia completo antes do envio
Por CaptainDNS
Publicado em 27 de março de 2026
Atualizado em 31 de julho 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
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. As 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 do 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 é detetável antes do envio. Um teste de entregabilidade analisa a sua configuração DNS (SPF, DKIM, DMARC), verifica a reputação do seu IP, controla os seus cabeçalhos de e-mail e produz uma pontuação global sobre 100. Em 30 segundos, sabe exatamente o que funciona e o que bloqueia os seus e-mails.
Este guia cobre o processo completo: porque testar, como funciona um teste de entregabilidade, como interpretar cada secção da pontuação, e sobretudo como corrigir os problemas identificados para passar de 40/100 a 100/100. Quer seja administrador de sistemas, desenvolvedor ou responsável de marketing, cada secção contém ações concretas.
Teste a sua entregabilidade agora
Porque 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 fornecedores 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 controlos há seis meses pode falhar hoje porque um fornecedor adicionou um include SPF adicional, ou porque a rotação de chave DKIM não foi realizada.
Os 5 controlos 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 | Registo 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 | Registos 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 os seus e-mails têm uma probabilidade significativa de serem classificados como spam. Abaixo de 50/100, a maioria dos fornecedores rejeitará ou filtrará as suas mensagens.
Estes cinco controlos abrangem a configuração e a autenticação; a reputação do remetente, a segurança de transporte e o envolvimento dos destinatários também pesam na entrega, como decompõe o nosso guia sobre a pontuação de entregabilidade de email.
As exigências do Gmail e Yahoo 2024
Desde fevereiro de 2024, Gmail e Yahoo tornaram obrigatórios controlos que antes eram opcionais. Essas exigências aplicam-se 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)
- Registo 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 cancelamento de subscrição num 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 o 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 registo SPF.
# Recuperar o registo SPF de captaindns.com
dig TXT captaindns.com +short | grep "v=spf1"
O registo SPF é um registo 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 o 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 registo 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 registo 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 partilhar 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=) aplica-se.
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: controlos complementares (MX, PTR, cabeçalhos, blacklists)
O teste verifica em seguida elementos técnicos adicionais:
Registos MX: o domínio deve ter registos 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 registo 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, UCEProtect, SpamCop). A presença em uma única blacklist importante pode ser suficiente para que os seus e-mails sejam rejeitados pela maioria dos fornecedores.
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 secção por secção
Uma vez executado o teste, o relatório exibe uma pontuação global e um detalhamento por categoria. Veja como ler cada secção e identificar as ações prioritárias.
Secçã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 em falta |
permerror | 0/25 | O registo SPF é inválido | Corrigir a sintaxe ou reduzir os lookups |
none | 0/25 | Nenhum registo SPF encontrado | Criar um registo 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.
Secçã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 registo 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.
Secçã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 registo DMARC | Criar um registo DMARC |
A armadilha do p=none: essa política é indispensável durante a fase de deploy, pois permite recolher relatórios sem impactar a entrega. Mas permanecer em p=none indefinidamente equivale a não ter DMARC em termos de proteção. Os fornecedores de e-mail concedem um crédito de confiança aos domínios que publicam p=quarantine ou p=reject.
Secção MX / PTR (15 pontos)
| Verificação | Pontos | Critério |
|---|---|---|
| MX válidos | 5/15 | Pelo menos um registo 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 utiliza um VPS ou um servidor dedicado, o PTR se configura pelo painel do seu fornecedor de alojamento. Se utiliza um serviço de envio (SendGrid, Mailgun, Brevo), o PTR normalmente é gerido pelo fornecedor nos seus IPs dedicados.
Secçã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
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 o seu SPF está ausente ou é inválido, essa é a correção que traz mais pontos imediatamente.
Caso 1: Nenhum registo SPF
Crie um registo 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:spf.brevo.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 acumulam-se. 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 não utiliza mais
Para um guia detalhado sobre o PermError, consulte o guia SPF PermError.
Caso 3: Dois registos SPF no mesmo domínio
A RFC 7208 proíbe estritamente a presença de vários registos TXT que começam por v=spf1 no mesmo domínio. Se 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 registo
Funda os dois registos 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 o seu domínio e clique em "Generate new record"
- Escolha um comprimento de chave de 2048 bits
- Copie o registo 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 registos 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 registo contendo "v=DKIM1; k=rsa; p=MII..."
Se o comando não retorna nada, o problema é DNS: ou o registo 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 fornecedores 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"
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 faturação, 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; t=y; rua=mailto:dmarc-rua@captaindns.com"
O t=y é o modo de teste do DMARCbis: os destinatários reportam as falhas mas ainda não aplicam a quarentena. É uma rede de segurança: se uma fonte legítima ainda não foi corrigida, os seus e-mails continuam a passar. Retire o t=y quando os relatórios deixarem de mostrar falhas legítimas.
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"
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 fornecedores.
Prioridade 4: configurar o reverse DNS (+15 pontos MX/PTR)
Registos MX: se o seu domínio não tem registo MX, adicione um apontando para o 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 fornecedor de alojamento 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 o 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 |
| 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 o 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 utiliza PHP mail(), passe para uma biblioteca como PHPMailer ou SwiftMailer que gera cabeçalhos conformes. Se utiliza um framework (Laravel, Django, Rails), os cabeçalhos geralmente são corretos por predefiniçã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 o seu próprio SPF
Se apesar dessas correções os seus e-mails continuam a cair 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 cancelamento de subscrição 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: envia a partir de contact@captaindns.com, mas o seu fornecedor 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 o seu fornecedor 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 fornecedores 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
A sua pontuação MX/PTR cai por causa de um IP em blacklist. As causas principais:
- IP partilhado: se está em um IP partilhado com outros clientes do seu fornecedor de alojamento, o spam de outro cliente pode afetar - Comprometimento: um script no seu servidor envia spam sem que o saiba (formulário de contacto explorado, conta de e-mail comprometida)
- Histórico do IP: o IP que 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 torna-se 10.113.0.203).
Quando testar: as 5 situações críticas
Um teste de entregabilidade não é um controlo 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 guardar 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 fornecedor 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 fornecedor e publicar a chave no DNS
- Verificar o alinhamento DMARC com o novo fornecedor
- 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 registo TXT, migração de registar, ativação de DNSSEC. Os erros de copiar e colar nos registos 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 a sua autenticação. Um SPF que ultrapassa repentinamente os 10 lookups (porque um fornecedor adicionou um include aninhado) pode provocar uma queda brusca.
5. Em um ritmo mensal, em prevenção
As configurações DNS mudam, os fornecedores atualizam os seus registos, as chaves DKIM precisam de ser renovadas. Um teste mensal deteta as regressões antes que impactem os seus envios. Programe um lembrete mensal e verifique que a 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 a sua pontuação detalhada secção por secçã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 a sua pontuação e a sua taxa de entregabilidade.
-
Verifique as 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 a monitorização DMARC: os relatórios agregados (
rua=) alertam-no automaticamente quando um problema de autenticação aparece. Analise-os pelo menos uma vez por semana durante a fase de crescimento, depois mensalmente. -
Planeie um teste mensal para detetar regressões. As configurações DNS evoluem silenciosamente (fornecedor que modifica os 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 a sua configuração DNS (SPF, DKIM, DMARC), a reputação do seu IP de envio, os seus cabeçalhos de e-mail e a eventual presença do seu IP em blacklists. 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, os seus e-mails têm uma probabilidade significativa de serem classificados como spam. Abaixo de 50/100, a maioria dos fornecedores (Gmail, Outlook, Yahoo) rejeitará ou filtrará as 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 registo 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 registo SPF. Os mecanismos include, a, mx, redirect e exists contam cada um como um lookup. Os includes aninhados acumulam-se: um include que contém por sua vez 3 includes consome 4 lookups no total. Acima de 10, o servidor retorna um PermError e o seu SPF é considerado inválido.
Porque 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 o seu fornecedor de envio assina com o seu próprio domínio DKIM e utiliza o seu próprio endereço no envelope SMTP, nem SPF nem DKIM estão alinhados com o seu domínio From. Configure o seu fornecedor para utilizar o 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 registos DNS. Um TTL de 300 segundos (5 minutos) significa que os servidores de recebimento verão a sua modificação em menos de 5 minutos. Um TTL de 86400 (24 horas) pode levar até 24 horas. Antes de modificar um registo 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 fornecedor de envio. O objetivo é detetar 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 partilhar 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 registos). 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 registos 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 registo 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 registo SPF é estruturalmente inválido (lookups demais, sintaxe incorreta, duplicatas). O registo não pode ser avaliado.
- PTR (Pointer Record): registo 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 regista endereços IP conhecidos por enviar spam. As principais são Spamhaus, Barracuda, SpamCop e UCEProtect.
- Seletor DKIM: identificador (cadeia de caracteres) que permite localizar a chave pública DKIM no DNS. O registo é publicado em
seletor._domainkey.captaindns.com. - RFC 7208: especificação oficial do protocolo SPF que define a sintaxe dos registos, 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, reencaminhamentos). Suportado por Gmail e Microsoft.
- RFC 8058: especificação do mecanismo de cancelamento de subscrição num clique (One-Click Unsubscribe) via o cabeçalho List-Unsubscribe-Post, exigido pelo Gmail para remetentes em massa desde 2024.
Teste a sua entregabilidade agora: utilize o mail tester da CaptainDNS para obter a sua pontuação sobre 100 e a lista exata das correções a aplicar. Um teste leva 30 segundos e pode transformar as suas taxas de entrega.
