Qual é a diferença, em uma frase?
O SMTP é o protocolo aberto que seu software usa para entregar e-mails a um servidor; uma API de e-mail é uma interface HTTPS específica de cada provedor que faz o mesmo trabalho com payloads estruturados e retorno de eventos. O protocolo de submissão não decide se você chega à caixa de entrada — a autenticação e a reputação do domínio decidem, e SPF, DKIM e DMARC se aplicam da mesma forma aos dois caminhos. Então escolha por critérios de integração: portabilidade, tratamento de erros, ferramentas. Para tudo o que acontece depois que o provedor aceita a mensagem, o guia é entregabilidade de e-mail para startups.
Como funciona o envio por SMTP?
Seu app abre uma conexão com o servidor do provedor, o relay SMTP — para submissão, normalmente a porta 587 com autenticação, conforme a RFC 6409 — e entrega a mensagem pronta. O protocolo de transferência em si é a RFC 5321, padronizada na forma atual em 2008 e em uso há muito mais tempo, e é por isso que tudo fala SMTP: qualquer framework, CMS, fórum, ferramenta de monitoramento ou script de décadas atrás pode enviar assim, só com um host, uma porta e credenciais. Essa é a vantagem discreta do SMTP — a migração é só uma troca de credenciais, então trocar de plataforma de e-mail nunca significa reescrever o código de envio. É também o encaixe natural para stacks auto-hospedadas, em que o suporte a SMTP já vem por padrão.
Como funciona o envio por uma API de e-mail?
Seu código chama o endpoint HTTPS do provedor com um payload JSON — destinatário, conteúdo ou uma referência a um modelo, tags, metadados e, muitas vezes, uma chave de idempotência para evitar envios duplicados. A resposta é síncrona: sucesso com um ID de mensagem, ou um erro que seu código pode capturar e tentar de novo. A documentação do Postmark deixa o contraste explícito — a API REST retorna sucesso ou erro na hora, enquanto o endpoint SMTP aceita todas as mensagens e registra os erros como bounces, que ainda podem ser obtidos pelos webhooks de bounce. Depois do aceite, os webhooks enviam bounces, reclamações e aberturas de volta ao seu app, e é isso que torna possível a supressão automática. Os SDKs dos provedores resolvem tudo isso em poucas linhas; em troca, a integração fica específica daquele provedor.
SMTP vs. API: frente a frente
A decisão inteira se resume a uma troca: com o SMTP você ganha portabilidade; com a API, retorno e ferramentas. Veja como isso se traduz, linha por linha.
| SMTP | API de e-mail | |
|---|---|---|
| O que é | Protocolo aberto (RFC 5321) — igual em todo lugar | Interface de produto específica do provedor, via HTTPS |
| Esforço de integração | Quase zero se o software já fala SMTP: host, porta, credenciais | Integrar seu código ao endpoint ou ao SDK do provedor |
| Portabilidade | Alta — trocar de provedor é trocar as credenciais | Baixa — cada provedor tem um formato; trocar significa reescrever a integração |
| Tratamento de falhas | Aceito na submissão; algumas falhas aparecem depois como bounces assíncronos | Erros síncronos que você captura e tenta de novo, mais eventos assíncronos |
| Retorno de eventos | Nada no protocolo — os webhooks de bounce do provedor ainda cobrem o e-mail enviado por SMTP, mas você os configura à parte | Webhooks enviam bounces, reclamações e aberturas ao seu app |
| Modelos e análises | Nada no protocolo — você envia uma mensagem pronta | Referências a modelos, tags e metadados por mensagem |
| Encaixe na auto-hospedagem | Natural — software auto-hospedado fala SMTP de fábrica | Mais uma dependência específica de fornecedor na sua stack |
Quando o SMTP é a escolha certa?
- Software que já fala SMTP — um CMS, fórum, help desk ou app legado começa a enviar pelo seu provedor só com novas credenciais.
- Máxima portabilidade — se você quer liberdade para trocar de provedor sem mexer no código, o SMTP é a interface neutra.
- Stacks auto-hospedadas — o suporte a SMTP vem embutido em praticamente tudo o que você rodaria na sua própria infraestrutura, sem SDK.
- E-mail operacional de baixo volume — alertas de cron e notificações internas raramente justificam uma integração de API sob medida.
Quando a API é a escolha certa?
Envio de produto em escala. Quando o e-mail está integrado ao seu app — onboarding, recibos, fluxos de ciclo de vida —, erros síncronos, referências a modelos e webhooks de eventos compensam o custo da integração, e uma lista de supressão pode se atualizar sozinha no momento em que um endereço dá bounce ou reclama. Uma coisa que a API não traz é reputação: ela mora no seu domínio de envio, não no caminho de submissão, então o aquecimento do domínio e a autenticação se aplicam da mesma forma, seja qual for a forma de submissão.
Por que o fromHello aceita os dois?
Como a escolha é uma decisão de integração, e não de entregabilidade, o fromHello traz adaptadores para os dois: APIs HTTP (Resend, Postmark, SendGrid), qualquer servidor SMTP e caixas de correio do Microsoft 365. Você define um padrão por espaço de trabalho e pode atribuir a um modelo um provedor próprio. No fromHello Cloud, em acesso antecipado, os planos Team e superiores já vêm com o envio de e-mail configurado; no Core ou na versão auto-hospedada, você traz o provedor. Os limites ficam no nível do provedor de qualquer forma — a Resend, por exemplo, documenta o mesmo limite de taxa para o endpoint SMTP e para a API. E a supressão e o consentimento são aplicados pela plataforma independentemente do caminho de submissão: um endereço suprimido continua suprimido, saia a mensagem por HTTPS ou pela porta 587.