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 sul 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 registra il dominio da monitorare. CaptainDNS genera un collettore di report HTTPS unico e il record DNS TLS-RPT corrispondente.
Passaggio 2: Verifica la proprietà del dominio
Aggiungi il record TXT di verifica al tuo DNS. La validazione è automatica una volta rilevato il record.
Passaggio 3: Pubblica il record TLS-RPT nel tuo dominio
Aggiungi il record TXT _smtp._tls fornito al tuo DNS. I server mittenti inizieranno a inviare report sugli errori TLS al tuo endpoint CaptainDNS.
Cos'è TLS-RPT?
TLS-RPT (SMTP TLS Reporting) è uno standard definito dalla RFC 8460 che fa risalire gli errori di negoziazione TLS al dominio destinatario. I server mittenti segnalano ogni connessione cifrata che fallisce. Un solo record DNS basta a innescarli.
Esempio di record DNS:
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/abc123"
Il record _smtp._tls indica ai mittenti dove inviare i loro report JSON. Qualsiasi errore TLS verso il tuo dominio innesca un report all'URL indicato in rua=.
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 |
Tipi di errore TLS-RPT (RFC 8460)
| Tipo di errore | Descrizione |
|---|---|
starttls-not-supported | Il server destinatario non supporta STARTTLS |
certificate-expired | Il certificato TLS presentato dal MX è scaduto |
certificate-host-mismatch | Il certificato non corrisponde al nome host del MX |
certificate-not-trusted | La catena di certificati non è considerata affidabile dal mittente |
validation-failure | Errore di validazione TLS generico |
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 |
tlsa-invalid | Il record DANE TLSA non è valido o non corrisponde |
dane-required | DANE è richiesto ma non ha potuto essere validato |
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 grandi provider di posta emettono report TLS-RPT non appena tentano una connessione TLS verso il tuo dominio. Da soli, Google e Microsoft instradano la maggior parte della posta in entrata di un dominio aziendale tipico. Ricevi posta da uno di loro? Allora un record TLS-RPT pubblicato ti dà già una copertura utile.
- Google (Gmail, Workspace): Invia report aggregati giornalieri su tutti i tentativi di connessione
- Microsoft (Outlook, Exchange Online): Segnala errori di negoziazione TLS per i tenant Microsoft 365
- Yahoo: Fornisce dati TLS-RPT per l'infrastruttura Yahoo Mail e AOL
- Apple (iCloud Mail): Riporta errori TLS per la consegna iCloud Mail
- Comcast: Uno dei primi ISP a implementare il reporting TLS-RPT
Pubblica un record TLS-RPT e questi provider iniziano a inviare report automaticamente. Non serve alcuna registrazione presso ciascun 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 sul 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 i MX attuali. Incrementa l'id di versione. I report successivi validano la correzione.
In entrambi i casi, l'innesco è lo stesso: un report TLS-RPT letto al momento giusto. Aggiungi il tuo dominio a CaptainDNS, pubblica il record _smtp._tls, e questi segnali arrivano nella tua dashboard senza alcun server da gestire.
FAQ - Domande frequenti
D: Cos'è un record TLS-RPT?
R: Un record TLS-RPT è un record DNS TXT posizionato su _smtp._tls.suodominio.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: Sì, il servizio di monitoraggio TLS-RPT è completamente gratuito. Riteniamo che ogni dominio debba poter monitorare la propria sicurezza TLS senza vincoli tecnici.
D: Come configuro il mio dominio per inviare i report qui?
R: Aggiungi un record TXT a _smtp._tls.tuodominio.com con il valore v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/{tuo-token}. Il record esatto viene fornito quando aggiungi il tuo dominio.
D: Quali formati di report sono supportati?
R: Accettiamo i report TLS-RPT in formato JSON come definito dalla RFC 8460, compressi (gzip) o meno. I report vengono accettati tramite HTTPS POST.
D: Come funziona la verifica del dominio?
R: Aggiungi un record TXT di verifica fornito da CaptainDNS al tuo DNS. Una volta rilevato, la proprietà del dominio viene confermata e il monitoraggio dei report viene attivato.
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 report vengono analizzati e resi disponibili nella tua dashboard entro pochi secondi dalla ricezione. La maggior parte dei provider di posta invia report quotidianamente.
D: Quali tipi di errore TLS segnala TLS-RPT?
R: TLS-RPT copre tutti i tipi di errore definiti nella RFC 8460: starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid e dane-required. 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 gratuitamente la tua policy MTA-STS |
| 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