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

Il validator analizza una sintassi che incolli, prima della pubblicazione DNS, senza leggere la configurazione già attiva. Il record check interroga il DNS dal vivo per ispezionare il record pubblicato su _smtp._tls.dominio. Usa 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: non ricevi alcun report e lo scopri solo quando si verifica un incidente. La validazione offline rileva i problemi prima che compromettano la tua 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'URI, indirizzo email mal formato e tag sconosciuto ereditato da DMARC come ruf= che non esiste per TLS-RPT.

Serve un'autorizzazione per inviare i report verso un altro dominio?

No. A differenza di DMARC, TLS-RPT non richiede alcun record di autorizzazione lato destinatario per una rua esterna: l'RFC 8460 ha scartato questo meccanismo. Una URI che punta a un servizio terzo è quindi valida così com'è, e il validatore non rifiuta mai un record a causa di una rua esterna.

Qual è la differenza tra URI mailto e https?

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

Come correggo un errore 'versione non valida'?

La versione deve essere esattamente v=TLSRPTv1 (case-sensitive), all'inizio del record. Verifica la capitalizzazione, gli spazi e l'assenza di caratteri estranei. 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 ti informa quando l'applicazione fallisce. Senza TLS-RPT, non saprai se server esterni non riescono a connettersi in TLS al tuo dominio.

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

Incolla il tuo 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. Combinalo 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 tuo record senza pubblicare né interrogare il DNS. Questo approccio offline copre quattro casi d'uso chiave che l'audit dal vivo non può gestire.

Casi d'uso tipici:

Prima del deployment → valida una bozza prima della pubblicazione DNS, per evitare un record silenziosamente ignorato dagli MTA.
Validazione di una bozza → verifica la sintassi di un record copiato da un generatore, una wiki interna o un template condiviso.
Debug offline → riproduci e correggi un errore senza dipendere dal DNS pubblico, per esempio su un record di pre-produzione non ancora pubblicato.
Revisione di configurazione → esamina un record ricevuto da un partner o esportato da uno strumento di terze parti prima di applicarlo.

Il validatore applica la specifica RFC 8460 sulla sintassi: versione TLSRPTv1, tag rua, formato delle URI mailto: e https:, e assenza di tag sconosciuti. La validazione gira sui nostri server: il record che incolli viene inviato a CaptainDNS per essere analizzato. Nulla viene però pubblicato, non parte alcuna query DNS e nessuna URI rua viene contattata.

Come usare questo validatore in 2 passi

Passo 1: incollare il record

Copia il valore del tuo record TLS-RPT nel campo dedicato:

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

Puoi incollare una bozza, un record esistente o l'output di un generatore. Il validatore non legge alcuna fonte esterna: analizza soltanto il testo che gli fornisci.

Passo 2: 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

Correggi ogni segnalazione 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.

Criterio	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
Identificazione delle URI esterne	nessuna	automatica
Rilevamento valore pubblicato	statico	stato reale
Dati inviati al server	il record incollato	dominio analizzato

Workflow raccomandato:

Progetta il record → validator per verificare la sintassi
Pubblica il TXT nel DNS → attendi 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 a quanto previsto.

Un solo campo, una sola modalità

Il modulo espone un unico riquadro: il record TLS-RPT stesso. Niente dominio, niente seconda modalità. Ecco cosa viene controllato:

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

Questa sobrietà nasce dall'RFC 8460. DMARC pretende un record di autorizzazione _report._dmarc presso il destinatario non appena i report escono verso un altro dominio; il §7 dell'RFC 8460 ha scartato di proposito quel meccanismo per TLS-RPT. Non c'è quindi nulla con cui confrontare le tue URI rua: un indirizzo presso un fornitore terzo di raccolta dei report va bene così com'è.

Per sapere quali delle tue URI già pubblicate escono dal tuo dominio, ci pensa il record check, che le individua a partire dal dominio interrogato.

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 una o più URI separate 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

Formato delle URI rua

Ogni URI 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ù URI sono possibili, separate da ,:

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

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

URI rua: mailto vs https

La scelta tra mailto: e https: incide sulla complessità del deployment e sull'elaborazione dei report.

URI 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 autorizzazione lato destinatario richiesta, anche per un indirizzo su un dominio diverso da quello del record

URI 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 autorizzazione lato destinatario richiesta, anche per un host su un dominio diverso da quello del record

URI esterne (rua verso un altro dominio)

Quando una URI punta a un dominio diverso da quello analizzato (ad esempio un servizio terzo di raccolta dei report), TLS-RPT non richiede alcuna autorizzazione lato destinatario:

A differenza di DMARC e del suo record _report._dmarc, l'RFC 8460 non definisce alcun meccanismo di verifica: il suo §7 ha deliberatamente scartato ogni autorizzazione cross-domain
Una URI esterna è quindi valida così com'è; i server mittenti inviano i report senza controllo preliminare lato destinatario

Il validatore non le rifiuta mai. Non le distingue nemmeno dalle altre: senza un dominio di riferimento, non ha con cosa confrontarle.

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 alcuna URI rua.

Correzione: aggiungi almeno una URI:

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

URI mailto non valida

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

URI https non valida

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

Correzione: solo le URI HTTPS sono accettate dall'RFC 8460.

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

URI esterna: non è un errore

Da sapere: una URI rua che punta a un altro dominio (servizio terzo di raccolta) è perfettamente valida. A differenza di DMARC, TLS-RPT non impone alcun record di autorizzazione lato destinatario: il validatore non rifiuta mai un record a causa di una rua esterna.

Puoi quindi puntare in tutta tranquillità verso un fornitore terzo:

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

Tag sconosciuto

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

Correzione: rimuovi 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 → applichi TLS ma non sai se alcuni server falliscono silenziosamente
TLS-RPT senza MTA-STS → ricevi report utili ma senza rinforzo della crittografia
MTA-STS + TLS-RPT → applichi E misuri, con visibilità completa

Deployment raccomandato:

Valida la tua policy MTA-STS con il MTA-STS Syntax Checker
Valida il tuo record TLS-RPT con questo validator
Pubblica TLS-RPT per primo (per raccogliere report fin dalla fase testing di MTA-STS)
Pubblica MTA-STS in mode: testing
Monitora i report TLS-RPT per 2-4 settimane
Passa 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 tuoi 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 tue 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)
Considerazioni di sicurezza - rua esterna (§7)