SMTP vs API de e-mail: qual você deve usar?

Você precisa enviar e-mail a partir da sua aplicação. Talvez sejam resets de senha, talvez sejam confirmações de pedido, talvez seja uma mistura de tudo. Em algum momento você vai enfrentar a pergunta: eu uso SMTP ou uma API de e-mail?

A resposta curta: se você está começando do zero, usa uma API. Se você está plugando em algo que já fala SMTP, usa SMTP. Mas os detalhes importam, e tem trade-offs que valem ser entendidos antes de se comprometer.

Como o SMTP funciona

SMTP (Simple Mail Transfer Protocol) existe desde 1982. É um protocolo baseado em texto onde sua aplicação abre uma conexão TCP com um servidor de e-mail, troca uma série de comandos (EHLO, MAIL FROM, RCPT TO, DATA) e transfere a mensagem. O servidor responde com códigos de status a cada passo.

Na prática, a maioria dos desenvolvedores não escreve comandos SMTP crus. Você usa uma biblioteca como Nodemailer (Node.js), PHPMailer (PHP) ou smtplib (Python) que lida com a conexão e o protocolo por você. Você configura um host, porta e credenciais, então chama um método de envio.

Aqui está como é enviar através do relay SMTP do Sendkit com Nodemailer:

import nodemailer from 'nodemailer';

const transport = nodemailer.createTransport({
  host: 'smtp.sendkit.dev',
  port: 587,
  auth: {
    user: 'sendkit',
    pass: 'sk_live_your_api_key',
  },
});

const sendViaSMTP = async () => {
  const info = await transport.sendMail({
    from: '[email protected]',
    to: '[email protected]',
    subject: 'Your order has shipped',
    text: 'Track your package at https://example.com/track/12345',
    html: '<p>Track your package at <a href="https://example.com/track/12345">this link</a>.</p>',
  });

  console.log(info.messageId);
};

sendViaSMTP();

Isso funciona. Vai continuar funcionando. Não tem nada de errado com isso se seu sistema já está conectado dessa forma.

Como uma API de e-mail funciona

Uma API de e-mail é um endpoint HTTP. Você manda uma requisição POST com JSON (ou form data), e recebe uma resposta JSON de volta. Sem handshake de protocolo, sem troca de comandos em múltiplos passos. Uma requisição, uma resposta.

Aqui está o mesmo e-mail enviado através da API do Sendkit:

import { Sendkit } from '@sendkitdev/sdk';

const sendkit = new Sendkit('sk_live_your_api_key');

const sendViaAPI = async () => {
  const { data, error } = await sendkit.emails.send({
    from: '[email protected]',
    to: '[email protected]',
    subject: 'Your order has shipped',
    text: 'Track your package at https://example.com/track/12345',
    html: '<p>Track your package at <a href="https://example.com/track/12345">this link</a>.</p>',
  });

  if (error) {
    console.error(error.name); // e.g. 'validation_error'
    console.error(error.message); // e.g. 'The to field is required.'
    console.error(error.statusCode); // e.g. 422
    return;
  }

  console.log(data.id); // msg_7a3b...
};

sendViaAPI();

As duas abordagens conseguem mandar o e-mail. As diferenças aparecem quando você dá zoom.

Velocidade

SMTP exige uma conexão TCP, um handshake TLS e múltiplos comandos de ida e volta antes da sua mensagem ser sequer transmitida. Cada passo espera uma resposta do servidor. Com uma rede rápida isso leva uns 200-500ms, mas soma quando você está enviando em lotes.

Uma chamada de API é uma única requisição HTTPS. O handshake TLS acontece uma vez (e é reutilizado com conexões keep-alive). O tempo total de ida e volta é tipicamente 50-150ms.

Se você está mandando um e-mail num submit de formulário, não vai notar a diferença. Se você está mandando 500 e-mails num loop, vai. E com a API, você pode usar endpoints em lote pra mandar múltiplas mensagens numa única requisição, o que não é possível com SMTP.

Funcionalidades

SMTP é um protocolo de transporte. Ele move bytes do ponto A pro ponto B. É pra isso que foi projetado, e faz isso bem.

Uma API pode fazer mais porque não está restrita por uma especificação de protocolo de 40 anos:

• Tagging e metadados. Anexe tags customizadas a mensagens pra poder filtrar analytics depois. Com SMTP, você teria que enfiar metadados em headers customizados (tipo X-Tag) e torcer pro seu provedor parsear.
• Envio em lote. Mande pra múltiplos destinatários com personalização por destinatário numa única chamada de API.
• Renderização de template. Passe IDs de template e variáveis em vez de construir HTML você mesmo. A API renderiza o template no servidor.
• Envio agendado. Enfileira uma mensagem pra entrega num horário específico.
• Dados de resposta inline. A resposta da API imediatamente te dá um ID de mensagem, resultados de validação e status. Com SMTP, você tem um código de status e precisa esperar eventos de webhook pra todo o resto.

O Sendkit suporta tracking de abertura, tracking de cliques e tratamento de bounce tanto via SMTP quanto via API. Mas a API te dá mais controle sobre como esses dados fluem.

Complexidade

SMTP tem barreira de entrada mais baixa se seu framework já tem um mailer embutido. Rails tem ActionMailer. Django tem django.core.mail. Laravel tem Mail. Troca as credenciais SMTP e pronto.

Integração de API leva um pouco mais de trabalho no começo. Você instala um SDK ou escreve chamadas HTTP, configura autenticação e lida com respostas. Mas o código que você acaba tendo é mais limpo, porque você está chamando uma função com um objeto em vez de configurar uma camada de transporte.

Pra projetos novos, eu escolheria a API toda vez. A configuração inicial é uns 10 minutos a mais, e tudo depois disso é mais fácil.

Debug

Debugar problemas de SMTP é doloroso. Timeouts de conexão, falhas de negociação TLS, erros de autenticação que aparecem como códigos de status crípticos ("535 5.7.8 Authentication failed"). Se a conexão cai no meio da transferência, você pode não saber se a mensagem foi aceita ou não.

Erros de SMTP tendem a ser vagos. "550 Requested action not taken: mailbox unavailable" pode significar que o endereço não existe, que a caixa tá cheia, ou que o servidor simplesmente não gosta de você.

Erros de API são estruturados. Você tem códigos de status HTTP com corpos JSON de erro que te dizem exatamente o que deu errado:

{
  "name": "validation_error",
  "message": "The 'to' field contains an invalid email address"
}

Você pode logar esses, alertar sobre eles, e construir lógica de retry em torno de tipos específicos de erro. Tenta fazer isso com códigos de resposta SMTP.

Tracking e analytics

Tanto SMTP quanto API suportam tracking de abertura, tracking de cliques, recibos de entrega e notificações de bounce quando você está usando um provedor como o Sendkit. O tracking acontece no nível do provedor independente de como você submeteu a mensagem.

A diferença está no que você recebe de volta no momento do envio. Com a API, a resposta inclui um ID de mensagem e status inicial de validação. Você pode imediatamente armazenar isso e correlacionar com eventos de webhook depois. Com SMTP, você tem um ID de mensagem da resposta 250 do servidor, mas é basicamente isso.

Se você precisa de analytics detalhado por mensagem, a API torna mais fácil conectar os pontos. Dá uma olhada nos docs do Sendkit pra lista completa de eventos de webhook que você pode escutar.

Segurança

As duas abordagens usam encriptação TLS em trânsito. O SMTP do Sendkit suporta porta 465 (TLS implícito) e porta 587 (STARTTLS). A API usa HTTPS exclusivamente.

Autenticação difere. SMTP usa sua chave de API como senha (com "sendkit" como usuário). A API usa a mesma chave como Bearer token ou via construtor do SDK. Mesma chave, transporte diferente.

Uma vantagem da API: você pode restringir chaves de API a endpoints e permissões específicos. Uma credencial SMTP é tudo ou nada. Se consegue autenticar, consegue enviar. Chaves de API podem ser escopadas pra que uma chave usada pelo seu serviço de billing só consiga enviar e-mail, enquanto uma chave usada pelo seu dashboard de analytics só consiga ler dados.

Quando usar qual

Use a API de e-mail quando:

• Você está construindo uma nova aplicação ou serviço do zero
• Você precisa de envio em lote, templates ou entrega agendada
• Você quer respostas de erro estruturadas e debug mais fácil
• Você está construindo algo que precisa escalar (APIs lidam melhor com concorrência)
• Você quer permissões de chave de API com granularidade fina

Use SMTP quando:

• Seu framework ou CMS já tem SMTP embutido (WordPress, apps Rails legados, etc.)
• Você está substituindo um provedor SMTP existente e não quer reescrever o código de envio
• Você está trabalhando com um sistema que não pode modificar (algumas ferramentas corporativas só suportam SMTP)
• Você precisa de uma troca rápida com zero mudanças de código além de atualizar credenciais

Não tem escolha errada aqui. O Sendkit te dá os dois, e você pode misturar na mesma conta. Use a API pra sua aplicação principal e SMTP pra um formulário de contato WordPress no seu site de marketing. Os dois usam a mesma chave de API, a mesma verificação de domínio e a mesma infraestrutura de tracking.

Migrando de SMTP pra API

Se você está no SMTP e quer migrar pra API, não tem muito mistério. Sua configuração de domínio, registros DNS e configuração de webhook continuam os mesmos. Só instala o SDK e começa a enviar:

npm install @sendkitdev/sdk

Então substitui suas chamadas do Nodemailer:

// Before (SMTP)
const transport = nodemailer.createTransport({
  host: 'smtp.sendkit.dev',
  port: 587,
  auth: { user: 'sendkit', pass: 'sk_live_your_api_key' },
});

const sendEmail = async (to, subject, html) => {
  await transport.sendMail({ from: '[email protected]', to, subject, html });
};

// After (API)
import { Sendkit } from '@sendkitdev/sdk';
const sendkit = new Sendkit('sk_live_your_api_key');

const sendEmail = async (to, subject, html) => {
  const { data, error } = await sendkit.emails.send({
    from: '[email protected]',
    to,
    subject,
    html,
  });
  if (error) {
    console.error(error.name, error.message);
    return;
  }
  console.log(data.id);
};

A assinatura da função continua a mesma. A principal coisa que você ganha é respostas estruturadas de erro em vez de códigos de status SMTP. Você pode migrar um tipo de e-mail por vez se quiser ser cuidadoso.

Pra um walkthrough mais completo de enviar com o SDK, vê como enviar e-mail transacional com Node.js.

O resumo

SMTP é um protocolo sólido e comprovado. Funciona em todo lugar. Se seu sistema já usa, não tem razão urgente pra arrancar fora.

Mas se você está escrevendo código de envio novo hoje, vai com a API. Você tem respostas mais rápidas, erros estruturados e funcionalidades que o SMTP simplesmente não consegue oferecer por causa de como o protocolo funciona. SMTP foi construído pra servidores falando com servidores em 1982. Seu app merece algo que foi construído pra apps.

O Sendkit suporta os dois, então você não fica preso. Use o que encaixa no seu setup agora e troca depois se precisar.