TLS-RPT Checker

Perché verificare il tuo 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 tue email partono in chiaro e nessuno ti avverte. Peggio, un MITM può rimuovere attivamente STARTTLS per forzare questo passaggio.

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

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

• Record assente → non sai nulla dei fallimenti TLS, nessuna tracciabilità
• URI rua invalida → gli MTA non possono consegnare i report, vengono scartati
• Record multipli → gli MTA mittenti ignorano un TLS-RPT duplicato, nessun report viene inviato

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: inserisci il dominio da analizzare

Digita il dominio esattamente come appare nei tuoi indirizzi email:

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

Lo strumento interroga automaticamente _smtp._tls.dominio e recupera il TXT pubblicato.

Passo 2: analizza i risultati

Il checker mostra:

Passo 3: correggi 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)

Correggi il DNS, attendi la propagazione e rilancia 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 della URI rua coincide con il dominio verificato (destinazione interna)
• Il dominio è diverso (destinazione esterna): valida senza alcuna autorizzazione lato destinatario
• L'URI https risponde con HTTPS valido (verifica leggera lato server)

Igiene globale

• Presenza simultanea di MTA-STS (bonus +2 al punteggio)
• Nessun tag sconosciuto che inquini 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. Identifica i duplicati, conserva quello da applicare, rimuovi gli altri.

CNAME su _smtp._tls (cname_on_smtp_tls)

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

Soluzione: nessun RFC vieta il CNAME in questa posizione. Il checker lo segnala come avviso, non come errore: Microsoft 365 ignora un _smtp._tls con alias. Un TXT diretto resta la configurazione sicura.

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. Vedi il MTA-STS Checker e la guida completa.

Inviare i report verso un dominio terzo

Puoi indirizzare i tuoi report TLS-RPT verso un dominio che non controlli, ad esempio un analizzatore terzo. A differenza di DMARC, l'RFC 8460 non definisce alcun record di autorizzazione lato destinatario: una rua verso un dominio terzo funziona senza pubblicazione aggiuntiva.

Il meccanismo

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

Nessun record è richiesto su uriports.com. Il report viene inviato direttamente. La fiducia si basa su due garanzie previste dall'RFC 8460 §7:

• mailto: il report è firmato in DKIM dall'MTA mittente, il che ne autentica l'origine.
• https: il dominio di destinazione controlla il proprio punto di raccolta (possesso del DNS).

L'RFC 8460 §7 ha deliberatamente scartato ogni meccanismo di verifica aggiuntivo, dato che il rischio di amplificazione è più basso che con DMARC.

Errori comuni

• Non trasporre il meccanismo DMARC: DMARC richiede un record [dominio]._report._dmarc.[terzo] per autorizzare una rua verso un dominio terzo. TLS-RPT non ha un equivalente. Pubblicare un record _report._tls è inutile e non è atteso da alcun MTA.
• Verificare la destinazione: assicurati semplicemente che l'indirizzo mailto o l'URL https di raccolta sia corretto e operativo.

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. Vedi i problemi senza poterli evitare.

Senza TLS-RPT: MTA-STS impone TLS ma non saprai mai che un MTA legittimo è bloccato dalla tua 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