Perché MTA-STS è essenziale
SMTP è stato progettato nel 1982 senza cifratura. STARTTLS è stato aggiunto successivamente per cifrare le email in transito. Presenta però un difetto critico: è opportunistico. Un server mittente annuncia il supporto STARTTLS. Il server destinatario può accettare o ignorarlo. Nulla obbliga la connessione a restare cifrata.
Questo crea una finestra per gli attacchi di downgrade SMTP. Un attaccante si posiziona tra due server di posta, tramite BGP hijacking, DNS spoofing o intercettazione a livello di rete. Rimuove il comando STARTTLS dall'handshake SMTP. Il server mittente non vede alcuna opzione di cifratura e ricade sul testo in chiaro. L'email viaggia non cifrata, leggibile da chiunque lungo il percorso.
MTA-STS (RFC 8461) colma questa lacuna. Pubblica una policy che comunica ai server mittenti: "questo dominio richiede TLS. Se la cifratura fallisce, non ricadere sul testo in chiaro." Il server mittente deve stabilire una connessione TLS valida. In caso contrario, il messaggio viene messo in coda per un nuovo tentativo.
L'ostacolo al deployment: MTA-STS richiede l'hosting di un file di policy su https://mta-sts.captaindns.com/.well-known/mta-sts.txt tramite HTTPS con un certificato valido. Per molte organizzazioni, un server web dedicato per un singolo file di testo è sproporzionato. CaptainDNS elimina completamente questo ostacolo.
Cosa succede senza MTA-STS
Senza MTA-STS, il trasporto delle tue email si basa esclusivamente sul TLS opportunistico. Ecco cosa significa in pratica:
- Intercettazione in chiaro: qualsiasi attaccante a livello di rete può leggere le tue email rimuovendo STARTTLS. Non è teorico. Programmi di sorveglianza statali e intercettazioni a livello di ISP sono stati documentati.
- Nessuna verifica dal mittente: senza una policy pubblicata, i server mittenti non hanno modo di sapere che il tuo dominio richiede TLS. Effettueranno silenziosamente il downgrade in caso di problemi.
- Esposizione normativa: regolamenti come GDPR, HIPAA e PCI-DSS richiedono la cifratura dei dati sensibili in transito. Il solo TLS opportunistico non soddisfa questo standard perché può essere aggirato.
- Errori invisibili: senza TLS-RPT (il protocollo di reporting associato), non saprai mai che le email verso il tuo dominio sono state consegnate senza cifratura. Il problema è silenzioso.
Nel 2014, i ricercatori hanno documentato la soppressione su larga scala di STARTTLS da parte di intermediari di rete in diversi paesi. Il Transparency Report di Google ha successivamente confermato che una quota significativa delle email in entrata arriva ancora senza cifratura. MTA-STS è il protocollo progettato per porre fine a questa situazione.
MTA-STS abbinato a TLS-RPT ti offre sia enforcement che visibilità.
Come funziona MTA-STS nel dettaglio
MTA-STS utilizza due componenti che lavorano insieme:
1. Un record DNS TXT su _mta-sts.captaindns.com
Questo record pubblicizza la tua policy MTA-STS e contiene un ID di policy univoco. Quando l'ID cambia, i server mittenti sanno di dover recuperare una copia aggiornata della policy.
Esempio: v=STSv1; id=20260308120000
2. Un file di policy ospitato tramite HTTPS su https://mta-sts.captaindns.com/.well-known/mta-sts.txt
Questo file definisce tre elementi:
- mode:
testing(solo report) oenforce(rifiuto in caso di errore TLS) - mx: i pattern dei server di posta che devono corrispondere ai tuoi record MX
- max_age: per quanto tempo i server mittenti devono conservare la policy in cache (in secondi)
Esempio:
version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800
Quando un server mittente vuole consegnare un'email al tuo dominio, verifica il record TXT _mta-sts. Se presente, recupera il file di policy tramite HTTPS. Valida il certificato TLS dei tuoi server MX rispetto ai pattern della policy e procede solo se tutto corrisponde.
Trust on first use (TOFU): MTA-STS si basa sul fatto che il primo recupero della policy sia legittimo. Dopodiché, la policy in cache protegge dagli attacchi futuri per la durata del max_age. Per questo un max_age lungo (7+ giorni) è raccomandato in modalità enforce.
Come funziona
1. Crea la tua policy
Accedi e crea una nuova policy. Imposta il dominio, la modalità (testing o enforce), i pattern MX e la durata della cache (max_age).
2. Verifica la proprietà del dominio
Aggiungi il record TXT di verifica al tuo DNS. Lo rileviamo automaticamente in pochi secondi.
3. Aggiungi i record DNS di distribuzione
Due record DNS:
- CNAME: Punta
mta-sts.captaindns.comal nostro server di policy - TXT: Pubblicizza la tua policy MTA-STS su
_mta-sts.captaindns.com
La tua policy MTA-STS è attiva.
Compatibile con i principali provider email
MTA-STS funziona con qualsiasi provider email che utilizza record MX standard. I pattern MX nella tua policy devono corrispondere ai server di posta del tuo provider:
| Provider | Pattern MX |
|---|---|
| Microsoft 365 | *.mail.protection.outlook.com |
| Google Workspace | *.google.com e *.googlemail.com |
| Proton Mail | *.protonmail.ch |
| Zoho Mail | *.zoho.com |
| Self-hosted (Postfix, Exchange) | Il tuo hostname MX |
Quando crei la tua policy su CaptainDNS, inserisci i pattern MX corrispondenti al tuo provider. La dashboard li valida rispetto ai tuoi record MX attivi per evitare discrepanze.
Ospitato vs. autogestito: quale opzione scegliere?
| Criterio | Ospitato (CaptainDNS) | Autogestito |
|---|---|---|
| Configurazione server | Nessuna | Necessaria (Nginx, Apache, Caddy) |
| Certificato HTTPS | Automatico (Let's Encrypt) | Provisioning e rinnovo manuali |
| Aggiornamenti policy | Dashboard + rotazione automatica dell'ID | Modifica manuale dei file + aggiornamento DNS |
| Domini multipli | Fino a 5 per account | Una configurazione server per dominio |
| Disponibilità | Infrastruttura ridondante | Dipende dalla tua configurazione |
| Monitoraggio certificati | Integrato | A tuo carico |
| Costo | Gratuito | Costi di hosting del server |
Scegli ospitato se vuoi MTA-STS operativo in pochi minuti senza infrastruttura. Scegli autogestito se hai bisogno del pieno controllo sull'endpoint della policy o operi in un ambiente isolato.
Da testing a enforce: una strategia progressiva
Attivare MTA-STS direttamente in modalità enforce è rischioso. Se i pattern MX sono errati o un certificato TLS scade, le email legittime vengono rifiutate. L'approccio raccomandato è progressivo:
Fase 1: Deploy in modalità testing (da 1 a 2 settimane)
Imposta mode: testing nella tua policy. I server mittenti tenteranno il TLS e segnaleranno gli errori tramite TLS-RPT, ma consegneranno comunque le email anche se il TLS fallisce. Questo ti dà visibilità senza rischi.
Fase 2: Analizza i report TLS-RPT
Esamina i report per identificare i problemi: discrepanze nei certificati, pattern MX che non coprono tutti i server di posta o mittenti terzi con TLS non funzionante. Correggi ogni problema prima di procedere.
Fase 3: Passa alla modalità enforce
Quando i report mostrano zero errori per almeno una settimana, cambia la modalità in enforce e aumenta il max_age a 604800 (7 giorni) o più. Su CaptainDNS basta un clic nella dashboard. L'ID della policy ruota automaticamente.
Rollback di emergenza: se la modalità enforce blocca email legittime, torna immediatamente a testing. I server mittenti recupereranno la policy aggiornata e smetteranno di rifiutare entro pochi minuti (o al massimo entro la finestra del vecchio max_age).
MTA-STS e DANE: due approcci complementari
Esistono due protocolli per imporre la cifratura del trasporto email: MTA-STS e DANE (DNS-based Authentication of Named Entities). Risolvono lo stesso problema in modo diverso.
| MTA-STS | DANE | |
|---|---|---|
| Meccanismo di fiducia | HTTPS (Certificate Authority) | DNSSEC (catena crittografica) |
| Infrastruttura necessaria | Server web HTTPS (o servizio ospitato) | Zona firmata con DNSSEC |
| Modello di fiducia | Trust on first use (TOFU) | Nessun TOFU, crittografico fin dall'inizio |
| Supporto dei provider | Microsoft 365, Google Workspace, la maggior parte dei provider | Richiede DNSSEC sul tuo dominio |
| Complessità di deployment | Bassa (2 record DNS + policy ospitata) | Alta (DNSSEC + record TLSA) |
Se il tuo dominio non utilizza DNSSEC, MTA-STS è la tua unica opzione per la cifratura del trasporto forzata.
Se il tuo dominio utilizza DNSSEC, distribuire entrambi i protocolli offre la protezione più forte: DANE elimina il TOFU per i mittenti compatibili DNSSEC, mentre MTA-STS copre i mittenti che non supportano DANE.
Buone pratiche per il deployment MTA-STS
- Inizia in modalità testing: identifica i problemi di connettività TLS prima di passare a enforce.
- Configura TLS-RPT: ricevi report sugli errori di consegna TLS. Usa il nostro Generatore TLS-RPT.
- Valida i tuoi record MX: assicurati che i pattern MX nella tua policy corrispondano ai tuoi server di posta reali. Le discrepanze causano errori di consegna in modalità enforce.
- Monitora prima di applicare: analizza i report TLS-RPT per almeno una settimana con zero errori prima di passare a enforce.
- Usa un max_age lungo in modalità enforce: 604800 secondi (7 giorni) o più. Questo garantisce che i server mittenti conservino la policy in cache abbastanza a lungo da resistere agli attacchi di downgrade.
- Passa a enforce: quando i report TLS-RPT confermano che tutto funziona, attiva la modalità enforce per la protezione completa.
Strumenti complementari
| Strumento | Descrizione |
|---|---|
| Verifica MTA-STS | Valida la tua configurazione MTA-STS esistente |
| Generatore MTA-STS | Genera record e file di policy MTA-STS |
| Verifica Sintassi MTA-STS | Valida la sintassi MTA-STS offline |
| Generatore TLS-RPT | Configura il reporting TLS insieme a MTA-STS |
| Hosting BIMI | Ospita i tuoi loghi e certificati BIMI gratuitamente |
| Monitoraggio TLS-RPT | Monitora e analizza automaticamente i report TLS-RPT |
Guide e risorse
- MTA-STS: la guida completa per proteggere il trasporto delle tue email - Tutto quello che devi sapere sulla configurazione e sul deployment di MTA-STS.
- Da testing a enforce: strategia di distribuzione progressiva MTA-STS - Best practice per un rollout graduale di MTA-STS.
- Configurare MTA-STS per Microsoft 365 e Google Workspace - Configurazione passo passo per le due piattaforme email più diffuse.
- MTA-STS non funziona? Guida completa alla risoluzione dei problemi - Diagnostica e correggi gli errori di configurazione MTA-STS più comuni.
- MTA-STS vs DANE: quale protocollo scegliere per proteggere il trasporto email? - Confronto dettagliato per scegliere il protocollo giusto.