Guia de Migração de Email de On-Premises para a Nuvem
Pássaro
28 de jun. de 2020
1 min read
Principais Conclusões
O Bird Cloud foi construído sobre o comprovado motor Momentum MTA, oferecendo aos clientes o desempenho de um sistema on-prem maduro com as vantagens adicionais de uma plataforma API de e-mail em nuvem moderna.
Muitos remetentes legados ainda dependem do Momentum ou PowerMTA, e o Bird oferece um caminho claro de migração para ambos—migração total para a nuvem ou roteamento híbrido através de nós on-prem.
A migração requer entender se você irá:
eliminar toda a infraestrutura on-prem, ou
continuar usando seu MTA para pré-processamento, roteamento ou restrições legadas.
O Bird aceita apenas injeção SMTP autenticada através das portas 587 ou 2525 (TLS fortemente recomendado). A injeção da API REST também está disponível para entrega baseada em JSON direta.
A Opção #1 (“cold turkey”) permite a desativação completa dos MTAs enviando diretamente para o Bird via SMTP ou REST, removendo complexidade e modernizando a arquitetura de envio.
A Opção #2 suporta ambientes híbridos—roteando fluxos selecionados do Momentum ou PMTA para o Bird configurando domínios de saída com SMTP_Auth para o Bird.
As configurações do PowerMTA e Momentum podem encaminhar tráfego para o Bird com segurança usando TLS, SMTP_Auth baseado em chave de API e definições de rota.
Clientes que usam scripts Lua avançados, substituição inline ou filtragem de pré-entrega podem permanecer híbridos até que a lógica seja reformulada para sistemas upstream.
O Bird suporta BYOIP (Bring Your Own IP) para clientes com um bloco contínuo /24, permitindo que você mantenha a reputação do IP aquecido e pule o aquecimento completo do IP.
Para usuários não-BYOIP, o Bird fornece aquecimento automático de IP e recomenda migração em estágios—começando com volumes pequenos, aumentando gradualmente o tráfego.
A configuração adequada de domínio (DKIM, SPF, DMARC, domínios de retorno, domínios de rastreamento) é essencial para alinhamento e coexistência suave durante a migração.
O Bird fornece dados de eventos em tempo real via webhooks ou Events API, permitindo automação downstream, fluxos ETL e reconstrução estilo log, se necessário.
Destaques de Perguntas e Respostas
Quais são os dois principais cenários de migração?
Ou desative completamente todos os MTAs locais (Opção #1) ou mantenha uma configuração híbrida onde parte do tráfego é roteado através do Momentum/PMTA antes de chegar ao Bird (Opção #2).
O que determina se você escolhe a Opção #1 ou a Opção #2?
Sua dependência de scripts Lua, lógica de pré-processamento, reescritas de mensagens, requisitos de segurança ou geradores que não podem enviar tráfego autenticado pela porta 587.
O Bird aceita injeção SMTP pela porta 25?
Não—Bird requer injeção SMTP através da porta 587 ou 2525, autenticada com SMTP_Auth.
O TLS é necessário?
Não é estritamente necessário, mas é fortemente recomendado para injeção de mensagens seguras a partir de geradores ou MTAs locais.
Os remetentes podem usar a API REST em vez do SMTP?
Sim—os remetentes podem enviar cargas úteis JSON por meio da API REST de Transmissões, simplificando frequentemente os fluxos de trabalho e eliminando a necessidade de gerar mensagens SMTP brutas.
O que é o programa BYOIP da Bird?
Um processo que permite aos clientes com um bloco contíguo /24 migrar seus IPs existentes para o Bird, mantendo a reputação e pulando o aquecimento.
E se o BYOIP não for uma opção?
Use novos domínios de envio (por exemplo, sp.seudominio.com), execute ambos os ambientes em paralelo e confie no aquecimento automático de IP da Bird.
Como você roteia apenas os streams selecionados através do Bird em uma configuração híbrida?
Ao configurar domínios de saída (Momentum) ou configurações de rollup/VMTAs (PowerMTA) que autentiquem e entreguem ao endpoint SMTP do Bird.
Quais alterações de metadata são necessárias ao injetar via SMTP?
Adicione um
X-MSYS-APIcabeçalho contendo atributos comoip_pool,campaigne qualquer metadado personalizado anteriormente tratado através de X-Headers.O que deve ser configurado no DNS antes da migração?
Registros DKIM, SPF, DMARC, domínios de retorno e domínios de rastreamento para garantir o alinhamento de domínios e reduzir o risco de entregabilidade durante a transição.
Como o tráfego deve ser migrado para o Bird?
Gradualmente: comece com um pequeno fluxo, depois 10%, depois 20%, aumentando diariamente até que todo o tráfego tenha sido transferido—similar às melhores práticas de aquecimento de IP.
Como os remetentes podem coletar dados de entrega e engajamento após a migração?
Ao usar o sistema de webhook em tempo real do Bird ou a API de Eventos; coletores de webhook podem ser construídos rapidamente e alimentar o armazenamento ou sistemas ETL a jusante.
Muitas vezes, ouvimos a pergunta: “Você tem algum manual que descreva o processo de migração de uma instalação local para o Bird?”
Sim, temos sim. Continue lendo.
Primeiro, um pouco de história. O serviço Bird Cloud foi criado em 2014 a partir do enorme sucesso da solução On-Premises Momentum MTA. O Momentum está no centro do Bird Cloud, proporcionando entrega de alta velocidade e modelagem de tráfego para milhares de clientes no serviço em nuvem. Por causa disso, o Momentum recebe uma grande parte da nossa atenção de engenharia, mas os resultados desse trabalho muitas vezes estão enterrados em melhorias de desempenho que não recebem muita cobertura na imprensa. Os clientes do Momentum veem os benefícios desse trabalho toda vez que uma nova versão pública do Momentum é publicada.
Isso NÃO significa que o Bird é apenas “Momentum na Nuvem”. A MessageBird é muito mais do que isso e pode ter benefícios adicionais para clientes que escolhem migrar ou usá-los em uma abordagem híbrida. Esses benefícios decorrem da nossa moderna arquitetura de API de e-mail baseada em nuvem, que proporciona capacidades não disponíveis em soluções tradicionais on-premises. Além disso, facilitamos muito a migração ou uso do PowerMTA com o Bird em uma configuração híbrida também. O restante deste documento descreverá em detalhes como você pode migrar seus fluxos de mensagens do Momentum ou PowerMTA para o serviço Bird Cloud.
Existem realmente dois cenários separados a considerar ao migrar para o Bird a partir do Momentum ou PowerMTA.
Você está pronto para deixar o mundo on-premises completamente, desligar seus centros de dados físicos e não gerenciar mais nenhum MTA on-premises diretamente. Isso significa eliminar o Momentum ou PowerMTA de sua implantação e enviar mensagens diretamente para o SparkPost para manuseio de mensagens. Antes de desativar sua infraestrutura on-premises, certifique-se de ter backups de banco de dados abrangentes de todos os sistemas críticos, especialmente se você estiver executando bancos de dados PostgreSQL que contêm dados ou configurações históricas importantes.
Você tem motivos para manter alguma presença on-premises por um motivo ou outro. Algumas possibilidades podem ser:
fluxos de entrega específicos que requerem pré-processamento no Momentum
divisão de capacidade para necessidades de pico ou recuperação de desastres
apoio a clientes legados no PMTA enquanto desloca novos clientes para o SparkPost
…então você deseja encaminhar as outras mensagens para o Bird para manuseio de mensagens subsequente.
Em qualquer uma das situações, você precisa estar ciente de que o Bird só aceitará mensagens SMTP para entrega que sejam injetadas pela porta 587 ou 2525 e usem SMTP_Auth com um nome de usuário e senha específicos (Veja a documentação SMTP aqui). Também recomendamos fortemente a conexão com uma conexão TLS, mas isso não é estritamente necessário. Se você estiver substituindo completamente sua camada de MTA (cenário 1), então você também pode querer considerar usar a Transmissions REST API, que pode aceitar mensagens por meio de conexões HTTPS. A documentação dessa API está aqui.
Para organizações que mantêm infraestrutura on-premises que requer capacidades de e-mail seguro, nosso guia de implementação S/MIME para PowerMTA e Momentum fornece instruções detalhadas de configuração para entrega de e-mail criptografado.
Muitas vezes, ouvimos a pergunta: “Você tem algum manual que descreva o processo de migração de uma instalação local para o Bird?”
Sim, temos sim. Continue lendo.
Primeiro, um pouco de história. O serviço Bird Cloud foi criado em 2014 a partir do enorme sucesso da solução On-Premises Momentum MTA. O Momentum está no centro do Bird Cloud, proporcionando entrega de alta velocidade e modelagem de tráfego para milhares de clientes no serviço em nuvem. Por causa disso, o Momentum recebe uma grande parte da nossa atenção de engenharia, mas os resultados desse trabalho muitas vezes estão enterrados em melhorias de desempenho que não recebem muita cobertura na imprensa. Os clientes do Momentum veem os benefícios desse trabalho toda vez que uma nova versão pública do Momentum é publicada.
Isso NÃO significa que o Bird é apenas “Momentum na Nuvem”. A MessageBird é muito mais do que isso e pode ter benefícios adicionais para clientes que escolhem migrar ou usá-los em uma abordagem híbrida. Esses benefícios decorrem da nossa moderna arquitetura de API de e-mail baseada em nuvem, que proporciona capacidades não disponíveis em soluções tradicionais on-premises. Além disso, facilitamos muito a migração ou uso do PowerMTA com o Bird em uma configuração híbrida também. O restante deste documento descreverá em detalhes como você pode migrar seus fluxos de mensagens do Momentum ou PowerMTA para o serviço Bird Cloud.
Existem realmente dois cenários separados a considerar ao migrar para o Bird a partir do Momentum ou PowerMTA.
Você está pronto para deixar o mundo on-premises completamente, desligar seus centros de dados físicos e não gerenciar mais nenhum MTA on-premises diretamente. Isso significa eliminar o Momentum ou PowerMTA de sua implantação e enviar mensagens diretamente para o SparkPost para manuseio de mensagens. Antes de desativar sua infraestrutura on-premises, certifique-se de ter backups de banco de dados abrangentes de todos os sistemas críticos, especialmente se você estiver executando bancos de dados PostgreSQL que contêm dados ou configurações históricas importantes.
Você tem motivos para manter alguma presença on-premises por um motivo ou outro. Algumas possibilidades podem ser:
fluxos de entrega específicos que requerem pré-processamento no Momentum
divisão de capacidade para necessidades de pico ou recuperação de desastres
apoio a clientes legados no PMTA enquanto desloca novos clientes para o SparkPost
…então você deseja encaminhar as outras mensagens para o Bird para manuseio de mensagens subsequente.
Em qualquer uma das situações, você precisa estar ciente de que o Bird só aceitará mensagens SMTP para entrega que sejam injetadas pela porta 587 ou 2525 e usem SMTP_Auth com um nome de usuário e senha específicos (Veja a documentação SMTP aqui). Também recomendamos fortemente a conexão com uma conexão TLS, mas isso não é estritamente necessário. Se você estiver substituindo completamente sua camada de MTA (cenário 1), então você também pode querer considerar usar a Transmissions REST API, que pode aceitar mensagens por meio de conexões HTTPS. A documentação dessa API está aqui.
Para organizações que mantêm infraestrutura on-premises que requer capacidades de e-mail seguro, nosso guia de implementação S/MIME para PowerMTA e Momentum fornece instruções detalhadas de configuração para entrega de e-mail criptografado.
Muitas vezes, ouvimos a pergunta: “Você tem algum manual que descreva o processo de migração de uma instalação local para o Bird?”
Sim, temos sim. Continue lendo.
Primeiro, um pouco de história. O serviço Bird Cloud foi criado em 2014 a partir do enorme sucesso da solução On-Premises Momentum MTA. O Momentum está no centro do Bird Cloud, proporcionando entrega de alta velocidade e modelagem de tráfego para milhares de clientes no serviço em nuvem. Por causa disso, o Momentum recebe uma grande parte da nossa atenção de engenharia, mas os resultados desse trabalho muitas vezes estão enterrados em melhorias de desempenho que não recebem muita cobertura na imprensa. Os clientes do Momentum veem os benefícios desse trabalho toda vez que uma nova versão pública do Momentum é publicada.
Isso NÃO significa que o Bird é apenas “Momentum na Nuvem”. A MessageBird é muito mais do que isso e pode ter benefícios adicionais para clientes que escolhem migrar ou usá-los em uma abordagem híbrida. Esses benefícios decorrem da nossa moderna arquitetura de API de e-mail baseada em nuvem, que proporciona capacidades não disponíveis em soluções tradicionais on-premises. Além disso, facilitamos muito a migração ou uso do PowerMTA com o Bird em uma configuração híbrida também. O restante deste documento descreverá em detalhes como você pode migrar seus fluxos de mensagens do Momentum ou PowerMTA para o serviço Bird Cloud.
Existem realmente dois cenários separados a considerar ao migrar para o Bird a partir do Momentum ou PowerMTA.
Você está pronto para deixar o mundo on-premises completamente, desligar seus centros de dados físicos e não gerenciar mais nenhum MTA on-premises diretamente. Isso significa eliminar o Momentum ou PowerMTA de sua implantação e enviar mensagens diretamente para o SparkPost para manuseio de mensagens. Antes de desativar sua infraestrutura on-premises, certifique-se de ter backups de banco de dados abrangentes de todos os sistemas críticos, especialmente se você estiver executando bancos de dados PostgreSQL que contêm dados ou configurações históricas importantes.
Você tem motivos para manter alguma presença on-premises por um motivo ou outro. Algumas possibilidades podem ser:
fluxos de entrega específicos que requerem pré-processamento no Momentum
divisão de capacidade para necessidades de pico ou recuperação de desastres
apoio a clientes legados no PMTA enquanto desloca novos clientes para o SparkPost
…então você deseja encaminhar as outras mensagens para o Bird para manuseio de mensagens subsequente.
Em qualquer uma das situações, você precisa estar ciente de que o Bird só aceitará mensagens SMTP para entrega que sejam injetadas pela porta 587 ou 2525 e usem SMTP_Auth com um nome de usuário e senha específicos (Veja a documentação SMTP aqui). Também recomendamos fortemente a conexão com uma conexão TLS, mas isso não é estritamente necessário. Se você estiver substituindo completamente sua camada de MTA (cenário 1), então você também pode querer considerar usar a Transmissions REST API, que pode aceitar mensagens por meio de conexões HTTPS. A documentação dessa API está aqui.
Para organizações que mantêm infraestrutura on-premises que requer capacidades de e-mail seguro, nosso guia de implementação S/MIME para PowerMTA e Momentum fornece instruções detalhadas de configuração para entrega de e-mail criptografado.
Qual opção eu escolho?
Para descobrir se você está na opção #1 ou na opção #2, considere estes fatores:
Opção | Melhor se você | Requisito chave | Compensação |
|---|---|---|---|
Opção #1: Migração total para a nuvem | Pode remover todos os MTAs on-prem | SMTP Auth sobre 587/2525 ou REST API | Requer refatoração de qualquer lógica avançada on-prem |
Opção #2: Roteamento híbrido | Necessita de suporte de pré-processamento ou legado | Momentum ou PowerMTA permanece online | Complexidade operacional adicional |
Você usa o motor de script Lua do Momentum para algo mais complicado do que roteamento de mensagens?
Lua é uma ferramenta de script abrangente para manipular mensagens em linha, mas a grande maioria de nossos usuários a utiliza apenas para selecionar uma vinculação para entrega. Se esse for o caso, você pode modificar seu código de geração para adicionar um atributo ip_pool ao cabeçalho X-MSYS-API e deixar o Bird atribuir a rota para você.
Se você usar Lua para fazer coisas mais complicadas como filtragem de corpo, reescritas de Mail_From ou cálculos de cadência de mensagens, e não for viável mover essa lógica para o seu aplicativo de injeção, você pode querer considerar mudar para o grupo da Opção #2.
Seu sistema de geração é capaz de enviar mensagens pela porta 587 usando TLS e SMTP_Auth?
Alguns sistemas de gerenciamento de campanhas só conseguem enviar e-mails pela porta 25 em texto claro. Isso causa um problema de segurança para o Bird, então você pode querer considerar a Opção #2
Você está usando a sintaxe de substituição PowerMTA ou outra modificação de mensagem em linha?
Se você puder mover essa função para seus geradores ou usar a Linguagem de Modelo do Bird, então você ainda pode usar a opção 1, mas caso contrário, pode precisar pensar em manter um nó PMTA online para essa modificação de mensagem antes de enviar para o Bird para entrega.
Você precisa de qualquer escaneamento AV/AS de entrada antes da injeção? Embora isso seja possível no Momentum e PowerMTA, o eBird assume que você já realizou todas essas verificações. Você pode querer considerar fazer isso antes da injeção.
Não importa por qual caminho você opte, isso certamente afetará seu relacionamento comercial. Como você pode imaginar, essa não é nossa primeira experiência. Certifique-se de envolver seu Gerente de Conta Comercial e seu Gerente de Sucesso do Cliente para que possamos ajudá-lo nos detalhes e garantir que você esteja obtendo o melhor valor pelo seu dinheiro.
Para descobrir se você está na opção #1 ou na opção #2, considere estes fatores:
Opção | Melhor se você | Requisito chave | Compensação |
|---|---|---|---|
Opção #1: Migração total para a nuvem | Pode remover todos os MTAs on-prem | SMTP Auth sobre 587/2525 ou REST API | Requer refatoração de qualquer lógica avançada on-prem |
Opção #2: Roteamento híbrido | Necessita de suporte de pré-processamento ou legado | Momentum ou PowerMTA permanece online | Complexidade operacional adicional |
Você usa o motor de script Lua do Momentum para algo mais complicado do que roteamento de mensagens?
Lua é uma ferramenta de script abrangente para manipular mensagens em linha, mas a grande maioria de nossos usuários a utiliza apenas para selecionar uma vinculação para entrega. Se esse for o caso, você pode modificar seu código de geração para adicionar um atributo ip_pool ao cabeçalho X-MSYS-API e deixar o Bird atribuir a rota para você.
Se você usar Lua para fazer coisas mais complicadas como filtragem de corpo, reescritas de Mail_From ou cálculos de cadência de mensagens, e não for viável mover essa lógica para o seu aplicativo de injeção, você pode querer considerar mudar para o grupo da Opção #2.
Seu sistema de geração é capaz de enviar mensagens pela porta 587 usando TLS e SMTP_Auth?
Alguns sistemas de gerenciamento de campanhas só conseguem enviar e-mails pela porta 25 em texto claro. Isso causa um problema de segurança para o Bird, então você pode querer considerar a Opção #2
Você está usando a sintaxe de substituição PowerMTA ou outra modificação de mensagem em linha?
Se você puder mover essa função para seus geradores ou usar a Linguagem de Modelo do Bird, então você ainda pode usar a opção 1, mas caso contrário, pode precisar pensar em manter um nó PMTA online para essa modificação de mensagem antes de enviar para o Bird para entrega.
Você precisa de qualquer escaneamento AV/AS de entrada antes da injeção? Embora isso seja possível no Momentum e PowerMTA, o eBird assume que você já realizou todas essas verificações. Você pode querer considerar fazer isso antes da injeção.
Não importa por qual caminho você opte, isso certamente afetará seu relacionamento comercial. Como você pode imaginar, essa não é nossa primeira experiência. Certifique-se de envolver seu Gerente de Conta Comercial e seu Gerente de Sucesso do Cliente para que possamos ajudá-lo nos detalhes e garantir que você esteja obtendo o melhor valor pelo seu dinheiro.
Para descobrir se você está na opção #1 ou na opção #2, considere estes fatores:
Opção | Melhor se você | Requisito chave | Compensação |
|---|---|---|---|
Opção #1: Migração total para a nuvem | Pode remover todos os MTAs on-prem | SMTP Auth sobre 587/2525 ou REST API | Requer refatoração de qualquer lógica avançada on-prem |
Opção #2: Roteamento híbrido | Necessita de suporte de pré-processamento ou legado | Momentum ou PowerMTA permanece online | Complexidade operacional adicional |
Você usa o motor de script Lua do Momentum para algo mais complicado do que roteamento de mensagens?
Lua é uma ferramenta de script abrangente para manipular mensagens em linha, mas a grande maioria de nossos usuários a utiliza apenas para selecionar uma vinculação para entrega. Se esse for o caso, você pode modificar seu código de geração para adicionar um atributo ip_pool ao cabeçalho X-MSYS-API e deixar o Bird atribuir a rota para você.
Se você usar Lua para fazer coisas mais complicadas como filtragem de corpo, reescritas de Mail_From ou cálculos de cadência de mensagens, e não for viável mover essa lógica para o seu aplicativo de injeção, você pode querer considerar mudar para o grupo da Opção #2.
Seu sistema de geração é capaz de enviar mensagens pela porta 587 usando TLS e SMTP_Auth?
Alguns sistemas de gerenciamento de campanhas só conseguem enviar e-mails pela porta 25 em texto claro. Isso causa um problema de segurança para o Bird, então você pode querer considerar a Opção #2
Você está usando a sintaxe de substituição PowerMTA ou outra modificação de mensagem em linha?
Se você puder mover essa função para seus geradores ou usar a Linguagem de Modelo do Bird, então você ainda pode usar a opção 1, mas caso contrário, pode precisar pensar em manter um nó PMTA online para essa modificação de mensagem antes de enviar para o Bird para entrega.
Você precisa de qualquer escaneamento AV/AS de entrada antes da injeção? Embora isso seja possível no Momentum e PowerMTA, o eBird assume que você já realizou todas essas verificações. Você pode querer considerar fazer isso antes da injeção.
Não importa por qual caminho você opte, isso certamente afetará seu relacionamento comercial. Como você pode imaginar, essa não é nossa primeira experiência. Certifique-se de envolver seu Gerente de Conta Comercial e seu Gerente de Sucesso do Cliente para que possamos ajudá-lo nos detalhes e garantir que você esteja obtendo o melhor valor pelo seu dinheiro.
Para a Opção #1 Acampamento (Parar “do nada”):
Vamos supor que você esteja de acordo com a opção 1 e esteja pronto para desligar seus MTAs locais e decidiu continuar usando o método de injeção SMTP, sem mudar seus sistemas de criação de mensagens. Seus sistemas de geração devem criar uma mensagem SMTP totalmente formatada e, em seguida, enviá-la para o Bird através de TLS usando SMTP_AUTH, onde o nome de usuário e a senha são conforme descrito na esta página. Lembre-se de que a "senha" é a chave da API que você gera em sua conta Bird com a opção de entrega SMTP ativada.
Se você está no grupo da Opção #1, considere mudar para a API REST diretamente de seu sistema de geração. Na maioria dos casos, descobrimos que os sistemas de processamento dos clientes já estão usando JSON sobre HTTP e precisam converter para SMTP antes da injeção. Você pode pular essa etapa e enviar diretamente para nós como um payload REST formatado em JSON.
Se você optar por injetar com a API REST, pode ser necessário alterar um pouco seu sistema de criação de conteúdo, mas pode valer a pena. Você pode saber mais aqui.
Uma das maiores preocupações que grandes ESPs têm com uma Migração é o Aquecimento de IP. Normalmente, eles gastaram muitos anos cuidando de seu inventário de endereços IP com grande atenção, então a ideia de abandonar todo esse trabalho é dolorosa. O Bird desenvolveu um processo de Bringue O seu PRóprio IP (BYOIP) que cuida dessa questão. Se você tiver pelo menos um bloco CIDR contíguo /24, o Bird pode usar esses IPs existentes para entrega, o que economiza a dor de precisar aquecê-los novamente. Se você puder aproveitar essa opção, pode pular a seção sobre aquecimento de IP aqui.
Se você sente que está pronto para seguir adiante, pule para "Fazendo acontecer"
Vamos supor que você esteja de acordo com a opção 1 e esteja pronto para desligar seus MTAs locais e decidiu continuar usando o método de injeção SMTP, sem mudar seus sistemas de criação de mensagens. Seus sistemas de geração devem criar uma mensagem SMTP totalmente formatada e, em seguida, enviá-la para o Bird através de TLS usando SMTP_AUTH, onde o nome de usuário e a senha são conforme descrito na esta página. Lembre-se de que a "senha" é a chave da API que você gera em sua conta Bird com a opção de entrega SMTP ativada.
Se você está no grupo da Opção #1, considere mudar para a API REST diretamente de seu sistema de geração. Na maioria dos casos, descobrimos que os sistemas de processamento dos clientes já estão usando JSON sobre HTTP e precisam converter para SMTP antes da injeção. Você pode pular essa etapa e enviar diretamente para nós como um payload REST formatado em JSON.
Se você optar por injetar com a API REST, pode ser necessário alterar um pouco seu sistema de criação de conteúdo, mas pode valer a pena. Você pode saber mais aqui.
Uma das maiores preocupações que grandes ESPs têm com uma Migração é o Aquecimento de IP. Normalmente, eles gastaram muitos anos cuidando de seu inventário de endereços IP com grande atenção, então a ideia de abandonar todo esse trabalho é dolorosa. O Bird desenvolveu um processo de Bringue O seu PRóprio IP (BYOIP) que cuida dessa questão. Se você tiver pelo menos um bloco CIDR contíguo /24, o Bird pode usar esses IPs existentes para entrega, o que economiza a dor de precisar aquecê-los novamente. Se você puder aproveitar essa opção, pode pular a seção sobre aquecimento de IP aqui.
Se você sente que está pronto para seguir adiante, pule para "Fazendo acontecer"
Vamos supor que você esteja de acordo com a opção 1 e esteja pronto para desligar seus MTAs locais e decidiu continuar usando o método de injeção SMTP, sem mudar seus sistemas de criação de mensagens. Seus sistemas de geração devem criar uma mensagem SMTP totalmente formatada e, em seguida, enviá-la para o Bird através de TLS usando SMTP_AUTH, onde o nome de usuário e a senha são conforme descrito na esta página. Lembre-se de que a "senha" é a chave da API que você gera em sua conta Bird com a opção de entrega SMTP ativada.
Se você está no grupo da Opção #1, considere mudar para a API REST diretamente de seu sistema de geração. Na maioria dos casos, descobrimos que os sistemas de processamento dos clientes já estão usando JSON sobre HTTP e precisam converter para SMTP antes da injeção. Você pode pular essa etapa e enviar diretamente para nós como um payload REST formatado em JSON.
Se você optar por injetar com a API REST, pode ser necessário alterar um pouco seu sistema de criação de conteúdo, mas pode valer a pena. Você pode saber mais aqui.
Uma das maiores preocupações que grandes ESPs têm com uma Migração é o Aquecimento de IP. Normalmente, eles gastaram muitos anos cuidando de seu inventário de endereços IP com grande atenção, então a ideia de abandonar todo esse trabalho é dolorosa. O Bird desenvolveu um processo de Bringue O seu PRóprio IP (BYOIP) que cuida dessa questão. Se você tiver pelo menos um bloco CIDR contíguo /24, o Bird pode usar esses IPs existentes para entrega, o que economiza a dor de precisar aquecê-los novamente. Se você puder aproveitar essa opção, pode pular a seção sobre aquecimento de IP aqui.
Se você sente que está pronto para seguir adiante, pule para "Fazendo acontecer"
Aproveitando a Opção #2 (pré-processamento local):
No entanto, se você estiver na equipe da Opção #2, então você vai querer adicionar algumas mudanças de configuração ao seu deployment. A maneira menos dolorosa de migrar alguns fluxos de mensagens selecionados do Momentum ou PMTA para o Bird enquanto ainda usa injeção SMTP dos seus sistemas de geração é adicionar uma rota especial na sua configuração.
Para Momentum:
Configure uma versão do Momentum > 3.6.23.
Instale um certificado SSL válido e abra a porta de saída 587 para que o Momentum possa se comunicar com o Bird. Configure um domínio de saída para que você possa encaminhar uma mensagem do Momentum para o Bird.
Com a configuração abaixo, qualquer mensagem que atingir essa configuração será roteada para smtp.sparkpostmail.com usando a porta 587 e SMTP_Auth com o nome de usuário e senha definidos lá.
outbound_smtp_auth { } Keep_Message_Dicts_In_Memory = true Domain "smtp.sparkpostmail.com" { Remote_SMTP_Port = "587" Outbound_SMTP_AUTH_Type = "LOGIN" Outbound_SMTP_AUTH_user = "SMTP_Injection" Outbound_SMTP_AUTH_pass = "17258redacted8bd6cd7a8redacted8c22bce" }
Configure os bindings que você deseja retransmitir através do MessageBird com TLS e encaminhe-os para o domínio que você definiu acima.
Nota: O TLS não é estritamente necessário, mas é uma forte recomendação. Se o TLS não for possível por algum motivo, então a lista de permissões de IP das chaves da API também é uma forte recomendação.binding "CustomerA-Outbound" { Gateway = "smtp-demo.sparkpostelite.com" TLS = "required" TLS_Certificate = "/etc/pki/tls/certs/trymsys.net.crt" TLS_Key = "/etc/pki/tls/certs/trymsys.net.key" TLS_Ciphers = "DEFAULT" }
Para PowerMTA:
Configure uma versão do PowerMTA > 4.5.0
Instale um certificado SSL válido e abra a porta de saída 587 para que o PowerMTA possa se comunicar com o Bird.
Configure um caminho de domínio de saída para que você possa encaminhar uma mensagem do PowerMTA para o Bird. Com a configuração abaixo, qualquer mensagem que atingir essa configuração será roteada para smtp.sparkpostmail.com usando a porta 587 e SMTP_Auth com o nome de usuário e senha definidos lá. No PowerMTA, é também onde você pode definir o TLS. Nota: isso também está documentado mais completamente aqui
<domain sparkpost.rollup> use-unencrypted-plain-auth yes auth-username SMTP_Injection auth-password YourAPIKeygoesherewhenyougenerateit route smtp.sparkpostmail.com:587 use-starttls yes require-starttls yes max-smtp-out 10 </domain>
4. Configure os VMTAs que você deseja retransmitir através do Bird com a configuração do rollup {sparkpost} que você definiu acima.
<virtual-mta SparkPostRelay> <domain *> queue-to {sparkpost} </domain> </virtual-mta>
Uma vez que você tenha feito essas mudanças de configuração, qualquer mensagem enviada para o “binding” ou “VMTA” selecionado deve ser roteada automaticamente através do Bird para entrega.
No entanto, se você estiver na equipe da Opção #2, então você vai querer adicionar algumas mudanças de configuração ao seu deployment. A maneira menos dolorosa de migrar alguns fluxos de mensagens selecionados do Momentum ou PMTA para o Bird enquanto ainda usa injeção SMTP dos seus sistemas de geração é adicionar uma rota especial na sua configuração.
Para Momentum:
Configure uma versão do Momentum > 3.6.23.
Instale um certificado SSL válido e abra a porta de saída 587 para que o Momentum possa se comunicar com o Bird. Configure um domínio de saída para que você possa encaminhar uma mensagem do Momentum para o Bird.
Com a configuração abaixo, qualquer mensagem que atingir essa configuração será roteada para smtp.sparkpostmail.com usando a porta 587 e SMTP_Auth com o nome de usuário e senha definidos lá.
outbound_smtp_auth { } Keep_Message_Dicts_In_Memory = true Domain "smtp.sparkpostmail.com" { Remote_SMTP_Port = "587" Outbound_SMTP_AUTH_Type = "LOGIN" Outbound_SMTP_AUTH_user = "SMTP_Injection" Outbound_SMTP_AUTH_pass = "17258redacted8bd6cd7a8redacted8c22bce" }
Configure os bindings que você deseja retransmitir através do MessageBird com TLS e encaminhe-os para o domínio que você definiu acima.
Nota: O TLS não é estritamente necessário, mas é uma forte recomendação. Se o TLS não for possível por algum motivo, então a lista de permissões de IP das chaves da API também é uma forte recomendação.binding "CustomerA-Outbound" { Gateway = "smtp-demo.sparkpostelite.com" TLS = "required" TLS_Certificate = "/etc/pki/tls/certs/trymsys.net.crt" TLS_Key = "/etc/pki/tls/certs/trymsys.net.key" TLS_Ciphers = "DEFAULT" }
Para PowerMTA:
Configure uma versão do PowerMTA > 4.5.0
Instale um certificado SSL válido e abra a porta de saída 587 para que o PowerMTA possa se comunicar com o Bird.
Configure um caminho de domínio de saída para que você possa encaminhar uma mensagem do PowerMTA para o Bird. Com a configuração abaixo, qualquer mensagem que atingir essa configuração será roteada para smtp.sparkpostmail.com usando a porta 587 e SMTP_Auth com o nome de usuário e senha definidos lá. No PowerMTA, é também onde você pode definir o TLS. Nota: isso também está documentado mais completamente aqui
<domain sparkpost.rollup> use-unencrypted-plain-auth yes auth-username SMTP_Injection auth-password YourAPIKeygoesherewhenyougenerateit route smtp.sparkpostmail.com:587 use-starttls yes require-starttls yes max-smtp-out 10 </domain>
4. Configure os VMTAs que você deseja retransmitir através do Bird com a configuração do rollup {sparkpost} que você definiu acima.
<virtual-mta SparkPostRelay> <domain *> queue-to {sparkpost} </domain> </virtual-mta>
Uma vez que você tenha feito essas mudanças de configuração, qualquer mensagem enviada para o “binding” ou “VMTA” selecionado deve ser roteada automaticamente através do Bird para entrega.
No entanto, se você estiver na equipe da Opção #2, então você vai querer adicionar algumas mudanças de configuração ao seu deployment. A maneira menos dolorosa de migrar alguns fluxos de mensagens selecionados do Momentum ou PMTA para o Bird enquanto ainda usa injeção SMTP dos seus sistemas de geração é adicionar uma rota especial na sua configuração.
Para Momentum:
Configure uma versão do Momentum > 3.6.23.
Instale um certificado SSL válido e abra a porta de saída 587 para que o Momentum possa se comunicar com o Bird. Configure um domínio de saída para que você possa encaminhar uma mensagem do Momentum para o Bird.
Com a configuração abaixo, qualquer mensagem que atingir essa configuração será roteada para smtp.sparkpostmail.com usando a porta 587 e SMTP_Auth com o nome de usuário e senha definidos lá.
outbound_smtp_auth { } Keep_Message_Dicts_In_Memory = true Domain "smtp.sparkpostmail.com" { Remote_SMTP_Port = "587" Outbound_SMTP_AUTH_Type = "LOGIN" Outbound_SMTP_AUTH_user = "SMTP_Injection" Outbound_SMTP_AUTH_pass = "17258redacted8bd6cd7a8redacted8c22bce" }
Configure os bindings que você deseja retransmitir através do MessageBird com TLS e encaminhe-os para o domínio que você definiu acima.
Nota: O TLS não é estritamente necessário, mas é uma forte recomendação. Se o TLS não for possível por algum motivo, então a lista de permissões de IP das chaves da API também é uma forte recomendação.binding "CustomerA-Outbound" { Gateway = "smtp-demo.sparkpostelite.com" TLS = "required" TLS_Certificate = "/etc/pki/tls/certs/trymsys.net.crt" TLS_Key = "/etc/pki/tls/certs/trymsys.net.key" TLS_Ciphers = "DEFAULT" }
Para PowerMTA:
Configure uma versão do PowerMTA > 4.5.0
Instale um certificado SSL válido e abra a porta de saída 587 para que o PowerMTA possa se comunicar com o Bird.
Configure um caminho de domínio de saída para que você possa encaminhar uma mensagem do PowerMTA para o Bird. Com a configuração abaixo, qualquer mensagem que atingir essa configuração será roteada para smtp.sparkpostmail.com usando a porta 587 e SMTP_Auth com o nome de usuário e senha definidos lá. No PowerMTA, é também onde você pode definir o TLS. Nota: isso também está documentado mais completamente aqui
<domain sparkpost.rollup> use-unencrypted-plain-auth yes auth-username SMTP_Injection auth-password YourAPIKeygoesherewhenyougenerateit route smtp.sparkpostmail.com:587 use-starttls yes require-starttls yes max-smtp-out 10 </domain>
4. Configure os VMTAs que você deseja retransmitir através do Bird com a configuração do rollup {sparkpost} que você definiu acima.
<virtual-mta SparkPostRelay> <domain *> queue-to {sparkpost} </domain> </virtual-mta>
Uma vez que você tenha feito essas mudanças de configuração, qualquer mensagem enviada para o “binding” ou “VMTA” selecionado deve ser roteada automaticamente através do Bird para entrega.
Fazendo acontecer
Quando você começa a seguir por este caminho, não cometa o erro de pensar que isso é uma operação de um dia para o outro. Fazer isso da maneira certa levará algum tempo e atenção.
Configure sua conta Bird e teste completamente usando uma subconta de desenvolvimento para que você possa filtrar esse tráfego mais tarde. Você precisará fazer isso para qualquer uma das opções, pois precisará da chave da API para a senha do SMTP_Auth de qualquer forma.
Se você estiver usando injeção SMTP, planeje adicionar um cabeçalho X-MSYS-API para incorporar todos os metadados e atributos de mensagem necessários. Todos os X-Headers devem ser reescritos como metadados e você deve incluir os atributos ip_pool e campanha também. Um exemplo está disponível aqui.
Se você NÃO estiver usando BYOIP, então você deve garantir que configure domínios de envio ligeiramente diferentes para uso com o MessageBird, para que você possa executar ambos os ambientes em paralelo pelo tempo que for necessário. Se seu domínio de envio atual é mycompany.com, talvez configure sp.mycompany.com especificamente para entrega do Bird. Isso permite que você migre devagar e com cuidado, sem comprometer nenhum dos domínios.
Certifique-se de ter total alinhamento de domínio e recursos de segurança habilitados. No DNS, configure DKIM, SPF, DMARC, domínios de bounce e rastreamento para que todos pareçam pertencer à mesma organização.
Configure Aquecimento Automático de IP em seus IP_Pools definidos. Se você estiver usando a opção mencionada anteriormente BYOIP, poderá ignorar a etapa de aquecimento.
Comece com um fluxo de mensagem e avance a partir daí. Assim como o Aquecimento de IP, você não deseja fazer isso tudo de uma vez. Redirecione algumas centenas de mensagens primeiro, depois 10% do volume, depois 20% no dia seguinte e aumente até que você tenha transferido todo o volume. Se você for um ESP, selecione um cliente com quem possa trabalhar e teste o processo com o feedback deles. Se tudo funcionar bem, passe para o próximo. Se você encontrar problemas, reserve um tempo para consertá-los e integrá-los no processo para o próximo.
Automatize o máximo possível com APIs. Fora das alterações de DNS, a configuração do SparkPost pode ser principalmente automatizada com algumas chamadas de API.
Quando você começa a seguir por este caminho, não cometa o erro de pensar que isso é uma operação de um dia para o outro. Fazer isso da maneira certa levará algum tempo e atenção.
Configure sua conta Bird e teste completamente usando uma subconta de desenvolvimento para que você possa filtrar esse tráfego mais tarde. Você precisará fazer isso para qualquer uma das opções, pois precisará da chave da API para a senha do SMTP_Auth de qualquer forma.
Se você estiver usando injeção SMTP, planeje adicionar um cabeçalho X-MSYS-API para incorporar todos os metadados e atributos de mensagem necessários. Todos os X-Headers devem ser reescritos como metadados e você deve incluir os atributos ip_pool e campanha também. Um exemplo está disponível aqui.
Se você NÃO estiver usando BYOIP, então você deve garantir que configure domínios de envio ligeiramente diferentes para uso com o MessageBird, para que você possa executar ambos os ambientes em paralelo pelo tempo que for necessário. Se seu domínio de envio atual é mycompany.com, talvez configure sp.mycompany.com especificamente para entrega do Bird. Isso permite que você migre devagar e com cuidado, sem comprometer nenhum dos domínios.
Certifique-se de ter total alinhamento de domínio e recursos de segurança habilitados. No DNS, configure DKIM, SPF, DMARC, domínios de bounce e rastreamento para que todos pareçam pertencer à mesma organização.
Configure Aquecimento Automático de IP em seus IP_Pools definidos. Se você estiver usando a opção mencionada anteriormente BYOIP, poderá ignorar a etapa de aquecimento.
Comece com um fluxo de mensagem e avance a partir daí. Assim como o Aquecimento de IP, você não deseja fazer isso tudo de uma vez. Redirecione algumas centenas de mensagens primeiro, depois 10% do volume, depois 20% no dia seguinte e aumente até que você tenha transferido todo o volume. Se você for um ESP, selecione um cliente com quem possa trabalhar e teste o processo com o feedback deles. Se tudo funcionar bem, passe para o próximo. Se você encontrar problemas, reserve um tempo para consertá-los e integrá-los no processo para o próximo.
Automatize o máximo possível com APIs. Fora das alterações de DNS, a configuração do SparkPost pode ser principalmente automatizada com algumas chamadas de API.
Quando você começa a seguir por este caminho, não cometa o erro de pensar que isso é uma operação de um dia para o outro. Fazer isso da maneira certa levará algum tempo e atenção.
Configure sua conta Bird e teste completamente usando uma subconta de desenvolvimento para que você possa filtrar esse tráfego mais tarde. Você precisará fazer isso para qualquer uma das opções, pois precisará da chave da API para a senha do SMTP_Auth de qualquer forma.
Se você estiver usando injeção SMTP, planeje adicionar um cabeçalho X-MSYS-API para incorporar todos os metadados e atributos de mensagem necessários. Todos os X-Headers devem ser reescritos como metadados e você deve incluir os atributos ip_pool e campanha também. Um exemplo está disponível aqui.
Se você NÃO estiver usando BYOIP, então você deve garantir que configure domínios de envio ligeiramente diferentes para uso com o MessageBird, para que você possa executar ambos os ambientes em paralelo pelo tempo que for necessário. Se seu domínio de envio atual é mycompany.com, talvez configure sp.mycompany.com especificamente para entrega do Bird. Isso permite que você migre devagar e com cuidado, sem comprometer nenhum dos domínios.
Certifique-se de ter total alinhamento de domínio e recursos de segurança habilitados. No DNS, configure DKIM, SPF, DMARC, domínios de bounce e rastreamento para que todos pareçam pertencer à mesma organização.
Configure Aquecimento Automático de IP em seus IP_Pools definidos. Se você estiver usando a opção mencionada anteriormente BYOIP, poderá ignorar a etapa de aquecimento.
Comece com um fluxo de mensagem e avance a partir daí. Assim como o Aquecimento de IP, você não deseja fazer isso tudo de uma vez. Redirecione algumas centenas de mensagens primeiro, depois 10% do volume, depois 20% no dia seguinte e aumente até que você tenha transferido todo o volume. Se você for um ESP, selecione um cliente com quem possa trabalhar e teste o processo com o feedback deles. Se tudo funcionar bem, passe para o próximo. Se você encontrar problemas, reserve um tempo para consertá-los e integrá-los no processo para o próximo.
Automatize o máximo possível com APIs. Fora das alterações de DNS, a configuração do SparkPost pode ser principalmente automatizada com algumas chamadas de API.
Coleta de Dados de Aves
O MessageBird relata a entrega de mensagens em um feed de webhooks ou na API de eventos de mensagens. Acessar logs de texto simples do Bird simplesmente não é possível. Você pode extrair esses dados de volta para o seu ambiente com um coletor de webhooks ou chamando a API de Eventos periodicamente e consumindo os dados. Recomendamos o uso de webhooks e temos algumas recomendações sobre como fazer isso da maneira certa. Em sua forma mais básica, um coletor de webhooks em PHP pode ser implantado em algumas linhas de código:
<?php $verb = $_SERVER['REQUEST_METHOD']; if ($verb === "POST") { $jsonStr = file_get_contents("php://input"); http_response_code(200); $rnum = rand(1000, 9999); $timestamp = date("YmdHis") . $rnum; $filePath = './data/data_' . $timestamp . '.txt'; // Handle duplicate filenames (edge case) if (file_exists($filePath)) { $baseName = basename($filePath, ".txt"); $seq = 0; $ftail = substr($baseName, -2, 1); if ($ftail === "-") { $seq = (int)
Enquanto você está experimentando, pode testá-los com coletores gratuitos como http://webhook.site/.
Uma vez que você tenha coletado todos os dados do webhook, pode ler isso em um armazenamento de dados para processamento adicional. Também há maneiras de enviar Webhooks através de serviços como StitchData e Segment.
As mesmas informações estão disponíveis na API de Eventos se você precisar PUXAR os dados e não puder aceitar dados PUSH. Aqui está um exemplo de chamada da API de Eventos:
GET https://api.sparkpost.com/api/v1/events/message?/
recipients=recipient@example.com&templates=my-template&events
Essa API está totalmente documentada com exemplos aqui: https://developers.sparkpost.com/api/events/#events-get-search-for-message-events
Se você realmente precisar dos dados do evento de volta em uma forma que pareça com registros PMTA ou Momentum, isso também é possível se você empregar algum código de condicionamento adicional. A boa notícia é que já há alguns exemplos para aproveitar.
O MessageBird relata a entrega de mensagens em um feed de webhooks ou na API de eventos de mensagens. Acessar logs de texto simples do Bird simplesmente não é possível. Você pode extrair esses dados de volta para o seu ambiente com um coletor de webhooks ou chamando a API de Eventos periodicamente e consumindo os dados. Recomendamos o uso de webhooks e temos algumas recomendações sobre como fazer isso da maneira certa. Em sua forma mais básica, um coletor de webhooks em PHP pode ser implantado em algumas linhas de código:
<?php $verb = $_SERVER['REQUEST_METHOD']; if ($verb === "POST") { $jsonStr = file_get_contents("php://input"); http_response_code(200); $rnum = rand(1000, 9999); $timestamp = date("YmdHis") . $rnum; $filePath = './data/data_' . $timestamp . '.txt'; // Handle duplicate filenames (edge case) if (file_exists($filePath)) { $baseName = basename($filePath, ".txt"); $seq = 0; $ftail = substr($baseName, -2, 1); if ($ftail === "-") { $seq = (int)
Enquanto você está experimentando, pode testá-los com coletores gratuitos como http://webhook.site/.
Uma vez que você tenha coletado todos os dados do webhook, pode ler isso em um armazenamento de dados para processamento adicional. Também há maneiras de enviar Webhooks através de serviços como StitchData e Segment.
As mesmas informações estão disponíveis na API de Eventos se você precisar PUXAR os dados e não puder aceitar dados PUSH. Aqui está um exemplo de chamada da API de Eventos:
GET https://api.sparkpost.com/api/v1/events/message?/
recipients=recipient@example.com&templates=my-template&events
Essa API está totalmente documentada com exemplos aqui: https://developers.sparkpost.com/api/events/#events-get-search-for-message-events
Se você realmente precisar dos dados do evento de volta em uma forma que pareça com registros PMTA ou Momentum, isso também é possível se você empregar algum código de condicionamento adicional. A boa notícia é que já há alguns exemplos para aproveitar.
O MessageBird relata a entrega de mensagens em um feed de webhooks ou na API de eventos de mensagens. Acessar logs de texto simples do Bird simplesmente não é possível. Você pode extrair esses dados de volta para o seu ambiente com um coletor de webhooks ou chamando a API de Eventos periodicamente e consumindo os dados. Recomendamos o uso de webhooks e temos algumas recomendações sobre como fazer isso da maneira certa. Em sua forma mais básica, um coletor de webhooks em PHP pode ser implantado em algumas linhas de código:
<?php $verb = $_SERVER['REQUEST_METHOD']; if ($verb === "POST") { $jsonStr = file_get_contents("php://input"); http_response_code(200); $rnum = rand(1000, 9999); $timestamp = date("YmdHis") . $rnum; $filePath = './data/data_' . $timestamp . '.txt'; // Handle duplicate filenames (edge case) if (file_exists($filePath)) { $baseName = basename($filePath, ".txt"); $seq = 0; $ftail = substr($baseName, -2, 1); if ($ftail === "-") { $seq = (int)
Enquanto você está experimentando, pode testá-los com coletores gratuitos como http://webhook.site/.
Uma vez que você tenha coletado todos os dados do webhook, pode ler isso em um armazenamento de dados para processamento adicional. Também há maneiras de enviar Webhooks através de serviços como StitchData e Segment.
As mesmas informações estão disponíveis na API de Eventos se você precisar PUXAR os dados e não puder aceitar dados PUSH. Aqui está um exemplo de chamada da API de Eventos:
GET https://api.sparkpost.com/api/v1/events/message?/
recipients=recipient@example.com&templates=my-template&events
Essa API está totalmente documentada com exemplos aqui: https://developers.sparkpost.com/api/events/#events-get-search-for-message-events
Se você realmente precisar dos dados do evento de volta em uma forma que pareça com registros PMTA ou Momentum, isso também é possível se você empregar algum código de condicionamento adicional. A boa notícia é que já há alguns exemplos para aproveitar.
Recapitulação
Certifique-se de conversar com sua equipe de Vendas e Gestão de Sucesso. Já fizemos isso antes e podemos ajudar você rapidamente e de forma econômica.
Descubra se você está no Campo #1 (capaz de mudar totalmente do On-Prem) ou no Campo #2 (ainda precisa de algum MTA on-prem).
Inscreva-se para uma conta de teste gratuita para avaliar os detalhes da integração.
Se você estiver usando injeção SMTP, descubra como obter dados de cabeçalho e atributos de mensagem em um cabeçalho X-MSYS-API.
Confirme se pode usar nosso processo BYOIP.
Atualize seu DNS com novos domínios, se necessário.
Construa um pequeno exemplo para testar sua migração. Você pode precisar ajustar sua configuração.
Aumente o volume até que todo o tráfego seja migrado.
Se você se encaixa no Campo #1, pode finalmente desligar seus MTAs on-prem após todo o tráfego ser migrado.
Ao planejar mudanças de DNS para sistemas de e-mail de alto volume, esteja ciente dos potenciais desafios de escalabilidade do DNS da AWS que podem afetar o desempenho de entrega de e-mails em grande escala.
Certifique-se de conversar com sua equipe de Vendas e Gestão de Sucesso. Já fizemos isso antes e podemos ajudar você rapidamente e de forma econômica.
Descubra se você está no Campo #1 (capaz de mudar totalmente do On-Prem) ou no Campo #2 (ainda precisa de algum MTA on-prem).
Inscreva-se para uma conta de teste gratuita para avaliar os detalhes da integração.
Se você estiver usando injeção SMTP, descubra como obter dados de cabeçalho e atributos de mensagem em um cabeçalho X-MSYS-API.
Confirme se pode usar nosso processo BYOIP.
Atualize seu DNS com novos domínios, se necessário.
Construa um pequeno exemplo para testar sua migração. Você pode precisar ajustar sua configuração.
Aumente o volume até que todo o tráfego seja migrado.
Se você se encaixa no Campo #1, pode finalmente desligar seus MTAs on-prem após todo o tráfego ser migrado.
Ao planejar mudanças de DNS para sistemas de e-mail de alto volume, esteja ciente dos potenciais desafios de escalabilidade do DNS da AWS que podem afetar o desempenho de entrega de e-mails em grande escala.
Certifique-se de conversar com sua equipe de Vendas e Gestão de Sucesso. Já fizemos isso antes e podemos ajudar você rapidamente e de forma econômica.
Descubra se você está no Campo #1 (capaz de mudar totalmente do On-Prem) ou no Campo #2 (ainda precisa de algum MTA on-prem).
Inscreva-se para uma conta de teste gratuita para avaliar os detalhes da integração.
Se você estiver usando injeção SMTP, descubra como obter dados de cabeçalho e atributos de mensagem em um cabeçalho X-MSYS-API.
Confirme se pode usar nosso processo BYOIP.
Atualize seu DNS com novos domínios, se necessário.
Construa um pequeno exemplo para testar sua migração. Você pode precisar ajustar sua configuração.
Aumente o volume até que todo o tráfego seja migrado.
Se você se encaixa no Campo #1, pode finalmente desligar seus MTAs on-prem após todo o tráfego ser migrado.
Ao planejar mudanças de DNS para sistemas de e-mail de alto volume, esteja ciente dos potenciais desafios de escalabilidade do DNS da AWS que podem afetar o desempenho de entrega de e-mails em grande escala.
