Resend: e-mail transacional que chega

E-mail parece resolvido — até precisar que ele chegue na caixa de entrada, não no spam. O Resend é a ferramenta de e-mail transacional do stack.

O que é

API de e-mail pensada pra dev: integração simples, boa entregabilidade, DX limpa e templates em React (react-email). É o componente de e-mail do pacote @repo/messaging.

Onde usamos

• Notificações, alertas, confirmações, resumos — o e-mail que o sistema dispara em resposta a algo.
• Sempre via @repo/messaging, não chamando o Resend direto pelo código (abstração: trocar de provedor um dia não espalha mudança).

Conceitos-chave

• Transacional ≠ marketing — separe domínios/subdomínios. Misturar reputação derruba o transacional.
• Verificação de domínio — SPF, DKIM e DMARC nos registros DNS são o que faz o e-mail ser confiável.
• Webhooks de eventos — entregue, aberto, bounce, reclamação. Use pra reagir (ex.: parar de mandar pra quem deu hard bounce).

Boas práticas

• Configure SPF/DKIM/DMARC antes de qualquer coisa — é 90% da entregabilidade.
• Idempotência em job — não mande o mesmo e-mail duas vezes no retry.
• Conteúdo sóbrio — assunto honesto, poucos links, pouca imagem. Espalhafato = spam.
• Trate bounce/complaint — limpar a lista protege a reputação.
• From consistente (RESEND_FROM_EMAIL/RESEND_FROM_NAME).

Pegadinhas

• ⚠️ "E-mail não chega" quase nunca é código — é DNS/reputação. Cheque SPF/DKIM/DMARC antes de mexer na integração.
• ⚠️ Degradação graciosa — Resend fora do ar não pode derrubar a ação principal do usuário; e-mail é efeito colateral, não o coração da transação.
• ⚠️ Limites de envio — respeite a cota do plano.

Quando usar (e quando não)

Use pra e-mail transacional confiável. Lembre que e-mail é um canal entre vários (WhatsApp, in-app) — qual evento vai por qual canal é decisão de produto (temos uma matriz de notificações como fonte da verdade).

E-mail que não chega é pior que e-mail não enviado — gera expectativa e quebra confiança. Entregabilidade primeiro.

Próximo da série: #10 — Sentry.