Exchange Hybrid: Fluxo de E-mail — Como o Roteamento Funciona em Cada Cenário

Exchange Hybrid – chesley.com.br

Exchange Hybrid: Fluxo de E-mail — Como o Roteamento Funciona em Cada Cenário

Categoria: Treinamentos | Microsoft Exchange
Nível: Avançado
Tempo de leitura: ~18 minutos
Referência principal: Transport routing in Exchange hybrid deployments – Microsoft Learn


Introdução

O roteamento de e-mail em um ambiente híbrido é um dos tópicos que mais gera dúvidas — e também um dos que mais impacta a operação caso seja mal configurado. Com caixas postais distribuídas entre o Exchange on-premises e o Exchange Online, e com domínios compartilhados, entender como cada mensagem encontra o destino correto é fundamental.

Este artigo detalha todos os cenários de roteamento documentados pela Microsoft, incluindo mensagens de entrada via internet, mensagens de saída, comunicação interna entre os dois ambientes e o impacto do Centralized Mail Transport em cada um desses fluxos.

Aviso importante: Não interponha servidores, serviços ou dispositivos que modifiquem o conteúdo de e-mails entre os servidores Exchange on-premises e o Microsoft 365. O transporte seguro híbrido depende de informações intactas nas mensagens trocadas entre os dois ambientes. Firewalls que permitem tráfego SMTP na porta TCP 25 sem modificação são suportados.


O Registro MX: A Primeira Decisão de Roteamento

Antes de qualquer configuração de conectores, a decisão mais importante de roteamento de entrada é: para onde aponta o registro MX do seu domínio?

O HCW não altera o registro MX automaticamente. Essa é uma decisão que precisa ser tomada conscientemente e implementada manualmente.

Opção 1: MX apontando para o Microsoft 365 (Recomendado)

Todas as mensagens externas chegam primeiro ao Exchange Online, que as distribui para o destinatário correto — seja uma caixa on-premises ou no Exchange Online.

Vantagens: – Permite utilizar todos os recursos de segurança integrados do Microsoft 365 (anti-spam, anti-malware, Defender for Office 365) para proteger também as caixas on-premises. – Simplifica o gerenciamento de segurança de e-mail. – Configuração recomendada pela Microsoft.

Opção 2: MX apontando para o Exchange on-premises

Todas as mensagens externas chegam primeiro ao Exchange on-premises, que as distribui internamente ou as encaminha para o Exchange Online.

Quando considerar: – A organização tem uma solução de journaling on-premises obrigatória por compliance. – Gateways de segurança de e-mail legados estão na infraestrutura local e não podem ser migrados.

Limitação: Nessa configuração, os recursos de segurança integrados do Microsoft 365 para proteção de caixas postais on-premises não ficam disponíveis.


Cenário 1: MX no Microsoft 365, Centralized Mail Transport Desabilitado (Padrão)

Este é o cenário mais comum em novos deployments híbridos.

Fluxo de Mensagens de Entrada

Considere que julie@contoso.com tem caixa on-premises e david@contoso.com tem caixa no Exchange Online. Um remetente externo envia um e-mail para ambos:

Remetente externo
      │
      ▼
[Exchange Online] ← MX aponta para Microsoft 365
      │
      ├─── Lookup: david@contoso.com → Exchange Online ──→ Entrega na caixa do David
      │
      └─── Lookup: julie@contoso.com → On-premises
                │
                ▼ (via Send Connector com TLS mútuo)
         [Exchange On-Premises]
                │
                ▼
         Entrega na caixa da Julie

O processo de bifurcação (splitting) da mensagem ocorre no Exchange Online: ele cria duas cópias independentes — uma para entrega local e outra para encaminhar ao on-premises via o conector de transporte seguro configurado pelo HCW.

Fluxo de Mensagens de Saída

Mensagens de usuários do Exchange Online para destinatários externos saem diretamente pelo Exchange Online, sem passar pelo ambiente on-premises:

David (Exchange Online) → Destinatário Externo
      │
      ▼
[Exchange Online] → Lookup MX do destinatário → Entrega direta

Mensagens de usuários on-premises para destinatários externos saem pelo Exchange on-premises via DNS, independentemente de qualquer configuração no HCW:

Julie (On-Premises) → Destinatário Externo
      │
      ▼
[Exchange On-Premises] → Lookup MX do destinatário → Entrega direta

Cenário 2: MX no Microsoft 365, Centralized Mail Transport Habilitado

O Centralized Mail Transport (CMT) é uma configuração que força todo o tráfego de e-mail de saída do Exchange Online a ser roteado através da infraestrutura on-premises antes de ser entregue ao destinatário externo.

Quando Habilitar o CMT

O CMT é indicado quando a organização tem requisitos específicos de compliance que exigem que todas as mensagens, independentemente de onde a caixa postal está hospedada, passem por políticas on-premises. Exemplos:

  • Scanners DLP legados que não podem ser migrados para o Microsoft 365.
  • Gateways de journaling on-premises.
  • Inspeção de conteúdo por sistemas de compliance regulatório que operam on-premises.

A Microsoft recomenda o CMT apenas para organizações com necessidades específicas de compliance. Para a maioria dos cenários, o CMT não é recomendado, pois adiciona latência, cria um ponto único de falha e aumenta a carga nos servidores on-premises.

Fluxo de Entrada com CMT Habilitado

Remetente externo
      │
      ▼
[Exchange Online] ← MX aponta para Microsoft 365
      │
      ▼ (CMT: roteia tudo para on-premises)
[Exchange On-Premises]
      │
      ├─── Lookup: julie@contoso.com → Entrega local
      │
      └─── Lookup: david@contoso.com → On-premises → Exchange Online
                                              ▼
                                      Entrega na caixa do David

Com CMT ativado, mesmo mensagens cujo destinatário final é o Exchange Online passam pelo servidor on-premises antes da entrega final.

Fluxo de Saída com CMT Habilitado

David (Exchange Online) → Destinatário Externo
      │
      ▼ (CMT força roteamento via on-premises)
[Exchange On-Premises]
      │ (Aplicação de políticas: DLP, journaling, anti-virus, etc.)
      ▼
Lookup MX do destinatário → Entrega ao destinatário externo

Cenário 3: MX On-Premises

Quando o MX aponta para o Exchange on-premises, toda mensagem externa chega primeiramente ao servidor local.

Fluxo de Entrada

Remetente externo
      │
      ▼
[Exchange On-Premises] ← MX aponta para on-premises
      │
      ├─── Lookup: julie@contoso.com → Entrega local
      │
      └─── Lookup: david@contoso.com → Exchange Online
                │ (endereço de roteamento: david@contoso.mail.onmicrosoft.com)
                ▼ (via Send Connector com TLS mútuo)
         [Exchange Online]
                ▼
          Entrega na caixa do David

Note que as mensagens destinadas ao Exchange Online são roteadas usando o endereço de roteamento no domínio .mail.onmicrosoft.com, que é o endereço interno do Exchange Online para cada tenant.


O Transporte Seguro Híbrido: Como Funciona Tecnicamente

O elemento central do fluxo de e-mail híbrido é o Secure Mail Transport — a conexão TLS mútua entre os conectores on-premises e o Exchange Online, configurada pelo HCW.

Componentes Configurados pelo HCW

On-Premises (Send Connector para Microsoft 365):

Nome: "Outbound to Office 365"
Espaço de endereços: *.mail.onmicrosoft.com
Smart host: <tenant>.mail.protection.outlook.com
TLS: RequireTls
Autenticação: CertificateValidation

On-Premises (Receive Connector para Microsoft 365):

Nome: "Inbound from Office 365"
Remote IP ranges: Ranges do Exchange Online Protection
TLS: Enabled
Autenticação: TlsCertificateName correspondente ao certificado da CA pública

Exchange Online (Inbound Connector):

Tipo: OnPremises
Origem: Certificado do domínio on-premises
Forçar TLS: Sim

Exchange Online (Outbound Connector):

Tipo: OnPremises
Destino: FQDN do servidor Exchange on-premises
Forçar TLS: Sim

Verificando os Conectores via PowerShell

On-Premises:

# Verificar Send Connectors para Microsoft 365
Get-SendConnector | Where-Object {$_.AddressSpaces -like "*mail.onmicrosoft.com*"} |
  Format-List Name, AddressSpaces, SmartHosts, TlsAuthLevel, TlsDomain

# Verificar Receive Connectors do Microsoft 365
Get-ReceiveConnector | Where-Object {$_.Name -like "*365*" -or $_.Name -like "*Hybrid*"} |
  Format-List Name, AuthMechanism, RemoteIPRanges, TlsCertificateName

Exchange Online (PowerShell do Exchange Online):

# Conectar ao Exchange Online PowerShell
Connect-ExchangeOnline

# Verificar Inbound Connectors
Get-InboundConnector | Format-List Name, ConnectorType, SenderDomains, RequireTls, TlsSenderCertificateName

# Verificar Outbound Connectors
Get-OutboundConnector | Format-List Name, ConnectorType, SmartHosts, UseMXRecord, TlsSettings

Mensagens Internas Cross-Premises

Uma das funcionalidades mais importantes do Exchange Hybrid é que mensagens entre usuários dos dois ambientes são tratadas como mensagens internas — não como e-mail externo.

Isso significa que: – Mensagens entre on-premises e Exchange Online não passam por filtros anti-spam como tráfego externo. – O campo P2 From e os cabeçalhos internos são preservados. – MailTips funcionam corretamente (ex: aviso de caixa postal lotada, ausência temporária). – Rastreamento de mensagens funciona entre os dois ambientes.

Como o Exchange Determina Que uma Mensagem é Interna

O Exchange Online classifica uma mensagem como interna quando ela é recebida através de um Inbound Connector configurado pelo HCW com o tipo OnPremises. Da mesma forma, o Exchange on-premises trata mensagens do Microsoft 365 como internas quando elas chegam via o Receive Connector configurado pelo HCW com os ranges de IP do Exchange Online Protection.

Para um entendimento aprofundado desse mecanismo, consulte: Demystifying and troubleshooting hybrid mail flow: when is a message internal?


Boas Práticas para Fluxo de E-mail Híbrido

1. Aponte o MX para o Microsoft 365 sempre que possível

Isso simplifica a segurança, reduz a complexidade operacional e permite aproveitar os recursos de proteção integrados do Defender for Office 365 para todas as caixas, incluindo as on-premises.

2. Evite o Centralized Mail Transport a menos que seja estritamente necessário

O CMT introduz latência adicional e cria dependência do ambiente on-premises para o funcionamento do Exchange Online. Se o objetivo é compliance, avalie primeiro as ferramentas nativas do Microsoft 365 (DLP, journaling, Defender for Office 365).

3. Não modifique os conectores criados pelo HCW manualmente

Alterações manuais nos conectores de transporte híbrido podem quebrar o fluxo de e-mail. Se ajustes forem necessários, reexecute o HCW e faça as modificações através do wizard.

4. Monitore o fluxo de e-mail regularmente

Utilize o Message Trace no Exchange Online Admin Center e os relatórios de fluxo de e-mail do Microsoft 365 para monitorar e diagnosticar problemas de entrega.

# Rastrear mensagens no Exchange Online PowerShell
Get-MessageTrace -SenderAddress "julie@contoso.com" -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) |
  Select-Object Received, SenderAddress, RecipientAddress, Subject, Status | Format-Table -AutoSize

5. Mantenha os ranges de IP do Exchange Online atualizados

Os IPs do Exchange Online Protection podem mudar. Utilize a API de endpoints do Microsoft 365 para manter os ranges atualizados nos firewalls e no Receive Connector on-premises.


Diagnóstico de Problemas de Fluxo de E-mail

Sintoma: Mensagens entre on-premises e Exchange Online chegando como externas

Causa provável: Receive Connector do Microsoft 365 no Exchange on-premises não está configurado corretamente, ou os ranges de IP do Exchange Online não estão incluídos.

# Verificar Remote IP Ranges do Receive Connector
Get-ReceiveConnector -Identity "Inbound from Office 365" | Select-Object -ExpandProperty RemoteIPRanges

Sintoma: Falha de entrega com erro de certificado TLS

Causa provável: O certificado do Exchange on-premises expirou ou o TlsDomain do Send Connector não corresponde ao CN do certificado do Exchange Online.

# Verificar certificados no Exchange on-premises
Get-ExchangeCertificate | Where-Object {$_.Services -match "SMTP"} |
  Format-List FriendlyName, NotAfter, Subject, Thumbprint, Services

Sintoma: Free/Busy retornando erro ou dados desatualizados

Causa provável: Organization Relationship não está configurado corretamente ou o EWS não está acessível externamente.

# Testar Free/Busy via PowerShell (Exchange On-Premises)
Test-OrganizationRelationship -UserIdentity "julie@contoso.com" -Identity "Exchange Online" -Verbose

Próximo Artigo

Com o fluxo de e-mail bem compreendido, o próximo passo é explorar a migração de caixas postais — como mover usuários do Exchange on-premises para o Exchange Online (onboarding) e o processo inverso (offboarding), utilizando o Exchange Admin Center e o PowerShell.


Referências Técnicas Microsoft


Artigo publicado em chesley.com.br | Série: Exchange Hybrid — Da Teoria à Produção