VPS para servidor de correo propio — puerto 25, PTR, sin KYC

Monta Mailcow o Postfix en un VPS sin KYC: puerto 25 abierto por política, rDNS editable y SPF/DKIM/DMARC bajo tu control. Factura en cripto, Core desde $4.80/mes anual.

Aquí el puerto 25 es política, no un permiso que hay que pedir

La verdad contraintuitiva del correo autoalojado es que el puerto es la parte fácil. La mayoría de la industria del hosting bloquea el puerto 25 saliente por defecto porque su espacio de direcciones quedó quemado por spammers años atrás, y desbloquearlo se convierte en una negociación: tickets, justificaciones de negocio, plazos de espera. En las líneas VPS y dedicadas de aquí el bloque nunca se instaló — el SMTP entre servidores está abierto por política, y no hay solicitud que presentar porque no hay nada que levantar.

El mecanismo es casi anticlimático. Los agentes de transferencia de correo hablan entre sí por el puerto 25, según la especificación SMTP, y tu servidor llega haciendo exactamente eso: elige cualquiera de las doce ubicaciones, instala la imagen y el MTA puede entregar correo saliente en cuanto lo montas. El registro inverso se edita desde el panel de cliente sin ticket, así que la mitad de identidad del handshake también la controlas tú — todo el panorama está detallado en la guía de requisitos sin KYC.

Donde se rompe es en las expectativas, no en la infraestructura. La gente que llega de grandes proveedores cloud abre un ticket de desbloqueo por inercia y se queda genuinamente confundida cuando soporte responde que no hay nada que desbloquear. El error contrario es asumir que un egreso abierto implica entregabilidad: un puerto abierto significa que tu servidor puede hablar; si alguien te escucha lo deciden el registro de puntero, los registros de autenticación y los hábitos de reputación de las secciones siguientes.

La política cubre todo el catálogo, lo que importa más de lo que suena. El mismo puerto abierto aplica en Reikiavik y en Singapur, en el plan más pequeño y en metal dedicado — la línea bare metal incluida — y los niveles dedicados añaden IPMI para que puedas ver arrancar el MTA fuera de banda cuando un experimento con el firewall sale mal a las tres de la madrugada. El filtrado DDoS está incluido en todos los niveles, así que la ruta de correo hereda la misma base que alquila el resto del catálogo. Nada del correo cambia entre banderas; la ley que lo rodea, sí.

El egreso abierto, entonces, es el mínimo que este pago da por sentado. Todo lo que de verdad decide si tu correo llega es configuración que te pertenece, y el primer punto es el que la mayoría de las guías te deja saltar: el registro de puntero, que la siguiente sección pone al frente del orden de operaciones por una razón.

Configura el registro de puntero antes de que salga el primer mensaje

El orden que la mayoría de las guías se equivoca es probar la conectividad antes de configurar la identidad, y cuesta semanas de reputación. Los receptores califican la historia que tu servidor cuenta en el handshake — el hostname que anuncia, el registro directo al que ese hostname resuelve, el registro inverso que mapea tu IP de vuelta — antes de procesar una sola línea del cuerpo del mensaje. Esa historia tiene que ser coherente desde el mensaje uno.

El mecanismo es un triángulo. Eliges un hostname de correo, digamos mail.example.com, le das un registro A que apunte a tu VPS, y pones el registro inverso de esa IP de vuelta al mismo hostname — el panel expone el rDNS por dirección precisamente para esto. Luego el MTA anuncia el mismo nombre en su HELO; los clientes modernos abren con EHLO, y la disciplina del nombre es idéntica. Los modos de fallo clásicos de este triángulo están catalogados en las notas de operaciones DNS, y los nombres de puntero que no coinciden son la entrada más antigua de todas.

Donde se rompe: la gente configura el registro directo, se salta el inverso, y el correo sale con un puntero que todavía nombra el pool por defecto del proveedor — una penalización de puntuación instantánea en todos los receptores importantes. El segundo fallo es renombrar en pleno vuelo: cambiar el hostname de correo después de que el calentamiento empezó reinicia la identidad que los receptores estaban aprendiendo, casi tan malo como empezar desde una dirección ya manchada.

Verifícalo a la manera aburrida antes de que fluya correo real. Desde la propia máquina, resuelve tu IP hacia atrás y hacia adelante y compara ambas respuestas con el hostname configurado del MTA; deberían coincidir hasta el último carácter. Es una comprobación de dos minutos que previene la herida autoinfligida más común en despliegues de postfix, y solo hay que rehacerla cuando añades una dirección o mueves la máquina.

Triángulo de identidad listo: directo, inverso y nombre anunciado, todo coincidiendo. Esa es la mitad estática del handshake — la mitad dinámica es lo que los receptores recuerdan de ti con el tiempo, y ningún ajuste de panel la acuña. Se acumula al ritmo de semanas, que es exactamente por lo que los vendedores de atajos encuentran compradores; la siguiente sección explica por qué su producto no existe.

Una IP nueva no tiene reputación, y nadie honesto puede venderte una

Comprar una dirección precalentada es comprar la historia de otro, y las agencias de cobro no venden deudas buenas. Un IPv4 nuevo no tiene reputación en ningún punto de internet — ni mala, ni buena, desconocida — y ningún proveedor puede enviarte un atajo alrededor de las semanas que tardan los receptores en aprender qué envías. El mercado de direcciones precalentadas existe precisamente porque los compradores siguen esperando otra cosa.

El mecanismo bajo el calentamiento es que los grandes receptores puntúan tu dominio y tu IP por separado, lo que corta en ambos sentidos. La reputación de tu dominio te sigue a una dirección nueva, así que un dominio establecido se recupera más rápido de lo que su máquina nueva merece; un dominio limpio sobre una dirección manchada se recupera más rápido que al revés. El calentamiento es el proceso de dar tiempo a ambas puntuaciones para que converjan en la verdad sobre tu correo.

Donde se rompe: el volumen. Lo configuras todo, los mensajes de prueba a tus propias cuentas aterrizan de maravilla, y la semana uno se siente como permiso para importar la lista completa. Los rebotes superan el dos por ciento, la puntuación del dominio lee la proporción, y la rampa que lleva semanas se reinicia a cero por una tarde de entusiasmo. La disciplina es aburrida a propósito: volumen bajo hacia destinatarios que realmente abren, un aumento semanal lento, y rebotes mantenidos por debajo de un pequeño porcentaje.

Mira la cola en lugar de tu bandeja de entrada. mailq y postqueue -p muestran qué está reteniendo el MTA y por qué, y la documentación de Postfix cubre ambos en sus primeras páginas precisamente porque el correo diferido es el estado normal de un servidor sano. Los aplazamientos crecientes con respuestas 4xx son receptores pidiendo paciencia; los rechazos 5xx son receptores respondiendo a una pregunta que aún no debías hacer.

La reputación, entonces, es un libro de cuentas que solo el tiempo escribe, y cada atajo que se ofrece contra ella se cobra en las semanas que te cuesta cuando falla. Los registros de la siguiente sección son la parte que sí controlas — las tres promesas que dicen a los receptores, en formato legible por máquina, quién puede hablar por tu dominio.

SPF, DKIM y DMARC son tres promesas distintas

La parte contraintuitiva de la autenticación de correo es que publicar los tres registros mal puntúa peor que publicar dos bien. Los receptores no califican la presencia; califican la alineación — si los registros que existen realmente coinciden sobre quién habla por el dominio visible en la línea From. Un montón de promesas a medio configurar se lee como un dominio que no conoce su propio correo.

Los tres registros hacen tres promesas distintas. v=spf1 lista las direcciones autorizadas a enviar por el dominio, según la especificación SPF; DKIM adjunta una firma por mensaje que el receptor comprueba contra una clave publicada, según la especificación DKIM; y DMARC ata ambas al dominio visible del From y dice a los receptores qué hacer cuando discrepan — cuarentena con p=quarantine, rechazo con p=reject, más informes agregados a la dirección rua= para que veas lo que ve el mundo.

Donde se rompe: los relés legítimos que olvidaste. Un SaaS de facturación, una herramienta de newsletter o un sistema de monitorización que envía como tu dominio no aparece en ninguna de las promesas, y DMARC hace exactamente lo que le pediste con ellos. Enviar listas desde un subdominio mantiene la alineación del dominio organizacional limpia mientras el subdominio carga con su propia reputación. El segundo clásico es una rotación de DKIM hecha al revés — borrar la clave del selector antiguo mientras el correo firmado con él sigue en vuelo, así que los mensajes fallan la verificación en tránsito durante horas después del cambio y los informes se llenan de fallos misteriosos.

La rotación tiene un orden correcto: publica el nuevo registro selector._domainkey junto al antiguo, cambia la firma, y retira la clave antigua solo cuando la cola se haya vaciado y los informes se hayan calmado. Mantén las claves rotando de verdad — un par de DKIM que no ha cambiado en dos años está a una copia de seguridad filtrada de convertirse en la identidad de firma de otra persona.

Tres promesas, una historia de alineación y un hábito de rotación. La autenticación resuelve en qué te creen los receptores; la cola decide qué pasa realmente con un mensaje cuando un receptor duda — y esa fontanería tiene mecánica propia, que es el territorio de la siguiente sección.

Mecánica de la cola: aplazamientos, backoff y cómo leer el mailq

El hábito contraintuitivo que conviene construir pronto es la serenidad ante la cola: la pila de correo diferido de un servidor sano nunca es cero, porque el aplazamiento es operación normal, no fallo. El correo que no puede aterrizar de inmediato se retiene y se reintenta con backoff en lugar de rebotarse, y los operadores que dañan su propia entregabilidad suelen ser los que entran en pánico por el retraso en lugar de leerlo.

El mecanismo es un conjunto de directorios, no un misterio. Postfix separa las colas incoming, active y deferred bajo /var/spool/postfix/; las respuestas transitorias 4xx vuelven a encolar un mensaje con backoff creciente, las permanentes 5xx lo rebotan al remitente, y maximal_queue_lifetime acota cuántos días sigue intentándose el correo diferido antes del rebote final. Las herramientas de inspección vienen de serie: postqueue -p lista el rezago, postcat -q abre cualquier mensaje en cola para leerlo, postsuper -r lo reencola para un reintento inmediato.

El correo entrante tiene su propia puerta fronteriza. postscreen puntúa las conexiones antes de que empiece la conversación SMTP, sacudiéndose barato a los clientes zombis, y el correo aceptado llega a los buzones locales vía LMTP hacia la entrega de Dovecot, donde las reglas Sieve lo clasifican por destinatario. Cada etapa es observable, y cada etapa es un lugar donde una ruta mal configurada puede esconderse si la configuras a ciegas.

Donde se rompe: los operadores que fuerzan vaciados cada diez minutos no les enseñan nada a los receptores — los reintentos diferidos caducan según el calendario del lado receptor — y borrar entradas diferidas para dejar bonita la cola destruye la evidencia que un ticket de entregabilidad necesita. Una cola que crece monótonamente durante días significa un fallo aguas abajo como autenticación, almacenamiento o filtrado, no un humor de la red. Publicar una política TLS exigida — MTA-STS según RFC 8461 con informes según RFC 8460 — endurece los mismos caminos que la cola sirve.

Colas observables, vidas acotadas, backoff entendido: la fontanería es legible una vez que la miras de frente. Con el transporte y la identidad resueltos, las decisiones restantes son arquitectónicas — qué pila instalar y sobre cuánto metal — y esa es una pregunta sobre modos de fallo, no sobre listas de funciones.

Todo en uno o por piezas: elige el fallo que quieras poder arreglar

Las discusiones de pilas en internet son discusiones de funciones, por eso nunca terminan. La pregunta real es qué fallo de las 3 de la madrugada quieres poder arreglar de memoria: un paquete todo en uno falla como unidad y se recupera como unidad, mientras que una pila ensamblada a mano falla de una pieza cada vez y te deja reemplazar exactamente esa pieza. Ninguna es la correcta; una de las dos te corresponde.

La ruta empaquetada es Mailcow o Mail-in-a-Box — SMTP, IMAP, webmail y una interfaz de administración desplegados como una unidad, que genuinamente es el camino más rápido de VPS vacío a correo funcional para un dominio personal o familiar. La ruta por piezas es Postfix para SMTP, Dovecot para IMAP y entrega, y Rspamd para el filtrado: más decisiones por adelantado, y cada componente sustituible sin tocar los demás.

Donde se rompe: la ruta de actualización del paquete — una actualización mayor de Mailcow que cambie el formato del mailstore es un evento a nivel de unidad, así que haz una copia de seguridad real antes de ejecutarla. En el lado de las piezas, el hueco clásico es desplegar Postfix y Dovecot y olvidar el filtro, y luego preguntarse por qué la carpeta de spam se volvió un estilo de vida. Y en ambos lados: alojar la web en la misma IP que el correo significa que la dirección web hereda lo que la dirección de correo se gane.

La separación de IPs tiene un arreglo con precio. Pide un Core a $4.80/mes en el término anual (lista $6.00/mes) para el rol de correo, añade el IPv4 extra de $3.50/mes para la web, y las dos reputaciones nunca se tocan — el rDNS sigue editable por dirección, así que cada una cuenta su propia historia verdadera. Para un dominio que envía facturas y aloja una tienda, esos $3.50 son el seguro más barato de esta página.

Pila y plan de direcciones resueltos, el dimensionamiento es la última decisión arquitectónica, y los números engañan menos que la intuición. La siguiente sección explica por qué el disco — la especificación que todo el mundo mira primero — casi nunca es la restricción que importa para el correo, y por qué un nivel que parece sobredimensionado usualmente no lo es.

El disco nunca es la restricción; la reputación siempre lo es

La gente dimensiona servidores de correo como dimensiona servidores web — CPU primero, disco segundo, reputación nunca — y el instinto invierte todos los términos. Una carga de correo personal o de dominio pequeño apenas calienta un núcleo moderno; el mailstore es intensivo en fsync, lo que hace que el NVMe importe y la capacidad sea casi irrelevante. Lo que de verdad limita el correo es el recurso que no se puede comprar: la reputación que describieron las secciones anteriores. Si estás sopesando VPS frente a bare metal para correo, la guía de VPS frente a dedicado resuelve primero la cuestión de la carga.

El caso de hardware para subir un escalón es el margen, no la necesidad. Titan a $19.20/mes en el término anual (lista $24.00/mes) — 8 vCPU de EPYC, 32 GB de DDR5 ECC y 320 GB de NVMe — lleva una carga de correo personal o de dominio pequeño sin esfuerzo, y el ECC importa en un almacén pensado para vivir años: un volteo de bit silencioso en un maildir es corrupción que descubres al restaurar, no al escribir. Si quieres dejar de pensar en la máquina por completo, pon el dominio en Titan a $19.20/mes anual y deja que el margen absorba tanto el crecimiento como la curiosidad.

Donde se rompe: la colocalización de apetitos. El correo comparte la máquina con una aplicación web, la aplicación web la comparte con una base de datos, la base de datos tiene un índice malo, y de repente Dovecot está muerto de hambre de I/O detrás de una consulta que no tiene nada que ver con el correo. Los buzones son sensibles a la latencia de formas que los usuarios notan — abrir una carpeta no debería hacer cola detrás del dashboard de otro. Separa los roles en máquinas distintas, o como mínimo direcciones distintas si tienes que compartir una.

La disciplina de las copias de seguridad cierra la historia del dimensionamiento: el mailstore es el único conjunto de datos de la máquina que no puede recrearse desde un repositorio o un pipeline, así que se lleva el calendario de backups de verdad, con restauraciones probadas incluidas. Todo lo demás en un VPS de correo es configuración reproducible; el maildir es el activo. Dimensiona para I/O y backups, compra el margen una vez, y gasta la atención ahorrada en la cola.

El dimensionamiento, entonces, es como la reputación: imposible de comprar después del hecho y barato de hacer bien primero. La última pregunta arquitectónica es de comportamiento — con qué alimentas la lista — y es la que tiene filo legal, que es donde la siguiente sección traza la línea.

Solo envío legal: dónde traza la línea la AUP

La forma más rápida de perder una IP limpia no es un registro mal configurado; es escribir a gente que nunca lo pidió. La AUP prohíbe el spam sin matices — no como zona gris, no como cuestión de volumen, sino como caso de abuso — y un informe de abuso que se verifica viaja a la jurisdicción de la instalación, donde se trata como cualquier otra queja sobre el servidor de un cliente.

El mecanismo es la categoría, no el ánimo. La lista de prohibiciones es corta y nombrada — el spam entre ellas — mientras todo lo legal corre sin permiso: correo personal, correo de dominio, correo transaccional, correo de listas a gente que dio su consentimiento. RFC 2142 estandarizó los buzones de contacto hace décadas, y operar una dirección abuse@ real en tu dominio de envío es tanto buena práctica como la forma más rápida de enterarte de los problemas mientras aún son lo bastante pequeños para arreglarlos en silencio.

Donde se rompe: la lista alquilada. Las campañas en frío y las listas compradas son spam por definición — los destinatarios no pidieron nada — y ningún calendario de calentamiento, pila de autenticación o IP nueva sobrevive a ser apuntado contra una. El marketing real a gran escala pertenece a un ESP construido para el opt-in: existen porque la entregabilidad a volumen es una disciplina del consentimiento, y el consentimiento es verificable, que es justo lo que un VPS que te alquila una dirección no puede verificar por ti.

La ruta de recuperación importa tanto como la regla. Si un flujo acumula informes — incluso el correo legítimo a una lista anticuada los acumula — la secuencia es pausar el flujo, arreglar el problema de consentimiento y dejar enfriar la cola; la reputación se reconstruye por la misma curva de semanas que una dirección nueva, solo que desde media ladera. Los informes ignorados se componen: el segundo informe de la misma conducta aterriza en un receptor más frío que el primero, y el tercero, más frío todavía.

La línea, entonces, es el consentimiento, y se aplica igual en todo proveedor que opere abiertamente. Lo que queda es el montaje — toda la construcción desde máquina vacía a remitente cálido y autenticado, en orden — y la sección final lo ejecuta de principio a fin sin introducir ni una sola regla nueva.

El servidor de correo, en el orden en que hay que ejecutarlo

Ejecuta el montaje en este orden y no habrá que rehacer nada. Elige el rack por su ley, no por su ping — la guía de jurisdicción primero vale para el correo exactamente igual que para cualquier otra cosa: Suiza o Islandia para las posturas fuera de la UE, Ámsterdam por la adyacencia de peering, cualquiera de las doce para el correo en sí, porque la entrega sigue a la reputación y la reputación no comprueba la latitud. Pide la máquina, instala la imagen, y anota ambas direcciones si tomaste el IPv4 extra para separar roles.

Segundo, identidad antes de conectividad: elige el hostname de correo, apunta un registro A a la máquina, fija el registro inverso en el panel al mismo nombre, y configura el MTA para anunciarlo — el triángulo de antes, verificado con una búsqueda directa e inversa antes de que se envíe nada. Este es también el momento de confirmar que el panel muestra el puntero que esperas, porque el nombre del pool por defecto es lo que ven los receptores hasta que lo cambies.

Tercero, la pila y las promesas: instala el paquete o las piezas que elegiste, publica v=spf1 acotado a exactamente quién envía, monta DKIM con un selector nuevo y un DMARC en p=quarantine vigilando los informes, y solo endurece a p=reject cuando los informes muestren la alineación que esperas. Endurecer pronto es la forma más común de bloquear tus propios relés legítimos.

Cuarto, las semanas: calienta la dirección con volumen bajo hacia destinatarios que abren, mantén los rebotes por debajo de un pequeño porcentaje, mira mailq en lugar de la bandeja de entrada, y rota la clave DKIM por calendario y no tras un incidente. El puerto 25 no necesita nada de ti en ningún paso — estaba abierto antes de que existiera la máquina, y sigue abierto tanto si estás listo como si no.

Esa es toda la secuencia: rack por ley, identidad por triángulo, promesas por registro, volumen por paciencia. Cada fallo que esta página describe es uno de esos cuatro peldaños saltado o hecho en desorden, y todos son más baratos de hacer bien a la primera que de reparar cuando los primeros mil destinatarios ya han votado.