• Che cos’è il TLS Reporting? In che modo i report TLS SMTP individuano gli errori di consegna delle e-mail

Che cos’è il TLS Reporting? In che modo i report TLS SMTP individuano gli errori di consegna delle e-mail

Blog

I report TLS ti avvisano quando la crittografia TLS SMTP non va a buon fine durante l'invio delle e-mail. Scopri come funzionano i report TLS SMTP, cosa contengono e come configurarne uno.

di Ahona Rudra

Ultimo aggiornamento:
6 Tempo di lettura: 6 min
Che cos’è il TLS Reporting? In che modo i report TLS SMTP individuano gli errori di consegna delle e-mail

La maggior parte degli errori SMTP TLS si verifica senza che nessuno se ne accorga. Se un certificato scade, un server smette di supportare STARTTLS o un malintenzionato impone un downgrade, l’e-mail viene inviata in chiaro oppure non arriva affatto, senza alcun avviso che ne spieghi il motivo. La reportistica TLS serve proprio a colmare questa lacuna.

Definito nella RFC 8460, il protocollo SMTP TLS Reporting (TLS-RPT) offre ai proprietari dei domini un metodo standardizzato per individuare quando la crittografia TLS fallisce tra i server di posta e per capirne le cause. Questo articolo illustra il funzionamento del protocollo SMTP TLS, i motivi per cui può fallire, come si presenta un vero e proprio report TLS-RPT campo per campo e i tipi specifici di errore che si possono riscontrare una volta che si inizia a leggerli.

Che cos’è SMTP TLS e perché non funziona?

Per capire perché la segnalazione TLS sia importante, è utile sapere innanzitutto perché SMTP ne avesse bisogno.

Il protocollo SMTP non è stato progettato per supportare la crittografia

L'SMTP risale al 1982. All'epoca, la posta elettronica era una rete ristretta e affidabile, e il protocollo era stato progettato senza un livello di crittografia. Per impostazione predefinita, i messaggi venivano trasmessi tra i server in testo in chiaro.

Quella lacuna è rimasta aperta per decenni. La crittografia è stata aggiunta in un secondo momento, come opzione piuttosto che come requisito, ed è proprio qui che nasce il problema successivo.

STARTTLS ha reso la crittografia facoltativa, non garantita

STARTTLS consente al server mittente di richiedere al server destinatario di trasformare una connessione in chiaro in una connessione crittografata. Se entrambe le parti supportano questa funzionalità, il messaggio viene trasmesso in forma crittografata. Se una delle due parti non la supporta, oppure se qualcosa interferisce con la procedura di handshake, la connessione torna silenziosamente in chiaro e l’e-mail viene comunque inviata.

Proprio questa soluzione di ripiego rappresenta il problema principale che TLS-RPT è stato progettato per mettere in luce. Lo standard SMTP non fornisce alcuna indicazione su quando un messaggio sia stato inviato in chiaro, sia che ciò sia avvenuto a causa di una configurazione errata, sia che qualcuno abbia attivamente rimosso il comando STARTTLS durante il transito.

Che cos’è il TLS Reporting (TLS-RPT)?

TLS-RPT è uno standard di segnalazione, definito nella RFC 8460, che consente ai proprietari di domini di ricevere rapporti periodici e strutturati sugli errori di connessione TLS relativi alle e-mail inviate al proprio dominio. Non impedisce che gli errori si verifichino, ma indica quando si sono verificati, con quale frequenza e per quale motivo, in modo da poter risolvere il problema alla radice.

Per un'analisi completa dei campi del report definiti nella RFC 8460 e per sapere come pubblicare un record DNS TLS-RPT, consulta la nostra guida dettagliata su TLS-RPT.

In che modo TLS-RPT è correlato a MTA-STS

TLS-RPT e MTA-STS funzionano in coppia. MTA-STS è il meccanismo di applicazione: indica ai server mittenti che la posta destinata al tuo dominio deve passare attraverso una connessione crittografata e autenticata, oppure non deve essere inviata affatto. TLS-RPT è il meccanismo di monitoraggio: segnala cosa è successo ogni volta che non è stato possibile stabilire quella connessione crittografata. Uno imposta la regola, l’altro ti avvisa quando la regola viene attivata.

Per le istruzioni dettagliate su come configurare MTA-STS per il tuo dominio, puoi consultare la nostra guida all'implementazione di MTA-STS.

Come funziona la segnalazione SMTP TLS, passo dopo passo

  1. Il proprietario del dominio pubblica un record DNS TLS-RPT, che indica ai server di posta mittenti dove inviare i rapporti di errore.
  2. Un server di invio tenta di consegnare la posta utilizzando il protocollo TLS, in genere tramite STARTTLS.
  3. Se tale tentativo fallisce, il server di invio registra il motivo dell'errore.
  4. Circa una volta ogni 24 ore, il server mittente raggruppa tali risultati in un report JSON e lo invia, solitamente tramite e-mail o POST HTTPS, all'indirizzo indicato nel record TLS-RPT del dominio.
  5. Il proprietario del dominio apre il report e cerca di individuare degli schemi ricorrenti: quali server presentano malfunzionamenti, con quale frequenza e per quale motivo.

All'interno di un vero rapporto TLS-RPT

I report TLS-RPT vengono forniti in formato JSON, che non è esattamente leggibile dall'utente. Di seguito è riportato un esempio sintetico e realistico basato sul formato RFC 8460, con un riepilogo di una sessione riuscita e uno di una sessione fallita, seguito da una spiegazione in parole semplici di ciascun campo.

JSON
{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-07-01T00:00:00Z",
    "end-datetime": "2026-07-01T23:59:59Z"
  },
  "contact-info": "[email protected]",
  "report-id": "[email protected]",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mail.yourdomain.com",
          "max_age: 604800"
        ],
        "policy-domain": "yourdomain.com"
      },
      "summary": {
        "total-successful-session-count": 4821,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "209.85.220.41",
          "receiving-mx-hostname": "mail.yourdomain.com",
          "receiving-mx-helo": "mail.yourdomain.com",
          "receiving-ip": "203.0.113.45",
          "failed-session-count": 2,
          "additional-information": "https://support.google.com/mail/answer/tls-rpt-cert-expired"
        },
        {
          "result-type": "starttls-not-supported",
          "sending-mta-ip": "209.85.220.41",
          "receiving-mx-hostname": "mail2.yourdomain.com",
          "receiving-ip": "203.0.113.46",
          "failed-session-count": 1
        }
      }
    }
  ]
}

Cosa significa effettivamente ogni campo

  • nome-organizzazione: Chi ha inviato la segnalazione. Di solito, un grande provider di posta elettronica come Google, Microsoft o Yahoo.
  • intervallo di date: il periodo di riferimento del report. La maggior parte dei mittenti genera i report su base mobile di 24 ore.
  • informazioni-di-contatto / id-segnalazione: Come contattare il mittente e un ID univoco per questa specifica segnalazione. Utile se è necessario fare riferimento alla segnalazione in un ticket di assistenza.
  • policy-type / policy-string: la politica MTA-STS (o DANE) che il server mittente ha rilevato per il tuo dominio in quel momento, riportata esattamente così come è stata recuperata. Ciò ti consente di verificare che la politica da te pubblicata corrisponda a quella che i mittenti ricevono effettivamente.
  • numero-totale-di-sessioni-riuscite / numero-totale-di-sessioni-fallite: Il dato principale. In questo esempio, su 4.824 tentativi di consegna, 4.821 hanno avuto esito positivo e 3 sono falliti.
  • failure-details: Una voce per ogni tipo di errore, con il relativo numero di occorrenze. Questa è la parte su cui vale la pena intervenire:
    – certificate-expired: Il certificato TLS era scaduto in 2 delle sessioni fallite. Soluzione: rinnovare e reinstallare il certificato.
    – starttls-not-supported: il server di destinazione (mail2.yourdomain.com) non ha risposto affatto a STARTTLS in 1 sessione. Soluzione: verificare la configurazione TLS del server, poiché potrebbe mancare o essere configurata in modo errato.

Tipi comuni di errori TLS che potresti riscontrare nei report

I report TLS-RPT utilizzano una serie fissa di valori relativi ai tipi di risultato. Di seguito sono riportati quelli che ricorrono più spesso, il loro significato e come gestirli.

Certificato scaduto

Il certificato TLS del server di destinazione era scaduto. Rinnova il certificato prima che scada e imposta un promemoria con largo anticipo rispetto alla prossima scadenza.

Discrepanza nel nome del certificato

Il certificato presentato non corrisponde al nome host previsto dal server mittente. Ciò indica solitamente un certificato configurato in modo errato o un record DNS che punta a un host sbagliato.

STARTTLS non supportato

Il server di destinazione non ha risposto affatto al comando STARTTLS. Verifica che TLS sia abilitato correttamente su quel server di posta e assicurati che il software del server lo supporti effettivamente.

Errore nel recupero delle politiche MTA-STS

Il server mittente non è riuscito a recuperare il file della politica MTA-STS tramite HTTPS. Verifica che il file della politica sia raggiungibile, formattato correttamente e servito con un certificato valido.

Versione TLS troppo vecchia

La connessione ha tentato di negoziare una versione TLS che il server mittente considera obsoleta o non sicura. Aggiorna la configurazione TLS del tuo server di posta per disabilitare le versioni obsolete del protocollo. Per quanto riguarda in particolare i problemi di convalida relativi ai certificati, consulta la nostra guida su DANE.

Perché è importante la reportistica SMTP TLS

La reportistica SMTP TLS offre numerosi vantaggi. Di seguito ne elenchiamo alcuni:

Sicurezza: Rilevamento degli attacchi di downgrade

TLS-RPT rileva i casi in cui una connessione è stata dirottata su un canale non crittografato, il che corrisponde esattamente allo schema alla base di un attacco MITM di downgrade. Senza una segnalazione, questo tipo di intercettazione può protrarsi all’infinito senza che nessuno se ne accorga.

Visibilità: Eliminare i punti ciechi

Senza TLS-RPT, non c'è modo affidabile di sapere perché le e-mail inviate al tuo dominio non siano state recapitate, né se siano state consegnate senza crittografia. I report mostrano esattamente dove e perché si è interrotta una connessione TLS, invece di lasciarti alle congetture.

Efficienza: Risoluzione dei problemi più rapida

L'analisi dei log del server per individuare l'origine di un problema di consegna richiede tempo. I report TLS-RPT indicano direttamente il server che ha generato l'errore, il tipo di errore e la frequenza con cui si è verificato, riducendo così i tempi di risoluzione del problema da giorni a minuti.

Conclusioni: come PowerDMARC semplifica la reportistica TLS

I report TLS-RPT vengono forniti come file JSON non elaborati, e leggerli manualmente per più fonti di invio diventa presto noioso. PowerDMARC converte automaticamente questi report in dashboard di facile consultazione, aggregati per tipo di risultato e per fonte di invio, in modo da poter individuare quali sono gli errori e dove si verificano senza dover aprire nemmeno un file JSON.

Aiutiamo i titolari di domini:

  • Analizza automaticamente i dati JSON grezzi trasformandoli in dashboard di facile lettura, senza che sia necessaria alcuna decodifica manuale dei file di report TLS-RPT.
  • Filtra in base a due visualizzazioni del report: per fonte di invio (modalità politica, numero di sessioni, totali di consegna) e per risultato (sessioni riuscite in alto, sessioni fallite in basso).
  • Non è possibile approfondire i dettagli di una sessione non riuscita per visualizzare il nome host, l'indirizzo IP, il numero di errori e il motivo del server di destinazione, in modo che la soluzione risulti evidente a prima vista.
  • Carica file JSON, ZIP o GZ con una cronologia dei caricamenti, in modo da poter consultare i report precedenti in qualsiasi momento.
  • Genera automaticamente e verifica i record CNAME necessari per ricevere i report grazie alla configurazione DNS con un solo clic, oltre a un indirizzo configurabile a cui inviare i report aggregati.
  • Esporta i file JSON grezzi quando hai bisogno del file originale per un ticket o per un’analisi più approfondita, con autorizzazioni dettagliate che consentono di controllare chi, all’interno dell’account, può caricare i report.

Inizia una prova gratuita o prenota una demo per provarlo con i dati del tuo dominio.

Domande frequenti

1. A cosa serve la segnalazione TLS?

I report TLS vengono utilizzati per individuare e diagnosticare i problemi nella consegna delle e-mail crittografate, tra cui certificati scaduti, server configurati in modo errato e attacchi di downgrade, generando report periodici su cosa è andato storto e perché.

2. Il protocollo SMTP TLS è la stessa cosa del TLS-RPT?

Sì. I termini “SMTP TLS reporting” e “TLS-RPT” si riferiscono allo stesso standard RFC 8460. TLS-RPT è la sigla del protocollo.

3. Come posso configurare la segnalazione TLS per il mio dominio?

Per configurarlo sul tuo dominio, ti basta pubblicare un record DNS TLS-RPT specificando dove devono essere inviati i report. Puoi generarne uno con il nostro generatore di record TLS-RPT e verificare che sia attivo con il nostro strumento di verifica TLS-RPT.

4. Cosa succede se non abilito TLS-RPT?

Se non si abilita TLS-RPT, i server di posta continueranno comunque a tentare la crittografia TLS autonomamente, ma non si avrà alcuna visibilità sugli eventuali errori. Attacchi di downgrade, certificati scaduti e server configurati in modo errato potrebbero passare inosservati a tempo indeterminato.

5. TLS-RPT funziona senza MTA-STS?

Sì, TLS-RPT è in grado di segnalare autonomamente gli errori TLS. Tuttavia, la sua utilità è massima se abbinato a MTA-STS, poiché MTA-STS impone la consegna crittografata e TLS-RPT segnala cosa è successo quando tale imposizione è entrata in vigore.

6. Con quale frequenza vengono inviati i rapporti SMTP TLS?

La maggior parte dei provider genera e invia i report all'incirca una volta ogni 24 ore, anche se l'intervallo esatto può variare a seconda del provider.

Ultimi messaggi di Ahona Rudra (vedi tutti)
Ultimo aggiornamento:
I migliori server MCP DMARC del 2026: collega l'intelligenza artificiale ai tuoi dati di autenticazione e-mail...