DANE e MTA-STS
Cifratura SMTP forzata, senza compromessi

SMTP è nato senza cifratura, e si vede

Il protocollo SMTP risale al 1982. La cifratura del trasporto è stata aggiunta solo nel 2002 con l'estensione StartTLS, e in modalità opportunistica: due server di posta che si parlano negoziano la cifratura solo se entrambi la dichiarano disponibile. Se la negoziazione fallisce, o se un attaccante in mezzo rimuove la riga STARTTLS dalla risposta del server, i due MTA proseguono in chiaro senza fare rumore.

Questo è il downgrade attack: la posta viene consegnata, l'utente non riceve alcun avviso, ma il contenuto del messaggio — password reset, fatture, contratti, dati riservati — transita leggibile su Internet. La posta certificata (PEC) ha lo stesso problema sul tratto SMTP−to−SMTP fuori dal circuito PEC, e qualsiasi flusso email aziendale ordinario è esposto.

SPF, DKIM e DMARC risolvono un problema diverso: dimostrano che il mittente è autorizzato e che il messaggio non è stato alterato. Non impediscono che il messaggio venga letto in chiaro durante il transito. Servono protocolli aggiuntivi che rendano la cifratura obbligatoria e verificabile: MTA-STS e DANE.

MTA-STS: la policy via HTTPS

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) è la risposta pratica al problema. Il dominio pubblica una policy che dice ai server mittenti: «quando mi mandi posta, devi usare TLS con uno di questi mail server e con un certificato valido». La policy è composta da tre elementi:

• 1Record TXT — _mta-sts.dominio.tld dichiara la versione della policy e cambia ogni volta che la policy viene aggiornata, in modo che i server mittenti sappiano quando rileggere il file.
• 2File di policy su HTTPS — pubblicato su https://mta-sts.dominio.tld/.well-known/mta-sts.txt, elenca i mail server autorizzati e il livello di enforcement (none, testing, enforce). La validazione della policy si appoggia alla PKI HTTPS pubblica: nessun DNSSEC richiesto.
• 3TLS-RPT (RFC 8460)— record TXT dedicato che indica un indirizzo email a cui i server mittenti spediscono report giornalieri sui tentativi di consegna falliti per problemi TLS. Senza TLS-RPT si sta cieca, e mettere MTA-STS in enforce è rischioso.

Il deployment standard è: si parte in modalità testing, si raccolgono report TLS-RPT per due o tre settimane, si correggono eventuali mismatch tra record DNS e certificati, e solo allora si passa a enforce. In enforce, i server mittenti che rispettano lo standard rifiutano la consegna se la cifratura non si può stabilire o se il certificato non è valido per uno dei mail server dichiarati.

DANE per SMTP: l'ancoraggio nel DNS

DANE (DNS-based Authentication of Named Entities, RFC 7672 per SMTP) affronta lo stesso problema da un'angolazione diversa. Invece di pubblicare la policy via HTTPS, DANE pubblica un record DNS di tipo TLSA che lega direttamente il certificato (o la sua chiave pubblica) al nome del mail server. Quando un MTA mittente sta per aprire una connessione TLS verso il destinatario, recupera il record TLSA e verifica che il certificato presentato corrisponda.

Il punto critico: il record TLSA deve essere firmato con DNSSEC, altrimenti chiunque controlli un resolver intermedio potrebbe alterarlo. DANE per SMTP richiede DNSSEC end-to-endsul dominio del destinatario e sul dominio dei suoi mail server (record MX). È il principale freno all'adozione: in Italia DNSSEC è ancora poco diffuso e non tutti i registrar lo supportano senza attivazione manuale.

Quando è in piedi, DANE è tecnicamente più robusto di MTA-STS: non si appoggia alla PKI HTTPS pubblica (che ha avuto la sua dose di compromessi storici), e non richiede al server mittente di fare una richiesta HTTPS separata per recuperare la policy. Tutto avviene sul piano DNS.

Cosa cambia: Exchange Online attiva DANE outbound

Microsoft ha portato in general availability il supporto a SMTP DANE con DNSSEC in uscita da Exchange Online a inizio 2025. In pratica: tutti i tenant Microsoft 365 che inviano posta verso domini esterni che hanno pubblicato record TLSA validi vedono la cifratura imposta e verificata da Microsoft. Se il certificato del destinatario non corrisponde al record TLSA, la consegna fallisce con un NDR esplicito invece di proseguire in chiaro.

Per il momento il supporto inbound(cioè la possibilità per un tenant Exchange Online di pubblicare un proprio record TLSA per i mail server Microsoft) è ancora in roadmap. MTA-STS è invece supportato in entrambe le direzioni da diversi anni: i tenant Microsoft 365 possono pubblicare la propria policy MTA-STS e i mail server Microsoft rispettano le policy MTA-STS dei destinatari.

Google Workspace ha un supporto analogo a MTA-STS in entrambe le direzioni e supporta DANE outbound. Il risultato concreto è che la maggior parte del traffico email mondiale oggi rispetta MTA-STS e DANE in uscita: pubblicare almeno una policy MTA-STS sul proprio dominio non è più un esercizio teorico, è una protezione reale.

Quale percorso ha senso per la tua azienda

Per la quasi totalità delle PMI italiane, l'ordine pratico è questo:

• Prima cosa: SPF, DKIM e DMARC— sono il prerequisito di tutto il resto. Senza un'autenticazione email correttamente configurata, MTA-STS e DANE risolvono solo metà del problema. Puoi verificarli con il nostro strumento DIG online o farli gestire dal nostro servizio di sicurezza email.
• Seconda cosa: MTA-STS con TLS-RPT— bassa complessità, alto ritorno. Si pubblica un record TXT, un file di policy HTTPS e un record TLS-RPT. Si parte in testing per due o tre settimane e si passa a enforce quando i report sono puliti.
• Terza cosa: valutare DANE— ha senso se il dominio già usa DNSSEC o se l'organizzazione ha requisiti di sicurezza elevati (PA, sanità, finanza, supply chain di soggetti NIS2). Per molti domini il primo passo è attivare DNSSEC tramite il proprio servizio di gestione DNS.
• In parallelo: un email security gateway— MTA-STS e DANE proteggono il trasporto, ma non il contenuto. Phishing, BEC e allegati malevoli passano comunque attraverso connessioni cifrate. Per quello serve un email security gateway.

Errori da evitare

Tre errori ricorrenti che vediamo regolarmente sui domini italiani:

• Pubblicare MTA-STS direttamente in enforce senza la fase di testing e senza TLS-RPT. Risultato: se il certificato di un mail server scade o cambia, le email in arrivo da Gmail e Microsoft 365 vengono rifiutate per giorni prima che qualcuno se ne accorga.
• Pubblicare record TLSA senza DNSSEC attivo. Il record c'è, ma non viene considerato dai server mittenti perché non è firmato. La protezione è solo apparente.
• Dimenticare di aggiornare il record TLSA al rinnovo del certificato. Se il TLSA punta all'hash del certificato e il certificato cambia, le connessioni TLS vengono rifiutate. Vanno pianificati pre-pubblicazione e rotazione del nuovo record TLSA prima del rinnovo.

Come AtWorkStudio gestisce il deployment

Il nostro stack email standard sui domini gestiti include SPF, DKIM, DMARC, MTA-STS, TLS-RPT e BIMI. Per i clienti che vogliono spingersi a DANE configuriamo prima DNSSEC (compatibilmente con il registrar e il provider DNS), pubblichiamo TLSA in modalità 2 1 1 con pre-pubblicazione del nuovo record prima del rinnovo del certificato, e attiviamo monitoring continuo dei report TLS-RPT.

AtWorkStudio opera da Piacenza dal 2000. Siamo certificati ISO/IEC 27001, 27017, 27018 e ISO 9001, con qualificazione ACN (Agenzia per la Cybersicurezza Nazionale) per i servizi cloud. Siamo membri di Clusit (Associazione Italiana per la Sicurezza Informatica) e associati a Confindustria Piacenza nel cluster RICT.

Domande frequenti