Como sair de uma lista negra DNS
Uma lista negra DNS — também chamada DNSBL ou blocklist — é uma lista publicada de endereços IP ou domínios que os servidores de correio consultam em tempo real para decidir se aceitam, limitam ou rejeitam o correio recebido. Entrar nela costuma significar que os seus devolvidos já começaram; sair não é um único botão, porque cada lista tem o seu próprio motivo de inclusão, a sua própria via de remoção e a sua própria ideia de prova. Este artigo percorre o processo pela ordem que resulta: confirme exatamente o que está listado, corrija a causa antes de pedir seja o que for, use o mecanismo de remoção de cada lista e depois aqueça e monitorize para não voltar à lista na semana seguinte. Comece por executar o verificador de listas negras sobre o seu IP de envio e o seu domínio, e leia com o resultado aberto.
Passo 1: Confirme o que está listado, e por quem
A sua primeira prova é o próprio devolvido. Leia a rejeição SMTP completa, não uma captura reencaminhada: normalmente indica o sistema recetor, a lista exata que consultou, o endereço listado e um código de referência ou motivo. Trate os resultados dos agregadores como um mapa, não como a inclusão em si, e confirme depois cada correspondência na consulta do próprio operador da lista. Execute o verificador de listas negras para cada IP a partir do qual envia de facto — incluindo o relay ou smart host por onde o seu correio sai, que pode não ser o servidor que considera «o servidor de correio» — e para o domínio do seu endereço From e dos seus links. Anote o nome da lista, o item listado, a data de inclusão se for mostrada e o motivo declarado antes de mudar seja o que for.
Separe as inclusões de IP das de domínio, porque têm donos e correções diferentes. As listas baseadas em IP, como a Spamhaus SBL e XBL ou a Barracuda Reputation Block List, seguem a máquina emissora: a correção vive na configuração do servidor, na limpeza do compromisso e no comportamento de envio. As listas baseadas em domínio, como a Spamhaus DBL ou a SURBL, seguem um domínio que apareceu no corpo das mensagens ou em endereços de remetente, pelo que um servidor perfeitamente limpo pode continuar bloqueado porque uma página comprometida, um redirecionador ou uma campanha antiga colocou o domínio no spam. Em alojamento partilhado ou nos IP partilhados de um fornecedor de correio, a inclusão pode nem sequer ser sobre si: nesse caso, o seu fornecedor é quem deve remediar e pedir a remoção, e o seu trabalho é entregar-lhe a referência exata da inclusão e perguntar se mudá-lo para um IP limpo é adequado enquanto trabalha.
Por fim, distinga uma inclusão por abuso de uma por política. Uma entrada na Spamhaus PBL, por exemplo, costuma significar que não se espera que aquele intervalo IP envie correio diretamente para a internet de todo — é uma afirmação sobre o intervalo, não uma acusação de que enviou spam. Apresentar um recurso por abuso contra uma inclusão por política desperdiça o seu único pedido claro; a correção certa é enviar através do relay autorizado do seu fornecedor, ou pedir-lhe que corrija os dados de política do intervalo. Saber que tipo de inclusão tem decide tudo o que se segue.
Passo 2: Corrija a causa raiz antes de pedir seja o que for
Nenhum pedido de remoção é credível enquanto a causa continuar ativa. Trabalhe primeiro as causas técnicas: um relay aberto ou um proxy aberto através do qual estranhos podem enviar, uma caixa de correio, site ou servidor comprometido que envia correio que nunca escreveu, um formulário vulnerável que reencaminha submissões para endereços arbitrários, palavras-passe fracas ou reutilizadas nas contas de correio e filas de saída cheias de correio que não reconhece. Pare o envio, rode as credenciais, corrija ou restaure o componente comprometido, feche o relay e guarde provas de quando o abuso cessou — marcas temporais, registos de fila e a alteração que fez. Os operadores de listas conseguem muitas vezes ver se o tráfego cessou de facto, e um pedido que afirma uma correção que os dados contradizem é a via mais rápida para uma recusa.
Trabalhe depois as causas de comportamento de envio, que listam com a mesma fiabilidade. Enviar para uma lista comprada, raspada ou com anos, ignorar devolvidos e cancelamentos, picos súbitos de volume a partir de um IP frio e campanhas que geram queixas voltarão a listar um servidor tecnicamente perfeito. Limpe a lista, suprima cada devolvido duro e cada reclamante, honre os cancelamentos prontamente e pause por completo os envios em massa até a inclusão estar resolvida. Se um cliente, revendedor ou afiliado enviou o correio problemático através do seu sistema, suspenda esse remetente e prepare-se para o dizer: «arranjámos o nosso servidor» não é uma resposta quando a prova do operador aponta para a campanha de uma conta.
Feche com a autenticação, porque uma autenticação desalinhada causa inclusões e enfraquece o seu pedido de remoção. O SPF deve autorizar os IP que realmente enviam pelo domínio, o DKIM deve assinar com uma chave que os recetores possam verificar e o DMARC deve passar com alinhamento com o domínio From visível — verifique os três com o verificador de entregabilidade e leia os relatórios agregados no analisador de relatórios DMARC para encontrar remetentes de que se esqueceu. Adicione DNS inverso correspondente e um nome HELO consistente enquanto está nisso. Um pedido de remoção vindo de um domínio cuja própria autenticação está quebrada lê-se, para o revisor, como um problema que ainda não terminou.
Passo 3: Use a via de remoção de cada lista — não são intermutáveis
Algumas listas são de self-service depois de corrigida a causa. A Spamhaus encaminha as consultas de reputação de IP e domínio e os passos de remoção aplicáveis através do seu próprio verificador e das suas FAQ; as inclusões por máquinas exploráveis podem muitas vezes ser removidas pelo operador do endereço assim que a infeção desaparece, enquanto o formulário de remoção da Barracuda pede o IP do servidor, um email e telefone contactáveis e um motivo — submeta-o uma só vez, com uma explicação específica, porque a Barracuda afirma que pedidos sem informação válida, e pedidos duplicados, são ignorados. Onde um formulário oferece um campo de texto livre, esse campo é o pedido: o que aconteceu, quando parou e o que mudou, em poucas frases factuais.
Outras inclusões não pode removê-las você de todo. Algumas expiram automaticamente quando param os relatórios que as desencadearam, e pedir antes não muda nada a não ser as suas próprias notas. As inclusões de investigação mais sérias só são removidas a pedido do proprietário da rede, pelo que a sua via passa pela mesa de abusos do seu ISP ou fornecedor de alojamento, com a referência da inclusão anexada. E alguns bloqueios nem sequer são inclusões públicas DNSBL: a Microsoft, por exemplo, mantém os seus próprios sistemas de remetente — use o portal de remoção indicado na rejeição se for dirigido para lá, e os dados SNDS da Microsoft para ver como os seus IP lhe parecem — em vez de andar à procura de uma lista pública que nunca foi o que o bloqueava.
Seja qual for a via, escreva o pedido como um relatório de incidente, não como uma súplica. Indique o IP ou domínio listado, a lista, quando soube, a causa raiz que encontrou, a remediação concreta e a sua data, e a monitorização que implementou. Use um endereço de contacto num domínio que ainda receba correio e guarde os números de referência. Se o operador pedir mais provas, envie exatamente essas provas. Um vago «por favor removam-nos, somos uma empresa legítima» não responde a nenhuma das perguntas do revisor e é o motivo mais comum para uma inclusão removível continuar de pé.
A armadilha da remoção paga — as listas legítimas não cobram
Esta é a regra que poupa dinheiro: nenhuma lista negra importante e legítima cobra uma taxa para o remover. A remoção na Spamhaus, Barracuda, SpamCop e no portal da Microsoft é gratuita. Quem oferecer remoção garantida ou instantânea mediante pagamento está, na melhor das hipóteses, a submeter o mesmo formulário gratuito que você pode submeter — nenhum terceiro pode comprar, influenciar ou acelerar a decisão de um operador — e, na pior, a ficar com o seu dinheiro por nada. Um pequeno número de listas obscuras exige de facto pagamento pela remoção; essa exigência é em si o sinal. Os grandes sistemas recetores não dependem de listas que vendem a remoção, pelo que pagar não compra nada que os recetores alguma vez notem.
As outras armadilhas são gratuitas e igualmente caras. Submeter antes de a correção estar terminada costuma produzir uma nova inclusão, e pedidos prematuros repetidos podem custar-lhe o acesso à remoção self-service. Submeter o mesmo pedido vezes sem conta «para dar sorte» pode fazê-lo ser ignorado. E fugir a uma inclusão saltando para um IP novo ou um domínio parecido sem corrigir a causa é lido pelos operadores como um padrão snowshoe — o comportamento de um remetente que distribui o abuso para fugir à reputação — que pode transformar uma inclusão removível numa outra mais ampla e dura. Não há atalho que as pessoas que gerem as listas já não tenham descontado no seu processo.
Depois da remoção: monitorize, aqueça e leia bem uma recusa
A remoção para a rejeição DNSBL; não restaura a reputação que tinha antes, e os sistemas internos dos recetores continuam com os seus próprios relógios. Espere um breve desfasamento enquanto as respostas DNS em cache e as pontuações internas envelhecem, e aqueça depois deliberadamente: retome primeiro com correio essencial e esperado para destinatários envolvidos, mantenha o volume baixo e constante, vigie devolvidos e queixas a cada passo e aumente gradualmente. Lançar a sua maior campanha do ano na primeira manhã limpa é como os operadores ganham uma segunda inclusão — o padrão de tráfego parece exatamente o que causou a primeira.
Transforme o incidente numa rotina de monitorização para que a próxima inclusão seja detetada por si, não pelos seus clientes. Volte a executar o verificador de listas negras regularmente e após qualquer alteração de envio, vigie dados de reputação tipo postmaster e SNDS onde for elegível, continue a ler os relatórios agregados DMARC à procura de remetentes desonestos e inspecione os cabeçalhos de qualquer nova rejeição com o analisador de cabeçalhos para ver que sistema objetou e porquê. A maioria das segundas inclusões é visível nestes dados dias antes de se tornarem devolvidos.
Se um pedido for recusado, leia a recusa como instruções. «Provas insuficientes» significa que a sua remediação foi afirmada, não mostrada — responda com registos, datas e a alteração específica. «Atividade ainda observada» significa que algo continua a enviar; acredite, e vá à caça em vez de discutir. «Contacte o seu fornecedor» significa que a inclusão não é sua para remover, e mais pedidos ao operador não a moverão. Corrija a falha indicada, espere até os dados o apoiarem e submeta uma vez mais com as novas provas. Uma recusa lida com cuidado é normalmente a descrição mais curta disponível do trabalho restante.