Perché monitorare i report TLS-RPT?
Il monitoraggio TLS-RPT rende visibili gli errori di cifratura SMTP che il tuo server non registra mai. È l'unico canale standardizzato (RFC 8460) attraverso cui i mittenti ti segnalano cosa si è rotto sul piano del trasporto. Senza di esso, un'email rifiutata per un problema TLS non lascia alcuna traccia dal lato di chi la riceve. La tua reputazione scivola. I tuoi utenti non aspettano nulla, perché ignorano che un messaggio fosse mai esistito.
Tre guasti tornano in quasi tutti i report.
Un certificato scaduto sull'MX fa fallire la negoziazione cifrata, e i mittenti in modalità rigida rifiutano il messaggio invece di consegnarlo in chiaro. Una policy MTA-STS che punta a un MX scomparso produce lo stesso esito: connessione rifiutata, posta mai arrivata. E il peggiore resta il downgrade STARTTLS, quando un apparato di rete rimuove l'annuncio STARTTLS dal dialogo SMTP. La posta passa allora in chiaro. Nessuno lo sa. Il report TLS-RPT, invece, lo vede.
Come configurare il monitoraggio TLS-RPT in 3 passaggi
Passaggio 1: Aggiungi il tuo dominio
Accedi e aggiungi il tuo dominio. CaptainDNS fornisce un indirizzo email per ricevere i report del monitor e un URL HTTPS alternativo.
Passaggio 2: Verifica la proprietà del dominio
Aggiungi il TXT di verifica di CaptainDNS per dimostrare la proprietà del dominio. La verifica del dominio e l'attivazione non confermano la ricezione dei report.
Passaggio 3: Pubblica il record TLS-RPT nel tuo dominio
Apri la configurazione del monitor per pubblicare il TXT _smtp._tls consigliato con la destinazione mailto. Controlla i destinatari mantenuti prima di sostituire un TXT esistente. Se la lettura DNS fallisce, aggiungi solo il frammento a rua= senza rimuovere altri destinatari, oppure riprova per ottenere il valore completo.
Cos'è TLS-RPT?
TLS-RPT (SMTP TLS Reporting), definito dalla RFC 8460, consente ai mittenti partecipanti di segnalare i risultati delle connessioni TLS. Il TXT indica la destinazione dei report, senza garantirne l'invio.
Esempio di record DNS:
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt-TOKEN@mailsrv1.captaindns.com"
Esempio illustrativo: sostituisci TOKEN con il token nella configurazione del tuo monitor. Per un TXT esistente, usa la raccomandazione del monitor per controllare i destinatari da mantenere. Il frammento mailto da solo non è un TXT completo.
Cosa contiene un report TLS-RPT?
Un report TLS-RPT è un documento JSON che aggrega, su una finestra di 24 ore, tutti i tentativi di connessione TLS di un mittente verso il tuo dominio. Conta le sessioni riuscite e fallite, e dettaglia ogni errore per tipo. CaptainDNS decodifica questo JSON e lo mostra in chiaro.
| Campo | Descrizione |
|---|---|
| Organizzazione mittente | Il provider di posta che ha inviato il report |
| Periodo | Timestamp di inizio e fine della finestra di reporting |
| Policy applicate | Policy MTA-STS, DANE o STARTTLS rilevate |
| Sessioni riuscite | Numero di connessioni TLS stabilite con successo |
| Sessioni fallite | Numero di errori di negoziazione TLS con dettagli dell'errore |
Gli 11 tipi di errore TLS-RPT (RFC 8460)
Il §4.3 dell'RFC 8460 definisce 11 valori di result-type, e il monitoraggio li riporta tutti. Alcuni mittenti emettono in più starttls-not-offered, una variante di starttls-not-supported estranea all'RFC: viene trattata allo stesso modo.
| Tipo di errore | Descrizione |
|---|---|
starttls-not-supported | Il server destinatario non supporta STARTTLS |
certificate-expired | Il certificato TLS presentato dall'MX è scaduto |
certificate-host-mismatch | Il certificato non corrisponde al nome host dell'MX |
certificate-not-trusted | La catena di certificati non è considerata affidabile dal mittente |
validation-failure | Errore di validazione TLS generico |
tlsa-invalid | Il record DANE TLSA non è valido o non corrisponde |
dnssec-invalid | La catena DNSSEC necessaria a DANE è interrotta o assente |
dane-required | DANE è richiesto ma non ha potuto essere validato |
sts-policy-fetch-error | Impossibile recuperare la policy MTA-STS (HTTPS o DNS) |
sts-policy-invalid | La policy MTA-STS non ha potuto essere validata |
sts-webpki-invalid | L'host della policy MTA-STS ha un certificato Web PKI non valido |
TLS-RPT vs DMARC
| TLS-RPT | DMARC | |
|---|---|---|
| Protegge | Crittografia del trasporto (SMTP TLS) | Autenticazione del mittente (SPF/DKIM) |
| Segnala | Errori di connessione TLS, errori di certificato | Errori di allineamento dell'autenticazione |
| RFC | RFC 8460 | RFC 7489 |
| Record DNS | _smtp._tls TXT | _dmarc TXT |
| Minacce rilevate | Certificati scaduti, rimozione STARTTLS, errori DANE/MTA-STS | Spoofing, phishing, impersonificazione del dominio |
I due protocolli sono complementari. Implementa il monitoraggio DMARC insieme a TLS-RPT per una visibilità completa sulla sicurezza email.
Chi invia report TLS-RPT?
I report provengono da mittenti che supportano TLS-RPT e tentano di consegnare posta al tuo dominio. Disponibilità e frequenza dipendono dal traffico e dall'implementazione di ogni mittente. Pubblicare il TXT non garantisce report da un determinato provider.
Casi d'uso concreti
La maggior parte degli incidenti TLS si risolve in un'ora quando li vedi, e si trascina per settimane quando non li vedi. Ecco due guasti reali che il monitoraggio TLS-RPT ha portato alla luce.
Incidente 1: Certificato scaduto non rilevato
Sintomo: Google e Microsoft segnalano errori certificate-expired. I tuoi utenti non ricevono più email da questi provider. Nessun errore visibile dal loro lato.
Diagnosi: La dashboard CaptainDNS mostra un picco di errori nelle ultime 24 ore. Tutti puntano a un certificato Let's Encrypt scaduto sull'MX principale. I mittenti rigidi hanno rifiutato i messaggi in silenzio.
Azione: Rinnova il certificato TLS sul server di posta. I report successivi confermano la ripresa delle connessioni cifrate.
Incidente 2: Policy MTA-STS non sincronizzata
Sintomo: I report segnalano errori sts-policy-invalid. La policy MTA-STS è pubblicata. Le email vengono comunque rifiutate.
Diagnosi: La policy MTA-STS fa riferimento a un server MX rimosso durante una migrazione. I mittenti in modalità enforce rifiutano la connessione. L'email non arriva mai. Nessun bounce raggiunge il mittente.
Azione: Aggiorna la policy MTA-STS con gli MX attuali. Incrementa l'id di versione. I report successivi validano la correzione.
CaptainDNS analizza i report ricevuti senza server da gestire né JSON da decodificare. L'invio dipende dai mittenti e dal traffico verso il tuo dominio.
FAQ - Domande frequenti
D: Cos'è un record TLS-RPT?
R: Un record TLS-RPT è un record DNS TXT posizionato su _smtp._tls.tuodominio.com. Contiene una direttiva rua= che indica ai server mittenti dove inviare i report sugli errori TLS (RFC 8460).
D: Il monitoraggio TLS-RPT di CaptainDNS è gratuito?
R: Il primo strumento del tuo account è gratuito. Ogni dominio TLS-RPT conta come uno strumento: successivamente, 3 €/mese IVA esclusa. Nessun costo nascosto, nessun periodo di prova.
D: Come configuro il mio dominio per inviare i report qui?
R: Apri la configurazione del monitor per pubblicare il TXT _smtp._tls consigliato con la destinazione mailto. Controlla i destinatari mantenuti prima di sostituire un TXT esistente. Se la lettura DNS fallisce, aggiungi solo il frammento a rua= senza rimuovere altri destinatari, oppure riprova per ottenere il valore completo.
D: Quali formati di report sono supportati?
R: Accettiamo report TLS-RPT JSON definiti dalla RFC 8460, con o senza compressione gzip, tramite email e HTTPS POST. L'email è la destinazione consigliata; HTTPS resta supportato.
D: Come funziona la verifica del dominio?
R: Aggiungi il TXT di verifica di CaptainDNS per dimostrare la proprietà del dominio. La verifica del dominio e l'attivazione non confermano la ricezione dei report.
D: Ho bisogno di MTA-STS per utilizzare TLS-RPT?
R: No, TLS-RPT funziona in modo indipendente. Tuttavia, combinare MTA-STS con TLS-RPT è consigliato: MTA-STS impone la crittografia, TLS-RPT ti informa quando i mittenti non riescono a rispettarla.
D: Quali rischi si corrono senza TLS-RPT?
R: Senza TLS-RPT, gli errori TLS restano invisibili. Un certificato scaduto può bloccare le email dai principali provider per giorni. Una policy MTA-STS obsoleta porta i mittenti a rifiutare silenziosamente la connessione. L'unico modo per accorgersene è quando un utente segnala il problema, spesso troppo tardi.
D: Con quale frequenza arrivano i report?
R: I mittenti che supportano TLS-RPT inviano generalmente report per periodi di 24 ore. La ricezione dipende da questi mittenti e dal traffico. Non è garantito un tempo di arrivo del primo report; i report ricevuti vengono poi analizzati nella dashboard.
D: Quali tipi di errore TLS segnala TLS-RPT?
R: TLS-RPT copre gli 11 tipi di errore definiti nell'RFC 8460: starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, tlsa-invalid, dnssec-invalid, dane-required, sts-policy-fetch-error, sts-policy-invalid e sts-webpki-invalid. Ogni tipo indica un problema specifico nella catena di negoziazione TLS o di validazione della policy.
D: Qual è la differenza tra TLS-RPT e DMARC?
R: TLS-RPT e DMARC proteggono livelli diversi. DMARC (RFC 7489) verifica l'autenticazione del mittente tramite allineamento SPF e DKIM e combatte lo spoofing e il phishing. TLS-RPT (RFC 8460) monitora la crittografia del trasporto e segnala quando le connessioni SMTP TLS falliscono, i certificati scadono o STARTTLS viene degradato. Entrambi sono essenziali.
Strumenti complementari
| Strumento | Utilità |
|---|---|
| Verifica della sintassi TLS-RPT | Validare la sintassi di un record TLS-RPT |
| Verifica del record TLS-RPT | Verificare il record TLS-RPT DNS del tuo dominio |
| Generatore TLS-RPT | Generare un record DNS TLS-RPT |
| Lettore di report TLS-RPT | Analizzare manualmente un report JSON TLS-RPT |
| Hosting MTA-STS | Ospitare la tua policy MTA-STS (primo strumento gratuito, poi 3 €/mese IVA esclusa) |
| Monitoraggio DMARC | Monitorare e analizzare i report aggregati DMARC |
Risorse utili
- RFC 8460 - SMTP TLS Reporting: Specifica ufficiale TLS-RPT
- RFC 8461 - MTA-STS: Standard complementare per imporre la crittografia SMTP
- Google: Configurare i report TLS: Guida Google Workspace per TLS-RPT