Il problema: STARTTLS è opportunistico
La maggior parte delle email tra server viene crittografata con STARTTLS, un'estensione SMTP che aggiorna la connessione da testo in chiaro a TLS. Tuttavia, STARTTLS ha un difetto fondamentale: è opportunistico. Se la negoziazione TLS fallisce per qualsiasi motivo — un attaccante che blocca il comando STARTTLS, un certificato scaduto, un errore di configurazione — la maggior parte dei server mittenti procede in chiaro, inviando le email senza crittografia. Un attaccante posizionato sulla rete (man-in-the-middle) può semplicemente intercettare il comando STARTTLS e forzare la connessione in chiaro, leggendo tutte le email in transito.
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) risolve questo problema permettendo al dominio destinatario di dichiarare: "le email per il mio dominio devono essere consegnate solo su connessioni TLS valide". Se il server mittente supporta MTA-STS e la negoziazione TLS fallisce, l'email non viene consegnata in chiaro — viene trattenuta e il mittente viene avvisato. Questo elimina la possibilità di downgrade attack.
Come funziona MTA-STS
MTA-STS richiede due componenti: un record DNS TXT su _mta-sts.dominio.com che segnala la presenza della policy e include un ID univoco (tipicamente un timestamp) che viene aggiornato ad ogni modifica, e un file di policy servito via HTTPS su https://mta-sts.dominio.com/.well-known/mta-sts.txt. Il fatto che la policy sia servita via HTTPS (non DNS) aggiunge un ulteriore livello di sicurezza: un attaccante dovrebbe compromettere anche il certificato HTTPS per falsificare la policy.
La policy specifica: la versione (STSv1), la modalità (testing o enforce), gli hostname dei mail server autorizzati (mx:), e la durata di cache della policy (max_age in secondi). La modalità testing segnala i problemi nei report TLS-RPT senza bloccare la consegna, permettendo di identificare e risolvere i problemi prima di passare a enforce.
MTA-STS e TLS-RPT: la coppia perfetta
MTA-STS senza TLS-RPT Lookup è come un antifurto senza allarme: blocca i problemi ma non ti avvisa. TLS-RPT (RFC 8460) fornisce report dettagliati sui fallimenti TLS, permettendoti di monitorare quante connessioni TLS vanno a buon fine, quante falliscono, e perché. Configura sempre TLS-RPT insieme a MTA-STS per avere visibilità completa sulla sicurezza delle connessioni email in ingresso.
Il nostro MTA-STS Lookup verifica entrambi i componenti: il record DNS e la policy HTTPS. Controlla che il record esista e abbia un ID valido, che il file di policy sia raggiungibile via HTTPS con un certificato valido, che i server MX nella policy corrispondano ai record MX effettivi del dominio, e che la modalità e il max_age siano configurati correttamente.
Implementazione step by step
Implementare MTA-STS richiede un server web HTTPS per servire la policy. Se già hai un sito web per il dominio, puoi creare un sottodominio mta-sts.tuodominio.com con un certificato SSL valido. In alternativa, servizi come Cloudflare Workers o GitHub Pages possono hostare il file di policy gratuitamente. Il certificato HTTPS deve essere valido e rilasciato da una CA pubblica — i certificati self-signed non sono accettati.
Inizia con mode: testing per raccogliere dati senza impatto sulla consegna. Monitora i report TLS-RPT per almeno 2 settimane. Verifica che il tuo certificato SSL Check sia valido e che i tuoi MX supportino TLS 1.2+. Una volta confermato che non ci sono problemi, passa a mode: enforce. Aggiorna l'ID nel record DNS ad ogni modifica della policy per forzare il refresh della cache dei server mittenti.