Ofuscação de e-mail: qual é o método eficaz em 2026?

• Para proteger endereços de e-mail de coletores de spam, foram testadas várias técnicas de ofuscação em HTML, CSS e JavaScript e comparadas suas taxas de bloqueio
• Em testes com 426 amostras de texto e 399 amostras de links, a maioria das técnicas baseadas em JS e várias em CSS e SVG registraram 100% de bloqueio
• Métodos antigos como entidades HTML e codificação de URL ainda mostraram alta eficácia de bloqueio
• Por outro lado, exibição por imagem, substituição por símbolos e inversão da direção do texto prejudicam seriamente a acessibilidade e a usabilidade
• Em 2026, transformação com JS, criptografia AES e abordagens baseadas em interação do usuário são avaliadas como os meios mais seguros e práticos para proteger e-mails

---

Comparação de técnicas de ofuscação de endereços de e-mail (em 2026)

• São apresentadas várias técnicas de ofuscação para ocultar endereços de e-mail de coletores de spam (harvesters), junto com estatísticas sobre a eficácia real de cada método
• Após proteger cada endereço de e-mail de uma forma diferente, foi medida a possibilidade de acesso pelos harvesters em amostras de 426 (texto) e 399 (links), calculando-se a taxa de bloqueio
• A maioria das técnicas baseadas em JavaScript e algumas técnicas com CSS e SVG alcançaram 100% de bloqueio
• Métodos antigos como entidades HTML e codificação de URL ainda mantêm altas taxas de bloqueio
• Algumas técnicas prejudicam gravemente a acessibilidade ou a usabilidade, tornando-se inadequadas para uso real

1. Técnicas de proteção para e-mail em texto comum

• O endereço de e-mail é exibido diretamente na página, mas protegido com várias técnicas de HTML, CSS e JS para impedir que harvesters o leiam
• Ao combinar várias técnicas e proteger por segmentos, é possível maximizar a eficácia

• Sem proteção (No protection)

  • Taxa de bloqueio de 0% (0 bloqueados entre 426)
  • O endereço de e-mail fica exposto como está e é coletado por todos os harvesters

• Entidades HTML (HTML Entities)

  • Taxa de bloqueio de 95%
  • Bibliotecas do lado do servidor fazem a decodificação automaticamente, mas na prática ainda bloqueiam a maioria dos harvesters

• Comentários HTML (HTML Comments)

  • Taxa de bloqueio de 99%
  • Só conseguem bloquear harvesters básicos com fraca interpretação de tags HTML
  • É simples, mas ainda mantém alta eficácia de bloqueio

• HTML SVG

  • Taxa de bloqueio de 100%
  • Oculta o endereço de e-mail como texto dentro de um objeto SVG
  • Permite acesso por leitores de tela para pessoas com deficiência visual
  • É obrigatório usar o elemento <object>; com <img> ou SVG inline há risco de exposição no código-fonte
  • Como depende de fonte, é necessário definir uma web font

• CSS display:none

  • Taxa de bloqueio de 100%
  • Explora a limitação de harvesters que não conseguem aplicar regras de estilo
  • É possível manter a acessibilidade, e recomenda-se usar display:none em vez de ocultação apenas visual

• Concatenação de strings em JS (Concatenation)

  • Taxa de bloqueio de 100%
  • Pode ser implementada de forma simples, sem dependências externas
  • Como o e-mail completo existe no HTML, é frágil do ponto de vista de segurança

• JS Rot18

  • Taxa de bloqueio de 100%
  • Usa uma cifra de rotação de caracteres semelhante a ROT13
  • Harvesters simples não conseguem decodificar, mas é vulnerável a coletores que ignoram JS

• Transformação com JS (Conversion)

  • Taxa de bloqueio de 100%
  • O HTML contém apenas uma string sem sentido, e uma função JS a converte no e-mail real
  • A maioria dos harvesters não consegue executar DOM ou JS, então não consegue reconstruí-lo
  • É uma técnica simples e muito eficaz

• Criptografia AES com JS

  • Taxa de bloqueio de 100%
  • Protege o e-mail com criptografia AES-256
  • Usa a SubtleCrypto API do navegador e funciona apenas em ambiente HTTPS
  • Sem o arquivo JS, a descriptografia é impossível

• Interação do usuário com JS (User interaction)

  • Taxa de bloqueio de 100%
  • O e-mail só é exibido quando o usuário interage com a página
  • Para o harvester, isso exigiria execução de DOM + simulação de eventos do usuário, o que na prática é inviável

• Substituição por símbolos em HTML (Symbol substitution)

  • Taxa de bloqueio de 96%
  • Substitui por elementos como “AT” e “DOT”
  • Como o usuário precisa corrigir manualmente, há perda de usabilidade

• Instruções HTML (Instructions)

  • Taxa de bloqueio de 100%
  • Inclui no e-mail instruções manuais como “remove the .fluff”
  • Só pode ser interpretado por humanos ou IA, mas gera muito incômodo ao usuário

• Imagem HTML

  • Taxa de bloqueio de 100%
  • Exibe o endereço de e-mail como imagem
  • Não há acessibilidade para pessoas com deficiência visual, não dá para copiar etc., ou seja, a usabilidade entra em colapso

• CSS content

  • Taxa de bloqueio de 100%
  • Exibe o e-mail com o pseudo-elemento ::after
  • Visualmente aparece, mas não pode ser copiado, e também pode ser reconstruído apenas com o HTML
  • É avaliada como uma técnica inútil

• Direção de texto em CSS (Text direction)

  • Taxa de bloqueio de 100%
  • Inverte a string com direction: rtl
  • Se o harvester ignorar CSS, é fácil decodificar
  • O texto é copiado ao contrário, prejudicando a usabilidade

2. Técnicas de proteção para links clicáveis

• Método para proteger o atributo href de links mailto:
• Se o texto do link contiver o e-mail, é necessário combinar com uma técnica separada de ofuscação de texto

• Sem proteção

  • Taxa de bloqueio de 0% (0 bloqueados entre 399)
  • O endereço de e-mail fica totalmente exposto

• Entidades HTML

  • Taxa de bloqueio de 100%
  • Apesar da decodificação automática no servidor, ainda bloqueia a maioria dos harvesters

• Codificação de URL

  • Taxa de bloqueio de 95%
  • É fácil de decodificar, mas na prática ainda bloqueia a maioria dos harvesters

• Redirecionamento HTTP

  • Taxa de bloqueio de 100%
  • Oculta o link mailto: fazendo-o parecer um link comum
  • Configura um redirecionamento 302 ou 301 no .htaccess
  • Usa nofollow, noindex para impedir indexação por mecanismos de busca
  • Ao preencher automaticamente campos de e-mail, é necessário o sinalizador QSA

• HTML SVG

  • Taxa de bloqueio de 100%
  • Oculta o link de e-mail dentro de SVG
  • Mantém a acessibilidade, sendo obrigatório usar <object>
  • É necessário definir a fonte

• Concatenação de strings em JS

  • Taxa de bloqueio de 100%
  • Pode ser implementada sem dependências externas
  • Como o e-mail está incluído diretamente no HTML, não é seguro

• JS Rot18

  • Taxa de bloqueio de 99%
  • Rotação de caracteres semelhante a ROT13
  • Harvesters simples não conseguem decodificar

• Transformação com JS (Conversion)

  • Taxa de bloqueio de 100%
  • No HTML existe apenas um link falso, e o JS o converte no mailto: real
  • Como o harvester só consegue acessar o HTML, não pode reconstruí-lo
  • É uma técnica simples e muito eficaz

• Criptografia AES com JS

  • Taxa de bloqueio de 100%
  • Link de e-mail criptografado com AES-256
  • Usa a SubtleCrypto API do navegador e requer HTTPS

• Interação do usuário com JS

  • Taxa de bloqueio de 100%
  • O link só é ativado quando o usuário interage com a página
  • É difícil para harvesters reproduzirem isso

3. Críticas e contrapontos

• Sobre a afirmação de que “spammers não raspam a web, eles compram bases de dados vazadas”
  • Os endereços de e-mail desta página foram publicados apenas nesta página, e mesmo assim receberam milhares de spams
• Sobre a afirmação de que “não é preciso proteger”
  • Conteúdos populares são coletados intensamente, então é necessário considerar a possibilidade de viralização
• Sobre a afirmação de que “basta ter filtro de spam”
  • Essas técnicas podem ser implementadas gratuitamente e sem falsos positivos, sendo recomendável usá-las em conjunto com filtros
• Sobre a afirmação de que “quando a técnica se torna conhecida, deixa de servir”
  • As estatísticas confirmam que as mesmas técnicas continuam eficazes há décadas

4. Metodologia do experimento

• Endereços de e-mail protegidos com cada técnica de ofuscação foram realmente publicados e operados como honeypots para harvesters
• Quando chegava spam, considerava-se que a técnica de proteção daquele endereço havia sido quebrada
• As mensagens foram agrupadas por spammer para gerar estatísticas com base no número de remetentes
• Para evitar que a filtragem de spam distorcesse as estatísticas, foram montados um servidor de e-mail e um cliente próprios
• Como harvesters baseados em texto e em links são diferentes, as estatísticas foram separadas
• O tamanho da amostra ainda é pequeno, mas espera-se maior confiabilidade estatística à medida que o número de links aumentar

Conclusão

• Técnicas baseadas em JS de transformação, criptografia e interação do usuário oferecem o melhor nível de segurança e acessibilidade
• CSS display:none e a técnica com objeto SVG também se destacam em acessibilidade e taxa de bloqueio
• Substituição por símbolos, imagem e inversão da direção do texto não são recomendadas por prejudicarem seriamente a usabilidade
• Quando for necessário publicar um e-mail, uma transformação simples com JS ou criptografia AES é a escolha mais eficaz em 2026

[GN⁺]

Comentários do Hacker News

• Antigamente eu me preocupava com coleta de e-mails, mas agora simplesmente deixo meu e-mail público no meu site
  A filtragem de spam é boa o bastante
  Ainda assim, foi interessante ver essa análise das técnicas. Fiquei surpreso que até métodos simples funcionem bem

  • Desde o começo dos anos 2000 deixo meu e-mail em texto puro no meu blog com um link mailto:, e recebo só alguns spams por dia
    Talvez a filtragem da Zoho seja boa, mas não acho que seja particularmente melhor que a de serviços grandes
  • A maioria dos bots de coleta já juntou milhões de endereços, então não ligam para alguns e-mails raros
    Por isso dá para usar seu próprio método simples, mas se você o divulgar ele pode ser neutralizado imediatamente
  • Depois de colocar meu e-mail no site da minha empresa, passei a receber mais de 1.500 spams por mês
  • Eu também venho deixando meu e-mail público de forma parecida, mas se métodos simples como entidades HTML ou display:none conseguirem bloquear mais de 90%, talvez valha reconsiderar
  • Acho que no fim os e-mails sempre vazam. Só que o spam baseado em LLM provavelmente vai conseguir driblar filtros cada vez mais

• Meu e-mail aparece em texto puro mais de 90 vezes em commits de repositórios populares de código aberto no GitHub
  Mesmo assim, quase não recebi spam em 8 anos
  Talvez o formato entre < e > confunda os coletores
  Hoje em dia, parece mais comum comprar listas de e-mail do que coletar diretamente

  • No meu domínio eu configurei endereços curinga
    Spam chega com frequência para git@, contact@, admin@
    Recentemente até começaram a chegar e-mails se passando pelo CEO para endereços falsos como finance@
    Ironicamente, o e-mail que deixei em texto puro no meu perfil do HN quase não recebe spam

• Minha hipótese é que os coletores de e-mail não fazem parsing de HTML, só procuram strings ao redor do caractere @
  Como fazer parsing de HTML custa caro, esse tipo de abordagem simples pode ser eficiente
  Por isso entidades HTML parecem funcionar

  • Talvez os coletores tenham aprendido que spam enviado para endereços ofuscados tem baixa taxa de resposta
    Então podem simplesmente ignorar esses endereços
  • Sim, a maioria faz só busca simples por bytes, mas no marketing black hat existem várias técnicas de scraping
  • No fim, é uma questão de quão insistente é o adversário. Atacantes irracionais continuam insistindo até o fim
  • Extração baseada em tokens ao redor de @ também funciona bem com pequenas variações

• O texto foi bem escrito, mas senti falta de mencionar a estratégia de ter o domínio inteiro sob seu controle e dar um e-mail único para cada destinatário
  Quando vier spam, é só bloquear aquele endereço
  Ou então dá para simplesmente viver sem e-mail. Hoje em dia, e-mails temporários resolvem a maioria dos casos

  • Também uso esse esquema há 20 anos
    Mas a maior parte do spam vem de amigos ou familiares compartilhando meu endereço em apps
    Com um simples método de ligação em JavaScript, consegui bloquear 100% do spam em e-mails públicos
  • No passado tentei gerar um e-mail exclusivo para cada pessoa, mas no fim simplifiquei para um único endereço com whitelist
    O efeito é parecido e é muito mais fácil de administrar

• Existe o método de esconder um endereço de e-mail tarpit no site
  Você o oculta com CSS, humanos não veem, e se um bot mandar e-mail para ele, aquele IP é bloqueado por 24 horas

  • Mas isso corre o risco de bloquear até grandes servidores de e-mail como o Google
    Como também existe spam vindo de contas do Gmail, os efeitos colaterais são grandes
  • Existe um conceito parecido no Project Honey Pot

• Bom conteúdo, mas acho que o título mais adequado seria "Email address obfuscation"
  Só que, vendo textos assim, dá a impressão de que os spammers também podem aprender com eles

  • Usar “email” no lugar de “email address” é confuso. Dependendo do contexto, muita gente entende como “mensagem de e-mail”
  • A forma de mostrar contato no site do Greg Egan era tão enigmática que ficou impossível decifrar

• Há um tempo testei se expressões como “me at foobar dot com” ainda seriam eficazes
  Usei um LLM para tentar resolver vários métodos de ofuscação de e-mail, e quase tudo que não era baseado em CSS ou JS pôde ser interpretado
  Mesmo assim, hoje os filtros de spam funcionam tão bem que deixar o e-mail em texto puro não causou grandes problemas
  Na verdade, e-mails de notificação de serviços são mais incômodos

  • Uma forma melhor seria fazer o visitante gastar um pouco de CPU para gerar um e-mail com token único
    Se houver abuso, basta descartar aquele endereço
    Seria ideal se cliente e servidor de e-mail suportassem esse tipo de API
  • Coletores baseados em LLM talvez interpretem instruções melhor do que humanos
    Então acredito que a ofuscação básica para bloquear bots simples baseados em regex ainda continue válida
  • Tem também a tirinha relacionada xkcd 1808

• No começo deste ano, enquanto fazia um interpretador de Brainfuck em C, tentei usá-lo para ofuscar e-mails
  Cada e-mail era armazenado como um programa Brainfuck, e um interpretador em JS o executava para mostrar o texto puro
  O JS era carregado de um domínio externo, e o código real só era enviado após validar o referer
  Claro que isso não serve contra coletores que executam JS, mas foi um experimento de ofuscação criativa interessante

  • Fico curioso sobre que diferença isso teria em relação a simplesmente usar criptografia XOR em JS
  • Se o coletor mandar screenshots para um LLM ou OCR, esse método provavelmente deixa de funcionar

• Esse texto também parece um guia para deixar os coletores de e-mail mais inteligentes

  • Sim, mas executar JS ou CSS, renderizar SVG etc. ainda são operações caras, então pesam para bots em larga escala