Funzionamento dell'autenticazione basata su DNS SMTP delle entità denominate (DANE)

Articolo
08/12/2023

Il protocollo SMTP è il protocollo principale usato per trasferire i messaggi tra i server di posta elettronica e, per impostazione predefinita, non è sicuro. Il protocollo Transport Layer Security (TLS) è stato introdotto anni fa per supportare la trasmissione crittografata dei messaggi tramite SMTP. Viene comunemente usato in modo opportunistico piuttosto che come requisito, lasciando molto traffico di posta elettronica in testo non crittografati, vulnerabile all'intercettazione da parte di attori nefasti. Inoltre, SMTP determina gli indirizzi IP dei server di destinazione tramite l'infrastruttura DNS pubblica, che è soggetta a attacchi di spoofing e man-in-the-middle (MITM). Questa vulnerabilità ha portato alla creazione di molti nuovi standard per aumentare la sicurezza per l'invio e la ricezione di posta elettronica, uno di questi standard è l'autenticazione basata su DNS di entità denominate (DANE).

DANE per SMTP RFC 7672 usa la presenza di un record Transport Layer Security Authentication (TLSA) nel set di record DNS di un dominio per segnalare un dominio e i server di posta che supportano DANE. Se non è presente alcun record TLSA, la risoluzione DNS per il flusso di posta funzionerà come di consueto senza che vengano tentati controlli DANE. Il record TLSA segnala in modo sicuro il supporto TLS e pubblica i criteri DANE per il dominio. Pertanto, l'invio di server di posta elettronica può autenticare correttamente i server di posta elettronica destinatari legittimi usando SMTP DANE. Questa autenticazione lo rende resistente agli attacchi miTM e downgrade. DANE ha dipendenze dirette su DNSSEC, che funziona firmando digitalmente i record per le ricerche DNS usando la crittografia a chiave pubblica. I controlli DNSSEC vengono eseguiti nei resolver DNS ricorsivi, i server DNS che eseguire query DNS per i client. DNSSEC garantisce che i record DNS non vengano manomessi e siano autenticati.

Dopo che i record di risorse correlati a MX, A/AAAA e DNSSEC per un dominio vengono restituiti al resolver ricorsivo DNS come DNSSEC autenticato, il server di posta elettronica di invio chiederà il record TLSA corrispondente alla voce o alle voci host MX. Se il record TLSA è presente e ha dimostrato l'autenticità usando un altro controllo DNSSEC, il resolver ricorsivo DNS restituirà il record TLSA al server di posta elettronica di invio.

Dopo aver ricevuto il record TLSA autenticato, il server di posta elettronica di invio stabilisce una connessione SMTP all'host MX associato al record TLSA autenticato. Il server di posta elettronica di invio tenterà di configurare TLS e confrontare il certificato TLS del server con i dati nel record TLSA per verificare che il server di posta di destinazione connesso al mittente sia il server di posta legittimo ricevente. Il messaggio verrà trasmesso (usando TLS) se l'autenticazione ha esito positivo. Quando l'autenticazione non riesce o se TLS non è supportato dal server di destinazione, Exchange Online ritenterà l'intero processo di convalida a partire da una query DNS per lo stesso dominio di destinazione dopo 15 minuti, quindi 15 minuti dopo, quindi ogni ora per le 24 ore successive. Se l'autenticazione continua a non riuscire dopo 24 ore di ripetizione dei tentativi, il messaggio scadrà e verrà generato e inviato al mittente un rapporto di mancato recapito con i dettagli dell'errore.

Consiglio

Se non si è un cliente E5, usare la versione di valutazione delle soluzioni Microsoft Purview di 90 giorni per esplorare in che modo funzionalità aggiuntive di Purview possono aiutare l'organizzazione a gestire le esigenze di sicurezza e conformità dei dati. Iniziare ora dall'hub delle versioni di valutazione Portale di conformità di Microsoft Purview. Informazioni dettagliate sull'iscrizione e le condizioni di valutazione.

Quali sono i componenti di DANE?

Record di risorse TLSA

Il record TLS Authentication (TLSA) viene usato per associare il certificato X.509 di un server o il valore della chiave pubblica al nome di dominio che contiene il record. I record TLSA possono essere considerati attendibili solo se DNSSEC è abilitato nel dominio. Se si usa un provider DNS per ospitare il dominio, DNSSEC può essere un'impostazione offerta durante la configurazione di un dominio con essi. Per altre informazioni sulla firma della zona DNSSEC, visitare questo collegamento: Panoramica di DNSSEC | Microsoft Docs.

Record TLSA di esempio:

Sono disponibili quattro campi configurabili univoci per il tipo di record TLSA:

Campo utilizzo certificato: specifica come il server di posta elettronica di invio deve verificare il certificato del server di posta elettronica di destinazione.

Valore	Acronimo	Descrizione
0¹	PKIX-TA	Il certificato usato è l'autorità di certificazione pubblica di trust anchor della catena di attendibilità X.509.
1¹	PKIX-EE	Il certificato selezionato è il server di destinazione; I controlli DNSSEC devono verificarne l'autenticità.
2	DANE-TA	Usare la chiave privata del server dall'albero X.509 che deve essere convalidata da un ancoraggio di trust nella catena di trust. Il record TLSA specifica l'ancoraggio di trust da usare per convalidare i certificati TLS per il dominio.
3	DANE-EE	Corrisponde solo al certificato del server di destinazione.

¹ Exchange Online segue le linee guida per l'implementazione rfc che i valori del campo di utilizzo del certificato pari a 0 o 1 non devono essere usati quando dane viene implementato con SMTP. Quando un record TLSA con un valore di campo Utilizzo certificato pari a 0 o 1 viene restituito a Exchange Online, Exchange Online lo considererà non utilizzabile. Se tutti i record TLSA vengono trovati inutilizzabili, Exchange Online non eseguirà i passaggi di convalida DANE per 0 o 1 durante l'invio del messaggio di posta elettronica. Invece, a causa della presenza di un record TLSA, Exchange Online imporrà l'uso di TLS per l'invio del messaggio di posta elettronica, inviando il messaggio di posta elettronica se il server di posta elettronica di destinazione supporta TLS o eliminando il messaggio di posta elettronica e generando un rapporto di mancato recapito se il server di posta elettronica di destinazione non supporta TLS.

Nel record TLSA di esempio, il campo Utilizzo certificato è impostato su '3', quindi i dati dell'associazione di certificati ('abc123... xyz789') verrebbe confrontato solo con il certificato del server di destinazione.

Campo selettore: indica quali parti del certificato del server di destinazione devono essere controllate.

Valore	Acronimo	Descrizione
0	Cert	Usare il certificato completo.
1	SPKI (Informazioni sulla chiave pubblica soggetto)	Usare la chiave pubblica del certificato e l'algoritmo con cui viene identificata la chiave pubblica da usare.

Nel record TLSA di esempio, il campo del selettore è impostato su '1' in modo che i dati dell'associazione di certificati vengano confrontati usando la chiave pubblica del certificato del server di destinazione e l'algoritmo con cui viene identificata la chiave pubblica da usare.

Campo tipo corrispondente: indica il formato in cui il certificato verrà rappresentato nel record TLSA.

Valore	Acronimo	Descrizione
0	Full	I dati nel record TSLA sono il certificato completo o l'spki.
1	SHA-256	I dati nel record TSLA sono un hash SHA-256 del certificato o dell'SPKI.
2	SHA-512	I dati nel record TSLA sono un hash SHA-512 del certificato o dell'SPKI.

Nel record TLSA di esempio, il campo Tipo di corrispondenza è impostato su '1' in modo che i dati dell'associazione di certificati siano un hash SHA-256 delle informazioni sulla chiave pubblica soggetto dal certificato del server di destinazione

Dati dell'associazione di certificati: specifica i dati del certificato usati per la corrispondenza con il certificato del server di destinazione. Questi dati dipendono dal valore del campo selettore e dal valore del tipo di corrispondenza.

Nel record TLSA di esempio, i dati dell'associazione di certificati sono impostati su 'abc123.. xyz789'. Poiché il valore Campo selettore nell'esempio è impostato su '1', fa riferimento alla chiave pubblica del certificato del server di destinazione e all'algoritmo identificato per l'uso. Poiché il valore del campo Tipo di corrispondenza nell'esempio è impostato su '1', fa riferimento all'hash SHA-256 delle informazioni sulla chiave pubblica soggetto dal certificato del server di destinazione.

In che modo Exchange Online clienti possono usare SMTP DANE In uscita?

In qualità di cliente Exchange Online, non è necessario eseguire alcuna operazione per configurare questa sicurezza avanzata della posta elettronica per la posta elettronica in uscita. Questa sicurezza avanzata della posta elettronica è stata creata per te ed è attiva per impostazione predefinita per tutti i clienti Exchange Online e viene usata quando il dominio di destinazione annuncia il supporto per DANE. Per sfruttare i vantaggi dell'invio di posta elettronica con i controlli DNSSEC e DANE, comunicare ai partner aziendali con cui si scambia la posta elettronica di cui hanno bisogno per implementare DNSSEC e DANE in modo che possano ricevere messaggi di posta elettronica usando questi standard.

In che modo Exchange Online clienti possono usare SMTP DANE in ingresso?

Attualmente, l'accesso DANE SMTP in ingresso non è supportato per Exchange Online. Il supporto per SMTP DANE in ingresso sarà disponibile nel prossimo futuro.

Qual è la configurazione di record TLSA consigliata?

Per indicazioni sull'implementazione RFC per SMTP DANE, è consigliabile usare un record TLSA composto dal campo Utilizzo certificato impostato su 3, dal campo Selettore impostato su 1 e dal campo Tipo di corrispondenza impostato su 1.

flusso di posta Exchange Online con DANE SMTP

Il processo del flusso di posta per Exchange Online con SMTP DANE, illustrato nel grafico di flusso seguente, convalida la sicurezza dei record di dominio e risorse tramite DNSSEC, il supporto TLS nel server di posta elettronica di destinazione e che il certificato del server di posta di destinazione corrisponde a quanto previsto in base al record TLSA associato.

Esistono solo due scenari in cui un errore SMTP DANE comporterà il blocco del messaggio di posta elettronica:

Il dominio di destinazione ha segnalato il supporto DNSSEC, ma uno o più record sono stati restituiti come non autenticati.
Tutti i record MX per il dominio di destinazione hanno record TLSA e nessuno dei certificati del server di destinazione corrisponde a quello previsto per i dati del record TSLA oppure una connessione TLS non è supportata dal server di destinazione.

Tecnologia	Informazioni aggiuntive
Mail Transfer Agent - Strict Transport Security (MTA-STS) consente di contrastare il downgrade e gli attacchi Man-in-the-Middle fornendo un meccanismo per l'impostazione di criteri di dominio che specificano se il server di posta elettronica di destinazione supporta TLS e cosa fare quando TLS non può essere negoziato, ad esempio arrestare la trasmissione.	Altre informazioni sul supporto imminente di Exchange Online per MTA-STS in ingresso e in uscita saranno pubblicate entro la fine dell'anno. Exchange Online transport news from Microsoft Ignite 2020 - Microsoft Tech Community rfc8461 (ietf.org)
Sender Policy Framework (SPF) usa le informazioni IP per garantire che i sistemi di posta elettronica di destinazione consideri attendibili i messaggi inviati dal dominio personalizzato.	Come Sender Policy Framework (SPF) impedisce lo spoofing
DomainKeys Identified Mail (DKIM) usa le informazioni sul certificato X.509 per garantire che i sistemi di posta elettronica di destinazione considerino attendibili i messaggi inviati in uscita dal dominio personalizzato.	Come usare DKIM per la posta elettronica nel dominio personalizzato
L'autenticazione dei messaggi basata su dominio, la creazione di report e la conformità (DMARC) funziona con Sender Policy Framework e DomainKeys Identified Mail per autenticare i mittenti di posta elettronica e assicurarsi che i sistemi di posta elettronica di destinazione considerino attendibili i messaggi inviati dal dominio.	Usare DMARC per convalidare la posta elettronica: procedura di configurazione

Risoluzione dei problemi relativi all'invio di messaggi di posta elettronica con SMTP DANE

Attualmente, esistono quattro codici di errore per DANE quando si inviano messaggi di posta elettronica con Exchange Online. Microsoft sta aggiornando attivamente questo elenco di codici di errore. Gli errori saranno visibili in:

Portale di Exchange Amministrazione Center tramite la visualizzazione Dettagli traccia messaggi.
NDR generati quando un messaggio non viene inviato a causa di un errore DANE o DNSSEC.
Strumento Analizzatore connettività remota Microsoft Remote Connectivity Analyzer.

Codice rapporto di mancato recapito	Descrizione
4/5.7.321	starttls-not-supported: il server di posta di destinazione deve supportare TLS per ricevere la posta.
4/5.7.322	certificate-expired: il certificato del server di posta di destinazione è scaduto.
4/5.7.323	tlsa-invalid: la convalida DANE del dominio non è riuscita.
4/5.7.324	dnssec-invalid: il dominio di destinazione ha restituito record DNSSEC non validi.

Nota

Attualmente, quando un dominio segnala che supporta DNSSEC ma non esegue i controlli DNSSEC, Exchange Online non genera l'errore dnssec-invalid 4/5.7.324. Genera un errore DNS generico:

4/5.4.312 DNS query failed

Stiamo lavorando attivamente per porre rimedio a questa limitazione nota. Se si riceve questa istruzione di errore, passare a Microsoft Remote Connectivity Analyzer ed eseguire il test di convalida DANE sul dominio che ha generato l'errore 4/5.4.312. I risultati mostreranno se si tratta di un problema DNSSEC o di un problema DNS diverso.

Risoluzione dei problemi 4/5.7.321 starttls-not-supported

Questo errore indica in genere un problema con il server di posta elettronica di destinazione. Dopo aver ricevuto il messaggio:

Verificare che l'indirizzo di posta elettronica di destinazione sia stato immesso correttamente.
Avvisare l'amministratore della posta elettronica di destinazione che ha ricevuto questo codice di errore in modo che possa determinare se il server di destinazione è configurato correttamente per ricevere messaggi tramite TLS.
Riprovare a inviare il messaggio di posta elettronica ed esaminare i dettagli di traccia dei messaggi per il messaggio nel portale di Exchange Amministrazione Center.

Risoluzione dei problemi relativi alla scadenza del certificato 4/5.7.322

Un certificato X.509 valido che non è scaduto deve essere presentato al server di posta elettronica di invio. I certificati X.509 vanno sempre rinnovati dopo la scadenza, che in genere è annuale. Dopo aver ricevuto il messaggio:

Avvisare l'amministratore di posta elettronica di destinazione che è stato ricevuto questo codice di errore e specificare la stringa del codice di errore.
Consente di rinnovare il certificato del server di destinazione e aggiornare il record TLSA per fare riferimento al nuovo certificato. Riprovare quindi a inviare il messaggio di posta elettronica ed esaminare i dettagli di traccia dei messaggi per il messaggio nel portale di Exchange Amministrazione Center.

Risoluzione dei problemi 4/5.7.323 tlsa-invalid

Questo codice di errore è correlato a una configurazione errata del record TLSA e può essere generato solo dopo la restituzione di un record TLSA autenticato da DNSSEC. Esistono molti scenari durante la convalida dane che si verificano dopo la restituzione del record che possono comportare la generazione del codice. Microsoft sta lavorando attivamente agli scenari coperti da questo codice di errore, in modo che ogni scenario abbia un codice specifico. Attualmente, uno o più di questi scenari potrebbero causare la generazione del codice di errore:

Il certificato del server di posta di destinazione non corrisponde a quello previsto per il record TLSA autentico.
Il record TLSA autenticato non è configurato correttamente.
Il dominio di destinazione viene attaccato.
Qualsiasi altro errore DANE.

Dopo aver ricevuto il messaggio:

Avvisare l'amministratore di posta elettronica di destinazione che è stato ricevuto questo codice di errore e specificare la stringa del codice di errore.
Consentire all'amministratore della posta elettronica di destinazione di esaminare la configurazione dane e la validità del certificato del server di posta elettronica. Riprovare quindi a inviare il messaggio di posta elettronica ed esaminare i dettagli di traccia dei messaggi per il messaggio nel portale di Exchange Amministrazione Center.

Risoluzione dei problemi 4/5.7.324 dnssec-invalid

Questo codice di errore viene generato quando il dominio di destinazione indica che è dnssec-authentic, ma Exchange Online non è stato in grado di verificarlo come DNSSEC-authentic.

Dopo aver ricevuto il messaggio:

Avvisare l'amministratore di posta elettronica di destinazione che è stato ricevuto questo codice di errore e specificare la stringa del codice di errore.
Consentire all'amministratore della posta elettronica di destinazione di esaminare la configurazione DNSSEC del dominio. Riprovare quindi a inviare il messaggio di posta elettronica ed esaminare i dettagli di traccia dei messaggi per il messaggio nel portale di Exchange Amministrazione Center.

Risoluzione dei problemi relativi alla ricezione di messaggi di posta elettronica con SMTP DANE

Attualmente, esistono due metodi che un amministratore di un dominio ricevente può usare per convalidare e risolvere i problemi relativi alla configurazione DNSSEC e DANE per ricevere messaggi di posta elettronica da Exchange Online usando questi standard.

Adottare SMTP TLS-RPT (Transport Layer Security Reporting) introdotto in RFC8460
Usare lo strumento Analizzatore connettività remota Microsoft Remote Connectivity Analyzer

TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 è un meccanismo di segnalazione che consente ai mittenti di fornire dettagli agli amministratori di dominio di destinazione sui successi e gli errori di DANE e MTA-STS con i rispettivi domini di destinazione. Per ricevere report TLS-RPT, è sufficiente aggiungere un record TXT nei record DNS del dominio che include l'indirizzo di posta elettronica o l'URI a cui si desidera inviare i report. Exchange Online invierà report TLS-RPT in formato JSON.

Record di esempio:

Il secondo metodo consiste nell'usare l'analizzatore connettività remota Microsoft Remote Connectivity Analyzer, che può eseguire gli stessi controlli DNSSEC e DANE sulla configurazione DNS che Exchange Online eseguiranno quando si inviano messaggi di posta elettronica all'esterno del servizio. Questo metodo è il modo più diretto per risolvere gli errori nella configurazione per ricevere messaggi di posta elettronica da Exchange Online usando questi standard.

Quando si verificano errori, è possibile che vengano generati i codici di errore seguenti:

Codice rapporto di mancato recapito	Descrizione
4/5.7.321	starttls-not-supported: il server di posta di destinazione deve supportare TLS per ricevere la posta.
4/5.7.322	certificato scaduto: il certificato del server di posta di destinazione è scaduto.
4/5.7.323	tlsa-invalid: la convalida DANE del dominio non è riuscita.
4/5.7.324	dnssec-invalid: il dominio di destinazione ha restituito record DNSSEC non validi.

Nota

Attualmente, quando un dominio segnala che supporta DNSSEC ma non esegue i controlli DNSSEC, Exchange Online non genera l'errore dnssec-invalid 4/5.7.324. Genera un errore DNS generico:

4/5.4.312 DNS query failed

Risoluzione dei problemi 4/5.7.321 starttls-not-supported

Nota

Questi passaggi consentono agli amministratori della posta elettronica di risolvere i problemi relativi alla ricezione di messaggi di posta elettronica da Exchange Online tramite SMTP DANE.

Questo errore indica in genere un problema con il server di posta elettronica di destinazione. Server di posta con cui l'analizzatore connettività remota sta testando la connessione. Esistono in genere due scenari che generano questo codice:

Il server di posta elettronica di destinazione non supporta affatto la comunicazione sicura e deve essere usata una comunicazione semplice e non crittografata.
Il server di destinazione non è configurato correttamente e ignora il comando STARTTLS.

Dopo aver ricevuto il messaggio:

Controllare l'indirizzo di posta elettronica.
Individuare l'indirizzo IP associato all'istruzione di errore in modo da poter identificare il server di posta a cui è associata l'istruzione.
Controllare l'impostazione del server di posta elettronica per assicurarsi che sia configurato per l'ascolto del traffico SMTP (in genere le porte 25 e 587).
Attendere alcuni minuti, quindi ritentare il test con lo strumento Analizzatore connettività remota.
Se il problema persiste, provare a rimuovere il record TLSA ed eseguire di nuovo il test con lo strumento Analizzatore connettività remota.
Se non si verificano errori, questo messaggio potrebbe indicare che il server di posta che si sta usando per ricevere la posta non supporta STARTTLS e potrebbe essere necessario eseguire l'aggiornamento a uno che lo fa per usare DANE.

Risoluzione dei problemi relativi alla scadenza del certificato 4/5.7.322

Nota

Questi passaggi consentono agli amministratori della posta elettronica di risolvere i problemi relativi alla ricezione di messaggi di posta elettronica da Exchange Online tramite SMTP DANE.

Controllare l'INDIRIZZO IP associato all'istruzione di errore, in modo da poter identificare il server di posta a cui è associato. Individuare il certificato scaduto nel server di posta elettronica identificato.
Accedere al sito Web del provider di certificati.
Selezionare il certificato scaduto e seguire le istruzioni per rinnovare e pagare il rinnovo.
Dopo che il provider ha verificato l'acquisto, è possibile scaricare un nuovo certificato.
Installare il certificato rinnovato nel server di posta associato.
Aggiornare il record TLSA associato al server di posta elettronica con i dati del nuovo certificato.
Dopo aver atteso un periodo di tempo appropriato, ripetere il test con lo strumento Analizzatore connettività remota.

Risoluzione dei problemi 4/5.7.323 tlsa-invalid

Nota

Questi passaggi consentono agli amministratori della posta elettronica di risolvere i problemi relativi alla ricezione di messaggi di posta elettronica da Exchange Online tramite SMTP DANE.

Questo codice di errore è correlato a una configurazione errata del record TLSA e può essere generato solo dopo la restituzione di un record TSLA autenticato da DNSSEC. Tuttavia, esistono molti scenari durante la convalida dane che si verificano dopo la restituzione del record che possono comportare la generazione del codice. Microsoft sta lavorando attivamente agli scenari coperti da questo codice di errore, in modo che ogni scenario abbia un codice specifico. Attualmente, uno o più di questi scenari potrebbero causare la generazione del codice di errore:

Il record TLSA autenticato non è configurato correttamente.
Il certificato non è ancora valido o configurato per un intervallo di tempo futuro.
Il dominio di destinazione è stato attaccato.
Qualsiasi altro errore DANE.

Dopo aver ricevuto il messaggio:

Controllare l'INDIRIZZO IP associato all'istruzione di errore per identificare il server di posta a cui è associato.
Identificare il record TLSA associato al server di posta identificato.
Verificare la configurazione del record TLSA per assicurarsi che segnali al mittente di eseguire i controlli DANE preferiti e che i dati del certificato corretti siano stati inclusi nel record TLSA.
1. Se è necessario apportare eventuali aggiornamenti al record per individuare eventuali discrepanze, attendere alcuni minuti ed eseguire nuovamente il test con lo strumento Analizzatore connettività remota.
Individuare il certificato nel server di posta identificato.
Controllare l'intervallo di tempo per cui il certificato è valido. Se è impostato per iniziare la validità in una data futura, deve essere rinnovato per la data corrente.
1. Accedere al sito Web del provider di certificati.
2. Selezionare il certificato scaduto e seguire le istruzioni per rinnovare e pagare il rinnovo.
3. Dopo che il provider ha verificato l'acquisto, è possibile scaricare un nuovo certificato.
4. Installare il certificato rinnovato nel server di posta associato.

Risoluzione dei problemi 4/5.7.324 dnssec-invalid

Nota

Questi passaggi consentono agli amministratori della posta elettronica di risolvere i problemi relativi alla ricezione di messaggi di posta elettronica da Exchange Online tramite SMTP DANE.

Questo codice di errore viene generato quando il dominio di destinazione indica che è DNSSEC-authentic, ma Exchange Online non è in grado di verificarlo come DNSSEC-authentic. Questa sezione non sarà completa per la risoluzione dei problemi DNSSEC e si concentrerà sugli scenari in cui i domini hanno passato in precedenza l'autenticazione DNSSEC, ma non ora.

Dopo aver ricevuto il messaggio:

Se si usa un provider DNS, ad esempio GoDaddy, avvisare il provider DNS dell'errore in modo che possa lavorare alla risoluzione dei problemi e alla modifica della configurazione.
Se si gestisce un'infrastruttura DNSSEC personalizzata, esistono molte configurazioni non corrette di DNSSEC che possono generare questo messaggio di errore. Alcuni problemi comuni per verificare se la zona passava in precedenza l'autenticazione DNSSEC:
1. Catena di trust interrotta, quando la zona padre contiene un set di record DS che puntano a qualcosa che non esiste nella zona figlio. Tali puntatori da record DS possono comportare la contrassegna della zona figlio come fittizia convalidando i resolver.
  - Risolvere esaminando gli ID chiave RRSIG dei domini figlio e verificando che corrispondano agli ID chiave nei record DS pubblicati nella zona padre.
2. Il record di risorse RRSIG per il dominio non è valido in tempo, è scaduto o il periodo di validità non è iniziato.
  - Risolvere generando nuove firme per il dominio usando intervalli di tempo validi.

Nota

Questo codice di errore viene generato anche se Exchange Online riceve la risposta SERVFAIL dal server DNS nella query TLSA per il dominio di destinazione.

Quando viene inviato un messaggio di posta elettronica in uscita, se il dominio ricevente ha DNSSEC abilitato, viene eseguita una query per i record TLSA associati alle voci MX nel dominio. Se non viene pubblicato alcun record TLSA, la risposta alla ricerca TLSA deve essere NOERROR (nessun record di tipo richiesto per questo dominio) o NXDOMAIN (non esiste tale dominio). DNSSEC richiede questa risposta se non viene pubblicato alcun record TLSA; in caso contrario, Exchange Online interpreta la mancanza di risposta come un errore SERVFAIL. Come da RFC 7672, una risposta SERVFAIL non è attendibile; pertanto, il dominio di destinazione non riesce la convalida DNSSEC. Questo messaggio di posta elettronica viene quindi posticipato con l'errore seguente:

450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records

Se il mittente del messaggio segnala la ricezione del messaggio

Se si usa un provider DNS, ad esempio GoDaddy, avvisare il provider DNS dell'errore in modo che possa risolvere i problemi relativi alla risposta DNS. Se si gestisce un'infrastruttura DNSSEC personalizzata, potrebbe trattarsi di un problema con il server DNS stesso o con la rete.

Domande frequenti

In qualità di cliente Exchange Online, è possibile rifiutare esplicitamente l'uso di DNSSEC e/o DANE?

Siamo fermamente convinti che DNSSEC e DANE aumenteranno significativamente la posizione di sicurezza del nostro servizio e andranno a vantaggio di tutti i nostri clienti. Nell'ultimo anno abbiamo lavorato diligentemente per ridurre il rischio e la gravità del potenziale impatto che questa distribuzione potrebbe avere per i clienti di Microsoft 365. La distribuzione verrà monitorata e monitorata attivamente per garantire che l'impatto negativo sia ridotto al minimo durante l'implementazione. Per questo motivo, le eccezioni a livello di tenant o il rifiuto esplicito non saranno disponibili. Se si verificano problemi relativi all'abilitazione di DNSSEC e/o DANE, i diversi metodi per l'analisi degli errori annotati in questo documento consentono di identificare l'origine dell'errore. Nella maggior parte dei casi, il problema riguarda la parte di destinazione esterna ed è necessario comunicare a questi partner commerciali che devono configurare correttamente DNSSEC e DANE per ricevere messaggi di posta elettronica da Exchange Online usando questi standard.

In che modo DNSSEC è correlato a DANE?

DNSSEC aggiunge un livello di attendibilità alla risoluzione DNS applicando l'infrastruttura a chiave pubblica per garantire che i record restituiti in risposta a una query DNS siano autentici. DANE garantisce che il server di posta ricevente sia il server di posta legittimo e previsto per il record MX autenticato.

Qual è la differenza tra MTA-STS e DANE per SMTP?

DANE e MTA-STS hanno lo stesso scopo, ma DANE richiede DNSSEC per l'autenticazione DNS, mentre MTA-STS si basa sulle autorità di certificazione.

Perché TLS opportunistico non è sufficiente?

TLS opportunistico crittograferà la comunicazione tra due endpoint se entrambi accettano di supportarla. Tuttavia, anche se TLS crittografa la trasmissione, un dominio potrebbe essere falsificato durante la risoluzione DNS in modo che punti all'endpoint di un attore malintenzionato anziché all'endpoint reale per il dominio. Questo spoofing è un gap nella sicurezza della posta elettronica che viene risolto implementando MTA-STS e/o SMTP DANE con DNSSEC.

Perché DNSSEC non è sufficiente?

DNSSEC non è completamente resistente agli attacchi Man-in-the-Middle e agli attacchi di downgrade (da TLS a testo non crittografato) per gli scenari di flusso di posta. L'aggiunta di MTA-STS e DANE insieme a DNSSEC offre un metodo di sicurezza completo per contrastare gli attacchi MITM e downgrade.

Collegamenti aggiuntivi

Individuare e correggere i problemi dopo l'aggiunta del dominio o dei record DNS

Panoramica di DNSSEC | Microsoft Docs

Usare DMARC per convalidare la posta elettronica, i passaggi di configurazione - Office 365 | Microsoft Docs

Come usare DKIM per la posta elettronica nel dominio personalizzato - Office 365 | Microsoft Docs

Come Sender Policy Framework (SPF) impedisce lo spoofing - Office 365 | Microsoft Docs

Exchange Online transport news from Microsoft Ignite 2020 - Microsoft Tech Community

rfc8461 (ietf.org)

Funzionamento dell'autenticazione basata su DNS SMTP delle entità denominate (DANE)