Da testing a enforce: strategia di distribuzione progressiva MTA-STS

Q: Come tornare in modalità testing dopo aver attivato enforce?

Modificate il file di policy per reimpostare mode: testing , poi incrementate l' id nel record DNS TXT. I server di invio che hanno mantenuto in cache la policy enforce continueranno ad applicarla fino alla scadenza del max_age precedente (massimo 7 giorni).

Di CaptainDNS
Pubblicato il 10 marzo 2026

Diagramma di progressione della distribuzione MTA-STS, dalla modalità testing alla modalità enforce

TL;DR

MTA-STS in modalità testing raccoglie i report TLS-RPT senza bloccare la consegna delle email, ideale per rilevare problemi di configurazione
La modalità enforce rifiuta qualsiasi connessione SMTP non cifrata verso i vostri server MX, bloccando gli attacchi di downgrade
La transizione da testing a enforce avviene in quattro passaggi: distribuzione iniziale, configurazione TLS-RPT, analisi dei report (da 1 a 2 settimane), poi attivazione enforce
Ospitate la vostra policy MTA-STS gratuitamente con CaptainDNS: due record DNS bastano

Pubblicare una policy MTA-STS in modalità enforce senza fase di test equivale ad attivare un firewall senza conoscere il traffico legittimo. Risultato possibile: email bloccate, partner che non riescono più a scrivervi e nessuna visibilità sulla causa. Secondo il Google Transparency Report, oltre il 90 % del traffico Gmail in entrata transita già tramite TLS, ma senza MTA-STS nulla garantisce che questa crittografia sia imposta anziché opportunistica.

Il RFC 8461 prevede esattamente questo scenario. Definisce due modalità operative: testing (osservare senza bloccare) ed enforce (bloccare le connessioni non cifrate). La strategia corretta consiste nel distribuire prima in testing, monitorare i report TLS-RPT per una o due settimane, correggere le anomalie, poi passare a enforce.

Questa guida descrive ogni passaggio di questa transizione. Si rivolge ad amministratori di sistema, DevOps e responsabili della sicurezza email che gestiscono uno o più domini di posta.

Comprendere le modalità MTA-STS: testing vs enforce

MTA-STS (RFC 8461) impone la crittografia TLS per le email in entrata tramite una policy HTTPS che contiene tre parametri: i server MX autorizzati, la durata della cache (max_age) e la modalità (testing o enforce).

Modalità testing: monitorare senza bloccare

La modalità testing di MTA-STS consente ai server di invio (Gmail, Outlook, Yahoo) di verificare la vostra policy senza bloccare la consegna in caso di errore TLS. Le anomalie vengono segnalate tramite un report TLS-RPT (RFC 8460) inviato all'indirizzo che avete configurato.

version: STSv1
mode: testing
mx: mx.captaindns.com
max_age: 86400

Questa modalità permette di rilevare tre tipi di problemi prima che influiscano sulla consegna:

Certificato TLS non valido: certificato scaduto, nome di dominio errato o catena di fiducia incompleta
MX non elencato: un server MX risponde alle email ma non compare nella policy
Errore di negoziazione TLS: il server MX non supporta STARTTLS o rifiuta la connessione cifrata

Modalità enforce: imporre la crittografia TLS

La modalità enforce di MTA-STS obbliga i server di invio a rifiutare la consegna se la connessione TLS fallisce o se il server MX non figura nella policy.

version: STSv1
mode: enforce
mx: mx.captaindns.com
max_age: 604800

Questa modalità offre una protezione reale contro gli attacchi di downgrade SMTP. Un attaccante che tenta di rimuovere STARTTLS o di reindirizzare verso un falso server MX non potrà intercettare le email: il server di invio rifiuterà la consegna.

Diagramma di progressione della distribuzione MTA-STS: testing poi enforce

Passaggio 1: distribuire MTA-STS in modalità testing

La distribuzione iniziale richiede due elementi DNS e un file di policy HTTPS.

Record DNS TXT

Pubblicate un record TXT su _mta-sts.captaindns.com:

_mta-sts.captaindns.com.  IN  TXT  "v=STSv1; id=20260310T000000"

Il campo id è un identificativo di versione. Incrementatelo ad ogni modifica della policy affinché i server di invio scarichino la nuova versione.

File di policy HTTPS

Il file deve essere accessibile all'indirizzo https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Con CaptainDNS, due record CNAME bastano: nessun server web da gestire, nessun certificato da rinnovare.

Iniziate con un max_age breve (86 400 secondi = 1 giorno) per poter correggere rapidamente in caso di problema:

version: STSv1
mode: testing
mx: mx.captaindns.com
max_age: 86400

Verifica

Utilizzate il verificatore MTA-STS per confermare che il vostro record DNS e la vostra policy siano pubblicati correttamente.

Passaggio 2: configurare TLS-RPT per ricevere i report

Senza TLS-RPT, la modalità testing è inutile. I server di invio rilevano i problemi ma non hanno dove segnalarli.

Record DNS TLS-RPT

Pubblicate un record TXT su _smtp._tls.captaindns.com:

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

I report TLS-RPT (RFC 8460) vengono inviati quotidianamente in formato JSON. Ogni report contiene:

Il dominio mittente e il dominio destinatario
Il tipo di policy applicata (MTA-STS o DANE)
Il numero di sessioni riuscite e fallite
Il dettaglio degli errori: tipo di errore, certificato presentato, codice di risultato

Configurare con CaptainDNS

Il generatore TLS-RPT crea il record DNS adatto al vostro dominio. Potete indirizzare i report verso un indirizzo email o un endpoint HTTPS.

Passaggio 3: analizzare i report e correggere i problemi

Attendete da 1 a 2 settimane in modalità testing prima di passare a enforce. Questo intervallo permette di raccogliere un numero sufficiente di report TLS-RPT per identificare i problemi ricorrenti.

Interpretare i report

Tipo di errore	Causa probabile	Correzione
`certificate-expired`	Certificato TLS del server MX scaduto	Rinnovare il certificato
`certificate-host-mismatch`	Il CN/SAN del certificato non corrisponde al nome MX	Correggere il certificato o la policy
`starttls-not-supported`	Il server MX non supporta STARTTLS	Attivare STARTTLS sul server
`sts-policy-fetch-error`	La policy HTTPS è inaccessibile	Verificare il DNS CNAME e il server HTTPS
`sts-webpki-invalid`	Il certificato HTTPS della policy non è valido	Rinnovare il certificato del server web
`validation-failure`	Il MX non figura nella policy	Aggiungere il MX mancante alla policy

Criteri per passare a enforce

Prima di attivare la modalità enforce, verificate queste tre condizioni:

Zero errori TLS ricorrenti nei report degli ultimi 7 giorni
Tutti i vostri server MX figurano nella policy
Certificati TLS validi su ogni server MX (non scaduti, CN/SAN corretto)

Se gli errori persistono, correggeteli prima. Un passaggio prematuro a enforce bloccherà le email provenienti dai server che riscontrano questi errori.

Checklist delle verifiche prima del passaggio alla modalità enforce

Passaggio 4: passare alla modalità enforce

La transizione si effettua con due modifiche: il file di policy e il record DNS.

Modificare la policy

Cambiate mode: testing in mode: enforce e aumentate max_age a 604 800 secondi (7 giorni):

version: STSv1
mode: enforce
mx: mx.captaindns.com
max_age: 604800

Un max_age di 7 giorni offre un buon compromesso: abbastanza lungo perché i server di invio mantengano la policy in cache (protezione contro TOFU), abbastanza breve per permettere un ritorno in testing se necessario.

Aggiornare l'identificativo DNS

Incrementate l'id nel record TXT per forzare l'aggiornamento:

_mta-sts.captaindns.com.  IN  TXT  "v=STSv1; id=20260310T120000"

Strategia di rollback

Se si verificano problemi dopo il passaggio a enforce:

Tornate immediatamente a mode: testing
Incrementate l'id DNS
Attendete la scadenza del max_age precedente (massimo 7 giorni)
Analizzate i nuovi report TLS-RPT
Correggete i problemi prima di ritentare il passaggio a enforce

Errori comuni e soluzioni

Errore	Conseguenza	Soluzione
Passare a enforce senza TLS-RPT	Nessuna visibilità sui blocchi	Configurare sempre TLS-RPT prima di enforce
`max_age` troppo lungo in testing	Correzione lenta in caso di problema	Utilizzare 86 400 s (1 giorno) in testing
`max_age` troppo breve in enforce	Protezione TOFU ridotta	Utilizzare 604 800 s (7 giorni) in enforce
Dimenticare un server MX nella policy	Email rifiutate in enforce	Elencare tutti i MX con `dig MX captaindns.com`
Non incrementare l'`id`	I server di invio usano la vecchia policy	Cambiare sempre l'`id` dopo una modifica
Certificato TLS scaduto	Errore di validazione in enforce	Automatizzare il rinnovo (Let's Encrypt)

Piano d'azione raccomandato

Verificate la vostra configurazione attuale: lanciate un'analisi con il verificatore MTA-STS
Distribuite in modalità testing: pubblicate la vostra policy con mode: testing e max_age: 86400
Attivate TLS-RPT: configurate il record _smtp._tls per ricevere i report giornalieri
Monitorate per 1-2 settimane: analizzate ogni report, correggete gli errori TLS
Passate a enforce: cambiate mode: enforce, aumentate max_age a 604 800 s, incrementate l'id

Proteggete il trasporto delle vostre email ora: ospitate la vostra policy MTA-STS gratuitamente con CaptainDNS. Due record DNS, zero server web, protezione attiva in 5 minuti.

FAQ

Qual è la differenza tra la modalità testing e la modalità enforce di MTA-STS?

In modalità testing, i server di invio verificano la vostra policy MTA-STS ma consegnano le email anche se la connessione TLS fallisce. Inviano un report TLS-RPT per segnalare il problema. In modalità enforce, i server rifiutano di consegnare se TLS fallisce o se il server MX non figura nella policy.

Quanto tempo bisogna restare in modalità testing prima di passare a enforce?

Minimo da 1 a 2 settimane. Questo intervallo permette di raccogliere un numero sufficiente di report TLS-RPT dai principali mittenti (Gmail, Outlook, Yahoo). Se i report mostrano zero errori TLS per 7 giorni consecutivi, potete passare a enforce.

Cosa succede se si passa direttamente a enforce senza fase di testing?

Le email provenienti da server che riscontrano un problema TLS con i vostri MX verranno rifiutate. Senza report TLS-RPT preliminari, non avrete alcuna visibilità su questi rifiuti. Partner o clienti potrebbero non riuscire più a inviarvi email senza che lo sappiate.

Quale max_age usare in modalità testing e in modalità enforce?

In testing, utilizzate 86 400 secondi (1 giorno). Questo intervallo breve permette di correggere rapidamente la policy in caso di problema. In enforce, passate a 604 800 secondi (7 giorni) per ridurre la vulnerabilità TOFU: i server di invio mantengono la policy in cache più a lungo.

Come tornare in modalità testing dopo aver attivato enforce?

Modificate il file di policy per reimpostare mode: testing, poi incrementate l'id nel record DNS TXT. I server di invio che hanno mantenuto in cache la policy enforce continueranno ad applicarla fino alla scadenza del max_age precedente (massimo 7 giorni).

TLS-RPT è obbligatorio per MTA-STS?

No, TLS-RPT non è tecnicamente necessario affinché MTA-STS funzioni. Ma senza TLS-RPT, non avete alcuna visibilità sugli errori TLS. In pratica, distribuire MTA-STS senza TLS-RPT equivale a pilotare alla cieca. I due protocolli sono progettati per funzionare insieme.

Gmail e Outlook rispettano la modalità testing di MTA-STS?

Sì. Gmail, Outlook e Yahoo verificano le policy MTA-STS in modalità testing e inviano report TLS-RPT all'indirizzo configurato. In modalità testing, consegnano le email normalmente anche in caso di errore TLS, ma segnalano il problema nel report giornaliero.

Scarica la checklist di deploy

Gli assistenti possono riutilizzare la checklist tramite gli export JSON o CSV qui sotto.

Glossario

MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Policy pubblicata via HTTPS che impone la crittografia TLS per la ricezione di email su un dominio.
TLS-RPT: SMTP TLS Reporting (RFC 8460). Meccanismo di report giornalieri che segnala gli errori di negoziazione TLS tra server email.
TOFU: Trust On First Use. Modello di sicurezza in cui la prima connessione non viene verificata, ma le successive sono validate grazie ai dati mantenuti in cache.
max_age: durata (in secondi) durante la quale un server di invio conserva in cache la policy MTA-STS. Determina la frequenza di aggiornamento.
STARTTLS: estensione SMTP (RFC 3207) che permette di negoziare una connessione TLS dopo l'instaurazione di una connessione in chiaro sulla porta 25.
Downgrade SMTP: attacco di rete che rimuove la negoziazione STARTTLS per intercettare le email in chiaro.

Guide correlate sulla sicurezza del trasporto email

Attacchi di downgrade SMTP: come funzionano e come proteggersi: meccanismo dello STARTTLS stripping e soluzioni di protezione
MTA-STS vs DANE: quale protocollo scegliere per proteggere il trasporto email?: confronto tecnico e guida alla scelta