Você criou uma lista de emails e lançou uma campanha. Depois, as aberturas caíram e as devoluções aumentaram. Na semana seguinte, muitas mensagens foram para o spam do Gmail, sem uma causa clara. Ter @ e domínio não basta para validar um endereço, e o fato de ele ter funcionado três meses atrás não garante que continue ativo. A deterioração de 2 a 3 por cento ao mês citada no artigo é uma referência aproximada: a evolução real depende da lista, e problemas de entrega podem ter várias causas.
A verificação de listas de emails avalia os endereços antes do envio, além da sintaxe e da existência do domínio. O artigo descreve 25 sinais, incluindo DNS, consultas SMTP e heurísticas de risco. SPF do domínio destinatário não comprova alinhamento do remetente, e heurísticas não identificam com certeza armadilhas de spam. O objetivo é fornecer uma pontuação para apoiar decisões sobre manutenção, revisão e exclusão.
Verificar endereços pode contribuir para a higiene da lista. Não substitui consentimento, relevância, tratamento de devoluções e reclamações nem garante reputação ou chegada à caixa de entrada.
Como listas desatualizadas podem afetar a entrega
Provedores como Google, Microsoft, Yahoo e Apple podem considerar devoluções, reclamações e sinais de interação, conforme seus sistemas. Endereços inválidos podem prejudicar uma campanha, mas os efeitos não seguem uma fórmula universal.
Primeiro, as devoluções permanentes podem aumentar. Uma resposta 5xx não significa sempre que a caixa não existe: também pode indicar política ou outro erro permanente. Taxas acima de 2 por cento ou 5 por cento são referências de alerta no artigo, não limites universais que determinam automaticamente a reputação.
Segundo, podem existir armadilhas de spam. Algumas usam endereços abandonados e reaproveitados; outras usam endereços que nunca pertenceram a uma pessoa. Listas compradas ou coletadas por raspagem exigem especial cuidado, mas a verificação não fornece consentimento nem uma identificação confiável de todas as armadilhas. O efeito na reputação depende do contexto.
Terceiro, as métricas de interação podem piorar. Endereços inativos não geram interação, e a composição da lista pode alterar taxas de abertura e clique. Esses sinais têm limitações de medição e não demonstram, sozinhos, a causa de uma mudança na entrega.
O que a verificação de listas avalia
A avaliação não precisa se limitar a válido ou inválido. O artigo atribui ao TrekMail 25 verificações em etapas, com uma pontuação resultante. Confirme o conjunto disponível e suas regras na implementação atual.
Etapa 1: verificações eliminatórias
No modelo descrito, determinados resultados zeram a pontuação e classificam o endereço como inválido. Essa classificação é uma decisão do produto e da política, não uma prova universal de que uma caixa não pode receber mensagens.
| Verificação | O que avalia | Por que importa |
|---|---|---|
| Sintaxe | Validação conforme RFC 5321 e regras do produto | Identifica erros de formato; confirme o tratamento de casos especiais |
| Punycode e caracteres semelhantes | Sinaliza possíveis homógrafos em domínios internacionalizados | Ajuda na revisão; um IDN legítimo não é necessariamente um ataque |
| Domínios descartáveis | Compara com 5,300+ provedores citados no artigo | Guerrilla Mail, Temp Mail e Mailinator podem exigir uma política específica de uso |
| Lista de bloqueio administrativa | Consulta os bloqueios definidos na sua conta | Aplica sua política para endereços já sinalizados |
| Registro MX | Consulta o DNS do domínio para localizar servidores de email | Ausência de MX pode permitir fallback implícito para A/AAAA; null MX indica que o domínio não recebe email |
| IP do MX roteável | Verifica se o endereço é público, não privado ou reservado | Identifica destinos como 127.0.0.1 ou faixas RFC 1918 |
| Supressão por devolução | Consulta devoluções permanentes anteriores na conta | Evita repetir envios indevidos, conforme o motivo e a política de supressão |
Após as sete verificações eliminatórias, o modelo inicia a etapa 2 com pontuação 100. Confirme como exceções e resultados inconclusivos são tratados.
Etapa 2: sinais de risco e pontuação
Alguns sinais descontam pontos; outros apenas acrescentam informações. A categoria final expressa o modelo de risco, não identidade ou autorização para contato.
| Verificação | O que avalia | Efeito descrito |
|---|---|---|
| Endereços de função | Sinaliza info@, support@ e admin@ | Informativo, sem penalidade |
| Sequências aleatórias | Identifica padrões como xk7q9z@ | -15 pontos no modelo |
| Sugestões de correção | Sinaliza gmial.com, outlok.com e yaho.com | -10 pontos no modelo |
| Endereçamento com sinal de mais | Detecta user+tag@, um recurso legítimo de aliases | -5 pontos na regra descrita; não prova risco |
| DNSBL | Consulta Spamhaus e outras listas conforme o escopo suportado | -30 pontos no modelo |
| Idade do domínio por RDAP | Consulta a data de registro | -10 se tiver menos de 1 ano no modelo |
| Gravatar | Procura um perfil associado ao endereço | Informativo; não comprova identidade |
| Nome no endereço | Procura um nome reconhecível na parte local | Informativo; não comprova identidade |
| Linguagem ofensiva | Sinaliza expressões na parte local | Informativo |
| Site do domínio | Verifica se há um site acessível | Informativo; não comprova legitimidade |
| Risco de armadilha de spam | Aplica heurísticas a características do endereço | Desconto variável; detecção não conclusiva |
| Registro SPF | Verifica publicação de SPF no domínio | Informativo, sem comprovar recebimento ou alinhamento do envio |
| Registro DMARC | Verifica publicação de política DMARC | Informativo, sem comprovar recebimento |
| Provedor gratuito | Sinaliza endereços Gmail, Yahoo e Outlook | Informativo |
| Domínio em vazamentos | Consulta bases conhecidas conforme disponibilidade | Informativo; não comprova comprometimento da caixa |
| Consulta SMTP | Conecta ao servidor e observa a resposta ao destinatário | Aceitação não prova existência nem entrega; catch-all e greylisting podem deixar o resultado inconclusivo |
| Bônus por domínio próprio | Domínio não gratuito com MX + SPF + DMARC no modelo | +5 pontos; não comprova alinhamento ou consentimento |
Categorias da pontuação
O modelo classifica os resultados nas categorias abaixo. Elas orientam a revisão, sem garantir atividade da caixa ou entrega.
| Categoria | Pontuação | Interpretação | Ação sugerida |
|---|---|---|---|
| Safe | 90 a 100 | Poucos sinais de risco no modelo, sem prova de identidade ou atividade | Enviar apenas com autorização, relevância e monitoramento |
| Valid | 60 a 89 | Resultado favorável com alguns sinais a avaliar | Confirmar permissão e monitorar |
| Risky | 20 a 59 | Vários alertas; resultado pode ser inconclusivo | Revisar manualmente ou excluir conforme política |
| Invalid | 0 a 19 | Falha eliminatória ou acúmulo de penalidades do modelo | Suspender envio e avaliar o motivo |
A pontuação oferece mais contexto que um resultado binário. Um endereço com 62 ou com 85 e sinal de função pode exigir decisões distintas conforme o uso. Não troque um endereço transacional confirmado por uma estimativa, nem use uma pontuação favorável como autorização para campanhas B2B ou contato pessoal.
Modo Quick e modo Deep
O artigo descreve dois modos para escolher a profundidade da avaliação. Confira recursos e cobrança atuais.
O modo Quick reúne a etapa 1 e verificações selecionadas da etapa 2, como sintaxe, descartáveis, MX, função, padrões aleatórios, erros de digitação, aliases com sinal de mais e supressão. MX exige consulta DNS, portanto não é uma operação sem rede. O custo citado é 1 crédito por endereço; latência em milissegundos é uma referência, não garantia para cadastros ou webhooks.
O modo Deep inclui o conjunto anunciado de 25 verificações, com SMTP, DNSBL, RDAP, Gravatar, heurísticas de armadilhas e referências a vazamentos. O custo citado é 2 créditos por endereço. Pode apoiar auditorias e campanhas autorizadas. Verificar uma lista comprada não cria consentimento nem torna seu uso automaticamente permitido.
| Recurso | Quick | Deep |
|---|---|---|
| Créditos por endereço | 1 | 2 |
| Verificações | Conjunto básico descrito | 25 anunciadas; conferir implementação |
| Consulta SMTP | Não no modo descrito | Sim, com possíveis resultados inconclusivos |
| Consulta DNSBL | Não | Sim, conforme cobertura |
| Idade do domínio por RDAP | Não | Sim, conforme disponibilidade |
| Heurísticas de armadilhas | Não | Sim, sem identificação garantida |
| Velocidade | Milissegundos no cenário descrito | 1 a 3 segundos no cenário descrito |
| Uso possível | Cadastros e revisões básicas | Campanhas autorizadas, importações e auditorias |
Verificação em lote
A consulta individual atende cadastros e integrações. Para listas de 10,000 ou 50,000 endereços, um processo em lote pode facilitar a revisão antes de uma campanha autorizada.
O artigo informa até 50,000 endereços por tarefa no TrekMail, enviados por CSV, XLSX ou API. Descreve eliminação de duplicados para evitar cobrança repetida na mesma tarefa; confirme limites e regras atuais.
A arquitetura descrita separa leitura do arquivo, consulta antecipada de DNS por domínio e processamento em lotes. A distribuição round-robin busca repartir a fila entre contas, e os lotes podem executar verificações em paralelo conforme a capacidade disponível.
O painel descrito mostra progresso e contagens por categoria: safe, valid, risky e invalid. Após a conclusão, a exportação CSV pode filtrar categorias. Use os segmentos para revisão, sem tratar safe como prova de permissão para envio.
O artigo informa exclusão automática dos resultados após 15 dias. Isso não demonstra que todos os logs ou backups sigam o mesmo prazo; confira a política de retenção aplicável.
Integração pela API
A API REST descrita permite operações de verificação conforme os endpoints disponíveis. Use um token bearer com os escopos necessários: verify:read para resultados e verify:write para solicitações. Os exemplos abaixo reproduzem o snapshot, inclusive sequências de escape que precisam de revisão antes do uso.
Verificação de um endereço
curl -X POST https://trekmail.net/api/v1/verify -H "Authorization: Bearer tm_live_your_token" -H "Content-Type: application/json" -d \x27{"email": "user@example.com", "mode": "deep"}\x27O exemplo de resposta inclui pontuação, categoria e verificações executadas. O estado SMTP accepted não comprova uma caixa real ou entrega futura:
{
"status": "safe",
"score": 95,
"mode": "deep",
"checks": {
"syntax": true,
"mx": true,
"disposable": false,
"role_based": false,
"gibberish": false,
"dnsbl_listed": false,
"domain_age_days": 365,
"smtp_status": "accepted"
}
}Solicitação em lote
curl -X POST https://trekmail.net/api/v1/verify/bulk -H "Authorization: Bearer tm_live_your_token" -H "Content-Type: application/json" -d \x27{
"emails": ["a@example.com", "b@test.com"],
"name": "March campaign cleanup",
"mode": "deep"
}\x27O fluxo descrito devolve um identificador de tarefa. Consulte o endpoint de status ou configure um webhook, quando suportado. Resultados paginados e exportação CSV por status dependem dos endpoints e permissões atuais.
Limites citados: 60 consultas individuais por minuto, 10 solicitações em lote por minuto e 120 consultas de status por minuto. Confirme os limites vigentes.
O artigo também descreve ferramentas MCP (Model Context Protocol). O conjunto de oito ferramentas permite operações como consulta, tarefas em lote, créditos e resultados, conforme a implementação. Claude Desktop, Claude Code, Cursor e outros clientes precisam de suporte compatível, credenciais e escopos adequados.
Quando revisar sua lista
A revisão não precisa ser um evento isolado. Pessoas mudam de emprego, abandonam endereços e deixam domínios expirar. A evolução de 95 por cento em janeiro para 85 por cento em junho é ilustrativa, não uma taxa prevista para sua lista.
Antes de campanhas importantes. Considere uma revisão básica quando o segmento for grande ou estiver desatualizado. A taxa de devolução de 5 por cento citada é um alerta ilustrativo; o custo e a profundidade da verificação dependem do risco.
Depois de uma pausa nos envios. O artigo sugere revisão após 90 dias sem contato. Use esse prazo como orientação, confirme permissão para retomar o contato e considere devoluções e histórico de interação.
Ao receber dados externos. Inscrições em eventos e dados de parceiros exigem revisão da origem e das permissões. Listas compradas ou raspadas não ganham autorização com uma consulta Deep. Não use a verificação para justificar envio em massa sem consentimento ou outra base válida aplicável.
Na coleta. A consulta pode ajudar a detectar erros de digitação no cadastro, checkout ou formulário. Trate aliases legítimos e resultados inconclusivos com cuidado; a latência da API varia e a consulta não impede todo dado incorreto.
Periodicamente. Para listas grandes, uma revisão mensal ou trimestral pode fazer sentido conforme atividade, consentimento e risco. Defina o calendário para sua operação, sem considerá-lo uma regra universal.
Créditos e preços
O artigo descreve créditos mensais incluídos nos planos. A coluna de preços abaixo contém registros corrompidos ou incompletos do snapshot e não representa uma tabela válida; confira o preço e os créditos atuais.
| Plano | Preço mensal na fonte | Créditos incluídos / mês | Oferta descrita |
|---|---|---|---|
| Free | -bash | 10 | Conta de hospedagem de email, conforme oferta |
| Starter | 100 | Hospedagem e leitura pela API, conforme plano | |
| Pro | 0 | 300 | API e encaminhamento conforme permissões |
| Agency | 3.25 | 1,000 | API e 1,000 domínios no cenário descrito |
O painel pode oferecer compra de créditos adicionais. Consulte a calculadora da página do Email Verifier para valores atuais por volume; não presuma o mesmo desconto em toda oferta.
No modelo citado, Quick usa 1 crédito e Deep usa 2. Duplicados são removidos dentro da mesma tarefa. O artigo descreve devolução de créditos não processados ao cancelar um lote; confira a regra vigente.
Integração com a hospedagem de email
Ferramentas de verificação de email podem ser independentes da hospedagem. Isso não impede integrações para compartilhar resultados e histórico quando disponíveis.
No TrekMail, o verificador é descrito como parte da plataforma de hospedagem. A integração pode facilitar os fluxos abaixo, sem torná-los exclusivos ou garantir reputação.
Supressão automática por devolução. O fluxo descrito acrescenta devoluções permanentes da conta à lista de supressão, consultada na etapa 1. Confirme o motivo, o tempo de atualização e as regras. Outros serviços também podem integrar histórico de envio quando recebem esses dados.
Proteção no Postfix. O artigo informa sincronização da lista a cada 5 minutos. Não é bloqueio instantâneo: uma atualização pendente ou uma configuração diferente pode alterar o resultado. A supressão no MTA reduz tentativas indevidas conforme as regras, sem garantir que a reputação permaneça intacta.
A oferta integrada pode reunir hospedagem e verificação na mesma conta e painel. Confirme faturamento, credenciais e escopos, evitando conceder permissões além das necessárias.
Segurança e privacidade
Endereços de terceiros podem ser dados pessoais. Avalie finalidade, acesso e retenção na operação de verificação.
- Criptografia TLS descrita para API e painel; confirme configuração e validação dos clientes
- Exclusão automática dos resultados em lote após 15 dias no artigo; logs e backups podem ter políticas distintas
- Recursos para gestão de dados incluem exclusão da tarefa pela API (
DELETE /api/v1/verify/bulk/{jobId}); a função não garante, sozinha, conformidade com o GDPR - Sem armazenamento do conteúdo das mensagens no verificador. O fluxo descrito avalia endereços; confira os demais dados e logs tratados
- Mitigação de análise temporal. O artigo descreve respostas individuais com duração mínima de 200ms; isso não elimina todas as inferências ou ataques de temporização
Experimente a demonstração
A página do TrekMail Email Verifier descreve uma demonstração pública com pontuação e detalhes. Use apenas endereços que você tenha autorização para consultar. Disponibilidade, cadastro, exigência de cartão e tempo de resposta dependem das condições atuais.
O artigo cita uma conta gratuita com 10 créditos mensais e opções para maior volume. O valor Pro de 0/mês está corrompido na fonte e não deve ser usado como preço. Os 300 créditos, a API e a consulta SMTP no Deep também precisam ser confirmados na oferta atual.
Cuide da qualidade e das permissões da sua lista. Revise os endereços antes do próximo envio autorizado.
