SMTP ou API de e-mail: qual o seu app deve usar?

Mais cedo ou mais tarde, todo produto precisa enviar e-mails, e a primeira pergunta é como o seu código deve conversar com o sistema de e-mail. Há duas respostas: falar SMTP diretamente ou chamar uma API de e-mail via HTTPS.

As duas funcionam. Mas elas impõem exigências muito diferentes à sua aplicação, e a escolha certa depende de onde o seu código roda e de quanta infraestrutura de e-mail você quer manter.

No que o SMTP é bom

O SMTP (Simple Mail Transfer Protocol) é a forma como os servidores de e-mail trocam mensagens desde o início dos anos 1980. Todo provedor de caixa de e-mail oferece suporte a ele, e quase todo framework tem um mailer SMTP embutido: Nodemailer, o send_mail do Django, Laravel Mail, o Action Mailer do Rails.

Pontos fortes:

• Universal. Toda conta de e-mail e toda linguagem conseguem usá-lo.
• Sem dependência de fornecedor. Para trocar de provedor, basta mudar um nome de host e uma senha.
• Seu próprio domínio e reputação. Os e-mails saem por um servidor que você controla ou aluga, a partir de endereços do seu domínio.

Onde o SMTP atrapalha dentro de um app

O SMTP é um protocolo verboso e com estado. Para enviar uma mensagem, seu app abre uma conexão TCP, cumprimenta o servidor, atualiza a conexão para TLS, autentica e então percorre uma série de comandos e respostas para o remetente, o destinatário e os dados. Cada etapa é uma ida e volta pela rede.

Na prática, isso causa:

• Requisições lentas. Um handshake com um servidor distante pode levar centenas de milissegundos antes mesmo de a mensagem começar.
• Portas bloqueadas. Muitas plataformas de nuvem e runtimes serverless restringem as portas de saída 25, 465 e 587 para combater spam. O HTTPS na porta 443 quase nunca é bloqueado.
• Credenciais por toda parte. Cada serviço que envia e-mail precisa da senha da caixa de e-mail. Trocá-la significa fazer o deploy de todos eles de novo.
• Pouca visibilidade. Quando algo falha, o erro fica nos logs de um único serviço, se é que foi registrado.

O que uma API de e-mail muda

Uma API de e-mail encapsula o envio em uma única requisição HTTPS com corpo JSON. Seu código faz um POST e recebe um código de status de volta. O serviço da API mantém a conexão SMTP e as credenciais.

Pontos fortes:

• Uma única requisição rápida pela porta 443, de qualquer lugar: containers, funções serverless, runtimes de edge, jobs de CI.
• Chaves em vez de senhas. Cada serviço recebe a própria chave de API com permissões limitadas, e você pode revogar ou rotacionar uma sem mexer nas outras.
• Visibilidade centralizada. Chamadas à API e resultados de entrega são acompanhados em um só lugar.
• Erros HTTP simples. Um 401 ou 429 é muito mais fácil de tratar do que um código de resposta SMTP enterrado em um stack trace.

A contrapartida: na maioria das APIs de e-mail, as mensagens saem pelos servidores delas, então você adota a configuração de domínio de envio e a reputação de IP delas, e migrar depois significa verificar tudo de novo em outro lugar.

Inbixio: uma API na frente do seu servidor SMTP

A Inbixio foi criada em torno de uma ideia simples: manter a parte valiosa do SMTP, ou seja, seu próprio servidor de e-mail e sua identidade de remetente, e substituir a parte que atrapalha dentro das aplicações.

1. Você conecta seu servidor SMTP uma única vez no painel: host, porta, nome de usuário e senha.
2. Seus serviços chamam POST /api/send-email/ com uma chave de API da Inbixio.
3. A Inbixio faz login no seu servidor SMTP via TLS e entrega a mensagem a partir do seu endereço.
4. Seu painel mostra a contagem de enviados, a taxa de entregas com falha e a latência de entrega, além de um log de cada chamada à API.

curl -X POST https://backend.inbixio.com/api/send-email/ \
  -H "X-API-Key: $INBIXIO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to_email":"user@example.com","subject":"Welcome!","message":"<h1>Hello</h1>"}'

O que isso oferece:

• Sua senha SMTP fica armazenada em um único lugar. Seus serviços só veem chaves de API.
• As chaves podem ser vinculadas a um servidor específico, então o serviço de cobrança envia de billing@ e o serviço de autenticação de security@.
• As permissões de cada chave são explícitas, e uma chave pode ser renovada ou excluída sem mexer no servidor de e-mail.
• Você mantém seu domínio de envio, seu provedor e sua reputação. Se trocar de provedor de e-mail, você atualiza o cadastro de um servidor, e nada no seu código muda.

Lado a lado

Então, qual usar?

• Use SMTP diretamente para um único app pequeno, em um servidor onde o SMTP de saída é permitido e você não se importa em gerenciar as credenciais ali.
• Use uma API de e-mail quando você roda vários serviços, faz deploy em plataformas que bloqueiam as portas SMTP, quer logs centralizados ou quer parar de espalhar senhas de caixas de e-mail.
• Use a Inbixio quando quiser esses benefícios de uma API, mas também quiser que os e-mails continuem passando pelo seu próprio servidor de e-mail e domínio.

Pronto para testar? O guia de início rápido de cinco minutos leva você do cadastro a um e-mail entregue.