A reputação de um endereço que não se escolhe

Ninguém escolhe um endereço IP. Ele é atribuído a quem o aluga, já carregando uma década de comportamento alheio. Em uma faixa offshore esse histórico costuma ser pior do que a média, por um motivo estrutural, não acidental — e a versão honesta dessa frase é a que nenhum provedor coloca em uma página de produto. A seguir, o que o endereço realmente decide, quem o julga, e a única decisão que pesa mais do que qualquer registro DNS configurado.

O histórico que vem junto com o endereço

Não há novos endereços IPv4 desde 2011. Todo endereço distribuído hoje já foi distribuído antes, muitas vezes mais de uma, e a faixa em que ele está inserido carrega dados de reputação desde antes de a ideia do serviço existir. Quando um provedor atribui um endereço, ele não está cunhando um endereço novo — está reciclando um usado, e o recibo vem com os inquilinos anteriores anexados.

A parte que surpreende é a granularidade. Quase nada na internet julga um endereço isolado. Listas de bloqueio, provedores de e-mail e sistemas de pontuação de fraude trabalham sobre faixas — um /24, às vezes um sistema autônomo inteiro — porque essa é a unidade que um operador controla, e porque quem abusa de um endereço simplesmente passa para o próximo da mesma faixa. Três consequências decorrem disso, e nenhuma delas está sob controle de quem aluga o endereço:

• Os vizinhos definem a reputação. As outras 253 máquinas no mesmo /24 tomam decisões que recaem sobre o endereço alugado, sem que seja possível saber quem são, o que rodam ou quanto e-mail enviam. O histórico herdado é a média deles.
• As listagens sobrevivem aos inquilinos. Uma faixa pode carregar uma entrada muito depois de o cliente que a causou ter sido encerrado, porque a lista não tem como saber que o cliente mudou nem motivo para supor isso.
• Faixas offshore começam mais baixo. Um provedor que não pede identidade atrai, entre clientes honestos, exatamente os clientes que acabam listados — e as listas reagem a isso alargando o alcance de um único endereço para o /24 inteiro, depois para toda a rede. Esse é um custo real da decisão de jurisdição. Ele deveria entrar na decisão, não aparecer como surpresa na primeira fatura.

Duas outras coisas se movem por baixo do endereço, mesmo que ele permaneça o mesmo. Endereços hoje são alugados e transferidos entre organizações, de modo que o registro de uma faixa pode trocar de mãos sem que um único pacote mude de rota — e os dados de reputação, que ficam ligados aos endereços e não ao registro, não acompanham essa papelada. E os bancos de geolocalização atrasam meses. Um endereço movido para Chișinău pode continuar resolvendo para Amsterdã em metade dos bancos comerciais por um trimestre ou mais, o que aparece para um mecanismo antifraude como um endereço holandês numa conexão moldava, pontuando a incompatibilidade. Nenhuma das duas coisas é um defeito. Ambas são o atrito normal de um mercado de endereços que ficou sem estoque há quinze anos.

Nossa própria política de uso aceitável nomeia o mecanismo em vez de escondê-lo: e-mail em massa não solicitado faz a faixa inteira ser colocada em lista negra em poucas horas, e a faixa é compartilhada. É por isso que a regra existe, e por isso a sanção recai sobre a porta, não sobre a conta. Servidores de e-mail e envios em massa com consentimento são explicitamente permitidos — o limite é o consentimento, não o volume.

Seis julgadores, e eles não concordam entre si

“Na lista negra” costuma ser tratado como uma condição única. Na prática são pelo menos seis, decididas por seis partes que usam dados diferentes, publicam quantidades diferentes desses dados e, em dois casos, nunca revelam que tomaram alguma decisão.

Seis partes que julgam um endereço IP, o que cada uma bloqueia, e o que dá para fazer

Quem julga	Como se descobre	Dá para corrigir	O que isso realmente bloqueia
Provedores de e-mail	Um bounce, ou silêncio	Parcialmente	A mensagem cai na pasta de spam ou não chega de jeito nenhum. Aqui a reputação é medida por endereço e por domínio de envio, e as duas são rastreadas separadamente.
Spamhaus e as principais listas públicas	Um bounce citando a lista	Sim	A conexão SMTP, na porta de entrada, antes mesmo de a mensagem ser lida. É o único caso que produz um bounce com um motivo explícito, o que faz dele a falha mais útil que existe.
Listas que cobram para remover	Um bounce, raramente	Não	Na prática, quase nada. Algumas listam um /24 inteiro ou uma rede completa com base em um único remetente, e depois oferecem remoção expressa mediante pagamento. Operadores de qualquer porte não as consultam.
CDNs e firewalls de aplicação web	Uma página de desafio	Não	Os visitantes, com uma página de desafio — ou as próprias requisições de saída para sites atrás de uma dessas proteções. A decisão é tomada sobre a rede, não sobre a máquina.
Pontuação de fraude e pagamento	Não se descobre	Não	Nada visível. Eleva uma pontuação de risco no checkout de outra empresa, silenciosamente, como mais um entre dezenas de fatores. A regra nunca é revelada, e não existe canal de recurso.
Sites que bloqueiam data centers em bloco	Uma recusa nos próprios logs	Não	Requisições que o servidor faz para fora — scrapers, chamadas de API, health checks. Isso não é um problema de reputação. É um problema de categoria: o endereço é de um data center, e o site queria pessoas.

Ao ler a terceira coluna de cima a baixo, o formato do problema aparece. Um dos seis é realmente corrigível por quem administra o servidor, um é parcialmente, e quatro são decisões tomadas em outro lugar sobre uma categoria à qual o endereço pertence. Essa proporção é o argumento para desenhar a arquitetura em torno do endereço em vez de brigar com ele — que é do que trata a última seção.

Por que o e-mail julga com mais rigor, e com mais honestidade

O e-mail é o único dos seis que informa, por escrito, no momento da falha, exatamente o motivo da recusa. Uma página de desafio não se explica. Uma pontuação de fraude nunca vem à tona. Uma mensagem de bounce traz um código, o nome de uma lista e, muitas vezes, uma URL. O e-mail é o julgador mais rigoroso desta página e o único honesto, e essa combinação é o motivo para concentrar ali o esforço de configuração.

DNS reverso, e a metade que todo mundo esquece

Um registro PTR liga o endereço de volta a um nome. Configurá-lo é a metade fácil, e é onde a maioria para. O requisito é ser confirmado no sentido direto: o nome retornado pelo PTR precisa, por sua vez, resolver de volta para o mesmo endereço. O Google define isso como condição para remetentes em massa nesses termos — registros diretos e reversos válidos, com o endereço de envio correspondendo ao endereço do nome de host no PTR. Um PTR apontando para um nome que não resolve para nada, ou para outra máquina, é pior do que nenhum PTR, porque parece configuração errada em vez de omissão. Na nossa rede o registro reverso pode ser definido pelo cliente, o que também significa que pode ser configurado errado por ele; configure antes de a primeira mensagem sair, não depois do primeiro bounce.

SPF, DKIM e DMARC autenticam — eles não avalizam

Os três registros provam que uma mensagem realmente veio de quem afirma tê-la enviado. É só isso que provam. Não são uma carta de recomendação, são um documento de identidade, e um documento de identidade não garante boas-vindas em lugar nenhum. Uma mensagem autenticada vinda de um endereço listado continua sendo uma mensagem autenticada vinda de um endereço listado — será recusada com mais confiança, não com menos. Configure os três porque hoje são um piso mínimo, não um diferencial, e entenda que isso ainda não resolveu nada em termos de reputação.

Há também uma divisão que vale entender antes de gastar uma semana na metade errada. A reputação é rastreada tanto pelo endereço quanto pelo domínio de envio, e os dois são pontuados separadamente. Isso tem uma consequência prática nos dois sentidos: um domínio novo e impecável enviando de um endereço limpo ainda assim não tem reputação nenhuma — não ter reputação não é o mesmo que ter boa reputação, e as primeiras mil mensagens são tratadas de acordo — enquanto um domínio com anos de envios bem-comportados carrega esse histórico mesmo depois de uma troca de endereço. A metade do domínio é a metade portátil, e esse é o verdadeiro argumento para assinar com DKIM no próprio domínio em vez de no domínio que a ferramenta de envio oferece por padrão.

Os números que o Gmail publica, e o que eles implicam

Para remetentes de cerca de cinco mil mensagens por dia ou mais, o Google publica exigências, não sugestões: SPF e DKIM no domínio de envio, DMARC presente — uma política none é aceita — cancelamento de inscrição em um clique para e-mails de marketing e assinatura, e uma taxa de reclamação de spam mantida abaixo de 0,30%, com 0,10% recomendado. Vale a pena converter esses números em algo concreto. Em cinco mil mensagens, 0,30% são quinze reclamações. Quinze pessoas clicando em um botão, num dia em que foi enviada uma lista sobre a qual havia dúvida, é a diferença entre entregue e filtrado, e não é um limite que se descubra por tentativa.

A porta 25 de saída vem bloqueada por padrão na maioria das grandes nuvens, e é por isso que quase ninguém lá chega a descobrir nada disso. Um provedor offshore costuma deixá-la aberta, e isso não é um presente: uma porta aberta numa faixa compartilhada significa que a reputação da faixa está sendo decidida por quem mais estiver usando ela. A nossa é limitada por taxa e depois fechada em caso de abuso repetido, exatamente por esse motivo, e por nenhum outro.

Dez minutos de verificação, antes de pagar

Cada um destes pontos pode ser respondido antes de qualquer pagamento, e cada resposta vale mais do que qualquer promessa em página de produto. A disposição do provedor em responder já é, em si, um indício importante.

1. Perguntar qual endereço será atribuído (2 min). Não a faixa — o endereço. Um provedor que não informa isso antes do pagamento também não vai informar nada sobre o histórico dele, e essa já é a resposta para a pergunta real.
2. Verificar o endereço, depois verificar o /24 ao redor (3 min). Os verificadores públicos de reputação aceitam os dois formatos. Um endereço limpo dentro de um bloco fortemente listado diz exatamente o que é preciso saber sobre os próximos dois anos.
3. Descobrir quem anuncia a faixa (2 min). A rede que anuncia um bloco diz mais do que o próprio bloco. Uma rede com longo histórico e um contato de abuso publicado se comporta de forma diferente de uma que surgiu no trimestre passado.
4. Testar a porta 25 de saída antes de desenhar a arquitetura em torno dela (1 min). Abrir uma conexão para um servidor de e-mail próprio e ver o que acontece. Descobrir a resposta só depois da migração é o tipo de coisa que consome um fim de semana inteiro.
5. Confirmar que o registro reverso pode ser definido pelo cliente, e em quanto tempo (1 min). As duas metades importam: poder configurá-lo, e a mudança levar minutos em vez de uma fila de chamados esperando resposta bem no dia do lançamento.
6. Perguntar o que acontece quando um endereço se revela inutilizável (1 min). A resposta desejável é a troca, sem discussão e sem custo. Pedir isso por escrito, porque no dia em que for preciso, não haverá margem para negociar.

O que dá para corrigir, e o que é preciso contornar

Cinco situações, e a distinção útil entre elas não é a gravidade aparente. É se a alavanca está nas mãos de quem administra o servidor, nas mãos de outra parte, ou nas mãos de ninguém.

Cinco situações, e se a alavanca está com o cliente

Situação	Quem decidiu	Cabe ao cliente corrigir	O que fazer
Listado em uma lista de política	O provedor	Sim	Uma listagem de política não é uma acusação. A maioria dessas faixas é enviada pelo próprio operador da rede, apenas informando que os endereços ali não deveriam enviar e-mail diretamente. Existe remoção self-service, condicionada a um endereço estático, um servidor de e-mail de verdade e registros corretos nos dois sentidos — e uma exclusão de endereço único expira depois de um ano e é revertida assim que um spam é detectado.
Listado por spam real vindo do endereço	A lista	Parcialmente	Corrigir a causa primeiro, porque uma remoção concedida e depois merecida de novo é pior do que a listagem original. Se o histórico pertence a um inquilino anterior, a solução é outro endereço, não um recurso.
O /24 inteiro listado por um operador que cobra para remover	Só a lista	Não	Não fazer nada, e principalmente não pagar. Tratar a listagem como informação sobre a lista, não sobre o endereço, e verificar se algum provedor relevante realmente a consulta. Em geral, nenhum consulta.
Visitantes desafiados por uma CDN de outra parte	Outra parte	Não	Nada na máquina muda esse resultado, porque nada disso é decidido na máquina. É mais uma coisa resolvida numa camada acima, junto com o registro e o proxy.
E-mail recusado com listas limpas e registros corretos	Ninguém, exatamente	Parcialmente	Isso é reputação, não listagem, e reputação se constrói enviando: volume baixo no início, destinatários reais, e semanas em vez de dias. Ou desiste-se de construí-la nesse endereço, que é o assunto da próxima seção.

As cinco situações melhoram muito assim que se para de adivinhar. Três instrumentos não custam nada e levam uma tarde para configurar: um painel de postmaster nos grandes provedores, que mostra a taxa de spam e a taxa de aprovação de autenticação contra os próprios números de referência deles; feedback loops, que informam quem reclamou, permitindo parar de enviar para essas pessoas antes que a taxa suba; e o hábito de ler os bounces com atenção. Um código 4xx é uma recusa temporária e muitas vezes um limite de taxa — é hora de desacelerar. Um 5xx é uma decisão, e o texto ao lado costuma nomear a lista ou a política responsável. A maioria apaga os dois sem ler nenhum, e depois descreve o resultado como misterioso.

Uma configuração que sobrevive a um endereço ruim

Uma decisão pesa mais do que qualquer registro deste guia, e é uma decisão de arquitetura, não de configuração: não enviar e-mail a partir da mesma máquina que roda a aplicação. Enviar por um relay cuja reputação é o trabalho de tempo integral de outra empresa, mantida sobre um conjunto de endereços aquecidos, monitorados e substituídos quando necessário. Isso não é terceirizar um problema que poderia ter sido resolvido sozinho; é recusar-se a reconstruir, num único endereço de uma faixa compartilhada, algo que exige uma equipe dedicada para continuar funcionando.

Isso deixa a máquina offshore fazendo o que a jurisdição realmente comprou — hospedar o serviço, guardar os dados, continuar no ar quando chega uma reclamação — e coloca a entregabilidade onde ela já é um produto pronto. As duas preocupações deixam de estar amarradas, o que significa que um mês ruim para o endereço deixa de ser um mês ruim para a redefinição de senhas dos usuários.

Para quem está começando hoje, a ordem importa mais do que a lista em si. Configurar o registro reverso e confirmar que ele resolve de volta antes de qualquer outra coisa, porque tudo o que vem depois é julgado com base nele. Publicar SPF e DKIM, depois DMARC em none para receber relatórios sem quebrar a entrega enquanto eles são lidos. Enviar cem mensagens reais para pessoas reais e ler os resultados. Só então decidir se esse endereço algum dia vai ser um endereço de envio, e se a resposta for não, decidir isso agora, em vez de depois de construir uma fila inteira sobre a suposição de que seria.

Se for indispensável hospedar o próprio e-mail, separar os endereços: um para a web pública, outro que só serve para enviar. Um /29 torna isso trivial e custa menos do que um mês investigando por que uma redefinição de senha enviada pelo mesmo IP do marketing está sendo filtrada. Perguntar antes de precisar, não durante.

O ponto mais amplo é o mesmo que este site repete de formas diferentes. Ir para offshore compra algo específico e cobra por isso em atrito de ecossistema, e é assim que esse atrito parece por dentro, em vez de como um item numa página de comparação. Se o perfil de risco não exige a jurisdição, um endereço limpo num provedor comum vale mais do que qualquer coisa nesta página. Se exige, compra-se a jurisdição e aluga-se a reputação de outra empresa — e, para quem for hospedar o próprio e-mail a sério, o ponto de partida é uma máquina que já vem com seu próprio bloco de endereços, em vez de um único endereço no meio da multidão.

Escrito pelos engenheiros que operam a plataforma, e revisado em hoje. Se algo aqui estiver errado ou desatualizado, informe pelo painel — foi de lá que veio cerca de metade destes conteúdos.