Verifica della politica MTA-STS

Legge il record TXT _mta-sts di un dominio e il relativo file di politica e verifica che l'imposizione della cifratura TLS nel trasferimento della posta sia configurata correttamente.

Ultimo aggiornamento: 2026-10-18

Diagnosticare il TLS imposto nel recapito della posta (MTA-STS)

La cifratura in SMTP è per sua origine una faccenda facoltativa, tentata dove si può, il che significa che un aggressore interposto il quale sfili l'annuncio di STARTTLS può ricacciare lo scambio nel testo in chiaro. MTA-STS è l'assetto che chiude quella porta, ingiungendo ai server mittenti che la posta destinata al dominio debba passare per TLS. Questo strumento preleva tanto il record TXT _mta-sts quanto il file di politica, e riferisce se la configurazione sia completa.

Ciò che disorienta in questo assetto è che la politica stessa non risiede nel DNS. Quanto il record TXT reca è un id che segna la versione; la sostanza viene servita in HTTPS da https://mta-sts.vostrodominio/.well-known/mta-sts.txt. La fiducia di questo meccanismo poggia dunque sui certificati web e non sul DNS. E il punto in cui ci si arena più spesso è lasciare mode a testing. In quello stato il recapito procede nonostante un fallimento di TLS, e l'imposizione ha effetto soltanto quando il valore è enforce. L'ordine consolidato di adozione consiste nel restare a testing, seguire i rapporti TLS-RPT finché non ci si convinca che nulla si rompe, e passare a enforce soltanto allora.

Come si usa

Inserite il dominio Indicate il solo dominio, nella forma example.com.
Controllate il record TXT Cercate v=STSv1 e un id=. L'id si cambia ogni volta che la politica viene aggiornata.
Leggete il contenuto del file di politica Vi compaiono tre voci: mx, max_age e mode.
Accertate il mode A testing non si impone nulla. È enforce a dare effetto alla politica.

Consigli per sfruttarlo al meglio

MTA-STS è un meccanismo che consultano i server mittenti: adottandolo, chi vi scrive imporrà la cifratura TLS nelle comunicazioni dirette al vostro dominio.
Prima di passare all'imposizione conviene sempre restare qualche settimana o un mese in modalità di prova, verificando che non si producano rifiuti di consegna indesiderati.
La durata di validità della politica si indica di norma fra 604.800 secondi, cioè sette giorni, e 31.557.600, cioè un anno. Un valore troppo breve comporta il costo di recuperare di continuo la politica alla scadenza della cache.
Nell'elenco dei server ammessi si possono usare caratteri jolly, ma i nomi alternativi del certificato TLS devono corrispondere a quella forma.
Configurare soltanto il record DNS oppure soltanto il file di politica non serve a nulla: MTA-STS entra in funzione solo quando sono presenti entrambi.

Quando torna utile

Nell'ispezionare il proprio dominio

Poiché il meccanismo richiede insieme DNS e HTTPS, potete scoprire quale delle due metà manchi.

Nel verificare prima di passare a enforce

Gli errori di configurazione si possono spazzare via finché si resta a testing.

Nel rivedere dopo aver aggiunto un MX

Dimenticare di aggiungere un nuovo host MX all'elenco mx della politica fa rifiutare il recapito verso quell'host.

Nel sapere a che punto sia un corrispondente

Potete vedere se imponga il TLS sulla propria posta.

Termini di MTA-STS

_mta-sts TXT: Il record DNS che reca l'id a segnare la versione della politica. La politica stessa non risiede qui.
File di politica: La sostanza, posta a https://mta-sts.vostrodominio/.well-known/mta-sts.txt. Servita in HTTPS, richiede un certificato valido.
Mode: Uno fra enforce, testing e none. Sotto testing la posta viene recapitata anche quando il controllo fallisca.
Max_age: Per quanti secondi un mittente possa tenere la politica in cache. Un valore più lungo rafforza la protezione ma rallenta la diffusione di ogni modifica.
Mx: L'elenco degli host MX su cui imporre il TLS. Il recapito verso un host assente da questo elenco viene rifiutato.
Declassamento di STARTTLS: L'attacco in cui un interposto sfila l'annuncio di STARTTLS per imporre il testo in chiaro. MTA-STS fu ideato per impedirlo.

Domande frequenti

La mancata adozione è una condizione comune a moltissimi domini e non comporta di per sé un pericolo immediato. Se però volete aumentare la resistenza agli attacchi che disattivano la cifratura, vale la pena valutarne l'adozione.

SPF, DKIM e DMARC autenticano il dominio mittente e verificano che non si tratti di contraffazione. MTA-STS non riguarda l'autenticazione del mittente: impone la cifratura TLS lungo il percorso di trasferimento della posta. I due gruppi difendono da minacce di livello diverso.

Non sul dominio principale, ma su un sottodominio con il prefisso «mta-sts», in un percorso convenzionale del server web. È indispensabile che sia servito con un certificato TLS valido.

Non è consigliabile. La procedura prudente prevede di restare qualche settimana o un mese in modalità di prova, monitorando la consegna anche con le relazioni TLS-RPT, e passare all'imposizione solo in assenza di problemi.

Lo strumento verifica soltanto la sintassi e la presenza delle voci obbligatorie nel record TXT e nel file di politica. Poiché non controlla la validità del certificato TLS né l'esito reale della negoziazione con i server di posta, per una verifica rigorosa affiancate strumenti specialistici.

A proposito — il punto debole della cifratura opportunistica e la nascita di MTA-STS

La cifratura nel trasferimento della posta si è a lungo affidata al meccanismo standardizzato nel 1999 che apre la connessione in chiaro e passa poi alla cifratura. Nel 2014, però, è stato osservato un attacco che sfrutta il fatto che quella negoziazione avvenga in chiaro, prima dell'attivazione della cifratura: un aggressore interposto riscrive le risposte contenenti il comando di avvio e ne impedisce l'attivazione. Il server colpito continua a inviare e ricevere posta in chiaro.

La causa profonda sta nel fatto che quel meccanismo era progettato per ripiegare sul testo in chiaro qualora l'interlocutore non supportasse la cifratura. L'aggressore rovescia a proprio favore questa retrocompatibilità, fingendo che l'altra parte non supporti la cifratura. Alcune indagini condotte intorno al 2015 hanno rivelato che in certi paesi e presso certi operatori la manomissione avveniva su vasta scala.

MTA-STS, pubblicato nel 2018 con la RFC 8461, è la risposta a quel punto debole, elaborata insieme dai principali fornitori di posta. Con un record TXT nel DNS si dichiara che il dominio adotta MTA-STS e in un file di politica scaricato via HTTPS si indicano i server ammessi e i requisiti TLS. Una volta ottenuta, la politica resta in cache per la durata indicata: nelle connessioni successive si possono quindi rilevare e rifiutare i tentativi di declassamento verso il testo in chiaro.

Si diffonde inoltre la pratica di combinarlo con TLS-RPT, definito dalla RFC 8460, per ricevere relazioni sugli insuccessi delle connessioni TLS. La suddivisione dei ruoli — MTA-STS per la difesa, TLS-RPT per l'osservabilità — e l'uso congiunto dei due sono oggi considerati la prassi migliore.

Vedi tutte le curiosità