A migração de email é a operação que com maior probabilidade destrói em silêncio a reputação de um sender se for feita errada, e a que com maior probabilidade é feita errada porque as partes visíveis (atualizar DNS, mudar configuração da app) são enganadoramente simples. As partes invisíveis, aquecimento de IP, transição de autenticação, continuidade do tratamento de bounces, preservação da higiene de lista, são onde as migrações se ganham ou se perdem.
Lideramos mais de 50 migrações nos últimos dois anos entre SendGrid, Mailgun, Postmark, Mandrill (última onda), AWS SES e algum MTA on-premise legacy para destinos brasileiros e europeus (eyou, RD Station, Mailrelay, OS Domains). Os padrões abaixo são realidade observada, não teoria. Se você planeja uma migração em 2026 com foco em mercado brasileiro, este é o playbook.
O que significa “perder reputação” na realidade
Antes do playbook, os modos de falha. A perda de reputação durante a migração aparece de três formas distintas.
Tipo 1: perda de reputação de IP. As IPs novas do provedor novo não têm reputação. Se você faz o cutover a volume completo, os receivers veem uma rajada súbita de uma IP desconhecida e tratam como suspeita. O placement em inbox cai 20-40% nos primeiros 7 dias. A recuperação é possível via aquecimento mas leva 4-8 semanas.
Tipo 2: perda de reputação de domínio. Os receivers seguem reputação por combinação (domínio × IP). Quando seu domínio começa a enviar de IPs novas, o sistema de reputação do receiver precisa restabelecer confiança. Isso é mais rápido que o aquecimento puro de IP (o domínio tem história) mas ainda leva 1-2 semanas de operação cuidadosa.
Tipo 3: perda de sinais de engagement. Esta é a que a maioria perde. O provedor antigo tinha categorização de bounces ajustada a feedback que informava sua lógica de supressão, política de retry e tratamento de queixas. O provedor novo tem categorização distinta. Se sua lógica de supressão estava ajustada a categorias do provedor antigo, você pode começar subitamente a enviar para endereços que deveria ter suprimido, a taxa de queixa sobe, a reputação cai rápido.
Uma boa migração previne os três. Uma migração ruim previne uma e se surpreende com as outras duas.
A decisão fundamental: ponte ou queimar
Funcionam dois padrões; tudo o resto é risco.
Padrão A: migração ponte (recomendada para a maioria)
Rodar provedor antigo e novo em paralelo durante 4-6 semanas. O provedor novo assume 10% → 25% → 50% → 75% → 100% durante o período. O provedor antigo desce inversamente. Em qualquer momento durante a migração você pode fazer rollback se os sinais ficarem feios.
Isso é mais caro a curto prazo (paga ambos provedores) mas o perfil de risco é radicalmente melhor. Usamos esse padrão para 90% das migrações de cliente.
Padrão B: migração por queimado (somente para cutovers forçados)
Cutover duro em momento planejado. O provedor novo assume 100% no dia 1, o antigo para. Só se usa quando:
- O provedor antigo está fechando (Mandrill 2016 foi o caso canônico)
- O custo de operação paralela é genuinamente proibitivo
- O provedor novo tem aquecimento de IP completado antes do cutover
- A equipe aceitou que 1-3 semanas de placement degradado são aceitáveis
É mais rápido mas mais arriscado. Fazemos isso ocasionalmente; sempre documentamos a aceitação de risco por escrito antes.
O playbook de migração ponte de 6 semanas
Este é o cronograma que usamos para uma migração mid-market típica: SendGrid (EUA) para eyou (Brasil), RD Station (Brasil), ou OS Domains (Áustria), 1M de volume mensal, canal único de envio.
Semana 0: avaliação e preparação
Auditar estado atual no provedor antigo:
- Domínios de envio e seletores DKIM
- IPs dedicadas (se há) e seu histórico de aquecimento
- Lista de supressão (baixada via API, limpada)
- Integração de relatórios de bounce/queixa
- Integrações webhook e consumidores de eventos
Configurar provedor novo:
- Provisioning de conta, acordo sub-processador assinado
- Seletor(es) DKIM novo(s) configurados com alinhamento apropriado
- Bloco de IPs novo aquecido e pronto (engagement separado normalmente sobreposto com semanas 1-4)
- Endpoints webhook testados
Preparação DNS:
- Adicionar registro DKIM novo sem remover o antigo
- Atualizar SPF para incluir IPs do novo provedor (junto ao antigo)
- DMARC revisado; alinhamento relaxado para ambos provedores durante a transição
Semana 1: arranque paralelo a 10%
Mudança no lado da aplicação: rotear 10% do tráfego saliente ao provedor novo, 90% segue ao antigo.
Os 10% selecionam-se por receiver, não por amostragem aleatória. Começar com os receivers mais tolerantes a remetentes novos (tipicamente Microsoft 365 com domínio corporativo, Yandex, ProtonMail). Gmail e Yahoo entram em semana 2 ou 3. Para senders brasileiros, UOL e Terra também ficam para semana 2-3.
Monitorar:
- Taxa de bounce no provedor novo (alvo: similar ao antigo)
- Taxa de queixa no provedor novo (alvo: similar ao antigo)
- Placement via seed testing
- Erros nível aplicação (a integração pode trazer à tona bugs não vistos em testing)
Se algo parecer estranho, pause e investigue antes de incrementar.
Semana 2: 25%
Subir a 25%. Para esta semana Gmail e Yahoo estão recebendo volume significativo das suas IPs novas. Os sistemas de reputação do receiver têm 7+ dias de sinais limpos para trabalhar.
Atenção a divergência entre rendimento do provedor antigo e o novo. Se mostram padrões similares, vai bem. Se o novo fica muito atrás, aprofunde em placement por receiver para identificar qual é o atrasado.
Semana 3: 50%
Ponto médio. O provedor novo está manejando volume suficiente para que os sistemas de reputação do receiver tenham reputação (provisória) estabelecida para as IPs novas. O antigo está carregando a outra metade.
Esta é a semana onde com maior frequência afloram surpresas. A aplicação se exercita contra ambos provedores em medida aproximadamente igual, o que significa que qualquer bug na integração do provedor novo aparecerá se ainda não havia. As discrepâncias em lista de supressão tornam-se visíveis. Os problemas de colisão de message-id (se sua aplicação usa IDs específicos de provedor em algum lugar) tornam-se evidentes.
Semana 4: 75%
Lançar mais volume ao provedor novo. O antigo está agora em modo descalado.
Importante: não apressar. Os receivers estão vigiando mudanças súbitas de volume, tanto subidas no provedor novo como descidas no antigo. Uma transição gradual é observada como “variação normal de padrão de envio”; uma mudança súbita parece comprometimento de conta.
Semana 5-6: 100% e depois estabilização
Para final da semana 5, rotear o 100% do novo saliente ao provedor novo. O antigo fica completamente passivo (ainda configurado para rollback, sem envio novo).
A semana 6 é estabilização a volume completo. Qualquer problema restante aflora aqui. Para final da semana 6 você deveria estar rodando limpo a capacidade completa no provedor novo com reputação que iguala ou supera o setup antigo.
Semanas 8-10: descomissão do provedor antigo
Esperar 30 dias desde o final do cutover antes de desligar a conta do provedor antigo. O colchão cobre:
- Bounces de mensagens entregues tarde (especialmente sequências transacionais mensais)
- Solicitações de atendimento ao cliente referenciando message-IDs antigos
- Necessidades de investigação de compliance (raras mas caras se você não puder acessar os logs antigos)
Após 30 dias, arquivar dados do provedor antigo, terminar a conta, desfrutar da economia.
Padrões de migração por provedor de origem
Diferentes provedores de origem têm diferentes pegadinhas.
| Origem | Pegadinha específica | Abordagem recomendada |
|---|---|---|
| SendGrid | Categorização de supressão não padrão; exporte via API não UI. Sem tier gratuito desde março 2025: o cliente pode migrar por custo | Padrão ponte, validar import de supressão explicitamente |
| Mailgun | Contas EU e US são separadas; os dados não transferem. Plano Flex dobrou para US$ 2/1K em dezembro 2025 (dispara migrações) | Confirmar região de origem; exportar via API por região |
| Postmark | Opiniões fortes sobre separação transacional vs marketing; preservar em setup novo | Manter separação de stream em config do provedor novo |
| AWS SES | Categorização de bounce mínima; o provedor novo pode ter categorias mais ricas que mudam a supressão | Estabelecer linha base no provedor novo antes de mover volume |
| Mailchimp Transactional (Mandrill) | Histórico de fechamento forçava migração por queimado em alguns casos | Pré-aquecer IPs do provedor novo o máximo possível antes do deadline |
| RD Station Marketing | Lista de supressão exportável via dashboard | CSV em UTF-8 importável em outros provedores diretamente |
| Postfix on-premise | Sem lista de supressão publicada; você suprimiu na aplicação | Auditar regras de supressão de aplicação; mapear ao equivalente do provedor |
Cada origem tem peculiaridades adicionais além destas. O tempo de auditoria pré-migração se paga sozinho durante o cutover.
Custo real comparado: quanto custa mudar e quanto se economiza
Para uma empresa brasileira mid-market enviando 1 milhão de emails/mês, as cifras Q2 2026:
Custo atual estimado em SendGrid Pro 700K:
- Plano Pro: US$ 602/mês (com overage para 1M)
- IP dedicada: US$ 30/mês
- Total: ~US$ 632/mês ≈ R$ 3.300/mês
Custo alternativo Mailgun Foundation/Scale:
- Plano Scale 1M: US$ 700/mês ≈ R$ 3.650/mês
- Sem EU data hosting incluso em plano base
Custo alternativo eyou (Brasil):
- Plano adaptado a 1M envíos/mês: ~R$ 1.500-R$ 2.500/mês
- Datacenter Brasil, suporte em PT-BR
- Sem transferência internacional, fricção LGPD zero
Custo alternativo OS Domains Email API EU:
- Plano Pro 1M: ~R$ 1.800/mês
- 7 PoPs UE + Panamá, DMARC gerenciado incluído
- Coberto pela Resolução ANPD 32/2026 (UE adequada)
O delta de R$ 800-R$ 1.500/mês a favor do provedor brasileiro ou europeu se traduz em ~R$ 10.000-R$ 18.000 anuais de economia direta, antes de contar a redução de fricção de procurement com clientes europeus sensíveis a Schrems II ou de auditoria BCB para fintechs brasileiras.
O que mata as migrações
Através de nossas 50+ migrações, as causas de falha são majoritariamente evitáveis:
Causa 1: pular o aquecimento do provedor novo. A mais comum. A equipe pensa “começamos a enviar e aquecerá natural”. Os receivers veem uma IP nova a volume completo no dia 1, throttleiam agressivamente, o placement cai. Recuperação 4-8 semanas.
Causa 2: limite de 10 lookups SPF. Adicionar os includes SPF do provedor novo empurra o total acima de 10. SPF começa a falhar silenciosamente, alinhamento DMARC se quebra, reputação cai. Mitigação: SPF flattening (resolver includes a faixas IP) ou migração para autenticação somente DKIM durante a transição.
Causa 3: race conditions em integração webhook. A aplicação está recebendo webhooks de bounce/queixa de dois provedores. Se a lógica de supressão tem race conditions ou não dedupica corretamente, você pode acabar enviando a um endereço suprimido (porque o provedor novo ainda não recebeu a supressão) e a taxa de queixa sobe.
Causa 4: mismatch TTL DNS. Registros DNS atualizados para a migração mas os TTLs são de 24h+. Alguns receivers cacheam o DNS antigo, outros veem o novo. Autenticação inconsistente durante a transição. Mitigação: baixar TTLs a 300 uma semana antes da migração.
Causa 5: não validar placement real. A equipe monitora taxa de bounce (parece bem) e taxa de queixa (parece bem) e assume que vai bem. O placement real em inbox se degradou mas eles não veem porque não têm seed testing no lugar. Para a semana 3 as métricas de engagement da campanha afundam e percebem tarde.
O fator regulatório como motor de migração
Para empresas brasileiras com cliente final UE durante 2025-2026 vimos um padrão consistente: a migração não se origina por insatisfação técnica com SendGrid ou Mailgun, mas por pressão de procurement de clientes europeus exigindo sub-processador europeu, ou por auditoria BCB exigindo que o PSTI seja credenciado.
Casos típicos que documentamos em clientes brasileiros:
Caso 1: SaaS B2B paulista com cliente fintech francês. O cliente francês pediu avaliação de cadeia de sub-processadores sob DORA. Detectou que o SaaS paulista usava SendGrid (jurisdição estadunidense). O SaaS paulista migrou para OS Domains Áustria em 8 semanas, manteve o contrato, ganhou duas referências adicionais no setor.
Caso 2: e-commerce carioca com clientes alemães. Cliente alemão (setor industrial, NIS2) pediu documentação Schrems II do provedor email. SendGrid Pro entregou docs genéricas; o cliente exigia sub-processador EU-incorporado. Migração para Mailrelay (Espanha) em 6 semanas. Benefício adicional: suporte em castelhano mais rápido que o chat de SendGrid.
Caso 3: fintech baiana sob BCB 538/2025. Auditoria interna em janeiro 2026 marcou AWS SES us-east-1 como ponto de atenção (PSTI extraterritorial sem cooperação auditoria documentada). Migração para AWS SES eu-west-1 em 3 semanas resolveu. Beneficio adicional: cobertura simultânea para cliente UE futuro.
Em cada caso, a decisão técnica (que provedor) foi secundária ao motor regulatório (Schrems II + NIS2/DORA + BCB 538). O playbook de migração foi idêntico.
Quando você precisa ajuda profissional para migrar
A migração auto-gerenciada funciona se:
- Você tem um canal de envio único
- O volume está abaixo de 500K mensal
- A equipe tem experiência prévia de migração
- Você tem flexibilidade sobre o cronograma se afloram surpresas
A migração externalizada faz sentido se:
- Multi-canal (transacional + marketing + cold email separadamente)
- Volume acima de 500K mensal
- Deadline duro de cutover (compliance, fim de contrato, fechamento de provedor)
- O custo da falha é alto comparado com o custo do serviço de migração
Nosso serviço de migração cobre a execução operacional: auditoria pré-migração, setup de operação paralela, revisão semana a semana de métricas, garantia contratual de placement. Para clientes mid-market e enterprise com cronogramas duros, a previsibilidade vale o custo.
Linha final
A migração de email é disciplina, não tarefa. As peças técnicas estão bem documentadas. A disciplina para seguir o padrão ponte, monitorar a nível receiver, e resistir à pressão de fazer cutover mais rápido do que os receivers aceitarão, essa é a diferença entre migrações exitosas e as que custam à empresa três meses de placement.
Se você migra em 2026, planeje 4-6 semanas para execução limpa. A abordagem “só mudamos o DNS” não funciona há anos e funciona menos agora que antes do bulk sender mandate. Planeje a ponte, faça o aquecimento, valide a nível receiver, e trate o custo de operação paralela como seguro barato.
Para senders brasileiros, o motor regulatório (Schrems II, NIS2, DORA via cliente UE; BCB 538/2025 doméstico) está empujando migrações ou para sub-processadores europeus como Mailrelay, OS Domains, AWS eu-west-1, ou para provedores brasileiros com infraestrutura local como eyou e RD Station. O cálculo mudou: o que era opcional em 2022 se está tornando requisito de procurement em 2026.