• Cloud, Guide, Microsoft 365, Sicurezza
• 30 Aprile 2026

Dopo aver visto come implementare DNSSEC in Azure DNS, il passo successivo naturale è aumentare il livello di sicurezza della posta elettronica. In questo scenario entra in gioco SMTP DANE (DNS-based Authentication of Named Entities), una tecnologia che permette di associare i certificati TLS ai record DNS firmati, eliminando la dipendenza esclusiva dalle autorità di certificazione pubbliche.

In questa guida ci concentreremo su come integrare SMTP DANE con Exchange Online, utilizzando Azure DNS con DNSSEC già attivo. L’obiettivo è consentirvi di garantire che le comunicazioni SMTP siano non solo cifrate, ma anche autenticate tramite DNS sicuro, riducendo drasticamente il rischio di attacchi di tipo Man-in-the-Middle.

Vedremo quindi come pubblicare correttamente i record TLSA, quali prerequisiti sono necessari lato Microsoft 365 / Exchange Online e come validare il funzionamento della configurazione. Partiremo da uno scenario reale, costruito sul lavoro già svolto con DNSSEC, per arrivare a una configurazione completa e verificabile.

Figura 1: Flusso di posta Exchange Online con DANE SMTP

Quali sono i reali vantaggi?

I vantaggi reali di SMTP DANE emergono quando si analizza come oggi viene gestita la sicurezza del trasporto SMTP. Senza DANE, anche in presenza di STARTTLS, il meccanismo resta vulnerabile: la cifratura è opportunistica e si basa su autorità di certificazione pubbliche, con tutti i limiti che ne derivano.

Con SMTP DANE, invece, spostate il modello di fiducia sul DNS firmato con DNSSEC, ottenendo benefici concreti.

Il primo vantaggio è la protezione reale contro gli attacchi Man-in-the-Middle. Non ci si limita più a “provare” a cifrare la comunicazione: il server mittente verifica il certificato del destinatario confrontandolo con il record TLSA pubblicato nel DNS firmato. Se qualcosa non combacia, la connessione viene rifiutata.

Un altro aspetto fondamentale è l’eliminazione della dipendenza esclusiva dalle Certification Authority. Con DANE, siete voi a dichiarare quale certificato è valido per il vostro servizio SMTP. Questo riduce drasticamente il rischio legato a certificati emessi in modo improprio o compromessi.

C’è poi un miglioramento tangibile nella integrità del canale SMTP. La cifratura non è più opzionale o degradabile: diventa vincolante e verificabile, impedendo attacchi di downgrade come il classico “strip” di STARTTLS.

Dal punto di vista operativo, DANE introduce anche maggiore trasparenza e controllo. Tutte le informazioni critiche sono pubblicate nel DNS e quindi verificabili in modo indipendente, senza affidarsi a terze parti.

Verifica dell’abilitazione DNSSEC sul dominio

Per impostare SMTP DANE in entrata con DNSSEC in Exchange Online il primo requisito fondamentale è verificare che il dominio sia correttamente firmato.

Dovete quindi accertarvi che la zona DNS sia protetta con DNSSEC e che la catena di fiducia sia integra, dal dominio fino alla root. Questo significa che i record DNSKEY, DS e le firme RRSIG devono essere presenti e coerenti tra loro.

La verifica può essere effettuata utilizzando strumenti come il DNSSEC Debugger, che analizza automaticamente la configurazione e restituisce un report dettagliato. In presenza di soli indicatori verdi, come mostrato nell’immagine, potete essere certi che la configurazione è valida e pronta per supportare scenari avanzati come SMTP DANE.

Se la validazione non è corretta, qualsiasi configurazione DANE risulterà inefficace, perché verrebbe meno il presupposto fondamentale: la fiducia nel DNS firmato.

Figura 2: Verifica della corretta implementazione DNSSEC tramite DNSSEC Debugger con esito positivo su tutta la catena di validazione

Il passo successivo consiste nell’aggiornare il TTL del record MX esistente direttamente nel vostro Azure DNS (o registrar DNS). Dovete modificare il record MX abbassando il valore di TTL (Time To Live) al minimo consentito, come mostrato nella figura sotto, e verificare che la priorità sia correttamente impostata, tipicamente 0 o 10 per Exchange Online.

Questa operazione non è solo formale, ma ha un impatto diretto sul comportamento della posta. Il TTL determina per quanto tempo i server DNS esterni mantengono in cache il record MX. Riducendolo, fate in modo che eventuali modifiche successive, come l’introduzione dei record necessari per SMTP DANE,
vengano recepite rapidamente da tutti i sistemi.

È fondamentale comprendere che, se non abbassate il TTL prima, i server remoti continueranno a utilizzare informazioni obsolete per tutta la durata del TTL precedente. Questo può causare comportamenti incoerenti, soprattutto durante una configurazione sensibile come DANE, dove coerenza tra DNS e certificati è essenziale.

Per questo motivo dovete attendere la scadenza del TTL precedente prima di procedere. Se, ad esempio, il TTL era impostato a 1 ora, sarà necessario attendere almeno un’ora affinché tutte le cache DNS si aggiornino. Solo a quel punto potete essere certi che le modifiche successive verranno propagate in modo uniforme.

Abbassare il TTL vi permette di lavorare in modo controllato e prevedibile, riducendo il rischio di errori durante la transizione verso una configurazione SMTP DANE corretta e affidabile.

Figura 3: Modifica del TTL del record MX in Azure DNS per velocizzare la propagazione delle modifiche e garantire coerenza durante la configurazione di SMTP DANE

Verifiche preliminari

Per dimostrare che SMTP DANE non è ancora abilitato, potete utilizzare il tool ufficiale Microsoft Remote Connectivity Analyzer all’indirizzo https://testconnectivity.microsoft.com/tests/O365DaneValidation/input , eseguendo il test specifico per DNSSEC e DANE.

Inserite il vostro dominio e selezionate l’opzione DANE Validation (including DNSSEC). Questo test verifica non solo la presenza dei record necessari, ma anche la loro coerenza con la configurazione SMTP reale.

Il motivo per cui eseguite questa verifica è molto importante: serve a stabilire una baseline iniziale. In assenza dei record TLSA correttamente pubblicati e validati tramite DNSSEC, il risultato del test evidenzierà che DANE non è configurato o non è funzionante.

Questo passaggio vi permette di avere un riscontro oggettivo prima della configurazione, così da poter confrontare il risultato dopo aver implementato DANE. In pratica, dimostrate in modo chiaro il prima e dopo, evitando ambiguità e confermando che le modifiche apportate producono l’effetto atteso.

Figura 4: DNSSEC and DANE Validation Test

Figura 5: Esecuzione del test DNSSEC e DANE Validation per verificare che SMTP DANE non sia ancora configurato sul dominio

Nella figura mostrata sotto il report è molto chiaro: anche se il dominio supera alcuni controlli preliminari, viene evidenziato che DNSSEC non è abilitato sul dominio MX di Exchange Online e, soprattutto, che i record TLSA non sono presenti o non sono risolvibili. L’errore sul record TLSA (“Error query TLSA records“) indica esplicitamente che non esiste alcuna associazione tra certificato e DNS, requisito fondamentale per DANE.

Questo comportamento è atteso. Quando utilizzate Exchange Online Protection (EOP), il record MX punta a un dominio del tipo *.mail.protection.outlook.com, sul quale non avete controllo diretto per quanto riguarda DNSSEC e TLSA. Di conseguenza, senza una configurazione specifica lato Microsoft (Inbound DANE) e senza i record TLSA pubblicati, il test non può che restituire esito negativo.

Questo passaggio è cruciale perché dimostra in modo oggettivo che, nello stato attuale, la posta viene gestita con TLS opportunistico e non con DANE obbligatorio.

Figura 6: Risultato del test con assenza di record TLSA e DNSSEC non attivo sul dominio MX, conferma che SMTP DANE non è ancora configurato

Configurazione di Exchange Online per DNSSEC e preparazione a DANE

A questo punto potete procedere con la configurazione lato Exchange Online utilizzando PowerShell. Dopo esservi connessi con il comando Connect-ExchangeOnline, eseguite la cmdlet:

Questa operazione è fondamentale perché consente a Microsoft 365 di preparare il dominio per l’utilizzo con DNSSEC, restituendo anche il valore corretto del nuovo record MX da utilizzare.

Il punto chiave è proprio questo: Exchange Online genera un nuovo endpoint (*.mx.microsoft) progettato per scenari avanzati, diverso dal classico *.mail.protection.outlook.com. Questo passaggio è necessario perché abilita un’infrastruttura compatibile con DNSSEC e DANE, superando i limiti dello scenario standard.

Al termine del comando, verificate che il risultato sia Success e annotate il valore MxValue, che verrà utilizzato nei passaggi successivi per aggiornare la configurazione DNS.

Figura 7: Esecuzione del cmdlet Enable-DnssecForVerifiedDomain per ottenere il nuovo endpoint MX compatibile con DNSSEC e DANE

Aggiunta del nuovo record MX per DNSSEC/DANE

Procedete quindi ad aggiungere un nuovo record MX nella vostra zona DNS, mantenendo temporaneamente anche quello esistente.

Create quindi un nuovo record MX e incollate come valore il DnssecMxValue ottenuto dal comando PowerShell precedente. Impostate il TTL al minimo possibile e assegnate una priorità più alta (valore numerico maggiore), ad esempio 20, rispetto al record MX attuale.

Questo passaggio è fondamentale perché introduce gradualmente il nuovo endpoint compatibile con DNSSEC e DANE, senza interrompere il flusso di posta. Il record esistente continuerà a gestire la consegna principale, mentre il nuovo record verrà utilizzato in fallback, consentendovi di validare la configurazione in sicurezza.

In questo modo costruite una transizione controllata, evitando impatti sulla deliverability e preparando l’infrastruttura per il passaggio definitivo a SMTP DANE.

Figura 8: Aggiunta del nuovo record MX con priorità superiore (20) utilizzando il valore restituito da Exchange Online per scenari DNSSEC/DANE

Verifica della configurazione SMTP in ingresso

Effettuate un test utilizzando il tool Microsoft Remote Connectivity Analyzer all’indirizzo https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input , selezionando la verifica Inbound SMTP.

Il risultato deve confermare che entrambi i record MX sono correttamente pubblicati e risolvibili. Come si vede, il dominio espone sia il record tradizionale *.mail.protection.outlook.com con priorità 10, sia il nuovo endpoint *.mx.microsoft con priorità 20.

Questa verifica è importante perché dimostra che la configurazione DNS è coerente e funzionante. Exchange Online riconosce entrambi i record come validi e il flusso SMTP continua a essere gestito senza interruzioni.

In questa fase state validando che l’introduzione del nuovo record MX non abbia impatti sulla deliverability, mantenendo una configurazione stabile mentre preparate il passaggio a SMTP DANE.

Figura 9: est SMTP in ingresso riuscito con presenza di due record MX (priorità 10 e 20) correttamente configurati e funzionanti.

Rimozione del record MX legacy

Una volta verificato che il nuovo record funziona correttamente, potete rimuovere il record MX precedente e lasciare attivo solo quello basato su *.mx.microsoft.

In questa fase impostate il nuovo record con priorità più alta (valore numerico più basso, ad esempio 0), rendendolo l’unico punto di ingresso per la posta.

Questa operazione segna il passaggio definitivo: tutto il traffico SMTP verrà ora gestito tramite l’endpoint compatibile con DNSSEC, requisito indispensabile per poter utilizzare SMTP DANE.

Figura 10: Rimozione del vecchio record MX e configurazione del nuovo endpoint *.mx.microsoft come unico destinatario della posta

Verifica DNSSEC e stato DANE

Eseguite nuovamente il test DNSSEC e DANE Validation tramite il Microsoft Remote Connectivity Analyzer all’indirizzo https://testconnectivity.microsoft.com/tests/O365DaneValidation/input per verificare lo stato della configurazione.

Figura 11: Verifica DNSSEC e stato DANE

Il risultato mostrato nella figura sotto evidenzia che DNSSEC è correttamente attivo e validato, segno che la catena di fiducia è ora integra e funzionante. Questo conferma che il dominio e il nuovo endpoint MX *.mx.microsoft sono protetti e autenticati tramite DNSSEC.

Allo stesso tempo, viene indicato che DANE non è ancora abilitato. Il motivo è chiaro: non sono ancora presenti i record TLSA, indispensabili per associare il certificato TLS al servizio SMTP.

In questa fase avete quindi completato il prerequisito fondamentale, ma non ancora l’intera configurazione. Il dominio è pronto per DANE, ma finché non pubblicate i record TLSA, la posta continuerà a essere gestita senza validazione DANE.

Figura 12: Verifica positiva di DNSSEC, ma assenza di record TLSA, quindi DANE non ancora attivo

Abilitazione di SMTP DANE in ingresso

Per completare la configurazione dovete tornare in PowerShell, connessi a Exchange Online, ed eseguire il comando:

Questo cmdlet abilita SMTP DANE in ingresso per il dominio specificato e consente a Exchange Online di pubblicare e gestire i record TLSA necessari alla validazione.

Al termine dell’operazione verificate che il risultato sia Success. Da questo momento il dominio è configurato per usare DANE, ma conviene eseguire nuovamente il test di convalida per confermare che anche i record TLSA risultino correttamente disponibili.

Figura 13: Abilitazione di SMTP DANE Inbound tramite PowerShell con il cmdlet Enable-SmtpDaneInbound

Attesa propagazione e verifica finale DANE

Nota: è necessario attendere prima di eseguire nuove verifiche. I record TLSA devono propagarsi correttamente nei resolver DNS e fino a quel momento il test potrebbe restituire risultati incompleti o non aggiornati.

Trascorso il tempo necessario (in genere 30 minuti), eseguite nuovamente il test DANE Validation (including DNSSEC) tramite il Microsoft Remote Connectivity Analyzer all’indirizzo https://testconnectivity.microsoft.com/tests/O365DaneValidation/input .

Questa verifica conferma che non solo DNSSEC è attivo, ma anche che i record TLSA sono pubblicati e correttamente risolti, completando così la configurazione di SMTP DANE.

Figura 14: Verifica finale della corretta configurazione DANE

L’output del test mostra chiaramente se la convalida DANE (incluso DNSSEC) è andata a buon fine per il record MX basato su *.mx.microsoft.

In questo caso potete verificare che DNSSEC, TLSA e DANE risultano attivi, confermando che la configurazione è corretta e che la posta viene ora gestita con SMTP DANE.

È importante notare un aspetto spesso frainteso: Exchange Online pubblica più record TLSA per garantire maggiore affidabilità e resilienza. Di conseguenza, è normale che alcuni record TLSA possano risultare non validi durante il test.

Questo comportamento è previsto. Il meccanismo DANE considera valida la configurazione se almeno un record TLSA supera la convalida. In questo scenario, la comunicazione SMTP è comunque protetta e autenticata correttamente.

Figura 15: Verifica finale con DANE attivo, presenza di più record TLSA e validazione riuscita

Conclusioni

Con questa configurazione avete portato Exchange Online a un livello di sicurezza superiore, abilitando SMTP DANE su un’infrastruttura basata su DNSSEC.

Il risultato è una comunicazione SMTP non solo cifrata, ma anche autenticata tramite DNS, eliminando i limiti del modello opportunistico e riducendo in modo significativo il rischio di attacchi Man-in-the-Middle.

Il passaggio al nuovo endpoint *.mx.microsoft rappresenta l’elemento chiave: vi consente di superare i vincoli dello scenario standard Microsoft 365 e di adottare un modello più sicuro, moderno e verificabile.