GUÍA DEFINITIVA: Cómo configurar su servidor para una entrega de correo fiable. PARTE I: Cortafuegos
El cortafuegos es un software (o un dispositivo de hardware-software) que controla qué conexiones al servidor están permitidas y cuáles se bloquean. En la gran mayoría de las distribuciones modernas de servidores Linux, existe alguna forma de cortafuegos disponible de fábrica.
La entrega fiable de correo al destinatario depende no solo del servidor de correo en sí, sino también de los registros DNS correctos y de la configuración del cortafuegos. Si algo falla en ellos, es muy probable que sus mensajes acaben en la carpeta de Spam o que no se entreguen en absoluto.
Este artículo describe los pasos clave que le permitirán lograr una entrega casi del 100% fiable de los mensajes enviados desde su servidor. En la Parte 1, repasaremos en detalle los posibles problemas relacionados con el cortafuegos; en la Parte 2, encontrará instrucciones para configurar los registros DNS.
La información de este artículo se aplica únicamente a los servidores de correo que se ejecutan en distribuciones Linux. Se utilizan Debian 12 y Rocky Linux 8.10 con el panel de control FASTPANEL como ejemplos.
Requisitos previos
Paso 1. Instalar herramientas de diagnóstico
Para comprobar registros y puertos, necesitará:
-
dig - para analizar registros DNS
-
lsof - para comprobar el estado del servidor de correo
-
netcat - para comprobar la disponibilidad de puertos
-
whois - para comprobar el proveedor de DNS actual
Instalación en Debian/Ubuntu:
sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd lsof whois
CentOS/AlmaLinux/Rocky Linux:
sudo yum install -y bind-utils nmap-ncat lsof whois
Disponibilidad de puertos de correo
Un puerto es un identificador numérico que se utiliza para dirigir diferentes servicios en un servidor. Cada servicio o aplicación escucha en su propio puerto para intercambiar datos a través de la red (por ejemplo, HTTP utiliza el puerto 80 y SMTP utiliza el puerto 25).
Para realizar todos los pasos siguientes, conéctese a su servidor a través de SSH utilizando las credenciales de usuario root o utilice sudo al ejecutar comandos, como se muestra en los ejemplos. Puede aprender a conectarse a un servidor por SSH en nuestro artículo sobre SSH.
Paso 2. Comprobar el estado del servidor de correo
Antes de comprobar si los puertos son accesibles a través de la red, asegúrese primero de que los servidores de correo se están ejecutando y funcionando correctamente. El correo saliente suele ser gestionado por Exim o Postfix, y el correo entrante por Dovecot.
Para comprobar que se están ejecutando, utilice los comandos:
sudo lsof -i:25
sudo lsof -i:143
Si los servicios se están ejecutando, obtendrá una salida similar a la siguiente:
Puerto 25:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
exim 839 exim 4u IPv6 778199358 0t0 TCP *:smtp (LISTEN)
exim 839 exim 5u IPv4 778199359 0t0 TCP *:smtp (LISTEN)
Si su servidor utiliza un servidor SMTP diferente, por ejemplo Postfix, verá su nombre exacto en lugar de exim en la primera columna. Si es necesario, utilice ese nombre en comandos posteriores.
Puerto 143:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
dovecot 859 root 39u IPv4 778204692 0t0 TCP *:imap (LISTEN)
dovecot 859 root 40u IPv6 778204693 0t0 TCP *:imap (LISTEN)
Esto significa que todo está bien y puede pasar al siguiente paso.
Si los servicios de correo no se están ejecutando, obtendrá una salida vacía:
~ sudo lsof -i:25
~
~ sudo lsof -i:143
~
En este caso, algo va mal y los servicios de correo no están disponibles. Puede intentar iniciarlos manualmente y luego comprobar su estado:
Debian/Ubuntu:
systemctl restart exim4 dovecot
systemctl status exim4
systemctl status dovecot
CentOS/AlmaLinux/Rocky Linux:
systemctl restart exim dovecot
systemctl status exim
systemctl status dovecot
En estado de ejecución, el estado del servicio se parecerá a esto:
Exim:
● exim.service - Agente de transporte de correo Exim
Loaded: loaded (/usr/lib/systemd/system/exim.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2025-11-02 16:38:57 UTC; 57min ago
Main PID: 839 (exim)
Tasks: 1
Memory: 11.0M
CGroup: /system.slice/exim.service
└─839 /usr/sbin/exim -bd -q1h
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
Dovecot:
● dovecot.service - Servidor de correo Dovecot IMAP/POP3
Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2025-11-02 16:38:58 UTC; 58min ago
Docs: man:dovecot(1)
https://doc.dovecot.org/
Main PID: 859 (dovecot)
Tasks: 5
Memory: 9.5M
CGroup: /system.slice/dovecot.service
├─ 859 /usr/sbin/dovecot -F
├─ 880 dovecot/anvil
├─ 881 dovecot/log
├─ 882 dovecot/config
└─1729 dovecot/stats
En este caso, todo está bien y puede pasar al siguiente paso.
Si algo va mal con los servicios, verá una salida similar a esta:
Exim:
● exim.service - Agente de transporte de correo Exim
Loaded: loaded (/usr/lib/systemd/system/exim.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Sun 2025-11-02 17:38:44 UTC; 3s ago
Process: 839 ExecStart=/usr/sbin/exim -bd -q${QUEUE} (code=exited, status=0/SUCCESS)
Main PID: 839 (code=exited, status=0/SUCCESS)
Dovecot:
● dovecot.service - Servidor de correo Dovecot IMAP/POP3
Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Sun 2025-11-02 17:39:32 UTC; 3s ago
Docs: man:dovecot(1)
https://doc.dovecot.org/
Process: 2278 ExecStop=/usr/bin/doveadm stop (code=exited, status=0/SUCCESS)
Process: 859 ExecStart=/usr/sbin/dovecot -F (code=exited, status=0/SUCCESS)
Main PID: 859 (code=exited, status=0/SUCCESS)
Existen muchas razones posibles por las que los servicios podrían no estar disponibles (errores en archivos de configuración, archivos de registro eliminados accidentalmente, falta de espacio libre en disco en el servidor, y mucho más). Estos aspectos escapan al alcance de este artículo.
Si se encuentra con este problema y desea investigarlo usted mismo, le recomendamos nuestro artículo sobre el trabajo con el journal del sistema. O póngase en contacto con el equipo de soporte de su proveedor de alojamiento para obtener ayuda. En kodu.cloud trabajamos 24/7 y respondemos a las solicitudes en pocos minutos.
Paso 3. Comprobación de la disponibilidad de los puertos de correo desde la red global
Para que el correo funcione correctamente, los siguientes puertos TCP deben ser accesibles a través de la red:
-
25, 465, 587 - para enviar correo (SMTP)
-
143, 993 - para recibir correo (IMAP)
Puede comprobar su disponibilidad usando netcat:
nc -vz 1.2.3.4 25
Reemplace 1.2.3.4 con la dirección IP real de su servidor.
Si el puerto está abierto, obtendrá la siguiente respuesta:
Debian/Ubuntu:
¡Conexión a 1.2.3.4 25!
CentOS/AlmaLinux/Rocky Linux:
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 1.2.3.4:25.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.
Si el puerto está cerrado, la respuesta será la siguiente:
Debian/Ubuntu:
nc: connect to 1.2.3.4 port 25 (tcp) failed: Connection refused
CentOS/AlmaLinux/Rocky Linux:
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connection refused.
Ejecute este comando para todos los puertos listados al principio de esta sección. Si todos están disponibles, continúe con la segunda parte de este artículo. Si no, vaya al Paso 4 para solucionar el problema.
Paso 4. Abrir acceso (opcional)
La mayoría de las veces, los servidores utilizan iptables o UFW como cortafuegos para proteger contra conexiones no deseadas. Ejecute el comando:
sudo ufw status
Si recibe la siguiente respuesta:
-bash: ufw: command not found
significa que se utiliza iptables. Si, sin embargo, la salida comienza con:
Status: active
Significa que se utiliza UFW.
Vaya a la subsección correspondiente de este paso según el cortafuegos en uso.
Existen otros programas para gestionar el cortafuegos del sistema en Linux (nftables, firewalld y otros). Estos no se cubrirán en este artículo para no aumentar su tamaño.
Iptables
En esta sección, todos los ejemplos se aplican únicamente a IPv4. Si su servidor tiene una dirección IPv6 y también necesita que los puertos de correo estén disponibles a través de IPv6, repita adicionalmente todos los comandos utilizando ip6tables en lugar de iptables.
Para mostrar todas las reglas actuales, ejecute:
sudo iptables -L -v -n --line-numbers
La salida puede diferir según el conjunto de reglas añadidas en el servidor. Por defecto, no hay reglas, pero dependiendo de la configuración del hosting o del sistema operativo, es posible que ya se haya realizado alguna configuración. Veamos dos casos principales que se encuentran a menudo al configurar un servidor de correo.
- Política de “todo lo que no está prohibido está permitido” (política ACCEPT)
En este caso, el cortafuegos, por defecto, permite todo el tráfico hasta que se crea una regla que lo bloquea explícitamente. Esta política se utiliza normalmente por defecto.
A continuación se muestra un ejemplo de un conjunto de reglas en el que los puertos SSH y de correo están bloqueados:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 51 5637 DROP 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp multiport dports 22
2 0 0 DROP 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp multiport dports 25,143,993,587,465
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 DROP 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp multiport dports 25,143,993,587,465
En este ejemplo:
-
Política ACCEPT define el comportamiento por defecto: se permiten todas las conexiones a menos que se indique lo contrario.
-
Chain INPUT (conexiones entrantes): se bloquean las nuevas conexiones al puerto 22 (SSH) y a todos los puertos de correo estándar (SMTP: 25, 465, 587; IMAP: 143; IMAPS: 993).
-
Chain OUTPUT (conexiones salientes): se bloquean los paquetes salientes a los mismos puertos.
El número de regla se muestra al principio de la línea (num). Si necesita eliminar, por ejemplo, la regla que bloquea los puertos de correo en la cadena INPUT (número de regla 2), el comando será:
sudo iptables -D INPUT 2
Aquí:
-
-D - es el comando para eliminar una regla.
-
INPUT es la cadena de la que se elimina la regla (en este caso, tráfico entrante).
-
2 es el número de línea donde se encuentra la regla que desea eliminar.
De manera similar, para eliminar el bloqueo de puertos salientes de este ejemplo, debe ejecutar:
sudo iptables -D OUTPUT 1
Los números de línea en la salida de iptables -L -v -n --line-numbers pueden cambiar si agrega o elimina otras reglas. Por lo tanto, si agrega nuevas reglas, los números de línea pueden cambiar. Para evitar errores, compruebe siempre los números de línea actuales antes de eliminar una regla.
Después de esto, para asegurarse de que todo es correcto, ejecute el comando de nuevo:
iptables -L -v -n --line-numbers
La salida no debería contener reglas que bloqueen el funcionamiento de los puertos de correo:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 51 5637 DROP 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp multiport dports 22
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Si las reglas siguen presentes, compruebe la corrección de los comandos que introdujo y los números de línea.
Después de cambiar las reglas del cortafuegos, asegúrese de guardar los cambios; de lo contrario, se perderán después de un reinicio. Para guardar las reglas de iptables actuales, ejecute:
Debian/Ubuntu:
iptables-save > /etc/iptables/rules.v4
CentOS/AlmaLinux/Rocky Linux:
iptables-save > /etc/sysconfig/iptables
Después de eso, vuelva a probar la disponibilidad de los puertos de correo, como se describe en el Paso 3. Si todavía no están disponibles, continúe con el Paso 5. Si todo está en orden, continúe con la segunda parte de este artículo.
- Política de “bloquear todo lo que no está explícitamente permitido” (política DROP)**
Este tipo de configuración es mucho más estricta. Todos los puertos y protocolos están bloqueados por defecto, y solo las reglas explícitas de permiso para puertos específicos dejan pasar el tráfico. Este es un enfoque más seguro y recomendado para servidores, especialmente si desea minimizar los riesgos.
Un ejemplo de reglas para dicha configuración:
Chain INPUT (policy DROP 306 packets, 17962 bytes)
num pkts bytes target prot opt in out source destination
1 92 12474 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 466 32947 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 197 packets, 29192 bytes)
num pkts bytes target prot opt in out source destination
1 44 10332 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
En este ejemplo:
- Chain INPUT (conexiones entrantes): la política es DROP, es decir, todos los paquetes se bloquean por defecto, excepto aquellos para los que existen reglas de permiso.
Regla 1: ACCEPT state RELATED,ESTABLISHED - permite paquetes entrantes que se relacionan con conexiones existentes o están asociados a ellas. Esto es importante para que el servidor reciba correctamente las respuestas a las conexiones salientes (por ejemplo, SSH, correo, consultas DNS) y mantenga una conexión estable.
Regla 2: ACCEPT tcp dpt:22 - permite nuevas conexiones entrantes en el puerto 22 (SSH).
- Chain OUTPUT (conexiones salientes): la política es DROP, es decir, todos los paquetes salientes se bloquean por defecto.
Regla 1: ACCEPT state RELATED,ESTABLISHED - permite paquetes salientes que se relacionan con conexiones existentes. Esto permite al servidor responder a las solicitudes del cliente (por ejemplo, conexiones SSH, de correo) y mantener una conexión estable.
Así vemos que no hay reglas de permiso para los puertos de correo. Para agregarlas, ejecute los siguientes comandos:
sudo iptables -A INPUT -p tcp -m multiport --dports 25,465,587,143,993 -m state --state NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp -m multiport --dports 25,465,587,143,993 -m state --state NEW,ESTABLISHED -j ACCEPT
Después de eso, guarde las reglas:
Debian/Ubuntu:
iptables-save > /etc/iptables/rules.v4
CentOS/AlmaLinux/Rocky Linux:
iptables-save > /etc/sysconfig/iptables
A continuación, pruebe la disponibilidad de los puertos de correo de nuevo, como se describe en el Paso 3. Si todavía no están disponibles, continúe con el Paso 5. Si todo está en orden, continúe con la segunda parte de este artículo.
UFW (Cortafuegos Sencillo)
En algunos servidores, se utiliza UFW en lugar de iptables, una interfaz simplificada para configurar el cortafuegos. Es adecuado para la configuración básica de servidores de correo y se encuentra a menudo en Ubuntu y Debian.
Para ver si UFW está habilitado y qué reglas están activas, ejecute:
sudo ufw status verbose
Ejemplo de salida:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip
Aquí:
-
Default: deny (incoming) - por defecto, se bloquean todas las conexiones entrantes.
-
Default: allow (outgoing) - por defecto, se permiten todas las conexiones salientes.
Para que el servidor de correo funcione correctamente, necesita abrir los puertos estándar. Ejecute los siguientes comandos en secuencia:
sudo ufw allow 25/tcp
sudo ufw allow 465/tcp
sudo ufw allow 587/tcp
sudo ufw allow 143/tcp
sudo ufw allow 993/tcp
Si también tiene restricciones de salida, necesita permitir los puertos SMTP para el correo saliente:
sudo ufw allow out 25/tcp
sudo ufw allow out 465/tcp
sudo ufw allow out 587/tcp
Tras añadir las reglas, puede volver a comprobarlas:
sudo ufw status numbered
Verá una lista de reglas con números. Si necesita eliminar una regla, utilice el número de la salida:
sudo ufw delete 3
En UFW, las reglas se guardan automáticamente y permanecerán en vigor después de un reinicio.
A continuación, pruebe la disponibilidad de los puertos de correo de nuevo, como se describe en el Paso 3. Si todavía no están disponibles, continúe con el Paso 5. Si todo está en orden, continúe con la segunda parte de este artículo.
Paso 5. El cortafuegos está configurado correctamente, pero los puertos de correo siguen sin estar disponibles (opcional)
Este comportamiento indica que los puertos de correo están bloqueados no a nivel de su servidor, sino en el equipo de su proveedor de alojamiento. En este caso, cree un ticket de soporte y pídales que desbloqueen estos puertos para su servidor. Si esto no es posible, la única solución será cambiar de proveedor de alojamiento.
En kodu.cloud no restringimos el funcionamiento de los puertos de correo de ninguna manera. Nuestras reglas prohíben los envíos masivos, pero para los clientes de buena fe el correo está disponible en su totalidad. Ni siquiera necesita configurar un servidor de correo, ya que a todos nuestros clientes se les proporciona acceso gratuito al panel de control FASTPANEL con una licencia ampliada. Solicite un servidor con el panel de control y empiece a usar el correo en su propio dominio en cuestión de minutos.
Los siguientes pasos para una configuración correcta de los registros DNS se cubrirán en la segunda parte de este artículo.