TLS-RPT: la guida completa per monitorare la sicurezza TLS delle tue email

⚡TL;DR

• TLS-RPT (RFC 8460) ti invia un report giornaliero su ogni errore di crittografia TLS rilevato dai server che ti inviano email
• Senza TLS-RPT, non sai se le tue email arrivano in chiaro a causa di un certificato scaduto, di un MX mal configurato o di un attacco downgrade
• Un solo record DNS TXT da pubblicare: _smtp._tls.captaindns.com con la direttiva v=TLSRPTv1; rua=mailto:...
• TLS-RPT è il compagno indispensabile di MTA-STS: ti offre la visibilità necessaria prima di passare alla modalità enforce

Il tuo dominio utilizza MTA-STS o stai pensando di attivarlo? Hai configurato STARTTLS sui tuoi server di posta? In entrambi i casi, una domanda resta senza risposta: come fai a sapere se la crittografia TLS funziona davvero durante la consegna delle tue email?

È esattamente il problema che risolve TLS-RPT. Definito nella RFC 8460, SMTP TLS Reporting è un meccanismo che permette ai server mittenti (Gmail, Microsoft, Yahoo e tutti i provider che lo supportano) di inviarti report dettagliati sugli errori di negoziazione TLS riscontrati nel tentativo di consegnare email al tuo dominio.

Questa guida ti spiega cos'è TLS-RPT, come funziona, come configurarlo in pochi minuti e come interpretare i report che riceverai. Che tu sia amministratore di sistema, DevOps o responsabile dell'infrastruttura email, qui troverai tutto il necessario per implementare TLS-RPT sul tuo dominio.

Cos'è TLS-RPT?

TLS-RPT, acronimo di SMTP TLS Reporting, è uno standard internet (RFC 8460) pubblicato a settembre 2018. Il suo ruolo è semplice: permettere al proprietario di un dominio di ricevere report sui tentativi di connessione TLS falliti quando dei server cercano di consegnargli email.

In pratica, quando Gmail tenta di inviare un'email a contact@captaindns.com, verifica se il server di ricezione supporta TLS e se la negoziazione TLS riesce. Se qualcosa fallisce (certificato scaduto, STARTTLS non supportato, policy MTA-STS non rispettata), Gmail registra l'errore. Una volta al giorno, aggrega tutti gli errori e invia un report JSON all'indirizzo specificato nel tuo record TLS-RPT.

Perché TLS-RPT è indispensabile?

Senza TLS-RPT, sei cieco sulla qualità della crittografia delle tue email in entrata:

• Un certificato TLS scade sul tuo server MX → le email continuano ad arrivare (in chiaro se MTA-STS non è in modalità enforce), ma tu non lo sai
• Un MX secondario non supporta STARTTLS → le email verso quel MX transitano senza crittografia
• Un attacco man-in-the-middle forza un downgrade → impossibile da rilevare senza report

TLS-RPT colma questa lacuna. Ricevi ogni giorno un bilancio preciso: quante connessioni TLS sono riuscite, quante sono fallite e perché sono fallite.

Che differenza c'è tra TLS-RPT e DMARC reporting?

I report DMARC (RUA/RUF) e i report TLS-RPT coprono ambiti diversi:

Criterio	DMARC Reporting	TLS-RPT
Cosa monitora	L'autenticazione delle email (SPF, DKIM, allineamento)	La crittografia del trasporto (TLS)
RFC	RFC 7489	RFC 8460
Record DNS	_dmarc.dominio	_smtp._tls.dominio
Formato del report	XML (aggregato) o testo (forensic)	JSON
Frequenza	Configurabile (spesso 24h)	Sempre 24h
Protocollo	Autenticazione del mittente	Sicurezza del canale di trasporto

I due sono complementari: DMARC verifica chi invia l'email, TLS-RPT verifica come l'email viene trasportata. Un dominio sicuro ha bisogno di entrambi.

Come funziona TLS-RPT?

Il meccanismo TLS-RPT si integra nel flusso normale di consegna email:

1. Pubblicazione del record DNS

Pubblichi un record TXT a _smtp._tls.captaindns.com che contiene l'indirizzo dove ricevere i report.

2. Rilevamento da parte del server mittente

Quando Gmail (o qualsiasi altro server compatibile) vuole inviare un'email al tuo dominio, effettua un lookup DNS su _smtp._tls.captaindns.com per verificare se hai configurato TLS-RPT.

3. Raccolta dei risultati TLS

A ogni tentativo di consegna, il server mittente registra il risultato della negoziazione TLS: successo o errore, con il tipo di errore se necessario.

4. Aggregazione e invio del report

Ogni 24 ore, il server mittente aggrega i risultati e invia un report JSON all'indirizzo rua specificato nel tuo record TLS-RPT.

Chi invia i report?

I principali provider che inviano report TLS-RPT:

Provider	Indirizzo di invio	Supportato
Google / Gmail	noreply-smtp-tls-reporting@google.com	Sì
Microsoft / Outlook	tlsrpt@microsoft.com	Sì
Yahoo / AOL	Variabile	Sì
LinkedIn	Variabile	Sì
Comcast	Variabile	Sì

Se ricevi un'email da noreply-smtp-tls-reporting@google.com, niente panico: è un report TLS-RPT legittimo inviato da Google. Contiene un file JSON compresso (gzip) con il dettaglio dei risultati TLS delle ultime 24 ore.

La sintassi del record TLS-RPT

Il record TLS-RPT è un record DNS TXT pubblicato a _smtp._tls.<dominio>.

Formato base

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"

Tag	Obbligatorio	Descrizione
v	Sì	Versione del protocollo, sempre TLSRPTv1
rua	Sì	URI di destinazione dei report (mailto: o https:)

Esempi di configurazioni valide

Reporting via email (il più comune):

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"

Reporting via endpoint HTTPS:

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=https://report.captaindns.com/tlsrpt"

Reporting multiplo (email + HTTPS):

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com,https://report.captaindns.com/tlsrpt"

Reporting verso un dominio esterno

Quando invii i report verso un dominio diverso dal tuo (ad esempio, un servizio terzo di monitoring), il dominio destinatario deve pubblicare un record di autorizzazione:

captaindns.com._report._tls.monitoring-tiers.com. TXT "v=TLSRPTv1"

Questo meccanismo impedisce a un attaccante di reindirizzare i report verso un dominio non autorizzato. Verifica sempre che il dominio esterno abbia pubblicato questo record di autorizzazione.

Consigli di configurazione

• Casella dedicata: usa un indirizzo email dedicato (es.: tlsrpt@captaindns.com) per non far annegare i report nella tua casella principale
• TTL ragionevole: un TTL da 300 a 3600 secondi è adatto per questo record
• HTTPS per i volumi alti: se ricevi molte email, un endpoint HTTPS è più adatto di una casella email per elaborare i report

Comprendere il report JSON TLS-RPT

I report TLS-RPT vengono inviati in formato JSON, compressi in gzip. Ecco la struttura di un report tipo:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-08T00:00:00Z",
    "end-datetime": "2026-02-09T00:00:00Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-02-08T00:00:00Z_captaindns.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mail.captaindns.com",
          "max_age: 604800"
        ],
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 4523,
        "total-failure-session-count": 2
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "192.0.2.1",
          "receiving-mx-hostname": "mail.captaindns.com",
          "failed-session-count": 2
        }
      ]
    }
  ]
}

Analisi del report

Campo	Significato
organization-name	Chi invia il report (Google, Microsoft, ecc.)
date-range	Periodo coperto (sempre 24h)
policy-type	Tipo di policy applicata: sts (MTA-STS), tlsa (DANE), o no-policy-found
total-successful-session-count	Numero di connessioni TLS riuscite
total-failure-session-count	Numero di connessioni TLS fallite
failure-details	Dettaglio di ogni tipo di errore

I tipi di errori TLS

Ogni errore è categorizzato da un result-type. Ecco i principali:

Codice	Descrizione	Gravità	Azione
starttls-not-supported	Il server MX non supporta STARTTLS	Critica	Attivare STARTTLS sul server
certificate-expired	Il certificato TLS del server è scaduto	Critica	Rinnovare il certificato immediatamente
certificate-host-mismatch	Il certificato non corrisponde all'hostname del MX	Critica	Correggere il certificato o l'hostname
certificate-not-trusted	Certificato non firmato da una CA attendibile	Elevata	Usare un certificato di una CA riconosciuta
validation-failure	Errore di validazione TLS generico	Elevata	Verificare la configurazione TLS completa
sts-policy-fetch-error	Impossibile recuperare la policy MTA-STS	Media	Verificare il file mta-sts.txt
sts-policy-invalid	La policy MTA-STS non è valida	Media	Correggere la sintassi della policy
sts-webpki-invalid	Il certificato HTTPS del server di policy non è valido	Media	Rinnovare il certificato del sottodominio mta-sts
tlsa-invalid	Record TLSA non valido (DANE)	Media	Correggere i record TLSA
dnssec-invalid	Validazione DNSSEC fallita	Elevata	Verificare la configurazione DNSSEC

TLS-RPT e MTA-STS: il duo indispensabile

TLS-RPT acquista tutto il suo valore quando è combinato con MTA-STS. Ecco perché:

Il workflow consigliato

1. Configurare TLS-RPT: pubblica il tuo record _smtp._tls per iniziare a ricevere report
2. Attivare MTA-STS in modalità testing: pubblica la tua policy MTA-STS con mode: testing
3. Analizzare i report: per 1-2 settimane, i report TLS-RPT ti mostrano se ci sono connessioni TLS che falliscono
4. Correggere i problemi: certificati scaduti, MX non coperti, configurazioni TLS errate
5. Passare alla modalità enforce: una volta che i report confermano zero errori, passa MTA-STS a mode: enforce

Senza TLS-RPT, passare alla modalità enforce equivale a navigare alla cieca: rischi di rifiutare email legittime senza saperlo.

TLS-RPT funziona anche con DANE

TLS-RPT non si limita a MTA-STS. Riporta anche gli errori legati ai record DANE TLSA (RFC 7672). Se il tuo dominio utilizza DNSSEC e pubblica record TLSA, i report TLS-RPT includeranno i risultati di validazione DANE con il policy-type: tlsa.

Configurare TLS-RPT in 5 minuti

Passo 1: Scegliere l'indirizzo di reporting

Crea un indirizzo email dedicato per ricevere i report:

• tlsrpt@captaindns.com (consigliato)
• Oppure usa un endpoint HTTPS se hai un sistema di elaborazione automatizzato

Passo 2: Generare il record DNS

Usa il nostro generatore TLS-RPT per creare il record adatto al tuo dominio. Otterrai un record pronto da copiare.

Passo 3: Pubblicare il record DNS

Aggiungi il record TXT nella tua zona DNS:

Campo	Valore
Host	_smtp._tls
Tipo	TXT
Valore	v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com
TTL	3600

Passo 4: Verificare la configurazione

Usa il nostro validatore di sintassi TLS-RPT per verificare che il tuo record sia formattato correttamente.

Passo 5: Attendere i primi report

I report arrivano generalmente 24-48 ore dopo la pubblicazione del record. Google è spesso il primo a inviare report.

Errori comuni e risoluzione dei problemi

Nessun report ricevuto dopo 48 ore

• Verifica che il record sia pubblicato correttamente a _smtp._tls.captaindns.com (non a _smtp-tls o smtp._tls)
• Verifica la sintassi: v=TLSRPTv1 (non v=TLSRPTv2 né v=TLSRPT1)
• Assicurati che la casella email di ricezione esista e accetti allegati gzip
• Verifica che il tuo dominio riceva abbastanza email per generare report

I report arrivano ma sono vuoti

Se total-failure-session-count è sempre a 0, è una buona notizia: la tua configurazione TLS funziona correttamente. I report confermano che tutte le connessioni TLS riescono.

Email da noreply-smtp-tls-reporting@google.com

Queste email sono legittime. Google invia un report TLS-RPT giornaliero per ogni dominio che ha pubblicato un record _smtp._tls. Il file allegato (.json.gz) contiene il report. Non segnalare queste email come spam.

Piano d'azione consigliato

1. Pubblica il tuo record TLS-RPT: 5 minuti con il generatore TLS-RPT (vedi passo 2 qui sopra)
2. Configura MTA-STS in modalità testing: attiva la policy MTA-STS affinché i report TLS-RPT includano i risultati di validazione
3. Analizza i report per 2 settimane: individua gli errori TLS e correggili
4. Passa MTA-STS alla modalità enforce: una volta che i report sono puliti, attiva il rifiuto delle connessioni TLS fallite
5. Monitora costantemente: i report giornalieri ti avvisano di qualsiasi nuovo problema (certificato scaduto, cambio di MX, ecc.)

FAQ

Cos'è TLS-RPT e a cosa serve?

TLS-RPT (SMTP TLS Reporting, RFC 8460) è un meccanismo che permette al proprietario di un dominio di ricevere report giornalieri sugli errori di negoziazione TLS durante la consegna delle email. Ti offre una visibilità completa sulla qualità della crittografia delle tue email in entrata.

Come si configura un record TLS-RPT?

Pubblica un record DNS TXT a _smtp._tls.captaindns.com con il valore v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com. Usa un generatore TLS-RPT per creare il record, poi aggiungilo nella tua zona DNS. I primi report arrivano entro 24-48 ore.

Perché ricevo email da noreply-smtp-tls-reporting@google.com?

Queste email sono report TLS-RPT legittimi inviati da Google. Il tuo dominio ha un record _smtp._tls configurato, e Google ti invia quotidianamente un report JSON compresso con il dettaglio dei risultati di negoziazione TLS per le email che ti ha inviato.

Qual è la differenza tra TLS-RPT e DMARC reporting?

DMARC monitora l'autenticazione delle email (SPF, DKIM, allineamento), mentre TLS-RPT monitora la crittografia del trasporto (TLS). DMARC verifica chi invia l'email, TLS-RPT verifica come viene trasportata. I due sono complementari e consigliati insieme.

TLS-RPT è obbligatorio se uso MTA-STS?

No, TLS-RPT non è tecnicamente obbligatorio per MTA-STS. Ma è fortemente consigliato: senza TLS-RPT, non saprai se ci sono connessioni TLS che falliscono. È particolarmente critico prima di passare MTA-STS alla modalità enforce, perché i report ti permettono di individuare e correggere i problemi a monte.

Con quale frequenza vengono inviati i report TLS-RPT?

I report TLS-RPT vengono inviati una volta al giorno (periodo di 24 ore). Ogni provider compatibile (Google, Microsoft, Yahoo, ecc.) invia il proprio report in modo indipendente. Potresti quindi ricevere più report al giorno, uno per provider.

Come si legge un report TLS-RPT JSON?

Un report TLS-RPT è un file JSON compresso in gzip. Contiene l'organizzazione mittente, il periodo coperto e, per ogni policy TLS (MTA-STS o DANE): il numero di sessioni riuscite, il numero di errori e il dettaglio di ogni tipo di errore (certificato scaduto, STARTTLS non supportato, ecc.).

Si possono usare sia mailto: che https: in TLS-RPT?

Sì, puoi specificare più URI di reporting separati da virgole. Ad esempio: rua=mailto:tlsrpt@captaindns.com,https://report.captaindns.com/tlsrpt. L'endpoint HTTPS è consigliato per i domini con un alto volume di email.

Glossario

• TLS-RPT: SMTP TLS Reporting, meccanismo di report sugli errori TLS definito nella RFC 8460.
• MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461), policy che impone la crittografia TLS per la ricezione delle email.
• DANE: DNS-Based Authentication of Named Entities (RFC 7672), meccanismo alternativo a MTA-STS che utilizza DNSSEC e i record TLSA per validare i certificati TLS.
• STARTTLS: Estensione SMTP che permette di crittografare una connessione inizialmente in chiaro. Opportunistico di default (nessun rifiuto se la crittografia fallisce).
• Downgrade attack: Attacco in cui un intermediario forza la connessione a restare in chiaro sopprimendo il comando STARTTLS dalla risposta del server.
• RUA: Reporting URI for Aggregated reports, l'indirizzo dove vengono inviati i report TLS-RPT.

---

Verifica subito la tua configurazione: Usa il nostro verificatore TLS-RPT per analizzare il record _smtp._tls del tuo dominio in pochi secondi.

---

Guide TLS-RPT correlate

• Configurare TLS-RPT per Microsoft 365, Google Workspace e OVHcloud (in arrivo)
• Analizzare e sfruttare i tuoi report TLS-RPT (in arrivo)

Fonti

• RFC 8460 - SMTP TLS Reporting
• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• Google SMTP TLS Reporting documentation