• 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 endpoint HTTPS all’indirizzo:

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

Se utilizzate Exchange Online, la configurazione è semplificata: potete utilizzare gli stessi parametri pubblicati da Microsoft, poiché tutti i tenant condividono lo stesso certificato e l’infrastruttura di ricezione. L’unico elemento realmente distintivo è il record MX, che deve puntare a *.mail.protection.outlook.com o in alternativa a vostrodominio.mail.protection.outlook.com.

Potete iniziare in modalità testing per validare la configurazione senza impatti sul flusso di posta, e successivamente passare a enforce per imporre l’uso obbligatorio di TLS. Questo approccio riduce il rischio di interruzioni e vi consente di verificare che tutto sia coerente, anche tramite strumenti di validazione esterni.

È importante chiarire che Exchange Online non ospita la policy MTA-STS per vostro conto: dovete pubblicarla utilizzando un servizio a vostra scelta, ad esempio Azure Web App o qualsiasi altro hosting, assicurandovi che l’endpoint sia raggiungibile in HTTPS e protetto da un certificato valido per il sottodominio mta-sts.

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.

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.