• Cloud, Guide, Microsoft 365, Sicurezza
• 30 Aprile 2026

La sicurezza del trasporto SMTP è un elemento fondamentale per proteggere le comunicazioni email da intercettazioni e attacchi di tipo man-in-the-middle. Sebbene il protocollo TLS sia ormai ampiamente utilizzato, di default non è obbligatorio e può essere soggetto a tentativi di downgrade.

MTA-STS (Mail Transfer Agent Strict Transport Security) nasce proprio per risolvere questo limite: consente al vostro dominio di dichiarare esplicitamente che le email devono essere recapitate solo tramite connessioni TLS sicure, definendo anche quali server MX sono autorizzati a riceverle. Questo avviene attraverso una combinazione di record DNS e una policy HTTPS, che insieme permettono ai server mittenti di verificare e applicare le vostre regole.

Oggi MTA-STS è adottato dai principali provider di posta, tra cui Microsoft (Exchange Online), Google (Gmail), Yahoo e altri grandi operatori, contribuendo a rendere il trasporto email sempre più sicuro e affidabile.

In questa guida vedrete come implementare MTA-STS in Exchange Online, configurando correttamente tutti i componenti necessari e verificando passo dopo passo il corretto funzionamento.

Prerequisiti e architettura

Prima di configurare MTA-STS è importante comprendere i componenti coinvolti e assicurarvi di avere tutti i prerequisiti necessari. State lavorando su un meccanismo che combina DNS pubblico, un endpoint HTTPS e l’infrastruttura di posta di Exchange Online; quindi, ogni elemento deve essere correttamente configurato e raggiungibile.

Dal punto di vista dei prerequisiti dovete disporre del controllo del vostro dominio DNS, necessario per pubblicare il record _mta-sts e, opzionalmente, quello per la reportistica TLS-RPT. Serve inoltre un endpoint web esposto in HTTPS, raggiungibile pubblicamente, che ospiterà il file della policy MTA-STS. Questo endpoint deve avere un certificato valido e trusted, associato al sottodominio mta-sts.vostrodominio. Infine, il vostro dominio deve utilizzare Exchange Online con record MX correttamente configurati verso mail.protection.outlook.com.

A livello architetturale, il funzionamento è lineare ma rigoroso. Quando un server mittente deve consegnare un’email al vostro dominio, interroga il DNS per verificare la presenza del record _mta-sts. Se presente, recupera la policy tramite connessione HTTPS e la memorizza in cache per il tempo definito dal parametro max_age. A questo punto, durante la connessione SMTP, il server verifica che il certificato TLS sia valido e che il server di destinazione corrisponda ai valori MX dichiarati nella policy. Se avete impostato la modalità enforce, qualsiasi incongruenza porta al rifiuto della connessione.

Questo modello introduce un controllo forte sul trasporto SMTP, perché lega insieme identità del dominio, cifratura TLS e destinazione autorizzata, riducendo drasticamente il rischio di attacchi di tipo downgrade o intercettazione.

Figura 1: Schema del funzionamento di MTA-STS con verifica DNS, recupero della policy HTTPS e validazione TLS durante la consegna SMTP

Configurazione del record DNS _mta-sts

Il primo passo operativo consiste nella pubblicazione del record DNS TXT _mta-sts, che segnala ai server mittenti che il vostro dominio supporta MTA-STS. Questo record è il punto di ingresso del meccanismo: senza di esso, nessun server tenterà di recuperare la vostra policy HTTPS.

Dovete creare il record nel vostro DNS pubblico, assicurandovi che il nome sia esattamente _mta-sts.vostrodominio. Il valore deve contenere la versione del protocollo e un identificativo di policy (id), ad esempio:

v=STSv1; id=YYYYMMDDHHMMSSZ

L’attributo id è fondamentale: identifica la versione della policy. Ogni volta che modificate la configurazione, dovete aggiornarlo, altrimenti i server remoti continueranno a usare la versione in cache fino alla scadenza del max_age. Un approccio pratico è usare un timestamp in formato UTC, ad esempio:

id=20260430100000Z

Partendo dalla data e ora attuale (30 aprile 2026, ad esempio ore 10:00 UTC), il record diventa:

_mta-sts.nicolaferrini.eu. 3600 IN TXT v=STSv1; id=20260430100000Z;

Adeguate sempre il valore dell’id all’orario UTC corrente, perché è ciò che forza i server remoti a rileggere la vostra policy aggiornata.

Nella figura sotto ho configurato il record DNS TXT per MTA-STS all’interno della mia zona DNS su Microsoft Azure.

Figura 2: Configurazione del record TXT _mta-sts in Azure DNS per abilitare MTA-STS sul dominio

Pubblicazione e gestione della policy MTA-STS

Parallelamente dovete pubblicare la policy MTA-STS su un endpoint HTTPS raggiungibile pubblicamente. L’URL deve essere esattamente:

https://mta-sts.vostrodominio.it/.well-known/mta-sts.txt

Per ottenere questo risultato è necessario creare un sottodominio dedicato (mta-sts.vostrodominio.it) e farlo puntare a un servizio web (ad esempio Azure Web App o altro hosting). Questo passaggio è fondamentale: dovete quindi rivolgervi al vostro provider DNS/hosting per creare il record (tipicamente CNAME o A record) che associa il sottodominio al server che ospiterà il file.

Una volta configurato il sottodominio, dovete pubblicare il file mta-sts.txt all’interno del percorso /.well-known/. Il contenuto deve essere coerente con Exchange Online. Un esempio in modalità testing:

Successivamente, quando avete validato tutto, potete passare a enforce:

Il parametro mx deve riflettere i vostri record Exchange Online. Potete usare il wildcard *.mail.protection.outlook.com oppure, se preferite maggiore granularità, il valore specifico del vostro dominio (es. vostrodominio.mail.protection.outlook.com).

È importante sottolineare che Exchange Online non ospita questa policy per voi: siete voi a dover garantire che l’endpoint sia sempre disponibile, raggiungibile via HTTPS e con un certificato valido per mta-sts.vostrodominio.it. Se il servizio non è disponibile o il certificato non è valido, i server mittenti potrebbero non riuscire a validare la policy.

Questo passaggio completa la parte più critica della configurazione: state pubblicando le regole che i server mittenti useranno per verificare la sicurezza del trasporto verso il vostro dominio.

Figura 3: Verifica della policy MTA-STS pubblicata via HTTPS con modalità testing per dominio in Exchange Online

Una volta che il record DNS TXT è configurato e la policy è correttamente pubblicata, il vostro dominio inizierà ad applicare MTA-STS, garantendo che la comunicazione SMTP avvenga solo su connessioni sicure e conformi alle vostre regole.

Validazione della configurazione MTA-STS

Per una verifica immediata potete utilizzare tool di validazione esterni, che simulano il comportamento dei server mittenti e controllano automaticamente la vostra configurazione MTA-STS. Questi strumenti analizzano il record DNS, verificano la raggiungibilità dell’endpoint HTTPS, validano il certificato e confrontano la policy con i vostri record MX di Exchange Online. Il vantaggio è che ottenete un riscontro rapido e oggettivo su eventuali errori di configurazione, senza dover attendere traffico reale o report TLS-RPT. Sono particolarmente utili durante la fase testing, perché vi permettono di individuare incongruenze prima di passare a enforce, riducendo il rischio di problemi nel recapito della posta.

Io ho utilizzato Mailhardener, che esegue un controllo completo della configurazione. Il risultato evidenzia che il dominio è configurato correttamente per MTA-STS, con record DNS valido, policy raggiungibile via HTTPS e certificato corretto. Inoltre, la corrispondenza tra i record MX di Exchange Online e la policy è ora valida.

Figura 4: Validazione completa con Mailhardener che conferma la corretta configurazione MTA-STS in modalità testing

Reportistica SMTP TLS (TLS-RPT)

Per completare l’implementazione di MTA-STS dovete abilitare anche la reportistica SMTP TLS, che vi consente di monitorare cosa accade realmente durante il recapito della posta verso il vostro dominio. Tramite un apposito record DNS TXT (_smtp._tls), chiedete ai server mittenti di inviarvi report aggregati in formato JSON, contenenti informazioni su connessioni riuscite, errori TLS e violazioni della policy MTA-STS. Questo è fondamentale perché vi dà visibilità su eventuali problemi di configurazione, tentativi di downgrade TLS o incompatibilità con sistemi remoti. In pratica, mentre MTA-STS definisce le regole, la reportistica TLS-RPT vi permette di verificarne l’effettiva applicazione nel traffico reale, soprattutto durante il passaggio da testing a enforce.

Nel record _smtp._tls dovete specificare dove volete ricevere i report TLS-RPT. Il valore è semplice e punta a un indirizzo email dedicato alla raccolta dei report.

Un esempio corretto è:

v=TLSRPTv1; rua=mailto:[email protected]

Dove rua indica l’indirizzo che riceverà i report aggregati in formato JSON. Potete usare una mailbox dedicata, perché i report possono diventare numerosi e poco leggibili senza strumenti di analisi.

Se volete essere più strutturati, potete anche inviarli a servizi esterni specializzati, ad esempio:

v=TLSRPTv1; rua=mailto:[email protected],mailto:[email protected]

L’importante è che l’indirizzo sia valido e monitorato, perché è lì che riceverete informazioni su errori TLS, problemi di consegna e violazioni della policy MTA-STS.

Figura 5: Configurazione del record _smtp._tls per abilitare la reportistica TLS-RPT

Tenete presente che i report sono tecnici e poco leggibili: per analizzarli in modo efficace è consigliato utilizzare piattaforme dedicate oppure strumenti che interpretano automaticamente i file JSON e vi mostrano eventuali errori o violazioni della policy.

Tra le soluzioni più utilizzate potete considerare Mailhardener, che offre una gestione completa di MTA-STS e TLS-RPT, oppure EasyDMARC, che include dashboard intuitive per l’analisi dei report. Un’altra opzione valida è Valimail, particolarmente diffusa in ambienti enterprise.

Passaggio alla modalità enforce

Una volta completata la fase di testing e verificato, tramite tool di validazione e report TLS-RPT, che non ci sono errori o anomalie nel recapito della posta, potete passare alla modalità enforce. Questo cambiamento rende obbligatorio l’uso di TLS per i server mittenti conformi a MTA-STS, che rifiuteranno la consegna se non riescono a stabilire una connessione sicura o se la destinazione non corrisponde alla policy dichiarata. Prima di effettuare il passaggio assicuratevi che la configurazione sia completamente allineata tra DNS, policy HTTPS e Exchange Online, quindi aggiornate il parametro mode nella policy e incrementate l’id nel record DNS per forzare il refresh da parte dei server remoti. Questo è il momento in cui la vostra configurazione diventa effettivamente vincolante e protettiva.

Figura 6: erifica della policy MTA-STS in modalità enforce pubblicata correttamente via HTTPS

Ricordate che, affinché questa modifica sia recepita, è necessario aver aggiornato anche l’id nel record DNS TXT _mta-sts, così da forzare il refresh della policy.

Figura 7: Aggiornamento del record _mta-sts in Azure DNS con nuovo id per forzare il refresh della policy

A questo punto la configurazione è completa: avete aggiornato sia la policy sia il relativo id, garantendo che le modifiche vengano propagate correttamente nel comportamento dei server mittenti.

Ma quindi d’ora in poi se un server non si connette in maniera sicura non riceverò più posta da quel dominio mittente?

Sì, ma con una precisazione importante: questo comportamento si applica solo ai server mittenti che supportano e rispettano MTA-STS.

Con mode: enforce, state dicendo: “accetto email solo se la connessione è TLS valida e verso un MX autorizzato“. Di conseguenza, se un server mittente conforme a MTA-STS non riesce a stabilire una connessione sicura o trova una discrepanza rispetto alla policy, non consegnerà l’email.

Tuttavia, non tutti i server nel mondo implementano MTA-STS. I server che non lo supportano continueranno a comportarsi come prima, quindi potrebbero comunque consegnare email anche senza rispettare questi controlli.

Di fatto aumentate significativamente la sicurezza, ma non state bloccando “tutta” la posta non sicura, solo quella proveniente da sistemi che implementano correttamente MTA-STS.

C’è anche un altro aspetto da considerare: se la vostra configurazione ha errori (ad esempio policy non raggiungibile o mismatch sugli MX), rischiate di perdere email legittime da mittenti conformi. Per questo la fase di testing e la verifica tramite TLS-RPT sono fondamentali prima di passare a enforce.

MTA-STS e SMTP DANE: coesistenza e configurazione corretta

MTA-STS e SMTP DANE possono convivere e sono entrambi supportati in Exchange Online, ma quando implementate DANE dovete considerare un aspetto fondamentale: i vostri record MX cambiano per poter gestire i record TLSA tramite DNSSEC.

Questo impatta direttamente anche la configurazione di MTA-STS. La policy non può più utilizzare il wildcard *.mail.protection.outlook.com, ma deve essere perfettamente allineata ai nuovi MX che avete definito (ad esempio vostrodominio.m-v1.mx.microsoft o hostname equivalente).

Il file mta-sts.txt deve quindi riflettere questa configurazione:

Questo è il punto chiave: MTA-STS deve dichiarare esattamente gli stessi host MX che avete configurato per DANE, perché sono quelli su cui pubblicate i record TLSA.

Dal punto di vista operativo:

• i server che supportano DANE utilizzeranno DNSSEC + TLSA con priorità
• i server che non supportano DANE utilizzeranno MTA-STS
• entrambi i meccanismi saranno coerenti perché puntano allo stesso hostname MX

Questo approccio vi permette di ottenere una protezione completa e consistente: DANE garantisce autenticità forte, mentre MTA-STS assicura compatibilità e enforcement TLS su larga scala.

Se volete approfondire la configurazione di SMTP DANE in Exchange Online con DNSSEC, potete fare riferimento alla mia guida Configurare SMTP DANE in Exchange Online con DNSSEC in Azure DNS – ICT Power.

Conclusioni

Con l’implementazione di MTA-STS avete introdotto un livello concreto di protezione per il traffico SMTP, assicurando che le comunicazioni verso il vostro dominio avvengano solo tramite connessioni TLS sicure e conformi alla vostra policy.

Il processo richiede coerenza tra DNS, endpoint HTTPS e configurazione Exchange Online, oltre a una fase iniziale di testing per evitare impatti sul recapito della posta. La reportistica TLS-RPT e i tool di validazione vi permettono di monitorare e verificare nel tempo il corretto funzionamento.

Una volta passati a enforce, la protezione diventa effettiva: riducete il rischio di attacchi di tipo downgrade e migliorate la postura di sicurezza del dominio in modo significativo.