Cos'è MTA-STS
MTA-STS (Mail Transfer Agent Strict Transport Security) è uno standard definito in RFC 8461 che obbliga gli MTA mittenti a usare connessioni TLS verificate verso un dominio destinatario. Risolve la vulnerabilità del classico STARTTLS opportunistico, che può essere downgrade-attacked da intermediari malevoli, garantendo cifratura end-to-end e validazione certificato.
Componenti necessari
L'implementazione MTA-STS richiede tre elementi: record DNS TXT su _mta-sts.example.com che annuncia la policy, file di policy servito via HTTPS su mta-sts.example.com/.well-known/mta-sts.txt, e configurazione TLS valida sui server MX con certificati riconosciuti. Tutti tre devono essere coerenti.
Record DNS TXT
Il record TXT MTA-STS ha formato: v=STSv1; id=20260101120000. Il valore id è un'identificatore univoco (tipicamente timestamp) che cambia ogni volta che si modifica la policy. I resolver MTA-STS controllano il record per rilevare modifiche e ricaricare la policy.
File policy mta-sts.txt
Il file di policy si pubblica su https://mta-sts.example.com/.well-known/mta-sts.txt e contiene: version (STSv1), mode (none/testing/enforce), mx (uno o più server MX accettati, con wildcard), max_age (TTL in secondi, tipicamente 86400 = 24h). Esempio: version: STSv1\nmode: enforce\nmx: mail.example.com\nmax_age: 86400.
Modi di operazione
I tre mode hanno effetti diversi. none disabilita la policy (utile per rimuovere senza eliminare il record). testing permette di monitorare violazioni senza bloccare email: errori vengono solo riportati via TLS-RPT. enforce rifiuta consegne se TLS valido non è possibile (downgrade attack o cert mismatch).
Hosting HTTPS richiesto
Il subdomain mta-sts.example.com deve essere servito via HTTPS con certificato valido. Si può usare hosting dedicato, CDN (Cloudflare, Fastly), o configurare nginx/Apache sullo stesso server web esistente. Importante: certificato valido (Let's Encrypt o commerciale), no self-signed.
Percorso di implementazione
Fase 1: pubblicare DNS e file policy in modalità testing per 30 giorni. Monitorare report TLS-RPT (necessario configurare anche TLS-RPT). Fase 2: identificare e correggere problemi sui server MX (rinnovi certificati, configurazioni ciphers). Fase 3: switch a enforce dopo conferma assenza errori. Fase 4: monitoring continuo.
Verifica e validazione
Strumenti di validazione: aykira.com/mta-sts-validator, mxtoolbox.com, hardenize.com (controllo completo policy). Verificare anche con curl https://mta-sts.example.com/.well-known/mta-sts.txt che il file sia accessibile. Errori di certificato sul subdomain mta-sts invalidano completamente la policy.
Hai bisogno di aiuto?
Se hai problemi di blacklist o deliverability email, il team di G Tech Group può aiutarti. Contattaci tramite il modulo di contatto.