AnonAddy: el proyecto de alias de correo anónimo y de código abierto que blinda la bandeja de entrada

En un internet saturado de rastreadores, filtraciones y spam, una dirección de correo es mucho más que un identificador: es un rastro. AnonAddy (addy.io) propone invertir la lógica. En lugar de entregar la cuenta personal a cada web o servicio, el usuario crea alias desechables que reenvían —y, si se desea, cifran— los mensajes hacia su buzón real. El proyecto, de código abierto y con opción de autoalojamiento, publica en GitHub todo su funcionamiento y una documentación extensa que explica desde los fundamentos hasta la configuración avanzada.

La idea es sencilla y poderosa: un alias por servicio. Si una web vende datos o sufre una brecha, basta con desactivar o borrar ese alias. El resto de la vida digital permanece a salvo. Detrás de la iniciativa está Will Browning, desarrollador británico y defensor del software libre y la privacidad, que usa el servicio a diario y mantiene el repositorio abierto a contribuciones.


Qué es AnonAddy y por qué interesa

AnonAddy actúa como pasarela entre el remitente y el buzón real del usuario. Permite:

  • Proteger la dirección real: se entrega un alias distinto en cada alta. Si aparece spam, se desactiva y listo.
  • Rastrear filtraciones: un alias por web ayuda a identificar quién ha filtrado o vendido el contacto.
  • Dificultar el cruce de cuentas en caso de brechas de datos.
  • Restringir la mirada del proveedor de correo: con cifrado GPG/OpenPGP, el contenido viaja protegido hasta el destinatario final.
  • Responder desde el alias sin revelar la identidad real.
  • Cambiar el buzón de reenvío sin actualizar dirección en cientos de servicios: se modifica en AnonAddy y la redirección sigue funcionando.

A diferencia de soluciones cerradas, el proyecto publica su código. No hay anuncios, ni analíticas invasivas ni contenido de terceros, solo logs de acceso del servidor. También ofrece extensiones para Firefox y Chrome, apps oficiales para Android y iOS (autor: Stjin) y una extensión para Raycast, todo en clave abierta.


Alias “compartidos” y alias “estándar”: así se construye el escudo

La plataforma distingue dos tipos principales:

  • Alias de dominio compartido: usan dominios comunes (p. ej., @anonaddy.me). Deben pre-generarse (no se crean “al vuelo”). Cualquiera puede usar esos dominios compartidos para generar combinaciones aleatorias de caracteres o palabras.
  • Alias estándar: se crean al vuelo y están ligados a un espacio propio: el subdominio de usuario (p. ej., @johndoe.anonaddy.com), usuarios adicionales o un dominio propio verificado. Este modo habilita automatismos y comportamientos tipo “catch-all” si se desea.

Para quienes buscan compartimentar todavía más, AnonAddy permite añadir nombres de usuario adicionales y separar alias por ámbitos (personal, trabajo, aficiones). Si la preocupación es que todo quede asociado a un mismo subdominio visible, la alternativa es tirar de alias aleatorios en dominios compartidos.


Usar tu propio dominio (y cuándo no se debe)

Sí, es posible. El usuario verifica la propiedad con un TXT y apunta el MX al servidor de AnonAddy para gestionar la entrada de correos. Con algunos registros adicionales habilita el envío desde ese dominio.

Hay, sin embargo, una regla de oro: no se puede usar el mismo dominio como “personal” y a la vez como destinatario de reenvío dentro de AnonAddy, porque implicaría bucles de correo. En ese caso, la guía recomienda usar un subdominio (p. ej., mail.example.com) para aliases, manteniendo example.com con su proveedor habitual (Proton, Namecheap, etc.). El correo no puede ser entregado simultáneamente a servidores distintos: prevalece el MX de mayor prioridad (número más bajo).


Cifrado, firmas y cabeceras protegidas

El servicio permite subir una clave pública GPG/OpenPGP por destinatario. Desde ese momento, todos los reenvíos se cifran para ese buzón. Incluso puede ocultarse y cifrarse el asunto con Protected Headers, evitando que proveedores como Gmail o iCloud escaneen el contenido y reduzcan falsos positivos de spam.

  • Adjuntos: se consideran parte del mensaje y también se cifran.
  • Firmas: cuando el cifrado está activo, los reenvíos se firman con la clave [email protected] (huella 26A987650243B28802524E2F809FD0D502E2F695), disponible en keys.openpgp.org.
  • Respuestas desde alias con cifrado:
    • Si el destinatario usa GPG/OpenPGP, el usuario cifra con su clave pública.
    • Si no, puede cifrar con la clave de [email protected] para ocultar el contenido a su propio proveedor. El servidor de AnonAddy descifra y entrega el mensaje en claro al destino final.
  • Higiene de metadatos: AnonAddy elimina claves públicas y firmas adjuntas al responder o enviar desde un alias, para evitar que se filtre la dirección real —suele figurar en la identidad de la clave—.

Cómo responder (y enviar) sin mostrar la cuenta real

Al reenviar un mensaje, AnonAddy inserta una dirección “codificada” en el From: del mensaje que llega al usuario. Responder es tan simple como pulsar “Responder” en el cliente; el sistema traduce y entrega al destinatario original sin exponer la cuenta real. El panel muestra contadores de respuestas y envíos para verificar que todo funcionó.

También es posible enviar desde un alias sin conversación previa, construyendo la dirección destino en el formato <alias+destino=dominio@subdominio_de_usuario>. La interfaz web ayuda: el botón “Send from” permite componer correctamente esa sintaxis y, si la catch-all está activa en un dominio propio o subdominio, incluso crear el alias sobre la marcha.


Anti-spam, autenticaciones y advertencias

El servicio se apoya en un conjunto de controles para filtrar abusos y suplantaciones:

  • Rspamd, listas negras DNS (Spamhaus), SPF y DKIM.
  • DMARC, para detectar spoofing y rechazar lo que falle.
  • FQDN y PTR válidos en remitentes.

Si un mensaje entrante falla DMARC, AnonAddy añade un banner rojo preventivo antes de reenviarlo; en las cabeceras (X-AnonAddy-Authentication-Results) se detallan los motivos. Por higiene del sistema, la plataforma prohíbe reportar como spam los mensajes reenviados: si un alias empieza a recibir basura, se desactiva o borra.

Para responder desde un alias, el remitente real debe ser una dirección verificada en la cuenta de AnonAddy (si no, los correos “rebotan” al propio usuario). Y si el envío es rechazado con un 550 5.1.1, el alias puede no existir o estar eliminado. Otra causa habitual: el dominio del destinatario verificado no cuenta con DMARC. La solución: añadir política DMARC (y asegurar SPF/DKIM).


Límites, ancho de banda y planes

El proyecto pone cotas razonables para preservar recursos y evitar abusos:

  • Reenvío: 200 correos/hora por usuario.
  • Creación de alias: 10/h en la modalidad Free, 20/h en Lite y 50/h en Pro; si se supera, los correos quedan aplazados.
  • Tamaño máximo por email: 25 MB (adjuntos incluidos).
  • Ancho de banda: se suma el tamaño de cada correo al reenviar o responder y se reinicia cada mes. Como referencia, un correo medio ronda 75 KB; 10 MB dan para unos 140 correos, mientras que 100 MB (Lite) rozan los 1.400. Al 80 % llega aviso; si se supera, el servidor responde 552 5.2.2 User over quota hasta el siguiente ciclo o hasta que se amplíe el plan.
  • Destinatarios por alias: hasta 10.

El uso de múltiples cuentas Free o la creación masiva de cuentas en servicios externos con alias está prohibido. La plataforma se reserva desactivar cuentas en caso de abuso.


Extensiones, apps y ecosistema

  • Extensión de navegador (Firefox y Chrome/Chromium: Brave, Vivaldi) para generar alias al vuelo.
  • Apps open-source para Android (Play Store y F-Droid) e iOS (App Store), obra de Stjin.
  • Extensión para Raycast (de http.james) para entornos macOS.

¿Dónde están los servidores?

AnonAddy indica que su servidor principal está en Ámsterdam (Países Bajos) con Greenhost (proveedor con foco en privacidad cuya energía es 100 % eólica), y un backup en Varsovia (Polonia) con UpCloud. El servicio participa en FBLs (feedback loops) para detectar reportes de spam y preservar la reputación de sus MTA.


Autoalojamiento: el control total

Para quienes “no se fían de nadie al 100 %”, la propuesta es clara: levantar su propia instancia. El repositorio documenta requisitos y despliegue:

  • Postfix 3.0+ (con postfix-mysql y postfix-pcre) y puerto 25 abierto.
  • PHP 8.2+ con extensiones mailparse, gnupg (si se cifra), imagick (2FA); Nginx como servidor web.
  • Redis 7.x+ para throttling y colas; MariaDB/MySQL para datos.
  • Rspamd como antispam.
  • DNS: MX, SPF, DKIM, DMARC y reverse DNS.
  • SSL/TLS (Let’s Encrypt).
  • FQDN correcto (p. ej., mail.midominio.tld).

Quien prefiera contenedores tiene imagen Docker mantenida por la comunidad. El proyecto funciona con licencia AGPL-3.0, e incluye >200 tests PHPUnit. La documentación de self-hosting y las imágenes oficiales están enlazadas en el README.


Gobernanza, soporte y continuidad

Will Browning asegura que el servicio seguirá operando a largo plazo y contempla planes de continuidad en caso de contingencias personales (renovación de dominios por >5 años, operación por terceros designados y aviso público). La financiación llega vía usuarios de pago; ya no se aceptan patrocinios económicos, sino alianzas de infraestructura (cloud, dominios, hosting). El proyecto agradece el apoyo de la comunidad —incluidos quienes han creado las apps móviles— y anima a reportar fallos, proponer funciones, enviar PRs o mejorar documentación.


Problemas habituales y cómo resolverlos (según su FAQ)

  • “No me llegan correos”: añadir [email protected] y alias a la agenda, revisar spam; confirmar que el alias/dominio/usuario adicional no está desactivado (si lo está, se descartan silenciosamente los mensajes); verificar que el remitente cumple SPF/DMARC y tiene reverse DNS y FQDN válidos. Apple iCloud y Google pueden marcar como “posible phishing” ciertos mensajes: cifrar, ocultar asunto o desactivar banners reduce rechazos.
  • “Al responder me vuelve el correo a mí”: probablemente se está respondiendo desde una dirección no verificada en la cuenta de AnonAddy. Verificarla en el panel.
  • “Rechazo 550 5.1.1 al enviar desde alias”: el alias no existe o está borrado; o el dominio del destinatario no tiene DMARC. Añadir política DMARC (y asegurar SPF/DKIM).
  • “Quiero que Stripe no vea mi email real”: en la suscripción puede usarse un alias para notificaciones de pago.

Un cortafuegos contra el spam… y contra el rastreo

El uso cotidiano aterriza en tres prácticas sencillas:

  1. Un alias por web.
  2. Desactivar alias que filtren o molesten.
  3. Cifrar para que ni siquiera el proveedor del buzón vea el contenido.

El resto es ingeniería de detalle: DMARC/SPF/DKIM bien puestos, sentido común y un par de clics cuando algo se tuerce.


Preguntas frecuentes (para búsquedas y consultas de padres, autónomos y equipos de TI)

¿Cómo crear alias de correo desechables para proteger la privacidad y evitar spam?
Con AnonAddy se genera un alias por servicio (en dominios compartidos o propios). Si un alias empieza a recibir spam, se desactiva o elimina desde el panel. Puede responderse desde el alias sin exponer la cuenta real y activarse cifrado GPG/OpenPGP para proteger contenidos y asuntos.

¿Cómo configurar SPF, DKIM y DMARC al usar AnonAddy con dominio propio?
Al añadir un dominio, se verifica con TXT, se apuntan MX a los servidores de AnonAddy y se publican SPF/DKIM/DMARC. DMARC evita suplantaciones y es requisito para que responder desde alias no se rechace en ciertos proveedores. Si el dominio principal ya aloja correo externo, conviene usar un subdominio (p. ej., mail.example.com).

¿Qué diferencia hay entre alias de dominio compartido y alias estándar?
Los compartidos (@anonaddy.me, @anonaddy.com, etc.) se pre-generan y no se crean al vuelo. Los estándar se crean sobre la marcha en tu subdominio de usuario, usuarios adicionales o dominio propio, permiten catch-all y automatismos, y facilitan responder/enviar sin fricción.

¿Cómo autoalojar AnonAddy paso a paso y qué requisitos técnicos tiene?
Se necesita Postfix 3.0+, PHP 8.2+ (con mailparse, gnupg, imagick), Redis 7.x+, MariaDB/MySQL, Nginx, Rspamd, DNS (MX/SPF/DKIM/DMARC), reverse DNS, TLS (Let’s Encrypt) y FQDN. El puerto 25 debe estar abierto. La documentación de self-hosting y las imágenes Docker están enlazadas en el README del repositorio oficial.


Fuente: repositorio y documentación pública del proyecto anonaddy/anonaddy (addy.io) en GitHub.

Suscríbete al boletín SysAdmin

Este es tu recurso para las últimas noticias y consejos sobre administración de sistemas, Linux, Windows, cloud computing, seguridad de la nube, etc. Lo enviamos 2 días a la semana.

¡Apúntate a nuestro newsletter!


– patrocinadores –

Noticias destacadas

– patrocinadores –

¡SUSCRÍBETE AL BOLETÍN
DE LOS SYSADMINS!

Scroll al inicio
×