TLS-RPT Checker

Perché verificare il Suo TLS-RPT

Il trasporto SMTP utilizza TLS in modo opportunistico: se la negoziazione fallisce, la connessione passa a testo in chiaro senza alcun avviso. Le Sue email partono in chiaro e nessuno La avverte. Peggio, un MITM può sopprimere attivamente STARTTLS per forzare questo passaggio.

TLS-RPT (RFC 8460) non corregge la falla di cifratura (lo fa MTA-STS), ma Le dà finalmente visibilità. Ogni MTA mittente che fallisce nello stabilire TLS invia un report JSON all'indirizzo rua che Lei pubblica. Senza questo meccanismo, è cieco.

Verificare la configurazione prima di dimenticarla in un angolo del DNS è essenziale:

• Record assente → non sa nulla dei fallimenti TLS, nessuna tracciabilità
• URI rua invalida → gli MTA non possono consegnare i report, vengono scartati
• Nessuna autorizzazione esterna → se delega a un analizzatore terzo, i suoi server rifiutano i report

Casi d'uso comuni:

• Dopo la pubblicazione → confermare che il record è correttamente propagato
• Audit di sicurezza email → validare la copertura TLS e la visibilità dei fallimenti
• Prima di MTA-STS enforce → assicurarsi che TLS-RPT raccolga i report durante la fase testing

Come usare questo checker in 3 passi

Passo 1: inserisca il dominio da analizzare

Digiti il dominio esattamente come appare nei Suoi indirizzi email:

• captaindns.com (dominio principale)
• marketing.captaindns.com (sottodominio se invia da un sottodominio)

Lo strumento interroga automaticamente _smtp._tls.dominio, recupera il TXT pubblicato e risolve l'autorizzazione esterna se necessario.

Passo 2: analizzi i risultati

Il checker mostra:

Passo 3: corregga i problemi segnalati

I risultati sono classificati per gravità:

• Critico → il record è invalido, nessun report sarà inviato
• Avviso → funziona ma espone a un rischio o copertura parziale
• Info → buona pratica non bloccante (tag sconosciuto, MTA-STS assente)

Corregga il DNS, attenda la propagazione e rilanci il checker.

Cos'è TLS-RPT

TLS-RPT (SMTP TLS Reporting, RFC 8460) è un meccanismo che:

1. Pubblica un indirizzo di report nel DNS per il dominio ricevente
2. Chiede agli MTA mittenti di inviare un report JSON quando TLS fallisce
3. Fornisce una traccia dei fallimenti di cifratura (certificato scaduto, downgrade, mismatch)

L'architettura è volutamente minimalista: un solo record TXT pubblicato su _smtp._tls.dominio, contenente la versione e una o più URI rua=.

Esempio di record TLS-RPT:

_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Questo record indica agli MTA mittenti (Gmail, Outlook, ecc.) di inviare i loro report di fallimento TLS a tls-reports@captaindns.com.

Differenza con MTA-STS: TLS-RPT è il compagno di MTA-STS, non un'alternativa. MTA-STS impone la cifratura TLS, TLS-RPT segnala i fallimenti. I due protocolli vivono in posizioni distinte (_mta-sts.dominio per STS, _smtp._tls.dominio per RPT) e funzionano in tandem.

Cosa verifica il checker

Cinque dimensioni vengono analizzate in parallelo per produrre un punteggio 0-100:

Record DNS pubblicato

Sintassi del record

URI di reporting

Qualità della rua

• Il dominio dell'URI rua coincide con il dominio verificato → nessuna autorizzazione esterna necessaria
• Il dominio è diverso → verificare la presenza di [dominio]._report._tls.[terzo] (autorizzazione cross-domain)
• L'URI https risponde con HTTPS valido (sondaggio leggero lato server)

Hygiene globale

• Presenza simultanea di MTA-STS (bonus +2 al punteggio)
• Nessun tag sconosciuto a inquinare il record
• Policy coerente con il deployment mail del dominio

Diagnosi comuni e soluzioni

Record assente (missing_record)

Causa: nessun TXT esiste su _smtp._tls.captaindns.com.

Soluzione: pubblicare

_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Tag rua mancante (rua_missing)

Causa: il record contiene v=TLSRPTv1 ma nessuna destinazione.

Soluzione: aggiungere almeno una URI: v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com. Senza rua, nessun MTA invierà report.

URI rua invalida (rua_invalid_uri)

Causa: l'URI è mal formata (mailto: mancante, spazio nell'indirizzo, schema sconosciuto).

Esempi di correzione:

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

- rua=mailto: tls-reports@captaindns.com # Spazio dopo mailto: vietato
+ rua=mailto:tls-reports@captaindns.com

Record multipli (multiple_records)

Causa: più di un TXT TLS-RPT esiste su _smtp._tls.captaindns.com.

Soluzione: l'RFC 8460 §3 impone un solo record. Identifichi i duplicati, conservi quello da applicare, rimuova gli altri.

CNAME su _smtp._tls (cname_on_smtp_tls)

Causa: _smtp._tls.dominio è un CNAME che punta altrove.

Soluzione: l'RFC vieta CNAME in questa posizione. Pubblichi un TXT diretto.

Autorizzazione esterna richiesta (rua_unauthorized_external)

Causa: l'indirizzo rua usa un dominio diverso dal dominio TLS-RPT.

Soluzione: il dominio ricevente (per esempio uriports.com) deve pubblicare:

captaindns.com._report._tls.uriports.com. IN TXT "v=TLSRPTv1"

Questo record autorizza la consegna dei report per captaindns.com.

MTA-STS compagno assente (mta_sts_companion_missing)

Causa: TLS-RPT è pubblicato ma MTA-STS no.

Soluzione: distribuire MTA-STS per dare senso ai report TLS-RPT. Veda il MTA-STS Checker e la guida completa.

Autorizzazione cross-domain e rua esterna

L'RFC 8460 riprende la convenzione DMARC (RFC 7489 §7.1): un dominio non può chiedere a un altro dominio di ricevere i suoi report senza il suo consenso esplicito.

Il meccanismo

Il Suo dominio: captaindns.com URI rua: mailto:tls-reports@uriports.com

Il dominio esterno uriports.com deve pubblicare:

captaindns.com._report._tls.uriports.com. IN TXT "v=TLSRPTv1"

Senza questo record, gli MTA mittenti conformi rifiutano di inoltrare i report verso uriports.com (proteggono gli analizzatori terzi contro abusi di redirezione).

Trappole comuni

• Confusione con DMARC: DMARC usa _report._dmarc.[terzo], TLS-RPT usa _report._tls.[terzo]. Verifichi il prefisso corretto.
• Più domini monitorati: un analizzatore multi-tenant (Postmark, Uriports, Dmarcian, Valimail, Sendmarc) deve pubblicare un record per dominio cliente (cliente1.com._report._tls.postmarkapp.com, cliente2.com._report._tls.postmarkapp.com, ecc.).
• Nessun wildcard ammesso: è richiesto un record esplicito per coppia (dominio monitorato, dominio analizzatore).
• Il checker segnala automaticamente le rua esterne senza autorizzazione pubblicata.

TLS-RPT e MTA-STS: deployment combinato

I due protocolli formano una difesa in profondità:

Ordine di deployment raccomandato

1. Pubblicare TLS-RPT per primo per raccogliere i report
2. Distribuire MTA-STS in modalità testing senza bloccare la consegna
3. Osservare da 2 a 4 settimane i report TLS-RPT per identificare gli MX problematici
4. Passare MTA-STS in modalità enforce quando i report sono puliti
5. Mantenere TLS-RPT indefinitamente per la sorveglianza continua

Senza MTA-STS: TLS-RPT segnala i fallimenti ma nessuna policy obbliga gli MTA mittenti a usare TLS. Vede i problemi senza poterli evitare.

Senza TLS-RPT: MTA-STS impone TLS ma non saprà mai che un MTA legittimo è bloccato dalla Sua policy. Rischio di mancata consegna silenziosa.

Strumenti complementari e risorse

Risorse:

• TLS-RPT: la guida completa
• Configurare TLS-RPT su Microsoft 365, Google Workspace e OVHcloud
• Analizzare i report TLS-RPT nel quotidiano
• RFC 8460 - SMTP TLS Reporting
• RFC 8461 - MTA-STS
• RFC 7489 §7.1 - Cross-domain reporting