Webmail seguro: cómo configurar tu correo con SSL/TLS

Configurar el correo electrónico con SSL/TLS es tan importante para la seguridad como tener HTTPS en la web. Sin cifrado en el correo, las credenciales de acceso (usuario y contraseña) y el contenido de los emails viajan en texto plano por la red: cualquier persona que intercepte el tráfico puede leerlos. Los puertos correctos para correo cifrado son el 993 para IMAP con SSL/TLS implícito, el 995 para POP3 con SSL/TLS implícito, y el 465 para SMTP con SSL/TLS implícito. Usar SSL/TLS en el correo protege la privacidad de las comunicaciones y es un requisito del RGPD cuando se transmiten datos personales por email.

Por qué el correo sin SSL es un riesgo de seguridad grave

El correo electrónico fue diseñado en los años 70 sin ninguna consideración de seguridad: los protocolos SMTP, IMAP y POP3 originales transmiten toda la información en texto plano. Esto significa que sin SSL/TLS, cuando tu cliente de correo (Outlook, Thunderbird, la app de tu móvil) se conecta al servidor de correo para enviar o recibir mensajes, ocurre lo siguiente en texto plano y completamente legible:

• Tu nombre de usuario y contraseña de correo electrónico.
• El contenido completo de todos los emails que envías y recibes.
• Los adjuntos de los emails.
• Las cabeceras de los mensajes (destinatarios, asunto, fecha, IPs de origen).

En redes WiFi públicas (aeropuertos, hoteles, cafeterías), en redes corporativas con monitorización del tráfico, o en cualquier punto de la ruta de red entre tu dispositivo y el servidor de correo, estas comunicaciones pueden ser interceptadas y leídas sin ningún esfuerzo técnico especial usando herramientas de captura de paquetes como Wireshark.

Con SSL/TLS activo, toda esta comunicación viaja cifrada con los mismos algoritmos que usa HTTPS (TLS 1.2 o TLS 1.3, AES-256): aunque alguien intercepte el tráfico, solo verá datos binarios sin ningún significado interpretable.

Los protocolos de correo y sus puertos: guía de referencia

El correo electrónico usa tres protocolos distintos para diferentes funciones, y cada uno tiene puertos diferentes según si usa cifrado o no:

IMAP: recepción de correo con sincronización

IMAP (Internet Message Access Protocol) es el protocolo estándar para recibir correo en 2026. A diferencia de POP3, IMAP mantiene los emails en el servidor y los sincroniza en todos tus dispositivos: si lees un email en el móvil, aparecerá como leído en el ordenador. Los cambios (leído, eliminado, movido a carpeta) se sincronizan en tiempo real.

POP3: recepción de correo con descarga local

POP3 (Post Office Protocol 3) descarga los emails del servidor al dispositivo local y (en su configuración por defecto) los elimina del servidor. Es un protocolo de los años 80 pensado para un único dispositivo. En 2026 solo se recomienda en casos muy específicos donde no se quiere mantener correo en el servidor (cumplimiento normativo, almacenamiento local de archivos críticos).

SMTP: envío de correo

SMTP (Simple Mail Transfer Protocol) se usa para enviar correo desde tu cliente al servidor de correo (submission) y entre servidores de correo (relay). Tiene tres puertos distintos con funciones diferentes:

SSL/TLS implícito vs STARTTLS: diferencias y cuál usar

Esta es una de las confusiones más frecuentes en la configuración del correo. Ambos métodos cifran la comunicación con TLS, pero de formas distintas:

Recomendación para 2026: usa siempre SSL/TLS implícito (puertos 993, 995, 465) en lugar de STARTTLS cuando tu cliente de correo lo permita. Es más seguro porque elimina la ventana de negociación sin cifrar. Todos los clientes de correo modernos (Outlook, Thunderbird, Apple Mail, Gmail app) soportan SSL implícito. Solo usa STARTTLS si tu cliente o servidor no soporta SSL implícito, algo muy infrecuente en 2026.

Tabla de referencia completa: puertos de correo en 2026

Configuración del correo con SSL/TLS en los principales clientes

Datos de configuración genéricos para cualquier cliente

Estos son los datos que necesitas introducir en cualquier cliente de correo para configurar una cuenta de correo alojada en los servidores de sys4net con SSL/TLS:

Configuración en Microsoft Outlook

El proceso de configuración varía ligeramente según la versión de Outlook (2019, 2021, 365, o la nueva versión de Outlook para Windows), pero los datos son los mismos:

1. Abre Outlook y ve a Archivo > Agregar cuenta.
2. Introduce tu dirección de email y haz clic en Conectar.
3. Outlook intentará configurar la cuenta automáticamente. Si falla, selecciona IMAP en el menú de tipo de cuenta.
4. Introduce los datos del servidor de entrada: mail.tudominio.com, puerto 993, cifrado SSL/TLS.
5. Introduce los datos del servidor de salida: mail.tudominio.com, puerto 465, cifrado SSL/TLS.
6. Haz clic en Siguiente e introduce tu contraseña.

Si necesitas cambiar la configuración SSL de una cuenta ya existente en Outlook:

1. Ve a Archivo > Configuración de la cuenta > Configuración de la cuenta.
2. Selecciona la cuenta y haz clic en Cambiar.
3. Haz clic en Más configuraciones > Avanzadas.
4. Cambia los puertos y el tipo de cifrado según la tabla anterior.

Configuración en Mozilla Thunderbird

1. En Thunderbird, ve a Cuenta de correo electrónico (o Herramientas > Configuración de la cuenta > Acciones de la cuenta > Añadir cuenta de correo).
2. Introduce tu nombre, dirección de email y contraseña.
3. Haz clic en Configurar manualmente si la configuración automática no encuentra los datos correctos.
4. Servidor de entrada: protocolo IMAP, servidor mail.tudominio.com, puerto 993, conexión SSL/TLS, autenticación contraseña normal.
5. Servidor de salida: servidor mail.tudominio.com, puerto 465, conexión SSL/TLS, autenticación contraseña normal.
6. Haz clic en Hecho.

Configuración en Apple Mail (macOS e iOS)

En macOS:

1. Abre Mail y ve a Mail > Ajustes > Cuentas > (+).
2. Selecciona Otra cuenta de correo.
3. Introduce tu nombre, email y contraseña.
4. En el servidor de entrada: mail.tudominio.com, selecciona IMAP y marca Usar SSL. El puerto se ajustará automáticamente a 993.
5. En el servidor de salida: mail.tudominio.com, marca Usar SSL. Puerto 465.

En iOS/iPadOS:

1. Ve a Ajustes > Mail > Cuentas > Añadir cuenta > Otra.
2. Selecciona Añadir cuenta de correo.
3. Introduce nombre, email, contraseña y descripción.
4. En la pestaña IMAP: servidor de entrada mail.tudominio.com, puerto 993, SSL activado.
5. Servidor de salida (SMTP): mail.tudominio.com, puerto 465, SSL activado.

Configuración en Android (Gmail app para cuentas externas)

1. Abre la app Gmail y ve a Ajustes > Añadir cuenta > Otra.
2. Introduce tu dirección de email y toca Configuración manual.
3. Selecciona IMAP.
4. Servidor de entrada: mail.tudominio.com, puerto 993, tipo de seguridad SSL/TLS.
5. Servidor de salida: mail.tudominio.com, puerto 465, tipo de seguridad SSL/TLS.
6. En "Requerir inicio de sesión": marca la casilla.

El certificado SSL del servidor de correo: cómo funciona

El servidor de correo (Postfix para SMTP, Dovecot para IMAP y POP3) necesita su propio certificado SSL/TLS para cifrar las conexiones de los clientes de correo. Este certificado puede ser el mismo que el del sitio web (si el servidor de correo usa el mismo nombre de dominio que el sitio web, por ejemplo mail.tudominio.com) o un certificado independiente.

En Plesk, el certificado SSL del servidor de correo se gestiona de forma independiente al del sitio web:

1. Ve a Websites y Dominios > [tu dominio] > Correo > Configuración del servidor de correo.
2. En la sección "Certificado SSL/TLS para el servidor de correo", selecciona el certificado a usar.
3. Puedes usar el mismo certificado de Let's Encrypt del dominio (si incluye mail.tudominio.com) o instalar un certificado específico para el servidor de correo.

# Verificar el certificado SSL del servidor de correo desde la línea de comandos:
# Verificar el certificado IMAP:
echo | openssl s_client -connect mail.tudominio.com:993 2>/dev/null | openssl x509 -noout -dates -subject

# Verificar el certificado SMTP:
echo | openssl s_client -starttls smtp -connect mail.tudominio.com:587 2>/dev/null | openssl x509 -noout -dates -subject

# Para SSL implícito en SMTP (puerto 465):
echo | openssl s_client -connect mail.tudominio.com:465 2>/dev/null | openssl x509 -noout -dates -subject

# Probar la autenticación SMTP desde la línea de comandos:
curl --ssl-reqd --url "smtps://mail.tudominio.com:465" \
     --user "tucorreo@tudominio.com:tucontraseña" \
     --mail-from "tucorreo@tudominio.com" \
     --mail-rcpt "destino@ejemplo.com" \
     --upload-file mensaje.txt

SPF, DKIM y DMARC: la seguridad del correo más allá de SSL/TLS

SSL/TLS protege la comunicación en tránsito entre el cliente de correo y el servidor. Pero hay otra dimensión de la seguridad del correo que es igualmente importante: garantizar que los emails que dicen venir de tu dominio realmente son enviados por tu servidor, no por spammers o atacantes que suplantan tu identidad. Para eso existen SPF, DKIM y DMARC.

SPF (Sender Policy Framework)

SPF es un registro DNS TXT que declara qué servidores tienen autorización para enviar correo en nombre de tu dominio. Cuando un servidor de correo recibe un email de @tudominio.com, consulta el registro SPF de tudominio.com para verificar si el servidor que envió el email está en la lista autorizada.

# Ejemplo de registro SPF para un servidor de correo en sys4net:
# Tipo: TXT
# Nombre: @ (o tudominio.com)
# Valor:
v=spf1 ip4:195.234.56.78 include:spf.tudominio.com ~all

# Desglose:
# v=spf1          → versión del protocolo SPF
# ip4:195.234.56.78 → la IP del servidor de correo está autorizada
# include:spf.tudominio.com → también están autorizados los servidores de ese dominio
# ~all            → cualquier otro servidor genera un "softfail" (sospechoso pero no rechazado)
# -all            → cualquier otro servidor genera un "fail" (rechazado — más estricto)

# Verificar el registro SPF de un dominio:
dig TXT tudominio.com | grep spf
# o:
nslookup -type=TXT tudominio.com | grep spf

DKIM (DomainKeys Identified Mail)

DKIM añade una firma digital criptográfica a cada email enviado por tu servidor. El servidor de correo del destinatario verifica esa firma consultando la clave pública publicada en tu DNS. Si la firma es válida, confirma que el email realmente fue enviado por tu servidor y que su contenido no fue modificado en tránsito.

# El registro DKIM se publica como registro DNS TXT:
# Tipo: TXT
# Nombre: selector._domainkey.tudominio.com
# Valor (ejemplo — la clave real es mucho más larga):
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

# Verificar el registro DKIM de un dominio:
dig TXT default._domainkey.tudominio.com

# En Plesk, DKIM se activa desde:
# Correo > Configuración del servidor de correo > Firma DomainKeys (DKIM)
# Plesk genera automáticamente el par de claves y publica el registro DNS

# Verificar que DKIM está firmando correctamente los emails:
# Envía un email a check-auth@verifier.port25.com y recibirás un informe
# con el resultado del SPF, DKIM y DMARC de tu dominio

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC es la capa de política que une SPF y DKIM. Define qué debe hacer el servidor receptor cuando un email falla la verificación SPF o DKIM, y solicita informes periódicos de autenticación para monitorizar el uso de tu dominio en el correo.

# Registro DMARC básico (política "none" para monitorizar sin bloquear):
# Tipo: TXT
# Nombre: _dmarc.tudominio.com
# Valor:
v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; ruf=mailto:dmarc@tudominio.com; fo=1

# Política DMARC progresiva (buena práctica de implementación):
# Fase 1: p=none — Monitorizar sin rechazar (recopilar datos durante 2-4 semanas)
v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com

# Fase 2: p=quarantine — Enviar a spam los emails que fallen la verificación
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@tudominio.com

# Fase 3: p=reject — Rechazar los emails que fallen la verificación (máxima protección)
v=DMARC1; p=reject; rua=mailto:dmarc@tudominio.com; ruf=mailto:dmarc@tudominio.com

# Verificar el registro DMARC de un dominio:
dig TXT _dmarc.tudominio.com

Diagnóstico de problemas de conexión SSL en el correo

El cliente de correo muestra "Error de certificado SSL" o "No se puede verificar la identidad del servidor"

Este error aparece cuando el certificado SSL del servidor de correo tiene algún problema desde el punto de vista del cliente:

• El certificado está caducado: verifica la fecha de caducidad con openssl s_client y renueva el certificado en Plesk o con Certbot.
• El nombre del certificado no coincide: el certificado es para tudominio.com pero el cliente se conecta a mail.tudominio.com. Asegúrate de que el certificado incluye el subdominio mail.tudominio.com.
• El certificado es autofirmado: no está firmado por una CA reconocida. Instala un certificado de Let's Encrypt en el servidor de correo.
• La cadena de certificados está incompleta: falta el certificado intermedio. El servidor debe presentar el fullchain.pem de Let's Encrypt, no solo el cert.pem.

# Diagnóstico completo del certificado del servidor de correo:
# IMAP SSL (puerto 993):
openssl s_client -connect mail.tudominio.com:993 2>&1 | head -30

# SMTP SSL implícito (puerto 465):
openssl s_client -connect mail.tudominio.com:465 2>&1 | head -30

# SMTP con STARTTLS (puerto 587):
openssl s_client -starttls smtp -connect mail.tudominio.com:587 2>&1 | head -30

# Verificar si la cadena de certificados está completa:
echo | openssl s_client -connect mail.tudominio.com:993 2>/dev/null | grep -E "Certificate chain|depth|verify"
# Debe mostrar al menos 2 certificados: el del servidor y el intermedio de Let's Encrypt

El cliente de correo no puede conectarse al servidor de correo

# Verificar que los puertos de correo están abiertos en el servidor:
# Desde el servidor (verifica que el servicio escucha):
ss -tlnp | grep -E ":993|:995|:465|:587|:25"

# Desde el cliente (verifica que el puerto es accesible desde internet):
nc -zv mail.tudominio.com 993
nc -zv mail.tudominio.com 465
nc -zv mail.tudominio.com 587

# Si el puerto no responde, verificar el firewall del servidor:
# En Ubuntu/Debian con UFW:
sudo ufw status | grep -E "993|995|465|587|25"
sudo ufw allow 993/tcp   # IMAP SSL
sudo ufw allow 995/tcp   # POP3 SSL
sudo ufw allow 465/tcp   # SMTP SSL
sudo ufw allow 587/tcp   # SMTP STARTTLS

# En CentOS/AlmaLinux con firewalld:
sudo firewall-cmd --list-services
sudo firewall-cmd --permanent --add-service=imaps
sudo firewall-cmd --permanent --add-service=pop3s
sudo firewall-cmd --permanent --add-service=smtps
sudo firewall-cmd --reload

El correo enviado llega a spam

Si el correo que envías desde tu dominio llega a la carpeta de spam de los destinatarios, casi siempre es un problema de configuración de SPF, DKIM o DMARC, no de SSL/TLS. Para diagnosticarlo:

# Herramientas online para verificar la reputación y configuración del correo:
# 1. Mail Tester (mail-tester.com):
#    Envía un email a la dirección que te da y te da una puntuación de 0 a 10
#    con todos los problemas detectados (SPF, DKIM, DMARC, contenido, reputación de IP)

# 2. MXToolbox (mxtoolbox.com):
#    Verifica el registro MX, SPF, DKIM, DMARC y la reputación de la IP del servidor

# 3. Google Postmaster Tools (postmaster.google.com):
#    Si tu correo llega a Gmail y quieres ver la reputación de tu dominio e IP
#    según Google, regístrate en Postmaster Tools

# Verificar los registros de autenticación del correo desde la línea de comandos:
dig MX tudominio.com           # Registro MX: servidor de correo del dominio
dig TXT tudominio.com          # SPF y otros registros TXT
dig TXT _dmarc.tudominio.com   # Política DMARC
dig TXT default._domainkey.tudominio.com  # Clave pública DKIM

Obligaciones legales: el correo y el RGPD

El correo electrónico frecuentemente contiene datos personales: nombres, apellidos, direcciones, números de teléfono, información médica, datos financieros. El RGPD (Reglamento General de Protección de Datos) exige que estos datos estén protegidos tanto en reposo como en tránsito.

El artículo 32 del RGPD establece que los responsables del tratamiento deben implementar medidas técnicas apropiadas para garantizar un nivel de seguridad adecuado al riesgo, citando explícitamente el cifrado como una de esas medidas. Transmitir datos personales por correo sin cifrado SSL/TLS puede considerarse una infracción del principio de integridad y confidencialidad del RGPD.

Las implicaciones prácticas para las empresas españolas son:

• Todos los clientes de correo de la empresa deben configurarse con SSL/TLS (puertos 993, 465).
• El webmail de empresa debe accederse solo por HTTPS (nunca por HTTP).
• Los dispositivos móviles con acceso al correo corporativo deben configurarse con SSL/TLS.
• Si se usan servicios de correo masivo (newsletters, transaccional), el proveedor debe garantizar el cifrado TLS en el envío.

Preguntas frecuentes sobre el correo seguro con SSL/TLS

¿Cuál es la diferencia entre el puerto 465 y el puerto 587 para SMTP?

Ambos puertos se usan para enviar correo desde clientes de correo (submission), pero con métodos de cifrado distintos. El puerto 465 usa SSL/TLS implícito: la conexión está cifrada desde el primer byte y nunca hay comunicación sin cifrar. El puerto 587 usa STARTTLS: la conexión comienza sin cifrar en texto plano y se actualiza a TLS cuando el cliente envía el comando STARTTLS. En 2026 se recomienda el puerto 465 (SSL implícito) por ser más seguro: elimina la pequeña ventana de comunicación sin cifrar del STARTTLS y es immune al ataque de downgrade conocido como STARTTLS stripping.

¿Es obligatorio usar SSL/TLS en el correo de empresa?

Obligatorio en el sentido legal depende del contexto, pero en la práctica no hay ninguna razón para no usarlo en 2026. Si tu empresa trata datos personales de ciudadanos europeos (lo cual incluye a prácticamente todas las empresas), el RGPD exige medidas técnicas apropiadas para proteger esos datos en tránsito, y el cifrado TLS es la medida estándar. Desde el punto de vista técnico, SSL/TLS no tiene ningún inconveniente: no ralentiza el correo de forma perceptible y es completamente transparente para el usuario una vez configurado correctamente.

¿Por qué mi cliente de correo da un error de certificado aunque el servidor funciona bien?

Los errores de certificado en el correo ocurren cuando el certificado SSL del servidor de correo tiene algún problema desde el punto de vista del cliente: está caducado, el nombre del certificado no coincide con el servidor al que se conecta el cliente (por ejemplo, el certificado es para tudominio.com pero el cliente se conecta a mail.tudominio.com), la cadena de certificados está incompleta (falta el certificado intermedio), o el certificado es autofirmado. La solución más común es asegurarse de que el certificado de Let's Encrypt instalado en el servidor de correo incluye el subdominio mail.tudominio.com y que el servidor presenta el fullchain.pem y no solo el cert.pem.

¿Qué diferencia hay entre SSL/TLS en el correo y el cifrado de extremo a extremo (E2EE)?

SSL/TLS en el correo cifra la comunicación en tránsito entre tu cliente de correo y el servidor de correo, y entre servidores de correo. Pero el email se almacena sin cifrar en el servidor: el proveedor de hosting puede técnicamente leer los emails. El cifrado de extremo a extremo (E2EE) como S/MIME o PGP cifra el contenido del email de forma que solo el destinatario puede descifrarlo: ni el proveedor de correo, ni los servidores intermedios, ni nadie que intercepte el tráfico puede leer el contenido. E2EE es más seguro pero requiere que tanto el emisor como el receptor lo configuren, lo que limita su adopción masiva. En 2026, SSL/TLS es el estándar universal; E2EE se usa principalmente en entornos que requieren confidencialidad extrema.

¿Por qué el correo que envío llega a spam aunque tengo SSL/TLS configurado?

El SSL/TLS solo cifra la comunicación y no afecta directamente a si el correo llega a spam o no. La entregabilidad del correo depende principalmente de SPF, DKIM y DMARC (que autentican que el correo realmente viene de tu servidor y no de un spammer), la reputación de la IP del servidor de correo (si la IP está en listas negras, el correo puede ir a spam), y el contenido del propio email (asunto, cuerpo, ratio texto/imagen). Verifica tu puntuación en mail-tester.com enviando un email de prueba: te dará una puntuación de 0 a 10 con todos los problemas específicos que tienes.

¿Puedo usar el mismo certificado SSL del sitio web para el servidor de correo?

Sí, siempre que el certificado incluya el subdominio del servidor de correo. Si tu web usa tudominio.com y tu correo usa mail.tudominio.com, puedes usar el mismo certificado si ese certificado es un wildcard (*.tudominio.com) que cubre todos los subdominios, o un certificado multi-dominio (SAN) que incluye específicamente mail.tudominio.com. Un certificado solo para tudominio.com no cubre mail.tudominio.com y dará error de certificado en los clientes de correo. En Plesk, la configuración del certificado para el correo se gestiona de forma independiente a la del sitio web, aunque pueden compartir el mismo certificado.