Transferir uma caixa de correio: guia de transição do DNS

Como transferir uma caixa de correio para outro fornecedor: guia de transição do DNS

Ao transferir os dados de uma caixa entre fornecedores de email, a estratégia de DNS pode fazer a diferença entre uma mudança tranquila e uma interrupção de até 48 horas. Um TTL mal configurado ou um include SPF esquecido pode causar devoluções definitivas e perdas comerciais.

Não há lugar para improvisos. Trata-se de uma sequência de operações técnicas precisas. Este guia explica como transferir o conteúdo de uma caixa com segurança, ajustando os tempos de propagação, combinando as identidades de autenticação SPF, DKIM e DMARC, e encaminhando o correio para o novo fornecedor com o menor risco possível de perder mensagens.

Para a migração dos dados, ou seja, a transferência efetiva das mensagens, consulte o guia de sincronização IMAP.

Por que motivo a propagação do DNS não é imediata ao transferir uma caixa

O DNS é um sistema de cache distribuído. Quando altera um registo, fica dependente de cada resolvedor recursivo, desde os servidores DNS dos fornecedores de Internet e o 8.8.8.8 da Google até aos routers locais, e da forma como respeita o valor do tempo de vida (TTL).

Se o TTL mantiver o valor comum de 86,400 segundos (24 horas), o encaminhamento pode ficar dividido até as caches expirarem. Algumas mensagens podem chegar à caixa nova e outras à antiga.

A cauda longa e a cache negativa

Dois fatores pouco visíveis costumam perturbar as transições de caixas de correio:

• A cauda longa: mesmo com um TTL baixo, estima-se que entre 1 e 5% dos resolvedores globais não respeitem valores inferiores a 60 minutos. Conte com algum tráfego residual para o fornecedor antigo durante cerca de uma hora após a mudança.
• Cache negativa (SOA): se consultar um registo antes de este existir, por exemplo, um seletor DKIM novo demasiado cedo, a resposta NXDOMAIN fica armazenada de acordo com o TTL mínimo do registo SOA, muitas vezes 1 hora. O registo válido pode assim continuar invisível até essa cache expirar, mesmo depois de ser publicado.

Fase 1: a contagem decrescente de 48 horas

Ainda não altere os registos MX. Prepare primeiro o ambiente para receber a mudança.

Passo 1: reduza os TTL (48 horas antes)

Localize os registos MX, SPF (TXT) e DMARC. Reduza o respetivo TTL para 300 segundos (5 minutos).

Isto reduz a janela prevista de propagação. Na transição final, as caches que respeitam o TTL poderão atualizar-se em cerca de 5 minutos, em vez de esperarem até 24 horas.

Passo 2: combine o SPF (24 horas antes)

O SPF (RFC 7208) autoriza endereços IP a enviar em seu nome. Durante a transição, tem de autorizar os dois fornecedores em simultâneo.

O problema: o SPF permite um máximo de 10 pesquisas DNS. Combinar dois fornecedores, como o Google Workspace e a TrekMail, pode ultrapassar esse limite.

A solução: simplifique o registo. Substitua instruções include: aninhadas por mecanismos ip4: diretos apenas quando o fornecedor publicar endereços estáveis e suportar a sua manutenção.

Exemplo de registo de transição:

Se utilizar SMTP externo com a TrekMail, como o Amazon SES ou o SendGrid, inclua antes os respetivos registos SPF.

Passo 3: publique o DKIM antecipadamente

O DKIM utiliza seletores, por exemplo, google._domainkey. Gere as chaves DKIM no novo fornecedor com um seletor único, como tm1._domainkey. Nunca reutilize o nome de um seletor. Os seletores novos podem ser publicados com vários dias de antecedência sem entrarem em conflito com o fornecedor antigo.

Passo 4: torne o DMARC menos restritivo

Se a política DMARC for p=reject ou p=quarantine, mude-a para p=none pelo menos 24 horas antes da transição. Podem ocorrer falhas de autenticação durante as primeiras horas. O p=none permite registá-las nos relatórios RUA sem pedir a rejeição por DMARC, mas a entrega continua dependente de outros controlos do destinatário. O guia de configuração do DMARC da Google explica como definir corretamente a política.

Fase 2: executar a transição

Os TTL estão baixos e a autenticação inclui os dois sistemas. Chegou o momento de encaminhar a caixa para o novo alojamento.

Passo 1: compare as respostas autoritativas e recursivas

Confirme que os registos novos estão visíveis no servidor de nomes autoritativo antes de os verificar através de resolvedores públicos:

Passo 2: atualize os registos MX

Adicione e confirme os MX novos antes de retirar os antigos, ou aplique a alteração de forma atómica se o fornecedor DNS o permitir. Para utilizadores da TrekMail:

Mantenha o TTL em 300 segundos. Ainda não o aumente.

Passo 3: limpe a cache e confirme

Limpe a cache DNS local com ipconfig /flushdns no Windows ou sudo dscacheutil -flushcache no macOS. Execute novamente o dig. Esta operação limpa apenas a cache local, e os MX novos aparecerão quando o resolvedor consultado atualizar a sua própria cache.

Fase 3: estabilização após a transição

Procure erros de atribuição do tenant (550 5.7.64)

Este erro é comum ao transferir o alojamento da caixa para o Microsoft 365 ou um conjunto semelhante. Se o destino ainda não tiver aprovisionado totalmente o domínio no diretório interno, pode rejeitar o correio com a mensagem «Relay Access Denied». Confirme que o estado do domínio é «Verified» ou «Healthy» no painel do novo fornecedor antes de mudar os MX.

Monitorize os relatórios DMARC (72 horas)

Acompanhe os relatórios RUA durante três dias:

• Êxito: o tráfego dos endereços IP do novo fornecedor passa nas verificações SPF e DKIM.
• Falha: tráfego legítimo de sistemas de faturação ou plataformas de marketing falha a autenticação. Atualize imediatamente o SPF ou o DKIM.

Limpeza (72 horas depois)

Quando o tráfego estabilizar:

1. Retire o include: do fornecedor antigo do registo SPF.
2. Retire os registos CNAME/TXT de DKIM antigos apenas depois de uma margem segura para as mensagens que ainda tenham assinaturas anteriores.
3. Volte a aumentar os TTL para 3,600s (1 hora) ou 86,400s (24 horas).
4. Volte a aplicar o DMARC com p=quarantine ou p=reject.

Resumo da lista para transferir uma caixa

A TrekMail simplifica a transferência de caixas

A gestão manual do DNS é propensa a erros. Um único erro de sintaxe num registo TXT pode invalidar toda a política SPF.

Para pequenas empresas

A TrekMail disponibiliza uma verificação do estado do DNS em tempo real. O painel consulta os servidores de nomes autoritativos e valida os registos MX, SPF e DKIM face à configuração necessária. Isto confirma a publicação autoritativa, não a propagação por todos os resolvedores, e assinala erros de sintaxe antes que possam causar devoluções.

Saiba mais sobre como configurar o email no seu próprio domínio.

Para agências

Gerir mais de 50 domínios exige normalização. A TrekMail permite aplicar um modelo DNS coerente a todos os tenants dos clientes. Nos planos Starter e Agency, o SMTP gerido cuida da reputação do IP e dos cabeçalhos de entrega, o que pode evitar configurações complexas de SPF ou calendários próprios de aquecimento do IP.

Veja como funciona o alojamento de email multidomínio para agências.

Todos os planos pagos incluem uma avaliação gratuita de 14 dias e exigem um cartão. O plano Nano não exige cartão.

Conclusão

Quando transfere uma caixa para outro fornecedor, a transição do DNS é uma das etapas mais delicadas. Reduza os TTL com antecedência, combine os registos de autenticação, mude os MX numa janela de manutenção e monitorize os relatórios DMARC durante 72 horas. Este é o procedimento.

Se preferir evitar a gestão manual de vários registos DNS, experimente a TrekMail gratuitamente e utilize o painel para validar a configuração.