Vai al contenuto principale

MTA-STS vs DANE: quale protocollo scegliere per proteggere il trasporto email?

Di CaptainDNS
Pubblicato il 10 marzo 2026

Schema comparativo dei protocolli MTA-STS e DANE per la sicurezza del trasporto email
TL;DR
  • MTA-STS (RFC 8461) pubblica una policy di crittografia obbligatoria via HTTPS. Funziona senza DNSSEC, ma la prima connessione resta vulnerabile (TOFU)
  • DANE/TLSA (RFC 7672) àncora il certificato TLS nel DNS firmato da DNSSEC. Nessun TOFU, ma DNSSEC è obbligatorio su tutta la catena
  • I due protocolli sono complementari: MTA-STS copre i domini senza DNSSEC, DANE elimina il TOFU per quelli che lo hanno
  • Ospitate la vostra policy MTA-STS gratuitamente con CaptainDNS: bastano due record DNS

La crittografia SMTP opportunistica (STARTTLS) protegge la maggior parte delle email in transito. Ma «opportunistica» significa che un attaccante di rete può rimuoverla senza che nessuno se ne accorga. Gli attacchi di downgrade SMTP sfruttano questa debolezza per intercettare messaggi in chiaro.

Due protocolli rispondono a questo problema: MTA-STS (RFC 8461) e DANE/TLSA (RFC 7672). Entrambi impongono la crittografia TLS obbligatoria tra server email. Ma i loro meccanismi di fiducia, i prerequisiti e la loro adozione differiscono.

Questo articolo confronta MTA-STS e DANE criterio per criterio. Identifica i casi d'uso di ciascuno e vi guida verso la migliore strategia in base alla vostra infrastruttura. Se gestite domini email, che sia con un provider cloud o con i vostri server MX, questo confronto è per voi.

Come funzionano MTA-STS e DANE?

I due protocolli condividono lo stesso obiettivo: impedire a un server mittente di inviare un'email in chiaro quando il server destinatario supporta TLS. Ma utilizzano canali di fiducia diversi.

MTA-STS: una policy pubblicata via HTTPS

MTA-STS si basa su due elementi:

  1. Un record TXT DNS _mta-sts.captaindns.com che segnala l'esistenza della policy e contiene un identificatore di versione
  2. Un file di testo ospitato in HTTPS su https://mta-sts.captaindns.com/.well-known/mta-sts.txt che descrive la policy: server MX autorizzati, modalità (testing o enforce), durata della cache (max_age)

Quando un server mittente (come Gmail o Outlook) vuole inviare un'email verso il vostro dominio:

  1. Interroga il DNS per _mta-sts.captaindns.com
  2. Scarica la policy via HTTPS (canale autenticato dal certificato web)
  3. Verifica che il server MX corrisponda alla policy
  4. In modalità enforce, rifiuta di inviare in chiaro o verso un MX non elencato

Il canale HTTPS è la chiave: anche se un attaccante manipola il traffico SMTP, non può falsificare il certificato HTTPS del dominio. La policy resta affidabile.

Limitazione: il TOFU (Trust On First Use). La prima volta che un server mittente contatta il vostro dominio, non ha ancora una policy in cache. Se un attaccante blocca questa prima richiesta HTTPS, il server mittente non saprà che MTA-STS è attivato. Le connessioni successive sono protette grazie alla cache (valida fino a max_age).

DANE/TLSA: il certificato ancorato nel DNS firmato

DANE funziona in modo diverso. Pubblica l'impronta (hash) del certificato TLS del server MX direttamente in un record TLSA del DNS:

_25._tcp.mx.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...

Il server mittente:

  1. Interroga il DNS per i record MX di captaindns.com
  2. Recupera il record TLSA associato al server MX
  3. Verifica la firma DNSSEC della risposta (obbligatoria)
  4. Confronta il certificato TLS presentato dal server MX con l'hash TLSA
  5. Se tutto corrisponde, la connessione viene stabilita. Altrimenti, l'email non viene inviata

Vantaggio: nessun TOFU. Ogni connessione è verificata individualmente tramite il DNS firmato. Un attaccante non può né falsificare il record TLSA (protetto da DNSSEC) né presentare un certificato falso (l'hash non corrisponderebbe).

Limitazione: DNSSEC obbligatorio. Tutta la catena DNS, dalla radice fino alla vostra zona, deve essere firmata. Se il vostro registrar o provider DNS non supporta DNSSEC, DANE è inutilizzabile.

Diagramma comparativo dei flussi di verifica MTA-STS e DANE durante l'invio di un'email

Confronto tecnico dettagliato

CriterioMTA-STS (RFC 8461)DANE/TLSA (RFC 7672)
Canale di fiduciaHTTPS (PKI web)DNSSEC
Protezione 1ª connessioneNo (TOFU)Sì
Dipendenza DNSSECNoObbligatoria
Validazione certificatoHostname match (CN/SAN)Hash del certificato (TLSA)
Modalità testing nativaSì (mode: testing)No
Report di erroreVia TLS-RPT (RFC 8460)Via TLS-RPT (RFC 8460)
Complessità distribuzioneBassa (2 record DNS + file HTTPS)Elevata (DNSSEC + record TLSA + rotazione)
RevocaModificare la policy (ritardo = max_age)Modificare il record TLSA (ritardo = TTL)
Adozione mittentiGmail, Outlook, Yahoo, Proton MailPostfix, Exim, alcuni operatori EU
Standard web richiestoSì (certificato HTTPS valido)No

Cosa mostra questa tabella

MTA-STS vince sull'accessibilità: nessun DNSSEC richiesto, modalità testing integrata, ampia adozione da parte dei grandi provider. È il protocollo che la maggior parte dei domini può implementare immediatamente.

DANE vince sulla sicurezza: nessun TOFU, verifica crittografica diretta, nessuna dipendenza da un'autorità di certificazione web. Ma richiede DNSSEC, che resta un ostacolo importante.

Quale protocollo scegliere in base alla vostra situazione?

Non esiste una risposta universale. La scelta dipende dalla vostra infrastruttura DNS e dai vostri vincoli.

Caso 1: il vostro registrar non supporta DNSSEC

Raccomandazione: solo MTA-STS.

È la situazione più comune. La maggior parte dei registrar generalisti non propone DNSSEC o lo rende difficile da configurare. MTA-STS è la vostra unica opzione, ed è efficace: Gmail, Outlook e Yahoo verificano e rispettano le policy MTA-STS.

Caso 2: avete DNSSEC attivato

Raccomandazione: DANE + MTA-STS.

Avete il meglio di entrambi i mondi. DANE elimina il TOFU per i server mittenti che lo supportano (principalmente Postfix nell'ecosistema europeo). MTA-STS copre tutti gli altri mittenti (Gmail, Outlook, Yahoo). I due protocolli coesistono senza conflitti.

Caso 3: utilizzate Microsoft 365 o Google Workspace

Raccomandazione: MTA-STS.

Microsoft ha annunciato il supporto DANE per Exchange Online con DNSSEC automatico sui nuovi domini MX mx.microsoft. Google Workspace non supporta DANE lato ricezione. In entrambi i casi, MTA-STS è pienamente supportato e facile da attivare.

Caso 4: gestite i vostri server MX

Raccomandazione: DANE + MTA-STS se DNSSEC è attivo, altrimenti MTA-STS.

Con i vostri server, controllate i certificati TLS e i record DNS. Se DNSSEC è attivo sulla vostra zona, aggiungete record TLSA per ogni server MX. Completate con MTA-STS per coprire i mittenti che non supportano DANE.

Albero decisionale per scegliere tra MTA-STS, DANE o entrambi in base alla vostra infrastruttura

Perché combinare MTA-STS e DANE?

Implementare entrambi i protocolli simultaneamente è la migliore strategia quando la vostra infrastruttura lo consente. Ecco perché:

MTA-STS compensa i limiti di DANE:

  • I server mittenti che non supportano DANE (Gmail, Yahoo) utilizzano MTA-STS
  • La modalità testing di MTA-STS permette di validare la configurazione prima di imporre la crittografia

DANE compensa i limiti di MTA-STS:

  • Nessun TOFU: ogni connessione è verificata fin dalla prima interazione
  • Nessuna dipendenza da un'autorità di certificazione web: la fiducia viene dal DNS firmato

Nessun conflitto: un server mittente che supporta entrambi verificherà DANE in priorità (verifica DNS diretta), poi MTA-STS come rete di sicurezza. Se uno dei due fallisce, l'altro subentra.

Buone pratiche di distribuzione

Qualunque sia il protocollo scelto, seguite questa progressione:

  1. Iniziate con MTA-STS in modalità testing: pubblicate una policy con mode: testing. I server mittenti invieranno le email normalmente, ma segnaleranno gli errori TLS nei report TLS-RPT
  2. Configurate TLS-RPT: senza report, siete al buio. TLS-RPT (RFC 8460) vi invia un riepilogo quotidiano degli errori di negoziazione TLS
  3. Monitorate per 1-2 settimane: verificate i report. Correggete i problemi di certificato o di configurazione MX prima di continuare
  4. Passate MTA-STS in modalità enforce: i server mittenti rifiuteranno ormai di inviare in chiaro verso i vostri MX
  5. Aggiungete DANE se DNSSEC è attivo: pubblicate i record TLSA per ogni server MX. Utilizzate il verificatore DANE/TLSA per validare i vostri record

🎯 Piano d'azione raccomandato

  1. Verificate la vostra configurazione attuale: lanciate un'analisi con il verificatore MTA-STS per conoscere lo stato del vostro dominio
  2. Attivate MTA-STS in modalità testing: ospitate la vostra policy gratuitamente con CaptainDNS: due record DNS, nessun server web da gestire
  3. Configurate TLS-RPT: aggiungete un record DNS _smtp._tls.captaindns.com per ricevere i report di errore TLS
  4. Passate in modalità enforce: quando i report confermano zero errori, attivate la modalità enforce per bloccare le connessioni non cifrate
  5. Valutate DANE: se il vostro registrar supporta DNSSEC, aggiungete record TLSA per eliminare il TOFU e rafforzare la sicurezza

Proteggete il trasporto delle vostre email adesso: ospitate la vostra policy MTA-STS gratuitamente con CaptainDNS. Due record DNS, zero server web, protezione attiva in 5 minuti.

FAQ

Qual è la differenza tra MTA-STS e DANE?

MTA-STS (RFC 8461) pubblica una policy di crittografia obbligatoria tramite un file HTTPS. Si basa sulla PKI web (certificati SSL) e funziona senza DNSSEC. DANE (RFC 7672) àncora il certificato TLS del server MX direttamente nel DNS tramite record TLSA firmati da DNSSEC. MTA-STS soffre del TOFU (prima connessione non protetta), DANE no. In compenso, DANE richiede DNSSEC su tutta la catena DNS.

Serve DNSSEC per utilizzare MTA-STS?

No. MTA-STS si basa su HTTPS, non su DNSSEC. È il suo principale vantaggio: qualsiasi dominio che dispone di un hosting HTTPS può attivare MTA-STS. Con CaptainDNS, non avete nemmeno bisogno di gestire un server web: bastano due record DNS CNAME per pubblicare la vostra policy.

DANE è migliore di MTA-STS?

DANE offre una sicurezza superiore su un punto preciso: elimina il TOFU (Trust On First Use). Ogni connessione è verificata individualmente tramite il DNS firmato. Ma DANE è molto più difficile da implementare (DNSSEC obbligatorio) e meno supportato dai grandi provider (Gmail e Yahoo non verificano DANE). In pratica, MTA-STS protegge più domini grazie alla sua semplicità.

Si possono utilizzare MTA-STS e DANE contemporaneamente?

Sì, ed è raccomandato. I due protocolli coesistono senza conflitti. Un server mittente che supporta DANE verificherà il record TLSA in priorità. Se supporta solo MTA-STS, utilizzerà la policy HTTPS. Ottenete così la copertura massima: DANE per i server compatibili, MTA-STS per tutti gli altri.

Qual è il problema del TOFU con MTA-STS?

TOFU (Trust On First Use) significa che la prima connessione di un server mittente verso il vostro dominio non è protetta da MTA-STS. Il server deve prima scaricare e mettere in cache la vostra policy. Se un attaccante blocca questa prima richiesta HTTPS, il server non saprà che MTA-STS è attivo. Le connessioni successive sono protette dalla cache (valida per max_age, tipicamente 7 giorni). DANE elimina questo problema perché la verifica avviene tramite il DNS ad ogni connessione.

Google e Microsoft supportano DANE?

Microsoft sta implementando progressivamente il supporto DANE per Exchange Online, con DNSSEC automatico sui nuovi domini MX. Google Gmail non supporta DANE lato ricezione (nessun record TLSA pubblicato), ma verifica e rispetta i record DANE dei domini destinatari lato invio. Entrambi supportano pienamente MTA-STS come mittenti.

Come testare la configurazione MTA-STS o DANE?

Per MTA-STS, verificate che il vostro record TXT _mta-sts sia pubblicato e che il vostro file di policy sia accessibile in HTTPS. Per DANE, verificate che i vostri record TLSA corrispondano al certificato dei vostri server MX e che DNSSEC sia attivo su tutta la catena. CaptainDNS propone strumenti di verifica dedicati per entrambi i protocolli.

Scarica le tabelle comparative

Gli assistenti possono riutilizzare i dati scaricando gli export JSON o CSV qui sotto.

📖 Glossario

  • MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Policy pubblicata via HTTPS che impone la crittografia TLS per la ricezione di email su un dominio.
  • DANE: DNS-Based Authentication of Named Entities (RFC 7672 per SMTP). Meccanismo che àncora il certificato TLS nel DNS tramite record TLSA, verificato da DNSSEC.
  • TLSA: tipo di record DNS utilizzato da DANE per pubblicare l'impronta (hash) del certificato TLS di un server.
  • TOFU: Trust On First Use. Modello di sicurezza in cui la prima connessione non è verificata, ma le successive sono validate grazie ai dati messi in cache durante la prima interazione.
  • DNSSEC: DNS Security Extensions. Sistema di firme crittografiche che autentica le risposte DNS e ne impedisce la falsificazione.
  • STARTTLS: estensione SMTP (RFC 3207) che permette di negoziare una connessione TLS dopo l'instaurazione di una connessione in chiaro sulla porta 25.
  • PKI: Public Key Infrastructure. Sistema di certificati digitali utilizzato da HTTPS (e quindi da MTA-STS) per autenticare i server.

📚 Guide correlate sulla sicurezza del trasporto email

Fonti

Articoli simili