Exchange Online: Scenari di flusso della posta elettronica in ambienti ibridi

Microsoft Office 365

In uno scenario di coesistenza tra Exchange Server e Exchange Online, tipicamente, possono essere implementati diversi metodi di distribuzione della posta elettronica. La scelta di una tipologia di flusso idonea, dipende tendenzialmente dalle esigenze del cliente, da eventuali limiti imposti dall’infrastruttura on-premise e da vincoli dettati da sicurezza e  conformità.

Nei prossimi scenari si analizzeranno quattro modelli di flusso relativi alle implementazioni ibride di Exchange, tenendo presente la situazione di un ipotetico cliente e sviluppando dei suggerimenti utili a risolvere le problematiche evidenziate.

Scenario 1: Il record MX punta a Office 365 e Office 365 filtra tutti i messaggi

Situazione attuale:

  • Si stanno migrando le mailbox di una determinata organizzazione a Office 365 e si desidera mantenere alcune cassette postali sul server di posta esistente (server locale)
  • Si desidera utilizzare Office 365 come soluzione di messaging hygiene e si desidera inviare i messaggi dal server locale ad Internet utilizzando Office 365
  • Office 365 invierà e riceverà tutti i messaggi.

Suggerimento:

La maggior parte dei clienti che necessitano di un’impostazione di flusso di posta elettronica ibrida dovrebbero consentire ad Office 365 di eseguire tutti i filtri ed il routing. Si consiglia di indirizzare il record MX a Office 365 poiché quest’ultimo, nella maggior parte dei casi, fornisce un filtro antispam/malware più accurato. Per questo scenario, l’impostazione del flusso di posta elettronica sarà simile alla figura 1.

Scenario 2: Il record MX punta ad Office 365 e la posta viene filtrata on-premises

Situazione attuale:

  • Si stanno migrando le mailbox verso Office 365 e si desidera mantenerne alcune sul server di posta elettronica esistente (server locale)
  • Si intendono utilizzare le soluzioni di messaging hygiene e conformità che sono già presenti nell’ambiente locale
  • Tutti i messaggi che arrivano da Internet verso le mailbox attestate su cloud (tenant), così come i messaggi inviati ad Internet dalle mailbox su cloud, devono essere instradati attraverso i server locali

Suggerimento:

Se si hanno ragioni commerciali, tecniche o normative per filtrare la posta elettronica all’interno dell’ambiente locale, si consiglia di indirizzare comuque il record MX del proprio dominio su Office 365 e abilitare il trasporto centralizzato della posta (CMT, Centralized Mail Transport) tramite hybrid wizard o il cmdlet Set-HybridMailflow . Questa configurazione fornisce un filtraggio dello spam ottimale e protegge gli indirizzi IP dell’organizzazione. Per questo scenario, l’impostazione del flusso di posta elettronica sarà simile alla figura 2.

Scenario 3: Il record MX punta ai server on-premises

Situazione attuale:

  • Si stanno migrando le mailbox da on-premises a Office 365 e si desidera mantenerne alcune sul server di posta elettronica esistente (server locale)
  • Si utilizzeranno le soluzioni di filtro e conformità già presenti nell’ambiente posta elettronica
  • Tutti i messaggi che provengono da Internet verso mailbox nel cloud, così come i messaggi inviati a Internet dalle mailbox in cloud, devono essere instradati attraverso i server locali
  • Si intende mantenere il puntamento del record MX del proprio dominio sui server locali

Suggerimento:

In alternativa allo scenario 2, è possibile indirizzare il record MX del proprio dominio al server di posta dell’organizzazione anziché a Office 365. Alcune organizzazioni hanno esigenze aziendali o normative che potrebbero far pesare l’ago della bilancia verso questa configurazione, ma in genere il filtro funziona meglio se si utilizza lo scenario 2. Per questo particolare  scenario, l’impostazione del flusso di posta elettronica sarà simile alla figura 3.

Scenario 4: Il record MX punta al server locale, che filtra e fornisce soluzioni di conformità per la posta elettronica. Il server locale farà relay verso internet tramite Office 365

Situazione attuale:

  • Si stanno migrando le cassette postali della propria organizzazione a Office 365 e si desidera mantenerne alcune sul server di posta elettronica esistente (server locale)
  • Si vogliono utilizzare le soluzioni di filtro e conformità già presenti nell’ambiente di posta elettronica locale
  • Tutti i messaggi inviati dal server locale devono essere inoltrati (relay) verso internet tramite Office 365
  • Si desidera che il record MX del proprio dominio punti sugli pubblici sul server locale

Suggerimento:

Il record MX per il proprio dominio deve puntare all’indirizzo IP pubblico del server locale. Per eseguire questa attività, utilizzare la seguente procedura:

  1. Aggiungere i domini personalizzati in Office 365. Per provare di essere il proprietario dei domini, seguire le istruzioni in “Add users and domains
  1. Creare le mailbox utente in Exchange Online o spostare le cassette postali di tutti gli utenti su Office 365
  1. Aggiornare i record DNS per i domini aggiunti al passaggio 1. (Seguire le istruzioni in questo articolo: Creating DNS records at any DNS hosting provider for Office 365). I seguenti record DNS controllano il flusso di posta:
  • Record MX: Puntare il proprio record MX al server locale nel seguente formato: [DomainKey].com – ad esempio, se il dominio è contoso.com, il record MX deve essere: .mail.contoso.com
  • Record SPF: Questo Record dovrebbe validare Office 365 come mittente valido. Dovrebbe anche includere qualsiasi indirizzo IP relativo ai server locali che si connettono a EOP ed eventuali server di terze parti che inviano e-mail per conto della propria organizzazione – ad esempio, se l’indirizzo IP pubblico del server di posta elettronica dell’organizzazione è 131.107.21.231, il record SPF per com deve essere: V = spf1 ipv4: 131.107.21.231 include: spf.protection.outlook.com -all 
  1. In “Exchange Admin Center”, usare “connector wizard” per Configurare il flusso mail usando i connettori in Office 365 per i seguenti scenari:
  • Invio di posta da Office 365 ai server di posta della propria organizzazione
  • Invio di posta dai server locali verso Office 365. In questo caso, è necessario creare un connettore se uno dei seguenti scenari si applica alla propria organizzazione:
  • La propria organizzazione è autorizzata ad inviare posta per conto di un’altra azienda, ma non ne possiede il dominio. Ad esempio, tailspintoys.com è autorizzato ad inviare e-mail tramite fabrikam.com, che non appartiene a contoso.com
  • La propria organizzazione inoltra rapporti di mancata consegna (NDR) verso Internet tramite Office 365
  • Il record MX per il proprio dominio, contoso.com, punta al server locale e gli utenti dell’organizzazione inoltrano automaticamente i messaggi agli indirizzi email esterni all’organizzazione. Ad esempio, kate@contoso.com ha abilitato l’inoltro e tutti i messaggi vengono inviati a kate@tailspintoys.com. Se john@fabrikam.com invia un messaggio a kate@contoso.com, quando il messaggio arriva a Office 365 il dominio del mittente è fabrikam.com e il dominio del destinatario è tailspin.com. Né il dominio del mittente né il dominio del destinatario appartengono alla propria organizzazione.

Conclusioni

Abbiamo visto i diversi tipi di flusso di posta elettronica che è possibile implementare in Office 365 in caso di una coesistenza o di una configurazione ibrida per Exchange Server. Ogni tipologia risolve diverse problematiche ed esigenze, anche se il suggerimento predominante resta quello di utilizzare Office 365 come opzione principale per il messaging hygiene.