MTA-STS: cos'è e quante aziende italiane lo adottano

Se gestisci una rrassicela o invii transazionali dai tuoi server, probabilmente conosci SPF, DKIM e DMARC. Ma c'è un quarto strato di sicurezza che molti ignorano ancora: MTA-STS (Mail Transfer Agent Strict Transport Security). A differenza dei primi tre, che autenticano il messaggio, MTA-STS protegge il canale di trasporto fra il tuo server e il server del destinatario, obbligando il trasferimento criptato in TLS e rifiutando le connessioni con certificati non validi. Questo articolo spiega cosa sia MTA-STS, come funziona, e quali dati abbiamo su quante aziende italiane l'hanno già implementato.

Che cosa è MTA-STS e come funziona?

MTA-STS è uno standard aperto (RFC 8461) che permette ai titolari di dominio di dichiarare un requisito di sicurezza ai propri server di posta (MX record). Se SPF verifica l'IP mittente, DKIM firma il messaggio e DMARC è la politica di azione, MTA-STS protegge il tunnel TLS fra i server.

In pratica, quando il server di posta di un mittente si connette all'MX-server del destinatario, MTA-STS richiede:

• Una connessione TLS crittografata (obbligatorio, non opzionale)
• Un certificato TLS valido con il nome dominio corretto
• Niente fallback su SMTP in chiaro (STARTTLS richiede successo totale)

Tecnicamente, MTA-STS funziona in due passaggi:

1. Il server mittente interroga il DNS con una query SRV su _mta-sts._tcp.dominio.it per trovare la versione della politica.
2. Poi carica la politica vera e propria tramite HTTPS da .well-known/mta-sts.txt e la cache per un periodo (tipicamente 7 giorni).

Questo meccanismo rende molto difficile un attacco di downgrade: nemmeno un attaccante che controlla il DNS locale può forzare una connessione non criptata.

Perché MTA-STS è importante per la deliverability?

Anche se la tua email è perfettamente autenticata con SPF/DKIM/DMARC e supera tutti i filtri antispam, potrebbe comunque essere intercettata o inoltrata su un canale non protetto se il destinatario (Gmail, Libero, Virgilio, TIM, Aruba, Outlook, Yahoo) non lo impedisce. MTA-STS capovolge la logica: sei tu a dichiarare che la crittografia è obbligatoria, e rifiuti le mail che non rispettano questo vincolo.

I vantaggi sono concreti:

• Niente furto di credenziali — un attaccante che intercetta il traffico SMTP non può leggere il corpo del messaggio.
• Niente sostituzione di mittente — anche se un attaccante controlla un router locale, non può inginocchiare un server MX a TLS degradato.
• Segnale di reputazione — i server riceventi vedono che il tuo dominio è serio sulla sicurezza, il che aumenta il trust.

Per le aziende italiane che inviano email con dati personali (come è quasi sempre nel marketing e nelle transazioni), MTA-STS è anche una conformità alle misure tecniche richieste dalla Garante per la protezione dei dati personali (l'autorità italiana di privacy).

Adozione di MTA-STS in Italia — cosa dicono i dati

Il modo migliore per capire quante aziende e provider utilizzano MTA-STS è consultare il dataset settimanale di /email-stats/, che scansiona i top 1 milione di domini (incluso il MX record, SPF, DKIM, DMARC e, appunto, MTA-STS). I dati mostrano:

• I grandi provider globali (Google, Microsoft, Yahoo) supportano già MTA-STS e pianificano di renderlo obbligatorio nei prossimi anni, come è accaduto con DMARC nel 2024.
• I provider locali italiani (Libero, Virgilio, TIM/Alice, Aruba, Tiscali) supportano MTA-STS ma lo adottano più lentamente.
• Tra i domini proprietari (aziende che inviano da dominio aziendale, non da ESP), l'adozione è più alta, soprattutto in grandi aziende ed e-commerce.

La curva di adozione accelera con ogni annuncio di obbligatorietà da parte dei grandi player. Consigliamo di visitare /email-stats/ per le cifre più aggiornate e filtrare per paese se disponibile.

Come configurare MTA-STS sul tuo dominio

Se usi un dominio proprietario (es. tuodominio.it) e vuoi implementare MTA-STS, ecco i passi:

1. Crea un host HTTPS per servire la politica.

   Generalmente un sottodominio mta-sts.tuodominio.it con certificato TLS valido, o un path sul tuo dominio principale. Il certificato deve avere il FQDN corretto nel Common Name / Subject Alternative Name.

2. Pubblica la politica all'indirizzo https://mta-sts.tuodominio.it/.well-known/mta-sts.txt.

   Crea un file di testo con contenuto simile a:

   version: STSv1 mode: testing mx: mail.tuodominio.it mx: mail2.tuodominio.it max_age: 604800

   Spiegazione dei campi:

   • version: STSv1 — versione dello standard
   • mode: testing|enforce|none — testing = report senza rifiuto, enforce = rifiuta se TLS fallisce, none = disabilita
   • mx: — elenca i tuoi MX record autorizzati (uno per riga)
   • max_age: — secondi per cui cacheare la politica (604800 = 7 giorni)
3. Aggiungi la SRV-record in DNS.

   Inserisci nel tuo DNS un record SRV come:

   _mta-sts._tcp.tuodominio.it. 86400 IN SRV 10 10 443 mta-sts.tuodominio.it.

   Questo record dice ai server riceventi dove trovare la tua politica.

4. Monitora e testa prima di passare a mode: enforce.

   Verifica che il tuo server HTTPS sia raggiungibile, che il certificato sia valido, e che gli MX record siano corretti. Usa un tool come check.live-direct-marketing.online per fare un test di deliverability reale.

Per chi usa un ESP (MailUp, 4Dem, GetResponse, Brevo, Mailchimp, ecc.): molti provider non offrono configurazione diretta di MTA-STS per il dominio personalizzato. Contatta il supporto ESP e chiedi se supporta MTA-STS e come configurarlo (potrebbe richiedere CNAME per la politica).

MTA-STS, SPF, DKIM e DMARC — quali sono le differenze?

Una domanda frequente: come si relazionano MTA-STS, SPF, DKIM e DMARC? Sono livelli diversi della sicurezza email:

• SPF (Sender Policy Framework) — un record DNS che elenca gli IP autorizzati a inviare da un dominio. L'MX-server del destinatario fa una DNS lookup e controlla se l'IP del mittente è in lista. È facile da spoofizzare se usato male, ma è il primo livello.
• DKIM (DomainKeys Identified Mail) — una firma crittografica che il tuo server aggiunge a ogni email. L'MX-server legge la firma con la chiave pubblica (anch'essa in DNS) e verifica che il messaggio non sia stato alterato. È il secondo livello e il più robusto.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) — una politica che dice al server ricevente cosa fare se SPF/DKIM falliscono (reject, quarantine, none), e dove mandare i report (mail di notifica). È il terzo livello di controllo.
• MTA-STS — protegge il trasporto, non il messaggio. Richiede che la connessione fra i due MX-server sia in TLS e che il certificato sia valido. È il quarto livello, orthogonale ai primi tre.

In pratica: SPF/DKIM/DMARC dicono “che cosa c'è dentro il messaggio e se è autentico”, mentre MTA-STS dice “il canale fra i server deve essere criptato”. Servono tutti e quattro per una deliverability e sicurezza completa.