Por que um SaaS B2B brasileiro escolhe um provedor europeu?
Servimos mais de 180 SaaS B2B europeus, e cerca de 25 SaaS B2B brasileiros entre clientes Standard, Performance e Enterprise. Os clientes brasileiros costumam chegar por uma das três rotas: (1) SaaS brasileiro com clientes europeus que precisam demonstrar processamento UE para cumprir GDPR no DPA com cliente final; (2) SaaS brasileiro pós-IPO ou em ciclo de fundraising internacional que precisa de stack jurisdição-neutra para due diligence de investidores; (3) SaaS brasileiro que migra de SendGrid ou Mailgun por problemas de entregabilidade ao escalar volume sem separação de pools. O denominador comum: precisa de uma infraestrutura técnica robusta sem dependência funcional de hyperscaler estadunidense.
Características que importam em SaaS B2B brasileiro.
Três blocos específicos do setor: integração técnica (webhooks idempotentes com HMAC-SHA256, SDKs oficiais em 6 linguagens, API REST documentada em OpenAPI 3.0, sandbox totalmente funcional para CI/CD), separação de pools (um mínimo por domínio sending para que o password reset crítico não compartilhe reputação com a newsletter semanal), métricas acionáveis (eventos webhook em tempo real para integrar com seu próprio painel de cliente, além do dashboard nosso). Adicionalmente, sub-conta por cliente final para SaaS multi-tenant: cada cliente final pode ter suas próprias IPs dedicadas, seus próprios domínios DKIM, sua própria configuração DMARC, sem que seu time tenha que rotacionar credenciais manualmente.
Volume típico e quando cada plano encaixa.
Um SaaS B2B brasileiro com 1.000-5.000 clientes ativos tipicamente envia 200.000-800.000 mensagens/mês (maioria password reset, alerts, invites, notifications, weekly digests). Encaixa em Standard 500.000 mensagens/mês a €599/mês com 2 PoPs UE em failover. Quando supera 5.000 clientes ou entra em setor com alta criticidade de mensagem (autenticação 2FA por email, alertas de segurança para SOC), vale saltar para Performance pelo SLA 99,95% e as 25 IPs distribuídas. Abaixo, em startups SaaS com 100-1.000 clientes ativos, Starter cobre o caso a €299/mês; o custo por mensagem resultante é maior que SES mas a diferença se compensa com o tempo poupado em operações de entregabilidade.
Cumprimento como diferencial competitivo no seu próprio sales cycle.
Os SaaS B2B brasileiros que vendem para empresas do setor regulado (banca, seguros, saúde, setor público) enfrentam pedidos de cliente final pedindo evidências detalhadas sobre a cadeia de suboperadores TIC. Documentar que seu email passa por infraestrutura UE pura, sem exposição ao CLOUD Act nem ao FISA 702, com DPA artigo 28 assinado, ISO 27001:2022 certificado, simplifica significativamente essa parte do sales cycle. Para SaaS que vendem a entidades NIS2 (entidades essenciais ou importantes europeias) ou DORA (banca europeia), nossas cláusulas Enterprise já estão alinhadas com o que o cliente final pede. O email vira parte da sua proposta de valor em vez de gargalo de procurement.
Em quais três cargas se divide o e-mail de um SaaS B2B?
Um remetente SaaS B2B típico tem três cargas de e-mail diferenciadas que exigem tratamento distinto. A primeira é transacional: confirmações de cadastro, redefinições de senha, OTP de duplo fator, recibos de cobrança, com tolerância de latência em segundos e o destinatário esperando ativamente. A segunda é de ciclo de vida: onboarding, dicas de ativação, avisos de renovação, win-back, disparada por comportamento e não por calendário. A terceira é de notificações de eventos de produto: menções, atribuições, mudanças de estado, digests, que podem virar bursts grandes quando um evento dispara fanout sobre a base de usuários. Cada carga tem um perfil de reputação e uma tolerância a falha próprios, e misturá-las num único pool é o erro que faz uma campanha de ciclo de vida infeliz derrubar a entrega de um OTP. A nossa arquitetura de três pools separa as três de fábrica, com estatísticas e reputação isoladas, para que o problema de uma não vire o problema das outras.
Quais padrões de integração a OS Domains testou?
A maioria dos clientes SaaS B2B integra por API REST, e é o caminho que recomendamos para tráfego transacional e de eventos por causa do controle fino sobre headers, idempotência e webhooks de estado. O SMTP relay autenticado segue disponível para frameworks e ferramentas que falam SMTP nativamente sem uma camada de API no meio. Testamos os SDKs nas linguagens mais comuns do mercado, Python, Node e Ruby, e os caminhos de integração com as ferramentas que um SaaS já costuma ter: RD Station e HubSpot para ciclo de vida, e os gateways de cobrança que disparam recibos. Um padrão recorrente é o cliente nos usar como camada transacional e de eventos enquanto mantém o marketing na ferramenta de growth existente, com chaves de API segmentadas por scope para que uma chave de envio transacional não tenha acesso às listas de marketing. O que entregamos é uma API documentada e credenciais SMTP que a stack consome sem reescrever a aplicação, não um conector proprietário que prende o cliente.
Por que a Microsoft é a parte que mais quebra no inbox B2B?
Cerca de 61% dos destinatários B2B leem o e-mail em um cliente Microsoft, entre o Microsoft 365 corporativo e o Outlook, o que torna a entrega à Microsoft a parte que decide se um programa B2B funciona ou não. E a Microsoft é exigente de um jeito distinto do Gmail: filtra por tenant, aplica o SmartScreen e o Defender for Office 365 com políticas que variam de empresa para empresa, e desde maio de 2025 rejeita em definitivo o correio não conforme com um 550 5.7.515 em vez de descartá-lo em silêncio. Isso significa que uma mensagem corretamente autenticada com SPF, DKIM e DMARC alinhado ainda pode ficar em quarentena por uma política de Defender mal calibrada do lado do tenant. As vias de remediação que funcionam são duas: que o tenant adicione as nossas IPs a uma lista de remetentes permitidos, ou rotear o tráfego daquele tenant por uma IP dedicada com reputação específica estabelecida. Mantemos contas semente em Microsoft 365 para medir a colocação real por tenant e um manual de liberação de quarentena, porque sem isso a degradação na Microsoft só aparece quando o cliente final liga reclamando.
Onde a OS Domains se posiciona ante Postmark, Resend, SendGrid e SES?
Perdemos negócios para quatro provedores, e dizemos quando um deles é a melhor resposta em vez de fingir que somos a escolha certa para todo mundo. Para transacional puro de baixo a médio volume com integração rápida, o Postmark e o Resend são excelentes e provavelmente mais simples que nós. Para quem já vive dentro da AWS e quer o preço por mensagem mais baixo aceitando operar o aquecimento e o suporte por conta própria, o Amazon SES é o padrão. O SendGrid cobre o meio-termo com uma plataforma madura. Onde passamos a fazer sentido é quando se somam várias coisas ao mesmo tempo: ciclo de vida e eventos além do transacional, o inbox corporativo dominado pela Microsoft, residência de dados na UE para um cliente final regulado, e a necessidade de falar com um engenheiro às quatro da manhã quando uma IP cai numa lista. Abaixo de uns 2 milhões de mensagens por mês de transacional puro, costumamos recomendar o Resend ou o Postmark com honestidade. Acima disso, e com o inbox corporativo e a conformidade UE no jogo, somos a opção dedicada gerenciada.
O envio multi-tenant coloca o problema do vizinho barulhento sobre a sua reputação.
Se o seu produto envia em nome dos seus próprios clientes, as consequências de reputação do comportamento deles caem sobre os seus domínios e IPs. Um cliente final que envia conteúdo que gera queixas pode degradar a entrega de todos os outros tenants que compartilham o mesmo pool, e o filtro do receptor não distingue de quem é a culpa: vê o seu domínio de envio. A arquitetura que resolve isso é o domínio próprio por tenant, com return-path e DKIM separados, mais a etiquetagem X-OSD-Tenant-ID em cada mensagem e estatísticas agrupadas por tenant_id, de modo que se possa identificar e isolar o tenant que gera o problema antes que ele contamine o resto. Para os planos que retransmitem em nome de muitos clientes finais, oferecemos IPs dedicadas por tenant de alto volume e pools compartilhados segmentados por tier de reputação para o resto. O ponto é que a reputação multi-tenant se gerencia a nível de tenant, com visibilidade por tenant, e não como um único número agregado que esconde qual cliente final está afundando a entrega de todos.
Por que os limites por tenant da Microsoft são uma restrição de design?
O Exchange Online aplica limites que mordem assim que seus clientes retransmitem o próprio correio através da sua plataforma, e tratá-los como uma nota de rodapé é o que faz um envio multi-tenant travar sem aviso. Os limites concretos que importam: cerca de 5.000 destinatários externos por dia por tenant, 10.000 destinatários internos e externos somados, e em torno de 30 mensagens por minuto de taxa de envio. Para um SaaS que envia em nome de clientes hospedados em Microsoft 365, isso significa que o caudal precisa ser acompassado por baixo desses limites, com filas que respeitam a janela diária de cada tenant em vez de despejar tudo de uma vez e colher rejeições. A nossa plataforma modela esses limites como parte do design de envio: o rate limiting por tenant é configurável, a fila distribui o volume ao longo do dia, e o sistema avisa quando um tenant se aproxima do teto diário antes de bater nele. Quem ignora esses limites descobre o problema quando metade dos e-mails de um cliente final volta com erro num dia de pico, e aí já é tarde para reacomodar a fila.