Verifica del record TLS-RPT (rendicontazione TLS per SMTP)

Legge il record TXT _smtp._tls di un dominio e verifica che il recapito a cui inviare le relazioni sugli insuccessi delle connessioni TLS sia configurato correttamente secondo la RFC 8460. Utile nel monitoraggio dopo l'adozione di MTA-STS o DANE.

Ultimo aggiornamento: 2026-09-20

Diagnosticare i rapporti sulle connessioni TLS fallite (TLS-RPT)

Adottare MTA-STS o DANE lascia una cosa fuori dalla vista: se il recapito stia davvero fallendo lo sa soltanto il lato mittente. TLS-RPT è l'assetto che colma quel vuoto. Scrivete un indirizzo di rapporto nel record TXT _smtp._tls e i server mittenti vi invieranno un rapporto quotidiano. Questo strumento preleva quel record e riferisce se la sua forma si conformi alla RFC 8460.

TLS-RPT non è di per sé una difesa, bensì un mezzo di osservazione. Nulla fa per fermare un attacco; si limita a dirvi quante volte l'instaurazione del TLS sia fallita. Senza quell'osservazione, però, non vi è modo di giudicare quando portare MTA-STS a enforce. Se il recapito si fermasse nell'istante in cui l'imposizione comincia, non lo sapreste finché qualcuno non se ne lamentasse. L'ordine consolidato nella pratica consiste dunque nel porre dapprima TLS-RPT, tenere MTA-STS a testing leggendone i rapporti, e passare a enforce soltanto una volta convinti che nulla fallisca.

Come si usa

Inserite il dominio Indicate il solo dominio, nella forma example.com.
Controllate il record TXT Cercate v=TLSRPTv1 e un rua=.
Accertate la forma dell'indirizzo di rapporto Si scrive con mailto: oppure https:. Accertate anche che quell'indirizzo possa davvero ricevere.
Stabilite chi leggerà i rapporti Porlo e non leggerli mai non approda a nulla. Stabilite chi guarda, e quando.

Consigli per sfruttarlo al meglio

TLS-RPT non riguarda chi riceve, ma dichiara il recapito a cui i server mittenti devono inviare le relazioni statistiche sugli insuccessi delle connessioni TLS.
Come recapito si possono indicare sia un indirizzo di posta, con il prefisso mailto:, sia un punto di raccolta web, con il prefisso https:, oppure più recapiti separati da virgola.
Le relazioni arrivano in formato JSON, eventualmente compresso, quindi conviene predisporre uno strumento di analisi o una casella dedicata.
Subito dopo l'adozione di MTA-STS o DANE si raccomanda di verificare con le relazioni TLS-RPT che non ci siano errori di configurazione involontari.
I principali fornitori di posta elettronica inviano le relazioni TLS-RPT, quindi i domini che scrivono spesso ai loro utenti traggono maggiore vantaggio dall'adozione.

Quando torna utile

Prima di portare MTA-STS all'imposizione

Potete misurare se qualcosa stia fallendo finché restate a testing, e ciò fonda la vostra decisione.

Nell'accorgersi per tempo di un guaio di recapito

Venite a sapere che si stanno verificando fallimenti senza attendere che qualcuno ve lo dica.

Nel vigilare dopo aver adottato DANE

Uno scarto fra certificato e record TLSA compare nei rapporti come un fallimento.

Nell'accertare la forma del vostro record

Un errore nella scrittura di rua si manifesta nel non ricevere rapporto alcuno.

Termini di TLS-RPT

_smtp._tls TXT: Il record DNS che reca l'indirizzo di rapporto. Si scrive nella forma v=TLSRPTv1; rua=mailto:....
Rua: Dove i rapporti debbano giungere. Indicate un indirizzo di posta o un punto HTTPS pronto a riceverli.
RFC 8460: La norma che definisce il formato di TLS-RPT e il contenuto di un rapporto.
Rapporto quotidiano: Il rapporto che un server mittente invia a copertura di una giornata. Reca il conto dei successi e dei fallimenti e i motivi di questi ultimi.
MTA-STS: L'assetto che impone il TLS. TLS-RPT vi si accompagna per vedere come quell'imposizione stia effettivamente riuscendo.
DANE: L'assetto che valida i certificati sulla premessa di DNSSEC. Anche i guai da questa parte affiorano nei rapporti di TLS-RPT.

Domande frequenti

MTA-STS è il meccanismo di difesa che impone la connessione TLS, TLS-RPT quello di osservazione che, tramite le relazioni, verifica se quelle connessioni stiano fallendo. Si configurano in modo indipendente ed è possibile adottarne uno soltanto.

La mancata adozione è una condizione comune a moltissimi domini e non comporta di per sé un pericolo immediato. Se però avete adottato MTA-STS o DANE, conviene configurare anche TLS-RPT per individuare eventuali errori di configurazione.

All'indirizzo di posta indicato con il prefisso mailto: nel record TXT oppure al punto di raccolta web indicato con https:. Si possono indicare più recapiti separati da virgola.

Trattandosi di dati strutturati in formato JSON, nella pratica si preferisce elaborarli automaticamente con strumenti di monitoraggio o con script invece di leggerli a occhio. Molti operatori si affidano a servizi di analisi dedicati.

Lo strumento verifica soltanto la sintassi del record TXT e la presenza dei campi obbligatori. Poiché non accerta l'effettivo arrivo delle relazioni, dopo l'adozione conviene attendere qualche giorno e controllare che i messaggi con le relazioni arrivino davvero.

A proposito — la lacuna dei «guasti silenziosi» colmata da TLS-RPT

TLS-RPT, definito nel 2018 dalla RFC 8460, è stato elaborato quasi in contemporanea con MTA-STS. Le due specifiche sono state discusse nello stesso gruppo di lavoro, poggiano entrambe sui record TXT del DNS e sono state promosse insieme dai principali fornitori di posta, ma svolgono ruoli del tutto diversi: MTA-STS è un meccanismo di difesa che impone l'uso di TLS, TLS-RPT è un meccanismo di osservazione che rende visibile che cosa sia realmente accaduto dopo averlo imposto.

Prima di TLS-RPT, quando la negoziazione TLS falliva in una comunicazione SMTP, nella maggior parte dei casi il server mittente si limitava a registrarlo nei propri log e chi amministrava il dominio ricevente non ne sapeva nulla. Un certificato scaduto o un errore nella configurazione della politica MTA-STS restavano invisibili finché i messaggi non smettevano di arrivare: quei «guasti silenziosi» erano un problema operativo rilevante.

Adottando TLS-RPT, al recapito indicato arrivano relazioni aggregate quotidiane in formato JSON, spesso compresse, che riportano come dati strutturati il numero di successi e insuccessi e, per questi ultimi, la causa: certificato non corrispondente, negoziazione TLS fallita e simili. Sono pensate meno per la lettura umana che per l'inserimento in un sistema di monitoraggio capace di rilevare le anomalie.

Nella pratica si configura TLS-RPT insieme a MTA-STS o a DANE. Adottando il solo meccanismo di difesa non si avrebbe modo di accorgersi che un errore di configurazione sta bloccando anche i messaggi legittimi: monitorando le relazioni TLS-RPT si può invece procedere in sicurezza con l'attivazione dell'obbligo di TLS.

Vedi tutte le curiosità