Verificar blacklist de email: o que as ferramentas escondem

Verificar blacklist de email significa fazer uma consulta DNS: você pega o IP de envio, inverte os octetos e pergunta a cada lista pública se esse endereço aparece nela neste momento. Uma tabela cheia de linhas verdes e vermelhas responde apenas a essa pergunta estreita. Ela não diz se o Gmail, o Outlook ou um gateway corporativo vai aceitar sua próxima mensagem, e tratar as duas coisas como a mesma pergunta é onde a maioria das linhas do tempo de incidentes dá errado.

Este guia explica o que uma verificação realmente consulta, como executar uma por conta própria com dig, quais códigos de resposta significam "limpo" e quais significam "sua consulta foi recusada", e como ligar tudo isso ao monitoramento para parar de fazer o trabalho à mão às 2 da manhã.

Uma verificação de blacklist é só uma consulta DNS

Toda DNSBL (lista de bloqueio via DNS) funciona do mesmo jeito. Você inverte os octetos do endereço IPv4, acrescenta a zona da lista e pede um registro A. A RFC 5782 define a convenção: para 192.0.2.99 consultado contra bad.example.com, a consulta é 99.2.0.192.bad.example.com. Se o endereço estiver listado, você recebe uma resposta na faixa 127.0.0.0/8. Se não estiver, não recebe registro nenhum.

Esse é todo o mecanismo. As ferramentas web onde você cola um IP estão executando dezenas dessas consultas em paralelo e formatando as respostas.

# O IP 203.0.113.25 está listado na Spamhaus ZEN?
dig +short 25.113.0.203.zen.spamhaus.org A

# Consulta por domínio em uma lista baseada em domínio funciona igual, sem inverter nada:
dig +short example.com.dbl.spamhaus.org A

Saída vazia significa que não está listado. Uma resposta 127.x.x.x significa que está listado, e os últimos octetos indicam qual sublista correspondeu. Rode isso a partir de uma máquina que você controla, usando seu próprio resolver, e você pode automatizar, registrar e gerar alertas.

Verifique o endereço por onde o email sai, não o do seu site

O primeiro erro é consultar o IP errado. Seu site de marketing, sua API e seu relay de envio costumam ser três endereços diferentes. O que importa é o IP que aparece no cabeçalho Received de uma mensagem que de fato chegou a uma caixa de entrada.

Se você envia por um ESP em infraestrutura compartilhada, esse IP não é seu, e a listagem também não é. Se envia a partir de um IP dedicado, ele é inteiramente seu, incluindo tudo o que o antigo ocupante daquela faixa fez.

Pegue o IP de envio de uma mensagem entregue, não de uma configuração no painel. Depois verifique três coisas separadas: o IP de envio, os domínios do envelope e do campo From, e todo domínio que aparece nos seus links, incluindo hosts de rastreamento e de cancelamento de inscrição. Listas baseadas em URI, como URIBL e SURBL, avaliam os links dentro do corpo da mensagem, então um IP limpo não protege uma mensagem que aponta para um domínio listado.

Um resultado limpo de um resolver público pode ser uma recusa disfarçada

Essa é a falha que as páginas genéricas de verificação nunca mencionam. A Spamhaus não responde a consultas que chegam por resolvers públicos ou abertos, e sinaliza isso com um código de retorno em vez de uma listagem. A Spamhaus documenta 127.255.255.254 como código de erro, não como resultado de reputação, e afirma que ele nunca deve ser usado para rejeitar email.

Há duas consequências. Se seu script lê qualquer resposta 127.x como "listado", uma consulta recusada a partir de um resolver de nuvem vai disparar um alerta para uma listagem que não existe. Se ele lê "nenhuma resposta utilizável" como "limpo", você vai deixar passar listagens reais sem perceber, porque a recusa também pode aparecer como resposta vazia ou NXDOMAIN.

A correção é rodar as consultas a partir de um host com resolver recursivo próprio e DNS reverso adequado, ou usar o serviço de consulta gratuito que a Spamhaus indica aos usuários de espelhos públicos. Depois valide a zona antes de confiar nela. A RFC 5782 exige que listas IPv4 tenham uma entrada para 127.0.0.2 e nenhuma para 127.0.0.1, então você pode testar sua configuração assim:

dig +short 2.0.0.127.zen.spamhaus.org A   # deve retornar uma resposta 127.x
dig +short 1.0.0.127.zen.spamhaus.org A   # não deve retornar nada

Se as duas retornarem vazio, o caminho do seu resolver está quebrado ou recusado. Conserte isso antes de ler qualquer resultado dele.

A maioria dos incidentes de entrega não são incidentes de blacklist

Em uma análise de bounces que fazemos antes de qualquer consulta, a primeira pergunta é o que o servidor receptor realmente disse. Uma listagem produz uma rejeição específica. Problemas de reputação nos provedores de caixa de entrada produzem outra, e nenhuma lista pública vai mostrá-los.

A documentação do Google para remetentes é direta sobre isso. Uma resposta 550 5.7.1 pode significar que o IP de envio está em uma lista de suspensão, geralmente por causa de reputação ruim de IP compartilhado, enquanto 5.7.26 aponta para falha de autenticação. Para remetentes em volume, o Google exige SPF, DKIM e DMARC, DNS direto e reverso válidos no IP de envio, TLS e uma taxa de spam abaixo de 0.30% nas Postmaster Tools. Os requisitos de remetente do Gmail recomendam 0.10% como meta.

Leia isso como uma ordem de prioridades. Se o texto do bounce citar uma zona ou URL de DNSBL, o problema é de listagem. Se disser reputação, autenticação ou limite de taxa, uma consulta de blacklist vai voltar limpa, e você terá perdido uma hora confirmando isso.

• Cita uma zona ou URL de DNSBL: você está listado nessa lista específica. Rode a consulta e use a página de remoção da própria lista.

• 550 5.7.1 com texto sobre "reputação de IP": reputação do lado do provedor, geralmente em IP compartilhado. Confira as Postmaster Tools e a tendência de volume e de reclamações.

• 5.7.26: a autenticação falhou. Verifique o alinhamento de SPF, DKIM e DMARC.

• 4.7.28 ou texto sobre taxa: você está enviando rápido demais para sua reputação atual. Reduza a velocidade e aumente o volume gradualmente.

Pare de usar o verificador web pontual como monitoramento

Uma consulta pontual mostra o estado no momento em que você apertou enter. Listagens costumam ser transitórias, e muitas aparecem depois de um pico que você mesmo causou: uma importação fria, um envio de re-permissão, um formulário comprometido que alguém usou para retransmitir spam.

As ferramentas que cobram para "remover você de 100 blacklists" vendem um serviço para um problema que a maioria dessas listas nem tem. Muitas das listas de uma verificação ampla têm impacto desprezível sobre os principais provedores de caixa de entrada, e a remoção costuma ser gratuita e feita na própria página do operador. Perseguir cada linha vermelha consome tempo que deveria ir para as duas ou três listas que seus destinatários realmente consultam.

Ordene as listas pelo tráfego que você envia. Veja quais receptores aparecem nos seus bounces, descubra quais listas esses receptores usam publicamente e monitore essas. O resto é ruído que pode ser revisado mensalmente.

Transforme a verificação em um job agendado com limite de alerta

Esta é a versão mínima que se sustenta. Ela roda a partir de um host com resolver real, valida a zona antes de tudo e distingue três resultados: listado, não listado e consulta recusada.

import socket

def dnsbl(ip: str, zona: str) -> str:
    rev = ".".join(reversed(ip.split(".")))
    try:
        resposta = socket.gethostbyname(f"{rev}.{zona}")
    except socket.gaierror:
        return "nao_listado"
    if resposta.startswith("127.255.255."):
        return "recusado"   # código de erro, não um resultado de reputação
    return f"listado:{resposta}"

# Teste a zona antes de confiar nela (entradas de teste da RFC 5782)
assert dnsbl("127.0.0.2", "zen.spamhaus.org").startswith("listado")
assert dnsbl("127.0.0.1", "zen.spamhaus.org") == "nao_listado"

Rode a cada 15 a 60 minutos por IP de envio e por domínio de envio, registre cada resultado com data e hora, e alerte apenas na transição de nao_listado para listado. Alerte separadamente sobre recusado, porque isso significa que seu monitoramento está cego, não que sua reputação mudou.

Combine isso com os sinais que as listas costumam demorar a refletir. Taxa de reclamação nos painéis do Postmaster, taxa de bounce por domínio receptor e taxa de adiamento por hora mudam antes de uma listagem aparecer, e são os números que dizem se você deve pausar um envio. Se você já envia logs e métricas para uma pilha de monitoramento, o resultado da consulta é apenas mais uma série temporal.

Quatro ferramentas se encaixam nesse fluxo, dependendo de onde está a dor.

O Postmark é apenas transacional, então seus emails de redefinição de senha não dividem o caminho de envio com o disparo de newsletter de outra pessoa. Se suas listagens sempre remetem a um vizinho em infraestrutura compartilhada, separar envio transacional de marketing é a correção estrutural.

O Resend é a opção voltada a desenvolvedores para quem quer uma API limpa e uma superfície pequena para instrumentar. Faz sentido quando a equipe vai escrever as próprias verificações de deliverability de qualquer forma.

O SendGrid tem o histórico mais longo em volume e oferece IPs dedicados, o que significa que a reputação e a exposição a blacklists são só suas. Não faz sentido para quem não tem equipe para o aquecimento e o monitoramento que IPs dedicados exigem.

O Better Stack é a peça para o lado dos jobs agendados: checagens tipo uptime, alertas e roteamento de plantão para o script de consulta acima, para que uma nova listagem chegue a uma pessoa e não a um arquivo de log.

Quando você estiver listado, corrija a causa antes de pedir remoção

Pedir remoção sem identificar a causa raiz compra apenas alguns dias. O operador de uma lista que vê o mesmo endereço voltar com o mesmo comportamento vai listá-lo de novo, e alguns operadores escalam as listagens repetidas.

Trabalhe nesta ordem:

1. Pare ou reduza o envio a partir do IP listado. Mais tráfego ruim prolonga a listagem e gera novas.

2. Leia o registro de listagem do operador. Muitos informam a evidência: um acerto em spam trap, um pico, uma denúncia de relay abusivo.

3. Encontre a origem. Verifique endpoints de formulário em busca de abuso de relay aberto, veja importações recentes de listas e revise qualquer nova integração que começou a enviar na última semana.

4. Corrija a causa e depois use o processo de remoção do próprio operador. Algumas listas expiram listagens automaticamente depois de um período sem atividade.

5. Retome em volume reduzido, começando pelos destinatários mais engajados, e acompanhe a taxa de reclamação e os adiamentos por uma semana.

O DNS reverso ausente é um fator recorrente. O Google inclui registros PTR válidos entre seus requisitos para remetentes, e um IP de envio sem esse registro é lido como de baixa confiança por muitos receptores antes mesmo de o conteúdo ser avaliado.

Monte o fluxo de ciclo de vida em torno do sinal, não da lista

Se seu produto envia emails de ativação, cobrança ou segurança, uma listagem é um incidente de disponibilidade para esses fluxos. Trate-a assim: roteie os emails transacionais por um caminho isolado do volume de marketing e faça a camada de disparo conhecer o estado da entrega, para que um email de ativação travado caia de volta para um aviso dentro do aplicativo.

Essa separação é a parte que vale copiar, mesmo que você escolha fornecedores diferentes. Um evento de blacklist deve mudar para onde a mensagem vai, não fazer a sua lógica de ciclo de vida deixar de funcionar.

O que colocaríamos em prática esta semana

Três coisas, em ordem de retorno. Primeiro, uma consulta agendada com validação de zona e um estado recusado distinto, rodando a partir de um host com resolver próprio. Segundo, a divisão dos bounces por domínio receptor, para saber quais listas importam para o seu tráfego. Terceiro, um runbook escrito que começa pelo texto do bounce e termina na etapa de remoção, para que quem estiver de plantão não precise improvisar.

Qual dos seus domínios de envio você não perceberia estando listado por um dia?