Check di igiene DNS

Cosa verifica

Un monitor di igiene DNS legge 3 record di un dominio da ciascuna delle sue regioni a ogni intervallo. SPF e DMARC decidono se la posta del dominio viene recapitata, e CAA decide chi può emettere certificati a suo nome. SPF presente, DMARC con p=quarantine o p=reject e un record CAA danno ok, e qualsiasi cosa in meno dà degraded. La valutazione non scende mai sotto degraded, così una postura indebolita della posta o dei certificati arriva sulla dashboard senza svegliare nessuno.

Da usare quando

• Un dominio invia posta, come fatture, reset delle password o notifiche, e i suoi record SPF e DMARC devono sopravvivere a ogni modifica del DNS.
• Una policy DMARC none o un record CAA mancante devono comparire come rilievo con una marca temporale, senza aprire un incident.
• Il dominio non ha un tuo endpoint HTTP su cui un monitor HTTP(S) potrebbe portare il subcheck di igiene DNS.

Non giudica se il dominio risolve o se il server di posta accetta connessioni. Un record che deve portare un valore preciso richiede il check del record DNS, e il percorso della posta richiede i check SMTP e IMAP. NS, SOA, DNSSEC e scadenza della registrazione appartengono al check del dominio.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Configurazione

Dominio. Il dominio di cui vengono letti i record, per esempio example.com. Un punto finale viene rimosso. I 3 lookup vanno all’apex e a _dmarc. sotto di esso, tramite il resolver del nodo, da ogni regione selezionata.

Come si svolge un check

1. Quando scatta un check, ogni regione chiede al resolver del proprio nodo i record TXT all’apex del dominio e ne cerca uno che contenga v=spf1.
2. Legge i record TXT sotto _dmarc.<domain>, ne cerca uno che contenga v=dmarc1 e ne estrae la policy p=.
3. Chiede i record CAA all’apex. Conta solo la loro presenza, non il contenuto.
4. Un record SPF o DMARC mancante dà degraded, e il dettaglio nomina cosa manca. Altrimenti una policy DMARC diversa da quarantine o reject, oppure nessun record CAA, dà degraded, e il dettaglio nomina cosa è debole. Tutto a posto dà ok.
5. Il risultato della regione va al control plane. Un risultato degradato resta fuori dalla valutazione degli incident. Lì conta come disservizio solo un errore, una volta raggiunto il quorum.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Cosa contiene un risultato

Riga di dettaglio

Una riga nomina i record mancanti (SPF, DMARC) o quelli deboli, come DMARC p=none o nessun CAA. Quando tutto è a posto recita SPF · DMARC p=reject · CAA, con la policy che il record porta.

Tempo di risposta

Il tempo dei 3 lookup insieme, per regione. Questo tipo non riporta né un codice di risposta né un livello della causa.

Regione

Ogni risultato porta la regione che l’ha misurato. Non ci sono sotto-risultati per famiglia o per indirizzo.

Stati e gravità

• okSPF è presente, DMARC porta p=quarantine o p=reject, ed esiste un record CAA.
• degradatoSPF o DMARC manca, DMARC porta una policy diversa da quarantine o reject, oppure non esiste nessun record CAA. Un lookup che fallisce o non restituisce nulla conta come mancante, non come errore.
• erroreIl check non può girare: la configurazione non può essere letta, il dominio è vuoto oppure il resolver del nodo non si inizializza. Conta come disservizio con gravità critica.

Confermato dal quorum: di default, 2 regioni devono segnalare il guasto prima che si apra un incident. La valutazione di postura è ok o degradato, mai down. Solo un errore, quando il check non può girare, conta come disservizio. Il default dell’organizzazione richiede 2 regioni e 2 check consecutivi, e un monitor può avere una regola propria (numero o percentuale, check consecutivi e durata minima).

Piani e limiti

Intervallo minimo

Free consente 300 s, Pulse 60 s e Sentinel 30 s. Command consente 15 s ed Enterprise 10 s, entrambi solo tramite MCP. Il modulo web offre 30 s, 1 min, 5 min, 15 min e 1 h.

Regioni

Free usa 2 regioni su 6 e Pulse 3 su 6. Tutte e 6 sono disponibili da Sentinel.

Monitor

Free include 10 monitor di sonda, Pulse 50, Sentinel 150 e Command 500. Le quote di Enterprise sono su misura. Il conteggio copre gli 11 tipi di check eseguiti dalle sonde, e host agent e heartbeat hanno 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": "example.com mail hygiene",
  "type": "dns_hygiene",
  "interval_seconds": 3600,
  "config": {
    "domain": "example.com"
  }
}

Ogni interfaccia, con il suo limite

Limiti

• Non c’è un controllo della sintassi SPF. Un record TXT all’apex deve solo contenere v=spf1.
• Non c’è un controllo DKIM né un controllo MX, e il contenuto di un record CAA non viene letto.
• Un lookup che fallisce conta come record mancante, non come errore di misura.
• Non ci sono famiglie IP né sotto-risultati per indirizzo. I lookup passano dal resolver del nodo, e il nodo interrompe un’esecuzione dopo 120 s.
• Un record mancante o debole non scende mai sotto degraded. Un record che deve portare un valore preciso richiede il check del record DNS.
• Dalla build del 13 settembre 2026 in poi, il validatore legge domain quando un monitor viene creato o modificato via API. Tra l’11 agosto 2026 e quella build leggeva name e rifiutava una richiesta senza di esso (name must not be empty). Il motore invece continuava a leggere domain, e i monitor esistenti hanno continuato a girare. Finché quella build non è in produzione, invia name con lo stesso valore accanto a domain.

Tipi di check correlati

• Check del record DNSUn tipo di record di un nome, risolto da ogni regione e confrontato con la risposta che ti aspetti.
• Check del dominioDelega su ogni nameserver autoritativo, scadenza della registrazione e DNSSEC di un dominio registrabile.
• Check SMTPBanner ed EHLO di un server di posta, con un controllo opzionale del certificato via STARTTLS o TLS implicito.
• Check HTTP(S)Disponibilità e risposta di un URL, con asserzioni su stato, body e TLS.

Tutti i tipi di check