Ejecutar un servidor de correo en un VPS: qué te mantiene de verdad fuera del spam

Tu servidor de correo funciona. Postfix arranca, los logs se ven limpios, envías un mensaje de prueba a tu Gmail — y aterriza en spam. O simplemente desaparece. Nada en tu config está roto. El software hizo exactamente lo que le dijiste.

El problema es que el servidor del otro extremo aún no confía en tu IP, y el email esconde toda una pila de pequeñas verificaciones de confianza que tienen que alinearse antes de que el buzón de un desconocido te deje entrar. Acierta esas y la entrega se encarga sola en su mayor parte. Falla una y estás gritando a una carpeta de spam.

Tres cosas cargan con la mayor parte del peso: el DNS inverso, la autenticación del remitente, y si tu host siquiera te deja hablar en el puerto 25. Ninguna es difícil. Solo son fáciles de olvidar, y cada una es un veto silencioso.

La que todos olvidan: DNS inverso

El DNS directo es la parte que conoces — un nombre apunta a una IP. El DNS inverso es el espejo: una IP apunta de vuelta a un nombre. Ese registro se llama PTR, y vive con quien controla la IP, no en la zona de tu dominio.

Aquí está por qué importa. Cuando tu servidor abre una conexión al SMTP de Gmail, una de las primeras cosas que hace el lado receptor es una búsqueda inversa de tu IP — ¿quién es este? Ejecútala tú mismo:

dig -x 203.0.113.19 +short

Si eso vuelve con algo como static.203-0-113-19.rev.example-isp.net, o vuelve vacío, ya has perdido puntos. Ese nombre genérico dice «un VPS cualquiera», y peor, no coincide con el nombre de host con el que tu servidor se presenta en el saludo HELO. Los servidores receptores marcan esa discrepancia con fuerza. Algunos rechazan directamente.

Lo que quieren ver es un PTR que coincida con tu nombre de host de correo. Si tu servidor dice HELO mail.example.com, la búsqueda inversa de su IP debería devolver mail.example.com. El directo y el inverso concuerdan, la historia es consistente, y pareces un servidor de correo de verdad en lugar de una máquina secuestrada.

Configurar un PTR ha significado tradicionalmente abrir un ticket de soporte con quien posee el bloque de IP y esperar. En los planes con IP dedicada de EQVPS es un campo en tu panel — teclea el nombre de host, se escribe directo en la registry a través de la API del proveedor, y está en línea en segundos. Ese es todo el sentido de hacerlo autoservicio: el DNS inverso es el paso que la gente se salta porque solía ser molesto.

Autenticación: SPF, DKIM, DMARC

Estos tres registros DNS le dicen a los servidores receptores que el correo que dice ser de tu dominio realmente lo es. Sáltatelos y eres un desconocido sin verificar.

• SPF es un registro TXT que lista qué servidores pueden enviar por tu dominio. Gmail lo comprueba y pregunta: ¿vino este mensaje de una IP que autorizaste?
• DKIM firma criptográficamente cada mensaje saliente. El receptor saca tu clave pública del DNS y verifica que la firma no fue falsificada en tránsito.
• DMARC ata las dos y le dice a los receptores qué hacer cuando una verificación falla — nada, cuarentena o rechazo — y a dónde enviar informes.

Quieres las tres. SPF y DKIM prueban que el correo es legítimamente tuyo; DMARC convierte esa prueba en una política. Son quizá veinte minutos de ediciones de DNS, y es la diferencia entre «remitente verificado» y «¿quién?».

El puerto 25, y por qué está cerrado

Aquí está la que sorprende a la gente. El puerto 25 saliente — el puerto que los servidores de correo usan para hablar entre sí — está bloqueado por defecto en esencialmente todos los hosters VPS. Nosotros también.

Eso es deliberado. El puerto 25 es el cañón de spam clásico, así que se mantiene cerrado hasta que lo pides y dices qué estás enviando de verdad. Lo abrimos a petición en lugar de dejarlo abierto para cualquiera que levante un servidor.

Y hay una salvedad honesta aquí que vale la pena decir claramente: con un puerto 25 abierto viene responsabilidad. Un script comprometido o un relay mal configurado bombeando spam, y la reputación de tu IP se acaba — a veces durante semanas. En una subred compartida ese desastre salpica a tus vecinos, que es exactamente por qué los hosters son cautelosos con ello. Si nos pides que abramos el 25, mantén tu servidor limpio, porque la reputación que proteges es en parte también nuestra.

Por qué la IP dedicada no es opcional

Todo esto vuelve en círculo a un requisito: la IP tiene que ser tuya. En un setup NAT o una dirección compartida no puedes configurar tu propio PTR, porque la dirección no es exclusivamente tuya para apuntar. También heredas cualquier reputación que la IP compartida ya lleve — y no tienes ni idea de qué hizo el último inquilino con ella.

Una IP dedicada te da un PTR que controlas, una reputación que es tuya para construir, y un punto de partida limpio. Para el correo saliente eso no es un nice-to-have; es el suelo.

El fondo honesto

Autoalojar el email en 2026 es trabajo real y continuo. No es configurar-y-olvidar — vigilarás listas negras, rotarás claves DKIM, y de vez en cuando averiguarás por qué un proveedor específico empezó a hacerte greylisting. Si esto es un proyecto paralelo de bajo riesgo, honestamente, reenviar a través de un proveedor de correo existente te ahorrará dolores de cabeza.

Pero si quieres control de verdad — tus datos, tu dominio, nadie más leyendo las cabeceras — es muy factible en un VPS pequeño. La fontanería de confianza de arriba es cerca del 90 % de la batalla, y nada de ello es exótico. Consigue una IP dedicada, configura el PTR para que coincida con tu nombre de host, publica SPF/DKIM/DMARC, pídenos que abramos el puerto 25, luego envía una prueba a través de una herramienta como mail-tester.com y arregla lo que marque. Haz eso y ya no estás gritando a una carpeta de spam — eres un servidor de correo en el que los buzones de la gente confían de verdad.