¿Vale la pena autoalojar el correo en 2026?

Respuesta breve

El autoalojamiento del correo electrónico sigue siendo útil en 2026, siempre que se divida el trabajo en dos partes. Recibir el correo propio en el propio VPS implica poco riesgo y funciona porque usted es el receptor y nadie tiene que confiar en usted. Enviar correo que los grandes proveedores de buzones acepten es un trabajo distinto. Depende de la reputación de una dirección IP que se hereda en lugar de construirse.

La configuración que realmente utilizan los operadores con experiencia es híbrida. Su propio servidor aloja los buzones y el archivo histórico. El correo saliente se envía mediante un relay autenticado por el puerto 587. El autoalojamiento completo, en ambas direcciones, sigue siendo la mejor opción en algunos casos concretos. Esos casos aparecen cerca del final de este artículo.

La parte difícil de alojar el correo por cuenta propia es la entregabilidad

Instalar un servidor de correo requiere un fin de semana de trabajo. Una pila moderna proporciona SMTP (simple mail transfer protocol) para transportar el correo, IMAP (internet message access protocol) para leerlo, filtrado de spam y una interfaz de webmail desde un solo archivo de compose. La guía Instalación del servidor de correo Mailcow en un VPS cubre esa parte. La instalación no es lo difícil.

La dificultad empieza cuando su servidor abre una conexión con una máquina administrada por una empresa que nunca ha oído hablar de usted y le pide que coloque un mensaje en la bandeja de entrada de alguien. Ese receptor no tiene motivos para aceptar la solicitud. Decide basándose en varias señales: la reputación de la dirección IP que se conecta, la reputación de su dominio, si el mensaje está autenticado y cómo han reaccionado sus propios usuarios a sus mensajes anteriores. Un remitente nuevo no tiene ningún historial, y la ausencia de historial no se considera neutral. Se considera un riesgo. Por eso, los primeros mensajes llegan a la carpeta de spam o se aplazan hasta que exista un patrón.

Verá el rechazo. Gmail envía un rechazo permanente de esta forma:

550-5.7.1 [203.0.113.5      19] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked.

Microsoft envía otro distinto, que termina con un código de lista de bloqueo variable:

550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3150).

Lea el primer dígito antes de hacer cualquier otra cosa. Un código que empieza por 4 es temporal, por lo que su servidor conserva el mensaje y vuelve a intentarlo. Un código que empieza por 5 es permanente, por lo que el mensaje rebota inmediatamente al remitente. Un aplazamiento 4xx que nunca desaparece indica un límite de tasa o de reputación, y puede resolverse por sí solo. Un 5xx es una decisión y no desaparecerá.

¿Por qué el correo de un servidor nuevo termina en spam?

Porque la dirección IP no es nueva. No recibe una dirección sin historial. Recibe una dirección reutilizada del grupo de direcciones de su proveedor, y su historial se conserva. Si el usuario anterior envió spam, su primer mensaje puede rechazarse antes de que haya enviado un segundo.

Compruebe la dirección antes de instalar nada en ella. Las listas de bloqueo públicas responden mediante DNS, con los cuatro octetos de la dirección invertidos:

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd swaks
dig +short 10.0.0.10.zen.spamhaus.org

Una respuesta vacía significa que la dirección no aparece en ninguna lista. Una respuesta dentro de 127.0.0.0/8 significa que sí aparece, y el octeto final indica qué lista coincidió. Hay una excepción importante en esta prueba: Spamhaus rechaza las consultas que llegan a través de los resolvers públicos grandes, por lo que la misma consulta realizada mediante 8.8.8.8 devuelve 127.255.255.254 independientemente del estado real. Ese código significa que se rechazó la consulta, no que la dirección esté incluida en una lista. Ejecute la consulta mediante el resolver de su propio servidor o use la consulta web.

Obtener un resultado limpio es necesario, pero no suficiente. No aparecer en una lista sólo significa que nadie se ha quejado recientemente de esa dirección. No implica una reputación positiva, y esa reputación es la que permite que el correo llegue a las bandejas de entrada. Se obtiene enviando pequeños volúmenes de correo solicitado durante varias semanas.

Sus vecinos también influyen, porque algunos receptores calculan la reputación de todo un bloque de red y no sólo de una dirección. Si otro cliente del mismo rango /24 empieza a enviar spam, su correo puede ralentizarse por asociación. Esta perspectiva por bloques también explica por qué las quejas de abuso llegan a la bandeja de entrada de un VPS por tráfico que el titular de la cuenta nunca envió: la queja sigue al rango de direcciones.

Qué debe confirmar antes de empezar: el puerto 25 y el registro PTR

El puerto TCP saliente 25 es el más utilizado de forma abusiva en internet, por lo que muchos proveedores de hosting lo cierran de forma predeterminada en las cuentas nuevas. Algunos lo abren previa solicitud. Otros lo abren cuando la cuenta tiene cierta antigüedad y un historial de pagos. Algunos nunca lo abren. Las políticas varían según el proveedor y cambian con el tiempo, así que no considere este artículo, un hilo antiguo de un foro ni la página de marketing de un proveedor como información actual. Pregunte y obtenga la respuesta por escrito antes de pagar.

Pruebe la ruta desde el propio servidor:

nc -vz gmail-smtp-in.l.google.com 25

Una ruta abierta muestra succeeded! en menos de un segundo. Una ruta bloqueada queda esperando y después agota el tiempo de espera sin indicar qué bloqueó la conexión, porque un paquete descartado silenciosamente tiene exactamente el mismo aspecto que un problema de red normal.

El segundo requisito es un registro PTR, también llamado DNS inverso. Los receptores toman la dirección IP que se conectó, consultan su registro PTR para obtener un nombre y después consultan ese nombre para obtener de nuevo una dirección. Cuando ambas direcciones coinciden, se denomina DNS inverso confirmado hacia delante. Es una comprobación sencilla que indica que el host que se conecta pertenece a quien afirma ser.

dig -x 203.0.113.5 +short
dig +short mail.example.com

La primera consulta debe devolver el nombre de host de correo. La segunda debe devolver la misma dirección con la que empezó. Sólo el propietario de una dirección IP puede publicar su registro PTR, por lo que el proveedor debe configurarlo por usted o poner esta opción a su disposición en un panel de control. La ausencia de un registro PTR, o un registro genérico como 203-0-113-5.static.example-isp.net, es una señal negativa importante, porque los servidores de correo reales casi siempre tienen un nombre coincidente y las fuentes masivas de spam a menudo no lo tienen.

Si su proveedor también asigna IPv6 y su servidor la prefiere, todo lo anterior se aplica también a la dirección IPv6, y Gmail es más estricto en ese caso. El envío mediante IPv6 desde una dirección sin registro PTR provoca un rechazo que indica que el mensaje no cumple las directrices de envío mediante IPv6 relativas a los registros PTR y la autenticación. Si no puede configurar un registro PTR para IPv6, envíe sólo mediante IPv4. En Postfix, smtp_address_preference = ipv4 establece la preferencia por IPv4 y inet_protocols = ipv4 desactiva IPv6 por completo.

Las tres preguntas que debe hacer a cualquier proveedor

1. ¿Está abierto el puerto TCP saliente 25 en una cuenta nueva? Si no lo está, ¿cuál es el proceso exacto y el plazo para abrirlo?
2. ¿Puedo configurar el registro PTR de mi dirección IPv4 y de mi dirección IPv6? ¿Dónde se hace?
3. Si se determina que mi dirección aparece en una lista de bloqueo debido a un cliente anterior, ¿me cambiarán a otra dirección?

Haga las tres preguntas antes de comprar, no después. Un proveedor que responda claramente a las dos primeras y diga que no a la tercera sigue siendo una opción viable, porque puede comprobar la dirección el primer día y cancelar el servicio. Un proveedor que no quiera responder a ninguna por escrito ya le ha indicado cómo será administrar el correo allí.

Qué demuestran realmente SPF, DKIM y DMARC

Tres registros DNS demuestran que el correo que afirma proceder de su dominio realmente se envió desde una fuente autorizada. Cada uno responde a una pregunta distinta, y el tercero sólo funciona cuando se entienden los dos primeros.

SPF (sender policy framework) es un registro TXT que enumera los servidores que pueden enviar correo para su dominio. El receptor lo comprueba con el remitente del sobre, que es la dirección indicada en el comando SMTP MAIL FROM, y no es la cabecera From: que ve el lector.

DKIM (domainkeys identified mail) añade una firma criptográfica a las cabeceras del mensaje, que cubre el cuerpo y una lista elegida de cabeceras. La clave pública correspondiente se encuentra en DNS bajo un selector que usted elige. Cualquiera puede verificar que el mensaje procede del titular de su clave privada y que no se modificó durante el transporte.

DMARC (domain-based message authentication, reporting and conformance) vincula los otros dos mecanismos con el dominio de la cabecera From: visible e indica a los receptores qué deben hacer cuando la vinculación falla.

example.com.                  TXT  "v=spf1 mx -all"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.           TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

La palabra importante es alineación. DMARC no pasa porque SPF haya pasado. Pasa cuando SPF o DKIM pasan y el dominio que pasó es el mismo que aparece en la cabecera From:. Aquí es donde el correo reenviado falla silenciosamente: un relay que reescribe el remitente del sobre con su propio dominio sigue produciendo un resultado SPF pass, pero el dominio que pasó es el del relay, por lo que no está alineado y DMARC falla, salvo que su propia firma DKIM esté presente y sea válida. Firme con una clave publicada bajo su dominio y el problema desaparece.

La alineación también explica el reenvío. Cuando una lista de correo o una antigua dirección universitaria reenvía su mensaje, el servidor de reenvío se convierte en la dirección IP que establece la conexión y no figura en su registro SPF, por lo que SPF falla en el destino final. DKIM sobrevive al reenvío mientras no se modifiquen las cabeceras que firmó. DKIM es el mecanismo que debe funcionar.

Publique p=none con una dirección de informes rua= primero y revise los informes agregados durante dos semanas antes de endurecer la política. Esos informes son el único lugar donde verá los mensajes enviados en su nombre que usted no envió y la única forma de encontrar el reenviador que olvidó. Pasar directamente a p=reject omite ese paso y rompe el correo legítimo sin dejar constancia de qué se rompió.

Después, pruebe toda la cadena de extremo a extremo. Envíe un mensaje a una cuenta que controle en un proveedor grande y abra su código fuente sin procesar:

swaks --to you@gmail.com --from postmaster@example.com --server 127.0.0.1
sudo journalctl -t postfix/smtp -f

swaks muestra la conversación SMTP a medida que ocurre. La línea del registro de Postfix correspondiente a la entrega termina en status=sent (250 2.0.0 OK ...) cuando el servidor receptor aceptó el mensaje. Cualquier otro resultado registra literalmente el texto del rechazo, y esa cadena es la que debe buscar. En el mensaje entregado, el código fuente sin procesar contiene una cabecera Authentication-Results: que nombra cada comprobación e indica si pasó o falló, junto con el dominio que autenticó. Las tres deben indicar pass y el dominio debe ser el suyo.

¿Cómo detectar un problema de reputación?

Un feedback loop es un mecanismo por el que un proveedor de buzones le envía una copia de un mensaje cada vez que uno de sus usuarios pulsa el botón para denunciarlo como spam. Sin uno, la primera señal de un problema es que la entrega ya ha fallado, con semanas de retraso.

Los programas son diferentes y no todos se adaptan a un VPS individual con una sola dirección. En agosto de 2026, Microsoft ofrece un servicio de datos y quejas por dirección al que puede registrarse el propietario de la dirección; Yahoo ofrece un feedback loop de quejas asociado al dominio que firma con DKIM; y Google publica datos agregados de reputación, no quejas individuales, en un panel que permanece vacío hasta que se envía un volumen diario significativo a sus usuarios. Lea las condiciones vigentes de cada servicio antes de depender de ellos, porque estos programas cambian y ninguno está obligado a concederle acceso.

Los requisitos de Google para remitentes de correo masivo, vigentes desde febrero de 2024, son la declaración pública más clara de lo que espera actualmente un receptor grande. Un remitente que envía más de 5,000 mensajes al día a cuentas personales de Gmail debe autenticarse con SPF y DKIM, publicar una política DMARC, ofrecer una opción de cancelación de suscripción con un clic en el correo masivo y mantener la tasa de quejas por spam por debajo del 0.3 por ciento. El correo personal enviado desde un servidor pequeño queda muy por debajo de ese umbral, pero las mismas señales se analizan con cualquier volumen, y la tasa de quejas es el dato que no puede ver sin un feedback loop.

La separación que funciona: recibir en el servidor propio y usar un relay para el correo saliente

La recepción es la parte que casi no tiene inconvenientes. Nadie tiene que confiar en usted para aceptar el correo que se le envía. El registro MX, que identifica en DNS el servidor de correo de su dominio, apunta a su servidor. Los remitentes se conectan a él y, a partir de ahí, todas las decisiones son suyas: qué conservar, durante cuánto tiempo, cómo indexarlo y quién puede buscarlo. El almacenamiento es barato y un archivo que usted controla no puede cerrarse por una decisión automatizada de una política aplicada en otro lugar. El trabajo es real y está delimitado: mantener actualizado el filtro antispam, renovar los certificados TLS (seguridad de la capa de transporte), conservar las copias de seguridad y evitar que el disco se llene.

El envío saliente es donde puede pagar para evitar el problema difícil. Configure el servidor para entregar todos los mensajes salientes a un relay autenticado en el puerto 587, en lugar de comunicarse con Internet por el puerto 25. En la configuración de Postfix, main.cf:

relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Escriba las credenciales en /etc/postfix/sasl_passwd con un editor para que la contraseña nunca quede en el historial del shell. Es una sola línea y el host de la izquierda debe escribirse exactamente como aparece en relayhost:

[smtp.relay.example]:587 username:password

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd.db
sudo systemctl reload postfix

Un mensaje enviado después de esa recarga registra relay=smtp.relay.example[...]:587 y status=sent. Una línea de registro que indique SASL authentication failed significa que las credenciales no fueron aceptadas. La causa habitual es que el nombre de host de sasl_passwd esté escrito de forma distinta al de relayhost, porque la búsqueda compara cadenas exactas.

Esta separación funciona porque el relay controla direcciones con años de correo aceptado y mantener esa reputación es toda su actividad. Usted conserva el dominio, los buzones, el archivo y la posibilidad de cambiar de proveedor, ya que cambiar de relay requiere modificar una línea de configuración y un registro DNS. Lo que pierde es la confidencialidad del correo saliente frente al operador del relay. Ese es el coste real del acuerdo y es mejor decidirlo de antemano que descubrirlo después.

Conviene hacer una separación más desde el primer día. Todo el correo masivo debería salir desde su propio subdominio y con su propia clave DKIM: news.example.com para un boletín y mail.example.com para el correo personal. La reputación se asocia al dominio remitente, por lo que una tasa de quejas elevada en un boletín autogestionado de Listmonk no podrá perjudicar también al correo personal.

¿Cuándo sigue siendo adecuada la autohospedaje completa?

Volumen. El precio por mensaje de un relay resulta cómodo con cientos de mensajes al mes y deja de serlo con millones. A esa escala puede permitirse direcciones dedicadas y el programa de calentamiento necesario para que funcionen.

Jurisdicción. Cuando una normativa o un contrato establece que el correo no puede almacenarse en el disco de un tercero, la calidad de entrega no es el factor decisivo. Simplemente no puede utilizar un relay.

Control que no se puede comprar. Reglas de retención que se ajustan a su política y no a un nivel del plan, una dirección por servicio para identificar quién la filtró, filtrado que ejecuta su propio código y ninguna suspensión de la cuenta decidida por un sistema sin posibilidad de apelación.

Correo que nunca sale de su red. Las alertas y otros mensajes entre máquinas no tienen ningún problema de entregabilidad, porque ambos extremos le pertenecen. Un servidor SMTP local que entregue los mensajes en sus propios buzones es toda la solución. Es el mismo patrón que hay detrás de darle a un asistente su propio buzón autohospedado mediante MCP (model context protocol).

Si envía correo saliente directamente, caliente la dirección. Empiece con un volumen diario bajo dirigido a personas que esperan sus mensajes, auméntelo gradualmente durante varias semanas y no envíe nunca un volumen repentino desde una dirección sin historial. La reputación se construye con mensajes aceptados y pocas quejas a lo largo del tiempo. Por eso, un aumento repentino desde una dirección sin historial parece exactamente un servidor comprometido y recibe el mismo tratamiento.

¿Cuánto cuesta el primer año de funcionamiento de un servidor de correo?

La primera semana es la fase de preparación: paquetes, registros DNS, certificados TLS, los primeros mensajes de prueba y DMARC en p=none.

Las semanas dos a seis son la parte que nadie planifica. Lee los informes agregados de DMARC, encuentra el problema de alineación que no sabía que tenía, descubre el reenviador que rompe SPF, cambia la política a p=quarantine y más adelante a p=reject. Esta etapa determina si el alojamiento propio se convierte en una tarea rutinaria o en algo que termina siendo una molestia.

Después, el mantenimiento se estabiliza en aproximadamente una hora al mes: actualizaciones de paquetes, una renovación de certificado que verifica en lugar de dar por supuesta, una prueba de restauración desde la copia de seguridad, una revisión del crecimiento del disco y una consulta a una lista de bloqueo.

Luego está la semana que no puede programar. Una dirección aparece incluida en una lista por algo que usted no hizo. Un receptor grande cambia una regla y sus mensajes vuelven a llegar a la carpeta de spam. Los mensajes en cola no son mensajes perdidos: Postfix vuelve a intentar entregar un mensaje diferido durante cinco días de forma predeterminada, según maximal_queue_lifetime = 5d, por lo que una interrupción de varias horas le cuesta latencia y nada más. Una interrupción de una semana le cuesta mensajes.

Un registro MX de respaldo es una solución menos eficaz de lo que parece. Los servidores de envío ya vuelven a intentar la entrega durante días por su cuenta, así que un servidor secundario que sólo pone mensajes en cola aporta poco. Peor aún, un servidor secundario que acepta correo para su dominio sin saber qué direcciones existen aceptará mensajes para direcciones inexistentes y después los devolverá a remitentes falsificados. Esto convierte su servidor de respaldo en una fuente de backscatter. Dedique el esfuerzo a la monitorización y a una restauración que haya probado realmente.

Evalúe todo el sistema con la misma pregunta que aplicaría a cualquier otro componente del servidor: ¿tenerlo le proporciona algo que no pueda comprar? Para los buzones y el archivo, la respuesta suele ser sí. Para la entrega saliente a destinatarios externos, normalmente es no. Esa es la misma prueba que permite clasificar el resto de la lista de cosas que merece la pena alojar por cuenta propia en 2026.

FAQ

¿Puedo alojar mi correo si mi proveedor de VPS bloquea el puerto 25 saliente?

Sí, tanto para recibir correo como para enviarlo mediante un relay. El correo entrante llega al puerto 25 de su servidor, y un bloqueo saliente no lo afecta. El correo saliente se envía mediante un relay autenticado en el puerto 587, que los proveedores no suelen bloquear. Con el puerto 25 cerrado, no puede entregar correo directamente a otros servidores de correo, porque la entrega entre servidores se realiza por definición en el puerto 25. Pruébelo con nc -vz gmail-smtp-in.l.google.com 25. Una espera seguida de un tiempo de espera agotado indica que el puerto está bloqueado.

¿Por qué mi correo llega a spam aunque SPF, DKIM y DMARC pasen correctamente?

La autenticación demuestra quién envió un mensaje. No demuestra que el mensaje sea deseado. Superar las tres comprobaciones le permite pasar de no identificado a identificado. Después, el receptor evalúa la reputación de su dirección IP y de su dominio, que un remitente nuevo todavía no tiene. Constrúyala enviando durante varias semanas pequeños volúmenes de correo que los destinatarios esperan recibir. Después, confirme que el registro PTR coincide en ambos sentidos con el nombre de host de correo y compruebe que el contenido no esté recibiendo penalizaciones adicionales, por ejemplo por usar acortadores de enlaces o un dominio de seguimiento desconocido.

¿Necesito una dirección IP dedicada para un servidor de correo alojado por mí?

Para la entrega saliente directa, sí. Un servidor de correo necesita una dirección cuyo registro PTR controle y cuya reputación le pertenezca exclusivamente. En ese sentido, una dirección de VPS ya es dedicada. Lo que no controla es su historial ni el de otros usuarios del mismo bloque de red. Si utiliza un relay para el correo saliente, las direcciones del relay aportan la reputación y la suya sólo tiene que aceptar conexiones entrantes.

¿Es seguro mover mi dirección principal a un servidor de correo propio?

Hágalo por etapas en lugar de realizar un cambio único. Mantenga activo el buzón existente, añada su propio servidor como segundo destino y reenvíele una copia durante unas semanas mientras revisa los informes de DMARC y confirma que el correo fluye en ambos sentidos. Cambie el registro MX sólo después de que el correo de prueba haya llegado correctamente durante una semana. El fallo que más se lamenta es un cambio que provoca la pérdida del correo entrante, porque esa parte no se puede reconstruir.

¿Cuál es la configuración más pequeña que mantiene el control de mi correo?

Su propio servidor para los buzones y el archivo, con el correo saliente entregado a un relay autenticado en el puerto 587. Usted conserva los datos y el dominio, y evita por completo el problema de la reputación. El coste de cambiar de decisión sigue siendo bajo, porque el relay requiere una sola línea de configuración y una entrada SPF. Sustituirlo más adelante sólo requiere una tarde de trabajo.