Analizzare e sfruttare i tuoi report TLS-RPT: individuare i problemi prima che impattino le tue email

Di CaptainDNS
Pubblicato il 14 febbraio 2026

Analizzare un report TLS-RPT: struttura JSON e tipi di errori TLS email

TL;DR

Un report TLS-RPT è un file JSON compresso (gzip) inviato quotidianamente dai server mittenti: descrive ogni errore di negoziazione TLS sul tuo dominio
I 3 errori più frequenti sono certificate-host-mismatch, starttls-not-supported e sts-policy-fetch-error, ciascuno con una causa e una correzione specifica
Analizza il campo failure-details per identificare il server MX coinvolto, l'IP del mittente e il tipo esatto dell'errore
Usa il validatore di sintassi TLS-RPT per verificare la tua configurazione prima e dopo la correzione

Hai configurato TLS-RPT sul tuo dominio e i report cominciano ad arrivare. File JSON compressi, inviati da Google, Microsoft, Yahoo e altri provider. Li apri e trovi blocchi di dati strutturati con campi come policy-type, result-type, failed-session-count. Cosa significano questi dati? Come trasformarli in azioni concrete?

È la parte meno documentata di TLS-RPT. La RFC 8460 definisce il formato, ma non ti dice come interpretare i risultati in un contesto operativo. Questa guida colma questa lacuna: imparerai a leggere la struttura JSON di un report, a identificare ogni tipo di errore e a seguire un workflow di diagnostica per correggere i problemi prima che influenzino la consegna delle tue email.

Se non hai ancora configurato TLS-RPT, inizia dalla guida completa TLS-RPT che copre la configurazione dalla A alla Z (vedi la sezione Guide correlate in fondo all'articolo). Se cerchi la configurazione specifica per il tuo provider (Microsoft 365, Google Workspace, OVHcloud), la guida di configurazione per provider è anch'essa disponibile in fondo all'articolo.

Anatomia di un report TLS-RPT

Un report TLS-RPT è un file JSON inviato come allegato compresso (.json.gz). Ogni provider che ti invia email produce il proprio report, una volta al giorno. Ecco la struttura completa di un report tipico:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-02-12T00: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",
        "mx-host": ["mail.captaindns.com"]
      },
      "summary": {
        "total-successful-session-count": 1842,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "sending-mta-ip": "209.85.220.41",
          "receiving-mx-hostname": "mail.captaindns.com",
          "receiving-ip": "203.0.113.10",
          "failed-session-count": 3
        }
      ]
    }
  ]
}

I 4 blocchi del report

Ogni report contiene esattamente 4 livelli di informazione:

1. Header del report: chi lo invia e quando:

organization-name: il provider mittente (Google, Microsoft, Yahoo)
date-range: il periodo coperto (sempre 24 ore)
report-id: identificativo univoco del report

2. Blocco policy: quale policy TLS è stata valutata:

policy-type: il tipo di policy (sts per MTA-STS, tlsa per DANE, no-policy-found se assente)
policy-string: il contenuto della policy MTA-STS o DANE applicata
policy-domain: il tuo dominio
mx-host: i server MX coinvolti

3. Blocco summary: il bilancio numerico:

total-successful-session-count: connessioni TLS riuscite
total-failure-session-count: connessioni TLS fallite

4. Blocco failure-details: il dettaglio di ogni errore (il più importante):

result-type: il tipo esatto dell'errore
sending-mta-ip: l'IP del server che ha tentato di inviarti l'email
receiving-mx-hostname: il tuo server MX coinvolto
receiving-ip: l'IP del tuo server MX
failed-session-count: numero di errori di questo tipo

Anatomia di un report TLS-RPT: i 4 blocchi di dati JSON (header, policy, bilancio, dettagli degli errori)

Come ricevere e decomprimere i report?

I report arrivano via email da indirizzi come noreply-smtp-tls-reporting@google.com. Il file allegato ha un nome nel formato:

google.com!captaindns.com!2026-02-12T00:00:00Z!2026-02-13T00:00:00Z.json.gz

Per decomprimerlo:

# Linux / macOS
gunzip google.com\!captaindns.com\!2026-02-12T00:00:00Z\!2026-02-13T00:00:00Z.json.gz

# Oppure visualizzare direttamente senza estrarre
zcat rapport.json.gz | python3 -m json.tool

Se ricevi i report via HTTPS (endpoint https://), il server riceve direttamente il JSON compresso in POST con il Content-Type application/tlsrpt+gzip.

I tipi di errori TLS-RPT (result-type)

Il campo result-type in failure-details identifica con precisione cosa è fallito. La RFC 8460 definisce 11 tipi di errori, suddivisi in 3 categorie:

Errori legati al certificato TLS

result-type	Causa	Azione correttiva
`certificate-host-mismatch`	Il certificato TLS del server MX non corrisponde all'hostname	Rinnova il certificato con il CN/SAN corretto per il tuo MX
`certificate-expired`	Il certificato TLS è scaduto	Rinnova immediatamente il certificato
`certificate-not-trusted`	Il certificato non è firmato da una CA riconosciuta	Usa un certificato firmato da una CA pubblica (Let's Encrypt, DigiCert)

Errori legati a STARTTLS

result-type	Causa	Azione correttiva
`starttls-not-supported`	Il server MX non offre STARTTLS	Attiva STARTTLS nella configurazione del tuo server mail
`validation-failure`	Errore generico di validazione TLS	Verifica la catena di certificati completa e la configurazione TLS

Errori legati alle policy MTA-STS e DANE

result-type	Causa	Azione correttiva
`sts-policy-fetch-error`	Impossibile recuperare la policy MTA-STS	Verifica che `https://mta-sts.captaindns.com/.well-known/mta-sts.txt` sia accessibile
`sts-policy-invalid`	La policy MTA-STS è mal formattata	Correggi la sintassi del file `mta-sts.txt`
`sts-webpki-invalid`	Il certificato HTTPS del server MTA-STS è invalido	Rinnova il certificato del sottodominio `mta-sts.captaindns.com`
`tlsa-invalid`	Il record DANE TLSA è invalido	Correggi il record TLSA nella tua zona DNS
`dnssec-invalid`	La validazione DNSSEC è fallita	Correggi la tua catena DNSSEC
`dane-required`	DANE è richiesto ma il server non lo supporta	Distribuisci DANE o rimuovi i record TLSA

I 3 errori più frequenti nel dettaglio

certificate-host-mismatch

È l'errore più comune. Appare quando il certificato TLS presentato dal tuo server MX non contiene l'hostname atteso nel campo CN (Common Name) o SAN (Subject Alternative Name).

Scenario tipico: il tuo MX è mail.captaindns.com ma il certificato è emesso per *.altrodominio.com (hosting condiviso) o per captaindns.com senza il sottodominio mail.

Diagnostica:

# Verificare il certificato del tuo MX
openssl s_client -connect mail.captaindns.com:25 -starttls smtp \
  -servername mail.captaindns.com 2>/dev/null | \
  openssl x509 -noout -subject -ext subjectAltName

Correzione: ottieni un certificato che includa il FQDN esatto del tuo MX nel SAN. Con Let's Encrypt:

certbot certonly --standalone -d mail.captaindns.com

starttls-not-supported

Il server MX non offre il comando STARTTLS nel suo banner SMTP. Le email transitano in chiaro.

Diagnostica:

# Testare se STARTTLS è annunciato
openssl s_client -connect mail.captaindns.com:25 -starttls smtp 2>&1 | head -5
# Se appare "CONNECTED", STARTTLS funziona
# Se errore, STARTTLS non è supportato

Correzione: attiva STARTTLS nel tuo server mail. Per Postfix:

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.captaindns.com/privkey.pem
smtpd_tls_security_level = may

sts-policy-fetch-error

Il server mittente non è riuscito a recuperare la tua policy MTA-STS dall'URL https://mta-sts.captaindns.com/.well-known/mta-sts.txt.

Cause frequenti:

Il sottodominio mta-sts.captaindns.com non ha un record DNS A/AAAA
Il server HTTPS non risponde o restituisce un errore 404/500
Il certificato HTTPS del sottodominio mta-sts è scaduto

Diagnostica:

# Testare l'accesso alla policy
curl -v https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Per una diagnostica completa dei tuoi problemi MTA-STS, consulta la nostra guida al troubleshooting MTA-STS.

Diagnostica passo dopo passo: dall'errore alla correzione

Quando ricevi un report con errori, segui questo workflow in 5 step:

Step 1: Identifica la gravità

Guarda il rapporto errori/successi nel blocco summary:

total-successful-session-count: 1842
total-failure-session-count: 3

Un rapporto inferiore all'1% di errori è normale: potrebbe trattarsi di tentativi da server mal configurati lato mittente. Oltre il 5%, c'è un problema da investigare.

Step 2: Identifica il result-type

Il campo result-type in failure-details ti dice esattamente cosa è fallito. Fai riferimento alla tabella degli 11 tipi qui sopra.

Step 3: Identifica il server MX coinvolto

Il campo receiving-mx-hostname ti indica quale server è impattato. Se hai più MX (primario + backup), solo uno potrebbe essere mal configurato.

Step 4: Verifica con gli strumenti CaptainDNS

Usa il verificatore TLS-RPT di CaptainDNS per confermare che il tuo record DNS è corretto e che le policy associate (MTA-STS, DANE) sono rilevate correttamente.

Step 5: Correggi e monitora

Applica la correzione corrispondente al result-type, poi monitora i report delle 48-72 ore successive per confermare che l'errore è scomparso.

Workflow di diagnostica TLS-RPT: dalla ricezione del report alla correzione dell'errore

Casi pratici: analizzare un report reale

Caso 1: report pulito (nessun errore)

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "report-id": "2026-02-12_captaindns.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 2156,
        "total-failure-session-count": 0
      },
      "failure-details": []
    }
  ]
}

Interpretazione: 2.156 connessioni TLS riuscite, zero errori. La tua configurazione funziona perfettamente. Questo report conferma che:

Il tuo certificato TLS è valido e corrisponde all'hostname MX
STARTTLS è attivo sul tuo server
La tua policy MTA-STS è accessibile e rispettata

Caso 2: errore certificato su un MX secondario

{
  "organization-name": "Microsoft Corporation",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com",
        "mx-host": ["mail.captaindns.com", "mail2.captaindns.com"]
      },
      "summary": {
        "total-successful-session-count": 890,
        "total-failure-session-count": 47
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "sending-mta-ip": "40.107.22.89",
          "receiving-mx-hostname": "mail2.captaindns.com",
          "receiving-ip": "198.51.100.20",
          "failed-session-count": 47
        }
      ]
    }
  ]
}

Interpretazione: 47 errori su mail2.captaindns.com (MX secondario) con un errore certificate-host-mismatch. Il MX primario (mail.captaindns.com) funziona correttamente. Il certificato del MX secondario non contiene mail2.captaindns.com nel suo SAN.

Azione: rinnova il certificato di mail2.captaindns.com includendo questo hostname nel SAN.

Caso 3: policy MTA-STS inaccessibile

{
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 0,
        "total-failure-session-count": 156
      },
      "failure-details": [
        {
          "result-type": "sts-policy-fetch-error",
          "failed-session-count": 156
        }
      ]
    }
  ]
}

Interpretazione: 156 errori, tutti di tipo sts-policy-fetch-error. Il server mittente ha rilevato il tuo record MTA-STS (_mta-sts.captaindns.com) ma non è riuscito a scaricare la policy da https://mta-sts.captaindns.com/.well-known/mta-sts.txt.

Azione: verifica che il sottodominio mta-sts.captaindns.com punti a un server HTTPS funzionante con un certificato valido.

Automatizzare l'analisi dei tuoi report

Volume basso: casella di posta dedicata

Per un dominio che riceve meno di 1.000 email al giorno, un indirizzo dedicato è sufficiente:

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

Crea un filtro nel tuo client email per classificare i report automaticamente. Consultali una volta a settimana cercando total-failure-session-count superiori a zero.

Volume elevato: endpoint HTTPS

Per i domini ad alto traffico, configura un endpoint HTTPS che riceve i report in POST:

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=https://reports.captaindns.com/tls-rpt"

L'endpoint riceve il JSON compresso in gzip con il Content-Type application/tlsrpt+gzip. Puoi fare il parsing dei report automaticamente e attivare alert quando total-failure-session-count supera una soglia.

Verificare la tua configurazione con CaptainDNS

Prima di modificare la tua configurazione TLS o MTA-STS, usa il generatore TLS-RPT per creare un record corretto. Dopo la correzione, verifica con il verificatore TLS-RPT che tutto sia a posto.

Piano d'azione consigliato

Decomprimi e leggi il tuo primo report: apri un file .json.gz ricevuto da Google o Microsoft e identifica i 4 blocchi (header, policy, summary, failure-details)
Verifica il rapporto errori/successi: un tasso di errore superiore al 5% richiede un'indagine
Identifica il result-type: usa la tabella degli 11 tipi di errori per capire la causa esatta
Correggi il problema sul server coinvolto: certificato, STARTTLS o policy MTA-STS a seconda del tipo di errore
Monitora i report successivi: conferma la scomparsa dell'errore nelle 48-72 ore dopo la correzione

FAQ

Cos'è un report TLS-RPT e cosa contiene?

Un report TLS-RPT è un file JSON compresso (gzip) inviato quotidianamente dai server di posta che ti inviano email. Contiene il nome dell'organizzazione mittente, il periodo coperto (24 ore), la policy TLS valutata (MTA-STS o DANE), il numero di connessioni TLS riuscite e fallite, e il dettaglio di ogni tipo di errore con gli IP e gli hostname coinvolti.

Come leggere la struttura JSON di un report TLS-RPT?

Il report JSON comprende 4 livelli: l'header (organization-name, date-range), il blocco policy (policy-type, policy-string), il blocco summary (contatori successi/errori), e il blocco failure-details (result-type, sending-mta-ip, receiving-mx-hostname). Decomprimi il file .json.gz con gunzip o zcat, poi formatta con python3 -m json.tool per una lettura leggibile.

Quali sono i tipi di errori (result-type) in un report TLS-RPT?

La RFC 8460 definisce 11 tipi di errori suddivisi in 3 categorie: errori di certificato (certificate-host-mismatch, certificate-expired, certificate-not-trusted), errori STARTTLS (starttls-not-supported, validation-failure), e errori di policy (sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid, dnssec-invalid, dane-required). Ogni tipo indica con precisione cosa è fallito durante la negoziazione TLS.

Cosa significa certificate-host-mismatch in un report TLS-RPT?

L'errore certificate-host-mismatch significa che il certificato TLS presentato dal tuo server MX non corrisponde all'hostname atteso. Ad esempio, se il tuo MX è mail.captaindns.com ma il certificato è emesso per un altro dominio. Correggilo ottenendo un certificato il cui SAN (Subject Alternative Name) includa il FQDN esatto del tuo MX.

Come correggere un errore starttls-not-supported?

L'errore starttls-not-supported significa che il tuo server MX non annuncia il comando STARTTLS, quindi le email transitano in chiaro. Attiva STARTTLS nella configurazione del tuo server: per Postfix, aggiungi smtpd_tls_security_level = may con i percorsi verso il tuo certificato e la chiave privata in main.cf. Verifica poi con openssl s_client -connect mail.captaindns.com:25 -starttls smtp.

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 che ti invia email (Google, Microsoft, Yahoo, ecc.) produce il proprio report indipendentemente. Puoi quindi ricevere potenzialmente più report al giorno, uno per provider mittente. I primi report arrivano 24-48 ore dopo la pubblicazione del tuo record TLS-RPT.

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

I report DMARC monitorano l'autenticazione delle email (SPF, DKIM, allineamento del dominio), mentre i report TLS-RPT monitorano la crittografia del trasporto (negoziazione TLS tra server). DMARC verifica chi invia l'email, TLS-RPT verifica come viene trasportata. I report DMARC sono in formato XML, i report TLS-RPT in formato JSON. Entrambi sono complementari per la sicurezza del tuo dominio.

Glossario

TLS-RPT: SMTP TLS Reporting (RFC 8460), meccanismo di report quotidiani sugli errori di negoziazione TLS durante la consegna delle email.
result-type: campo JSON in failure-details che identifica il tipo esatto di errore TLS (certificate-host-mismatch, starttls-not-supported, ecc.).
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.
STARTTLS: estensione SMTP che permette di crittografare una connessione inizialmente in chiaro. Opportunistico di default.
SAN: Subject Alternative Name, campo del certificato TLS che elenca gli hostname validi.
policy-type: campo JSON che indica il tipo di policy valutata (sts, tlsa, o no-policy-found).

Verifica la tua configurazione ora: Usa il nostro verificatore TLS-RPT per controllare che il tuo record _smtp._tls sia corretto e che le policy associate siano rilevate correttamente.

Guide TLS-RPT correlate

Fonti

Articoli simili

CaptainDNS · 10 febbraio 2026

TLS-RPT: monitorare gli errori di crittografia TLS nella consegna email

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

TLS-RPT (RFC 8460) ti permette di ricevere report sugli errori di crittografia TLS delle tue email. Scopri come configurarlo, leggere i report e intervenire.

CaptainDNS · 9 febbraio 2026

Risoluzione dei problemi MTA-STS: diagnostica e correzione degli errori comuni

MTA-STS non funziona? Guida completa alla risoluzione dei problemi

La tua policy MTA-STS è inaccessibile, il certificato TLS viene rifiutato o la modalità enforce blocca le email? Questa guida alla risoluzione dei problemi copre gli errori più comuni e le relative soluzioni.

CaptainDNS · 6 febbraio 2026

MTA-STS: proteggere il trasporto email con la crittografia TLS obbligatoria

MTA-STS: la guida completa per proteggere il trasporto delle tue email

MTA-STS (RFC 8461) impone la crittografia TLS per la ricezione delle email. Scopri come configurarlo, scegliere tra testing ed enforce e validare il tuo deployment.