Infraestrutura, Continuidade e Datacenters
A MailGrid opera sobre infraestrutura de padrão enterprise, projetada para alta
disponibilidade, redundância em múltiplos níveis e continuidade operacional mesmo
diante de falhas isoladas de componentes.
Este documento descreve as características dos ambientes utilizados, o modelo de
redundância adotado, as políticas de continuidade e os limites de divulgação
de informações de infraestrutura. Informações técnicas detalhadas de arquitetura
interna não são divulgadas publicamente por razões de segurança operacional.
-
1. Soberania e localização dos dados de clientes
Todos os dados de clientes da plataforma MailGrid são armazenados exclusivamente no Brasil.
Isso inclui, sem exceção:
- dados cadastrais e contratuais dos clientes
- credenciais de acesso (armazenadas com hash criptográfico)
- metadados de envio: remetente, destinatário, timestamp, status e código de resposta
- logs de entrega, bounce e histórico de retentativas
- configurações de domínio, registros DKIM e demais dados de conta
- tokens de API e registros de sessão do painel de controle
A MailGrid utiliza infraestrutura localizada nos Estados Unidos exclusivamente para funções operacionais de transporte de mensagens — especificamente para a entrega de e-mails a destinatários cujos servidores de recebimento (MX) estão localizados fora do Brasil, onde a proximidade geográfica reduz latência e melhora as taxas de entrega. Nenhum dado de cliente é armazenado, replicado ou retido nessas instalações.
Esta arquitetura garante conformidade com a Lei Geral de Proteção de Dados (LGPD — Lei 13.709/2018) no que se refere à soberania e localização do tratamento de dados pessoais, mantendo todos os registros de clientes sob jurisdição brasileira. -
2. Datacenters e instalações
A plataforma MailGrid opera em instalações de dois dos maiores e mais reconhecidos provedores de infraestrutura do mundo: AWS (Amazon Web Services) e Equinix.
AWS — Amazon Web Services
A AWS é a maior provedora de infraestrutura de nuvem do mundo, com presença em mais de 30 regiões geográficas e certificações de segurança e conformidade reconhecidas internacionalmente: ISO/IEC 27001, ISO 27017, ISO 27018, SOC 1/2/3, PCI DSS Nível 1 e C5 (BSI Alemanha), entre outras. Os data centers AWS são projetados com redundância N+1 em energia e refrigeração, múltiplos provedores de conectividade de rede independentes e sistemas de monitoramento ambiental e segurança física de nível militar. O modelo de responsabilidade compartilhada da AWS garante conformidade de segurança física e de infraestrutura auditada de forma independente.
Equinix — International Business Exchange (IBX)
A Equinix é a maior empresa global de data centers interconectados, operando mais de 240 instalações IBX em 70 mercados ao redor do mundo. Os data centers Equinix são certificados como Tier III pelo Uptime Institute, a principal organização internacional de classificação e auditoria de data centers. A certificação Tier III é o padrão adotado por grandes instituições financeiras, operadoras de telecomunicações e provedores de infraestrutura crítica, e garante:
- disponibilidade de 99,982% ao ano (máximo de 1,6 hora de downtime não planejado por ano)
- infraestrutura Concurrently Maintainable: qualquer componente pode ser inspecionado, mantido e substituído sem interrupção da operação
- múltiplos caminhos ativos de energia e refrigeração com comutação automática (ATS)
- geração própria de energia elétrica com grupos geradores de alta capacidade e autonomia estendida
- UPS (no-break) de alta eficiência com redundância por seção de corredor
- conectividade direta a múltiplos carriers de trânsito internacional e Internet Exchanges (IX)
- controle de acesso físico por múltiplos fatores com registro de auditoria por visita
- monitoramento ambiental contínuo: temperatura, umidade, partículas e detecção de fumaça
- sistemas de supressão de incêndio de precisão, específicos para ambientes com equipamentos eletrônicos
-
3. Arquitetura de redundância
A plataforma é projetada para eliminar pontos únicos de falha (SPOF — Single Point of Failure) em todos os componentes críticos da cadeia de envio. A redundância é implementada em múltiplas camadas, de forma que a falha de um componente individual não cause interrupção do serviço.
Redundância de servidores
Os componentes funcionais da plataforma — recepção SMTP, processamento de fila, entrega (MTA de saída) e painel de controle — operam em múltiplos servidores simultâneos com balanceamento de carga. A falha de um servidor individual é absorvida pelos demais sem impacto perceptível ao cliente.
Redundância de armazenamento
Os servidores utilizam discos SSD/NVMe em configuração RAID por hardware, garantindo que a falha de um disco físico não resulte em perda de dados. Dados operacionais críticos são replicados entre múltiplos nós de armazenamento dentro da infraestrutura brasileira.
Redundância de rede
A conectividade de rede opera com múltiplos uplinks independentes, fornecidos por provedores distintos. A falha ou degradação de um provedor de trânsito é tratada automaticamente pelo roteamento dinâmico, sem intervenção manual. Cada servidor de envio opera com links de 1Gbps a 10Gbps de capacidade disponível.
Redundância de energia
Herdada das instalações Equinix e AWS, a redundância de energia cobre desde a entrada do fornecimento público até os rack-level PDUs, com UPS por seção e geradores dedicados com combustível para operação estendida em caso de falha da rede elétrica.
Balanceamento de carga e distribuição geográfica
O tráfego de submissão SMTP e as requisições de API são distribuídos entre múltiplos servidores por balanceadores de carga com verificação ativa de saúde (health check). Servidores com falha ou degradação de desempenho são removidos automaticamente da rotação e reinstituídos após recuperação verificada. -
4. Disponibilidade e SLA
A MailGrid opera com objetivo de disponibilidade de 99,9% ao mês para os serviços de submissão SMTP e API REST, calculado sobre a capacidade de recepção e enfileiramento de mensagens.
O que está coberto pelo SLA:
- disponibilidade dos endpoints de submissão SMTP (portas 587, 465 e 25)
- disponibilidade dos endpoints da API REST
- disponibilidade do painel de controle
O que não está coberto pelo SLA:
- disponibilidade ou tempo de resposta dos servidores de destino (MTAs de terceiros)
- atrasos de entrega causados por filas ou políticas de throttling nos provedores destinatários
- indisponibilidade causada por uso indevido, abuso ou violação dos Termos de Uso
- janelas de manutenção previamente comunicadas
- eventos de força maior ou indisponibilidade de infraestrutura de terceiros fora do controle da MailGrid
As condições completas de SLA, incluindo critérios de medição, créditos e procedimentos de reclamação, estão definidas no contrato padrão da plataforma:
Acessar contrato -
5. Continuidade operacional
A MailGrid mantém plano de continuidade operacional documentado, revisado periodicamente, cobrindo os cenários de falha com maior potencial de impacto ao serviço.
Fila de mensagens e durabilidade
Mensagens aceitas pela plataforma (código 250 retornado ao cliente) são persistidas em fila durável antes de qualquer tentativa de entrega. Em caso de falha de um servidor de envio, as mensagens enfileiradas são automaticamente redistribuídas para outros servidores da plataforma, sem perda de dados e sem necessidade de resubmissão pelo cliente.
Retentativas automáticas
Falhas temporárias de entrega (códigos SMTP 4xx) ativam mecanismo de retentativa com intervalos progressivos (exponential backoff) por até 5 dias corridos. O cliente não precisa monitorar ou intervir nas retentativas — a plataforma gerencia o ciclo completo de tentativas até a entrega ou expiração.
Janelas de manutenção
Manutenções planejadas que impliquem impacto ao serviço são realizadas em janelas de baixo tráfego, previamente comunicadas aos clientes por e-mail e pelo painel de status da plataforma. Atualizações que não requerem interrupção são aplicadas de forma contínua (rolling update) sem impacto ao serviço.
Monitoramento 24x7
A infraestrutura é monitorada continuamente por sistemas automatizados de verificação de saúde, desempenho e disponibilidade. Eventos que indicam degradação ou falha iminente geram alertas imediatos com resposta proativa da equipe de operações, reduzindo o tempo médio de detecção e recuperação (MTTD/MTTR). -
6. Conectividade e capacidade de rede
A plataforma opera com capacidade de rede dimensionada para absorver os volumes de envio dos planos disponíveis com margem operacional adequada, sem degradação de desempenho em picos de tráfego.
Uplinks e trânsito
Cada servidor de envio dispõe de uplinks de 1Gbps a 10Gbps com múltiplos provedores de trânsito independentes. A presença nos datacenters Equinix permite acesso direto a Internet Exchanges (IX) brasileiros e internacionais, reduzindo saltos de roteamento e melhorando a latência nas conexões com os principais provedores de e-mail.
IPv4 e IPv6 (dual stack)
Todos os servidores de envio da plataforma operam em modo dual stack, suportando conexões de saída tanto em IPv4 quanto em IPv6. Servidores destinatários com suporte a IPv6 recebem as mensagens por este protocolo quando disponível, em conformidade com as boas práticas de modernização de infraestrutura de e-mail.
Latência e desempenho
A arquitetura de servidores distribuídos e o acesso direto a IXs garantem baixa latência no estabelecimento de conexões SMTP com os principais provedores de destino (Google, Microsoft, Yahoo, provedores brasileiros). O tempo de aceitação de mensagens submetidas pelo cliente (do MAIL FROM ao 250 OK) é monitorado como métrica operacional contínua. -
7. Gestão de IPs de envio
Os endereços IP utilizados para envio de mensagens são um ativo crítico da plataforma e são gerenciados ativamente pela MailGrid.
PTR e FCrDNS
Todos os IPs de envio possuem registros PTR (DNS reverso) configurados e consistentes com o domínio da plataforma, com Forward-confirmed Reverse DNS (FCrDNS) válido. Esta configuração é um requisito de entregabilidade exigido pelos principais provedores de destino e é mantida integralmente pela MailGrid.
Monitoramento de reputação e DNSBL
A MailGrid monitora continuamente a presença dos seus IPs de envio nas principais listas de bloqueio (DNSBLs) do mercado, incluindo Spamhaus, Barracuda, SURBL e outras. Em caso de listagem, o processo de remoção (delisting) é iniciado imediatamente pela equipe de operações.
Feedback Loops (FBL)
A plataforma está registrada nos programas de Feedback Loop dos principais provedores participantes. Reclamações de spam recebidas via FBL são analisadas pela equipe de operações para identificação da origem e tomada de ação quando aplicável.
IPs dedicados
Nos planos com IP dedicado, o endereço de envio é alocado exclusivamente à conta do cliente, sem compartilhamento com outros remetentes. A reputação do IP reflete exclusivamente o histórico de envios da conta. A MailGrid garante que IPs dedicados são entregues limpos, sem histórico negativo em listas de bloqueio. -
8. Backups e recuperação de dados
Os dados operacionais e de configuração da plataforma são protegidos por rotinas de backup executadas regularmente, com armazenamento redundante dentro da infraestrutura brasileira da MailGrid.
Escopo dos backups:
- configurações de contas, domínios e credenciais cadastradas
- dados operacionais de envio dentro do período de retenção de 90 dias
- configurações de infraestrutura e parâmetros de serviço
O que não está no escopo de backup:
- conteúdo (corpo e anexos) das mensagens enviadas — a MailGrid não armazena o conteúdo das mensagens após o processamento de envio
Recuperação
Em caso de falha de componente com perda de dados, os backups permitem recuperação dos dados operacionais dentro do período de retenção vigente. O RTO (Recovery Time Objective) e o RPO (Recovery Point Objective) são definidos internamente por componente e revisados periodicamente no plano de continuidade. -
9. Status da plataforma e comunicação de incidentes
A MailGrid mantém canais de comunicação para que os clientes acompanhem o estado operacional da plataforma em tempo real e sejam notificados sobre incidentes e manutenções planejadas.
Página de status
A disponibilidade dos componentes da plataforma (submissão SMTP, API, painel de controle e entrega) é publicada na página de status oficial. Incidentes em curso são atualizados com frequência até a resolução, com descrição do impacto, ações em andamento e estimativa de normalização.
Comunicação de manutenções
Manutenções planejadas com potencial impacto ao serviço são comunicadas com antecedência mínima de 48 horas por e-mail aos clientes ativos e publicadas na página de status. Manutenções de emergência podem ser realizadas sem aviso prévio quando necessário para preservar a segurança ou a integridade da plataforma.
Notificação de incidentes de segurança
Incidentes de segurança com potencial impacto sobre dados de clientes são comunicados nos prazos definidos pela LGPD e pelo contrato de serviço, com descrição do ocorrido, dados potencialmente afetados e medidas adotadas pela MailGrid. -
10. Limites de divulgação de informações de infraestrutura
A MailGrid adota política de divulgação seletiva de informações de infraestrutura, balanceando transparência com os clientes e a necessidade de preservar a segurança operacional da plataforma.
Informações disponibilizadas publicamente:
- provedores de datacenter utilizados (AWS e Equinix)
- classificação Tier III das instalações Equinix
- regiões geográficas de operação (Brasil e Estados Unidos)
- localização exclusiva dos dados de clientes no Brasil
- capacidade de uplink por servidor (faixa)
- portas e protocolos de conexão suportados
- versões de TLS suportadas
- período de retenção de logs
Informações não divulgadas:
- endereços físicos ou identificação específica das instalações utilizadas
- topologia interna de rede, diagrama de arquitetura detalhado ou segmentação de VLANs
- número exato de servidores, configurações de hardware individuais ou capacidade total de processamento
- fornecedores específicos de software de infraestrutura, versões e configurações
- detalhes de configuração de firewall, regras de filtragem ou limiares de bloqueio
- procedimentos internos de resposta a incidentes com nível de detalhe operacional
- credenciais, certificados ou chaves de qualquer componente de infraestrutura
Esta política é adotada como medida de segurança operacional (security through operational discipline): a exposição de detalhes internos de arquitetura reduz a barreira para ataques dirigidos à plataforma e não agrega valor técnico relevante para a avaliação do serviço pelos clientes. Clientes com requisitos específicos de auditoria técnica podem ser atendidos sob infraestrutura dedicada com proposta específica. -
11. Conformidade e certificações
A plataforma MailGrid opera em conformidade com as legislações e boas práticas aplicáveis à sua atividade como MTA dedicado e prestador de serviços de infraestrutura de comunicação.
LGPD — Lei Geral de Proteção de Dados (Lei 13.709/2018)
Todos os dados de clientes são armazenados exclusivamente no Brasil, em conformidade com os princípios de soberania de dados da LGPD. A MailGrid atua como operadora dos dados pessoais processados em nome dos seus clientes e adota as medidas técnicas e organizacionais exigidas pelo art. 46 da lei para proteção dos dados tratados.
Marco Civil da Internet (Lei 12.965/2014)
A MailGrid cumpre as obrigações de guarda de registros de conexão e acesso a aplicações de internet previstas no Marco Civil, dentro dos prazos e condições definidos pela legislação.
Certificações dos provedores de infraestrutura
A infraestrutura AWS e Equinix utilizada pela MailGrid é auditada e certificada de forma independente por organismos internacionais reconhecidos. As certificações relevantes dos provedores incluem:
- AWS: ISO/IEC 27001, ISO 27017, ISO 27018, SOC 1/2/3, PCI DSS Nível 1
- Equinix: ISO/IEC 27001, Uptime Institute Tier III, SOC 1/2, PCI DSS
A MailGrid não possui certificação própria ISO 27001 neste momento. Clientes que necessitem de conformidade certificada em nível de provedor de serviço devem avaliar este ponto em seu processo de due diligence. -
12. Referência contratual e suporte
As condições de SLA, disponibilidade, responsabilidades e garantias relacionadas à infraestrutura estão definidas no contrato padrão da plataforma:
Acessar contrato
Para dúvidas sobre infraestrutura, localização de dados ou conformidade:
Falar com o suporte | Política de Segurança
