Condividi tramite

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

  • Articolo

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 relativi server di posta supportano DANE. Se non è presente alcun record TLSA, la risoluzione DNS per il flusso di posta funziona 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 sistema di risoluzione ricorsivo DNS come dnssec autenticato, il server di posta elettronica di invio richiede 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 restituisce 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 tenta 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 viene 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.

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:

Screenshot che mostra un esempio di record TLSA.

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
01 PKIX-TA Il certificato usato è l'autorità di certificazione pubblica di trust anchor della catena di attendibilità X.509.
11 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.

1 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 considera 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 applica 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 di corrispondenza: indica il formato in cui il certificato è 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', quindi i dati dell'associazione di certificati sono 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.

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 comporta 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.

    Screenshot che mostra il flusso di posta online di Exchange con SMTP DANE.

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

Dane SMTP in ingresso con DNSSEC

Prerequisiti

Prima di iniziare, assicurarsi di soddisfare i prerequisiti seguenti:

  1. È necessario aver aggiunto il dominio come "Dominio accettato" e lo stato del dominio deve essere "Integro" nel Centro Amministrazione Microsoft 365. La documentazione presuppone che il record MX del dominio sia impostato sulla priorità 0 o 10 e che non sia presente alcun record MX secondario o di "fallback". Se si dispone di un record MX di fallback, è necessario collaborare a stretto contatto con l'amministratore Exchange Online per garantire che le modifiche vengano eseguite correttamente.
  2. Per ottenere tutti i vantaggi di sicurezza della funzionalità, assicurarsi di aver abilitato DNSSEC per il dominio.
  3. È necessario avere accesso a Exchange Online PowerShell e le autorizzazioni per eseguire i cmdlet descritti in Exchange Online PowerShell
  4. Se si fa riferimento al dominio che si vuole proteggere con DANE SMTP in ingresso con DNSSEC in qualsiasi configurazione smarthost o in qualsiasi connettore, è necessario passare al nome smarthost prima tenantname.mail.protection.outlook.com di seguire la procedura.

Nota

Se si vuole abilitare DNSSEC per un dominio che usa un gateway di terze parti, è possibile eseguire questa operazione seguendo i passaggi da 1 a 3, seguendo la nota alla fine del passaggio 3 nei gateway di terze parti.

Avviso

Se si vuole configurare l'accesso DANE SMTP in ingresso con DNSSEC per il "dominio accettato" contoso.come i partner aziendali usano connettori per l'endpoint contoso-com.mail.protection.outlook.com , è necessario collaborare con i partner in modo che aggiornino i connettori in modo che facciano riferimento all'endpoint tenantname.onmicrosoft.com o all'endpoint prima di configurare l'accesso tenantname.mail.protection.outlook.com DANE SMTP in ingresso con DNSSEC. In caso contrario, la posta elettronica dei connettori dei partner aziendali non riesce dopo aver completato l'abilitazione. Dopo aver completato l'abilitazione, i partner possono usare il nuovo contoso-com.<random>.mx.microsoft endpoint per ristabilire il connettore originale.

Configurare l'interfaccia DANE SMTP in ingresso con DNSSEC

Nota

Il completamento del provisioning e degli aggiornamenti dei record DNS può richiedere del tempo. Le modifiche DNS possono richiedere più tempo del previsto per diventare visibili a causa di più livelli di memorizzazione nella cache.

Per configurare SMTP DANE in ingresso con DNSSEC, seguire questa procedura:

  1. Aggiornare il TTL del record MX esistente al TTL più basso possibile (ma non inferiore a 30 secondi). Attendere quindi che il TTL precedente scada prima di procedere. Ad esempio, se il TTL del record MX esistente era "3600 secondi" o "1 ora" prima di modificarlo, è necessario attendere 1 ora prima di procedere al passaggio 2.

  2. Connettersi a PowerShell di Exchange Online.

    Avviso

    Se si usa MTA-STS, è necessario impostare la modalità dei criteri su "testing" e aggiornare l'ID nel record txt MTA-STS. È possibile usare l'ora corrente in formato UTC come nuovo ID criterio. Attendere quindi che il "max_age" del criterio scada prima di procedere. Ad esempio, se il "max_age" del criterio stS esistente era 3600 secondi o 1 ora prima della modifica, è necessario attendere "1 ora" prima di procedere.

  3. Per il dominio per cui si vuole abilitare SMTP DANE con DNSSEC, è necessario prima abilitare DNSSEC nel dominio eseguendo il comando seguente (sostituire "domain" con il nome del dominio scelto, ad esempio, contosotest.com):

    Enable-DnssecForVerifiedDomain -DomainName <DomainName>

    Nota

    L'esecuzione di questo comando può richiedere alcuni minuti.

    Output di esempio dell'esecuzione riuscita

    Risultato DnssecMxValue ErrorData
    Esito positivo contosotest-com.o-v1.mx.microsoft

    La risposta di esito positivo fornisce il valore MX per il dominio. Questo valore è il nome a cui punta il nuovo record MX per il dominio che si sta abilitando con DNSSEC. Ad esempio, contosotest-com.o-v1.mx.microsoft.

  4. Prendere il valore "DnssecMxValue", passare al registrar DNS che ospita il dominio, aggiungere un nuovo record MX usando il valore restituito nel passaggio 3, impostare il TTL sul valore più basso possibile (ma non inferiore a 30 secondi) e impostare la priorità del nuovo record MX su 20.

    Nota

    Se si usa un gateway di posta elettronica di terze parti e si vuole usare questo valore come nuovo host di destinazione Exchange Online a cui il gateway di posta elettronica di terze parti invierà la posta in ingresso, passare al portale di amministrazione di terze parti, aggiornare lo smart host di destinazione usato da terze parti per inviare a Exchange Online, quindi verificare che "il flusso di posta funzioni tramite il test DNSSEC (assicurarsi di selezionare "Convalida DNSSEC" durante l'input di test, non "Convalida DANE [incluso DNSSEC])" in Microsoft Remote Connectivity Analyzer: Test Input". Se il flusso della posta viene eseguito come previsto, NON è necessario continuare seguendo la procedura seguente. Se si vuole abilitare SMTP DANE per questo dominio, andare al passaggio 7.

    Avviso

    Se si usa MTA-STS, assicurarsi che la modalità dei criteri sia impostata su "testing". Eliminare quindi la riga mx corrente contenente le informazioni del record MX legacy e aggiungere il nuovo nome di dominio completo al file dei criteri MTA-STS come nuova riga mx. Aggiornare quindi l'ID dei criteri nei criteri e nel record TXT MTA-STS (è possibile usare l'ora corrente in formato UTC come nuovo ID criterio).

  5. Verificare che il nuovo MX funzioni tramite il test smtp in ingresso Email (https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input) espandendo i passaggi di test e verificando che Mail Exchanger che termina con mx.microsoft sia stato testato correttamente. Potrebbe essere necessario ripetere questo test, a seconda della memorizzazione nella cache DNS.

    Output dell'esito positivo di esempio

    Screenshot che mostra l'esempio di un output che notifica l'esito positivo del processo implementato.

  6. Modificare la priorità dell'MX legacy che punta a mail.protection.outlook.com dalla priorità corrente a 30; modificare la priorità del record MX creato nel passaggio 3 in modo che sia impostato sulla priorità 0 (priorità più alta).

  7. Eliminare il record MX legacy che termina con "mail.protection.outlook.com", "mail.eo.outlook.com" o "mail.protection.outlook.de". Aggiornare quindi il TTL per il record MX che termina con mx.microsoft a 3600 secondi. Facoltativamente, è possibile verificare che tutto funzioni come previsto usando il test DNSSEC (assicurarsi di selezionare "Convalida DNSSEC" durante l'input di test, non "Convalida DANE [incluso DNSSEC])" in Remote Connectivity Analyzer. Potrebbe essere necessario ripetere questo test, a seconda della memorizzazione nella cache DNS e delle TTL.

    Una volta scadute le TTL nel record MX legacy, un output con esito positivo sarà simile al seguente:

    Screenshot che mostra l'esempio di un output che notifica che i domini hanno superato correttamente il test di convalida DNSSEC.

  8. Eseguire il comando seguente [replace (DomainName) con il nome del dominio scelto, ad esempio contosotest.com] se si desidera abilitare SMTP DANE per lo stesso dominio al termine dell'abilitazione DNSSEC:

    Enable-SmtpDaneInbound -DomainName <DomainName>
    Risultato ErrorData
    Esito positivo

  9. Verificare che il record TLSA sia stato propagato (che può richiedere da 15 a 30 minuti) usando uno strumento online di propria scelta e Microsoft Remote Connectivity Analyzer: Test Input.

    Dopo aver completato l'abilitazione DNSSEC e aver effettuato il provisioning del record SMTP DANE (TLSA) da Exchange Online, viene visualizzato un output corretto, come illustrato nello screenshot seguente:

    Screenshot che mostra l'esempio di un output che notifica che i domini hanno superato correttamente il test di convalida dane.

    Exchange Online ospita più record TLSA per aumentare l'affidabilità di un esito positivo delle convalide DANE SMTP. È previsto che alcuni record TLSA non riescano a eseguire la convalida. Finché 1 record TLSA passa la convalida, SMTP DANE viene configurato correttamente e il messaggio di posta elettronica è protetto con SMTP DANE.

    Avviso

    Se si usa MTA-STS, dopo aver verificato che i criteri funzionano e che il flusso della posta elettronica viene eseguito come previsto, impostare nuovamente la modalità dei criteri su "imponi" e aggiornare l'ID nel record txt MTA-STS. È possibile usare l'ora corrente in formato UTC come nuovo ID criterio.

Limitazioni

  1. Domini di iscrizione virali o self-service: i domini configurati come "self-service" non sono attualmente supportati con DANE SMTP in ingresso con DNSSEC.
  2. onmicrosoft.com domini: il dominio "onmicrosoft.com" per il tenant non è attualmente supportato con DANE SMTP in ingresso con DNSSEC. Si sta esaminando il supporto per l'interfaccia DANE SMTP in ingresso con DNSSEC per i domini onmicrosoft.com. tuttavia, l'ETA è sconosciuto.
  3. Gateway di terze parti: i clienti che usano un gateway di posta elettronica di terze parti nel percorso in ingresso (che accetta la posta per il tenant, esegue alcune elaborazioni e quindi lo inoltra a Exchange Online) potranno usare questa funzionalità solo per proteggere i messaggi di posta elettronica inoltrati dal gateway di terze parti a Exchange Online se il gateway di terze parti supporta SMTP DANE con convalida DNSSEC. I clienti in questa configurazione devono configurare IL DANE SMTP in ingresso con DNSSEC usando Exchange PowerShell.
  4. Altra integrazione di terze parti con il flusso di posta elettronica: ci sono clienti per i gateway di terze parti nel percorso in uscita, in cui il messaggio di posta elettronica viene inviato a terze parti tramite un connettore, la terza parte esegue alcune elaborazioni e quindi invia di nuovo a Exchange Online, quindi Exchange Online infine invia il messaggio di posta elettronica. Questi clienti potrebbero dover collaborare con il provider di terze parti quando abilitano la funzionalità in modo che non si verifichino interruzioni. L'inoltro di terze parti deve usare una ricerca DNS durante l'invio del messaggio di posta elettronica a Exchange Online e usare il nuovo nome host del record MX -> contoso-com. subdomain).mx.microsoft creato durante l'abilitazione della funzionalità. La terza parte NON DEVE usare il nome host del record MX precedente:> contoso-com.mail.protection.outlook.com come Exchange Online eliminerà il record A circa entro 2 giorni (48 ore) dopo l'abilitazione della funzionalità una volta raggiunta la disponibilità generale.
  5. Domini completamente delegati: i domini ospitati da Microsoft e che usano la delega NS in modo che i server dei nomi di Microsoft siano autorevoli per il dominio sono supportati con DANE SMTP in ingresso con DNSSEC. Si prevede di supportare l'interfaccia DANE SMTP in ingresso con DNSSEC per questi domini; tuttavia, l'ETA è sconosciuto.

Problemi di debug che si verificano durante l'abilitazione del dane SMTP in ingresso con DNSSEC

Problemi relativi a Enable/Disable-DnssecForVerifiedDomain e Enable/Disable-SmtpDane Inbound

  1. DomainNotFound

    Messaggio (DNSSEC): "L'abilitazione/disabilitazione DNSSEC non è riuscita a causa di contoso.com di dominio non esistenti in AAD".
    Messaggi (SMTP DANE):

    • 'Smtp DANE enabling/disabling failed due to domain contoso.com not existing in AAD.'
    • "L'abilitazione/disabilitazione di SMTP DANE non è riuscita a causa del dominio contoso.com non trovato nell'elenco dei domini accettati."
      Causa: il dominio specificato non è stato trovato nell'elenco dei domini accettati.
      Azioni da eseguire: passare al Centro Amministrazione Microsoft 365 e verificare che il dominio sia stato verificato con il tenant. Se il dominio è integro nel Centro Amministrazione Microsoft 365, passare a Exchange Amministrazione Center e verificare che il dominio sia stato aggiunto come "Dominio accettato".

    DNSSEC

    Risultato DnssecMxValue ErrorData
    Error ErrorCode: 'DomainNotFound' ErrorDetails 'DNSSEC enabling failed...

    SMTP DANE

    Risultato ErrorData
    Error ErrorCode: 'DomainNotFound' ErrorDetails 'SMTP DANE enabling...

  2. DnsSecOperationFailed

    Messaggio (DNSSEC):"L'abilitazione/disabilitazione DNSSEC non è riuscita a causa di AdditionalErrorDetails. Ripetere l'operazione in un secondo momento."
    Messaggi (DANE SMTP): abilitazione/disabilitazione del dane SMTP non riuscita a causa di AdditionalErrorDetails. Ripetere l'operazione in un secondo momento.
    Causa: tentativo di creare la zona DNS e/o i record appropriati non riusciti.
    Azioni da eseguire: provare a eseguire nuovamente il cmdlet.

    DNSSEC

    Risultato DnssecMxValue ErrorData
    Error ErrorCode: 'DnssecOperationFailed' ErrorDetails 'DNSSEC enabling failed...

    SMTP DANE

    Risultato ErrorData
    Error ErrorCode: 'DnssecOperationFailed' ErrorDetails 'SMTP DANE enabling ...

  3. PartitionNotFound

    Messaggi (DANE SMTP): "L'abilitazione/disabilitazione del DANE SMTP non è riuscita a causa di contoso.com di dominio che non hanno una partizione".
    Causa: DNSSEC non è abilitato per il dominio.
    Azioni da intraprendere: assicurarsi di usare un dominio abilitato per DNSSEC.

    Risultato ErrorData
    Error ErrorCode: 'PartitionNotFound' ErrorDetails 'SMTP DANE enabling

  4. DomainNotSupported

    Messaggio (DNSSEC): 'Il dominio specificato è un dominio onmicrosoft: contoso-com.onmicrosoft.com.'
    Messages (SMTP DANE): 'Il dominio specificato è un dominio onmicrosoft: contoso-com.onmicrosoft.com.'
    Causa: il dominio è un dominio iniziale o MOERA. Questi elementi non sono attualmente supportati.
    Azioni da intraprendere: assicurarsi di usare un dominio che non termina con "onmicrosoft.com".

    DNSSEC

    Risultato DnssecMxValue ErrorData
    Error ErrorCode: 'DomainNotSupported' ErrorDetails 'Il dominio specificato ...

    SMTP DANE

    Risultato ErrorData
    Error ErrorCode: 'DomainNotSupported' ErrorDetails 'Il dominio specificato ...
Problemi con Get-DnssecStatusForVerifiedDomain

  1. Messaggio: 'EG001: Cannot retrieve DNSSEC feature status for domain [{domain}].'
    Causa: durante la convalida della configurazione del dominio in Exchange Online, è stato rilevato che il dominio non è stato aggiunto a Exchange Online. Se si ritiene di aver già aggiunto questo dominio a Exchange Online, ripetere l'esecuzione del cmdlet perché potrebbe trattarsi di un problema temporaneo.
    Azioni da eseguire: riprovare il cmdlet. Se continua a non riuscire, passare al Centro Amministrazione Microsoft 365 e completare il processo di installazione per questo dominio.

  2. Messaggio: 'EG002: Dominio [{dominio}] non verificato dominio dell'organizzazione.'
    Causa: durante la convalida della configurazione del dominio in Exchange Online, è stato rilevato che il dominio è stato aggiunto a Exchange Online ma non verificato.
    Azioni da intraprendere: passare al Centro Amministrazione Microsoft 365 e completare il processo di configurazione e verifica per questo dominio.

  3. Messaggio: "Errore di query DNS durante il recupero dei record MX per il dominio [{domain}].
    Causa: durante la convalida DNS si è verificato un errore DNS generico durante l'esecuzione di query sul dominio.
    Azioni da eseguire: riprovare a eseguire il cmdlet. Potrebbe essere necessario esaminare la configurazione per il dominio che si sta tentando di abilitare con SMTP DANE con DNSSEC.

  4. Messaggio: 'Dominio [{dominio}] non trovato.'
    Causa: durante la convalida DNS, si è verificato un errore NXDOMAIN durante l'esecuzione di query sul dominio.
    Azioni da eseguire: ripetere l'esecuzione del cmdlet dopo aver verificato la configurazione del record MX per il dominio. La propagazione DNS può richiedere fino a 48 ore per alcuni provider DNS.

  5. Messaggio: 'ED003: Dominio [{dominio}] trovato. Nessun record MX autenticato trovato.
    Causa: durante la convalida DNSSEC non è stato possibile trovare un record MX risolto in un record A protetto da DNSSEC (il record A per il valore "hostname" del record MX).
    Azioni da eseguire: ripetere l'esecuzione del cmdlet dopo aver verificato la configurazione del record MX per il dominio. La propagazione DNS può richiedere fino a 48 ore per alcuni provider DNS.

  6. Messaggio: 'EX002: Il valore del record MX non corrisponde a quello previsto'.
    Causa: durante la convalida MX non è stato trovato un record MX corrispondente a quello previsto.
    Azioni da intraprendere: esaminare i record MX nel dominio. Assicurarsi che un record MX corrisponda al record previsto restituito dopo l'esecuzione Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain.

  7. Messaggio: 'EX003: La priorità del record MX non corrisponde a quella prevista'.
    Causa: durante la convalida MX, è stato rilevato il record MX previsto, ma la priorità non è stata impostata su 0.
    Azioni da intraprendere: impostare il record MX (contenente il valore restituito durante l'esecuzione Enable-DnssecForVerifiedDomaino Get-DnssecStatusForVerifiedDomain) come priorità 0.

  8. Messaggio: 'EX004: Esiste un record MX diverso con la stessa preferenza di quello previsto'.
    Causa: durante la convalida MX, è stato rilevato che il record MX con priorità più alta non era il record MX previsto.
    Azioni da eseguire: se sono già stati completati i passaggi da 1 a 4 di Set up inbound SMTP DANE with DNSSEC (Configurare SMTP DANE in ingresso con DNSSEC), completare i passaggi 5 e 6 cambiando le priorità dei record MX in modo che l'MX previsto sia 0 (priorità più alta), convalidando la configurazione e quindi eliminando il record MX legacy.

  9. Messaggio: 'EX005: Esiste un record MX diverso con preferenza inferiore a quello previsto'.
    Causa: durante la convalida MX è stato trovato un record MX per il dominio che non corrisponde al record MX previsto.
    Azioni da eseguire: se sono già stati completati i passaggi da 1 a 5 di Set up inbound SMTP DANE with DNSSEC (Configurare IL DANE SMTP in ingresso con DNSSEC), completare il passaggio 6 eliminando il record MX legacy.

  10. Messaggio: 'EX006: Esiste un record MX diverso con preferenza superiore a quello previsto'.
    Causa: durante la convalida MX è stato trovato un record MX diverso con una preferenza superiore a quella prevista.
    Azioni da intraprendere: impostare il record MX legacy (che termina con mail.protection.outlook.com, mail.eo.outlook.com o mail.protection.outlook.de) come priorità 20.

  11. Messaggio: 'EX007: Record MX non trovato'.
    Causa: durante la convalida MX non è stato trovato un record MX corrispondente a quello previsto.
    Azioni da intraprendere: esaminare i record MX nel dominio. Assicurarsi che un record MX corrisponda al record previsto che viene restituito dopo l'esecuzione Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain.

  12. Messaggio: 'EX008: Il record MX corretto trovato, ma con una preferenza inferiore al previsto.'
    Causa: durante la convalida MX è stato rilevato che la priorità del record MX previsto è errata.
    Azioni da intraprendere: impostare il record MX (contenente il valore restituito durante l'esecuzione Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain) come priorità 0.

  13. Messaggio: 'EX009: Il record MX corretto trovato, ma con una preferenza superiore al previsto.'
    Causa: durante la convalida MX è stato rilevato che la priorità del record MX previsto è errata.
    Azioni da intraprendere: impostare il record MX (contenente il valore restituito durante l'esecuzione Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain) come priorità 0.

  14. Messaggio: 'EX010: Errore sconosciuto durante la ricerca di record MX nel dominio [{domain}].'
    Causa: durante la convalida MX si è verificato un errore DNS generico.
    Azioni da eseguire: ripetere l'esecuzione del cmdlet dopo aver verificato la configurazione del record MX per il dominio. La propagazione DNS può richiedere fino a 48 ore per alcuni provider DNS.

  15. Messaggio: 'EX012: Record MX non trovati per il dominio [{domain}].'
    Causa: durante la convalida MX non è stato trovato un record MX corrispondente a quello previsto.
    Azioni da intraprendere: esaminare i record MX nel dominio. Assicurarsi che un record MX corrisponda al record previsto che viene restituito dopo l'esecuzione Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain.

  16. Messaggio: 'EX013: Record MX previsto sconosciuto per il dominio [{domain}].'
    Causa: durante la convalida MX non è stato trovato un record MX corrispondente a quello previsto.
    Azioni da intraprendere: esaminare i record MX nel dominio. Assicurarsi che un record MX corrisponda al record previsto che viene restituito dopo l'esecuzione Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain.

  17. Messaggio: 'ES001: Record MX previsto mancante nei criteri mentre la modalità è ''enforced''.'
    Causa: durante la convalida MTA-STS non è stato possibile trovare il valore mx corrispondente al record previsto.
    Azioni da eseguire: impostare la modalità dei criteri MTA-STS da testare; aggiungere quindi il valore mxhostname (restituito durante l'esecuzione Enable-DnssecForVerifiedDomain di o Get-DnssecStatusForVerifiedDomain) come riga nei criteri MTA-STS.

  18. Messaggio: 'ES002: Nessun record MX previsto con cui confrontare i criteri. Abilitare prima la funzionalità DNSSEC per il dominio [{domain}].
    Causa: È stato trovato MTA-STS, ma lo stato DNSSEC del dominio non è recuperabile.
    Azioni da eseguire: completare i passaggi descritti in Configurare IL DANE SMTP in ingresso con DNSSEC.

Mitigazione dei problemi del flusso di posta con IL DANE SMTP in ingresso con DNSSEC

Esistono 3 scenari chiave per i problemi relativi al flusso di posta dopo l'abilitazione di DANE SMTP in ingresso con DNSSEC:

  1. Problema con le convalide DANE SMTP non riuscite: per informazioni su come attenuare questo problema, la mitigazione delle convalide dane SMTP ha esito negativo.
  2. Problema di convalide DNSSEC non riuscite: per informazioni su come attenuare questo problema, vedere Mitigating DNSSEC validations fail(Mitigating DNSSEC validations failing).
  3. Problema con il valore MX: per informazioni su come attenuare questo problema, vedere Mitigating issues with MX value (Mitigating issues with MX value).
Mitigazione delle convalide dane SMTP non riuscita

Per attenuare l'impatto delle convalide DANE SMTP, eseguire il comando seguente:

Disable-SmtpDaneInbound -DomainName <DomainName>
Mitigazione delle convalide DNSSEC non riuscita

  1. Per ridurre l'impatto delle convalide DNSSEC non riuscite, è necessario disabilitare DNSSEC nel dominio (contoso.com) tramite il provider DNS.

    Nota

    Se la disabilitazione di DNSSEC non risolve il problema, potrebbe trattarsi di un problema con il valore MX.

  2. Dopo aver disabilitato DNSSEC nel dominio tramite il provider DNS, aprire un ticket di supporto con il provider DNS per determinare come riabilitare DNSSEC in modo sicuro per il dominio.

Mitigazione dei problemi con il valore MX

  1. Assicurarsi che il valore MX corrisponda al valore nel centro Amministrazione Microsoft 365 -> Impostazioni -> Domini.

  2. Selezionare il dominio, selezionare record DNS, quindi eseguire Controlla integrità.

  3. Assicurarsi che il record MX venga visualizzato come OK; in caso contrario, aggiornare il valore in base a quanto specificato nell'interfaccia di amministrazione.

  4. Passare al registrar DNS e trovare il record MX per il dominio. Il valore del nome host sarà:

    <MX token>.<subdomain>.mx.microsoft

  5. Creare un secondo record MX con il valore del nome host seguente e impostare la priorità su 20:

    <MX token>.mail.protection.outlook.com

    Nota

    Sostituire il valore "Token MX" con il token MX del record MX corrente per il dominio trovato nel passaggio 4. Ad esempio, il token MX per contosotest.com è contosotest-com.

  6. Assicurarsi che L'MX creato nel passaggio 5 funzioni.

    Importante

    Un modo per assicurarsi che il secondo record MX funzioni consiste nell'usare Microsoft Remote Connectivity Analyzer.

    1. Inserire il dominio (ad esempio, contoso.com) nel test; quindi selezionare Esegui test.
    2. Aprire Test Steps (Passaggi di test).
    3. Aprire Test Steps for Testing inbound SMTP mail flow for domain "admin@(domain)" (Passaggi di test per il test del flusso di posta SMTP in ingresso per il dominio "admin@(dominio)".
    4. Aprire Dettagli aggiuntivi in Tentativo di recuperare i record MX DNS per il dominio '(dominio)'.
    5. Verificare che il record MX (token MX) .mail.protection.outlook.com sia integro.

  7. Se il flusso di posta funziona con il record MX token.mail.protection.outlook.com MX, eseguire il comando seguente:

    Disable-DnssecForVerifiedDomain -DomainName <DomainName>

  8. Eliminare il record MX DNSSEC corrispondente ai valori seguenti:

    <MX token>.<subdomain>.mx.microsoft

  9. Assicurarsi che il record MX creato nel passaggio 5 sia l'unico record MX e che sia impostato sulla priorità 0 (priorità più alta).

In che modo Exchange Online clienti possono usare IL DANE SMTP in uscita con DNSSEC?

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.

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:

  1. Portale di Exchange Amministrazione Center tramite la visualizzazione Dettagli traccia messaggi.

  2. NDR generati quando un messaggio non viene inviato a causa di un errore DANE o DNSSEC.

  3. 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:

  1. Verificare che l'indirizzo di posta elettronica di destinazione sia stato immesso correttamente.
  2. 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.
  3. 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:

  1. Avvisare l'amministratore di posta elettronica di destinazione che è stato ricevuto questo codice di errore e specificare la stringa del codice di errore.
  2. 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:

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

Dopo aver ricevuto il messaggio:

  1. Avvisare l'amministratore di posta elettronica di destinazione che è stato ricevuto questo codice di errore e fornire loro la stringa del codice di errore.
  2. 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:

  1. Avvisare l'amministratore di posta elettronica di destinazione che è stato ricevuto questo codice di errore e fornire loro la stringa del codice di errore.
  2. 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 gli standard seguenti:

  1. Adottare SMTP TLS-RPT (Transport Layer Security Reporting) introdotto in RFC8460
  2. 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.

I dati della tabella seguente sono un esempio di record:

Tipo Nome di dominio TTL Registrazione
TXT _smtp._tls.microsoft.com 3600 v=TLSRPTv1; rua=https://tlsrpt.azurewebsites.net/report

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

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

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:

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

Dopo aver ricevuto il messaggio:

  1. Controllare l'indirizzo di posta elettronica.
  2. Individuare l'indirizzo IP associato all'istruzione di errore in modo da poter identificare il server di posta a cui è associata l'istruzione.
  3. 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).
  4. Attendere alcuni minuti, quindi ritentare il test con lo strumento Analizzatore connettività remota.
  5. Se il problema persiste, provare a rimuovere il record TLSA ed eseguire di nuovo il test con lo strumento Analizzatore connettività remota.
  6. 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.

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:

  1. 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.
  2. Accedere al sito Web del provider di certificati.
  3. Selezionare il certificato scaduto e seguire le istruzioni per rinnovare e pagare il rinnovo.
  4. Dopo che il provider ha verificato l'acquisto, è possibile scaricare un nuovo certificato.
  5. Installare il certificato rinnovato nel server di posta associato.
  6. Aggiornare il record TLSA associato al server di posta elettronica con i dati del nuovo certificato.
  7. 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:

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

Dopo aver ricevuto il messaggio:

  1. Controllare l'INDIRIZZO IP associato all'istruzione di errore per identificare il server di posta a cui è associato.
  2. Identificare il record TLSA associato al server di posta identificato.
  3. 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.
  4. Individuare il certificato nel server di posta identificato.
  5. 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.

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.

Dopo aver ricevuto il messaggio:

  1. 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.
  2. 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.

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.

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)