Documentação Técnica

• Home
• /
• Documentação Técnica

Este documento descreve a arquitetura técnica e operacional da plataforma MailGrid, abrangendo o protocolo SMTP, mecanismos de autenticação, infraestrutura física, modelo de operação como MTA e as responsabilidades entre a plataforma e o cliente.

A MailGrid atua exclusivamente como MTA (Mail Transfer Agent) dedicado para envios transacionais, provendo infraestrutura de transporte de mensagens com foco em disponibilidade, segurança e entregabilidade técnica.

• 1. Modelo de operação — MTA dedicado

  A MailGrid opera como MTA (Mail Transfer Agent) dedicado, responsável exclusivamente pelo transporte de mensagens entre a aplicação do cliente e os MTAs dos provedores destinatários. Neste modelo, a plataforma recebe as mensagens via conexão SMTP autenticada ou API REST, processa a fila de envio e executa as tentativas de entrega diretamente aos servidores de destino, consultando os registros MX dos domínios destinatários via DNS.
  
  A MailGrid não atua como ESP (Email Service Provider) e não oferece recursos de gestão de campanhas, listas de contatos ou ferramentas de comunicação em massa. O escopo do serviço é restrito ao transporte e à entrega de mensagens transacionais geradas pela aplicação do cliente.
  
  Responsabilidades da MailGrid como MTA:
  
  - recepção autenticada das mensagens submetidas pelo cliente
  - enfileiramento e processamento da fila de envio
  - resolução DNS dos registros MX dos domínios destinatários
  - estabelecimento de conexões SMTP com os MTAs de destino
  - retentativas automáticas em caso de falha temporária (soft bounce)
  - geração de DSN (Delivery Status Notification) para mensagens não entregues
  - monitoramento e gestão da reputação dos IPs de envio da plataforma
  - manutenção dos registros PTR (rDNS) e FCrDNS dos IPs de envio
  

• 2. Protocolo SMTP — visão técnica

  O SMTP (Simple Mail Transfer Protocol), definido pela RFC 5321, é o protocolo padrão para transporte de mensagens de e-mail entre agentes de transferência (MTAs). A extensão ESMTP (Extended SMTP, RFC 1869) adiciona suporte a autenticação, criptografia e outras capacidades negociadas via o comando EHLO.
  
  Sequência de uma sessão SMTP autenticada com STARTTLS:
  
  1. O cliente estabelece conexão TCP com o servidor SMTP na porta configurada
  2. O servidor responde com banner de identificação (código 220)
  3. O cliente envia EHLO <domínio>; o servidor lista as extensões suportadas
  4. O cliente emite STARTTLS; o servidor responde 220 e o canal é promovido a TLS
  5. O cliente reenvia EHLO sobre o canal TLS estabelecido
  6. Autenticação via AUTH LOGIN ou AUTH PLAIN
  7. MAIL FROM:<remetente@dominio.com> — define o envelope sender
  8. RCPT TO:<destinatario@dominio.com> — um comando por destinatário
  9. DATA — transmissão dos headers RFC 5322 e corpo da mensagem
  10. Linha contendo apenas . encerra o DATA; servidor responde 250 e enfileira a mensagem
  11. QUIT encerra a sessão
  
  Códigos de resposta SMTP relevantes:
  
  - 220 — servidor pronto para receber conexão
  - 250 — comando aceito / mensagem enfileirada com sucesso
  - 354 — servidor aguardando conteúdo da mensagem (após DATA)
  - 421 — serviço temporariamente indisponível (retentativa programada)
  - 450 / 451 — falha temporária no processamento, retentativa programada
  - 550 — endereço ou domínio inexistente; hard bounce
  - 552 / 554 — mensagem recusada por política do servidor destinatário
  

• 3. Portas de conexão e criptografia

  A plataforma MailGrid suporta conexões nas três portas SMTP padrão. A escolha da porta determina o mecanismo de criptografia negociado na sessão.
  
  Porta 587 — Submission com STARTTLS (recomendada)
  Designada pelo RFC 6409 para submissão autenticada de mensagens por agentes clientes (MUAs e aplicações). A conexão é iniciada em texto claro e imediatamente promovida a TLS após o comando STARTTLS. Autenticação obrigatória. Esta é a porta recomendada para integração de aplicações com a plataforma MailGrid.
  
  Porta 465 — SMTPS com TLS implícito
  O canal TLS é estabelecido antes de qualquer troca de dados SMTP. Reassignada como porta de submissão SMTP com segurança implícita pelo RFC 8314 (2018). Aceita pela plataforma MailGrid para compatibilidade com clientes e bibliotecas que implementam este modelo.
  
  Porta 25 — SMTP padrão
  Porta histórica do protocolo, utilizada primariamente para comunicação MTA-to-MTA. A MailGrid disponibiliza a porta 25 para conexões autenticadas. Seu uso por aplicações clientes não é recomendado pois a maioria dos provedores de acesso à internet bloqueia conexões de saída na porta 25 em redes residenciais e corporativas (Resolução Anatel nº 614/2013). Em ambientes de datacenter ou servidores com saída na porta 25 liberada, a conexão opera normalmente.
  
  Versões TLS suportadas: TLS 1.2 e TLS 1.3 em todas as conexões.
  Nas portas 587 e 465, conexões sem criptografia ativa não são aceitas. Na porta 25, o STARTTLS é oferecido e fortemente recomendado.

• 4. Autenticação SMTP, segurança de acesso e painel de controle

  O acesso à plataforma exige autenticação em todas as conexões de submissão. Cada conta dispõe de credenciais SMTP individuais isoladas por conta e por conjunto de domínios remetentes autorizados.
  
  Autenticação SMTP
  As credenciais de acesso SMTP são transmitidas exclusivamente sobre canal TLS ativo, com criptografia de ponta a ponta estabelecida antes de qualquer troca de dados de autenticação. Os mecanismos suportados são AUTH LOGIN e AUTH PLAIN, ambos operando sob a camada de segurança TLS 1.2/1.3, que garante confidencialidade, integridade e autenticidade da sessão por meio de cifras simétricas modernas (AES-256-GCM, ChaCha20-Poly1305) negociadas durante o handshake.
  
  Tentativas de autenticação em sessões sem criptografia ativa são recusadas pela plataforma. As credenciais nunca trafegam em texto claro em nenhuma etapa da comunicação.
  
  Autenticação de dois fatores (2FA) no painel de controle
  O acesso ao painel de controle MailGrid conta com autenticação de dois fatores (2FA) como camada adicional de segurança. Além das credenciais de acesso, o usuário precisa confirmar a identidade por meio de um segundo fator de autenticação gerado por aplicativo TOTP (Time-based One-Time Password, RFC 6238), válido por janela de tempo restrita e não reutilizável.
  
  Este modelo assegura que mesmo em caso de comprometimento das credenciais de acesso, o painel permanece protegido contra acessos não autorizados. Toda a comunicação com o painel é realizada sobre HTTPS com certificado TLS válido, garantindo canal criptografado de ponta a ponta entre o navegador do usuário e os servidores da plataforma.
  
  Proteção contra força bruta (brute force protection)
  A plataforma aplica mecanismos ativos de detecção e bloqueio de ataques de força bruta nos três vetores de acesso:
  
  - Conexões SMTP: tentativas de autenticação com falha repetida a partir do mesmo IP ativam bloqueio automático progressivo, com escalada de tempo de bloqueio conforme o número de tentativas acumuladas
  - API REST: requisições com token inválido ou ausente são contabilizadas por IP de origem; após exceder o limiar configurado, o IP é bloqueado temporariamente e o evento registrado nos logs de segurança
  - Painel de controle: tentativas de login com falha ativam lockout temporário da conta e do IP de origem, com notificação ao titular. O 2FA adiciona uma segunda barreira independente das credenciais, tornando ataques de força bruta contra a senha ineficazes para obter acesso completo
  
  Isolamento e controle de acesso:
  
  - cada credencial SMTP está vinculada a domínios remetentes explicitamente autorizados no cadastro
  - tentativas de envio por domínio não cadastrado resultam em rejeição com código 550
  - tokens de API são gerados individualmente por conta, com escopo restrito e revogação independente
  - o número de credenciais simultâneas e conexões paralelas é definido pelo plano contratado
  

• 5. Autenticação de domínio: SPF, DKIM e DMARC

  A autenticação do domínio remetente é obrigatória na plataforma MailGrid. Os três mecanismos devem estar corretamente publicados no DNS do domínio antes do início dos envios. Sua configuração e manutenção são responsabilidade do cliente.
  
  SPF — Sender Policy Framework (RFC 7208)
  Registro DNS do tipo TXT publicado na zona raiz do domínio, que declara os hosts autorizados a enviar mensagens em nome do domínio. O servidor destinatário consulta o SPF durante a sessão SMTP, validando o IP do servidor de envio (envelope sender) contra os mecanismos declarados no registro.
  
  Qualificadores do mecanismo final:
  -all (fail) — rejeitar mensagens de IPs não listados
  ~all (softfail) — aceitar mas sinalizar como suspeito
  ?all (neutral) — sem política definida
  
  Exemplo de registro SPF para uso com a plataforma MailGrid:
  v=spf1 include:spf.mailgrid.net.br ~all
  
  DKIM — DomainKeys Identified Mail (RFC 6376)
  Mecanismo de assinatura criptográfica que vincula cada mensagem ao domínio remetente. A plataforma assina todas as mensagens com a chave privada RSA configurada para o domínio. O servidor destinatário recupera a chave pública publicada no DNS (subdomínio _domainkey) e verifica a assinatura presente no header DKIM-Signature. A assinatura cobre os principais headers RFC 5322 (From, Subject, Date, To) e o corpo da mensagem, garantindo integridade contra alterações em trânsito.
  
  Exemplo de registro DKIM (CNAME delegado para a plataforma):
  mailgrid._domainkey.seudominio.com.br CNAME mailgrid._domainkey.mailgrid.net.br
  
  DMARC — Domain-based Message Authentication, Reporting and Conformance (RFC 7489)
  Política publicada no DNS do domínio (registro TXT em _dmarc.seudominio.com.br) que instrui os provedores destinatários sobre como tratar mensagens que falham na validação de SPF e/ou DKIM. O DMARC introduz o conceito de alinhamento (alignment): o domínio autenticado pelo SPF ou pelo DKIM deve corresponder ao domínio declarado no header From da mensagem.
  
  Políticas disponíveis (p=):
  none — monitoramento sem ação de filtragem
  quarantine — mensagens em falha encaminhadas para spam/quarentena
  reject — mensagens em falha rejeitadas pelo provedor destinatário
  
  Exemplo de registro DMARC:
  v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@seudominio.com.br
  
  O parâmetro rua define o endereço para recebimento de relatórios agregados (formato XML), enviados diariamente pelos principais provedores, permitindo ao cliente auditar o uso do seu domínio como remetente.

• 6. PTR e DNS reverso (rDNS)

  O registro PTR (Pointer Record) realiza a resolução inversa de um endereço IP para um hostname, sendo mantido na zona in-addr.arpa (IPv4) ou ip6.arpa (IPv6) pelo provedor responsável pelo bloco de IPs.
  
  Durante o recebimento de uma mensagem, servidores de destino frequentemente executam uma consulta PTR sobre o IP de origem da conexão SMTP e verificam se o hostname retornado é resolúvel de volta ao mesmo IP — prática conhecida como Forward-confirmed Reverse DNS (FCrDNS). IPs sem PTR configurado ou com PTR inconsistente são comuns em infraestruturas comprometidas e redes residenciais, sendo tratados com desconfiança por filtros anti-spam e políticas de recepção de grandes provedores.
  
  A MailGrid mantém registros PTR configurados e FCrDNS válido em todos os IPs utilizados para envio. Esta configuração é gerenciada integralmente pela plataforma e não requer ação por parte do cliente.

• 7. Reputação e gestão de IPs de envio

  A reputação de um IP de envio é o conjunto de sinais históricos avaliados pelos provedores destinatários e por sistemas anti-spam para determinar o grau de confiança nas mensagens originadas daquele endereço. Os principais fatores avaliados incluem histórico de bounces, taxa de reclamações (spam complaints), presença em DNSBLs (DNS-based Blackhole Lists) e consistência do comportamento de envio ao longo do tempo.
  
  Responsabilidades da MailGrid sobre os IPs de envio:
  
  - monitoramento contínuo dos IPs de envio em listas de bloqueio (DNSBLs)
  - execução de processos de remoção (delisting) junto às entidades de lista
  - monitoramento de Feedback Loops (FBLs) junto a provedores participantes
  - análise de métricas de bounce e complaint por conta para detecção de anomalias
  - manutenção dos registros PTR e FCrDNS dos IPs da plataforma
  - isolamento de IPs entre clientes nos planos com IP dedicado
  
  Responsabilidades do cliente:
  
  - reputação do domínio remetente perante os provedores destinatários
  - qualidade e higienização da base de destinatários
  - taxas de bounce e reclamação geradas pelos seus envios
  - configuração e manutenção dos registros SPF, DKIM e DMARC do domínio
  - conformidade do conteúdo das mensagens com políticas dos provedores destinatários
  
  A MailGrid não gerencia a reputação do domínio remetente do cliente, não executa processos de aquecimento de domínio (domain warming) e não intervém na relação de reputação entre o domínio do cliente e os provedores destinatários. Bloqueios por domínio devem ser tratados diretamente pelo cliente junto ao provedor destinatário.

• 8. Infraestrutura e datacenters

  A plataforma MailGrid opera em infraestrutura distribuída em instalações enterprise-grade: AWS (Amazon Web Services) e Equinix, com presença no Brasil e nos Estados Unidos.
  
  AWS — Amazon Web Services
  Infraestrutura de nuvem com certificações ISO/IEC 27001, SOC 1/2/3, PCI DSS e C5 (BSI). Os data centers AWS operam com redundância N+1 em energia (UPS independentes por PDU e grupos geradores), múltiplos provedores de conectividade de rede e sistemas automatizados de detecção e supressão de incêndio. O modelo de responsabilidade compartilhada da AWS garante conformidade de segurança física e lógica na camada de infraestrutura.
  
  Equinix — International Business Exchange (IBX)
  Os data centers Equinix são certificados como Tier III pelo Uptime Institute, padrão que garante disponibilidade de 99,982% ao ano (máximo de 1,6 hora de downtime não planejado). A certificação Tier III implica infraestrutura Concurrently Maintainable: todos os componentes críticos podem ser inspecionados, mantidos e substituídos sem interrupção da operação.
  
  Características das instalações Equinix utilizadas:
  
  - redundância N+1 em energia (UPS, PDUs e geradores independentes por corredor)
  - múltiplos caminhos de energia ativos com comutação automática (ATS)
  - acesso direto a múltiplos carriers de trânsito e Internet Exchanges (IX)
  - controle de acesso físico multifator, câmeras e log de auditoria por visita
  - monitoramento ambiental contínuo (temperatura, umidade, partículas e fumaça)
  - refrigeração com redundância N+1 e contenção de corredor quente/frio
  
  Hardware e conectividade de rede:
  
  - armazenamento em SSD/NVMe com RAID por hardware
  - uplinks de 250Mbps a 1Gbps por servidor de envio
  - balanceamento de carga e distribuição de filas entre múltiplos servidores
  - suporte a IPv4 e IPv6 (dual stack) em todos os servidores de envio
  

• 9. Segurança da plataforma

  A infraestrutura MailGrid é protegida por múltiplas camadas de segurança, cobrindo desde o perímetro de rede até o isolamento lógico entre contas.
  
  Segurança de rede e perímetro:
  
  - firewall de dupla camada com inspeção stateful de pacotes (L3/L4)
  - proteção anti-DDoS em camada de rede e de aplicação (L7)
  - rate limiting por IP de origem para mitigação de ataques de força bruta
  - bloqueio automático de IPs com comportamento anômalo de autenticação
  
  Isolamento e controle de acesso:
  
  - isolamento lógico entre contas de clientes em todos os componentes da plataforma
  - cada credencial SMTP vinculada a domínios remetentes explicitamente autorizados
  - acesso administrativo à infraestrutura restrito a canais criptografados com autenticação por chave
  
  Monitoramento e disponibilidade:
  
  - monitoramento 24x7 de serviços, filas de envio e conectividade de rede
  - alertas automáticos para anomalias operacionais com atuação proativa
  - atualizações de segurança aplicadas em janelas controladas sem impacto ao serviço
  

• 10. Fila de envio, retentativas e DSN

  Após a aceitação de uma mensagem (código 250), a plataforma enfileira o envio e inicia as tentativas de entrega ao MTA de destino. O comportamento da fila segue os padrões definidos pelas RFCs 5321 e 3463.
  
  Retentativas (retry schedule):
  Falhas temporárias (códigos 4xx) ativam mecanismo de retentativa com intervalos crescentes (exponential backoff). As tentativas são realizadas por até 24 horas corridos a partir da primeira falha. Após esse período, a mensagem é descartada e um DSN de falha permanente é gerado.
  
  DSN — Delivery Status Notification (RFC 3464):
  Notificações de entrega são geradas para falhas permanentes (hard bounce, códigos 5xx) e para falhas temporárias que expiram o período de retentativa. O DSN é enviado ao endereço definido no envelope sender (MAIL FROM) da mensagem original e inclui o código de resposta SMTP retornado pelo servidor de destino.
  
  Limites operacionais por plano:
  
  - volume de mensagens por hora
  - número de conexões SMTP simultâneas por credencial
  - número de credenciais SMTP por conta
  - tamanho máximo por mensagem: até 50MB (incluindo anexos codificados em Base64)
  - número de destinatários por mensagem (RCPT TO): conforme plano contratado
  

• 11. Logs, relatórios e retenção de dados

  O painel de controle MailGrid disponibiliza ao cliente acesso a logs e relatórios de entrega com os seguintes dados por mensagem:
  
  - status (enfileirada, entregue, bounce, rejeitada)
  - timestamp de submissão, tentativas e entrega final
  - código de resposta SMTP retornado pelo servidor destinatário
  - hostname do servidor de destino que aceitou ou recusou a mensagem
  - histórico de retentativas com timestamps e código de cada tentativa
  - classificação de bounces (hard / soft) com mensagem de erro original
  
  Retenção de logs de envio: 90 dias corridos a partir da data de submissão.
  
  Logs internos de infraestrutura, dados de configuração de servidores e informações de roteamento interno da plataforma não são disponibilizados ao cliente.

• 12. Integração via API REST

  Além do protocolo SMTP, a MailGrid disponibiliza uma API REST para submissão de mensagens, voltada a aplicações que necessitam de integração programática simplificada ou que operam em ambientes com restrição de conexões SMTP de saída.
  
  Autenticação: token Bearer por conta, transmitido no header Authorization: Bearer <token> de cada requisição.
  
  Endpoint de envio: POST https://api.mailgrid.net.br/v1/send
  
  Payload suportado:
  
  - remetente (from), destinatários (to, cc, bcc)
  - assunto, corpo em HTML e/ou texto simples
  - cabeçalhos customizados (headers adicionais RFC 5322)
  - anexos codificados em Base64 com especificação de MIME type
  - envelope sender customizado para gestão de bounces (return_path)
  
  A documentação completa da API, incluindo referência de endpoints, exemplos de payload e códigos de resposta, está disponível em:
  
  Acessar documentação da API

• 13. Conformidade, uso aceitável e LGPD

  Uso aceitável
  A plataforma MailGrid destina-se exclusivamente ao envio de mensagens transacionais legítimas geradas por sistemas e aplicações do cliente: confirmações de cadastro, autenticação de dois fatores (2FA), notificações de pedido, alertas de sistema, faturas e comunicações operacionais.
  
  É vedado o uso da plataforma para envio de spam, phishing, mensagens com conteúdo fraudulento ou qualquer prática que viole os Termos de Uso. Contas identificadas com uso indevido são suspensas imediatamente, sem aviso prévio, nos termos contratuais.
  
  LGPD — Lei Geral de Proteção de Dados (Lei 13.709/2018)
  No modelo operacional da MailGrid, o cliente atua como controlador dos dados pessoais dos destinatários, sendo responsável pela base legal do tratamento e pelo consentimento quando aplicável. A MailGrid atua como operadora, processando os dados de envio estritamente para execução do serviço contratado.
  
  Cabeçalho List-Unsubscribe
  Para envios recorrentes a destinatários identificados, recomenda-se a inclusão dos headers List-Unsubscribe (RFC 2369) e List-Unsubscribe-Post (RFC 8058). Desde fevereiro de 2024, Gmail e Yahoo exigem este header para remetentes de alto volume como condição de entregabilidade.
  
  Para detalhes completos sobre uso aceitável e obrigações contratuais, consulte:
  
  Política de Privacidade   |   Termos de Uso   |   Política Anti-Spam

• 14. Glossário técnico

  SMTP — Simple Mail Transfer Protocol (RFC 5321). Protocolo padrão de transporte de e-mail entre MTAs.
  
  ESMTP — Extended SMTP (RFC 1869). Extensão do SMTP com suporte a autenticação, TLS e capacidades adicionais negociadas via EHLO.
  
  MTA — Mail Transfer Agent. Componente responsável pelo roteamento e transporte de mensagens entre servidores SMTP.
  
  MUA — Mail User Agent. Aplicação cliente que submete mensagens ao MTA (clientes de e-mail, aplicações, bibliotecas SMTP).
  
  ESP — Email Service Provider. Plataforma de gestão de envios em massa, campanhas e listas. Diferente de um MTA dedicado.
  
  EHLO / HELO — Comandos de identificação do cliente ao servidor. EHLO inicia a negociação de extensões em sessões ESMTP.
  
  STARTTLS — Extensão SMTP que promove conexão TCP em texto claro para canal TLS durante a sessão.
  
  AUTH LOGIN / AUTH PLAIN — Mecanismos de autenticação SMTP por credenciais codificadas em Base64, seguros apenas sobre TLS.
  
  Envelope sender — Endereço declarado no MAIL FROM da sessão SMTP, utilizado para roteamento e recebimento de DSNs. Pode diferir do header From.
  
  MX Record — Registro DNS tipo MX (Mail Exchanger) que indica o hostname do servidor responsável por receber mensagens para um domínio.
  
  PTR / rDNS — Registro DNS reverso que associa um IP a um hostname. Mantido na zona in-addr.arpa (IPv4) ou ip6.arpa (IPv6).
  
  FCrDNS — Forward-confirmed Reverse DNS. Consistência entre PTR e resolução direta: o hostname retornado pelo PTR resolve de volta ao mesmo IP.
  
  SPF — Sender Policy Framework (RFC 7208). Registro TXT no DNS que declara os IPs autorizados a enviar mensagens em nome do domínio.
  
  DKIM — DomainKeys Identified Mail (RFC 6376). Assinatura criptográfica RSA de mensagens vinculada ao domínio remetente via par de chaves.
  
  DMARC — Domain-based Message Authentication, Reporting and Conformance (RFC 7489). Política DNS que define o tratamento de mensagens que falham em SPF e/ou DKIM.
  
  DSN — Delivery Status Notification (RFC 3464). Notificação gerada pelo MTA sobre o status de entrega de uma mensagem ao envelope sender.
  
  Hard Bounce — Falha permanente de entrega (código 5xx). Endereço inexistente, domínio inválido ou rejeição definitiva pelo servidor destinatário.
  
  Soft Bounce — Falha temporária de entrega (código 4xx). O MTA realiza novas tentativas conforme o schedule configurado.
  
  DNSBL — DNS-based Blackhole List. Base consultada via DNS contendo IPs com histórico de envio de spam ou comportamento abusivo.
  
  FBL — Feedback Loop. Mecanismo pelo qual provedores encaminham reclamações de spam ao responsável pelo IP de envio.
  
  List-Unsubscribe — Header RFC 2369 que permite ao provedor exibir mecanismo nativo de descadastro na interface do usuário final.
  
  Tier III — Classificação Uptime Institute para data centers Concurrently Maintainable, com disponibilidade garantida de 99,982% ao ano.

• 15. Referência contratual e suporte

  As condições de prestação do serviço, SLA, responsabilidades e garantias estão definidas no contrato padrão da plataforma:
  
  Acessar contrato
  
  Para questões técnicas, configuração de domínio ou suporte operacional:
  
  Falar com o suporte