Ir al contenido principal

Cómo probar la conectividad SMTP de tus servidores MX

Por CaptainDNS
Publicado el 17 de febrero de 2026

Test de conectividad SMTP de un servidor MX: banner, STARTTLS, certificado TLS y open relay
TL;DR
  • Un registro MX válido no prueba que tu servidor de correo funcione: prueba la conexión TCP, el banner, STARTTLS y el certificado TLS
  • Usa telnet para verificar la conectividad en el puerto 25 y el banner SMTP, luego openssl s_client para inspeccionar STARTTLS y el certificado
  • Los problemas comunes (puerto 25 bloqueado, certificado expirado, STARTTLS mal configurado) son silenciosos: solo un test activo los detecta
  • Automatiza el diagnóstico con el SMTP/MX Connectivity Tester de CaptainDNS para probar todos tus MX en una sola solicitud

Tus registros SPF, DKIM y DMARC están correctamente configurados. Tu dominio pasa todos los tests DNS. Sin embargo, algunos emails no llegan a destino, o llegan sin cifrado TLS. El problema no viene de la configuración DNS, sino de la capa de transporte: la conexión SMTP entre los servidores.

Esta guía te muestra cómo probar la conectividad SMTP de tus servidores MX, desde la resolución DNS hasta la inspección del certificado TLS. Cada comando es reproducible desde un terminal Linux, macOS o WSL. Ya sea que estés diagnosticando un problema de entrega o auditando la seguridad de tu infraestructura de correo, sabrás exactamente qué verificar y cómo interpretar los resultados.

Por qué probar la conectividad SMTP de tus MX

La configuración DNS (registros MX, SPF, DKIM, DMARC) es una condición necesaria, pero no suficiente. Tres categorías de problemas escapan a las herramientas de verificación DNS clásicas.

La entregabilidad depende del transporte

Si tu servidor MX es inalcanzable en el puerto 25, los servidores remitentes reciben un error "connection timed out" y reintentan durante 24 a 48 horas antes de abandonar. El mensaje se pierde, y el remitente recibe un bounce tardío. Este tipo de fallo es invisible desde tu lado mientras no pruebes activamente.

El cifrado TLS no está garantizado

En 2024, más del 95 % de los emails recibidos por Gmail transitan vía TLS (Google Transparency Report). Pero STARTTLS es oportunista: si la negociación falla silenciosamente, la conexión continúa en texto plano. Un certificado expirado o una mala configuración TLS puede degradar la seguridad de todos tus flujos entrantes sin generar alerta.

Un open relay destruye tu reputación

Un servidor SMTP que acepta retransmitir correo para cualquiera es un open relay. Los spammers lo explotan en pocas horas, y tu IP termina en las listas negras (Spamhaus, Barracuda, SpamCop). Todos tus emails salientes son entonces rechazados.

Los 7 pasos de un test de conectividad SMTP completo

Qué verifica un test SMTP completo

Un test de conectividad SMTP completo cubre siete puntos, en este orden.

PasoVerificaciónHerramienta
1Resolución DNS MXdig o nslookup
2Conexión TCP puerto 25telnet
3Banner SMTP (220)telnet
4Extensiones EHLOtelnet
5STARTTLS y versión TLSopenssl s_client
6Certificado TLS (validez, expiración, SAN)openssl s_client
7Test open relaytelnet

Cada paso puede fallar de forma independiente. Un servidor puede responder en el puerto 25, anunciar STARTTLS en EHLO, pero fallar en la negociación TLS por un certificado expirado.

Paso 1: resolver los registros MX

Antes de probar la conectividad, identifica los servidores MX de tu dominio. El comando dig devuelve los MX ordenados por prioridad:

$ dig captaindns.com MX +short
10 mx1.captaindns.com.
20 mx2.captaindns.com.

El número (10, 20) es la prioridad: los servidores remitentes contactan primero al MX con el valor más bajo. Prueba todos tus MX, no solo el primario. Un MX secundario mal configurado sigue siendo alcanzable y puede aceptar correo sin TLS.

Si dig no devuelve ningún resultado, el problema es DNS: tu dominio no tiene registro MX, o el DNS no responde.

Paso 2: probar la conexión TCP y el banner con telnet

El comando telnet prueba dos cosas en una sola operación: la apertura del puerto TCP 25 y la recepción del banner SMTP.

$ telnet mx1.captaindns.com 25
Trying 203.0.113.10...
Connected to mx1.captaindns.com.
Escape character is '^]'.
220 mx1.captaindns.com ESMTP Postfix

Interpretar el resultado

ResultadoSignificadoAcción
Connected + 220 ...Servidor alcanzable, banner OKContinuar el test
Connection refusedPuerto 25 cerrado o servicio detenidoVerificar el firewall y el servicio SMTP
Connection timed outPuerto 25 bloqueado (ISP, firewall)Probar desde otra red
220 sin hostnameBanner mal configuradoCorregir la config del MTA

Capturar las extensiones EHLO

Después del banner, envía el comando EHLO para descubrir las capacidades del servidor:

EHLO test.captaindns.com
250-mx1.captaindns.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-8BITMIME
250-SMTPUTF8
250 OK

Busca 250-STARTTLS en la respuesta: es la línea que confirma que el servidor soporta cifrado TLS. Si está ausente, el servidor solo acepta conexiones en texto plano.

Paso 3: probar STARTTLS y el certificado TLS con openssl

telnet no puede iniciar una negociación TLS. Para probar STARTTLS e inspeccionar el certificado, usa openssl s_client:

$ openssl s_client -connect mx1.captaindns.com:25 -starttls smtp
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = mx1.captaindns.com
verify return:1
---
Certificate chain
 0 s:CN = mx1.captaindns.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
[...]
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
[...]

La información clave a verificar

Versión TLS: busca la línea New, TLSv1.X. TLS 1.3 es óptimo, TLS 1.2 es aceptable. TLS 1.0 y 1.1 son obsoletos y vulnerables.

Cadena de certificados: verify return:1 en cada nivel significa que la cadena es válida. verify return:0 indica un problema (certificado expirado, emisor desconocido, SAN faltante).

Sujeto del certificado: el CN o los SAN deben corresponder al hostname del MX. Un certificado emitido para mail.captaindns.com no será válido para mx1.captaindns.com.

Verificar la fecha de expiración

$ openssl s_client -connect mx1.captaindns.com:25 -starttls smtp 2>/dev/null | openssl x509 -noout -dates
notBefore=Jan 15 00:00:00 2026 GMT
notAfter=Apr 15 23:59:59 2026 GMT

Si notAfter está en el pasado, el certificado está expirado. Los servidores remitentes que verifican certificados (vía MTA-STS o DANE) rechazarán la conexión.

Paso 4: probar el open relay

Un open relay acepta transmitir correo para destinatarios externos sin autenticación. Para detectarlo, intenta enviar un email hacia un dominio que tu servidor no gestiona:

$ telnet mx1.captaindns.com 25
220 mx1.captaindns.com ESMTP
EHLO test.captaindns.com
250 OK
MAIL FROM:<test@captaindns.com>
250 OK
RCPT TO:<test@domaine-externe.example>
550 5.7.1 Relaying denied
QUIT

Interpretar el resultado

Respuesta a RCPT TOSignificado
550 Relaying deniedServidor correctamente configurado (no es un open relay)
250 OKOpen relay detectado, corrección urgente requerida
450 o 451Greylisting activo (normal, no es un open relay)
554Rechazado por otra razón (lista negra, política)

Si tu servidor devuelve 250 OK a un RCPT TO hacia un dominio externo, está configurado como open relay. Corrige inmediatamente la configuración de tu MTA (Postfix: smtpd_relay_restrictions, Exchange: receive connectors).

Diagnosticar los problemas comunes

Puerto 25 bloqueado

Síntoma: telnet mx1.captaindns.com 25 devuelve "Connection timed out".

Causas posibles:

  • Firewall local o de red que bloquea el puerto 25 en salida
  • Proveedor cloud (AWS, Google Cloud, Azure) que bloquea el puerto 25 por defecto
  • ISP que bloquea el puerto 25 en conexiones residenciales

Diagnóstico: prueba desde un servidor fuera de tu red. Si el test funciona desde el exterior pero falla en local, el bloqueo está del lado de la red/ISP. Para más detalles sobre el bloqueo del puerto 25, consulta nuestra guía sobre los puertos SMTP.

Certificado TLS expirado

Síntoma: openssl s_client muestra verify return:0 y certificate has expired.

Impacto: los servidores que aplican MTA-STS rechazarán entregar los emails. Los servidores sin MTA-STS entregarán de todas formas (STARTTLS oportunista), pero la conexión no está autenticada.

Solución: renueva el certificado (Let's Encrypt: certbot renew), luego recarga el servicio SMTP.

STARTTLS anunciado pero falla

Síntoma: el servidor anuncia 250-STARTTLS en EHLO, pero openssl s_client -starttls smtp falla con un error de handshake.

Causas posibles:

  • Certificado referenciado en la config del MTA pero archivo ausente o ilegible
  • Permisos incorrectos en los archivos de clave privada
  • Versión TLS demasiado antigua (TLS 1.0 rechazado por el cliente)

Diagnóstico:

$ openssl s_client -connect mx1.captaindns.com:25 -starttls smtp -debug 2>&1 | head -30

Timeout de conexión (servidor lento)

Síntoma: la conexión TCP se establece, pero el banner tarda más de 30 segundos en aparecer.

Impacto: algunos servidores remitentes abandonan después de un timeout (generalmente 5 minutos para el banner, RFC 5321 sección 4.5.3.2). Un MX lento provoca retrasos en la entrega y reintentos innecesarios.

Solución: verifica la carga del servidor, las reglas de greylisting agresivas, o los lookups DNS inversos lentos (PTR) en la configuración del MTA.

Árbol de diagnóstico de los problemas SMTP comunes

Automatizar los tests SMTP

Los comandos telnet y openssl son útiles para un diagnóstico puntual, pero tienen límites: solo prueban un servidor a la vez, no producen un informe estructurado y no son prácticos para un monitoreo regular.

Script bash de verificación rápida

#!/bin/bash
# Test SMTP básico para todos los MX de un dominio
DOMAIN="captaindns.com"

echo "=== MX de $DOMAIN ==="
dig $DOMAIN MX +short | sort -n | while read priority mx; do
  mx="${mx%.}"  # Eliminar el punto final
  echo ""
  echo "--- $mx (prioridad $priority) ---"

  # Test de conexión puerto 25
  timeout 10 bash -c "echo QUIT | telnet $mx 25 2>&1" | head -5

  # Test STARTTLS + certificado
  echo | timeout 10 openssl s_client -connect $mx:25 -starttls smtp 2>/dev/null | \
    openssl x509 -noout -subject -dates 2>/dev/null || echo "STARTTLS: fallo o no soportado"
done

Este script prueba cada MX del dominio: conexión TCP, banner y certificado TLS. No cubre el test open relay (que requiere una interacción SMTP más compleja).

Herramienta en línea CaptainDNS

Para un diagnóstico completo sin instalación, el SMTP/MX Connectivity Tester de CaptainDNS prueba automáticamente todos los MX de un dominio en una sola solicitud: resolución DNS, conexión puerto 25, banner, EHLO, STARTTLS, certificado TLS y detección open relay. Los resultados se presentan con un scoring por servidor y códigos de diagnóstico explícitos.


Prueba la conectividad SMTP de tus servidores MX: usa nuestro SMTP/MX Connectivity Tester para diagnosticar en segundos todos tus MX, con validación del certificado TLS y detección open relay.


FAQ

¿Cómo probar si un servidor SMTP responde en el puerto 25?

Usa el comando telnet hostname 25. Si la conexión se establece y recibes una línea que empieza por 220, el servidor es alcanzable y el servicio SMTP funciona. Si obtienes "Connection refused" o "Connection timed out", el puerto está cerrado o bloqueado.

¿Cómo verificar el soporte STARTTLS de un servidor MX?

Conéctate con telnet hostname 25, envía EHLO tu.hostname, y busca 250-STARTTLS en la respuesta. Para probar la negociación TLS efectiva, usa openssl s_client -connect hostname:25 -starttls smtp. Si la negociación tiene éxito, STARTTLS es funcional.

¿Cómo inspeccionar un certificado TLS SMTP con openssl?

Ejecuta openssl s_client -connect hostname:25 -starttls smtp 2>/dev/null | openssl x509 -noout -text. Este comando muestra el sujeto, el emisor, las fechas de validez, los SAN (Subject Alternative Names) y el tipo de clave. Verifica que el CN o un SAN corresponda al hostname del MX.

¿Cómo detectar si un servidor es un open relay?

Conéctate al servidor, envía MAIL FROM:&lt;test@captaindns.com&gt;, luego RCPT TO:&lt;test@domaine-externe.example&gt;. Si el servidor devuelve 250 OK al RCPT TO hacia un dominio que no gestiona, es un open relay. Un servidor correctamente configurado devuelve 550 Relaying denied.

¿Por qué mi servidor MX es inalcanzable en el puerto 25?

Las causas más frecuentes: firewall que bloquea el puerto 25, proveedor cloud que bloquea el puerto 25 por defecto (AWS, GCP, Azure), servicio SMTP detenido, o registro MX apuntando a una IP incorrecta. Prueba desde una red diferente para aislar la causa.

¿Qué versión TLS es aceptable para un servidor MX?

TLS 1.2 es el mínimo aceptable en 2026. TLS 1.3 es recomendado para una seguridad óptima y mejores rendimientos (handshake más rápido). TLS 1.0 y 1.1 son obsoletos (RFC 8996) y no deberían estar activados.

¿Qué herramientas en línea prueban la conectividad SMTP?

El SMTP/MX Connectivity Tester de CaptainDNS prueba automáticamente todos los MX de un dominio: banner, EHLO, STARTTLS, certificado TLS y open relay. Otras herramientas como MXToolbox SMTP Test o CheckTLS ofrecen funcionalidades similares, pero con menos detalles sobre el certificado.

Glosario

  • Banner SMTP: primera respuesta del servidor (código 220) al establecerse la conexión TCP. Contiene el hostname y a veces el software MTA (Postfix, Exchange, Exim).
  • EHLO: Extended HELO. Comando SMTP que identifica al cliente y solicita al servidor que liste sus extensiones (STARTTLS, SIZE, PIPELINING, etc.).
  • STARTTLS: extensión SMTP (RFC 3207) que permite pasar una conexión en texto plano a una conexión cifrada TLS mediante un comando explícito.
  • Open relay: servidor SMTP que acepta transmitir correo para destinatarios externos sin autenticación. Vector de spam, causa de inclusión rápida en listas negras.
  • SAN: Subject Alternative Name. Campo del certificado TLS que lista los hostnames para los cuales el certificado es válido.
  • MTA: Mail Transfer Agent. Software servidor que transporta los emails (Postfix, Exim, Exchange, Sendmail).
  • Greylisting: técnica anti-spam que rechaza temporalmente (código 450) los emails de remitentes desconocidos. El servidor legítimo reintenta, el spammer no.

📚 Guías de SMTP y conectividad email relacionadas

Fuentes

Artículos relacionados