TLS-RPT Generator

Come usare questo generatore TLS-RPT

Passo 1: Aggiungi destinazioni di reporting

Indica dove vuoi ricevere i report di fallimento TLS:

Email (consigliata per iniziare)

mailto:tlsrpt@captaindns.com

Webhook HTTPS (per automazione)

https://tlsrpt.captaindns.com/v1/report

Puoi aggiungere più destinazioni: i report vengono inviati a tutte.

Passo 2: Copia il record generato

Il generatore crea un record RFC 8460 valido:

v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Passo 3: Pubblica nel DNS

Crea un record TXT a _smtp._tls.captaindns.com con il valore generato.

Esempio per captaindns.com:

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

Passo 4: Verifica la pubblicazione

Usa il nostro TLS-RPT Checker per confermare che la configurazione sia corretta.

Cosa segnala davvero TLS-RPT

TLS-RPT è uno strumento di pura osservabilità: non modifica mai il comportamento di un server, ma rivela ciò che è realmente accaduto durante le connessioni TLS in entrata verso i tuoi MX.

Gli operatori mittenti ti segnalano in particolare:

• un downgrade o uno stripping di STARTTLS, in cui la sessione ricade in chiaro
• un certificato scaduto, non attendibile o autofirmato
• un certificato il cui hostname non corrisponde all'MX previsto
• il fallimento nel recupero o nella validazione di una policy MTA-STS
• un errore DANE: record TLSA non valido o catena DNSSEC interrotta

TLS-RPT non applica alcuna regola. Il rifiuto di consegnare un messaggio in chiaro proviene da MTA-STS o da DANE; TLS-RPT si limita a dirti quando e perché la crittografia è fallita, così puoi correggere prima di passare in enforce.

Formato del record TLS-RPT

Componenti richiesti

Schemi di URI supportati

mailto: - Consegna email

rua=mailto:team-sicurezza@captaindns.com

I report arrivano come allegati JSON compressi.

https: - Consegna webhook

rua=https://api.captaindns.com/tlsrpt/ingest

I report vengono inviati via HTTP POST come JSON, con l'header Content-Type: application/tlsrpt+gzip

Destinazioni multiple

Separa con virgole:

v=TLSRPTv1; rua=mailto:reports@captaindns.com,https://tlsrpt.captaindns.com/report

Inviare i report verso un dominio terzo

Una rua che punta a un dominio diverso dal tuo funziona così com'è, senza alcun record di autorizzazione lato destinatario.

È una differenza importante rispetto a DMARC. DMARC richiede un record _report._dmarc presso il dominio terzo prima di accettare report cross-domain. L'RFC 8460 ha deliberatamente scartato questo meccanismo (sezione 7): il rischio di amplificazione con TLS-RPT è più basso che con DMARC, e la fiducia è garantita in altro modo. I report mailto: sono firmati in DKIM dall'operatore mittente, e i report https: si basano sul possesso del DNS e del certificato dell'endpoint.

v=TLSRPTv1; rua=mailto:reports@tlsrpt-service.com

Nessuna azione è richiesta su tlsrpt-service.com perché questa rua sia valida.

Per semplicità, un indirizzo sul tuo dominio basta nella maggior parte dei casi:

v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Esempi per provider DNS

Cloudflare

1. Vai alle impostazioni DNS del tuo dominio
2. Aggiungi un record:
   • Tipo: TXT
   • Nome: _smtp._tls
   • Contenuto: il valore del record generato
   • TTL: Auto

AWS Route 53

1. Apri la zona ospitata per il tuo dominio
2. Crea un record:
   • Nome record: _smtp._tls
   • Tipo record: TXT
   • Valore: "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"
   • TTL: 3600

Aruba / OVH

1. Vai alla zona DNS
2. Aggiungi una voce:
   • Sottodominio: _smtp._tls
   • Tipo: TXT
   • Destinazione: il valore del record generato
   • TTL: 3600

Capire i report TLS-RPT

Un report TLS-RPT è un documento JSON aggregato, compresso in gzip, che riassume le sessioni TLS di un operatore verso il tuo dominio nell'arco di una giornata.

Anatomia di un report

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2024-01-15T00:00:00Z",
    "end-datetime": "2024-01-16T00:00:00Z"
  },
  "contact-info": "postmaster@google.com",
  "report-id": "2024011512345",
  "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": 8432,
      "total-failure-session-count": 3
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "198.51.100.1",
      "receiving-mx-hostname": "mail.captaindns.com",
      "failed-session-count": 3
    }]
  }]
}

I tipi di errore (result-type)

Il registro IANA definisce 11 valori possibili per result-type:

I tipi di policy (policy-type)

Ogni sessione è collegata a uno dei 3 policy-type:

Trasporto e cadenza

Tutti i report sono compressi in gzip. Esistono due canali di consegna, a seconda dello schema della tua rua:

• HTTPS: il report viene inviato via POST con l'header Content-Type: application/tlsrpt+gzip (o application/tlsrpt+json). L'endpoint conferma la ricezione con uno stato 2xx.
• Email: il messaggio è un multipart/report; report-type="tlsrpt" con un allegato application/tlsrpt+gzip. Porta gli header TLS-Report-Domain e TLS-Report-Submitter, un oggetto della forma Report Domain: captaindns.com Submitter: google.com Report-ID: 2024011512345, ed è firmato in DKIM con il selettore s=tlsrpt.

Cadenza: ogni operatore mittente invia un report aggregato al giorno, che copre la finestra dalle 00:00 alle 24:00 UTC. In caso di errore di consegna, riprova fino a 24 ore.

Chi invia i report

I grandi operatori emettono report TLS-RPT: Google, Microsoft e Yahoo lo fanno sistematicamente; anche Apple e Comcast risultano tra i mittenti. Ogni operatore produce il proprio report indipendente, quindi puoi riceverne più di uno al giorno, uno per mittente.

TLS-RPT con MTA-STS e DANE

TLS-RPT è l'anello di osservabilità di MTA-STS e di DANE. Questi protocolli applicano la crittografia; TLS-RPT ti mostra l'effetto di questa applicazione, prima e dopo il passaggio in produzione.

Ordine di deployment raccomandato

1. Pubblica TLS-RPT, e MTA-STS in mode: testing
2. Analizza i report per 2-4 settimane
3. Passa MTA-STS in mode: enforce
4. Continua il monitoraggio via TLS-RPT

Passare in enforce senza TLS-RPT equivale ad avanzare alla cieca: se una policy compromette la deliverability, lo scoprirai solo dalle lamentele degli utenti.

Strumenti collegati

• Genera una policy MTA-STS
• Verifica lo stato MTA-STS
• Verifica lo stato TLS-RPT
• Verifica i record DANE TLSA

Buone pratiche ed errori comuni

Buone pratiche

• Punta la rua verso una casella o un endpoint dedicato, capace di assorbire il volume e di analizzare il JSON. Mai una casella umana: i report arrivano ogni giorno, in JSON gzippato, da ogni operatore.
• Usa uno strumento di aggregazione per trasformare questi report in tendenze sfruttabili invece di aprirli uno per uno.

Errori da evitare

• Due record TXT su _smtp._tls rendono la configurazione non valida. Mantieni un solo record con un solo valore.
• Codifica in percent-encoding i caratteri ,, ! e ; quando compaiono in un URI (ad esempio in un mailto: con parametri), altrimenti il parsing del record si rompe.

Casi d'uso concreti

Ogni scenario qui sotto si traduce in un result-type preciso nei tuoi report:

• Un MX di backup mai configurato per TLS: starttls-not-supported. Lo individui prima che un attaccante ne approfitti.
• Il certificato di un partner è scaduto: certificate-expired sulle sessioni interessate.
• Un MX presenta un certificato emesso per l'hostname sbagliato: certificate-host-mismatch.
• Un downgrade attivo di STARTTLS (attacco sulla rete) fa crollare le sessioni cifrate: picco di starttls-not-supported.
• La tua stessa policy MTA-STS è rotta o irraggiungibile: sts-policy-fetch-error o sts-policy-invalid, prima che blocchi posta legittima.
• Un DANE mal configurato: tlsa-invalid (TLSA che non corrisponde più dopo una rotazione di certificato) o dnssec-invalid (catena DNSSEC interrotta).

Strumenti complementari

Risorse utili

• RFC 8460 - SMTP TLS Reporting (specifica ufficiale)
• RFC 8461 - MTA-STS (protocollo complementare)
• Google - Configurare TLS reporting
• Postfix - Documentazione TLS