Ofuscación de correo electrónico: ¿qué métodos siguen siendo efectivos en 2026?

• Para proteger direcciones de correo electrónico de los recolectores de spam, se compararon distintas técnicas de ofuscación con HTML, CSS y JavaScript midiendo su tasa de bloqueo
• Las pruebas sobre 426 muestras de texto y 399 de enlaces mostraron que la mayoría de las técnicas basadas en JS, así como varias con CSS y SVG, lograron un 100% de bloqueo
• Métodos antiguos como entidades HTML y codificación URL también siguieron mostrando una alta eficacia de bloqueo
• En cambio, opciones como mostrar el correo como imagen, sustituir símbolos o invertir la dirección del texto perjudican gravemente la accesibilidad y la usabilidad
• Para 2026, se consideran las opciones más seguras y prácticas de protección de correo electrónico los métodos de conversión con JS, cifrado AES e interacción del usuario

---

Comparación de técnicas de ofuscación de direcciones de correo electrónico (a 2026)

• Se presentan diversas técnicas de ofuscación para ocultar direcciones de correo electrónico de los recolectores de spam (harvesters), junto con estadísticas sobre su eficacia real
• Tras proteger cada dirección de correo con un método distinto, se midió si los harvesters podían acceder a 426 muestras (texto) y 399 muestras (enlaces) para calcular la tasa de bloqueo
• La mayoría de las técnicas basadas en JavaScript y algunas con CSS y SVG registraron una tasa de bloqueo del 100%
• Métodos antiguos como entidades HTML y codificación URL siguen manteniendo altas tasas de bloqueo
• Algunas técnicas perjudican gravemente la accesibilidad o la usabilidad, por lo que no son adecuadas para uso real

1. Técnicas para proteger correos electrónicos en texto plano

• El correo electrónico se muestra directamente en la página, pero se evita que los harvesters lo lean mediante varias técnicas de HTML, CSS y JS
• Si se combinan varios métodos y se protegen segmentos por separado, se puede maximizar la eficacia

• Sin protección (No protection)

  • Tasa de bloqueo: 0% (0 bloqueados de 426)
  • La dirección queda expuesta tal cual y todos los harvesters la recolectan

• Entidades HTML (HTML Entities)

  • Tasa de bloqueo: 95%
  • Aunque las bibliotecas del lado del servidor la decodifican automáticamente, en la práctica bloquea a la mayoría de los harvesters

• Comentarios HTML (HTML Comments)

  • Tasa de bloqueo: 99%
  • Solo puede bloquear harvesters básicos con poca capacidad para interpretar etiquetas HTML
  • Es simple, pero sigue manteniendo una alta eficacia de bloqueo

• HTML SVG

  • Tasa de bloqueo: 100%
  • Oculta la dirección de correo como texto dentro de un objeto SVG
  • Sigue siendo accesible para lectores de pantalla para personas con discapacidad visual
  • Es obligatorio usar el elemento <object>; con <img> o SVG inline existe riesgo de exponer el código fuente
  • Depende de la fuente, por lo que es necesario especificar una web font

• CSS display:none

  • Tasa de bloqueo: 100%
  • Aprovecha las limitaciones de los harvesters que no pueden aplicar reglas de estilo
  • Mantiene la accesibilidad, y se recomienda usar display:none en lugar de ocultamiento visual

• Concatenación de cadenas en JS (Concatenation)

  • Tasa de bloqueo: 100%
  • Se puede implementar fácilmente sin dependencias externas
  • Como el correo completo existe en el HTML, es débil desde el punto de vista de seguridad

• JS Rot18

  • Tasa de bloqueo: 100%
  • Usa un cifrado por rotación de caracteres similar a ROT13
  • Los harvesters simples no pueden descifrarlo, pero es vulnerable frente a recolectores que ignoran JS

• Conversión con JS (Conversion)

  • Tasa de bloqueo: 100%
  • El HTML solo contiene una cadena sin sentido, y una función JS la convierte al correo real
  • La mayoría de los harvesters no pueden reconstruirla porque no ejecutan DOM ni JS
  • Es una técnica simple y muy efectiva

• Cifrado AES con JS

  • Tasa de bloqueo: 100%
  • Protege el correo usando cifrado AES-256
  • Usa la SubtleCrypto API del navegador y solo funciona en entornos HTTPS
  • Sin el archivo JS, no se puede descifrar

• Interacción del usuario con JS (User interaction)

  • Tasa de bloqueo: 100%
  • El correo solo se muestra cuando el usuario interactúa con la página
  • Para un harvester, requeriría ejecución del DOM + simulación de eventos de usuario, algo prácticamente imposible

• Sustitución de símbolos en HTML (Symbol substitution)

  • Tasa de bloqueo: 96%
  • Sustituye partes por “AT”, “DOT”, etc.
  • Como el usuario debe corregirlo manualmente, reduce la usabilidad

• Instrucciones HTML (Instructions)

  • Tasa de bloqueo: 100%
  • Incluye instrucciones manuales en el correo, como “remove the .fluff”
  • Solo personas o IA pueden interpretarlo, pero resulta muy incómodo para el usuario

• Imagen HTML

  • Tasa de bloqueo: 100%
  • Muestra la dirección de correo como imagen
  • No es accesible para personas con discapacidad visual, no se puede copiar, etc.; la usabilidad colapsa

• CSS content

  • Tasa de bloqueo: 100%
  • Muestra el correo con el pseudoelemento ::after
  • Visualmente aparece, pero no se puede copiar y también puede reconstruirse solo con el HTML
  • Se considera una técnica inútil

• Dirección del texto en CSS (Text direction)

  • Tasa de bloqueo: 100%
  • Invierte la cadena con direction: rtl
  • Si el harvester ignora CSS, puede descifrarla fácilmente
  • El texto se copia al revés, lo que perjudica la usabilidad

2. Técnicas para proteger enlaces clicables

• Métodos para proteger el atributo href de enlaces mailto:
• Si el texto del enlace incluye el correo, es necesario combinarlo con una técnica aparte de ofuscación de texto

• Sin protección

  • Tasa de bloqueo: 0% (0 bloqueados de 399)
  • La dirección de correo queda completamente expuesta

• Entidades HTML

  • Tasa de bloqueo: 100%
  • A pesar de la decodificación automática del lado del servidor, bloquea a la mayoría de los harvesters

• Codificación URL

  • Tasa de bloqueo: 95%
  • Es fácil de decodificar, pero en la práctica bloquea a la mayoría de los harvesters

• Redirección HTTP

  • Tasa de bloqueo: 100%
  • Oculta el enlace mailto: haciéndolo parecer un enlace común
  • Se configura una redirección 302 o 301 en .htaccess
  • nofollow, noindex evita que los motores de búsqueda lo indexen
  • Se requiere la bandera QSA para el autocompletado de campos de correo

• HTML SVG

  • Tasa de bloqueo: 100%
  • Oculta el enlace de correo dentro de un SVG
  • Mantiene la accesibilidad y exige usar <object>
  • Requiere especificar fuente

• Concatenación de cadenas en JS

  • Tasa de bloqueo: 100%
  • Se puede implementar sin dependencias externas
  • No es seguro porque el correo está incluido directamente en el HTML

• JS Rot18

  • Tasa de bloqueo: 99%
  • Rotación de caracteres similar a ROT13
  • Los harvesters simples no pueden descifrarlo

• Conversión con JS (Conversion)

  • Tasa de bloqueo: 100%
  • En el HTML solo existe un enlace falso, y JS lo convierte en el mailto: real
  • Como los harvesters solo pueden acceder al HTML, no pueden reconstruirlo
  • Es una técnica simple y muy efectiva

• Cifrado AES con JS

  • Tasa de bloqueo: 100%
  • Enlace de correo cifrado con AES-256
  • Usa la SubtleCrypto API del navegador y requiere HTTPS

• Interacción del usuario con JS

  • Tasa de bloqueo: 100%
  • El enlace solo se activa cuando el usuario interactúa con la página
  • A los harvesters les resulta difícil reproducir ese comportamiento

3. Críticas y contraargumentos

• Sobre la afirmación de que “los spammers no rastrean la web, sino que compran bases de datos filtradas”
  • Las direcciones de correo de esta página solo se publicaron en esta página, y aun así recibieron miles de correos spam
• Sobre la afirmación de que “no hace falta protección”
  • El contenido popular se recolecta de forma intensiva, así que si existe posibilidad de viralización, sí hace falta protección
• Sobre la afirmación de que “basta con filtros de spam”
  • Estas técnicas pueden implementarse gratis y sin falsos positivos, y conviene usarlas junto con filtros
• Sobre la afirmación de que “si la técnica se conoce, deja de servir”
  • Las estadísticas muestran que las mismas técnicas siguen siendo efectivas incluso después de varias décadas

4. Metodología del experimento

• Se publicaron direcciones de correo protegidas con cada técnica de ofuscación y se usaron como honeypots para harvesters
• Cuando llegaba spam, se consideraba que la técnica de protección de esa dirección había sido vulnerada
• Los mensajes se agruparon por spammer para generar estadísticas basadas en número de remitentes
• Para evitar que el filtrado de spam distorsionara las estadísticas, se construyeron directamente un servidor de correo y un cliente
• Como los harvesters basados en texto y los basados en enlaces son distintos, las estadísticas se separaron
• La muestra aún es pequeña, pero se espera que la confiabilidad estadística mejore a medida que aumenten los enlaces

Conclusión

• Las técnicas basadas en conversión con JS, cifrado y interacción del usuario ofrecen el mayor nivel de seguridad y accesibilidad
• CSS display:none y la técnica con objetos SVG también destacan en accesibilidad y tasa de bloqueo
• La sustitución de símbolos, las imágenes y la inversión de dirección del texto no se recomiendan porque dañan gravemente la usabilidad
• Si es necesario publicar un correo electrónico, una conversión simple con JS o un método de cifrado AES es la opción más efectiva a 2026

[GN⁺]

Opiniones de Hacker News

• Antes me preocupaba por la recolección de correos, pero ahora simplemente dejo mi email público en mi sitio web
  El filtrado de spam es lo suficientemente bueno
  Aun así, esta revisión de técnicas me pareció interesante. Me sorprendió que los métodos simples fueran bastante efectivos

  • Desde inicios de los 2000 tengo mi correo en texto plano con un enlace mailto: en mi blog, y solo recibo unas pocas piezas de spam al día
    Quizá el filtrado de Zoho sea bueno, pero no creo que sea especialmente mejor que el de los servicios grandes
  • La mayoría de los bots recolectores ya tienen millones de direcciones, así que no les importan unos cuantos emails poco comunes
    Por eso está bien usar tu propio método simple, pero si lo publicas puede quedar inutilizado de inmediato
  • Desde que puse mi correo en el sitio web de mi empresa, recibo más de 1,500 correos spam al mes
  • Yo también he publicado mi correo de forma similar, pero si métodos simples como entidades HTML o display:none pueden bloquear más del 90%, valdría la pena reconsiderarlo
  • Creo que el correo tarde o temprano termina filtrándose. Aun así, pienso que el spam basado en LLM tendrá cada vez más probabilidades de evadir los filtros

• Mi correo aparece en texto plano más de 90 veces en commits de repositorios populares de código abierto en GitHub
  Pero en 8 años casi no he recibido spam
  Puede que el formato entre < y > confunda a los recolectores
  Hoy en día parece más común comprar listas de correos que recolectarlos directamente

  • En mi dominio tengo configuradas direcciones comodín
    Con frecuencia llega spam a git@, contact@, admin@ y direcciones similares
    Últimamente también llegan correos haciéndose pasar por el CEO a direcciones falsas como finance@
    Irónicamente, el correo que dejé en texto plano en mi perfil de HN casi no recibe spam

• Mi hipótesis es que los recolectores de correos no parsean el HTML, sino que simplemente buscan cadenas alrededor del carácter @
  Parsear HTML cuesta más, así que este enfoque simple puede ser más eficiente
  Por eso las entidades HTML parecen funcionar

  • Puede que los recolectores hayan aprendido que el spam enviado a direcciones ofuscadas tiene baja tasa de respuesta
    Así que quizá simplemente ignoran esas direcciones
  • Sí, la mayoría hace búsquedas simples de bytes, pero en el marketing black hat existen varias técnicas de scraping
  • Al final depende de qué tan insistente sea el adversario. Un atacante irracional se aferra hasta el final
  • La extracción basada en tokens alrededor de @ también funciona bien con unas pocas variaciones

• El artículo está bien escrito, pero me decepciona que no mencione el método de poseer todo un dominio y dar un correo único a cada destinatario
  Si llega spam, basta con bloquear esa dirección
  O incluso está la opción de vivir sin email. Hoy en día, con correos temporales se puede resolver casi todo

  • Yo también llevo 20 años operando así
    Pero la mayor parte del spam viene de amigos o familiares que comparten mi dirección en apps
    Los correos públicos pude bloquearlos al 100% con una simple técnica de ensamblado en JavaScript
  • Antes intenté generar un correo único para cada persona, pero al final lo simplifiqué a una sola dirección basada en lista blanca
    El efecto fue parecido y es mucho más fácil de administrar

• Hay una forma de ocultar una dirección de email tarpit en un sitio web
  Se esconde con CSS para que las personas no la vean, y si un bot le envía correo, se bloquea esa IP durante 24 horas

  • Pero esto puede terminar bloqueando hasta servidores de correo importantes como Google
    Como también hay spam que llega desde cuentas de Gmail, los efectos secundarios son grandes
  • Existe un concepto parecido en Project Honey Pot

• Buen contenido, pero creo que el título correcto sería “Email address obfuscation”
  Aunque al ver artículos así, también parece que los spammers podrían aprender de ellos

  • Usar “email” en vez de “email address” es confuso. Según el contexto, muchas veces se entiende como “mensaje de correo”
  • La forma de mostrar el contacto en el sitio de Greg Egan era tan enrevesada que no pude descifrarla

• Antes hice una prueba porque quería saber si expresiones como “me at foobar dot com” seguían siendo efectivas
  Usando un LLM para resolver varios métodos de ofuscación de correos, vi que casi todo lo que no fuera CSS o JS podía interpretarse
  Aun así, hoy los filtros de spam funcionan tan bien que publicar el correo en texto plano no me causó mayores problemas
  Más bien, lo que resulta más molesto son los correos de notificaciones de servicios

  • Un mejor método sería que el visitante use un poco de CPU para generar un correo con token único
    Si hay abuso, solo se descarta esa dirección
    Sería ideal que el cliente y el servidor de correo soportaran una API así
  • Los recolectores basados en LLM podrían incluso interpretar instrucciones mejor que una persona
    Por eso creo que la ofuscación básica para frenar bots simples con regex sigue siendo válida
  • También está la historieta relacionada de xkcd 1808

• A inicios de este año, mientras hacía un intérprete de Brainfuck en C, probé usarlo para ofuscar correos
  Guardaba cada correo como un programa Brainfuck y un intérprete en JS lo ejecutaba para mostrar el texto plano
  El JS se cargaba desde un dominio externo y, tras verificar el referer, enviaba el código real
  Obviamente no sirve contra recolectores que ejecutan JS, pero como experimento creativo de ofuscación fue interesante

  • Me pregunto en qué se diferencia esto de simplemente usar cifrado XOR en JS
  • Si un recolector mete una captura de pantalla en un LLM u OCR, este método probablemente dejaría de servir

• Este artículo también parece una guía para hacer más inteligentes a los recolectores de correos

  • Sí, pero ejecutar JS o CSS, renderizar SVG y demás sigue siendo costoso, así que para bots a gran escala sigue siendo una carga