Qual è la differenza tra validator e record check TLS-RPT?

Il validator analizza una sintassi che Lei incolla, prima della pubblicazione DNS, senza alcuna richiesta di rete. Il record check interroga il DNS dal vivo per ispezionare il record pubblicato su _smtp._tls.dominio. Usi il validator a monte, il record check a valle.

Perché validare la sintassi TLS-RPT offline?

Un record non valido viene silenziosamente ignorato dai server mittenti: Lei non riceve alcun report e lo scopre solo quando si verifica un incidente. La validazione offline rileva i problemi prima che impattino la Sua visibilità sui fallimenti TLS.

Quali sono gli errori di sintassi TLS-RPT più comuni?

Errori tipici: versione assente o errata (TLSRPT1 invece di TLSRPTv1), tag rua assente, schema mailto: o https: dimenticato davanti all'endpoint, indirizzo email mal formato e autorizzazione cross-domain mancante per endpoint esterni.

Il validator verifica la cross-domain authorization?

Sì, se Lei compila il campo dominio (modo record_and_domain). Il validator analizza allora ogni endpoint esterno (mailto o https che punta a un altro dominio) e verifica che esista un record TLSRPT di autorizzazione lato destinatario.

Qual è la differenza tra endpoint mailto e https?

Gli endpoint mailto ricevono i report come allegati email (JSON compresso gzip). Gli endpoint https ricevono i report tramite HTTP POST su un webhook. mailto è più semplice da implementare, https consente elaborazione automatizzata.

Come correggo un errore 'versione non valida'?

La versione deve essere esattamente v=TLSRPTv1 (case-sensitive), all'inizio del record. Verifichi la capitalizzazione, gli spazi e l'assenza di caratteri spuri. v=TLSRPT1 e v=tlsrptv1 vengono rifiutati.

Devo anche implementare MTA-STS insieme a TLS-RPT?

Sì, fortemente raccomandato. MTA-STS applica la crittografia TLS, TLS-RPT La informa quando l'applicazione fallisce. Senza TLS-RPT, non saprà se server esterni non riescono a connettersi in TLS al Suo dominio.

Come validare la sintassi TLS-RPT per Microsoft 365 e Google Workspace?

Incolli il Suo record TLS-RPT nel validator. La sintassi è identica indipendentemente dal fornitore. Per Microsoft 365 o Google Workspace, il record deve essere pubblicato su _smtp._tls.captaindns.com una volta validato. Lo combini con MTA-STS per forzare la crittografia.

TLS-RPT Validator gratis - Sintassi offline

Perché usare un validatore offline

Un validatore di sintassi TLS-RPT analizza il Suo record senza pubblicare né interrogare il DNS. Questo approccio offline copre tre casi d'uso chiave che l'audit dal vivo non può gestire.

Casi d'uso tipici:

Prima del deployment → validi una bozza prima della pubblicazione DNS, per evitare un record silenziosamente ignorato dagli MTA.
Validazione di una bozza → verifichi la sintassi di un record copiato da un generatore, una wiki interna o un template condiviso.
Debug offline → riproduca e corregga un errore senza toccare il DNS pubblico, ad esempio in ambiente isolato o pre-produzione.
Revisione di configurazione → esamini un record ricevuto da un partner o esportato da uno strumento di terze parti prima di applicarlo.

Il validatore applica la specifica RFC 8460: versione TLSRPTv1, tag rua, formato degli endpoint mailto: e https:, cross-domain authorization e assenza di tag sconosciuti. Nessuna richiesta DNS viene effettuata. I Suoi dati restano nel Suo browser.

Come usare questo validatore in 3 passi

Passo 1: incollare il record

Copi il valore del Suo record TLS-RPT nel campo dedicato:

v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Lei può incollare una bozza, un record esistente o l'output di un generatore. Il validatore non effettua alcuna connessione di rete in questo passo.

Passo 2: aggiungere un dominio (opzionale)

Indicare un dominio attiva la verifica di cross-domain authorization. Il validatore passa in modalità record_and_domain e analizza ogni endpoint esterno per verificare che esista un record TLSRPT di autorizzazione lato destinatario.

Senza dominio, viene analizzata solo la sintassi pura (modalità record_only).

Passo 3: analizzare il verdetto

I risultati sono classificati per livello di gravità:

Errore → problema bloccante, il record sarà ignorato o rifiutato dai server mittenti
Avviso → funzionale ma miglioramento raccomandato
Valido → sintassi conforme RFC 8460

Corregga ogni alert prima di pubblicare il record nel DNS pubblico.

Validator o record check: quando usare quale strumento

I due strumenti sono complementari. Non si sostituiscono: intervengono in momenti diversi del ciclo di vita di un record TLS-RPT.

Dimensione	Validator (questo strumento)	Record check
Momento d'uso	prima del deployment	dopo il deployment
Lookup DNS	nessuno	risoluzione `_smtp._tls` dal vivo
Sorgente del record	manuale (incollato)	DNS pubblico
Verifica cross-domain	opzionale (via domain)	sistematica
Rilevamento valore pubblicato	statico	stato reale
Dati inviati al server	nessuno	dominio analizzato

Workflow raccomandato:

Progetti il record → validator per verificare la sintassi
Pubblichi il TXT nel DNS → attenda la propagazione
Record check per confermare lo stato live

Il validatore rileva gli errori di immissione prima della pubblicazione. Il record check rileva le deviazioni e conferma che il record servito dal DNS corrisponde al progetto previsto.

Modalità di validazione

Il validatore supporta due modalità a seconda dei campi compilati.

Modalità record_only

Lei incolla solo il record TLS-RPT. Validazione pura di sintassi:

versione TLSRPTv1 esatta, in prima posizione
presenza del tag rua=
formato degli endpoint (mailto: o https:)
indirizzi email ben formati negli endpoint mailto:
tag sconosciuti segnalati come avvisi

Nessuna richiesta di rete. Ideale per validare una bozza prima della pubblicazione.

Modalità record_and_domain

Lei incolla il record e un dominio. Oltre alla validazione di sintassi, il validatore esegue una verifica di cross-domain authorization per gli endpoint esterni:

rileva ogni endpoint il cui dominio differisce dal dominio analizzato
cerca il record TLSRPT di autorizzazione lato destinatario
segnala gli endpoint esterni privi di autorizzazione

Questa modalità aiuta a rilevare configurazioni in cui Lei punta verso un fornitore terzo (analisi gestita di report) senza che questi abbia pubblicato l'autorizzazione lato server.

Regole di sintassi verificate

Il validatore applica le regole della RFC 8460 §3 sul record TXT in _smtp._tls.dominio:

Campo	Regola
v	deve essere esattamente `TLSRPTv1` (case-sensitive), in prima posizione
rua	obbligatorio, contiene uno o più endpoint separati da `,`
Formato globale	coppie `chiave=valore` separate da `;`
Tag sconosciuti	tollerati ma segnalati come avvisi
Spazi	tollerati attorno al `;` e dopo `=`

Esempio valido:

v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Formati di endpoint rua

Ogni endpoint in rua= deve usare uno schema riconosciuto:

Schema	Formato	Utilizzo
`mailto:`	`mailto:indirizzo@dominio`	report ricevuti come allegati email
`https:`	`https://host/percorso`	report inviati a un webhook

Più endpoint sono possibili, separati da ,:

v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com,https://api.captaindns.com/tlsrpt

Ogni endpoint riceve gli stessi report aggregati (uno ogni 24 ore per mittente).

Endpoint rua: mailto vs https

La scelta tra mailto: e https: impatta la complessità del deployment e l'elaborazione dei report.

Endpoint mailto

rua=mailto:tls-reports@captaindns.com

Caratteristiche:

report ricevuti come allegati email (JSON compresso gzip)
configurazione semplice, nessuno sviluppo richiesto
spesso un indirizzo dedicato (tlsrpt@, reports@)
nessuna cross-domain authorization richiesta se l'email è sullo stesso dominio del record

Endpoint https

rua=https://tlsrpt.captaindns.com/v1/report

Caratteristiche:

report inviati tramite HTTP POST a un webhook
consente elaborazione automatizzata in tempo reale
richiede un endpoint HTTPS valido (certificato riconosciuto)
nessuna cross-domain authorization richiesta se l'host è sullo stesso dominio del record

Cross-domain authorization

Quando un endpoint punta a un dominio diverso da quello analizzato (ad esempio un raccoglitore di report di terze parti), la RFC 8460 §3.3 impone un'autorizzazione lato destinatario:

il destinatario pubblica un record TLSRPT su [dominio-sorgente]._report._tls.[dominio-destinatario]
senza questa autorizzazione, i server mittenti non invieranno i report

Il validatore segnala gli endpoint esterni privi di questa autorizzazione, a condizione che Lei abbia compilato il campo dominio.

Esempi non validi

- rua=tls-reports@captaindns.com
+ rua=mailto:tls-reports@captaindns.com

- rua=mailto:tlsrpt
+ rua=mailto:tls-reports@captaindns.com

- rua=http://tlsrpt.captaindns.com/report
+ rua=https://tlsrpt.captaindns.com/report

Errori di sintassi comuni e correzioni

Versione assente o errata

Causa: tag v= mancante o valore diverso da TLSRPTv1.

Correzione:

- rua=mailto:tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

- v=TLSRPT1; rua=mailto:tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Tag rua mancante

Causa: il record contiene v=TLSRPTv1 senza alcun endpoint rua.

Correzione: aggiunga almeno un endpoint:

- v=TLSRPTv1
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Endpoint mailto non valido

Causa: schema mailto: dimenticato, indirizzo email mal formato o troncato.

Correzione:

- v=TLSRPTv1; rua=tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

- v=TLSRPTv1; rua=mailto:tlsrpt@
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Endpoint https non valido

Causa: schema http: invece di https: o URL incompleto.

Correzione: solo gli endpoint HTTPS sono accettati dalla RFC 8460.

- v=TLSRPTv1; rua=http://tlsrpt.captaindns.com/report
+ v=TLSRPTv1; rua=https://tlsrpt.captaindns.com/report

Cross-domain non autorizzato

Causa: un endpoint esterno (dominio diverso da quello analizzato) punta verso un destinatario che non ha pubblicato un record TLSRPT di autorizzazione.

Correzione: chieda al fornitore terzo di pubblicare il record di autorizzazione, oppure usi un endpoint sul Suo dominio:

- rua=mailto:tls-reports@uriports.com
+ rua=mailto:tls-reports@captaindns.com

Tag sconosciuto

Causa: presenza di un tag non definito dalla RFC 8460 (ad esempio ruf=, che non esiste per TLS-RPT a differenza di DMARC).

Correzione: rimuova il tag sconosciuto:

- v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com; ruf=mailto:forensic@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

TLS-RPT e MTA-STS: deployment combinato

TLS-RPT dà il meglio con MTA-STS. I due protocolli formano un duo inseparabile per la sicurezza del trasporto SMTP.

Protocollo	Ruolo
MTA-STS	applica la crittografia TLS per la posta in arrivo
TLS-RPT	riporta i fallimenti e le anomalie di connessione TLS

Perché distribuirli insieme:

MTA-STS senza TLS-RPT → Lei applica TLS ma non sa se alcuni server falliscono silenziosamente
TLS-RPT senza MTA-STS → Lei riceve report utili ma senza rinforzo della crittografia
MTA-STS + TLS-RPT → Lei applica E misura, con visibilità completa

Deployment raccomandato:

Validi la Sua policy MTA-STS con il MTA-STS Syntax Checker
Validi il Suo record TLS-RPT con questo validator
Pubblichi TLS-RPT per primo (per raccogliere report fin dalla fase testing di MTA-STS)
Pubblichi MTA-STS in mode: testing
Monitori i report TLS-RPT per 2-4 settimane
Passi MTA-STS a mode: enforce una volta risolti i problemi

Strumenti complementari e risorse

Strumento	Quando usarlo
TLS-RPT record check	audit live del record pubblicato nel DNS
Monitoraggio TLS-RPT	ricevere e analizzare automaticamente i Suoi report TLS-RPT
TLS-RPT generator	creare un record TLS-RPT conforme RFC 8460
MTA-STS syntax checker	validare la policy MTA-STS associata offline
DMARC record check	completare la sicurezza dell'autenticazione email
Propagazione DNS	confermare la propagazione dopo la pubblicazione

Guide correlate

TLS-RPT: la guida completa per monitorare la crittografia TLS delle Sue email - comprendere il protocollo e la sua integrazione con MTA-STS.
Distribuire TLS-RPT su Microsoft 365, Google Workspace e OVHcloud - procedura passo passo per fornitore.
Analizzare i report TLS-RPT: guida pratica - leggere e sfruttare i report ricevuti.

Specifiche

RFC 8460 - SMTP TLS Reporting (specifica ufficiale)
RFC 8461 - MTA-STS (protocollo complementare)
Formato del record TLS-RPT (§3)
Cross-domain authorization (§3.3)