O que uma equipe de produto deve avaliar ao escolher um serviço SMTP gratuito?

Defina gratuito a partir do contrato vigente

A palavra gratuito pode descrever uma franquia contínua, um teste por tempo limitado, créditos promocionais, testes apenas com destinatários verificados ou um plano pago com créditos temporários. Leia os preços e os termos atuais do provedor no dia da avaliação. Registre moeda, região, impostos, exigência de cartão de pagamento, expiração do teste, unidades incluídas, comportamento de excedente, comportamento de suspensão e quais recursos desaparecem no downgrade. Não dependa de trechos de resultados de busca, posts de comparação antigos, capturas de tela ou de um chat de vendas sem uma referência contratual durável. AWS SES, Resend e Mailgun publicam em suas páginas oficiais modelos de preços e recursos incluídos diferentes; nenhum deve ser considerado intercambiável. Vincule à decisão a URL da página revisada e a data da captura, e agende uma nova verificação antes do lançamento, porque as ofertas dos provedores podem mudar. Um custo de aquisição zero não elimina os custos de engenharia, DNS, monitoramento, privacidade, incidentes ou migração.

Modele a carga de trabalho em unidades cobráveis e operacionais

Estime mensagens, destinatários, anexos, bytes, requisições de API ou SMTP, entregas de eventos, e-mails de entrada, conteúdo armazenado, retenção de logs, domínios, membros da equipe e ambientes. Uma mensagem com vários destinatários pode consumir a cota de forma diferente de uma transação com um único destinatário. Novas tentativas, tráfego de teste, aquecimento, bounces e reenvios de webhooks podem somar volume. Calcule a demanda média, do minuto de pico, da hora de pico, diária, mensal e sazonal, além de folga para crescimento e incidentes. Mantenha os controles de taxa da aplicação abaixo dos tetos do provedor e proteja os tenants uns dos outros. Pergunte o que acontece quando as unidades restantes chegam a zero: rejeição imediata, adiamento, cobrança automática, recursos degradados ou perda silenciosa de logs. Um plano gratuito que cobre chamadas de envio, mas exclui um histórico de eventos utilizável, suporte ou exportação da lista de supressão, pode sair mais caro na operação do que um plano pago pequeno. Valide os contadores observados na conta com tráfego controlado antes da produção.

Exija submissão SMTP segura

Um serviço SMTP de produção deve documentar a submissão protegida, as portas suportadas, o comportamento do TLS, os mecanismos de autenticação, as expectativas de certificado, o escopo das credenciais e a rotação. Prefira TLS obrigatório e falhe de forma segura quando faltar STARTTLS, houver falha de certificado, divergência de hostname ou protocolo não suportado. Armazene as credenciais em um sistema gerenciado de segredos, nunca em código do navegador, apps móveis, código-fonte, imagens, logs, URLs, ferramentas de analytics, tickets ou prompts. Separe a autoridade de produção, de teste, de tenant e administrativa. Confirme se o plano gratuito restringe credenciais, IPs de origem, domínios, regiões ou conexões simultâneas. A RFC 8314 recomenda que protocolos em texto claro sejam descontinuados em favor do TLS para submissão e acesso, enquanto a RFC 4954 define a autenticação SMTP como uma extensão do protocolo, e não como autorização do produto. A aplicação ainda precisa autorizar o evento de negócio, o remetente, o tenant, o destinatário, o template e a classe da mensagem antes de abrir a conexão SMTP.

Verifique a identidade do remetente e a propriedade do DNS

Exija um domínio From pertencente à organização e um processo documentado de verificação de domínio. Faça um inventário do SMTP MAIL FROM ou return path, do From visível, do domínio d= e do seletor DKIM, dos IPs de envio e do tratamento de respostas. Publique uma única política SPF válida que inclua o caminho real, configure a assinatura DKIM com chaves protegidas e avalie o alinhamento DMARC com o domínio do From visível. A verificação do provedor é evidência de que uma checagem de configuração passou; ela não comprova o consentimento do destinatário, o roteamento correto em produção, a reputação nem a chegada à caixa de entrada. Entenda quais registros DNS pertencem ao provedor e quais permanecem na zona autoritativa da organização. Guarde os valores anteriores e os passos de rollback. Evite um domínio From do próprio provedor como identidade de produção, porque isso enfraquece a portabilidade e pode deixar o alinhamento DMARC ou a continuidade da marca dependentes do fornecedor. Teste as mensagens brutas recebidas em cada fluxo e ambiente.

Exija resultados úteis por destinatário

O serviço precisa diferenciar a aceitação por SMTP ou API, a recusa por destinatário, o adiamento temporário, a falha permanente, o bounce posterior, a reclamação, o descadastro e a supressão pelo provedor. Verifique como esses resultados são entregues, autenticados, reenviados, ordenados, retidos e exportados no plano gratuito. Autentique os webhooks antes do parsing, aplique controles de atualidade e de replay, capture os eventos de forma durável antes de confirmar o recebimento e correlacione-os às tentativas registradas pela aplicação. Armazene separadamente os escopos de destinatários aceitos e recusados. Tente novamente as falhas temporárias elegíveis com backoff limitado, jitter, teto de tentativas e limites de idade na fila. Interrompa os envios automáticos após falha permanente de endereço, reclamação ou descadastro no escopo aplicável. Um painel sem evidências exportáveis cria dependência operacional. Um evento delivered do provedor costuma descrever a aceitação pelo servidor de destino, não a pasta final na caixa postal. Aberturas e cliques são instrumentação de engajamento e podem ser distorcidos por tecnologias de privacidade.

Inspecione limites que aparecem fora da página de preços

As páginas de preços raramente contêm todo o contrato operacional. Revise a documentação atual sobre quantidade de destinatários, tamanho de mensagem, tamanho de anexo, taxa de conexão, sessões simultâneas, taxa de API, domínios DNS, templates, tentativas de webhook, retenção de eventos, capacidade da lista de supressão e restrições de destinatários no teste. Descubra se suporte, logs de auditoria, IPs dedicados, processamento regional, rotas de entrada ou recursos de compliance exigem planos pagos. Teste a conta real, porque contas novas ou em teste podem ter limites menores ou revisão manual. Registre cada limite com a URL de origem e a data da observação. Não projete exatamente no máximo; deixe folga para mudanças do provedor, novas tentativas e recuperação de incidentes. Se uma aplicação puder ultrapassar um limite silenciosamente por meio de arrays de destinatários ou anexos fornecidos pelo usuário, aplique primeiro um limite mais rígido no produto. Trate limites não documentados ou pouco claros como risco, não como capacidade ilimitada.

Avalie os controles de privacidade, segurança e abuso

Mapeie o conteúdo das mensagens, os dados dos destinatários, os cabeçalhos, os payloads de eventos, os endereços IP, os logs, o acesso do suporte, os backups e os subprocessadores em cada região. Minimize os metadados personalizados e evite segredos ou dados pessoais desnecessários em tags e cabeçalhos. Confirme o comportamento de retenção e exclusão para contas gratuitas, inclusive após o cancelamento. Verifique isolamento de tenants, controle de acesso baseado em funções, MFA, histórico de auditoria, rotação de credenciais, assinatura de webhooks, autorização de supressões e notificação de incidentes. Teste injeção de cabeçalhos, seleção arbitrária de remetente, excesso de destinatários, abuso de anexos, consulta de eventos entre tenants e replay. Planos gratuitos são alvos comuns de abuso, então os provedores podem impor revisões automatizadas ou suspensão rápida; o produto precisa de uma fila durável e de um caminho seguro de pausa. Nunca contorne os controles de abuso trocando de contas, domínios, credenciais ou IPs. Preserve o estado de consentimento e de supressão fora do provedor, para que uma suspensão ou migração não descarte as proteções dos destinatários.

Calcule o custo de saída antes de enviar

Coloque os campos específicos do provedor atrás de um único adapter e mantenha o modelo de eventos da aplicação independente. Faça um inventário do host e da autenticação SMTP, dos payloads da API, dos templates, dos domínios de remetente, dos return paths, dos seletores DKIM, dos webhooks, dos nomes de eventos, dos identificadores de mensagem, das tags, das supressões, das rotas de entrada e dos logs. Exija exportações da lista de supressão e do histórico operacional em formatos que o produto consiga validar. Uma migração precisa preservar as chaves de eventos de negócio, o histórico de tentativas, o consentimento, a segurança dos destinatários e a propriedade do remetente. Teste um segundo transporte com identidades controladas, mas não o configure como desvio automático para falhas permanentes de destinatário ou de política. Estime as janelas de mudança de DNS, a rotação de credenciais, a conversão de templates, o processamento duplo de webhooks, a prevenção de duplicatas e a retenção de eventos antigos. O plano gratuito mais barato pode ser a escolha errada quando sair dele exige perder evidências, mudar a identidade do remetente ou reconstruir controles de segurança sob a pressão de um incidente.

Execute uma prova com pontuação antes da produção

Crie uma matriz de testes representativa: negociação TLS e falha de certificado, autenticação e rotação, remetentes verificados e não autorizados, conteúdo simples e multipart, Unicode, anexos, destinatários parciais, respostas transitórias e permanentes, timeout após o DATA, bounces, reclamações, descadastros, replay de webhooks, eventos fora de ordem, esgotamento da cota, expiração do plano, exportação e encerramento da conta. Use destinatários controlados e dedicados, nunca listas reais de clientes. Pontue separadamente segurança, correção, evidências, capacidade, privacidade, suporte, portabilidade e custo total. Bloqueie o lançamento se faltar verificação TLS, se houver segredos compartilhados sem rotação, exposição entre tenants, ausência de tratamento de falhas permanentes, exportação da lista de supressão indisponível, excedente silencioso ou retenção pouco clara. Refaça a prova quando um plano de preços, caminho de envio, domínio ou contrato do provedor mudar. Um plano gratuito pode ser adequado para uma carga de trabalho limitada e de baixo risco somente quando os controles e o plano de saída atendem ao mesmo padrão esperado de uma dependência paga.

Avalie os planos atuais do SendHQ

O SendHQ não tem plano gratuito. Novos workspaces recebem um teste de integração controlado de 100 entregas para o e-mail da conta ou para um endereço do simulador AWS SES. Para ver preços, franquias e recursos dos planos pagos atuais, consulte a página de preços do SendHQ.

Perguntas frequentes

Fontes

• Amazon Simple Email Service pricing — Amazon Web Services (em inglês)
• Resend pricing — Resend (em inglês)
• Mailgun pricing — Mailgun (em inglês)
• RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access — RFC Editor (em inglês)
• RFC 4954: SMTP Service Extension for Authentication — RFC Editor (em inglês)
• RFC 5321: Simple Mail Transfer Protocol — RFC Editor (em inglês)
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance — RFC Editor (em inglês)