DNS, Cloudflare e e-mail: como migrar um site sem quebrar o MX

Migrar um site parece, em muitos casos, uma troca simples de apontamento DNS. O problema e que o dominio normalmente nao carrega apenas o site. Ele tambem pode carregar e-mail, FTP, subdominios, verificacoes de ferramentas, tags de publicidade, Search Console, AdSense, automacoes, formularios e integracoes que dependem de registros diferentes.

Quando a mudanca e feita olhando apenas para o registro do site, o resultado pode ser curioso: a pagina nova abre, mas o e-mail para de receber; o formulario salva o contato, mas a notificacao nao chega; o Outlook comeca a pedir senha; ou o servidor SMTP rejeita mensagens porque o remetente nao combina com a conta autenticada.

Este guia organiza uma migracao segura de DNS, Cloudflare e e-mail para pequenas empresas. A ideia nao e decorar todos os tipos de registro, mas entender quais deles precisam ser preservados, o que pode ficar proxied, o que deve ficar apenas como DNS e como validar antes de considerar a migracao concluida.

1. Separe site, e-mail e servicos auxiliares

O primeiro cuidado e separar mentalmente tres coisas que usam o mesmo dominio, mas nao devem ser tratadas como se fossem uma coisa so.

• Site: normalmente usa registros A, AAAA ou CNAME para apontar o dominio e o www para a hospedagem, VPS, proxy ou plataforma.
• E-mail: usa MX para indicar quem recebe mensagens do dominio, alem de registros TXT para SPF, DKIM e DMARC.
• Servicos auxiliares: podem incluir FTP, webmail, subdominios de API, verificacoes do Google, tags de anuncios, CDN, automacoes e integracoes.

Cloudflare, VPS e Nginx podem resolver muito bem o trafego web, mas eles nao substituem automaticamente o provedor de e-mail. Se a empresa usa contas do dominio em Outlook, webmail ou servidor de hospedagem antigo, os registros de e-mail precisam continuar apontando para o lugar correto.

Antes de alterar qualquer coisa, registre quem e responsavel por cada parte. A pagina de responsabilidades tecnicas ajuda a transformar isso em uma matriz simples: quem decide, quem executa, quem valida e onde ficam as evidencias.

2. Inventarie a zona DNS antes de mexer

Uma migracao segura comeca com inventario. Tire prints ou exporte a zona DNS atual. Anote cada registro, tipo, nome, valor, TTL e finalidade conhecida. O objetivo e evitar que uma configuracao antiga, aparentemente pequena, seja perdida durante a troca.

Registros comuns que merecem atencao:

• A ou AAAA: apontam nomes para IPs.
• CNAME: apontam um nome para outro nome.
• MX: definem os servidores que recebem e-mail do dominio.
• TXT SPF: informa quais servidores podem enviar e-mail em nome do dominio.
• TXT DKIM: publica chaves usadas para assinar e-mails.
• TXT DMARC: orienta como destinatarios devem tratar mensagens suspeitas.
• TXT de verificacao: confirmam propriedade em Google, Microsoft, ferramentas de marketing ou outros servicos.

Esse inventario tambem deve incluir URLs e credenciais operacionais: painel da hospedagem antiga, painel da VPS, Cloudflare, registrar do dominio, webmail, provedor SMTP, pipeline de deploy, repositorio e local das variaveis de ambiente. Sem isso, a equipe consegue mudar o DNS, mas nao consegue responder rapidamente se algo falhar.

3. Entenda o que pode usar proxy da Cloudflare

Na Cloudflare, o icone de nuvem laranja indica que o trafego HTTP/HTTPS passa pelo proxy da Cloudflare. Isso costuma ser adequado para o site, porque ajuda com cache, TLS, protecao e roteamento web. Mas nao e adequado para registros de e-mail.

Registros relacionados a e-mail devem ficar como DNS only. Em termos praticos:

• O registro usado pelo MX, como mail.seudominio.com.br, deve ficar sem proxy.
• Registros MX nao devem apontar para nomes escondidos por proxy web.
• SPF, DKIM e DMARC sao TXT e devem ser preservados exatamente como o provedor orienta.
• Webmail ou SMTP podem usar nomes proprios, mas devem apontar para o servidor correto e nao para o container da aplicacao.

Um erro comum e criar mail como CNAME para o dominio principal quando o dominio principal agora aponta para a VPS do site. Isso pode fazer o nome mail deixar de representar o servidor de e-mail real. Se o e-mail continua em outro provedor, o nome usado pelo MX precisa apontar para esse provedor, nao para a aplicacao web.

Em migracoes com Nginx, Docker e VPS, o Nginx geralmente cuida de trafego web. Ele nao deve virar o destino do e-mail so porque esta no mesmo dominio. O artigo sobre Cloudflare, Nginx e Docker em VPS aprofunda essa separacao do lado de publicacao web.

4. Planeje a janela e reduza o TTL

DNS depende de propagacao e cache. Por isso, mudancas importantes ficam mais seguras quando o TTL e reduzido antes da janela de migracao. Em vez de alterar tudo no susto, faca em etapas:

1. Reduza o TTL dos registros que serao alterados algumas horas antes, quando possivel.
2. Valide que a zona nova tem todos os registros do inventario.
3. Altere primeiro os apontamentos web necessarios.
4. Mantenha MX, SPF, DKIM e DMARC preservados.
5. Teste site, formulario, envio SMTP e recebimento de e-mail.
6. So depois aumente o TTL novamente, se fizer sentido.

Nem toda empresa consegue escolher uma janela longa. Ainda assim, uma lista curta de verificacao evita a maior parte dos acidentes. A pagina de gestao de mudancas tecnicas mostra como classificar risco, preparar rollback e validar antes e depois da alteracao.

5. Valide o e-mail como parte da migracao

Site no ar nao significa migracao concluida. Se o dominio recebe e envia e-mail, a validacao precisa incluir os dois caminhos.

Checklist minimo para e-mail:

• Enviar uma mensagem externa para uma conta do dominio e confirmar recebimento.
• Enviar uma mensagem da conta do dominio para um e-mail externo e confirmar entrega.
• Testar no Outlook ou cliente real usado pela empresa.
• Testar webmail, quando existir.
• Confirmar se o formulario do site envia notificacao pelo SMTP configurado.
• Verificar spam, lixeira, logs do provedor e logs da aplicacao.
• Confirmar se o remetente autenticado e o From sao aceitos pelo servidor SMTP.

Esse ultimo ponto e importante. Muitos servidores SMTP rejeitam mensagens quando a aplicacao autentica com uma conta, mas tenta enviar usando outro remetente automatico. Em containers, por exemplo, pode aparecer um remetente como root@container. O correto, em geral, e configurar o From com a conta autorizada do dominio e usar o e-mail do visitante como Reply-To.

Quando o formulario falha, nao basta olhar a tela do site. E preciso olhar logs, status do contato salvo, resposta do servidor SMTP e mensagem retornada pelo provedor. O playbook de formulario que salva mas nao envia e-mail organiza essa investigacao.

6. Nao misture segredo, configuracao e codigo

Configuracoes de e-mail costumam envolver senha, porta, host, SSL e autenticacao. A senha nao deve ficar escrita no repositorio. O ideal e manter dados sensiveis em variaveis de ambiente ou arquivo de segredo fora do versionamento, com nomes claros por ambiente.

Uma configuracao saudavel separa:

• Codigo: sabe enviar e-mail e montar a mensagem.
• Configuracao nao sensivel: host, porta, SSL e remetente padrao podem ficar documentados.
• Segredos: senha SMTP e tokens ficam em variaveis protegidas.
• Operacao: README ou runbook explicam como validar sem expor credenciais.

Essa separacao reduz risco de vazamento e facilita deploy em ambientes diferentes. Tambem ajuda em auditorias simples: quem tem acesso a senha, onde ela esta, como trocar e como confirmar que a troca funcionou.

7. Prepare rollback realista

Rollback de DNS nem sempre e instantaneo. Mesmo voltando um registro, caches podem manter a versao anterior por algum tempo. Por isso, a melhor estrategia e reduzir chance de erro antes da mudanca e ter um caminho claro se algo falhar.

Um rollback realista inclui:

• copia da zona DNS antiga;
• IP antigo e IP novo documentados;
• nomes de servidores de e-mail confirmados;
• acesso ao painel de DNS e ao provedor antigo;
• criterios para decidir voltar;
• pessoa responsavel pela comunicacao interna;
• validacao apos a reversao.

A pagina de continuidade operacional tecnica trata esse tipo de situacao como risco de operacao, nao como detalhe tecnico isolado. Dominio, DNS, e-mail e servidor fazem parte da mesma continuidade.

8. Evidencias para considerar a migracao concluida

Ao final, registre evidencias. Isso evita a frase "parece que esta tudo certo" e cria memoria para a proxima mudanca.

• Home e paginas internas respondendo pelo dominio final.
• HTTPS valido no dominio e no www, se existir.
• API ou backend respondendo onde precisa responder.
• Formulario salvando contato e enviando notificacao.
• E-mail do dominio recebendo e enviando.
• MX, SPF, DKIM e DMARC presentes.
• Search Console, sitemap, robots e ads.txt acessiveis quando o site usa SEO e AdSense.
• Logs sem erros recorrentes depois da mudanca.

A biblioteca de evidencias tecnicas pode ser usada como roteiro para guardar prints, respostas HTTP, cabecalhos, logs e testes sem expor dados sensiveis.

9. Erros comuns em migracoes de DNS e e-mail

Os erros mais frequentes aparecem quando a pressa junta coisas que deveriam ser tratadas separadamente.

• Apontar o dominio principal para a VPS e esquecer que mail dependia do provedor antigo.
• Proxyar nome usado por e-mail na Cloudflare.
• Copiar registros visiveis, mas perder TXT de verificacao ou DKIM.
• Testar apenas abertura do site e nao testar envio/recebimento de e-mail.
• Publicar formulario com SMTP que autentica, mas usa remetente nao permitido.
• Trocar DNS sem registro de rollback.
• Nao avisar quem usa Outlook, webmail ou ferramentas conectadas ao dominio.

A migracao bem feita nao e aquela que "vira a chave" mais rapido. E aquela que muda o necessario, preserva o que ja funcionava e deixa evidencias suficientes para a empresa confiar no novo ambiente.

10. Um roteiro simples de execucao

Para pequenas empresas, um roteiro enxuto ja resolve muito:

1. Inventarie a zona DNS atual.
2. Defina o que muda: site, VPS, Cloudflare, Nginx, pipeline ou hospedagem.
3. Defina o que nao deve mudar: e-mail, MX, SPF, DKIM, DMARC e verificacoes.
4. Prepare variaveis de ambiente do SMTP e segredos fora do repositorio.
5. Reduza TTL quando possivel.
6. Altere apontamentos web.
7. Teste site, API, formulario, SMTP, recebimento e envio de e-mail.
8. Valide sitemap, robots, ads.txt e Search Console quando o site depende de SEO e monetizacao.
9. Registre evidencias e atualize documentacao.
10. Monitore logs e caixa de e-mail nos dias seguintes.

Se a empresa usa o site como canal comercial, a migracao tambem afeta leads, campanhas e monetizacao. Por isso, DNS e e-mail precisam entrar no mesmo plano de mudanca que deploy, formulario, tags de conversao e AdSense.

Quando ha duvida sobre o que preservar, comece pelo inventario e pela validacao. A tecnologia pode variar, mas a disciplina e sempre parecida: entender dependencias, mudar em etapas, validar com evidencias e deixar o proximo responsavel menos perdido do que voce encontrou.