Check SMTP

Cosa verifica

Un monitor SMTP si connette a host e porta da ciascuna delle sue regioni, legge il banner del server e invia EHLO datargo.monitor. Il check è superato quando il banner inizia con 220 e la prima riga della risposta a EHLO inizia con 250. Qualsiasi altro codice, una connessione rifiutata o un timeout lo fanno fallire. Con il subcheck del certificato attivo, un check superato prosegue in TLS, via STARTTLS o direttamente sulla porta 465, e giudica scadenza, emittente, soggetto e fiducia.

Da usare quando

• Un server di posta deve accettare connessioni sulla porta 25 o 587 e rispondere come server SMTP, non solo tenere aperta la porta.
• Il certificato dietro STARTTLS va tenuto sotto controllo. Il check del certificato TLS esegue solo un handshake diretto, quindi il certificato di una porta di submission con STARTTLS si controlla qui.
• La posta in uscita di un’applicazione dipende da un relay, e un relay che smette di rispondere deve aprire un incident.

Il check non fa il login, non invia messaggi e non esegue MAIL FROM o RCPT TO, quindi non dice nulla sulla consegna. Per SPF e DMARC del dominio usa il check di igiene DNS. Usa il check IMAP per un server di caselle di posta e il suo certificato, e il check TCP per una porta senza dialogo di protocollo.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Configurazione

Target. Un nome host o un indirizzo IP senza schema, percorso o spazi (label fino a 63 caratteri, 253 in totale), più una porta opzionale da 1 a 65535. Senza porta il motore controlla la porta 25, anche se il modulo propone la 587. Ogni indirizzo risolto viene validato prima di essere contattato. Gli indirizzi loopback, privati, link-local e di metadata cloud vengono rifiutati, così il monitor non può raggiungere una rete interna.

Certificato TLS

Un check superato può proseguire in TLS e giudicare il certificato. Sulla porta 465 usa un handshake diretto, su ogni altra porta il dialogo STARTTLS (banner, EHLO fino all’ultima riga, STARTTLS, 220). Senza il subcheck il monitor mostra comunque il certificato che ha visto, ma non si applicano né una policy né una finestra di avviso.

Come si svolge un check

1. Ogni regione a cui tocca l’intervallo risolve l’host tramite il resolver del proprio nodo.
2. Ogni indirizzo risolto della famiglia scelta viene validato contro gli intervalli di indirizzi bloccati, poi contattato separatamente.
3. Per ogni indirizzo la sonda legge la riga del banner, invia EHLO datargo.monitor e legge la prima riga della risposta. L’intero dialogo deve concludersi entro il limite di 10 s.
4. Un banner che inizia con 220 e una risposta a EHLO che inizia con 250 superano il check. Qualsiasi altro codice, un errore di I/O o un timeout lo fanno fallire.
5. Solo un check superato con tls_cert.enabled esegue la policy sul certificato, una volta per check. Usa un handshake diretto sulla 465 e il dialogo STARTTLS su ogni altra porta.
6. Ogni check legge il certificato presentato dal server per mostrarlo, con o senza il subcheck. Questa lettura non cambia mai il verdetto.
7. Il risultato della regione va al control plane. La regola di alert decide quando le regioni in errore aprono un incident, di default quando 2 regioni concordano su 2 check consecutivi.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Cosa contiene un risultato

Banner

La riga di dettaglio porta il banner inviato dal server. In caso di fallimento porta SMTP error: ... con la risposta del server, oppure Timeout.

Tempo di risposta

Tempo dalla connessione alla risposta a EHLO, per regione e per indirizzo. Con più indirizzi viene riportato il minimo tra loro.

Livello della causa

Indica se il fallimento dipendeva dal DNS del target (NXDOMAIN o NODATA) o dalla sua applicazione, dopo la risoluzione del nome. Le altre cause vengono riportate come unknown.

Certificato

Il certificato viene letto via STARTTLS o sulla porta 465. Il risultato conserva common name, nomi alternativi, emittente e date di validità, e indica se è autofirmato e attendibile. Con il subcheck attivo porta l’avviso non appena il certificato entra nella sua finestra di avviso.

Regione, famiglia, indirizzo

Ogni risultato porta la regione che l’ha misurato, e un sotto-risultato per famiglia IP e per indirizzo.

Stati e gravità

• okIl banner inizia con 220 e la risposta a EHLO inizia con 250. Con il subcheck attivo regge anche la policy sul certificato, e un certificato dentro la sua finestra di avviso mantiene questo stato.
• degradatoUna famiglia IP fallisce mentre l’altra risponde, oppure falliscono alcuni dei vari indirizzi risolti, con il valore predefinito di family_fail_severity.
• downLa connessione viene rifiutata, va in timeout o viene bloccata, oppure l’host non si risolve. Il check è down anche quando il banner o la risposta a EHLO porta un altro codice. Lo stesso vale quando la policy sul certificato fallisce per scadenza, per un handshake rifiutato o per un emittente o un soggetto non corrispondente.
• erroreLa configurazione non può essere eseguita. Conta come disservizio con gravità critica.

Confermato dal quorum: di default, 2 regioni devono segnalare il guasto prima che si apra un incident. Il default dell’organizzazione richiede 2 regioni e 2 check consecutivi. Un monitor può avere una regola propria con numero o percentuale, check consecutivi e durata minima.

Piani e limiti

Intervallo minimo

300 s in Free, 60 s in Pulse, 30 s in Sentinel, 15 s in Command e 10 s in Enterprise. Il modulo web offre 30 s, 1 min, 5 min, 15 min e 1 h. I minimi di 15 s e 10 s si raggiungono solo tramite MCP.

Regioni

2 su 6 in Free, 3 su 6 in Pulse e tutte e 6 da Sentinel.

Monitor

10 in Free, 50 in Pulse, 150 in Sentinel, 500 in Command e una quota su misura in Enterprise. Gli undici tipi di check regionali condividono questa quota. I monitor heartbeat e agent attingono a quote proprie.

Confronta tutti i limiti

Dalla pipeline o da un agente

La stessa config funziona nello step di deploy, in un client MCP come Claude Code e nel modulo qui sopra. create_monitor richiede una chiave API valida per tutta l’organizzazione. Se ometti regions, il piano sceglie il suo default.

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

Ogni interfaccia, con il suo limite

Limiti

• Nessuna autenticazione, nessun messaggio inviato, niente MAIL FROM o RCPT TO. Il check prova che il server risponde, non che consegna.
• La sonda di disponibilità legge solo la prima riga della risposta a EHLO. Le estensioni annunciate dal server non vengono valutate.
• Un monitor creato senza porta controlla la porta 25, non la 587.
• SPF e DMARC del dominio non vengono letti qui. Li copre il check di igiene DNS.
• I target su indirizzi privati, loopback, link-local e di metadata cloud vengono rifiutati.
• Non tutte le regioni sondano IPv6, quindi selezionare ipv6 restringe le regioni utilizzabili. Il modulo offre IPv6 solo quando l’host risolve verso un record AAAA o è un letterale IPv6.

Tipi di check correlati

• Check IMAPRaggiungibilità di un server IMAP tramite il suo saluto, sulla 993 dopo un handshake TLS, con una policy opzionale sul certificato.
• Check del certificato TLSScadenza, emittente e soggetto di un certificato tramite handshake TLS diretto, con un avviso prima della scadenza.
• Check di igiene DNSSPF, DMARC con la sua policy e CAA di un dominio, valutati come postura e mai come disservizio.
• Check della porta TCPSe una porta accetta una connessione, a scelta con il certificato servito su di essa.

Tutti i tipi di check