Cifratura del trasporto: MTA-STS e TLS-RPT

MTA-STS obbliga i mittenti a consegnare la tua posta solo in modo cifrato e verificato. Come si pubblica la policy, che cosa dice TLS-RPT e che cosa questa verifica non può misurare.

Quando un server di posta ne contatta un altro, la connessione parte in chiaro e viene cifrata solo se entrambi si accordano, con un comando che si chiama STARTTLS. Il difetto sta proprio lì: è un'offerta, non un obbligo. Chi si trova in mezzo alla connessione può cancellare quell'offerta, e i due server proseguono in chiaro senza accorgersi di nulla. Nessun avviso, nessun errore.

MTA-STS chiude questa porta. È una dichiarazione pubblica: chi consegna posta al mio dominio deve farlo in modo cifrato, e il certificato del mio server deve essere valido; se non è così, non consegnare affatto. Chi la rispetta interrompe la consegna invece di ripiegare in chiaro.

TLS-RPT è il suo complemento: un indirizzo a cui i mittenti spediscono un rapporto giornaliero quando qualcosa non ha funzionato. Senza, un problema di cifratura resta invisibile.

Come sono fatti i record

MTA-STS ha due pezzi che devono coincidere: un record DNS e un file su un sito.

Il record:

_mta-sts.esempio.it.  TXT  "v=STSv1; id=20260916T120000;"

L'id è un'etichetta di versione: la si cambia ogni volta che si modifica il file, così i mittenti sanno di doverlo riscaricare. Un formato con data e ora è la scelta più pratica.

Il file, raggiungibile a https://mta-sts.esempio.it/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail1.esempio.it
mx: mail2.esempio.it
max_age: 604800

TLS-RPT è invece un record solo:

_smtp._tls.esempio.it.  TXT  "v=TLSRPTv1; rua=mailto:tls@esempio.it"

Come si imposta

L'ostacolo pratico non è il DNS: è il file. Serve un sottodominio mta-sts.<dominio> che risponda in HTTPS con un certificato valido. Su un hosting condiviso — Aruba, Register.it, Netsons, Serverplan — significa creare il sottodominio nel pannello, farsi emettere il certificato e caricare un file di testo in una cartella .well-known. È fattibile ovunque, ma è mezz'ora di lavoro, non un clic.

L'ordine giusto:

1. Pubblica prima TLS-RPT: è un record solo e non ha effetti collaterali. Da quel momento cominci a ricevere rapporti.
2. Crea il sottodominio mta-sts.tuo-dominio.it con certificato HTTPS valido e caricaci .well-known/mta-sts.txt.
3. Nel file metti mode: testing e tutti i nomi MX del dominio. Controllali uno per uno: un nome dimenticato qui è ciò che poi blocca la posta.
4. Pubblica il record _mta-sts con un id qualsiasi.
5. Aspetta due o tre settimane e leggi i rapporti TLS-RPT. Se non segnalano scostamenti, cambia mode: testing in mode: enforce e aggiorna l'id.
6. Ogni volta che cambi i server di posta, aggiorna prima il file e poi gli MX.

Chi usa Microsoft 365 o Google Workspace ha vita più facile per la parte MX — basta il nome con l'asterisco — ma il sottodominio con il file va comunque ospitato da qualche parte: di solito sullo stesso hosting del sito.

I rilievi nel dettaglio

Più record MTA-STS

Sotto _mta-sts ci sono due o più record TXT che cominciano con v=STSv1. Ne è ammesso uno solo; con più di uno l'indicazione diventa inutilizzabile e i mittenti ignorano la policy.

Che cosa fare. Tieni il record con l'id più recente e cancella gli altri. Succede spesso quando si aggiorna l'id creando un nuovo record invece di modificare quello esistente.

MTA-STS in modalità di prova

La policy dice mode: testing. I mittenti che la rispettano verificano la cifratura e, se qualcosa non torna, consegnano lo stesso e lo segnalano nei rapporti TLS-RPT. Non c'è protezione, ma c'è informazione: è il modo giusto di cominciare.

Che cosa fare. Lascia passare qualche settimana e controlla i rapporti. Se non arrivano segnalazioni di scostamento, passa a mode: enforce e aggiorna l'id nel record DNS. Se invece la modalità di prova dura da mesi, è probabile che nessuno stia leggendo i rapporti: vale la pena chiudere il ciclo in un verso o nell'altro.

MTA-STS disattivato (mode: none)

La policy dice espressamente mode: none: i mittenti non devono applicare nulla. È il modo previsto per ritirare una policy in modo ordinato, così chi l'aveva in cache la scarta invece di continuare a imporla.

Che cosa fare. Se la disattivazione era temporanea e il problema è risolto, rimetti mode: testing o mode: enforce e aggiorna l'id. Se invece la disattivazione è definitiva, dopo qualche settimana togli sia il file sia il record DNS: una policy none che resta lì per anni confonde e basta.

Validità MTA-STS molto breve

Il valore di max_age è inferiore a un giorno. In pratica annulla la protezione: i mittenti riscaricano la policy così spesso che chi si trova in mezzo alla connessione può semplicemente impedirne il recupero, e a quel punto non c'è più nulla da imporre.

Che cosa fare. Porta max_age ad almeno 86400 secondi, e preferibilmente a 604800, che è l'uso comune. Un valore breve ha senso solo nei giorni attorno a una migrazione dei server, e va rialzato subito dopo.

La policy non cita tutti i server

Nel file mancano uno o più nomi che compaiono nei tuoi record MX. Con mode: testing la conseguenza è limitata: i mittenti consegnano comunque e generano rapporti di errore. È però un avviso preciso di che cosa succederebbe passando a enforce.

Che cosa fare. Confronta riga per riga i nomi del file con i record MX del dominio e aggiungi quelli mancanti. Ricordati di aggiornare l'id nel record DNS, altrimenti chi ha la vecchia policy in cache non vede la modifica.

La policy imposta esclude i tuoi server

La policy è su enforce ma non cita tutti i server elencati negli MX. Questo è un guasto in corso, non un avvertimento: i mittenti che rispettano la policy — Google e Microsoft, quindi una quota enorme della posta mondiale — interrompono la consegna verso i server mancanti. La tua posta in entrata non arriva.

Che cosa fare. Subito: o aggiungi al file i nomi MX mancanti e aggiorni l'id, oppure, se ti serve tempo per capire, rimetti mode: testing e aggiorna comunque l'id. Tieni presente che la vecchia policy resta in cache presso i mittenti per la durata del max_age, quindi l'effetto della correzione non è immediato per tutti.

Record MTA-STS senza file di policy

Il record DNS c'è, ma il file all'indirizzo https://mta-sts.<dominio>/.well-known/mta-sts.txt non è raggiungibile. Cause tipiche: il sottodominio non esiste, il certificato HTTPS non è valido o è scaduto, il file è stato caricato nella cartella sbagliata, o il server risponde con una pagina di errore invece del testo.

Che cosa fare. Apri quell'indirizzo in un browser: devi vedere il testo della policy, non una pagina del sito. Se non è così, controlla nell'ordine il sottodominio, il certificato e il percorso del file. Finché il file non c'è, è più prudente togliere il record DNS: alcuni mittenti, vedendo il record senza ottenere il file, possono interrompere la consegna.

TLS-RPT senza indirizzo di destinazione

Il record _smtp._tls esiste ma non contiene rua=. Senza un destinatario non viene recapitato nessun rapporto: il record c'è e non produce niente.

Che cosa fare. Aggiungi rua=mailto:tls@tuo-dominio.it al record, usando una casella che qualcuno legge davvero. I rapporti TLS-RPT sono pochi e, in condizioni normali, quasi sempre vuoti di segnalazioni — quando invece arrivano, vale la pena leggerli.

Domande frequenti

MTA-STS protegge la posta che spedisco o quella che ricevo?

Quella che ricevi. La policy che pubblichi vale per chi consegna al tuo dominio. Per la posta che spedisci, conta la policy pubblicata dai destinatari e il fatto che il tuo server la rispetti: questo dipende dal software del server e non si vede dall'esterno.

Serve anche se uso Microsoft 365 o Google Workspace?

Sì, e ha senso: entrambi supportano la cifratura correttamente, ma solo tu puoi dichiarare pubblicamente che la consegna al tuo dominio deve essere cifrata. Il lavoro si riduce alla parte web, cioè al sottodominio con il file.

Che differenza c'è tra MTA-STS e DANE?

Servono allo stesso scopo con mezzi diversi: DANE ancora il certificato nel DNS e richiede DNSSEC, MTA-STS usa un file su HTTPS e non richiede DNSSEC. Nella pratica MTA-STS è molto più diffuso perché si può attivare ovunque; DANE è più rigoroso ma ha bisogno di una zona DNS firmata.

Rischio di bloccare la mia posta in entrata?

Solo con mode: enforce e un file incompleto. È esattamente il motivo per cui si comincia da testing e si passa a enforce solo dopo settimane di rapporti puliti. E anche dopo, ogni cambio di server di posta va fatto aggiornando prima il file.