Contas híbridas no mesmo domínio

01 Como o Bridge funciona

No lua Bridge, o domínio tem um único ponto de entrada: o MX aponta para a Lua. Toda mensagem que chega passa pelo antispam e pelo antivírus e depois segue para o provedor onde está a caixa de cada conta.

1. Entrada. A mensagem chega ao MX da Lua (mx.secure.edgium-dns.net), que filtra spam, phishing e vírus para todas as contas do domínio.
2. Roteamento por conta. Cada endereço tem um provedor definido: lua.email, Microsoft 365, Google Workspace ou outro provedor (Zoho, um servidor próprio, um sistema que recebe e-mail). Quem não tem regra própria fica no lua.email.
3. Entrega. A mensagem vai para a caixa certa, no provedor certo, com o resultado do filtro registrado nos cabeçalhos.

O caminho de volta também precisa estar configurado. Quando alguém no Microsoft 365 escreve para um colega no lua.email, a Microsoft precisa saber que esse endereço não está com ela e mandar a mensagem para a Lua. O mesmo vale no sentido contrário e em qualquer outro provedor. Cada provedor tem os seus pontos de configuração: os capítulos 4 a 7 explicam cada lado.

02 Antes de começar

O que separar

• A lista de contas do domínio, com o provedor de cada uma (lua.email, Microsoft 365, Google ou outro). Inclua grupos, aliases e caixas compartilhadas.
• Acesso ao DNS do domínio, para mudar MX, SPF, DKIM e DMARC.
• Acesso de administrador a cada provedor em uso: Microsoft 365 (Exchange admin center), Google Workspace (Admin console) ou o painel do outro provedor.
• Para cada conta que fica fora do lua.email, o endereço técnico dela no provedor, por exemplo [email protected]. Veja o capítulo 4.

Ordem recomendada

1. Cadastrar as contas e o provedor de cada uma no painel da Lua.
2. Fazer os ajustes em cada provedor em uso (capítulos 5 a 7).
3. Publicar SPF e DKIM de todos os provedores (capítulo 3).
4. Mudar o MX para a Lua.
5. Rodar os testes do capítulo 9 e, com tudo certo, endurecer o DMARC.

03 DNS do domínio

MX

O MX aponta só para a Lua. Não deixe o MX antigo do Google ou da Microsoft junto: um remetente que use o MX antigo entrega direto no provedor, sem filtro, e as contas do lua.email não recebem por esse caminho.

suaempresa.com.br.   3600   IN   MX   5   mx.secure.edgium-dns.net.

SPF

O SPF diz quem pode enviar e-mail em nome do domínio. No Bridge, três sistemas enviam como @suaempresa.com.br, e o SPF precisa autorizar todos que estiverem em uso:

suaempresa.com.br.  IN  TXT  "v=spf1 include:spf.edgium-dns.net include:spf.protection.outlook.com include:_spf.google.com -all"

• O domínio só pode ter um registro SPF. Junte tudo numa linha só.
• Mantenha os outros sistemas que já enviam pelo domínio (ERP, nota fiscal, marketing).
• O SPF aceita no máximo 10 consultas de DNS somando todos os include. Passando disso, o SPF inteiro falha. Confira com uma ferramenta de verificação de SPF depois de publicar.
• Comece com ~all se ainda não tiver certeza de que todos os remetentes estão no registro, e passe para -all depois de conferir.

DKIM

Cada provedor assina as mensagens com a própria chave, e cada chave tem um registro no DNS. Publique os registros de todos os provedores em uso:

• lua.email: o registro DKIM do domínio aparece no painel da Lua. Copie o nome e o valor exatamente como estão lá.
• Microsoft 365: dois CNAME (selector1._domainkey e selector2._domainkey), mostrados no Microsoft Defender em Email authentication settings → DKIM. Depois de publicar, ligue a assinatura do domínio na mesma tela.
• Google Workspace: um TXT (google._domainkey), gerado no Admin console em Apps → Google Workspace → Gmail → Autenticar e-mails. Depois de publicar, clique em Iniciar autenticação.
• Outro provedor: o registro que ele indicar, em geral com um seletor próprio.

DMARC

O DMARC diz ao destinatário o que fazer com uma mensagem que usa o seu domínio e não passa no SPF nem no DKIM. Suba a política aos poucos:

1. Início: p=none, para acompanhar sem afetar a entrega.
2. Depois dos testes (SPF e DKIM dos três provedores conferidos): p=quarantine.
3. Com tudo estável: p=reject.

_dmarc.suaempresa.com.br.  IN  TXT  "v=DMARC1; p=quarantine; sp=quarantine; adkim=r; aspf=r"

Para receber relatórios agregados, acrescente rua=mailto:[email protected] (crie a caixa antes). Sem rua, nenhum relatório é enviado.

04 Roteamento por conta

No painel da Lua, cada conta do domínio tem um provedor. É isso que decide para onde vai a mensagem que chega da internet.

Provedor de cada conta

• lua.email: a caixa fica na Lua. É o padrão de quem não tem regra própria.
• Microsoft 365: a mensagem é entregue no Microsoft 365 do domínio.
• Google Workspace: a mensagem é entregue no Google do domínio.
• Outro provedor: a mensagem é entregue no servidor informado para aquela conta.

Trocar uma conta de provedor muda só o destino das próximas mensagens. As mensagens que já estão na caixa antiga não são movidas: para isso, combine a migração com a equipe da Lua.

Endereço técnico das contas fora do lua.email

A regra por conta vale para o que chega pelo MX. Quando quem escreve é uma conta do próprio lua.email, a mensagem não sai para a internet e não passa pelo MX, então a Lua precisa saber para onde mandar. Para isso, toda conta que fica fora do lua.email precisa ter cadastrado o endereço técnico dela no provedor:

Grupos, aliases e caixas compartilhadas

• Um alias do lua.email pode apontar para contas de qualquer provedor. Para as contas externas, use o endereço técnico.
• Um grupo do Microsoft 365 ou do Google precisa ser cadastrado como conta daquele provedor no painel, como se fosse uma caixa.
• Não cadastre o mesmo endereço como caixa em dois provedores. Escolha um, senão cada lado entrega na sua cópia e a pessoa recebe metade das mensagens em cada lugar.

05 Ajustes no Microsoft 365

Os nomes das telas estão em português, com o nome em inglês entre parênteses, porque o Exchange admin center muda de idioma conforme o usuário.

1. Domínio como relay interno

Este é o ajuste mais importante do lado da Microsoft. Na configuração do domínio, as contas que não existem no Microsoft 365 precisam ir para o MX externo (o da Lua), em vez de serem devolvidas.

Por padrão, o Microsoft 365 acha que todas as contas do domínio estão nele e devolve com 550 5.1.10 RecipientNotFound qualquer endereço que não conhece. Com o domínio como relay interno, o Microsoft 365 entrega o que é dele e passa adiante o que não é. O conector do passo 2 diz para onde.

1. No Exchange admin center, abra Fluxo de e-mails → Domínios aceitos (Mail flow → Accepted domains).
2. Abra o domínio e troque o tipo de Autoritativo (Authoritative) para Relay interno (Internal relay).

2. Conector de saída para o MX da Lua

Diz ao Microsoft 365 para onde mandar as mensagens das contas que não existem nele: o MX externo, que é o da Lua.

1. Em Fluxo de e-mails → Conectores (Connectors), crie um conector do Office 365 para Organização parceira (From Office 365 to Partner organization).
2. Use o conector só para mensagens enviadas a estes domínios e informe suaempresa.com.br.
3. Encaminhamento: rotear pelos hosts inteligentes (smart hosts) e informe mx.secure.edgium-dns.net.
4. Segurança: exija TLS. Na validação, faça o teste com um endereço que está no lua.email.

3. Conector de entrada e filtragem aprimorada

Como as mensagens da internet chegam ao Microsoft 365 pelos servidores da Lua, a Microsoft enxerga o IP da Lua e não o do remetente original. A filtragem aprimorada (Enhanced Filtering) faz a Microsoft olhar além do último salto.

1. Crie um conector de Organização parceira para o Office 365 (From Partner organization to Office 365), identificado pelo endereço IP do remetente, com os IPs da lista resources.edgium.net/ips_mx.txt.
2. No Microsoft Defender, abra Políticas e regras → Políticas de ameaças → Filtragem aprimorada para conectores (Enhanced filtering for connectors), escolha esse conector e marque detectar e ignorar automaticamente o último IP.

4. Selo ARC da Lua como confiável

A Lua registra, num cabeçalho assinado (ARC, domínio lua.email), o resultado de SPF, DKIM e DMARC que viu na entrada. Com o selo marcado como confiável, a Microsoft aceita esse resultado quando o SPF original se perde no caminho.

1. No Microsoft Defender, abra Configurações de autenticação de e-mail → ARC (Email authentication settings → ARC).
2. Adicione lua.email como selador ARC confiável (trusted ARC sealer).

5. DKIM do domínio

Ligue o DKIM do domínio no Microsoft 365, como no capítulo 3. Sem ele, as contas da Microsoft só passam no DMARC pelo SPF, e o SPF não sobrevive a um encaminhamento.

06 Ajustes no Google Workspace

1. Rota para destinatários não reconhecidos

É o equivalente do relay interno da Microsoft: o Google entrega o que conhece e manda para a Lua o que não conhece.

1. No Admin console, abra Apps → Google Workspace → Gmail → Roteamento.
2. Na configuração Roteamento, adicione uma regra para mensagens recebidas e internas recebidas.
3. Em Tipos de conta afetados, marque só Não reconhecidos / Catch-all.
4. Em Rota, troque o destino para o host mx.secure.edgium-dns.net, porta 25, com TLS.

2. Gateway de entrada

Diz ao Google que as mensagens chegam por um filtro e que ele pode usar a marcação da Lua.

1. Em Gmail → Spam, phishing e malware → Gateway de entrada, informe os IPs da lista resources.edgium.net/ips_mx.txt.
2. Marque A mensagem é considerada spam se o seguinte cabeçalho corresponder à expressão regular e informe X-Edgium-Spam: Yes.

3. DKIM do domínio

Gere e publique a chave google._domainkey e inicie a autenticação, como no capítulo 3.

07 Outros provedores

O Bridge não depende de Google ou Microsoft. Qualquer provedor ou servidor que receba e-mail por SMTP pode ficar com parte das contas: Zoho, um servidor próprio, um sistema de atendimento que recebe por e-mail. Cada um tem os seus pontos de configuração, mas os ajustes são sempre os mesmos quatro:

1. Entrega: o servidor do provedor aceita mensagens vindas dos IPs da Lua (lista oficial) para as contas dele, sem barrar por limite de conexões ou por SPF do remetente original.
2. Contas que ele não conhece: o provedor envia para mx.secure.edgium-dns.net as mensagens para endereços do domínio que não estão nele, em vez de devolver. Cada provedor chama isso de um jeito: domínio compartilhado, relay interno, roteamento parcial, entrega dividida (split delivery) ou catch-all para host externo.
3. Endereço técnico: cada conta tem um endereço que a Lua usa para entregar a mensagem enviada pelas contas do lua.email (capítulo 4).
4. Autenticação: o include do SPF e o DKIM do provedor publicados no DNS do domínio (capítulo 3).

08 Treinar o filtro

O antispam vale para todas as contas do domínio, inclusive as que estão no Microsoft 365, no Google ou em outro provedor. Quando uma mensagem for classificada errada, ensine o certo pela página de treinamento do painel de gerenciamento da Lua (painel.lua.email): marque como spam o que passou e como não spam o que foi marcado sem motivo.

As contas do lua.email também treinam pelo webmail: mover uma mensagem para a pasta Spam, ou tirá-la de lá, já conta como correção.

09 Testes de ativação

Envie uma mensagem em cada sentido e confira o cabeçalho completo de cada uma ("mostrar original" ou "exibir código-fonte").

Com todos os testes passando, suba o DMARC para p=quarantine (capítulo 3).

10 Problemas comuns

Devolução "550 5.1.1 User unknown" ao escrever do lua.email

A conta de destino está fora do lua.email, mas não tem endereço técnico cadastrado. Cadastre o endereço onmicrosoft.com, o do Google ou o do outro provedor (capítulo 4).

Devolução "550 5.1.10 RecipientNotFound" ao escrever do Microsoft 365

Na configuração do domínio no Microsoft 365, as contas que não existem lá ainda não vão para o MX externo: o domínio continua como Autoritativo, ou o conector de saída não cobre o domínio. Veja o capítulo 5.

Mensagem volta com "hop count exceeded" ou "loop detected"

A conta foi cadastrada no painel com um provedor (Microsoft, Google ou outro), mas não existe nele. O provedor não a encontra e devolve para a Lua, que manda de novo para o provedor. Crie a conta no provedor ou mude o provedor dela no painel.

Mensagens das contas do lua.email caem no spam ou falham no SPF

Falta include:spf.edgium-dns.net no SPF, ou o SPF passou de 10 consultas. Veja o capítulo 3.

DMARC falha em mensagens encaminhadas

O provedor que enviou não está assinando com DKIM do domínio. Ligue o DKIM em todos os provedores antes de usar p=quarantine ou p=reject.

A pessoa recebe parte das mensagens em cada provedor

O endereço existe como caixa em dois provedores. Deixe a caixa em um só e, se precisar de cópia, use um alias (capítulo 4).