Melhorar a entregabilidade de e-mail: revisão de 30 minutos

Você pode enviar, receber 250 OK e não encontrar a mensagem no destino. A aceitação pelo servidor de envio não confirma a entrega final nem a chegada à caixa de entrada. Para melhorar a entregabilidade de e-mail, comece por DNS, autenticação e reputação. O guia de e-mail empresarial explica o modelo geral; aqui está o roteiro de diagnóstico.

Quando mensagens caem no spam, mudar o assunto pode não resolver. Um SPF incorreto, uma chave DKIM antiga ou uma falha de alinhamento DMARC podem provocar filtragem antes da leitura. Propostas podem sumir, redefinições de senha atrasar e respostas de suporte não chegar.

Este guia ajuda a melhorar a entregabilidade de e-mail com uma primeira revisão de cerca de 30 minutos. É uma referência para organizar o diagnóstico, não um prazo garantido para resolver o problema.

Revisão de 30 minutos para melhorar a entregabilidade

Verifique listas de bloqueio, filas, SPF, DKIM, alinhamento DMARC, DNS reverso e denúncias de spam, nessa ordem. Assim você investiga a infraestrutura antes de mudar o texto; relevância da mensagem e qualidade da lista também importam.

1. Veja se o IP de envio está no Spamhaus ou em outra lista de bloqueio relevante.
2. Confirme se as mensagens saem do servidor ou provedor SMTP.
3. Revise a sintaxe SPF e o limite de 10 termos que acionam consultas DNS.
4. Verifique o seletor DKIM, o tamanho da chave e o domínio de assinatura.
5. Confira o alinhamento DMARC, não apenas a existência do registro.
6. Confirme a correspondência entre DNS direto e reverso e analise as denúncias de spam.

No TrekMail, consulte as telas de status DNS e os registros antes de alterá-los manualmente. Comece pelos registros DNS necessários e depois pelas verificações de status DNS.

Etapa 1: verificar listas de bloqueio de nível 1

Se o IP está no Spamhaus ZEN, mudanças no conteúdo e novas tentativas podem deixar a causa intacta. Contenha o envio afetado, preserve as evidências e investigue a inclusão antes de solicitar a remoção.

Exemplo: uma caixa comprometida envia malware por 20 minutos, o IP entra em uma lista e alguns destinatários passam a rejeitar faturas ou respostas legítimas. O alcance depende das políticas de recebimento.

Etapa 2: confirmar que o e-mail sai do sistema

Uma fila pode indicar um gargalo interno ou um adiamento pelo destinatário; ambos fazem parte do processo de entrega. Consulte a fila do MTA ou o painel SMTP e confira como o provedor define os estados:

• Queued: pendente por carga, cota, tempo de espera ou adiamento remoto.
• Bounced: falha de entrega; examine a causa e o sistema que a gerou.
• Sent, mas ausente: identifique qual aceitação esse estado confirma antes de investigar a filtragem.

Verificar DNS e autenticação em ordem

SPF avalia a autorização do IP para MAIL FROM ou HELO quando aplicável; DKIM verifica as partes assinadas; DMARC exige autenticação alinhada ao From. O DNS reverso ajuda a identificar o servidor, mas não comprova sozinho confiança nem entrega na caixa de entrada.

1. Revisar o limite de SPF

Dois problemas a verificar são registros SPF duplicados e cadeias extensas de avaliação. O limite de 10 se aplica aos termos que acionam consultas DNS, inclusive de forma recursiva: a, mx, include, exists, ptr e redirect. Não é simplesmente a contagem de todos os pacotes DNS ou dos include visíveis. Excedê-lo pode produzir um erro permanente.

dig txt example.com +short

Verifique estes pontos:

• Um único registro TXT SPF para a identidade avaliada, iniciado por v=spf1; suas cadeias entre aspas são concatenadas, e outros TXT de verificação podem coexistir.
• Não use +all, que autoriza qualquer origem.
• Um encerramento como ~all ou -all, conforme a política revisada.
• Uma cadeia de include documentada, com suas dependências recursivas.

Exemplo para análise:

example.com. IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:spf.trekmail.net ~all"

O registro pode respeitar ou ultrapassar o limite por causa das dependências dos provedores. Para melhorar a entregabilidade de e-mail, remova autorizações de serviços efetivamente desativados. Não troque include por IPs fixos sem análise: a infraestrutura desses serviços pode mudar.

Ao enviar com TrekMail, reúna as autorizações em um registro e use os valores atuais do painel. Este exemplo não substitui a configuração do seu domínio. Para começar, consulte como configurar e-mail no meu domínio.

2. Verificar o seletor e a chave DKIM

A assinatura precisa ser validada criptograficamente com o seletor e a chave pública publicados, considerando as partes cobertas. Chaves antigas, seletores ausentes ou rotações incompletas podem impedir a verificação mesmo quando SPF passa.

dig txt selector._domainkey.example.com +short

Verificações iniciais:

• O registro correto existe.
• Se a versão estiver indicada, usa v=DKIM1; isso não prova que a assinatura é válida.
• p= contém uma chave pública válida e utilizável, não apenas um texto parecido com uma chave.
• O assinante usa o seletor correspondente nos cabeçalhos, e a verificação criptográfica é bem-sucedida.

Ver pass em uma ferramenta não encerra a análise. Para usar DKIM no DMARC, o domínio de assinatura precisa estar alinhado ao From visível. SPF também pode satisfazer DMARC quando passa com uma identidade alinhada, inclusive em serviços externos.

3. Verificar o alinhamento DMARC

DMARC relaciona SPF ou DKIM ao From visível. Publicar o registro não basta: pelo menos uma dessas autenticações precisa passar e estar alinhada ao domínio.

dig txt _dmarc.example.com +short

Registro ilustrativo para observação:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Um caso a analisar: Return-Path: bounce.provider.com representa de forma abreviada o domínio do endereço real do envelope SMTP, não um cabeçalho Return-Path completo válido. O provedor assina com d=provider.com, enquanto o From visível é team@example.com. SPF e DKIM podem passar e DMARC falhar se nenhum domínio estiver alinhado. A política de observação do exemplo não desativa os demais filtros nem garante entrega.

Verificar cada fluxo autorizado pode levar horas quando há vários provedores. No TrekMail, confira a disponibilidade de Managed SMTP nos planos pagos ou mantenha seu motor por BYO SMTP. Separar hospedagem e envio pode permitir mudanças na camada de saída sem migrar todas as caixas; não garante reputações independentes.

4. Confirmar o DNS reverso com resolução direta

FCrDNS verifica se o PTR do IP aponta para um nome cuja resolução direta contém o mesmo IP. O destinatário pode considerar essa correspondência, mas ela não comprova confiança nem entrega.

dig -x 203.0.113.10 +short
dig A mail.example.com +short

A resolução direta deve retornar o IP original; verifique também AAAA quando aplicável. O proprietário ou provedor do IP normalmente controla o PTR. Solicite a correção adequada e confira os dois sentidos antes de continuar tentando melhorar a entregabilidade de e-mail.

Acompanhar as denúncias de spam

Combine autenticação correta com mensagens esperadas pelos destinatários. O Google recomenda uma taxa de spam abaixo de 0.1% e evitar que alcance 0.3% ou mais. Esses valores pertencem à métrica de domínio para Gmail pessoal e dependem das condições de disponibilidade, não são um indicador universal de entregabilidade.

SPF, DKIM e DMARC válidos não anulam denúncias dos usuários. Consulte Google Postmaster Tools regularmente, por exemplo a cada semana. Um volume insuficiente pode impedir a exibição de dados; ausência de dados não comprova ausência de reclamações.

Para interpretar essa métrica:

• Abaixo de 0.1%: dentro da meta recomendada, sem comprovar toda a saúde do envio.
• 0.1% - 0.3%: investigue consentimento, segmentação e conteúdo.
• A partir de 0.3%: pause campanhas não essenciais e investigue a causa antes de retomá-las.

Para várias marcas, separe permissões, fluxos e acompanhamento. Domínios ou assinaturas DKIM diferentes não garantem isolamento de reputação se o IP ou a infraestrutura forem compartilhados. A hospedagem de e-mail multidomínio ajuda na organização, mas essas dependências precisam ser avaliadas.

Ler o código de falha antes de mudar configurações

O código e a resposta completa do destinatário orientam o diagnóstico. Corrija a causa confirmada em vez de fazer alterações DNS aleatórias que possam adicionar outro problema.

Se você encaminha entre sistemas, diferencie falhas de autenticação do encaminhamento e reputação do remetente. O guia de configuração e diagnóstico do encaminhamento explica essas rotas.

O que não mudar sem análise

Evite mudanças emergenciais que eliminem evidências ou criem riscos. Trocar IP sem diagnóstico, excluir todo erro temporário ou editar DNS às 2 da manhã pode complicar as próximas 48 horas.

1. Não troque IP para contornar uma lista. Investigue o comprometimento e planeje mudanças autorizadas; IP novo não garante confiança.
2. Não exclua um destinatário no primeiro erro temporário. Um 4xx exige contexto e uma política limitada de tentativas.
3. Não acumule provedores no SPF: retire os que não fazem mais envios autorizados.
4. Não imponha p=reject antes de verificar os fluxos autorizados e o alinhamento necessário.
5. Não esqueça os subdomínios e as dependências compartilhadas de reputação.

Dois modelos de operação da entregabilidade

Hospedagem e envio podem estar vinculados ou separados. A separação pode facilitar mudanças na saída sem migrar cada caixa, mas compatibilidade, cotas e reputação compartilhada ainda precisam ser analisadas.

Modelo integrado: um provedor controla as caixas e a infraestrutura de saída. Diante de um problema compartilhado, avalie as alternativas reais antes de decidir migrar.

Modelo com envio separável: TrekMail reúne hospedagem, armazenamento compartilhado da conta com cotas individuais e limites do plano, migração IMAP e gestão multidomínio conforme o plano. Somente o modelo Nano descrito exige SMTP externo próprio via BYO SMTP para todos os envios e respostas. A referência histórica a planos pagos desde $3.50 por mês inclui Managed SMTP, sujeito às permissões e à configuração de um cliente compatível. O teste de 14 dias para planos pagos é descrito com cartão obrigatório. Confira as condições atuais; Nano pode permitir testar o recebimento sem cartão quando disponível, sem promessa de permanência.

A separação pode permitir corrigir o envio sem reconstruir todo o sistema. A migração IMAP exige acesso autorizado, compatibilidade, backup e verificação de pastas e mensagens, além de DNS e sincronização final. Contatos e calendários precisam de tratamento separado.

Compare licenças por usuário, cotas compartilhadas e flexibilidade de saída conforme a necessidade. Manter seu próprio provedor permite gerenciar essa camada, sem garantir reputação independente ou eliminar todos os riscos compartilhados.

Conclusão: começar pelas verificações comprováveis

Para melhorar a entregabilidade de e-mail, confira SPF, assinaturas DKIM, alinhamento DMARC, DNS reverso, denúncias e serviços autorizados. Essas verificações ajudam a encontrar erros; consentimento e qualidade dos destinatários continuam essenciais.

Se você busca melhorar a entregabilidade de e-mail em um modelo multidomínio, compare cotas de armazenamento, condições da migração IMAP e opções BYO SMTP ou Managed SMTP do plano. Os preços do TrekMail permitem conferir condições atuais e possíveis cobranças.

Consulte as perguntas frequentes do Google sobre requisitos de envio e a especificação SPF na RFC 7208. Se o problema persistir, obtenha cabeçalhos e registros relevantes com autorização e examine a cadeia de falhas, sem substituir evidências por suposições.