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:
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:
Para dúvidas sobre infraestrutura, localização de dados ou conformidade:
