Implementare DANE per Exchange Online e Microsoft 365

Q: Quanto tempo richiede l'attivazione di DANE su Exchange Online?

L'attivazione avviene in due fasi. La migrazione MX ( Enable-DnssecForVerifiedDomain ) richiede pochi minuti, ma la propagazione DNS dipende dai tuoi TTL. La pubblicazione TLSA ( Enable-SmtpDaneInbound ) richiede 15-30 minuti. Prevedi qualche ora in totale, principalmente per le propagazioni DNS.

Di CaptainDNS
Pubblicato il 24 febbraio 2026

Schema del flusso DANE tra un mittente SMTP ed Exchange Online con DNSSEC e TLSA

TL;DR

Microsoft 365 supporta DANE inbound (SMTP) da marzo 2024 per Exchange Online, con pubblicazione automatica dei record TLSA
Il prerequisito principale è DNSSEC: il tuo dominio deve essere firmato e i record DS pubblicati presso il registrar
L'attivazione migra il tuo MX da mail.protection.outlook.com a o-v1.mx.microsoft, un dominio firmato DNSSEC. Microsoft pubblica automaticamente i TLSA, non devi gestirli tu
Google Workspace non supporta DANE inbound, solo il DANE outbound (verifica) è attivo
Verifica il tuo deployment con il nostro ispettore DANE/TLSA che testa DNSSEC, TLSA e la catena dei certificati in un solo clic

Microsoft ha annunciato la disponibilità generale di DANE inbound per Exchange Online a marzo 2024. In concreto, i domini ospitati su Microsoft 365 possono ora ricevere email protette da DANE: i server mittenti che verificano DANE/TLSA validano il certificato TLS di Exchange Online tramite DNS firmato, invece di fidarsi ciecamente delle autorità di certificazione.

Ma attivare DANE su Microsoft 365 non si fa con un pulsante. Il prerequisito fondamentale è DNSSEC: senza zona DNS firmata, i record TLSA pubblicati da Microsoft non hanno alcun valore. E la configurazione DNSSEC dipende dal tuo registrar e dal tuo provider DNS, non da Microsoft.

Questa guida copre la procedura completa: verificare i prerequisiti, attivare DNSSEC sul tuo dominio, attivare DANE in Exchange Online e validare il deployment end-to-end. Confronta anche le differenze con Google Workspace (che non supporta DANE inbound) e i server on-premise come Postfix o Exchange Server.

Pubblico di riferimento: amministratori Microsoft 365, IT manager aziendali, MSP che gestiscono tenant M365. Per i fondamenti di DANE e TLSA, consulta il primo articolo di questa serie (link in fondo alla pagina).

Come funziona DANE con Exchange Online?

Quando un server mittente invia un'email verso un dominio ospitato su Exchange Online e protetto da DANE:

Risoluzione MX: il server risolve il MX di captaindns.com e ottiene captaindns-com.o-v1.mx.microsoft (il nuovo formato MX per i domini DANE)
Verifica DNSSEC: verifica che la risposta DNS sia firmata DNSSEC. La catena di fiducia passa per root → .microsoft → mx.microsoft → o-v1.mx.microsoft, interamente firmata
Query TLSA: richiede il record TLSA a _25._tcp.captaindns-com.o-v1.mx.microsoft
Connessione TLS: si connette in STARTTLS sulla porta 25 e confronta il certificato presentato da Exchange Online con l'hash TLSA
Consegna: se tutto corrisponde, l'email viene consegnata. Altrimenti, viene rifiutata o differita secondo la policy del server mittente

Un punto importante: outlook.com non è firmato DNSSEC. Per questo Microsoft ha creato l'infrastruttura mx.microsoft sotto il TLD .microsoft, che è firmato DNSSEC end-to-end. L'attivazione di DANE migra automaticamente il tuo MX dal vecchio formato mail.protection.outlook.com al nuovo o-v1.mx.microsoft.

La differenza chiave rispetto a un server self-hosted (Postfix, Exchange Server on-premise): Microsoft gestisce la migrazione MX, i record TLSA e i certificati TLS. Non pubblichi tu stesso i TLSA. La tua unica responsabilità è attivare DNSSEC sul tuo dominio.

Flusso DANE tra un server mittente ed Exchange Online

Prerequisiti prima di attivare DANE

Dominio con DNSSEC attivo

DANE si basa interamente su DNSSEC. Senza firme DNS valide, i record TLSA vengono ignorati dai server mittenti. Verifica lo stato attuale:

dig +dnssec captaindns.com SOA +short

Se la risposta include un flag ad (Authenticated Data) nell'header, il tuo dominio è firmato. Altrimenti, devi attivare DNSSEC.

Registrar compatibile con DNSSEC

Non tutti i registrar supportano DNSSEC allo stesso modo:

Registrar	DNSSEC	Metodo
Cloudflare	Automatico	Un clic nella dashboard, DS pubblicato automaticamente
OVH	Supportato	Attivazione manuale, DS da pubblicare presso il registrant
Gandi	Supportato	Chiave KSK da fornire, DS pubblicato automaticamente
GoDaddy	Supportato	Attivazione manuale nelle impostazioni DNS avanzate
Route 53 (AWS)	Supportato	Creazione della catena KSK/ZSK, DS da pubblicare manualmente

Se il tuo registrar non supporta DNSSEC, dovrai migrare il DNS verso un provider compatibile prima di poter attivare DANE.

MX che punta a Exchange Online

Prima di attivare DANE, i tuoi MX puntano a *.mail.protection.outlook.com. Verifica:

dig MX captaindns.com +short

Il risultato dovrebbe essere simile a:

0 captaindns-com.mail.protection.outlook.com.

Al momento dell'attivazione di DANE, Microsoft ti chiederà di migrare questo MX verso un nuovo formato: captaindns-com.o-v1.mx.microsoft. Questo nuovo dominio è ospitato sotto il TLD .microsoft, firmato DNSSEC end-to-end. Dato che il vecchio outlook.com non è firmato DNSSEC, la catena di fiducia sarebbe impossibile senza questa migrazione.

Se i tuoi MX passano per un relay di terze parti (Proofpoint, Mimecast, Barracuda), DANE proteggerà solo l'ultimo hop verso Exchange Online. Anche il relay deve supportare DANE per una protezione end-to-end.

Attivare DNSSEC sul tuo dominio

La procedura varia a seconda del tuo provider DNS. Ecco i passaggi principali comuni.

Se il tuo DNS è su Cloudflare

Accedi alla dashboard Cloudflare
Seleziona il tuo dominio
Vai in DNS → DNSSEC
Clicca Enable DNSSEC
Cloudflare mostra le informazioni DS da pubblicare presso il registrar
Se Cloudflare è anche il tuo registrar, è automatico

Cloudflare firma la zona e pubblica il DS in pochi minuti. Verifica poi:

dig +dnssec captaindns.com DNSKEY +short

Se il tuo DNS è presso un altro provider

Il processo si divide in due fasi:

Attivare la firma della zona presso il tuo provider DNS (generazione delle chiavi KSK/ZSK, firma automatica)
Pubblicare il record DS presso il registrar (la chiave DS collega la tua zona firmata alla zona padre)

Il DS deve corrispondere esattamente alla chiave KSK della tua zona. Un errore nel DS interromperà la risoluzione DNS del tuo dominio. Testa sempre in ambiente di staging o con un sottodominio prima.

Guida in 4 passaggi per implementare DANE su Microsoft 365

Attiva la firma DNSSEC presso il tuo provider DNS e pubblica il record DS presso il registrar. Verifica con dig +dnssec captaindns.com SOA che il flag ad appaia nella risposta. Prevedi 24-48 ore per la propagazione completa del DS.
Abbassa il TTL del tuo MX attuale al minimo (non meno di 30 secondi) e attendi la scadenza del vecchio TTL. Esegui Enable-DnssecForVerifiedDomain -DomainName captaindns.com in Exchange Online PowerShell. Il comando restituisce il nuovo valore MX: captaindns-com.o-v1.mx.microsoft. Aggiungi questo nuovo MX con priorità 20, verifica che funzioni, poi impostalo a priorità 0 e rimuovi il vecchio MX mail.protection.outlook.com.
Una volta migrato il MX e verificato che funzioni, esegui Enable-SmtpDaneInbound -DomainName captaindns.com. Microsoft genera e pubblica automaticamente i record TLSA sotto _25._tcp.captaindns-com.o-v1.mx.microsoft. La propagazione richiede 15-30 minuti.
Usa dig TLSA _25._tcp.captaindns-com.o-v1.mx.microsoft per confermare la presenza del TLSA. Testa la connessione TLS con openssl s_client -starttls smtp -connect captaindns-com.o-v1.mx.microsoft:25. Valida il tutto con lo strumento di verifica DANE/TLSA di CaptainDNS.

Attivare DANE in Exchange Online

L'attivazione avviene in due fasi distinte: prima la migrazione DNSSEC (nuovo MX), poi l'attivazione DANE (pubblicazione TLSA). La procedura si gestisce tramite Exchange Online PowerShell.

Fase 1: migrazione MX verso mx.microsoft

Questa prima fase attiva DNSSEC e migra il tuo MX verso l'infrastruttura mx.microsoft, firmata DNSSEC.

# Connessione a Exchange Online
Connect-ExchangeOnline -UserPrincipalName admin@captaindns.com

# Attivare DNSSEC per il dominio
Enable-DnssecForVerifiedDomain -DomainName captaindns.com

Il comando restituisce il nuovo valore MX:

Result	DnssecMxValue
`Success`	`captaindns-com.o-v1.mx.microsoft`

Procedura di migrazione MX:

Abbassare il TTL del tuo MX attuale al minimo (non meno di 30 secondi)
Attendere la scadenza del vecchio TTL
Aggiungere il nuovo MX captaindns-com.o-v1.mx.microsoft con priorità 20
Verificare che il nuovo MX riceva posta correttamente
Invertire le priorità: nuovo MX a 0, vecchio a 30
Rimuovere il vecchio MX captaindns-com.mail.protection.outlook.com
Impostare il TTL del nuovo MX a 3600 secondi

Se utilizzi MTA-STS, imposta la policy in modalità testing e aggiungi il nuovo hostname nel file di policy prima della migrazione. Ripristina la modalità enforce una volta completata.

Fase 2: attivazione DANE (pubblicazione TLSA)

Una volta migrato il MX e verificato che funzioni:

# Attivare DANE (pubblicazione dei TLSA)
Enable-SmtpDaneInbound -DomainName captaindns.com

# Verificare lo stato completo
Get-DnssecStatusForVerifiedDomain -DomainName captaindns.com

Lo stato passa attraverso diverse fasi:

Stato	Significato
`DnssecFeatureNotEnabled`	DNSSEC non attivato
`DnssecValidationPending`	Microsoft sta verificando DNSSEC sul tuo dominio
`DnssecEnabled`	DNSSEC validato, MX migrato, TLSA non ancora pubblicato
`DaneEnabled`	DANE attivo, TLSA pubblicato e funzionante
`DnssecValidationFailed`	Validazione DNSSEC fallita, verifica il tuo DS

Tempistiche

Migrazione MX: pochi minuti per il comando, poi il tempo della propagazione DNS (variabile in base al TTL)
Pubblicazione TLSA: 15-30 minuti dopo Enable-SmtpDaneInbound
End-to-end: prevedi qualche ora, principalmente a causa delle propagazioni DNS

Verificare il deployment

Verificare i TLSA con dig

dig TLSA _25._tcp.captaindns-com.o-v1.mx.microsoft +short

Risultato atteso:

3 1 1 A4B5C6D7E8F9...  (hash SHA-256 del certificato Exchange Online)

Microsoft pubblica diversi record TLSA 3 1 1 (DANE-EE, SPKI, SHA-256) e 3 1 2 (DANE-EE, SPKI, SHA-512) per garantire la ridondanza. È normale che alcuni non corrispondano al certificato attuale: un solo match è sufficiente per validare DANE.

Verificare la connessione TLS

openssl s_client -starttls smtp \
  -connect captaindns-com.o-v1.mx.microsoft:25 \
  -servername captaindns-com.o-v1.mx.microsoft

Verifica che il certificato presentato corrisponda a uno degli hash TLSA pubblicati.

Verificare con CaptainDNS

L'ispettore DANE/TLSA menzionato nel TL;DR testa automaticamente:

La presenza e la validità DNSSEC sul tuo dominio
La risoluzione MX verso o-v1.mx.microsoft
La presenza dei record TLSA nella zona firmata
La corrispondenza tra il TLSA e il certificato TLS

Matrice di compatibilità DANE per provider email

Errori comuni e soluzioni

DNSSEC validation failed

Causa: il record DS presso il registrar non corrisponde alla chiave KSK della tua zona.

Soluzione: verifica la corrispondenza tra il DS pubblicato e la chiave KSK con dig DNSKEY captaindns.com +short e confronta con il DS presso il registrar. Rigenera il DS se necessario.

TLSA non pubblicato dopo l'attivazione

Causa: il MX non è stato migrato verso o-v1.mx.microsoft, Microsoft non ha potuto validare DNSSEC, oppure la propagazione è ancora in corso.

Soluzione: verifica che il tuo MX punti a *.o-v1.mx.microsoft e che il vecchio mail.protection.outlook.com sia rimosso. Verifica lo stato con Get-DnssecStatusForVerifiedDomain. Se lo stato è DnssecValidationFailed, correggi la configurazione DNSSEC prima di riprovare.

Vecchio MX non rimosso

Causa: il vecchio MX mail.protection.outlook.com coesiste con il nuovo o-v1.mx.microsoft, impedendo a DANE di funzionare correttamente.

Soluzione: segui la procedura di migrazione MX completa. Il nuovo MX deve avere priorità 0 e il vecchio deve essere rimosso prima di eseguire Enable-SmtpDaneInbound.

Relay di terze parti che blocca DANE

Causa: un servizio di filtering (Proofpoint, Mimecast) intercetta i MX e non supporta DANE.

Soluzione: DANE protegge solo l'ultimo hop SMTP. Se il tuo relay non supporta DANE, dovrai scegliere tra il filtering di terze parti e DANE. Alcuni relay stanno iniziando a supportare DANE nel 2025-2026, verifica con il tuo provider.

Email rifiutate da server restrittivi

Causa: il tuo DANE è mal configurato e i server mittenti che applicano una policy DANE restrittiva rifiutano i messaggi.

Soluzione: utilizza la metodologia di troubleshooting descritta nella nostra guida di troubleshooting DANE/TLSA (link in fondo alla pagina) per diagnosticare l'errore esatto. Verifica per prima cosa la catena DNSSEC e la corrispondenza TLSA/certificato.

Microsoft 365 vs Google Workspace vs on-premise

Funzionalità	Microsoft 365	Google Workspace	On-premise (Postfix)
DANE inbound	Sì (da marzo 2024)	No	Sì (nativo)
DANE outbound	Sì	Sì	Sì (nativo)
Migrazione MX	Sì (`o-v1.mx.microsoft`)	N/A	No (MX invariato)
Gestione TLSA	Automatica (Microsoft)	N/A	Manuale
Gestione certificato	Automatica (Microsoft)	N/A	Manuale (Let's Encrypt, ecc.)
Prerequisiti	DNSSEC + migrazione MX	-	DNSSEC + TLSA + certificato
Complessità	Media (DNSSEC + migrazione)	N/A	Elevata (tutto da gestire)
Rotazione certificato	Trasparente	N/A	Deploy-hook necessario

Google Workspace

Google supporta DANE in uscita (verifica dei TLSA dei destinatari) dal 2023, ma non supporta DANE in entrata. I domini ospitati su Google Workspace non possono pubblicare TLSA tramite Google. Se utilizzi Google Workspace e desideri DANE inbound, attualmente non esiste alcuna soluzione.

Exchange Server on-premise

Per un server Exchange on-premise (2016, 2019), DANE funziona come per qualsiasi server SMTP self-hosted:

Gestisci tu stesso DNSSEC, i TLSA e i certificati
La configurazione è simile a Postfix (vedi il nostro tutorial Postfix/Bind/Let's Encrypt nelle guide correlate)
Devi automatizzare la rotazione TLSA al rinnovo dei certificati

Completare DANE con MTA-STS e TLS-RPT

DANE e MTA-STS sono complementari, non concorrenti:

DANE verifica il certificato tramite DNS/DNSSEC (forte, ma richiede DNSSEC)
MTA-STS impone TLS tramite una policy HTTPS (più semplice, ma dipende dalle CA)
TLS-RPT invia report giornalieri via email sugli errori TLS e DANE

Microsoft 365 supporta tutti e tre i protocolli. Per una sicurezza email massima:

Attiva DANE (questa guida)
Pubblica una policy MTA-STS con il nostro generatore MTA-STS
Attiva TLS-RPT per ricevere i report sugli errori

FAQ

Microsoft 365 supporta DANE?

Sì. Microsoft ha lanciato il supporto DANE inbound per Exchange Online in disponibilità generale a marzo 2024. L'attivazione migra il tuo MX da mail.protection.outlook.com a o-v1.mx.microsoft, un dominio sotto il TLD .microsoft firmato DNSSEC. Microsoft pubblica poi automaticamente i record TLSA.

Bisogna pubblicare manualmente i record TLSA con Microsoft 365?

No. A differenza di un server self-hosted, Microsoft gestisce automaticamente la pubblicazione e la rotazione dei record TLSA nella zona o-v1.mx.microsoft. La tua responsabilità è attivare DNSSEC sul tuo dominio e migrare il MX verso il nuovo formato.

Google Workspace supporta DANE inbound?

No. Google Workspace supporta solo DANE in uscita (verifica dei TLSA dei destinatari). Non esiste un modo per attivare DANE inbound per i domini ospitati su Google Workspace.

Quanto tempo richiede l'attivazione di DANE su Exchange Online?

L'attivazione avviene in due fasi. La migrazione MX (Enable-DnssecForVerifiedDomain) richiede pochi minuti, ma la propagazione DNS dipende dai tuoi TTL. La pubblicazione TLSA (Enable-SmtpDaneInbound) richiede 15-30 minuti. Prevedi qualche ora in totale, principalmente per le propagazioni DNS.

Cosa succede se DNSSEC smette di funzionare sul mio dominio?

Se DNSSEC fallisce (firma scaduta, DS errato), la risoluzione DNS del tuo dominio sarà compromessa. I server DANE-aware non potranno più validare i TLSA e rifiuteranno o differiranno le email. Per questo il monitoraggio DNSSEC è fondamentale.

DANE funziona con un relay di terze parti (Proofpoint, Mimecast)?

Parzialmente. DANE protegge solo l'ultimo hop SMTP. Se i tuoi MX puntano a un relay di terze parti che poi inoltra a Exchange Online, DANE protegge solo l'hop relay → Exchange. L'hop mittente → relay non è coperto, a meno che anche il relay supporti DANE.

Si possono usare DANE e MTA-STS contemporaneamente?

Sì, ed è consigliato. DANE verifica il certificato tramite DNS/DNSSEC, MTA-STS impone TLS tramite HTTPS. I due protocolli sono complementari. Microsoft 365 li supporta entrambi contemporaneamente.