I punti chiave da prendere in considerazione
- DANE trasferisce la convalida dei certificati TLS dalle autorità di certificazione di terze parti al DNS, utilizzando record TLSA firmati con DNSSEC per stabilire l'affidabilità.
- Impedisce gli attacchi di downgrade STARTTLS imponendo connessioni crittografate invece di consentire il passaggio silenzioso al testo in chiaro.
- DANE riduce il rischio di certificati emessi erroneamente o compromessi, consentendo ai proprietari dei domini di definire con precisione quali certificati sono validi.
- Il protocollo DNSSEC è indispensabile affinché DANE funzioni. Senza di esso, i record TLSA non possono essere considerati affidabili né verificati.
- Sebbene sia un protocollo potente, l'adozione di DANE è ancora limitata, pertanto viene spesso utilizzato in combinazione con MTA-STS e integrato da DMARC per garantire una sicurezza completa della posta elettronica.
L'autenticazione delle entità denominate basata sul DNS (DANE) è un metodo per verificare i certificati TLS tramite il DNS. Si avvale dei record DNSSEC e TLSA per garantire che le connessioni crittografate non vengano intercettate o compromesse.
Il problema che DANE è stato progettato per risolvere
L'invio di e-mail tramite il protocollo SMTP (Simple Mail Transfer Protocol) utilizza spesso STARTTLS per rendere le connessioni crittografate. Il problema è che STARTTLS è un protocollo opportunistico. Ciò significa che, se la crittografia fallisce, la connessione può ricadere in modalità testo in chiaro. Questo passaggio a un livello di sicurezza inferiore può avvenire in modo silenzioso, rendendo facile per gli hacker sfruttare questo comportamento per intercettare le e-mail.
Il percorso normale:

Il percorso dell'attacco:

C'è anche un secondo problema con il TLS tradizionale:
I certificati TLS vengono convalidati da autorità di certificazione (CA) commerciali. Queste CA possono essere compromesse o rilasciare certificati in modo errato. Se un malintenzionato ottiene un certificato valido per un dominio, può spacciarsi per quel server.
Questi due aspetti rendono possibili gli attacchi «man-in-the-middle» anche quando si utilizza il protocollo TLS. Il DANE risolve entrambi i problemi trasferendo la convalida dei certificati nel DNS, protetto dal protocollo DNSSEC. Ciò elimina la dipendenza da autorità di certificazione esterne e previene gli attacchi di downgrade silenziosi.
Che cos'è DANE?
DANE è un protocollo di sicurezza Internet che consente ai proprietari di domini di pubblicare informazioni sui propri certificati TLS direttamente nel DNS tramite i record TLSA.
Questi record sono protetti dal protocollo DNSSEC, che garantisce:
- I dati non possono essere modificati durante il trasferimento
- Il cliente può verificare che la risposta sia autentica
Anziché affidarsi a un'autorità di certificazione (CA) di terze parti, il client verifica la validità del certificato confrontandolo con quanto pubblicato dal dominio stesso.
Come funziona DANE: passo dopo passo
Passaggio 1: Il proprietario del dominio pubblica un record TLSA nel DNS
L'amministratore di dominio crea un record di risorsa TLSA (Transport Layer Security Authentication) e lo pubblica nella propria zona DNS. Questo record contiene i dati del certificato che i client utilizzeranno in seguito per la verifica.

Fase 2: La zona DNS viene firmata tramite DNSSEC
Il protocollo DNSSEC (DNS Security Extensions) firma crittograficamente l'intera zona DNS, compreso il nuovo record TLSA. In questo modo si crea una catena di fiducia che va dalla zona DNS radice fino ai record del dominio, impedendo qualsiasi manomissione.

Fase 3: un client si connette al server e interroga il record TLSA
Quando un client (come un server di posta o un browser) desidera stabilire una connessione TLS con il server, invia innanzitutto una richiesta al DNS per ottenere il record TLSA del dominio.

Fase 4: Il client verifica la risposta DNS tramite DNSSEC
Prima di considerare attendibile il record TLSA, il resolver del client verifica le firme DNSSEC risalendo la catena di fiducia.

Passaggio 5: Il server presenta il proprio certificato TLS
Durante la procedura di handshake TLS, il server invia il proprio certificato TLS al client per dimostrare la propria identità presentando la propria catena di certificati.

Passaggio 6: Il client confronta il certificato con il record TLSA
Questa è la parte più importante della verifica DANE. In questa fase, il client estrae la parte pertinente del certificato del server e la confronta con i dati memorizzati nel record TLSA.

Passaggio 7: Se corrispondono, la connessione prosegue
Quando i dati del certificato corrispondono al record TLSA, la convalida DANE va a buon fine, consentendo così di stabilire correttamente la connessione TLS.

Passaggio 8: Se non corrispondono, la connessione viene rifiutata
Quando il certificato non corrisponde al record TLSA, il client lo considera un errore di sicurezza e rifiuta di completare la procedura di handshake TLS. Ciò impedisce fin dall'inizio il successo degli attacchi man-in-the-middle.

Che cos'è un record TLSA?
Un record TLSA è un record DNS utilizzato dal protocollo DANE per definire le modalità di convalida di un certificato TLS.
The format looks like this: <usage> <selector> <matching-type> <certificate-data>
Esempio di record TLSA:
_25._tcp.mail.example.com. IN TLSA 3 1 1 (
2A3F5C7D8E9B1A2C3D4E5F67890123456789ABCDEF1234567890ABCDEF123456
)
Ogni campo ha una funzione specifica:
- Utilizzo: definisce le modalità di verifica e di riconoscimento della validità del certificato
- Selettore: specifica quale parte del certificato viene utilizzata (certificato completo o chiave pubblica)
- Tipo di corrispondenza: indica come vengono memorizzati i dati (valore completo o hash)
- Dati del certificato: il valore effettivo o l'hash da confrontare
Valori di utilizzo del certificato
Esistono quattro tipi di utilizzo:
0 (PKIX-TA): Vincolo di ancoraggio di fiducia tramite PKI tradizionale
1 (PKIX-EE): Certificato dell'entità finale convalidato tramite PKI
2 (DANE-TA): Ancoraggio di fiducia definito dal DNS
3 (DANE-EE): Certificato dell'entità finale definito direttamente nel DNS
Per quanto riguarda la sicurezza della posta elettronica, i livelli di utilizzo 2 e 3 sono i più rilevanti poiché eliminano la dipendenza dalle autorità di certificazione pubbliche.
Dove vengono pubblicati i registri TLSA
I record TLSA vengono pubblicati sotto sottodomini specifici relativi ai servizi. Per SMTP, il formato è solitamente il seguente: _25._tcp.mail.example.com
DANE per l'e-mail: come garantisce la sicurezza del protocollo SMTP
DANE aiuta il server mittente a verificare l'autenticità dei certificati del server destinatario. Questa verifica contribuisce a prevenire il downgrade di STARTTLS e gli attacchi man-in-the-middle, garantendo così la sicurezza delle comunicazioni SMTP.
DANE impone l'uso del protocollo TLS per la trasmissione delle e-mail, impedendo così che i messaggi vengano inviati in chiaro o manomessi durante il trasferimento.
Perché DANE richiede DNSSEC
DANE dipende interamente dall'integrità dei record DNS. Senza DNSSEC, i record TLSA potrebbero essere falsificati e gli hacker potrebbero reindirizzare i client verso certificati dannosi. Ecco come funziona questa dipendenza: DNSSEC firma le risposte DNS utilizzando chiavi crittografiche. Ciò consente al client di verificare che la risposta non sia stata alterata e che i dati siano autentici. Pertanto, senza DNSSEC, DANE non offre alcun reale vantaggio in termini di sicurezza.
Chi utilizza DANE?
L'adozione di DANE varia a livello globale, con i tassi più elevati registrati tra le agenzie governative europee e le organizzazioni statunitensi. L'adozione è in crescita nei settori in cui la riservatezza della posta elettronica è fondamentale. Tra gli utenti abituali di DANE figurano:
- Gli amministratori di posta elettronica come livello di autenticazione e sicurezza
- Le agenzie governative dei paesi europei e degli Stati Uniti, al fine di garantire la sicurezza della trasmissione delle e-mail nel settore pubblico (ad esempio: la tedesca T-Online è un caso concreto di adozione della tecnologia DANE)
- Provider di posta elettronica come Comcast, Protonmail, ecc.
- Microsoft ha annunciato che a partire da luglio 2024 supporterà il protocollo SMTP in entrata DANE.
DANE vs. MTA-STS: qual è la differenza?
Sia DANE che Mail Transfer Agent – Strict Transport Security (MTA-STS) sono stati progettati per proteggere le connessioni SMTP, ma utilizzano modelli di fiducia diversi. Mentre MTA-STS si basa su HTTPS e sulle autorità di certificazione (CA), DANE si basa su DNSSEC e sul DNS. Ecco alcune delle principali differenze tra i due:
| Caratteristica | DANE | MTA-STS |
|---|---|---|
| È richiesto il supporto DNSSEC | Sì | No |
| Posizione della politica | DNS | File delle impostazioni HTTPS |
| Dipendenza CA | Opzionale | Richiesto |
| Protezione contro il ribasso | Forte | Forte |
| Adozione | Basso | Alto |
Per saperne di più su MTA-STS, leggi la nostra guida completa su cos'è MTA-STS. Per scoprire come implementare MTA-STS sul tuo dominio, consulta la nostra guida all'implementazione di MTA-STS.
Come funziona TLS-RPT insieme a DANE e MTA-STS
TLS-RPT è un protocollo di segnalazione che offre visibilità sugli errori di negoziazione TLS e sui problemi di consegna causati da configurazioni errate di DANE o MTA-STS. Si può considerare TLS-RPT come un livello di visibilità che si sovrappone a DANE e MTA-STS (livelli di sicurezza). Sebbene sia DANE che MTA-STS contribuiscano a garantire l'applicazione del protocollo TLS per proteggere le trasmissioni e-mail, esiste una grave lacuna in termini di chiarezza riguardo a quando o perché la consegna fallisca.
È qui che entra in gioco TLS-RPT. Il protocollo SMTP TLS Reporting (TLS-RPT) invia quotidianamente ai server destinatari dei rapporti di feedback aggregati riguardanti:
- Errori nella negoziazione TLS
- Problemi relativi alla convalida dei certificati
- Incompatibilità tra protocolli (MTA-STS o DANE)
- Errori di consegna dovuti all'applicazione del protocollo TLS
Come verificare se il tuo dominio dispone di un record DANE/TLSA
Per verificare la configurazione DANE, è necessario controllare:
- Se esiste un record TLSA per il tuo server di posta
- Se il protocollo DNSSEC è abilitato e valido
- Se il certificato corrisponde al record TLSA
Puoi utilizzare lo strumento gratuito DANE Record Checker di PowerDMARC per verificare rapidamente la tua configurazione.
Come implementare DANE per la posta elettronica
Per implementare DANE nella tua posta elettronica, puoi seguire questi passaggi:
Passaggio 1: Abilitare il protocollo DNSSEC
DANE non funziona senza DNSSEC, quindi il primo passo è configurare il protocollo DNSSEC tramite il proprio provider DNS o registrar. È possibile verificare se il protocollo è già configurato per il proprio dominio utilizzando il nostro strumento di verifica DNSSEC.
Fase 2: Recupera i dati del tuo certificato TLS
Estrai il certificato o l'hash della chiave pubblica dal tuo server di posta.
Passaggio 3: Creare il record TLSA
Definisci l'utilizzo corretto, il selettore e il tipo di corrispondenza, quindi pubblica il tuo record TLSA nel sottodominio appropriato.
Fase 4: Verifica del record
Utilizza il nostro strumento di verifica DANE per assicurarti che il record sia corretto e che il protocollo DNSSEC funzioni correttamente.
Passaggio 5: Monitorare le modifiche ai certificati
Quando il certificato TLS viene rinnovato o modificato, è necessario aggiornare il record TLSA. In caso contrario, la consegna della posta potrebbe non funzionare correttamente.
Parole finali
Se non state già proteggendo il livello di trasporto delle vostre e-mail tramite MTA-STS, DANE può rappresentare un ottimo punto di partenza. Soprattutto nei settori che trattano dati sensibili, come gli istituti finanziari e gli enti pubblici, è fondamentale proteggere i messaggi dall’intercettazione.
Tuttavia, DANE non è in grado di impedire attacchi di spoofing o phishing che utilizzano il tuo stesso nome di dominio. A tal fine, DMARC è fondamentale. Desideri una suite completa per la sicurezza del dominio che gestisca l'autenticazione delle tue e-mail dall'inizio alla fine? Prenota oggi stesso una demo con i nostri esperti.
Domande frequenti
DANE è la stessa cosa di DNSSEC?
No, DANE e DNSSEC non sono la stessa cosa, anche se DANE richiede DNSSEC per funzionare. DNSSEC protegge i record DNS, mentre DANE utilizza DNSSEC per pubblicare in modo sicuro le informazioni relative ai certificati.
Mi servono sia DANE che MTA-STS?
Non necessariamente, ma l'uso combinato dei due garantisce una maggiore compatibilità e una protezione più efficace. Nel complesso, MTA-STS registra un tasso di adozione più elevato rispetto a DANE.
DANE sostituisce SPF, DKIM o DMARC?
No. DANE garantisce la sicurezza del livello di trasporto, mentre SPF, DKIM e DMARC si occupano dell'autenticazione delle e-mail e della prevenzione dello spoofing. Per garantire una sicurezza completa delle e-mail, è necessario un approccio multilivello che combini tutti i protocolli con un monitoraggio e aggiornamenti costanti.
Cosa succede se i miei dati TLSA sono errati?
Se il record TLSA non è corretto, i server di posta che applicano il protocollo DANE rifiuteranno le connessioni. Ciò può causare errori nella consegna delle e-mail. È importante verificare la configurazione DANE (compresa la validità del record TLSA) per risolvere eventuali problemi.
Quali provider di posta elettronica supportano DANE?
Il supporto per DANE varia da paese a paese. Alcuni provider europei e organizzazioni specializzate nella sicurezza lo rendono obbligatorio, ma la sua diffusione a livello globale è ancora limitata.
- Che cos'è DANE? Spiegazione dell'autenticazione delle entità denominate basata sul DNS (2026) - 20 aprile 2026
- VPN: nozioni di base sulla sicurezza. Le migliori pratiche per proteggere la tua privacy - 14 aprile 2026
- Recensione di MXtoolbox: caratteristiche, esperienze degli utenti, pro e contro (2026) - 14 aprile 2026


