Check SMTP

Qué verifica

Un monitor SMTP se conecta al host y al puerto desde cada una de sus regiones, lee el banner del servidor y envía EHLO datargo.monitor. El check se supera cuando el banner empieza por 220 y la primera línea de la respuesta al EHLO empieza por 250. Cualquier otro código, una conexión rechazada o un timeout lo hacen fallar. Con el subcheck de certificado activado, un check superado continúa hacia TLS, por STARTTLS o directamente en el puerto 465, y evalúa caducidad, emisor, sujeto y confianza.

Úsalo cuando

• Un servidor de correo debe aceptar conexiones en el 25 o el 587 y responder como servidor SMTP, no solo mantener el puerto abierto.
• Hay que vigilar el certificado detrás de STARTTLS. El check de certificado TLS solo hace un handshake directo, así que el certificado de un puerto de submission con STARTTLS se comprueba aquí.
• El correo saliente de una aplicación depende de un relay, y un relay que deja de responder debe abrir un incidente.

El check no inicia sesión, no envía mensajes y no ejecuta MAIL FROM ni RCPT TO, así que no dice nada sobre la entrega. Para SPF y DMARC del dominio, usa el check de higiene DNS. Usa el check IMAP para un servidor de buzones y su certificado, y el check de puerto TCP para un puerto sin diálogo de protocolo.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Configuración

Objetivo. Un nombre de host o una dirección IP sin esquema, ruta ni espacios (etiquetas de hasta 63 caracteres, 253 en total), más un puerto opcional de 1 a 65535. Sin puerto, el motor comprueba el puerto 25, aunque el formulario sugiere el 587. Cada dirección resuelta se valida antes de contactarla. Las direcciones de loopback, privadas, link-local y de metadatos de nube se rechazan, así que el monitor no puede llegar a una red interna.

Certificado TLS

Un check superado puede continuar hacia TLS y evaluar el certificado. En el puerto 465 usa un handshake directo, y en cualquier otro puerto el diálogo STARTTLS (banner, EHLO hasta su última línea, STARTTLS, 220). Sin el subcheck, el monitor sigue mostrando el certificado que vio, pero no se aplican ni política ni ventana de aviso.

Cómo se ejecuta un check

1. Cada región a la que le toca el intervalo resuelve el host con el resolver propio del nodo.
2. Cada dirección resuelta de la familia elegida se valida contra los rangos bloqueados y después se conecta por separado.
3. Por dirección, la sonda lee la línea del banner, envía EHLO datargo.monitor y lee la primera línea de la respuesta. El diálogo completo debe terminar dentro del límite de 10 s.
4. Un banner que empieza por 220 y una respuesta al EHLO que empieza por 250 superan el check. Cualquier otro código, un error de E/S o un timeout lo hacen fallar.
5. Solo un check superado con tls_cert.enabled ejecuta la política de certificado, una vez por check. Usa un handshake directo en el 465 y el diálogo STARTTLS en cualquier otro puerto.
6. Cada check lee el certificado que presenta el servidor para mostrarlo, con o sin el subcheck. Esta lectura nunca cambia el veredicto.
7. El resultado de la región va al control plane. La política de alertas decide cuándo las regiones que fallan abren un incidente, por defecto cuando 2 regiones coinciden en 2 checks consecutivos.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Qué contiene un resultado

Banner

La línea de detalle lleva el banner que envió el servidor. Si el check falla, lleva SMTP error: ... con la respuesta del servidor, o Timeout.

Tiempo de respuesta

Tiempo desde la conexión hasta la respuesta al EHLO, por región y por dirección. Con varias direcciones se informa el mínimo entre ellas.

Capa de causa

Si el fallo estuvo en el DNS del objetivo (NXDOMAIN o NODATA) o en su aplicación, después de resolverse el nombre. Las demás causas se registran como unknown.

Certificado

El certificado se lee por STARTTLS o en el puerto 465. El resultado conserva su nombre común, nombres alternativos, emisor y fechas de validez, y si es autofirmado y de confianza. Con el subcheck activado, lleva el aviso en cuanto el certificado entra en su ventana de aviso.

Región, familia, dirección

Cada resultado lleva la región que lo midió, y un subresultado por familia IP y por dirección.

Estados y gravedad

• okEl banner empieza por 220 y la respuesta al EHLO empieza por 250. Con el subcheck activado, además se cumple la política de certificado, y un certificado dentro de su ventana de aviso mantiene este estado.
• degradadoUna familia IP falla mientras la otra responde, o fallan algunas de varias direcciones resueltas, con el family_fail_severity por defecto.
• caídoLa conexión se rechaza, expira o se bloquea, o el host no resuelve. El check también está caído cuando el banner o la respuesta al EHLO llevan otro código. Lo mismo ocurre cuando la política de certificado falla por caducidad, por un handshake rechazado o porque no coinciden el emisor o el sujeto.
• errorLa configuración no se puede ejecutar. Cuenta como caída con gravedad critical.

Confirmado por quórum: por defecto, 2 regiones deben informar del fallo antes de que se abra un incidente. El valor por defecto de la organización pide 2 regiones y 2 checks consecutivos. Un monitor puede llevar su propia regla con número o porcentaje, checks consecutivos y duración mínima.

Planes y límites

Intervalo mínimo

300 s en Free, 60 s en Pulse, 30 s en Sentinel, 15 s en Command y 10 s en Enterprise. El formulario web ofrece 30 s, 1 min, 5 min, 15 min y 1 h. Los mínimos de 15 s y 10 s solo se alcanzan por MCP.

Regiones

2 de 6 en Free, 3 de 6 en Pulse y las 6 desde Sentinel.

Monitores

10 en Free, 50 en Pulse, 150 en Sentinel, 500 en Command y un cupo a medida en Enterprise. Los once tipos de check de sonda comparten este cupo. Los monitores heartbeat y de agente usan cupos propios.

Comparar todos los límites

Desde la pipeline o un agente

La misma config sirve en el paso de despliegue, en un cliente MCP como Claude Code y en el formulario de arriba. create_monitor necesita una clave de API válida para toda la organización. Si omites regions, el plan aplica su valor por defecto.

{
  "name": "Mail relay",
  "type": "smtp",
  "interval_seconds": 60,
  "config": {
    "host": "mail.example.com",
    "port": 587,
    "tls_cert": { "enabled": true, "warn_days": 21 }
  }
}

Cada interfaz, con su límite

Límites

• Sin autenticación, sin envío de mensajes y sin MAIL FROM ni RCPT TO. El check demuestra que el servidor responde, no que entrega.
• La sonda de vida lee solo la primera línea de la respuesta al EHLO. Las extensiones que anuncia el servidor no se evalúan.
• Un monitor creado sin puerto comprueba el 25, no el 587.
• SPF y DMARC del dominio no se leen aquí. Los cubre el check de higiene DNS.
• Se rechazan los objetivos en direcciones privadas, de loopback, link-local y de metadatos de nube.
• No todas las regiones sondean IPv6, así que seleccionar ipv6 restringe las regiones utilizables. El formulario ofrece IPv6 solo cuando el host resuelve a un registro AAAA o es un literal IPv6.

Tipos de check relacionados

• Check IMAPAlcanzabilidad de un servidor IMAP por su saludo, en el 993 tras un handshake TLS, con una política de certificado opcional.
• Check de certificado TLSCaducidad, emisor y sujeto de un certificado por handshake TLS directo, con un aviso antes de la caducidad.
• Check de higiene DNSSPF, DMARC con su política y CAA de un dominio, calificados como postura y nunca como caída.
• Check de puerto TCPSi un puerto acepta conexiones, opcionalmente con el certificado que sirve.

Todos los tipos de check