MTA-STS: la guida completa per proteggere il trasporto delle tue email
Di CaptainDNS
Pubblicato il 6 febbraio 2026
- MTA-STS (RFC 8461) forza la crittografia TLS sulle email in entrata e previene gli attacchi di tipo downgrade e man-in-the-middle su SMTP
- Due componenti da implementare: un record DNS TXT
_mta-stse un file di policy ospitato in HTTPS sumta-sts.captaindns.com/.well-known/mta-sts.txt - Tre modalità disponibili:
none(disattivato),testing(monitoraggio tramite TLS-RPT) edenforce(rifiuto se la crittografia TLS fallisce) - Inizia sempre con la modalità
testinge configura TLS-RPT per ricevere i report di errore prima di passare aenforce
Le tue email transitano ogni giorno tra server SMTP. Ma sai se questi scambi sono realmente crittografati? Di default, SMTP utilizza STARTTLS in modo opportunistico: se il server remoto non supporta la crittografia, il messaggio parte in chiaro. Un attaccante posizionato sulla rete può forzare questo comportamento e intercettare le tue comunicazioni.
MTA-STS (Mail Transfer Agent Strict Transport Security) risolve questo problema. Definito nella RFC 8461, questo standard consente a un dominio di dichiarare pubblicamente che richiede la crittografia TLS per ricevere email. I server mittenti che rispettano MTA-STS rifiuteranno di inviare un messaggio se la connessione TLS fallisce.
Questa guida ti spiega come funziona MTA-STS, quali sono i suoi componenti, come implementarlo passo dopo passo e perché è diventato un complemento indispensabile a DMARC, SPF e DKIM nello stack di sicurezza email.
Cos'è MTA-STS? (RFC 8461)
MTA-STS, Mail Transfer Agent Strict Transport Security, è un meccanismo che consente al proprietario di un dominio di pubblicare una policy di sicurezza del trasporto per i propri server di ricezione email (MX). Questa policy indica ai server mittenti che devono:
- Negoziare una connessione TLS valida prima di inviare un'email
- Verificare il certificato del server destinatario (hostname, catena di fiducia, scadenza)
- Rifiutare l'invio se la crittografia TLS fallisce (in modalità enforce)
Perché STARTTLS non basta?
STARTTLS è il meccanismo standard per crittografare le connessioni SMTP. Ma soffre di due falle fondamentali:
- Attacco downgrade: un attaccante può rimuovere il comando STARTTLS dalla risposta del server, forzando l'invio in chiaro. Il server mittente non sa che la crittografia era disponibile.
- Nessuna validazione del certificato: anche se STARTTLS viene negoziato, SMTP non verifica l'identità del server destinatario di default. Un server falso con un certificato auto-firmato può intercettare i messaggi.
MTA-STS corregge entrambi i problemi: la policy, recuperata via HTTPS (canale separato e autenticato), impone la crittografia TLS e la validazione del certificato.
I due componenti di MTA-STS
MTA-STS si basa su due elementi che funzionano insieme.
Il record DNS TXT _mta-sts
Un record TXT pubblicato nella tua zona DNS su _mta-sts.captaindns.com:
_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260205120000"
| Tag | Obbligatorio | Descrizione |
|---|---|---|
v | Sì | Versione del protocollo, sempre STSv1 |
id | Sì | Identificativo unico della policy, da modificare a ogni aggiornamento |
Il campo id serve come segnale di aggiornamento. Quando un server mittente rileva un cambiamento dell'id, riscarica la policy. Utilizza un timestamp (es.: 20260205120000) o un numero incrementale.
Il file di policy mta-sts.txt
Un file di testo ospitato all'URL esatto https://mta-sts.captaindns.com/.well-known/mta-sts.txt:
version: STSv1
mode: testing
mx: mail.captaindns.com
mx: backup.captaindns.com
max_age: 604800
| Direttiva | Obbligatorio | Descrizione |
|---|---|---|
version | Sì | Sempre STSv1 |
mode | Sì | none, testing o enforce |
mx | Sì | Pattern MX autorizzati (uno per riga, wildcards ammessi come *.captaindns.com) |
max_age | Sì | Durata della cache in secondi (max 31 557 600 = 1 anno) |
Hosting HTTPS obbligatorio
Il file di policy deve essere servito tramite HTTPS con un certificato TLS valido sul sottodominio mta-sts. È un elemento fondamentale della sicurezza di MTA-STS: a differenza del DNS (che può essere falsificato senza DNSSEC), HTTPS garantisce l'autenticità della policy tramite la validazione del certificato.
Le 3 modalità MTA-STS: testing, enforce, none
Modalità testing: monitorare senza bloccare
mode: testing
In modalità testing, i server mittenti tentano di negoziare TLS e segnalano gli errori tramite TLS-RPT (RFC 8460), ma consegnano comunque il messaggio se la crittografia fallisce. È la modalità di avvio consigliata.
Modalità enforce: crittografia o rifiuto
mode: enforce
In modalità enforce, i server mittenti rifiutano di consegnare il messaggio se la connessione TLS fallisce o se il certificato non è valido. È la modalità target per una protezione completa.
Modalità none: disattivazione
mode: none
La modalità none indica che MTA-STS è disattivato. Utilizzala per disattivare correttamente una policy esistente (i server mittenti che hanno una policy in cache devono attendere la scadenza del max_age).
Quale valore max_age scegliere?
| Fase di deployment | max_age consigliato | Durata |
|---|---|---|
| Inizio (testing) | 86 400 | 1 giorno |
| Stabilizzazione | 604 800 | 7 giorni |
| Produzione (enforce) | 2 592 000 a 31 557 600 | 30 giorni a 1 anno |
Un max_age breve in fase di test consente di correggere rapidamente gli errori. Una volta in enforce, un max_age lungo riduce la frequenza di riscaricamento e rafforza la protezione contro gli attacchi DNS temporanei.
Implementare MTA-STS passo dopo passo
Passo 1: Verificare i tuoi MX e certificati TLS
Prima di implementare MTA-STS, assicurati che tutti i tuoi server MX dispongano di un certificato TLS valido (TLS 1.2 minimo) con un hostname corrispondente. Un certificato scaduto o mal configurato causerà rifiuti in modalità enforce.
Passo 2: Creare il file di policy
Crea il file mta-sts.txt con i tuoi server MX. Puoi utilizzare il generatore MTA-STS CaptainDNS per crearlo automaticamente:
version: STSv1
mode: testing
mx: mail.captaindns.com
mx: backup.captaindns.com
max_age: 86400
Passo 3: Ospitare la policy all'URL .well-known
Pubblica il file all'URL esatto:
https://mta-sts.captaindns.com/.well-known/mta-sts.txt
Il sottodominio mta-sts deve risolvere verso un server web HTTPS con un certificato valido. Opzioni di hosting comuni:
- Cloudflare Pages / Cloudflare Workers: gratuito, HTTPS automatico
- GitHub Pages: gratuito, certificato Let's Encrypt
- Azure Static Web Apps: integrazione Microsoft 365
- Server web esistente: Apache, Nginx con Let's Encrypt
Il Content-Type della risposta deve essere text/plain.
Passo 4: Pubblicare il record DNS TXT
Aggiungi nella tua zona DNS:
_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260205120000"
Passo 5: Validare la tua configurazione
Utilizza il verificatore MTA-STS CaptainDNS per controllare che tutto sia in ordine: record DNS, file di policy, certificato TLS, corrispondenza MX.
MTA-STS vs DANE vs STARTTLS
Tre meccanismi coesistono per proteggere il trasporto SMTP. Ecco le loro differenze:
| Criterio | Solo STARTTLS | MTA-STS | DANE |
|---|---|---|---|
| Protezione | Crittografia opportunistica | Crittografia obbligatoria | Crittografia obbligatoria |
| Validazione del certificato | No | Sì (tramite HTTPS/CA) | Sì (tramite DNSSEC/TLSA) |
| Resiste agli attacchi downgrade | No | Sì | Sì |
| Prerequisiti | Nessuno | HTTPS sul sottodominio mta-sts | DNSSEC sulla zona DNS |
| Complessità di deployment | Bassa | Media | Elevata |
| Adozione | Universale | In crescita (Google, Microsoft) | Limitata (prerequisito DNSSEC) |
| RFC | RFC 3207 | RFC 8461 | RFC 7671 |
In pratica: MTA-STS è la scelta pragmatica. DANE offre una sicurezza teoricamente superiore (nessuna dipendenza dalle CA) ma richiede DNSSEC, ancora poco diffuso. I due approcci sono complementari e possono coesistere.
TLS-RPT: monitorare il tuo deployment MTA-STS
TLS-RPT (SMTP TLS Reporting, RFC 8460) è il compagno indispensabile di MTA-STS. Consente di ricevere report JSON quotidiani che descrivono i successi e gli errori di negoziazione TLS verso il tuo dominio.
Per attivare TLS-RPT, pubblica un record DNS:
_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"
Questi report sono essenziali in modalità testing: ti permettono di identificare i problemi (certificati scaduti, MX non coperti, server incompatibili con TLS 1.2) prima di passare in modalità enforce.
Piano d'azione consigliato
- Verifica i tuoi certificati TLS: tutti i tuoi server MX devono avere un certificato valido con TLS 1.2+
- Implementa in modalità testing: crea la policy e il record DNS con
mode: testingemax_age: 86400 - Attiva TLS-RPT: pubblica il record
_smtp._tlsper ricevere i report di errore - Monitora per 2-4 settimane: analizza i report TLS-RPT e correggi i problemi identificati
- Passa in modalità enforce: una volta che i report sono puliti, cambia
mode: enforcee aumenta ilmax_age
Verifica subito la tua configurazione MTA-STS: Utilizza il nostro verificatore MTA-STS per analizzare il tuo dominio in pochi secondi.
FAQ
Cos'è MTA-STS e perché ne ho bisogno?
MTA-STS (Mail Transfer Agent Strict Transport Security) è uno standard internet (RFC 8461) che consente a un dominio di dichiarare che richiede la crittografia TLS per ricevere email. Senza MTA-STS, le connessioni SMTP utilizzano STARTTLS in modo opportunistico, rendendole vulnerabili agli attacchi downgrade e man-in-the-middle. MTA-STS garantisce che le tue email in entrata siano sempre crittografate in transito.
MTA-STS è obbligatorio per la sicurezza email?
MTA-STS non è ancora obbligatorio dal punto di vista normativo, ma è fortemente consigliato. Google e Microsoft lo hanno attivato sui propri domini e verificano la presenza di MTA-STS sui domini che contattano. Per le organizzazioni soggette a requisiti di conformità (GDPR, PCI-DSS), MTA-STS rafforza la postura di sicurezza del trasporto email.
Qual è la differenza tra le modalità testing ed enforce?
In modalità testing, i server mittenti tentano la connessione TLS e segnalano gli errori tramite TLS-RPT, ma consegnano comunque il messaggio. In modalità enforce, i server rifiutano di consegnare il messaggio se il TLS fallisce. Inizia sempre con testing per identificare i problemi prima di passare a enforce.
Come si confronta MTA-STS con DANE?
MTA-STS utilizza HTTPS e le autorità di certificazione (CA) per autenticare la policy, mentre DANE utilizza DNSSEC e i record TLSA. DANE offre una sicurezza superiore (nessuna dipendenza dalle CA) ma richiede DNSSEC, ancora poco diffuso. MTA-STS è più semplice da implementare e più ampiamente adottato. I due meccanismi sono complementari.
È necessario configurare anche TLS-RPT con MTA-STS?
Sì, fortemente consigliato. TLS-RPT (RFC 8460) ti invia report quotidiani sui successi e gli errori di negoziazione TLS verso il tuo dominio. Senza TLS-RPT, non hai alcuna visibilità sui problemi del tuo deployment MTA-STS. Pubblica un record _smtp._tls con un indirizzo di ricezione.
Come configurare MTA-STS per Microsoft 365?
Per Microsoft 365, utilizza il pattern MX *.mail.protection.outlook.com nella tua policy MTA-STS. Ospita il file di policy su Azure Static Web Apps, Cloudflare Pages o qualsiasi server HTTPS. Microsoft supporta MTA-STS in invio (verifica la policy dei tuoi destinatari) e in ricezione (puoi pubblicare una policy per il tuo dominio M365).
Come configurare MTA-STS per Google Workspace?
Per Google Workspace, includi i seguenti pattern MX nella tua policy: aspmx.l.google.com, *.google.com e *.googlemail.com. Google verifica attivamente le policy MTA-STS dei domini che contatta e pubblica report TLS-RPT. Ospita il file di policy su un server HTTPS con un certificato valido per il sottodominio mta-sts.
Cosa succede se il file di policy non è accessibile?
Se il file mta-sts.txt non è accessibile (errore HTTP, timeout, certificato non valido), il server mittente non può applicare la policy. In assenza di una policy in cache, torna al comportamento STARTTLS opportunistico standard. Se una policy è in cache (non scaduta secondo il max_age), continua ad applicarsi. Per questo motivo un max_age sufficientemente lungo protegge contro le interruzioni temporanee.
Glossario
- MTA-STS: Mail Transfer Agent Strict Transport Security. Standard RFC 8461 che impone la crittografia TLS per la ricezione delle email.
- STARTTLS: Estensione SMTP che consente di passare da una connessione in chiaro a una connessione crittografata TLS. Opportunistica di default.
- TLS-RPT: SMTP TLS Reporting (RFC 8460). Meccanismo di report sui successi e gli errori di negoziazione TLS.
- DANE: DNS-based Authentication of Named Entities (RFC 7671). Utilizza DNSSEC e i record TLSA per validare i certificati TLS.
- Attacco downgrade: Tecnica in cui un attaccante forza una connessione a utilizzare un protocollo meno sicuro (es.: rimuovere STARTTLS per forzare l'invio in chiaro).
- max_age: Direttiva della policy MTA-STS che indica la durata del caching in secondi.
Guide MTA-STS correlate
- Configurare MTA-STS per Microsoft 365 e Google Workspace (in arrivo)
- MTA-STS non funziona? Guida completa alla risoluzione dei problemi (in arrivo)
