MTA-STS e TLS-RPT: che cosa fanno e se ti servono
MTA-STS è un criterio con cui dici ai server mittenti che la posta verso il tuo dominio può essere consegnata solo su una connessione TLS cifrata e verificata. TLS-RPT è il canale di rendicontazione che l'accompagna: i mittenti ti inviano ogni giorno un resoconto delle connessioni che non hanno rispettato quel criterio. Entrambi proteggono la posta che ricevi; per la posta che invii ti serve soprattutto un server d'invio che rispetti i criteri del destinatario.
Il problema che risolvono
La posta tra server viaggia da anni in gran parte cifrata, tramite STARTTLS. Ma STARTTLS è opportunistico: il server mittente chiede se il destinatario supporta la cifratura e, se la risposta non arriva o il certificato non è valido, ripiega in silenzio su una connessione non cifrata. Chi si trova tra i due server può filtrare via quella domanda e far passare la posta in chiaro. MTA-STS toglie quel ripiego: se il tuo criterio è su "enforce", un mittente che non riesce a completare la cifratura non può consegnare la posta.
Come funziona MTA-STS
Consiste di due parti che pubblichi tu:
- Un record DNS su _mta-sts.tuodominio.be con una versione e un id. L'id lo cambi ogni volta che modifichi il criterio; i mittenti sanno così di doverlo recuperare di nuovo.
- Un file di criterio su https://mta-sts.tuodominio.be/.well-known/mta-sts.txt. Contiene la modalità (none, testing o enforce), i server di posta che possono ricevere per il tuo dominio e per quanto tempo un mittente può ricordare il criterio.
La seconda parte spiega perché MTA-STS passa da HTTPS e non solo dal DNS: il certificato di quella pagina web dimostra che il criterio viene davvero dal tuo dominio, senza bisogno di DNSSEC. L'alternativa, DANE, fa la stessa cosa via DNS ma richiede sì DNSSEC sul tuo dominio, cosa che in pratica presso molti registrar e pacchetti di hosting non è attiva di base.
Come funziona TLS-RPT
TLS-RPT è un solo record DNS su _smtp._tls.tuodominio.be con un indirizzo a cui vuoi ricevere i rapporti. I mittenti che lo supportano (tra cui i grandi provider) ti mandano allora una volta al giorno un resoconto con, per ogni server mittente, quante connessioni sono riuscite e quante no, e perché: certificato scaduto, nome del server non corrispondente, STARTTLS non offerto, criterio non recuperabile.
Quel rapporto è il motivo per cominciare da TLS-RPT prima ancora di imporre MTA-STS. Ti dice se ci sono mittenti che tra poco non riusciranno più a consegnare la tua posta se metti la modalità su enforce. Paragonalo a DMARC: prima guardare, poi stringere. Come si legge sta nel nostro articolo sui rapporti DMARC; la logica è la stessa.
Ti serve?
Dipende da quale lato della connessione guardi.
Come destinatario
Se il tuo dominio riceve posta sensibile (fascicoli del personale, dati sanitari, corrispondenza legale, istruzioni di pagamento), MTA-STS è una protezione economica contro l'intercettazione della posta in transito. Per un dominio che riceve soprattutto newsletter e conferme d'ordine il guadagno è minore, ma costa poco: un record DNS, un piccolo file statico su un sottodominio con certificato valido e una casella per i rapporti.
Come mittente
MTA-STS sul tuo dominio non cambia nulla per la posta che invii. Conta invece questo: il server con cui invii deve controllare e rispettare il criterio MTA-STS del destinatario, e deve avere a sua volta un certificato TLS corretto. Se invii tramite un SMTP relay, è responsabilità del relay. Chiedilo se non ne sei sicuro: un mittente che ignora il criterio viene rifiutato da un destinatario in modalità enforce, e tu lo vedi come bounce.
Un percorso pratico
- Metti il record TLS-RPT e lascia arrivare i rapporti per qualche settimana a un indirizzo che qualcuno legga davvero.
- Pubblica il criterio MTA-STS in modalità testing. I mittenti segnalano allora gli scostamenti nei rapporti ma consegnano ancora normalmente.
- Risolvi ciò che vedi nei rapporti: di solito un server di posta che non era nel criterio, o un certificato intestato a un altro nome.
- Metti la modalità su enforce e aumenta l'id nel record DNS.
- Guarda i rapporti ogni mese e a ogni modifica dei tuoi server di posta controlla che il file del criterio sia ancora corretto.
Chi usa una piattaforma di posta ospitata trova i nomi dei server per il criterio nelle impostazioni MX di quella piattaforma. Chi gestisce server di posta propri deve sorvegliarne il certificato: un certificato scaduto significa, in modalità enforce, che la posta esterna non entra più.
Che cosa non fa
MTA-STS non dice nulla su chi può inviare a nome tuo; per quello restano necessari SPF, DKIM e DMARC. Non protegge nemmeno il tragitto dal server destinatario alla casella del lettore, e non cifra il contenuto sul server stesso. Chiude una falla precisa: il ripiego non cifrato tra due server di posta.
Domande frequenti
MTA-STS è obbligatorio?
No. È una raccomandazione che i grandi provider supportano, non una condizione per consegnare. In alcuni settori e in alcune gare d'appalto viene però richiesto sempre più spesso.
Posso attivare MTA-STS se la mia posta è su Microsoft 365 o Google Workspace?
Sì. Il criterio lo pubblichi tu, con dentro i server MX di quella piattaforma. Entrambe le piattaforme hanno certificati validi su quei server.
E se su quel dominio invio soltanto e non ricevo nulla?
Allora MTA-STS per quel dominio serve a poco. Dedica il tuo tempo all'autenticazione e alla deliverability; è su quello che viene giudicata la tua posta in uscita.