Servidor de correo propio en un VPS: puerto 25, DNS inverso y por qué cae en spam

Qué decide realmente un receptor de correo, y en qué orden

Un servidor de correo receptor toma una serie de decisiones, y toma la mayoría antes de haber leído un solo byte de tu mensaje. El orden es la parte útil, porque un problema en la fase de conexión no se arregla con mejor contenido, y un mensaje perfectamente autenticado desde una dirección sin historial igualmente acaba en spam. Leer esta cadena en orden te dice dónde debes poner el esfuerzo, que casi nunca es donde la gente lo pone.

La primera decisión ocurre en la conexión TCP: ¿quién es este remitente y merece la pena siquiera hablar con él? En ese momento el receptor ya tiene tu dirección IP, su DNS inverso y la reputación que le asignan él o sus proveedores de listas negras. La segunda ocurre en el sobre SMTP —HELO y MAIL FROM—, donde se evalúa el SPF contra la IP que se conecta. La tercera llega con los datos del mensaje, donde se verifican las firmas DKIM y DMARC decide si alguno de los resultados de autenticación alinea con el dominio del encabezado From: visible. Solo después de todo esto empieza algo parecido a un filtrado de contenido, y para entonces la mayor parte del resultado ya está decidida.

De ahí se siguen dos cosas. Las victorias más baratas están al principio de la cadena: un registro PTR correcto cuesta un solo campo en un panel de control y elimina toda una categoría de rechazos. Y el final de la cadena —la parte que a todos preocupa, la redacción del mensaje— es la que menos margen de maniobra te da, y solo empieza a importar cuando todo lo anterior está limpio.

El puerto 25 es la parte más barata del problema

Casi todas las grandes nubes bloquean por defecto el tráfico saliente por el puerto 25, y desbloquearlo significa pedirlo. AWS, Google Cloud, Azure, Oracle Cloud y la mayoría de las grandes marcas de VPS traen el puerto 25 de salida filtrado de serie, y la solicitud de desbloqueo es un formulario ligado a una cuenta que ya lleva tu identidad, tu tarjeta y tu teléfono. Ahí es donde un plan de autoalojamiento muere en silencio la mayoría de las veces, y por eso la búsqueda que trae a más gente a una página como esta es alguna variante de qué VPS tiene el puerto 25 abierto.

Conviene tener claro qué hace cada puerto, porque los tres se confunden constantemente. El puerto 25 es de servidor a servidor: es como un MX le entrega un mensaje a otro, nunca lleva autenticación, y es el único puerto que importa para entregar correo a gente que no son tus usuarios. El puerto 587 es de envío (submission): tus propios clientes se autentican contra tu servidor antes de que este retransmita por ellos. El puerto 465 es lo mismo pero con TLS desde el primer byte; se dio por obsoleto en los noventa y luego se recuperó formalmente con la RFC 8314, y hoy es la opción sensata por defecto. Perder el 25 de salida te impide enviar al resto del mundo; perder el 25 de entrada impide que el mundo te envíe a ti, y es perfectamente posible tener uno sin el otro y pasarte una tarde entera culpando al DNS.

En BitVPS el puerto 25 de salida está desbloqueado por defecto en todos los planes y ubicaciones. No hay formulario ni proceso de excepción porque no hay nada que levantar. Los puertos 25, 465 y 587 de entrada están detrás de una limpieza de tráfico consciente del protocolo de correo, en vez de un filtro genérico de capa 3, y esa diferencia es la que importa durante un ataque: un filtro que entiende SMTP puede absorber una inundación de tráfico sin tirar también la conversación MX legítima que va detrás. La página de servidor de correo tiene los detalles, y la guía sobre protección DDoS explica en general qué significa y qué no significa esa limpieza de tráfico.

Tener el puerto 25 abierto es una condición necesaria, pero ni de lejos suficiente, y esa es la razón de que esta guía continúe durante otras tres mil palabras.

La dirección IP que te dan decide más que tu propia configuración

Tu configuración es un puñado de registros DNS y un día de trabajo. La dirección IP es una historia que no escribiste tú. Un /24 que se pasó 2019 enviando spam de farmacias se recuerda; una dirección reciclada de un cliente al que dieron de baja el mes pasado llega ya prejuzgada; un rango con vecinos ruidosos se juzga por asociación en los receptores que puntúan a nivel de /24. Nada de eso es visible desde dentro de la máquina, y nada de eso mejora con un main.cf más cuidado.

Así que comprueba la IP antes de decidirte, no después. Las listas negras públicas cuentan parte de la historia: Spamhaus es la que de verdad mueve la entregabilidad, con la SBL y la CSS listando remitentes observados, la PBL listando rangos cuyo operador ha declarado que no deberían enviar correo directamente, y la DBL listando dominios en lugar de direcciones. Barracuda y SpamCop merecen un vistazo y se limpian rápido cuando se corrige la causa. Sin embargo, las dos reputaciones que más pesan en el resultado son privadas: Google y Microsoft mantienen cada uno puntuaciones por IP y por dominio que no puedes consultar salvo a través de Postmaster Tools y SNDS, y solo a partir de que envíes lo suficiente para que tengan una opinión formada.

Dos avisos sobre las listas de comprobación que encontrarás en otros sitios. La mitad todavía te dice que revises SORBS: su propietario la retiró el 5 de junio de 2024 y sus zonas ahora no responden nada, así que una consulta contra SORBS no es un certificado de buena salud, sino una consulta muerta. Y trata con escepticismo los niveles 2 y 3 de UCEPROTECT: listan vecinos y sistemas autónomos enteros por asociación, y luego te invitan a pagar por una retirada exprés, razón por la cual la mayoría de los receptores serios los ignoran. Perseguir una entrada de nivel 3 es una forma de perder un fin de semana sin lograr nada. El que hay que tomarse en serio es el propio portal de reputación de Spamhaus.

Esta es también la parte en la que un proveedor ayuda o no ayuda. BitVPS comprueba cada dirección contra las listas principales durante el aprovisionamiento y la sustituye antes de que llegues siquiera a iniciar sesión si aparece en alguna, asigna los clientes de correo desde bloques /29 que no se han reciclado de un cliente de correo anterior en los últimos doce meses, y puede mover un /29 entre máquinas del mismo centro de datos sin cambiarte de IP, algo que importa enormemente cuando una dirección tiene una reputación que has tardado seis meses en construir. Nada de eso convierte una dirección en buena; la convierte en neutra, que es lo máximo que cualquier proveedor puede ofrecer honestamente.

El PTR (DNS inverso), el HELO y el registro A tienen que contar la misma historia

Esta es, con diferencia, la razón más habitual por la que se rechaza un servidor de correo bien instalado, y es lo más barato de arreglar de toda esta página. Tres nombres tienen que estar de acuerdo. Tu servidor anuncia un nombre de host en el HELO; ese nombre de host tiene un registro A que apunta a la dirección desde la que se conecta; y esa dirección tiene un registro PTR que apunta de vuelta al nombre de host. Resuélvelo hacia adelante y llegas a la dirección; resuélvelo hacia atrás y llegas al nombre. Ese viaje de ida y vuelta se llama DNS inverso confirmado hacia adelante (forward-confirmed reverse DNS), y desde febrero de 2024 un registro PTR válido ya no es un detalle agradable para Gmail, sino un requisito explícito para todo remitente, envíe en volumen o no.

Hay cuatro formas de que esto salga mal, en orden descendente de frecuencia. No hay PTR en absoluto, porque el proveedor no ofrece ese campo. Hay un PTR, pero es el genérico del proveedor: algo que termina en el dominio de la empresa de hosting, lo que le anuncia a todo receptor que es una dirección alquilada en un rango que en su mayoría no envía correo. El nombre de HELO está mal: el que trae por defecto el instalador, un nombre de host corto sin cualificar, o localhost, ninguno de los cuales resuelve. Y la que pilla hasta a los cuidadosos: la máquina tiene IPv6, el MTA prefiere IPv6 cuando el receptor publica un registro AAAA, y no hay PTR en la dirección v6, así que el correo a Gmail por IPv4 funciona perfectamente mientras el mismo correo por IPv6 se rechaza. O configuras bien el PTR de v6, o fijas el transporte con smtp_address_preference = ipv4 hasta que lo hagas.

En BitVPS el campo PTR es autoservicio desde el panel para cualquier dirección IPv4 e IPv6, acepta el FQDN que quieras sin sufijo de proveedor forzado, los cambios se propagan globalmente en menos de cinco minutos, y la edición masiva cubre hasta diez direcciones a la vez. La página de red tiene los detalles, y el motivo para que esto te importe es exactamente esta sección: un proveedor que te obliga a abrir un ticket para fijar el DNS inverso es un proveedor que te obligará a abrir un ticket cada vez que reconstruyas el servidor.

SPF, DKIM y DMARC: qué demuestra cada uno, y qué significa la alineación

Estos tres se publican como registros DNS, se configuran en una hora, y casi en todas partes se explican mal, normalmente como si fueran tres amuletos antispam intercambiables en lugar de tres afirmaciones distintas. SPF (RFC 7208) dice qué direcciones pueden enviar correo con un determinado remitente de sobre. DKIM (RFC 6376) añade una firma criptográfica sobre las cabeceras y el cuerpo, para que el mensaje pueda demostrar qué dominio se responsabilizó de él. Ninguno de los dos dice nada sobre la dirección que tu destinatario realmente ve.

Ese es el trabajo de DMARC (RFC 7489), y por eso alineación es la palabra que importa. DMARC pasa cuando SPF o DKIM pasan y el dominio que autenticaron coincide con el dominio del encabezado From: visible. Aquí es donde vive el fallo clásico: tu correo pasa SPF porque la dirección de rebote está en un dominio que controla el servidor emisor, pero ese dominio no es el que aparece en From:, así que no alinea, y sin una firma DKIM de respaldo, DMARC falla en un mensaje que en los registros parecía perfectamente autenticado. El otro clásico es publicar p=reject el primer día, antes de leer un solo informe, y descubrir un mes después que el sistema de facturación llevaba todo ese tiempo rechazado en silencio. Empieza con p=none y una dirección rua, lee lo que llega, y endurece la política después.

Dos notas operativas que valen más de lo que parecen. Mantén el registro SPF por debajo de diez consultas DNS: cada include: cuenta una, y anidar tres proveedores SaaS supera el límite y se convierte en un error permanente en lugar de un fallo blando. Y rota los selectores DKIM de vez en cuando, no nunca: un selector es barato de añadir, y tener ya publicado un segundo es la diferencia entre una rotación de claves de cinco minutos y una caída del servicio.

El listón subió en 2024, y otra vez en 2025

Durante veinte años, el mínimo para enviar correo fue más o menos «tener un PTR y no estar en Spamhaus». Eso cambió en febrero de 2024, cuando Google y Yahoo publicaron unos requisitos para remitentes casi idénticos y empezaron a exigirlos. Todo remitente —incluido tú, que envías cuatro mensajes al día— necesita ahora un registro PTR válido con DNS inverso confirmado hacia adelante, TLS en la conexión, y al menos uno de SPF o DKIM. Los remitentes que superan los cinco mil mensajes diarios a un mismo receptor necesitan SPF y DKIM y un registro DMARC, una cabecera de baja con un clic que funcione según la RFC 8058, y una tasa de quejas de spam por debajo del 0.3%.

Microsoft siguió el 5 de mayo de 2025 con una norma de la misma forma para Outlook.com, Hotmail y Live: los dominios que envían más de cinco mil mensajes al día a esos buzones de particulares deben tener SPF, DKIM y DMARC, y el correo que no cumple se envía primero a la carpeta de spam y después se rechaza directamente. Tanto el soporte para remitentes de Microsoft como las buenas prácticas de Yahoo merecen diez minutos de lectura antes de enviar nada.

La consecuencia práctica para un servidor personal o de un equipo pequeño no es que los umbrales te vayan a pillar (no lo harán), sino que la línea base sin autenticación ahora resulta genuinamente anómala. Antes era normal recibir correo sin registro DMARC desde una dirección sin historial. En 2026 tiene el mismo perfil que todo lo que los filtros se diseñaron para detener. Configúralo como si fueras un remitente masivo aunque no lo seas, porque el coste es una tarde y la alternativa es que te puntúen junto a una población a la que no perteneces.

Calentar una dirección que nadie ha visto nunca

Una dirección nueva no empieza tanto en neutro como en desconocida, y lo desconocido se trata con más sospecha cuanto más envías. La rampa de calentamiento que funciona es aburrida: empieza con correspondencia genuina con gente que de verdad la abrirá y responderá, mantén el volumen diario más o menos estable y déjalo crecer poco a poco en lugar de a saltos, y nunca apuntes a una dirección recién estrenada con una lista que has comprado o exportado de algún sitio. La interacción es la señal que convierte lo desconocido en confiable, y no hay atajo que la produzca.

Mide con las herramientas que te dan los propios receptores, no mirando tu propia bandeja de entrada. Postmaster Tools de Google muestra la reputación de dominio e IP, la tasa de quejas de spam y la tasa de éxito de autenticación una vez verificas el dominio, aunque se queda vacía hasta que envías lo suficiente como para que agregue algo, lo que en un servidor personal puede significar nunca, y no pasa nada. SNDS de Microsoft hace lo mismo para Outlook.com y se combina con el Junk Mail Reporting Program, que te reenvía las quejas directamente. Un servicio de puntuación de un solo uso es útil para detectar un registro roto en diez segundos, e inútil para cualquier otra cosa: no te dice nada sobre reputación, porque tampoco tiene historial contigo.

Sé honesto contigo mismo sobre el receptor más difícil. Outlook.com es donde una dirección nueva lo pasa peor durante más tiempo: es habitual que un servidor bien configurado y con autenticación perfecta acabe en spam allí durante semanas, mientras Gmail lo acepta desde el primer mensaje. La solución es tiempo, constancia y destinatarios que saquen el mensaje de la carpeta de spam, no otro registro DNS. Si la entregabilidad en Outlook.com desde el primer día es un requisito de negocio y no una preferencia, esa es una de las señales de que necesitas un relay en lugar de un remitente autoalojado, que es el tema de la última sección.

Qué instalar, y cuánta máquina necesita

Cuatro combinaciones cubren a casi todo el mundo. Postfix junto con Dovecot para IMAP y rspamd para el filtrado es el despliegue de referencia: tres demonios, configuración en texto plano, y cada mensaje de error que vas a ver ya está respondido en algún sitio. OpenSMTPD hace el mismo trabajo con un archivo de configuración que puedes leer de un tirón, lo cual vale más de lo que parece a las tres de la madrugada. Stalwart es un único binario que habla SMTP, IMAP y JMAP con filtrado incorporado, y hoy es la opción más agradable para empezar de cero. Y Mailcow o Mail-in-a-Box te montan todo el conjunto, webmail incluido, al precio de una pila que no elegiste tú y que no es fácil desmontar por piezas.

El dimensionamiento depende menos de los buzones que de lo que le enganches por delante. SMTP e IMAP en sí son baratos; unas cuantas docenas de buzones son un margen de error en cualquier máquina moderna. La memoria se la lleva el filtrado. rspamd es modesto, unos pocos cientos de megabytes con sus mapas cargados. ClamAV no lo es: solo la base de datos de firmas lo empuja bastante por encima de un gigabyte de memoria residente, y es el componente con más probabilidades de hacer que una instancia pequeña empiece a usar swap, lo que en un servidor de correo significa que la cola se acumula y la entrega se ralentiza hasta el punto de que los receptores empiezan a diferirte los envíos. Instálalo si tienes la RAM, sáltatelo si no, y deja que rspamd cargue con el peso.

Trasladado a planes reales: un Starter a $8.50 con 2 vCPU, 4 GB de RAM y 60 GB de NVMe hace correr Postfix, Dovecot y rspamd sin problemas para un dominio personal, siempre que dejes fuera ClamAV. Un Growth a $13.50 con 4 vCPU, 8 GB y 120 GB es el tamaño a partir del cual dejas de pensar en ello: de veinte a treinta buzones con filtrado completo, y de sobra margen para un almacén de correo que crece durante años. El almacenamiento es el eje que realmente se agota primero, porque el correo lo guarda para siempre todo aquel que alguna vez lo ha recibido.

Ponerlo en marcha en el orden correcto

1. Apunta el dominio y despliega la instancia. Decide el nombre de host con el que se identificará el servidor —mail.example.com es la convención habitual—, publica su registro A, añade AAAA solo si vas a enviar por IPv6, y publica el MX del dominio apuntando a ese nombre. Elige la ubicación más cercana a la gente con la que te correspondes; en BitVPS la instancia está lista unos sesenta segundos después de confirmarse el pago, con el puerto 25 de salida ya abierto.

2. Configura el DNS inverso para que coincida. Pon el PTR de la dirección IPv4 —y de la dirección IPv6, si publicaste un AAAA— exactamente igual al nombre de host del paso uno. Directo e inverso deben coincidir en ambos sentidos. Es un solo campo del panel, y es el minuto de mayor valor de todo el procedimiento.

3. Abre los puertos correctos en ambos sentidos. El 25 de salida para entregar, el 25 de entrada para recibir, el 587 y el 465 para que tus propios usuarios envíen, el 993 para IMAP, todo lo demás cerrado. Un cortafuegos que permite el 25 de salida pero no el de entrada parece exactamente un problema de DNS durante la primera hora de depuración, y no lo es.

4. Instala el MTA y dale una identidad real. Postfix, OpenSMTPD o Stalwart; pon el nombre de HELO igual al nombre de host del paso uno; activa TLS con un certificado para ese nombre. Let's Encrypt es gratis y es lo que presenta la mayor parte de internet. Envíate un mensaje a ti mismo y lee las cabeceras antes de continuar: cada paso posterior da por hecho que este ha funcionado.

5. Publica SPF, DKIM y DMARC. Un registro SPF que liste la dirección emisora, terminado en ~all mientras haces pruebas. Una clave DKIM de 2048 bits con su selector publicado y la firma activada. Un registro DMARC en p=none con una dirección rua para que empiecen a llegar informes. Tres registros DNS, sin coste, una hora como mucho.

6. Lee los resultados de autenticación, no la bandeja de entrada. Envía a Gmail, a Outlook.com y a un receptor corporativo, y luego abre Authentication-Results en cada uno. Quieres ver spf=pass, dkim=pass, dmarc=pass, y que la alineación sea con el dominio del From: visible. Acabar en spam con los tres en verde es un problema de reputación; acabar en spam con un fallo es un problema de configuración. Se arreglan de formas completamente distintas, y confundirlos hace perder semanas.

7. Endurece la política cuando los informes estén limpios. Tras una o dos semanas de informes DMARC en los que ninguna fuente legítima falle, pasa a p=quarantine, y más adelante a p=reject, y cambia el SPF de ~all a -all. Endurecer la política antes de leer los informes es la forma habitual en que la gente bloquea sus propias facturas durante un mes sin darse cuenta.

8. Añade las piezas que todo el mundo olvida. Publica MTA-STS y TLS-RPT para que otros remitentes sepan que deben insistir en TLS contigo, añade DANE si tu zona está firmada, pon rspamd delante del buzón, haz copia de seguridad del almacén de correo en algún sitio que no sea esta misma máquina, y cífralo en reposo: la guía de cifrado de disco completo explica qué protege eso y qué no. Después vigila la cola de salida: una cola que crece calladamente es el primer síntoma de un problema de reputación, y aparece días antes de que notes que faltan respuestas.

Cuándo autoalojar el correo es la herramienta equivocada

Hay casos en los que llevar tu propio remitente es un mal negocio, y dejarlo claro es más útil que otro párrafo de ánimo. El marketing masivo en frío es el más obvio: una dirección recién estrenada, sin historial, enviando miles de mensajes es exactamente la firma que los filtros existen para detectar, y ninguna configuración la salva. El correo transaccional donde perder un mensaje cuesta dinero —restablecimientos de contraseña, confirmaciones de pedido, códigos de doble factor— pertenece a una infraestructura con reputación ya consolidada, porque las dos semanas que una dirección nueva tarda en demostrarse son dos semanas de tickets de soporte. Y cualquier equipo sin alguien que vaya a mirar la cola de correo un domingo es un equipo que descubrirá que su salida lleva desde el viernes en diferido.

Hay también una contrapartida de anonimato que la mayoría de los artículos se saltan. Un servidor de correo es lo menos anónimo que puedes montar. Publica un dominio, una dirección estable, un registro PTR que nombra ese dominio, un registro MX que los une, y le entrega a cada destinatario un juego completo de cabeceras que describen el recorrido. Anonimato y un MX público tiran en direcciones opuestas, y si el motivo por el que estás aquí es la privacidad y no el control, lee hasta qué punto es rastreable el hosting pagado en cripto antes de montar nada. Autoalojar sí elimina de verdad a un tercero de tu correo almacenado y sus metadatos, lo cual es una ganancia real y que merece la pena; no vuelve anónimo el correo en sí, y no puede hacerlo, porque la mitad de cada conversación vive en el buzón de otra persona.

El arreglo que le funciona a la mayoría de la gente es repartir la carga. Mantén en un proveedor con reputación el correo que tiene que llegar sí o sí, autoaloja un segundo dominio para la correspondencia que quieres sacar de infraestructura de terceros, y deja que cada uno cargue con lo que se le da bien. Cuesta una zona DNS extra, significa que ningún sistema hace un trabajo para el que es malo, y es lo que de hecho hace buena parte de la gente que lleva un servidor de correo en BitVPS. Envíes lo que envíes, que sea solo con consentimiento previo: las listas compradas quedan fuera de nuestra política de uso aceptable y son la forma más rápida de quemar una dirección que estaba limpia cuando te la entregamos.