Email messaggi vengono messi in quarantena in modo errato nelle distribuzioni ibride di Exchange che usano il controllo della posta centralizzato

  • Articolo
  • Si applica a:
    Exchange Online, Exchange Online Protection, Exchange Server 2010 Enterprise, Exchange Server 2010 Standard, Exchange Server 2013 Enterprise, Exchange Server 2013 Standard Edition

Numero KB originale: 3079142

Nota

La configurazione guidata ibrida inclusa nel Exchange Management Console in Microsoft Exchange Server 2010 non è più supportata. Pertanto, non è più consigliabile usare la configurazione guidata ibrida precedente. Usare invece la configurazione guidata ibrida di Microsoft 365. Per altre informazioni, vedere Configurazione guidata ibrida di Microsoft 365 per Exchange 2010.

Problema

È disponibile una distribuzione ibrida di Exchange Server e Exchange Online locali in Microsoft 365. In questa distribuzione si usa il controllo posta centralizzato. In questo modo i messaggi vengono indirizzati al server di posta locale prima che vengano recapitati alle cassette postali Exchange Online. In questo scenario si verificano uno o più dei sintomi seguenti:

  • Le notifiche di posta indesiderata per gli utenti vengono messi in quarantena.
  • Email messaggi nell'elenco Consenti vengono messi in quarantena.
  • Email messaggi rilasciati dalla quarantena vengono riabilitati.
  • I controlli di Sender Policy Framework (SPF) hanno esito negativo al secondo passaggio.

Causa

Questo problema si verifica se l'organizzazione Exchange Online o l'organizzazione locale non è configurata per alzare di livello le intestazioni di posta elettronica come cross-premise, ovvero da Exchange Online al server locale a Microsoft 365.

Soluzione

  1. Verificare che il controllo della posta centralizzato sia abilitato e che sia configurato per alzare di livello le intestazioni in Microsoft 365. A tal fine, attenersi alla seguente procedura:

    1. Connettersi a Exchange Online usando una sessione di Windows PowerShell remota. Per ulteriori informazioni, vedere Connettersi a Exchange Online utilizzando una sessione PowerShell remota.

    2. Visualizzare le informazioni di configurazione del connettore in uscita ibrido nell'organizzazione Exchange Online. A tale scopo, utilizzare il seguente comando:

      Get-OutboundConnector "Contoso Outbound Connector" | Format-List

      Verificare che il valore della RouteAllMessagesViaOnPremises proprietà sia impostato su $true.

    3. Visualizzare le informazioni di configurazione del connettore in ingresso ibrido nell'organizzazione Exchange Online. A tale scopo, utilizzare il seguente comando:

      Get-InboundConnector "Contoso Inbound Connector" | Format-List

      Verificare che il valore della CloudServicesMailEnabled proprietà sia impostato su $true.

    4. Individuare la riga seguente nelle intestazioni:

      X-MS-Exchange-Organization-Cross-Premises-Headers-Promoted: <Microsoft 365 Server Name>

      Ad esempio, server.contoso.com.

      Nota

      Se la RouteAllMessagesViaOnPremises proprietà e la CloudServicesMailEnabled proprietà sono impostate su $false e l'intestazione X-MS-Exchange-Organization-Cross-Premises-Headers-Promoted: <Microsoft 365 Server Name> non viene trovata, questa risoluzione non si applica alla configurazione dell'organizzazione.

  2. Inviare un messaggio di test in ingresso a una cassetta postale Exchange Online instradando prima il messaggio attraverso il server locale. Individuare le righe di intestazione X seguenti nelle intestazioni del messaggio. Ciò consente di indicare che il messaggio è stato analizzato due volte nel trasporto.

    • X-Forefront-Antispam-Report-Untrusted: si tratta del primo passaggio. Si verifica quando il messaggio viene ricevuto per la prima volta in Microsoft 365. L'indirizzo IP di connessione (CIP) in tale riga sarà un indirizzo IP Internet.
    • X-Forefront-Antispam-Report: si tratta del secondo passaggio. Si verifica quando il messaggio viene restituito dal server locale e viene ricevuto per la seconda volta in Microsoft 365. L'indirizzo IP di connessione sarà l'indirizzo IP del server locale dell'organizzazione.

    Nota

    Se è presente una sola intestazione X-Forefront, questa risoluzione non si applica alla configurazione dell'organizzazione.

  3. Per alzare di livello le intestazioni dall'ambiente locale a Microsoft 365, seguire questa procedura:

    1. Verificare che le intestazioni non siano attualmente alzate di livello. A tale scopo, verificare se nelle intestazioni manca la riga seguente:

      X-MS-Exchange-Organization-Cross-Premises-Headers-Promoted: <On-premises Server Name>

      Ad esempio, il nome del server locale è contoso_on_premises.contoso.com.

    2. Individuare X-OriginatorOrg dalle intestazioni. Sarà nel formato di contoso.onmicrosoft.com.

    3. Aprire Exchange Management Shell in Exchange 2013 o Exchange 2010, quindi eseguire i comandi seguenti:

      • New-RemoteDomain -Name 'Hybrid Domain - contoso.onmicrosoft.com' -DomainName 'contoso.onmicrosoft.com'

      • Set-RemoteDomain 'Hybrid Domain - contoso.onmicrosoft.com' -TrustedMailOutboundEnabled $true -TrustedMailInboundEnabled $true

    4. Verificare che il problema sia stato risolto. Inviare un nuovo messaggio e verificare che nelle intestazioni sia presente la riga seguente:

      X-MS-Exchange-Organization-Cross-Premises-Headers-Promoted: <On-premises Server Name>

      Ad esempio, il nome del server locale è contoso_on_premises.contoso.com.

Ulteriori informazioni

Per altre informazioni, vedere le risorse Microsoft seguenti: