Entregabilidade de e-mail: guia prático de diagnóstico

Você envia uma mensagem e o servidor responde 250 OK. Duas semanas depois, descobre que a proposta ficou no spam ou foi retida por um filtro antes de chegar à vista do destinatário. A aceitação pelo servidor não confirma a pasta em que o e-mail terminou.

Esse é um problema de entregabilidade de e-mail. Não se resume a erros de digitação ou linhas de assunto: a infraestrutura também pesa. Desde as mudanças de requisitos do início de 2024, Google, Yahoo e Microsoft aplicam controles mais exigentes conforme o serviço e o tráfego. Falhas de autenticação e reputação podem levar a filtragem ou rejeição, mas não existe uma resposta única de todos os provedores.

Este guia atende tanto a fundadores que enviam dez mensagens essenciais por dia quanto a prestadores que administram quinhentos domínios. Em vez de dicas genéricas sobre assuntos atraentes, vamos investigar causas: por que o envio falha, o que verificar e como manter uma configuração adequada em 2026.

Entrega e entregabilidade: entenda a diferença

Entregabilidade de e-mail não é sinônimo de mensagem aceita. O status de entrega indica que o servidor receptor aceitou o e-mail com uma resposta 250 OK. A entregabilidade diz respeito à capacidade de chegar à caixa de entrada ao longo do tempo, incluindo categorias legítimas como Promoções, e não apenas atravessar a primeira barreira.

Veja a diferença entre os três conceitos:

• Entregue: o servidor receptor aceitou a mensagem. É como deixar uma carta na portaria: isso ainda não informa onde ela será colocada nem se alguém a verá.
• Posicionamento na caixa de entrada: a mensagem aparece na caixa de entrada, seja na categoria Principal ou em outra categoria legítima, e pode ser consultada pelo destinatário.
• Entregabilidade de e-mail: a capacidade de manter esse posicionamento ao longo do tempo, em diferentes domínios e volumes de envio.

Se o painel mostra 99% de entrega e apenas 2% de abertura, investigue o posicionamento, mas não conclua automaticamente que as mensagens foram para o spam. Privacidade, bloqueio de imagens, rastreamento e interesse do público também afetam aberturas. Distinguir aceitação de posicionamento ajuda a escolher a investigação correta.

O modelo: autenticação, reputação, conteúdo e classificação

Os servidores receptores combinam várias verificações. Este modelo ajuda a organizar o diagnóstico, mas não representa uma sequência rígida e universal: uma falha de autenticação pode ser tratada de formas diferentes. Pense também como administrador de sistemas, não apenas como profissional de marketing.

1. Autenticação, a identificação: SPF, DKIM e DMARC verificam aspectos da autorização, da assinatura e do alinhamento do domínio. Uma falha pode causar rejeição ou filtragem, conforme as políticas do receptor.
2. Reputação, o histórico: o domínio ou IP costuma enviar mensagens desejadas ou gerar reclamações? Google e Microsoft usam sinais próprios do histórico de envio. Uma taxa de denúncias de spam de 0.3% exige atenção, considerando a métrica e o provedor.
3. Conteúdo e comportamento, o envio: disparar 10,000 mensagens na primeira hora de um IP sem histórico pode causar problemas. Links quebrados, conteúdo indesejado e mensagens difíceis de ler também merecem revisão, sem tratar palavras ou proporções de imagens como regras universais.
4. Posicionamento, a decisão: caixa de entrada, categoria Promoções, spam ou quarentena. O receptor combina seus próprios sinais para decidir o destino.

Não há atalho que dispense autenticação e reputação. Corrigir o conteúdo continua sendo útil, mas não substitui a revisão do DNS quando existem erros técnicos. Priorize o que os registros e respostas do receptor efetivamente mostram.

Sintomas: como interpretar os erros

O diagnóstico começa pelos códigos e pela resposta completa do servidor. Eles ajudam a delimitar o problema, mas um código isolado nem sempre identifica a causa. Use os exemplos abaixo como orientação, não como prova conclusiva.

Para organizar a investigação desses sintomas, consulte como evitar que os e-mails vão para o spam. Adapte a sequência às evidências do seu ambiente.

Etapa 1 - SPF, DKIM e DMARC

SPF, DKIM e DMARC são uma base importante da entregabilidade de e-mail. Desde o início de 2024, Google e Yahoo exigem os três para os remetentes em massa abrangidos por suas regras. A Microsoft adotou requisitos próprios em outro calendário. Confirme o serviço e o escopo aplicáveis; cumprir a autenticação não garante caixa de entrada.

Consulte o guia de autenticação de e-mail com SPF, DKIM e DMARC para a sequência completa. Para os requisitos de DNS do TrekMail, veja a documentação dos registros DNS necessários.

SPF (Sender Policy Framework)

SPF publica no DNS, em um registro TXT, uma política que autoriza servidores a enviar usando o domínio do remetente do envelope SMTP, ou o domínio HELO em situações aplicáveis. Não autentica diretamente o endereço From visível. O receptor avalia a política e decide o tratamento segundo suas próprias regras.

Um registro SPF começa com v=spf1. É comum terminar com ~all para softfail ou -all para fail, embora esses não sejam os únicos formatos possíveis. Os termos anteriores definem os IPs e serviços autorizados.

Dois problemas recorrentes de SPF podem afetar a entregabilidade:

• Encaminhamento: se Bob encaminha uma mensagem do Gmail para o Yahoo, o servidor seguinte vê o IP do encaminhador. Isso pode fazer o SPF falhar. SPF sozinho não resolve todos esses casos; uma assinatura DKIM válida e alinhada pode ajudar se as partes assinadas permanecerem intactas.
• Limite de 10 consultas: SPF limita a 10 os mecanismos e modificadores avaliados que exigem consultas DNS, incluindo termos aninhados. Gmail, Outlook, Mailchimp, Zendesk, seu CRM e o serviço transacional podem aumentar o uso desse orçamento, mas a quantidade de serviços não basta para provar excesso. Ultrapassar o limite gera PermError na avaliação afetada; há também outras causas desse erro. Veja o limite de consultas SPF e o guia de configuração do registro SPF.

DKIM (DomainKeys Identified Mail)

DKIM acrescenta uma assinatura criptográfica à mensagem, cobrindo as partes do corpo e os cabeçalhos especificados. O servidor usa uma chave privada, enquanto a chave pública correspondente fica no DNS. O receptor consulta essa chave para validar a assinatura. A validação depende também da chave, da assinatura e das demais condições, não apenas da ausência de alterações.

Ao contrário do SPF, DKIM pode continuar válido após um encaminhamento se os dados assinados permanecerem compatíveis com a assinatura e sua canonicalização. Alterações feitas por listas ou encaminhadores podem invalidá-lo. Para contribuir com DMARC, a assinatura também precisa estar alinhada ao domínio do From.

Atenção ao tamanho da chave: o Google exige no mínimo 1024 bits para RSA e recomenda 2048 bits. Chaves antigas de 512 bits são inadequadas. Publique um novo seletor antes de usá-lo e mantenha a chave pública anterior enquanto mensagens assinadas em trânsito ainda precisarem ser verificadas. Veja como configurar as chaves DKIM.

DMARC: política e alinhamento

DMARC verifica se há SPF aprovado e alinhado ou alguma assinatura DKIM válida e alinhada ao domínio do From visível. Não exige que os dois passem. As identidades precisam estar alinhadas, usando o domínio organizacional no modo relaxado ou correspondência exata no modo estrito. A política informa o tratamento solicitado para falhas, sujeito à decisão do receptor.

O registro TXT de DMARC é publicado em _dmarc.yourdomain.com. As opções de política são:

• p=none - Não solicita quarentena nem rejeição por DMARC. Relatórios exigem configuração própria e dependem do receptor. É uma opção comum para começar a observar os fluxos.
• p=quarantine - Solicita quarentena ou tratamento como spam para mensagens que falham em DMARC, conforme a política local. Considere a mudança após inventário e testes.
• p=reject - Solicita rejeição das mensagens que falham. Não é uma garantia de bloqueio nem uma etapa obrigatória sem antes validar remetentes, monitoramento e reversão.

Um ponto frequente em pequenas empresas é o alinhamento DMARC. Um serviço como Mailchimp pode usar mailchimp.com no Return-Path. SPF pode aprovar esse domínio sem alinhá-lo ao From da empresa. DMARC só falha se também não houver uma assinatura DKIM válida e alinhada.

Dependendo do serviço, configure um domínio de retorno personalizado ou DKIM alinhado; os dois não são obrigatórios para passar em DMARC. Veja o diagnóstico de falhas e alinhamento DMARC e o guia de configuração do registro DMARC.

O assistente de DNS do TrekMail pode orientar a geração de SPF, DKIM e DMARC a partir dos serviços informados. Revise o inventário, publique os registros no DNS correto e verifique a propagação e o orçamento de 10 consultas. A geração não elimina erros nem substitui a validação contínua.

Etapa 2 - Entregabilidade e reputação

Entregabilidade de e-mail não termina na autenticação. Mesmo com SPF, DKIM e DMARC corretos, mensagens podem ir para o spam. Cada receptor combina sinais do histórico do domínio e dos IPs; não existe uma pontuação única compartilhada por todos, nem recuperação automática.

O risco de 0.3%

Google e Yahoo destacam taxas baixas de denúncias de spam em suas regras. Atingir 0.3%, por exemplo 3 denúncias em 1,000 mensagens no denominador aplicável, é preocupante. Filtragem, rejeição e elegibilidade para mitigação dependem do provedor e das condições; não se trata de bloqueio instantâneo e universal.

Três denúncias por mil parecem poucas, mas um segmento sem interesse pode ser suficiente para elevar a métrica. Listas compradas aumentam o risco de mensagens indesejadas. Investigue a origem das denúncias, não apenas o percentual.

O limite para remetentes em massa

Ao enviar aproximadamente 5,000 mensagens por dia a contas pessoais do Gmail, considerando a agregação do domínio principal, o Google pode classificar o remetente como remetente em massa. Essa classificação pode permanecer mesmo com a redução posterior do volume; não significa, por si só, má reputação. Cuide da reputação do domínio de e-mail antes de escalar e acompanhe a reputação do remetente para identificar problemas de posicionamento.

Reputação do domínio e do IP

São dimensões distintas, avaliadas de formas próprias por cada receptor.

• Reputação do domínio: relaciona-se à identidade de envio e ao histórico. Separar marketing em um subdomínio facilita a gestão, mas não cria uma barreira absoluta de reputação entre ele e o domínio principal.
• Reputação do IP: relaciona-se ao endereço do servidor remetente. Hospedagens compartilhadas, como algumas configurações de cPanel ou GoDaddy, podem compartilhar IPs com outros clientes. Abuso de terceiros pode afetar o IP comum, mas não gera automaticamente uma listagem para todos os domínios.

Avalie a qualidade e a gestão do provedor SMTP. Um IP dedicado pode ser adequado a certos volumes, mas custa e exige manutenção de histórico; em baixo volume, não é necessariamente melhor que um pool compartilhado bem administrado. Retomamos essas opções na seção do TrekMail.

Etapa 3 - Cuidados com a infraestrutura

Autenticação e reputação são importantes, mas a configuração do servidor também merece revisão em 2026. DNS reverso e TLS podem fazer parte dos requisitos do receptor; confirme as políticas relevantes em vez de presumir uma rejeição idêntica em todos os serviços.

Registros PTR e DNS reverso

O IP remetente deve ter um registro de DNS reverso, PTR, apontando para um hostname apropriado. A confirmação FCrDNS exige também que a consulta direta A ou AAAA desse nome retorne o IP correspondente. Em um VPS novo, confira ambos com o responsável pelo IP. A referência a uma correção de 10 minutos é ilustrativa: acesso ao provedor e atualização do DNS podem levar mais tempo.

Criptografia TLS

TLS protege o transporte entre servidores que o negociam, não oferece criptografia de ponta a ponta por si só. Verifique os requisitos e o uso real de TLS nos fluxos SMTP; a ausência pode afetar aceitação e proteção conforme a política. Confirme também a configuração aplicável no TrekMail, sem presumir proteção em todas as conexões. Consulte o guia de verificação do status DNS e os registros do transporte.

Diferenças entre Gmail, Outlook e Yahoo

SPF, DKIM e DMARC ajudam a estabelecer uma base técnica, mas não garantem entregabilidade em nenhum dos três grandes provedores. Cada serviço usa políticas e sinais próprios. Separe o diagnóstico por provedor, mesmo quando a autenticação parece correta.

Google (Gmail)

O Google considera sinais dos usuários e reputação do domínio, entre outros fatores. Não rastreia taxas de abertura como as métricas usadas por plataformas de marketing. Não há uma fórmula pública que transforme cada abertura, exclusão ou resposta em uma mudança de posicionamento.

Uma ferramenta útil é o Google Postmaster Tools, que pode mostrar a taxa de spam e categorias de reputação, como Alta, Média, Baixa e Ruim. Os dados dependem de volume, disponibilidade e atrasos. Uma revisão semanal ajuda, mas não é o único recurso nem garante antecipar todos os bloqueios.

A categoria Promoções é uma parte legítima da caixa de entrada, não spam. Envie conteúdo que o público pediu e facilite o cancelamento da inscrição. Não presuma que abrir, apagar ou responder mova automaticamente uma mensagem entre categorias.

Consulte as diretrizes oficiais do Google para remetentes para confirmar requisitos, métricas e escopo atuais.

Microsoft (Outlook / Office 365)

A Microsoft aplica políticas técnicas e controles de reputação próprios. Enviar 1,000 mensagens no dia 1 de um servidor novo pode gerar limitações, mas respostas 451 ou 421 têm várias causas e não são uma consequência garantida desse volume. Aumente o envio conforme a demanda legítima e as respostas observadas.

O Microsoft SNDS, Smart Network Data Services, oferece dados sobre IPs dentro de seu escopo, conforme acesso autorizado e disponibilidade. Não representa uma visão completa de todos os serviços da Microsoft.

Outro risco é a detecção de namespace mining, associada a tentativas de envio para muitas contas inexistentes. Listas antigas merecem revisão, mas uma alta taxa de falhas não prova essa detecção nem que o bloqueio será mais rápido que no Google. Suprima endereços permanentemente inválidos confirmados e investigue rejeições por política separadamente.

Veja as regras de aquecimento de domínio do TrekMail e adapte o ritmo ao ambiente.

Yahoo / AOL

O Yahoo dá atenção às denúncias de spam. Entender o denominador da métrica é essencial para não subestimar o problema.

Consulte o Yahoo Sender Hub para orientações e ferramentas disponíveis aos remetentes.

A taxa considera mensagens entregues na caixa de entrada, não o total enviado. Em um exemplo simplificado, de 1,000 mensagens, 900 vão para spam, 100 chegam à caixa de entrada e 1 é denunciada: a taxa seria 1% (1/100), não 0.1% (1/1000). Um posicionamento ruim pode ampliar o peso relativo das denúncias, mas o exemplo não prevê uma espiral inevitável nem a decisão sobre cada mensagem.

Se a situação piorar no Yahoo, revise ou pause as campanhas afetadas, verifique autenticação e trate denúncias válidas com supressão no fluxo apropriado. O Sender Hub orienta procedimentos e recursos; não é um mecanismo de reativação automática de pessoas que reclamaram.

Medidas iniciais em 24 horas

Se a entregabilidade está comprometida, estas medidas ajudam a organizar o trabalho de hoje. A janela é ilustrativa, não um prazo garantido de recuperação. Ajuste a ordem à gravidade e às evidências de cada fluxo.

Consulte a lista de verificação de 30 minutos para melhorar a entregabilidade. Abaixo está uma versão para o diagnóstico inicial:

Passo 1 - Conter os danos

Se a taxa de denúncias ultrapassar 0.3% na métrica relevante, revise e considere pausar o marketing afetado. Mensagens transacionais, como redefinições de senha, faturas e confirmações, devem continuar apenas quando legítimas e esperadas; não são imunes a filtragem. Antes de retomar campanhas, corrija as causas, pois a queda do percentual sozinha não demonstra recuperação.

Passo 2 - Verificar listas de bloqueio

Consulte o IP remetente no MXToolbox e confirme diretamente no Spamhaus eventuais listagens. Uma ocorrência na SBL pode afetar receptores que a utilizam, mas não significa bloqueio mundial. Identifique o IP e o escopo reais, resolva a causa e siga o procedimento de remoção aplicável.

Passo 3 - Revisar o DNS

Use um validador, como o Email Health Check do MXToolbox, e procure:

• SPF PermError, que pode resultar de ultrapassar o orçamento de 10 consultas ou de outros erros de avaliação.
• Seletor DKIM ausente, chave incorreta ou assinatura inválida.
• Registro DMARC ausente ou política p=none sem acompanhamento. Essa política é válida; uma mudança exige inventário, testes e plano de reversão.
• Falhas de alinhamento DMARC nos relatórios agregados configurados, lembrando que sua cobertura depende dos receptores.

Veja as perguntas frequentes sobre e-mails no spam e o guia de diagnóstico de erros de envio para interpretar respostas específicas.

Passo 4 - Cuidar da lista

A qualidade da lista influencia a entregabilidade. Remova endereços confirmados como permanentemente inválidos, mas não trate toda rejeição permanente por política como conta inexistente. Reavalie também assinantes inativos: seis meses sem abertura é um exemplo para análise, não um critério universal de exclusão, pois rastreamento e privacidade limitam essa informação. Considere consentimento, atividade real e preferências.

Estratégia de prevenção

O diagnóstico inicial pode reduzir problemas imediatos; a prevenção exige acompanhamento contínuo. Estas três práticas ajudam a manter o controle, sem prometer recuperação rápida ou proteção permanente contra spam e bloqueios.

Separação por subdomínio

Um subdomínio de marketing, como @marketing.yourdomain.com ou @newsletter.yourdomain.com, facilita separar fluxos da comunicação corporativa. Não garante que o domínio principal ou os e-mails do diretor aos investidores fiquem imunes: receptores podem agregar reputação por domínio organizacional ou IP.

A separação também permite políticas DMARC e monitoramento específicos quando configurados corretamente. Verifique o domínio efetivamente usado no envelope e o alinhamento relaxado ou estrito; mudar apenas o From visível não separa todas as dimensões.

Aquecimento de IP

Um IP novo pode não ter histórico suficiente. Como exemplo, 20 mensagens no dia 1 e 40 no dia 2, com duplicação a cada poucos dias, ilustram uma subida gradual ao longo de 4-6 semanas. Não é uma receita universal nem uma previsão de bloqueio no dia 3: ajuste o ritmo ao volume esperado, aos destinatários e às respostas, em vez de dobrar automaticamente.

Veja a programação nas regras de aquecimento de domínio do TrekMail.

Acompanhamento semanal

Inclua o Google Postmaster Tools na rotina semanal, quando houver dados. Uma mudança de Alta para Média pode merecer investigação, mas não prevê necessariamente um bloqueio. Consulte o guia de monitoramento da entregabilidade para uma rotina ilustrativa de cerca de 10 minutos por semana, complementada por registros e alertas.

Onde o TrekMail se encaixa na infraestrutura de e-mail

Muitos operadores comparam duas alternativas, cada uma com custos e responsabilidades próprios.

Opção A: cobrança por usuário. Para Google Workspace ou Microsoft 365, a faixa de $6-$30 por usuário ao mês é uma referência do texto de origem, não uma cotação atual de todos os contratos. Uma agência com 50 clientes e 10 usuários em cada um pode ter custos expressivos. Compare os planos atuais e os recursos incluídos antes de decidir.

Opção B: e-mail da hospedagem compartilhada. Alguns serviços de cPanel, GoDaddy ou Bluehost incluem e-mail no pacote. Isso pode envolver IP compartilhado e exposição ao histórico de outros remetentes, dependendo da arquitetura. Abuso de terceiros não coloca automaticamente todos em listas de bloqueio, mas a gestão do serviço importa.

O TrekMail propõe uma alternativa para operadores que precisam administrar vários domínios e separar hospedagem de caixas postais do transporte de saída.

Modelo de preço fixo

O modelo descrito cobra pela plataforma e oferece armazenamento compartilhado entre domínios, dentro das condições do plano, em vez de cobrar apenas por usuário. Ter 5 ou 500 usuários não implica o mesmo preço em qualquer plano: limites de usuários, domínios, armazenamento e envio ainda precisam ser respeitados.

• Free: o retrato do texto de origem indica até 10 domínios, 10 usuários por domínio e 5GB de armazenamento compartilhado, com SMTP próprio e sem cartão de crédito. Confirme disponibilidade e condições atuais.
• Starter ($3.50/mês ou $42/ano): o retrato indica 50 domínios, 100 usuários por domínio e 15GB compartilhados, SMTP gerenciado e ferramenta de migração IMAP no servidor. Verifique os recursos e limites atuais.
• Pro ($8/mês ou $96/ano): o retrato indica 100 domínios, 300 usuários por domínio e 50GB compartilhados, limites de envio maiores, encaminhamento com SRS, ferramenta de migração e suporte prioritário. Confirme as condições vigentes.
• Agency: o retrato apresenta 1,000+ domínios e 200GB+ compartilhados para prestadores com grandes carteiras de clientes. Capacidade e condições dependem da oferta atual.

Use seu próprio SMTP

Essa opção permite separar o transporte de saída da hospedagem IMAP, do armazenamento e da gestão das caixas no TrekMail. Conforme a configuração e o plano, você pode conectar um provedor SMTP próprio, como Amazon SES, SendGrid ou Mailgun.

Os receptores avaliam os IPs efetivamente usados pelo provedor SMTP, além de outros sinais. Uma conta no SES não fornece automaticamente IP dedicado, pool privado ou isolamento completo; desempenho e custo dependem da configuração e do volume. Trocar uma chave de API altera credenciais, não o IP remetente nem a causa de um bloqueio. Investigue o abuso ou a falha real e ajuste legitimamente o transporte quando necessário, sem precisar tratar a hospedagem das caixas como a mesma configuração.

Consulte a documentação de SMTP próprio para a configuração completa.

Assistente de DNS

O assistente do TrekMail pode gerar recomendações de SPF, DKIM e DMARC com base nas respostas sobre seu envio. Revise todos os serviços autorizados, a publicação externa e os caches, além do orçamento de 10 consultas SPF. A ferramenta não elimina cálculos e validação quando necessários nem garante economia suficiente para pagar a assinatura.

Migração no servidor

A ferramenta descrita copia mensagens e pastas acessíveis diretamente do servidor de origem por IMAP, em vez de exigir movimentação manual no cliente durante, por exemplo, três horas. A duração é ilustrativa. Valide acesso e credenciais seguras, confira contagens, pastas e indicadores, faça sincronização complementar e testes conforme necessário. Isso não migra DNS, aplicativos ou reputação nem garante ausência de perda ou interrupção.

Catch-all e encaminhamento com SRS

Quando configurado, o catch-all direciona mensagens para endereços desconhecidos do domínio a uma caixa escolhida. Pode ajudar com erros de digitação e endereços antigos, mas continua sujeito a filtros, cotas e regras de roteamento; nem toda mensagem será aceita.

No encaminhamento, SRS (Sender Rewriting Scheme) reescreve o remetente do envelope SMTP, refletido no Return-Path, para um domínio do encaminhador. Isso pode permitir SPF para esse domínio, mas não restaura o alinhamento SPF com o From original. Uma assinatura DKIM original ainda válida e alinhada pode preservar DMARC; ARC e políticas locais do receptor podem influenciar o tratamento, sem garantia de entrega.

O essencial sobre entregabilidade de e-mail

Entregabilidade de e-mail envolve infraestrutura, reputação, destinatários e conteúdo. Começa pela revisão de autenticação e DNS, passa pelos IPs usados e depende das políticas de cada receptor. Listas consentidas, mensagens desejadas e acompanhamento regular ajudam a manter a caixa de entrada, incluindo suas categorias legítimas, sem garantir posicionamento.

Muitos problemas podem ser diagnosticados e corrigidos, mas a recuperação da reputação tem prazo e resultado incertos. Entender SPF, DKIM e DMARC facilita o trabalho; interromper as causas de abuso e revisar a lista são passos importantes. Mesmo uma infraestrutura bem configurada exige manutenção e monitoramento contínuos.

Para quem administra vários domínios, o TrekMail reúne um modelo de preço fixo, assistente de DNS, SMTP próprio e migração no servidor conforme o plano. Compare os recursos e limites atuais com as necessidades do seu ambiente, sem presumir que a plataforma assume todas as responsabilidades de envio.

Para cuidar da identidade de envio, consulte os guias de reputação de domínio e reputação do remetente. Veja a opção gratuita e suas condições atuais em trekmail.net.