Check SMTP

Ce qu’il vérifie

Un monitor SMTP se connecte à l’hôte et au port depuis chacune de ses régions, lit la bannière du serveur et envoie EHLO datargo.monitor. Le check réussit quand la bannière commence par 220 et que la première ligne de la réponse EHLO commence par 250. Tout autre code, une connexion refusée ou un délai dépassé le fait échouer. Avec le sous-check de certificat activé, un check réussi se poursuit en TLS, via STARTTLS ou directement sur le port 465, et juge l’expiration, l’émetteur, le sujet et la confiance.

À utiliser quand

• Un serveur mail doit accepter les connexions sur 25 ou 587 et répondre comme un serveur SMTP, pas seulement garder le port ouvert.
• Le certificat derrière STARTTLS doit être surveillé. Le check de certificat TLS ne fait qu’un handshake direct, le certificat d’un port de soumission STARTTLS se vérifie donc ici.
• Le mail sortant d’une application dépend d’un relais, et un relais qui cesse de répondre doit ouvrir un incident.

Le check ne se connecte à aucun compte, n’envoie aucun message et n’exécute ni MAIL FROM ni RCPT TO. Il ne dit donc rien de la remise. Pour SPF et DMARC du domaine, utilisez le check d’hygiène DNS. Utilisez le check IMAP pour un serveur de boîtes mail et son certificat, et le check TCP pour un port sans dialogue protocolaire.

Balayez horizontalement pour examiner la vue du produit.

app.perstat.io

Configuration

Cible. Un nom d’hôte ou une adresse IP sans schéma, chemin ni espace (étiquettes de 63 caractères au plus, 253 au total), plus un port facultatif de 1 à 65535. Sans port, le moteur vérifie le port 25, même si le formulaire propose 587. Chaque adresse résolue est validée avant d’être contactée. Les adresses de boucle locale, privées, link-local et de métadonnées cloud sont refusées, le monitor ne peut donc pas atteindre un réseau interne.

Certificat TLS

Un check réussi peut se poursuivre en TLS et juger le certificat. Sur le port 465, il passe par un handshake direct, sur tout autre port par le dialogue STARTTLS (bannière, EHLO jusqu’à sa dernière ligne, STARTTLS, 220). Sans le sous-check, le monitor affiche quand même le certificat qu’il a vu, mais aucune politique ni fenêtre d’avertissement ne s’applique.

Déroulement d’un check

1. Chaque région dont l’intervalle est échu résout l’hôte par le résolveur du nœud.
2. Chaque adresse résolue de la famille choisie est validée contre les plages bloquées, puis contactée séparément.
3. Par adresse, la sonde lit la ligne de bannière, envoie EHLO datargo.monitor et lit la première ligne de la réponse. Tout le dialogue doit tenir dans la limite de 10 s.
4. Une bannière commençant par 220 et une réponse EHLO commençant par 250 réussissent. Tout autre code, une erreur d’E/S ou un délai dépassé échoue.
5. Seul un check réussi avec tls_cert.enabled exécute la politique de certificat, une fois par check. Elle passe par un handshake direct sur 465 et par le dialogue STARTTLS sur tout autre port.
6. Chaque check lit, pour l’affichage, le certificat présenté par le serveur, avec ou sans sous-check. Cette lecture ne change jamais le verdict.
7. Le résultat de la région part au plan de contrôle. La politique d’alerte décide quand des régions en échec ouvrent un incident, par défaut dès que 2 régions concordent sur 2 checks consécutifs.

Balayez horizontalement pour examiner la vue du produit.

app.perstat.io

Ce que contient un résultat

Bannière

La ligne de détail porte la bannière envoyée par le serveur. En cas d’échec, elle porte SMTP error: ... avec la réponse du serveur, ou Timeout.

Temps de réponse

Temps entre la connexion et la réponse EHLO, par région et par adresse. Avec plusieurs adresses, c’est le minimum qui est rapporté.

Couche de cause

Indique si l’échec relevait du DNS de la cible (NXDOMAIN ou NODATA) ou de son application, une fois le nom résolu. Les autres causes sont signalées comme inconnues.

Certificat

Le certificat est lu via STARTTLS ou sur le port 465. Le résultat conserve son common name, ses noms alternatifs, son émetteur et ses dates de validité, et indique s’il est auto-signé et de confiance. Avec le sous-check activé, il porte l’avertissement dès que le certificat entre dans sa fenêtre d’avertissement.

Région, famille, adresse

Chaque résultat porte la région qui l’a mesuré, et un sous-résultat par famille IP et par adresse.

États et gravité

• okLa bannière commence par 220 et la réponse EHLO par 250. Avec le sous-check activé, la politique de certificat tient aussi, et un certificat dans sa fenêtre d’avertissement conserve cet état.
• dégradéUne famille IP échoue pendant que l’autre répond, ou certaines de plusieurs adresses résolues échouent, à la valeur par défaut de family_fail_severity.
• en panneLa connexion est refusée, expire ou est bloquée, ou l’hôte ne se résout pas. Le check est aussi en panne quand la bannière ou la réponse EHLO porte un autre code. Il en va de même quand la politique de certificat échoue pour cause d’expiration ou de handshake rejeté, ou parce que l’émetteur ou le sujet ne correspond pas.
• erreurLa configuration ne peut pas s’exécuter. Cet état compte comme une panne de gravité critique.

Confirmé par quorum : par défaut, 2 régions doivent signaler l’échec avant l’ouverture d’un incident. Par défaut, l’organisation exige 2 régions et 2 checks consécutifs. Un monitor peut porter sa propre règle avec un nombre ou un pourcentage, des checks consécutifs et une durée minimale.

Offres et limites

Intervalle minimal

300 s en Free, 60 s en Pulse, 30 s en Sentinel, 15 s en Command et 10 s en Enterprise. Le formulaire web propose 30 s, 1 min, 5 min, 15 min et 1 h. Les intervalles de 15 s et 10 s ne sont accessibles que par MCP.

Régions

2 sur 6 en Free, 3 sur 6 en Pulse et les 6 à partir de Sentinel.

Monitors

10 en Free, 50 en Pulse, 150 en Sentinel, 500 en Command et un quota sur mesure en Enterprise. Les onze types de sonde partagent ce quota. Les monitors heartbeat et agent puisent dans leurs propres quotas.

Comparer toutes les limites

Depuis le pipeline ou un agent

La même config fonctionne dans l’étape de déploiement, dans un client MCP comme Claude Code et dans le formulaire ci-dessus. create_monitor exige une clé API valable pour toute l’organisation. Si vous omettez regions, l’offre applique sa valeur par défaut.

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

Chaque interface, avec sa limite

Limites

• Pas d’authentification, aucun message envoyé, ni MAIL FROM ni RCPT TO. Le check prouve que le serveur répond, pas qu’il remet le courrier.
• La sonde de vivacité ne lit que la première ligne de la réponse EHLO. Les extensions annoncées par le serveur ne sont pas évaluées.
• Un monitor créé sans port vérifie le port 25, pas 587.
• SPF et DMARC du domaine ne sont pas lus ici. Le check d’hygiène DNS s’en charge.
• Les cibles sur des adresses privées, de boucle locale, link-local et de métadonnées cloud sont refusées.
• Toutes les régions ne sondent pas IPv6, sélectionner ipv6 restreint donc les régions utilisables. Le formulaire ne propose IPv6 que si l’hôte se résout en enregistrement AAAA ou est un littéral IPv6.

Types de checks liés

• Check IMAPJoignabilité d’un serveur IMAP par son message d’accueil, sur 993 après un handshake TLS, avec une politique de certificat en option.
• Check de certificat TLSExpiration, émetteur et sujet d’un certificat par handshake TLS direct, avec un avertissement avant l’expiration.
• Check d’hygiène DNSSPF, DMARC avec sa politique et CAA d’un domaine, notés comme posture et jamais comme panne.
• Check de port TCPUn port accepte ou non les connexions, avec en option le certificat qu’il sert.

Tous les types de checks