Usar Google Workspace ou Microsoft 365 mantendo o site na hospedagem
Além de trocar os registros MX para o provedor externo, é preciso avisar a hospedagem para não entregar o e-mail localmente. Sem esse segundo passo, mensagens enviadas de dentro do próprio site continuam caindo numa caixa local que ninguém lê.
O detalhe que quase todo mundo esquece
Quando o servidor de hospedagem também hospeda e-mail, ele assume que os endereços do seu domínio são dele. Ao enviar para vendas@seudominio a partir de um formulário do próprio site, ele nem consulta o MX: entrega direto na caixa local. O sintoma é característico — mensagens de fora chegam no Workspace, mas as do formulário do site somem.
A correção é mudar o roteamento de e-mail do domínio de local para remoto no painel. É uma opção separada da zona de DNS.
Ordem da migração
- Crie as contas no provedor novo e valide o domínio por lá.
- Importe as mensagens antigas antes de virar o MX — a maioria dos provedores tem ferramenta de importação por IMAP.
- Baixe o TTL dos registros MX um ou dois dias antes.
- Troque os MX pelos do provedor novo e remova os antigos.
- Ajuste o SPF: ele precisa autorizar o provedor novo. Se o site também envia, os dois entram no mesmo registro.
- Publique o DKIM gerado pelo provedor novo.
- Mude o roteamento para remoto no painel da hospedagem.
- Mantenha as caixas antigas por algumas semanas antes de apagar.
Envio pelo site
Com o e-mail fora, o site deve enviar por SMTP autenticado do provedor novo, e não pela função nativa do PHP. Alguns provedores exigem uma senha de aplicativo específica em vez da senha da conta.
Conferindo
Teste os três caminhos, porque eles falham de forma independente: mensagem vinda de fora, mensagem enviada pelo formulário do site e mensagem enviada de uma conta do domínio para outra do mesmo domínio. O terceiro é justamente o que denuncia roteamento local esquecido.