MTA-STS

Questa guida fa parte della nostra guida all’autenticazione email. Correlate: MTA-STS e DKIM vs DMARC.

MTA-STS (SMTP MTA Strict Transport Security) è uno standard che permette a un dominio di richiedere che la posta in entrata sia consegnata tramite TLS crittografato e autenticato, prevenendo attacchi di downgrade e man-in-the-middle. TLS-RPT è il suo standard di reporting complementare, che raccoglie report giornalieri sui fallimenti TLS di consegna. MTA-STS protegge il livello di trasporto, complementando SPF, DKIM e DMARC, che autenticano il mittente anziché la connessione.

Il problema che MTA-STS risolve

Quando due server di posta si scambiano messaggi tramite SMTP, normalmente negoziano la crittografia usando STARTTLS. Il problema è che STARTTLS è opportunistico: il server di invio chiede se il destinatario supporta TLS, e se la risposta è no, ripiega silenziosamente sul testo in chiaro. Quella domanda e risposta avvengono in chiaro, il che significa che un aggressore posizionato tra i due server può rimuovere il comando STARTTLS dalla conversazione. Il server di invio crede allora che il destinatario non abbia supporto TLS e consegna il messaggio non crittografato, oppure si connette a un server impostore che presenta un certificato contraffatto.

Questi sono noti come attacchi di downgrade e man-in-the-middle. Poiché SMTP è stato progettato prima per l’interoperabilità e poi per la sicurezza, storicamente non c’era modo per un dominio ricevente di dire “crittografa sempre la posta verso di me e rifiuta di consegnarla se non puoi”. MTA-STS colma esattamente questa lacuna. Permette a un dominio di pubblicare una policy che dichiara che la posta in entrata deve essere consegnata tramite TLS, usando un certificato valido che corrisponde a uno dei suoi host MX pubblicati. I server di invio che supportano MTA-STS rispettano la policy e differiranno o rimbalzeranno un messaggio anziché inviarlo in chiaro.

Come funziona MTA-STS

MTA-STS si basa su due componenti che lavorano insieme: un record TXT del DNS che pubblicizza la policy e un file di policy ospitato via HTTPS che la definisce.

Innanzitutto, pubblica un record TXT su _mta-sts.yourdomain.com. Questo record segnala che una policy esiste e porta un ID che cambia ogni volta che aggiorni la policy, così i server di invio sanno quando riscaricarla.

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260910T120000;"

In secondo luogo, servi il file di policy via HTTPS in una posizione fissa e ben nota: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Il requisito HTTPS conta perché il certificato su quell’host dimostra che la policy è autentica e non è stata manomessa in transito.

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800

Le righe mx elencano ogni hostname autorizzato a ricevere la tua posta, corrispondente ai tuoi record MX. max_age indica ai server di invio per quanto tempo memorizzare in cache la policy, in secondi (604800 è una settimana). Una cache più lunga è più resistente a un aggressore in grado di manipolare brevemente il DNS, quindi un valore di almeno qualche giorno è consigliato una volta che sei sicuro della tua configurazione.

Modalità enforce contro testing

Il campo mode nel file di policy controlla quanto rigorosamente la policy viene applicata, ed è la manopola più importante nel rollout di MTA-STS.

Inizia con mode: testing. In modalità testing, i server di invio valutano la tua policy ma non bloccano mai la consegna quando fallisce. Invece, in combinazione con TLS-RPT qui sotto, ti riportano i fallimenti. Questo ti permette di scoprire host MX mal configurati, certificati scaduti o discrepanze di hostname senza mai perdere un messaggio legittimo.

Una volta che i tuoi report tornano puliti per una o due settimane, passa a mode: enforce. Ora i server di invio rifiuteranno di consegnare la posta che non può essere inviata tramite TLS autenticato a un host MX elencato. Un terzo valore, mode: none, disabilita di fatto la policy e viene usato per ritirare MTA-STS con grazia. Passa sempre da testing a enforce in modo deliberato, mai il contrario in fretta.

TLS-RPT: reporting

MTA-STS da solo non ti dice nulla su come sta andando la consegna. TLS-RPT (SMTP TLS Reporting) è il canale di feedback. Pubblichi un secondo record TXT su _smtp._tls.yourdomain.com che indica un indirizzo che dovrebbe ricevere i report aggregati.

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

I server di invio partecipanti ti inviano un report JSON giornaliero che riassume le sessioni TLS riuscite e fallite verso il tuo dominio, incluso il motivo di ogni fallimento, come un certificato non validato o una negoziazione STARTTLS rimossa. Questi report sono ciò che rende utile la modalità testing, e restano preziosi in modalità enforce come sistema di allerta precoce per la scadenza dei certificati o i cambiamenti degli MX. Molti team indirizzano l’indirizzo rua verso una dashboard di monitoraggio anziché una casella di posta umana.

Dove si colloca accanto a SPF, DKIM e DMARC

È facile accomunare MTA-STS agli altri acronimi, ma risolve un problema diverso. SPF, DKIM e DMARC autenticano il mittente, rispondendo a “questo messaggio proviene davvero dal dominio che dichiara?” MTA-STS protegge la connessione, rispondendo a “questo messaggio viene consegnato in modo privato e al server giusto?” Vuoi entrambi. Un messaggio può essere perfettamente autenticato e comunque intercettato in transito, e una connessione perfettamente crittografata può comunque trasportare un messaggio contraffatto.

Per il quadro completo dell’autenticazione del mittente, consulta la nostra guida all’autenticazione email. MTA-STS si abbina naturalmente a questi standard come aggiunta al livello di trasporto, e una volta che li hai in atto, BIMI è un altro livello avanzato da considerare, che ti permette di mostrare un logo di brand verificato nelle caselle di posta che lo supportano.

Domande frequenti

Che cos’è MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security) è uno standard che permette a un dominio di richiedere che l’email in entrata sia consegnata tramite TLS crittografato e autenticato. Pubblica un record DNS e un file di policy ospitato via HTTPS affinché i server di invio applichino la crittografia e rifiutino di ripiegare sul testo in chiaro, bloccando gli attacchi di downgrade e man-in-the-middle contro SMTP.

Qual è la differenza tra MTA-STS e TLS-RPT?

MTA-STS è lo standard di enforcement: definisce la policy che richiede la consegna TLS. TLS-RPT è lo standard di reporting: definisce un record DNS e un formato di report JSON affinché i server di invio ti inviino riepiloghi giornalieri dei successi e dei fallimenti di consegna TLS. Li distribuisci insieme, usando TLS-RPT per validare in sicurezza una policy MTA-STS prima di applicarla.

MTA-STS è obbligatorio?

No, MTA-STS non è obbligatorio, e l’email funziona senza di esso. Tuttavia, è fortemente consigliato per qualsiasi dominio che gestisce posta sensibile, perché chiude una lacuna reale che SPF, DKIM e DMARC non affrontano. Distribuirlo prima in modalità testing non comporta alcun rischio di consegna, quindi ci sono pochi motivi per non adottarlo.

MTA-STS sostituisce SPF, DKIM o DMARC?

No. MTA-STS opera a un livello diverso. SPF, DKIM e DMARC autenticano il mittente e rilevano lo spoofing, mentre MTA-STS protegge la connessione di trasporto affinché la posta sia consegnata in modo privato al server corretto. Sono controlli complementari, e un dominio ben protetto li distribuisce tutti insieme anziché sceglierne uno al posto dell’altro.