Trocar o provedor de e-mail do domínio: conferência DNS

Você pode trocar a hospedagem de e-mail do seu domínio mantendo endereços se reconstruir caixas, aliases e permissões. Uma alteração DNS incorreta pode afetar os fluxos. Cópia de mensagens e mudança de recebimento são tarefas separadas; misturá-las pode causar rejeições ou entregas divididas.

Para uma visão geral, consulte o e-mail empresarial. Aqui o foco é transferir o serviço de um domínio administrado entre provedores, coordenando MX, SPF, DKIM e DMARC enquanto os usuários trabalham.

Prepare caixas antes da cópia, reduza TTL antecipadamente, publique autenticação nova e altere MX com destino testado. Inverter essa ordem pode gerar correções posteriores.

O que significa transferir o e-mail de um domínio?

Você mantém domínio e endereços autorizados, mas muda o provedor de recebimento e a autenticação dos serviços emissores. Não é transferência do domínio entre registradores nem permite alterar o domínio de uma conta pessoal. A cópia também importa; DNS, caches e autenticação exigem coordenação.

Geralmente são três tarefas:

1. Copiar mensagens antigas ao destino, com as caixas de destino criadas previamente.
2. Completar e conferir as mesmas caixas, aliases e encaminhamentos com permissões.
3. Alterar DNS se mudar o recebimento do domínio próprio.

Não altere MX antes de preparar as caixas e conferir a cópia prévia. Teste SPF e DKIM: um erro pode afetar autenticação de saída, sem determinar sozinho spam ou rejeição.

Organize preparação, mudança e estabilização. O texto descreve importação IMAP de Gmail, Outlook, Yahoo, iCloud ou outro servidor em Starter e superiores; confira acesso e compatibilidade. IMAP copia mensagens, não calendários, contatos e todos os ajustes. Consulte imapsync para a operação de cópia.

Fase 1: preparar a mudança com 24-48 horas de antecedência

A preparação pode reduzir riscos. Crie caixas de destino primeiro, prepare autenticação, reduza TTL e copie o correio. A margem depende de caches e ambiente, não de prazo universal.

1. Reduzir TTL dos registros existentes

300 segundos é um TTL ilustrativo para MX, SPF e DMARC se o provedor permitir. Uma margem de 24-48 horas pode servir de referência sem garantir atualização mundial; cinco minutos antes não elimina caches antigos. Estas consultas são básicas: a última combina argumentos sem conferir DMARC de forma confiável; TXT da raiz também não valida o seletor DKIM:

dig example.com MX

dig example.com TXT

dig example.com TXT _dmarc.example.com

Se o TTL anterior era 3600 ou 86400, alguns resolvedores conservam respostas até expirarem. Comece dias antes, não na sexta-feira às 4:55 PM, e confira autoridade e resolvedores relevantes separadamente.

2. Copiar mensagens antes da mudança MX

Importe com a origem ativa, depois de criar a caixa de destino. O assistente TrekMail copia de contas IMAP externas conforme acesso e compatibilidade; confira conteúdo, datas, pastas e indicadores em um teste prévio.

Vincule o domínio, crie a caixa e consulte iniciar uma importação no painel. O importador usa credenciais IMAP diretas: senhas de app Gmail conforme políticas ou outro caminho autorizado com ferramenta compatível se OAuth for obrigatório. O texto descreve TrekMail sem POP3; isso não significa que POP sempre rompa continuidade, mas faça backup do correio local não sincronizado antes de retirar perfis.

3. Completar todas as identidades do destino

Antes de mudar o tráfego, crie e teste cada caixa, alias, encaminhamento e caixa curinga. Confira permissões, restrições de encaminhamento e casos menos comuns.

Exemplo: billing@, support@, careers@, noreply@, uma caixa curinga e um encaminhamento antigo ao Gmail do fundador. Omitir um pode deixar mensagens sem a rota prevista, mesmo com o restante funcionando.

Para várias marcas, um modelo multidomínio pode simplificar tarefas dentro dos limites. Consulte a hospedagem de e-mail multidomínio se precisa de escala, não apenas de uma mudança.

4. Unificar SPF antes da transferência

Durante a sobreposição, autorize todos os serviços legítimos ainda emissores, antigos e novos, para a identidade SMTP avaliada. A RFC 7208 limita a 10 os mecanismos e modificadores avaliados que exigem DNS, incluindo os aninhados; não conta todos os pacotes ou consultas de rede. O exemplo só corresponde se esses provedores continuarem autorizados:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

O texto descreve SMTP externo no TrekMail Free e gerenciado nos planos pagos; confira condições e rotas reais. Publique uma política SPF por nome DNS, não duas separadas; outros TXT sem relação podem coexistir.

5. Publicar DKIM e revisar a política DMARC

Publique o seletor novo antes da mudança e configure a assinatura real no provedor. Não sobrescreva o antigo enquanto ele assinar; conserve a chave pública enquanto mensagens em trânsito puderem precisar dela. Mudar para p=none é uma decisão temporária opcional do responsável após avaliar riscos, não obrigação nem garantia contra rejeições. As solicitações de quarentena ou rejeição da política DMARC podem ser mantidas se a autenticação estiver validada.

Considere cache negativo: um seletor consultado antes de existir pode permanecer ausente no cache conforme o SOA descrito na RFC 2308. Publique cedo e confira expiração e respostas reais.

Fase 2: executar a transição

Confira DNS autoritativo, altere MX com destino pronto, revise resolvedores públicos e teste recebimento e envio entre contas reais. A duração depende do ambiente.

Faça a mudança prevista sem limpeza DNS sem relação. Mantenha plano de retorno e origem disponível para recebimento tardio e sincronização administrativa.

1. Conferir a preparação do destino

Revise o que pode ser conferido antes de MX e teste as caixas. Active e indicadores verdes dependem dos valores publicados, sem comprovar todos os fluxos. Consulte adicionar um domínio ao TrekMail. O texto de março de 2026 apresenta este exemplo; use valores atuais da conta e política DMARC aprovada, não publique às cegas:

MX   @              mail.trekmail.net.   priority 10
TXT  @              v=spf1 include:spf.trekmail.net -all
TXT  dkim._domainkey  [unique value from dashboard]
TXT  _dmarc         v=DMARC1; p=quarantine;

Substitua MX de Google Workspace, Microsoft 365, Zoho, cPanel ou registrador no momento adequado. Prioridades geralmente indicam preferência e alternativa, não distribuição uniforme; manter destinos que aceitam correio pode levar mensagens a servidores diferentes.

2. Alterar MX e manter TTL baixo

Substitua o conjunto MX do domínio próprio após validar a preparação. Manter 300 na transição é uma escolha ilustrativa, não atualização simultânea de todos os emissores.

dig @8.8.8.8 example.com MX

dig @1.1.1.1 example.com MX

Consulte ao menos dois resolvedores públicos e compare a autoridade. Teste envio externo ao domínio e saída da caixa nova; repita passagens para chegadas tardias, movimentações e indicadores, incluindo mensagens com data antiga.

3. Conferir clientes IMAP

Confira ajustes atuais: IMAP imap.trekmail.net em 993 com TLS e SMTP smtp.trekmail.net em 465 com TLS implícito ou 587 com STARTTLS. Verifique cadeia de certificados, nome do servidor, endereço completo e senha da caixa, não do painel. Consulte ajustes IMAP e SMTP dos clientes.

“Consigo enviar, mas não receber” exige diagnóstico: DNS, caixas e aliases, cotas, filtros, pastas, caches e conexão do cliente. Use testes e registros para identificar a causa real.

Fase 3: observar as primeiras 72 horas

As primeiras 72 horas são uma janela ilustrativa, não comprovação de conclusão. Monitore recebimento, autenticação e serviços ainda na origem. Retire autorizações temporárias somente após confirmar que não são necessárias.

A mudança pode parecer concluída depois de dez minutos e revelar dependências nos dias seguintes. Continue monitorando conforme o tráfego e os serviços.

1. Procurar tráfego pelo provedor antigo

CRM, scanners, formulários WordPress, faturamento e suporte podem conservar SMTP antigo. Revise cabeçalhos e registros; atualize e teste cada integração antes de retirar autorização ou fortalecer a política.

2. Monitorar autenticação, não só entrega

Uma mensagem entregue pode ter falhas de autenticação; isso não comprova sozinho perda de reputação. Confira resultados adicionados pelo receptor confiável e alinhamento com From. DMARC pode passar com SPF válido e alinhado ou qualquer assinatura DKIM válida e alinhada. Encaminhamento pode afetar SPF; DKIM só ajuda se continuar válido e alinhado.

Para encaminhar externamente, consulte encaminhar e-mail do domínio ao Gmail sobre efeitos e configuração.

3. Retirar sobreposição após conferir o tráfego

Retire do SPF serviços não mais autorizados e conserve registros DKIM antigos enquanto filas ou verificações de mensagens encaminhadas precisarem deles. Você pode voltar a um TTL ilustrativo de 3600 conforme a operação. Se escolheu p=none, revise inventário, testes e relatórios antes de restaurar solicitações de quarentena ou rejeição da política DMARC.

A retirada verificada integra a transferência: evita autorizações desnecessárias sem apagar chaves ou serviços ainda usados por um prazo fixo.

Improviso e processo controlado

Não confunda hospedagem e transferência do domínio entre registradores. Prepare caixas e cópia, planeje uma única substituição MX, valide autenticação e use conferências que não substituam testes completos.

Se administra mais de um domínio, compare TrekMail por domínios próprios, caixas IMAP, caixa curinga, SMTP externo no Nano ou incluído nos planos pagos, encaminhamento, importação e API conforme condições atuais. O texto situa Starter a partir de $3.50 por mês e cita Free, Starter, Pro, Agency e Enterprise. Consulte os preços do TrekMail para limites e custos vigentes.

Lista final da transferência

A lista resume preparação, cópia, identidades, SPF, DKIM, decisão DMARC, mudança, testes e retirada verificada. Não autoriza MX antes de criar e conferir o destino nem exige flexibilizar políticas.

1. Reduzir TTL com margem ilustrativa de 24-48 horas e considerar caches anteriores.
2. Copiar correio por IMAP com caixas de destino já criadas.
3. Completar e testar caixas, aliases, encaminhamentos e caixa curinga.
4. Reunir autorizações SPF em uma política por nome.
5. Publicar DKIM com seletor novo e configurar assinatura real.
6. Considerar p=none somente se o responsável aprovar ajuste temporário e riscos.
7. Conferir destino, acesso e verificações disponíveis.
8. Substituir MX publicados mantendo recebimento antigo temporário.
9. Testar entrada e saída e repetir sincronizações de alterações.
10. Depois de janela ilustrativa de 72 horas, avaliar tráfego e chaves em trânsito antes de retirar autorizações ou ajustar DMARC.

Uma transferência controlada exige inventário, testes e acompanhamento, não só ajustes. TrekMail pode oferecer modelo multidomínio, armazenamento compartilhado e importação IMAP conforme o plano; avalie limites e custos sem presumir ausência de interrupção, perda ou adicionais.