Autoalojar un servidor de correo en un VPS.
Mailcow, Mail-in-a-Box, iRedMail — y el proveedor que lo permite.
El correo electrónico autoalojado es más difícil de lo que debería ser en 2026, y casi toda la dificultad reside en tres lugares — puerto 25 bloqueado en la mayoría de los proveedores, reputación de IP nueva, registros DNS que deben alinearse perfectamente. Esta guía nombra los requisitos previos, compara los tres stacks serios y recorre el camino de la entregabilidad.
- 01
Tres muros antes de cualquier instalación: el puerto 25 saliente debe estar abierto, la IP necesita un historial de reputación limpio y el registro PTR debe coincidir con el nombre de host HELO. Sin los tres, ningún stack de software entregará correo a Gmail.
- 02
El proveedor importa más que el software. El VPS de NordBastion abre el puerto 25 por defecto y establece los registros PTR desde el panel en menos de una hora — la postura sin KYC significa que no hay paso de verificación de identidad.
- 03
Elija el stack según su preferencia operativa: Mail-in-a-Box (script, 2 GB, por defecto), Mailcow (Docker, 6 GB, interfaz moderna), iRedMail (flexible, manual, para el operador con experiencia).
Tres muros. Choque con cualquiera de ellos y el resto de la guía es inútil.
La razón por la que «simplemente instale un servidor de correo» es un mal consejo es que la instalación es el 10% fácil del problema. El otro 90% son requisitos previos a nivel de infraestructura que el software no puede hacer por usted. Confirme los tres antes de instalar nada.
Muro 1 — puerto 25 saliente. La entrega SMTP es TCP/25 desde su servidor al intercambiador de correo del destinatario. La mayoría de los hyperscalers y proveedores de VPS económicos bloquean esto saliente por defecto a nivel de hipervisor para limitar el spam. Pruébelo primero: nc -zv smtp.gmail.com 25 — si la conexión expira, su proveedor bloquea el puerto 25 y ningún correo saldrá jamás. Abra un ticket solicitando el desbloqueo, o cambie a un proveedor que no lo bloquee.
Muro 2 — reputación de IP. Compruebe la IP en Spamhaus, SORBS, Barracuda y Cisco Talos (mxtoolbox.com/blacklists.aspx). Si aparece en alguna lista, la IP tiene historial previo; la entregabilidad será deficiente hasta que se elimine de la lista o cambie. Las IPs nuevas sin historial previo están bien — empiezan en el grupo de «remitente neutral / desconocido», que es el punto de partida correcto.
Muro 3 — alineación del registro PTR. El PTR (DNS inverso) de la IP de su VPS debe coincidir con el nombre de host HELO que anuncia Postfix. Si su servidor anuncia «mail.example.com» pero el PTR de la IP dice «static-12-34-56-78.example-host.net», Gmail diferirá o rechazará. El PTR lo establece el proveedor de VPS en la IP, no usted en su dominio. La mayoría de los proveedores exponen un control en el panel para esto; algunos requieren un ticket de soporte. NordBastion lo expone desde el panel.
Si supera los tres, está listo para instalar. Si falla cualquiera de ellos, corrija primero.
Por qué la mayoría de los proveedores bloquean el puerto 25. Y el ángulo sin KYC.
El SMTP saliente es el favorito de los spammers. Un VPS comprometido con el puerto 25 abierto puede enviar 100.000 mensajes al día antes de que alguien lo note, y todas las quejas de abuso llegan a la bandeja de entrada del proveedor. Para mantener eso bajo control, la mayoría de los proveedores de VPS o bien bloquean el puerto 25 saliente en el borde de la red, o bien requieren una verificación de identidad y una aprobación de uso aceptable antes de desbloquearlo por cliente.
Ese modelo falla para un proveedor que prioriza la privacidad. Toda la propuesta de un VPS sin KYC es que los clientes no tienen que identificarse. Añadir un paso de «pero para el puerto 25 sí» sería una contradicción doctrinal. Así que la industria de proveedores de privacidad se divide en dos grupos: proveedores que rechazan el puerto 25 por completo (descarta el correo autoalojado) y proveedores que lo abren para todos sin verificación de identidad (la categoría más rara y más interesante).
NordBastion pertenece al segundo grupo. Cada <a href="/es/vps/" class="text-nord-cyan border-b border-nord-cyan/40 hover:border-nord-cyan transition">VPS que entregamos</a> tiene TCP/25 saliente abierto desde el primer arranque. No hay verificación de identidad, ni aceptación de condiciones de uso, ni tickets de desbloqueo manual. El abuso se supervisa mediante patrones de tráfico saliente, no mediante la identidad del cliente — un VPS que de repente emite 10 veces su volumen habitual queda marcado, independientemente del titular de la cuenta. El equilibrio funciona porque las trampas antispam operan en la capa de protocolo, no en la capa de identidad.
La implicación práctica: NordBastion + una IP nueva limpia + un registro PTR configurado desde el panel es la lista de verificación de los tres muros superada en menos de una hora. El resto de la guía es la instalación real.
Los tres stacks comparados. Mailcow vs Mail-in-a-Box vs iRedMail.
Mail-in-a-Box. Un único script de shell que convierte una instalación limpia de Ubuntu 22.04 en un servidor de correo completo — Postfix, Dovecot, Roundcube webmail, contactos/calendario equivalentes a Nextcloud, SpamAssassin, orientación DNS. Los valores predeterminados son sensatos, la interfaz de administración es mínima, el consumo de recursos es cómodo con 2 GB de RAM. La mejor opción para quien quiere el resultado sin aprender Docker. Las actualizaciones siguen la cadencia del proyecto upstream, normalmente dos o tres al año.
Mailcow. Un stack basado en Docker Compose — Postfix, Dovecot, Rspamd, ClamAV, SOGo, Nginx, MariaDB, Redis, Solr — con una elegante interfaz de administración web (2FA, ActiveSync, calendarios, libros de direcciones, cuotas de buzón). Necesita 6 GB de RAM como mínimo práctico; cómodo con 8. La mejor opción para quien quiere una configuración moderna y modular con filtrado de spam de primer nivel y ActiveSync para móviles. Con lanzamientos continuos; el docker-compose.yml moby se distribuye desde el repositorio del proyecto.
iRedMail. La elección tradicional — un script de shell que instala el stack clásico Postfix + Dovecot + Amavisd-new + ClamAV sobre Debian / Ubuntu / CentOS. La interfaz de administración (iRedAdmin) es funcional más que bonita. La mejor opción para el operador que ya tiene opiniones sobre cada componente y quiere control directo de los archivos de configuración. La edición Pro añade una administración más rica; la edición de código abierto es completamente utilizable.
Lo que todos comparten. Los tres producen un servidor de correo completamente funcional con SMTP / IMAP / envío / DKIM / SpamAssassin o Rspamd / webmail. Los tres dependen de los mismos mecanismos de entregabilidad a nivel de protocolo (SPF / DKIM / DMARC / PTR). Los tres necesitan el mismo mantenimiento mensual. La elección es sobre ergonomía, no sobre si el correo funcionará.
Los registros DNS. Los cinco, perfectamente, o nada.
La entregabilidad moderna del correo depende de cinco registros DNS. Con los cinco correctos, aterriza en la bandeja de entrada de Gmail y Outlook. Si falta uno o lo tiene a medias, aterriza en spam — o peor, se descarta silenciosamente en la capa SMTP sin rebote.
1. MX (registro). example.com. MX 10 mail.example.com. — indica al mundo dónde entregar el correo para el dominio.
2. A (registro). mail.example.com. A 1.2.3.4 — la IP de su VPS de correo.
3. PTR (inverso). [redacted-ip].in-addr.arpa. PTR mail.example.com. — se configura en la IP desde el proveedor de VPS. Debe coincidir con el HELO. NordBastion: configúrelo desde el panel en la hora en que se aprovisiona el VPS.
4. SPF (registro). example.com. TXT "v=spf1 mx -all" — declara que solo los hosts MX pueden enviar correo para el dominio. El -all (fallo duro) es correcto cuando se autoaloja; ~all (fallo suave) es la forma permisiva antigua a evitar.
5. DKIM (registro). default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=<clave-larga-del-admin-de-mailcow>" — la clave pública que usa el receptor para verificar la firma DKIM que su servidor añade a cada mensaje saliente. La clave privada permanece en el servidor de correo; la mitad pública va en DNS.
6. DMARC (registro). _dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[redacted-user]@[redacted-host]" — indica a los receptores qué hacer con los mensajes que fallan SPF/DKIM (rechazar), y adónde enviar los informes agregados. Empiece con p=none durante la primera semana para monitorear, luego cambie a p=reject.
Verifique todo el stack con la comprobación de salud de correo de mxtoolbox.com después de cada cambio. Verde en todos los apartados es el único estado aceptable.
Entregabilidad. Gmail, Outlook, el calentamiento.
Una IP nueva, incluso con DNS perfecto, empieza en el grupo de «remitente neutral» en Gmail y Outlook. El primer mes es un ejercicio de construcción de reputación. El objetivo es parecerse exactamente a un pequeño remitente legítimo: bajo volumen, cadencia constante, autenticación perfecta, destinatarios que abren y responden.
Semana 1. Envíe correo solo a sus propias cuentas externas (Gmail, Outlook, Yahoo, Proton). Lea cada mensaje en la bandeja de entrada del destinatario, marque «No es spam» si llega al spam, responda. La respuesta es la señal de reputación que más importa. Volumen: 5–20 mensajes al día.
Semanas 2–4. Añada un puñado de corresponsales que respondan de forma natural. Suscríbase a una o dos listas de correo que envíen a su nueva dirección (anuncios técnicos, boletines de proyectos); la interacción con entrantes de remitentes establecidos ayuda a los salientes. Volumen: 50–200 al día.
Meses 2–3. En este punto la IP tiene un historial. Migre los entrantes desde su antiguo proveedor mediante reenvío SMTP para que la nueva dirección empiece a recibir tráfico real. Continúe supervisando las listas DNSBL mensualmente. Hacia el tercer mes, la entregabilidad es prácticamente indistinguible de la de un proveedor alojado.
Lo que destruye el calentamiento. Envío masivo saliente el primer día. Enviar a una lista de contactos obsoleta con direcciones inactivas (Gmail cuenta los rebotes como una señal muy negativa). Campañas de boletines. Cualquiera de estas acciones en la semana 1 retrasa la reputación de la IP semanas. La disciplina es la paciencia, no la técnica.
Mantenimiento. Una hora al mes, o se rompe.
Un servidor de correo autoalojado no es de «configurar y olvidar» — el ecosistema del correo electrónico evoluciona continuamente, y el coste de quedarse atrás es una degradación silenciosa de la entregabilidad que solo se nota cuando un amigo dice «nunca recibí tu correo». La rutina de mantenimiento mensual es pequeña pero no negociable.
Lista de verificación mensual. (1) Verificación DNSBL — análisis de listas negras en mxtoolbox, solicitar eliminación si aparece. (2) Verificación de renovación de certificado — Let's Encrypt debe renovar automáticamente, pero conviene confirmarlo. (3) Ejecución del actualizador — update.sh de Mailcow, actualización de MIAB o apt upgrade en iRedMail. (4) Análisis de registros — Rspamd / Postfix en busca de tasas de rechazo inusuales. (5) Verificación de copia de seguridad — restaurar la última copia en un directorio de prueba y confirmar que el spool de correo se descomprime correctamente.
Trimestral. Ejercicio completo de restauración de copia de seguridad a un segundo VPS, verificar que el inicio de sesión en el webmail funciona. Revisar las reglas de SpamAssassin / Rspamd — las puntuaciones bayes se desvían, reentrenar con ham/spam reciente. Revisar los informes agregados DMARC en busca de uso no autorizado del dominio.
Con la llegada de una versión principal. Tome primero una instantánea del VPS (panel de NordBastion: un clic). Tome una copia de seguridad actualizada de la base de datos fuera del servidor. Ejecute la actualización. Verifique el envío SMTP, la recuperación IMAP, el inicio de sesión en el webmail, la sincronización móvil y cada cuenta del servidor. Revierta mediante la instantánea si algo falla. Tiempo: 30–60 minutos una o dos veces al año.
El punto de quiebre. Las personas abandonan el correo autoalojado cuando omiten tres meses de actualizaciones, luego llega un cambio mayor de DSA / DMARC, la entregabilidad se degrada silenciosamente y un amigo les dice que el correo está rebotando. Incorpore la hora mensual al calendario desde el primer día y el punto de quiebre nunca llega.
Preguntas, respondidas.
Ocho preguntas que surgen al iniciar y ejecutar un servidor de correo autoalojado en 2026.
¿Sigue siendo realista autoalojar el correo electrónico en 2026?
Sí — pero solo si entiende los tres problemas estructurales y acepta el coste operativo. Problema uno: el puerto 25 saliente está bloqueado por defecto en la mayoría de los proveedores de VPS y desbloquearlo requiere conversación con el equipo de ventas. Problema dos: el espacio de IP nuevo tiene una reputación de entregabilidad «fría» que tarda semanas en calentarse ante Gmail y Outlook. Problema tres: el ciclo de mantenimiento mensual (verificaciones DNSBL, renovación TLS, eliminación de listas negras) es no negociable. Con esos manejados, el correo autoalojado es más saludable en 2026 que en 2020.
¿Qué stack debo elegir — Mailcow, Mail-in-a-Box o iRedMail?
Mail-in-a-Box para el lector que quiere que «simplemente funcione». Un script de instalación, valores predeterminados sensatos, funciona con 2 GB. Mailcow para el lector que quiere «una interfaz de administración moderna y Docker»; necesita 6 GB, le da Rspamd, ActiveSync, SOGo y una elegante administración web. iRedMail para el lector que «tiene un stack específico que quiere»; muy flexible, muy manual, la elección del veterano. Los tres producen un servidor de correo completamente funcional; la elección es sobre ergonomía, no sobre el resultado.
¿Por qué está bloqueado el puerto 25 en la mayoría de los proveedores de VPS?
Porque los spammers lo abusan. Los hyperscalers y los proveedores de VPS económicos bloquean TCP/25 saliente en el hipervisor o el firewall por defecto para reducir las quejas por abuso — desbloquearlo requiere abrir un ticket de soporte, verificación de identidad y una aprobación de «AUP para correo electrónico». Los proveedores que priorizan la privacidad y rechazan la verificación de identidad no pueden ofrecer el desbloqueo; los proveedores convencionales que ofrecen el desbloqueo requieren KYC. La combinación «sin KYC Y puerto 25 desbloqueado» es poco frecuente y es la razón por la que esta guía está en este sitio.
¿NordBastion desbloquea el SMTP saliente para los clientes de servidores de correo?
Sí — el puerto 25 saliente está abierto en todos los VPS de NordBastion sin necesidad de un ticket de soporte. No ejecutamos un paso de verificación de identidad antes de permitir SMTP, porque la postura sin KYC es la doctrina; el abuso saliente se monitorea en patrones de tráfico, no en la identidad del cliente. Este es el diferenciador que hace que un servidor de correo autoalojado sea realmente posible en un proveedor de privacidad.
¿Qué es un registro PTR y por qué mi correo sigue siendo rechazado sin uno?
Un registro PTR (puntero) es la búsqueda DNS inversa de su IP — la respuesta a «¿a qué nombre de host pertenece esta IP?». Muchos grandes proveedores de correo (Gmail, Microsoft, Yahoo) rechazan el correo entrante de servidores cuyo PTR no coincide con el nombre de host HELO de la conversación SMTP. El PTR se configura en la IP, no en el dominio — en un VPS, eso significa pedir al proveedor que establezca el PTR de su IP a mail.example.com. NordBastion configura los registros PTR bajo petición desde el panel en menos de una hora.
¿Cuánto tiempo lleva el calentamiento de la reputación de IP?
De dos a seis semanas de tráfico normal para salir del grupo de «remitente nuevo» en Gmail y Outlook, más tiempo si envía con poca frecuencia. Los aceleradores son: volumen saliente bajo y constante (50–200 mensajes al día durante la primera semana, escalar gradualmente), alineación perfecta de SPF + DKIM + DMARC en cada mensaje, cero entradas en DNSBL, interacción de los destinatarios (aperturas y respuestas). Los factores destructivos son: envío masivo el primer día, registros de autenticación ausentes o mal alineados, y envío a trampas de spam.
¿Necesito un VPS dedicado para el correo o puedo ejecutarlo junto a mis otros servicios?
Se recomienda encarecidamente un servidor dedicado. El software de servidor de correo (Postfix, Dovecot, Rspamd, ClamAV, la base de datos, el webmail) tiene un perfil particular de RAM y almacenamiento, y la reputación de la IP está vinculada específicamente al tráfico de correo — colocarla junto a un relé de salida Tor o un nodo Bitcoin es arriesgarse a que la IP aparezca en alguna lista indeseable. Un segundo VPS a $5.90/mes es un seguro económico.
¿Cuál es la carga de mantenimiento continuo?
Lista de verificación mensual: confirmar que la IP no está en las DNSBL de Spamhaus / SORBS / Barracuda (5 min — mxtoolbox.com); confirmar que los certificados de Let's Encrypt se han renovado (1 min); analizar los registros de Rspamd / Postfix en busca de patrones inusuales (5 min); ejecutar el actualizador de Mailcow / MIAB (10 min); verificar que la última copia de seguridad se restaura correctamente (15 min una vez por trimestre). Total: una hora al mes, con una hora más intensa dos veces al año cuando llegan versiones principales.
Puerto 25 abierto, PTR desde el panel, sin KYC, pago en criptomoneda.
Mail-in-a-Box funciona en Ravelin (2 vCPU, 4 GB, $5.90/mes). Mailcow requiere Iron (4 vCPU, 8 GB, $24.90/mes). Ambos vienen con el puerto 25 ya abierto.
Última revisión · 2026-05-20 · Fuentes · Documentación upstream de Mailcow / Mail-in-a-Box / iRedMail, Gmail Postmaster Tools, RFC 5321 / 6376 / 7489 · Cadencia · anual
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Bitwarden-compatible password vault under your own control.
Files, calendar, contacts, photos — owned, not rented.
A meta search engine that does not log you — because you own it.
What “no KYC” actually means — and what it does not.