La forma más sencilla de dejar de recibir spam en la bandeja principal es aburrida: dejar de compartir la dirección principal. En la práctica esto es un dolor constante, porque casi cualquier servicio pide un email y además envía un código de confirmación. Al final o expones la dirección, o recurres a servicios públicos de correo temporal, que a menudo bloquean y en los que no siempre quieres confiar.
La solución usada por paranoicos, evaluadores y quienes están cansados de las listas: levantar un correo desechable en tu propio dominio. Entonces las direcciones temporales viven por separado, los correos entrantes se ven en una interfaz web y la bandeja principal queda para la vida normal.
Más abajo analizaremos una opción basada en NortixMail (en la línea de TempFastMail): qué ofrece, qué inconvenientes tiene y cómo ponerlo en marcha en una tarde, sin convertirlo en un servidor de correo corporativo completo.
Por qué usar direcciones desechables y por qué lo autohospedado es mejor que los temp-mail públicos
El correo electrónico desechable no es para misiones secretas. Es higiene cotidiana: registrarse en un servicio de un solo uso, descargar una versión de prueba, reclamar un cupón, probar un formulario de registro, recibir un código de confirmación y olvidarlo. Cuantos menos rastros queden en la bandeja principal, menos probabilidad de terminar con un zoológico de spam y phishing.
Los servicios públicos de correo temporal son cómodos, pero tienen un problema típico: son masivos. Muchos sitios bloquean dominios conocidos de temp-mail, y además no controlas quién ni cómo guarda tus mensajes. Para códigos de confirmación suele ser tolerable, pero queda un mal sabor.
La opción autohospedada resuelve ambos problemas. El dominio es tuyo, la infraestructura es tuya y, desde la perspectiva de la mayoría de sitios, es simplemente correo normal. Y, lo más importante, puedes hacer que las direcciones sean realmente desechables según tus propias reglas.
Hay limitaciones honestas. El SMTP entrante casi siempre necesita el puerto 25, y algunos proveedores lo bloquean por defecto. Además, cualquier servicio SMTP público atrae la atención de escáneres, por lo que la disciplina básica de seguridad es obligatoria, incluso si no envías mensajes al exterior.
Casos prácticos donde compensa al instante:
- Registrarse en servicios que requieren confirmación por email cuando no quieres dejar la dirección principal.
- Probar boletines, registros y recuperación de contraseña en entornos de desarrollo.
- Dirección separada para tiendas, suscripciones y promociones puntuales (y luego simplemente cortar el flujo).
- Segmentación de riesgos: la bandeja principal para lo importante, la desechable para todo lo demás.
Cómo funciona y qué preparar antes de la instalación
La idea es simple: el servidor recibe los correos entrantes para tu dominio (o subdominio) y la interfaz web los muestra en el navegador. Cero clientes de correo complicados, cero ajustes en el teléfono. Solo necesitas saber abrir una página y copiar un código del mensaje.
Punto clave: para que los correos realmente lleguen, el mundo exterior debe poder contactar tu SMTP. En la práctica eso significa un puerto 25 accesible y registros DNS correctos. Si el proveedor bloquea el puerto 25, los mensajes no llegarán aunque la interfaz funcione bien.
En DNS como mínimo: un registro A apuntando a tu servidor y un registro MX que indique que el correo del dominio se entrega a tu host. Es mejor usar un subdominio separado (por ejemplo, temp.tudominio.tld) para no mezclar las direcciones desechables con el correo normal.
Otro matiz real: el proxy inverso suele llevarse bien con HTTP, pero SMTP es otra historia. Para correo entrante es mejor mapear directamente el puerto 25 al contenedor o servicio, sin esperar que el proxy lo haga mágicamente.
Mini-lista de verificación antes de empezar:
- VPS con IP pública y puerto entrante 25 accesible (consulta al hoster, es importante).
- Dominio o subdominio para el correo temporal.
- Registro A (o AAAA si usas IPv6) apuntando a la IP del servidor.
- Registro MX hacia el host elegido (normalmente el mismo subdominio).
- Firewall del servidor abierto para 25/tcp y para el puerto de la interfaz web.
Instrucciones paso a paso: inicio rápido con Docker Compose
La vía más sencilla para la mayoría: Docker Compose. Es bueno porque ofrece un arranque predecible, actualizaciones cómodas y el mínimo lío con dependencias. Además, es fácil deshacer todo si el proyecto deja de ser necesario.
La lógica de instalación: clonar el repositorio, levantar los contenedores, comprobar la interfaz web y luego verificar la recepción de mensajes. Después ya se puede ajustar la estética: configuración, TLS y limpieza automática.
Los comandos siguientes están pensados para un servidor tipo Ubuntu y suponen que Docker y Compose ya están instalados. Si no lo están, instálalos con los métodos oficiales de tu distribución.
Pasos de arranque:
# 1) Descargar el proyecto
git clone https://github.com/Zhoros/NortixMail.git
cd NortixMail
# 2) Iniciar
docker compose up -d
# 3) Comprobar que los contenedores están activos
docker ps
# 4) Ver los registros si algo no arrancó
docker compose logs -n 200 --no-colorVerificación tras el arranque:
- Abre la interfaz web en el navegador por IP o dominio (normalmente puerto 80, si no cambiaste la configuración).
- Asegúrate de que el puerto 25 está accesible desde fuera (lo más fácil es probar desde otra máquina o usar verificadores SMTP en línea).
- Envía un correo de prueba a cualquier dirección de tu dominio, por ejemplo test123@temp.yourdomain.tld, y comprueba si aparece en la interfaz.
Configuración, TLS y limpieza automática: para que el correo temporal siga siendo temporal
Tras el primer arranque normalmente querrás dos cosas: hacer la transmisión de mensajes más correcta (TLS) y evitar que el almacenamiento se convierta en un vertedero. En NortixMail la configuración está en el archivo config.json dentro de la carpeta data. Ahí puedes cambiar el intervalo de actualización y la cantidad de mensajes por página para que la interfaz no sea ni demasiado lenta ni demasiado ruidosa.
TLS es opcional, pero recomendable. SMTP históricamente puede funcionar sin cifrado y los mensajes podrían transitar en texto claro. Para códigos de confirmación no es el fin del mundo, pero si ya montaste tu solución, tiene sentido asegurar el canal.
Conectar TLS es directo: coloca el certificado y la clave privada en la carpeta data y el servicio se encargará. Es cómodo si ya emites certificados con ACME para el mismo dominio web.
Ahora lo importante sobre la desechabilidad. No todos los proyectos eliminan los mensajes por temporizador como a ti te convenga. El enfoque más fiable es añadir una limpieza automática programada. Por ejemplo, borrar los datos de correo cada 48 horas. Es honesto, transparente y no depende de cómo se implementa el almacenamiento internamente.
Ejemplo de limpieza automática (con cuidado: primero verifica dónde están los mensajes y prueba en una copia):
# Ejemplo: añadir una tarea cron que elimine los archivos de correo cada 48 horas
# 1) Abrir cron
crontab -e
# 2) Añadir la línea (ejemplo, ejecución a las 03:30 cada dos días)
30 3 */2 * * /usr/bin/find /path/to/NortixMail/data -type f -name "*.json" -deleteY un pequeño conjunto de prácticas para que el servicio no se convierta en un problema:
- Mantén el correo desechable en un subdominio separado; no lo mezcles con el principal.
- No uses direcciones temporales para cuentas con dinero, documentos o acceso a datos importantes.
- Vigila los registros y la carga: el puerto público 25 interesará a muchos bots.
- Si tu proveedor bloquea el puerto 25, elige otro hoster o confirma antes la posibilidad de abrirlo.
Enlace al proyecto: NortixMail en GitHub.
