Resend: email transacional, preços e limites na prática

Resend é uma boa opção de email para equipes pequenas de produto que querem integrar cadastros, recibos e redefinições de senha ao aplicativo sem complicar a implementação. O cuidado está na operação em produção: a franquia gratuita para em 100 emails por dia, e cabe ao aplicativo lidar com mensagens rejeitadas por limite de uso. Escolha o Resend pelo fluxo de trabalho para desenvolvedores; dimensione o plano pelos picos de demanda e escolha o provedor conforme seus requisitos de dados.

Informações conferidas nas páginas de preços, documentação e segurança do Resend em 13 de novembro de 2026. Esta análise avalia os fluxos documentados, os limites e os cálculos de cobrança; não apresenta testes com acesso à conta nem medições de chegada à caixa de entrada.

O que a plataforma de email Resend faz?

Resend é um serviço de entrega de emails que seu aplicativo aciona por API, uma interface de programação, ou por SMTP, o protocolo padrão de envio de email. Ele envia mensagens individuais disparadas por eventos e campanhas de marketing com Broadcasts, gerencia contatos e modelos, informa eventos de entrega e recebe emails para seu aplicativo processar. Continua sendo responsabilidade do produto decidir quem deve receber um recibo, se uma solicitação de redefinição é válida e o que fazer quando uma mensagem falha. A documentação de primeiros passos apresenta as formas de envio e as integrações com linguagens disponíveis.

Para quem vale a pena — e quem deve procurar outra opção?

Resend atende fundadores e desenvolvedores que querem tratar o email como mais um serviço do aplicativo: versionar o modelo, fornecer os dados do evento, enviar a mensagem e tratar o resultado. O cenário mais favorável é um SaaS pequeno em que as mesmas pessoas cuidam do aplicativo e de seus emails transacionais.

A decisão depende do esforço de integração, do tratamento de falhas, de quem cuida do marketing e das restrições sobre dados. Não depende de uma afirmação sem comprovação de que um provedor entrega mais mensagens na caixa de entrada.

Não migre se o provedor atual funciona e você não consegue apontar qual problema o Resend resolveria. Uma API mais organizada, por si só, não justifica mover um tráfego de email já estabelecido. Postmark merece entrar na comparação quando a infraestrutura de envio separada é um requisito; Amazon SES, quando a equipe quer manter a operação sob seu controle na AWS.

Se uma pessoa de marketing vai cuidar diariamente das jornadas de onboarding, compare o Loops, cujo foco são emails de ciclo de vida para SaaS. O Resend agora também tem Automations. Portanto, compare a jornada que essa pessoa realmente precisa manter, em vez de partir da ideia desatualizada de que o Resend só envia mensagens por API.

Alternativas ao Resend: quando cada uma faz mais sentido

Twilio SendGrid: prefira quando sua operação atual com Email API, SMTP e Marketing Campaigns já atende às necessidades. Continue com ele, a menos que o custo de manter essa estrutura supere um benefício específico da migração.

Postmark: prefira quando separar o tráfego transacional dos envios em massa for decisivo. A documentação de Message Streams descreve infraestruturas de IP separadas. É uma diferença concreta de arquitetura, não uma promessa de resultados melhores para o seu domínio.

Mailgun: inclua na comparação quando validação e roteamento de emails fizerem parte dos requisitos, além do envio. Para esse perfil de comprador, essas ferramentas adicionais pesam mais que uma sintaxe agradável na chamada de envio.

Amazon SES: prefira quando sua engenharia já cuida da operação na AWS e quer incorporar o email a esse ambiente. Compare todo o esforço de implementação, incluindo monitoramento e resposta a incidentes.

Loops: prefira quando a compra parte de jornadas de onboarding, ativação e reativação sob responsabilidade de quem cuida do ciclo de vida do cliente no SaaS. Demonstre a mesma jornada nos dois produtos antes de escolher.

Para uma decisão mais ampla sobre plataformas de campanhas, a análise do GetResponse trata de uma necessidade de compra diferente da escolha do serviço de envio de emails de um aplicativo.

API do Resend: do evento no produto à mensagem

O ponto forte do Resend é o caminho curto entre um evento do aplicativo e uma mensagem baseada em modelo. Seu SDK para Node.js recebe remetente, destinatário, assunto e conteúdo, e retorna um resultado com dados ou erro. Outros guias de início rápido documentados cobrem Python, PHP, Ruby, Go, Rust, Java e .NET; adotar o serviço não exige adotar React.

Pense no recibo de um pagamento aprovado. O aplicativo registra o pagamento, prepara os dados do recibo, pede ao Resend que faça o envio e salva o identificador retornado da mensagem junto ao pagamento. Assim, o suporte pode investigar o recibo sem depender de uma busca apenas pelo nome do cliente. O guia de início rápido para Node.js mostra a operação de envio usada nesse fluxo.

Modelos de email no Resend: defina quem cuida do texto

React Email permite criar o conteúdo dos emails com componentes React. O Resend aceita tanto mensagens mantidas em código quanto modelos hospedados; o guia de integração com React Email documenta a prévia local, a saída em HTML ou texto simples e o envio para Templates hospedados.

No caso de um recibo, mantenha o layout no código quando as alterações precisarem passar pela revisão do aplicativo. Se alguém de fora da engenharia precisa corrigir o texto, um modelo hospedado pode definir melhor as responsabilidades: o aplicativo fornece as variáveis, e quem cuida do conteúdo edita a mensagem. A documentação de Templates descreve o editor, o histórico de versões e o envio pelo ID de um modelo publicado.

O ganho é ter um responsável claro por cada alteração. Nenhuma das abordagens significa que um email de redefinição de senha deva ser aprovado só pela prévia. Antes do lançamento, teste o link, o comportamento de expiração e o conteúdo nos clientes de email usados pelos seus clientes.

Novas tentativas precisam de uma identidade

Resend oferece chaves de idempotência, identificadores que fazem uma solicitação de envio repetida retornar o resultado original, em vez de enviar outro email. A proteção documentada dura 24 horas. No fluxo do recibo, derive a chave do evento do recibo e mantenha o conteúdo da solicitação estável nas novas tentativas. O guia de idempotência define tanto essa janela quanto o erro retornado quando a mesma chave acompanha um payload diferente.

Essa janela é um limite que o aplicativo precisa respeitar. Uma tarefa reprocessada depois desse prazo precisa de um registro persistente próprio que indique se o recibo já foi solicitado. A deduplicação do provedor ajuda durante as novas tentativas, mas não substitui um histórico permanente dos eventos de negócio.

SMTP facilita a migração de aplicativos existentes

Resend também atende aplicativos que já usam SMTP. As configurações de SMTP especificam smtp.resend.com, usuário resend e a chave de API como senha. A porta 465 usa TLS implícito; a 587 usa STARTTLS. Use a configuração de criptografia correspondente no cliente de email ou framework.

Assim, é possível preservar o código que gera os emails e trocar apenas o transporte. A contrapartida para o diagnóstico é específica: o Resend informa que não fornece logs do servidor SMTP, embora as mensagens enviadas por SMTP apareçam na tabela Emails. Se investigar problemas de conexão é uma necessidade recorrente, leve isso em conta antes de migrar.

Configuração de domínio: autenticação faz parte do lançamento

Resend exige um domínio de envio verificado, e essa configuração deve entrar na lista de lançamento junto à integração por API. É no DNS, o sistema que publica os registros do domínio, que você autoriza o serviço a enviar em seu nome.

SPF identifica a infraestrutura autorizada a enviar. DKIM adiciona uma assinatura criptográfica às mensagens. DMARC orienta os sistemas de recebimento sobre como tratar mensagens que não atendem à política de autenticação do domínio. São funções diferentes; um selo verde de domínio verificado não substitui uma configuração deliberada de DMARC.

Para um SaaS novo, uma configuração prática é:

1. 1

   Escolha o remetente e a região de envio

   Adicione um domínio na página Domains do Resend. Para um remetente novo, use um subdomínio com finalidade definida, como account.example.com; escolha a região de envio adequada aos destinatários.

2. 2

   Publique os registros gerados

   Copie as configurações DKIM e SPF do Resend para seu provedor de DNS exatamente como aparecem. Verifique o domínio antes de conectar os envios destinados aos clientes. Evite substituir esses dados por um registro genérico copiado de um tutorial.

3. 3

   Adicione DMARC e separe as finalidades de envio

   Configure DMARC após a verificação. Considere um subdomínio separado para marketing, de modo que as configurações da newsletter e as transacionais possam ser gerenciadas de forma independente.

4. 4

   Preserve a reputação existente durante a migração

   Se você já tem um endereço de envio estabelecido, planeje a migração levando esse histórico em conta. O Resend recomenda manter um endereço estabelecido em vez de substituí-lo automaticamente por um subdomínio novo.

O guia de configuração de domínio apresenta a sequência; as orientações sobre domínios verificados explicam a exceção para migrações e as configurações separadas de rastreamento. Em uma redefinição de senha, prefira um link limpo e direto a rastrear cada clique só porque a opção existe.

Eventos de entrega e emails recebidos: complete o fluxo

Resend fornece informações ao aplicativo depois da chamada de envio. É isso que torna o serviço útil quando um cliente diz que o recibo não chegou. Webhooks são notificações HTTPS enviadas ao aplicativo quando ocorrem eventos. O guia de webhooks documenta eventos de entrega, rejeição, abertura e clique, verificação de solicitações, reprocessamento e armazenamento dos dados de eventos no seu próprio banco.

No fluxo do recibo, verifique as solicitações dos webhooks, associe cada evento ao identificador salvo da mensagem e garanta que repetir o processamento seja seguro. Uma rejeição deve gerar uma situação sobre a qual o suporte possa agir, em vez de sumir em um log que ninguém consulta. Mantenha esse histórico no seu próprio sistema se ele precisar sobreviver ao prazo de retenção do provedor.

Entregue não significa visualizado na caixa de entrada. Resend define esse status como entrega ao servidor de email do destinatário. A documentação de gerenciamento de emails distingue os estados de entrega, rejeição, atraso, falha e supressão. Use essas diferenças ao explicar uma falha ao cliente.

Ferramentas de entregabilidade ajudam no diagnóstico, mas não comprovam chegada à caixa de entrada

O Deliverability Insights do Resend procura problemas como divergência de domínio nos links, ausência de DMARC e falta de conteúdo em texto simples. São verificações úteis sobre a mensagem que você controla. Elas não comprovam um percentual de chegada à caixa de entrada.

A lista de supressão também impede envios contínuos a endereços com rejeição permanente ou reclamações. O ponto central é a supressão para toda a equipe: um endereço na lista é ignorado em todos os seus domínios e subdomínios, tanto em emails transacionais quanto em Broadcasts. A documentação de supressão também informa que Gmail/Google Workspace não retorna eventos de reclamação.

Em uma operação que combina marketing e emails transacionais, há uma consequência prática: mover um destinatário suprimido para outro subdomínio de envio não fará o email de redefinição de senha voltar a chegar. Investigue o motivo da supressão e ofereça um caminho de recuperação de conta. Não remova a supressão nem reenvie sem investigar.

O recebimento de emails também está documentado

Resend permite receber emails em um domínio verificado ou em seu subdomínio gerenciado resend.app. O guia de recebimento descreve notificações por webhook, recuperação do conteúdo e dos anexos, encaminhamento e respostas na mesma conversa.

Um fluxo útil é a resposta a um recibo de pedido: associe a mensagem recebida ao pedido, recupere o conteúdo e crie uma tarefa de suporte. A infraestrutura de recebimento dispensa a operação da entrada de emails por conta própria. Ainda cabe a você tratar anexos, avaliar a confiança no remetente e definir o que uma mensagem recebida pode alterar no produto.

Broadcasts e contatos: deixe clara a finalidade de marketing

Resend pode atender à newsletter e aos anúncios de produto de uma equipe pequena sem exigir que o desenvolvedor crie do zero um sistema de envio de campanhas. Broadcasts oferece editor, agendamento, seleção de contatos e acompanhamento de desempenho. O guia de Broadcasts descreve os fluxos pelo painel e pela API.

Para anunciar uma funcionalidade, importe ou adicione contatos que deram consentimento, coloque os destinatários em um Segment, escolha o Topic adequado, prepare a mensagem, confira o cancelamento de inscrição e agende o Broadcast. Um Segment é seu agrupamento interno; um Topic é uma preferência que o destinatário pode controlar.

Se uma integração antiga menciona Audiences, reveja suas premissas. O Resend agora usa Contacts globais e Segments: um endereço de email pode fazer parte de vários segmentos e contar como um único Contact. O guia de migração de Audiences informa que a API de Audiences está obsoleta. Isso importa quando um código antigo trata o cancelamento de inscrição como restrito a uma audiência específica.

Resend também documenta Automations com gatilhos personalizados, condições, atrasos e etapas de espera por eventos. Assim, uma sequência de boas-vindas pode ficar no Resend, em vez de inteiramente no código do aplicativo. Antes de mover um programa de ciclo de vida, mapeie seus gatilhos e condições de saída reais: conseguir desenhar uma sequência não define quem vai mantê-la.

Preços do Resend: Pro é o ponto de partida prático

O plano Pro de entrada custa $20 por mês para 50,000 emails, sem limite diário de emails e com 10 domínios. O Free oferece 3,000 por mês, com limite de 100 por dia e 3 domínios. A barreira diária pesa antes da franquia mensal: um lançamento hipotético com 60 cadastros e duas mensagens por cadastro exige 120 envios naquele dia. A página de preços também lista o Scale a partir de $90 por mês para 100,000 emails e planos Enterprise personalizados.

Preços da API do Resend: compare o seletor de volume antes dos excedentes

Com uso integral da franquia incluída, o Pro de entrada sai por $0.40 por 1,000 emails: $20 divididos por 50,000, multiplicados por 1,000. Com apenas 5,000 emails de uso efetivo, a mesma assinatura sai por $4 por 1,000. Esses cálculos refletem o uso da franquia, não o preço por entrega bem-sucedida na caixa de entrada.

A tabela de preços legível por máquina também lista o Pro a $35 para 100,000 emails. Nesse volume, manter o Pro de entrada com excedentes habilitados custaria $20 + 50 × $0.90 = $65. Escolha a franquia maior do Pro antes de presumir que excedentes ou Scale são a próxima compra mais sensata.

Marketing tem uma cobrança separada: o Free cobre 1,000 contatos; o Pro para marketing começa em $40 por mês para 5,000; o Enterprise é personalizado. O envio de Broadcasts é ilimitado dentro da franquia de contatos e não consome a cota transacional. Enviar uma newsletter por /emails, por outro lado, usa a cota transacional e deixa o cancelamento de inscrição a cargo da sua implementação.

Para esse perfil de leitor, comece com o Pro transacional pago quando os picos em produção puderem ultrapassar o Free. Adicione capacidade de marketing quando a lista de contatos exigir. Avalie o Scale pelos recursos operacionais, como a opção de IP dedicado, em vez de tratar o nome como prova de que é a forma mais barata de comprar mais envios.

Limitações que podem mudar a escolha

As principais restrições do Resend envolvem responsabilidade pela entrega, retenção, limites compartilhados e dados armazenados. Elas pesam mais que a elegância da primeira chamada de API.

Rejeições por limite de uso são responsabilidade do aplicativo

Resend contabiliza emails enviados e recebidos na cota transacional, e cada destinatário é contado separadamente. A cota diária do Free é reiniciada à meia-noite UTC. A cobrança de excedentes nos planos pagos fica desativada até um administrador habilitá-la; um envio rejeitado por cota retorna um erro, e o Resend não coloca essa mensagem em fila nem tenta enviá-la novamente. Essas regras estão explícitas na documentação de cotas e limites da conta.

Coloque as tarefas que podem ser repetidas na sua própria fila e gere alertas para falhas de cota. Em redefinições de senha, confira a validade do token antes de repetir uma tarefa antiga. Uma mensagem enviada depois que o limite é reiniciado pode já ter perdido a utilidade.

Um plano pago não aumenta automaticamente as requisições por segundo

Todas as contas começam com 10 requisições por segundo por equipe, compartilhadas entre chaves de API e domínios. Criar outra chave não cria uma capacidade separada. O envio em lote comporta até 100 emails em uma requisição, mas sua fila ainda precisa respeitar o limite de requisições. O Resend informa que mudar de plano não aumenta esse limite automaticamente; uma vazão maior exige uma conversa separada com o suporte.

Essa é a diferença entre capacidade e vazão. Capacidade é quantas mensagens cabem no mês. Vazão é quantas requisições o aplicativo consegue fazer durante um pico. Planeje o orçamento e a engenharia para as duas.

Retenção não substitui um histórico permanente de auditoria

Free, Pro e Scale retêm dados de emails e logs por 30 dias; Enterprise oferece retenção flexível. Mantenha seu próprio histórico de eventos quando uma contestação de recibo ou investigação de suporte puder chegar depois desse prazo. Preserve também o evento de negócio de forma independente da janela de idempotência de 24 horas do provedor.

A exclusão antecipada também tem restrições. As orientações públicas do Resend sobre tratamento de dados dizem que não há API para excluir um email individual; remover mensagens enviadas antes do prazo exige contato com o suporte, e mensagens recebidas não podem ser removidas antes do fim da retenção. O serviço é pouco adequado a um fluxo que exige exclusão programática imediata.

Enviar da Europa não significa armazenar dados lá

Resend oferece regiões de envio no norte da Virgínia, na Irlanda, em São Paulo e em Tóquio. A documentação de regiões diferencia o local de envio do local de armazenamento.

Os dados dos clientes, incluindo conteúdo das mensagens, logs de entrega, payloads de webhooks e registros de conta, são armazenados nos Estados Unidos. O Resend informa que não há uma configuração para mover esses dados armazenados para a UE. Sua página sobre GDPR apresenta a posição da empresa sobre conformidade, descreve a autoauditoria e explica o DPA padrão e as cláusulas de transferência. Essas declarações não transformam um domínio de envio na Irlanda em armazenamento exclusivo na UE.

Resend também declara conformidade com SOC 2 Type II; a página pública identifica o período do relatório, enquanto o relatório em si exige login. A visão geral de segurança lista proteções de criptografia e classifica HIPAA como “In progress” (em andamento). São declarações do fornecedor analisadas aqui, não uma auditoria independente de conformidade.

Se armazenamento exclusivo na UE ou um acordo HIPAA disponível no presente forem requisitos obrigatórios de contratação, não aprove o Resend com base no menu de regiões de envio ou nos selos de segurança. Esclareça o requisito exato antes da integração.

Veredito: use Resend quando a equipe puder assumir os pontos críticos

Resend é uma boa escolha quando uma equipe pequena de produto quer um fluxo coerente entre modelos, envio por API ou SMTP, eventos de entrega e campanhas ocasionais de marketing. Seu valor está em reduzir o trabalho de integração e manter o comportamento do produto sob seu controle.

A decisão muda quando o armazenamento nos EUA não atende aos requisitos, o diagnóstico no nível de SMTP é essencial ou o aplicativo não consegue tratar com segurança falhas de cota e novas tentativas. Um provedor anterior que funciona também continua sendo uma boa escolha quando a migração não tem um ganho concreto.

Na implementação da próxima semana, leve um fluxo de redefinição de senha e um de recibo por autenticação de domínio, rejeição por cota, solicitações duplicadas, tratamento de rejeições e consulta pelo suporte. Inclua uma estimativa de volume para o dia de pico. Escolha o Resend quando conseguir identificar o responsável e o comportamento esperado em cada ponto de falha, e não apenas quando o email de boas-vindas ficar bonito.

Perguntas frequentes

O nome coincide com a expressão em inglês “resend an email”, que significa reenviar um email. As respostas abaixo diferenciam o produto das ações em uma caixa de correio.

Quais serviços gratuitos de envio de email valem a pena?

Para um aplicativo, Resend é um ponto de partida razoável quando os limites diários e mensais do Free atendem à demanda. Uma franquia gratuita não basta para produção se um pico de lançamento puder esgotá-la; dimensione o serviço pelo dia de maior movimento.

Como reenviar um email no novo Outlook?

No novo Outlook, abra Itens Enviados, selecione a mensagem e use o menu de mais opções e Ações avançadas → Reenviar mensagem. Revise o rascunho antes de enviar. As instruções de reenvio da Microsoft descrevem esse recurso da caixa de correio; ele não tem relação com a API do Resend.

Em inglês, o correto é resent ou Resend?

“Resend” significa enviar novamente; “resent” é a forma no passado. Resend, com inicial maiúscula, também é a marca da plataforma de email analisada aqui.

Como cancelar um email que já enviei?

Não trate a plataforma Resend como uma ferramenta para recuperar mensagens da caixa de correio. O Outlook tem um recurso separado de recuperação, sujeito a restrições de conta e organização; a explicação da Microsoft sobre recuperação informa que não é possível recuperar mensagens enviadas a contas externas ou pessoais.

Como reenviar um email que já foi enviado?

No Outlook, use a ação da mensagem enviada descrita acima. Em um aplicativo, decida se é uma nova tentativa do evento original ou um novo envio intencional; reutilizar uma chave de idempotência do Resend dentro da janela de proteção impede uma duplicata.

Posso recuperar um email que já enviei?

Se a intenção é consultar uma mensagem do Resend, use a página Emails e os detalhes da mensagem dentro do período de retenção. Se a intenção é remover a cópia do destinatário, consultar ou excluir seu próprio registro não é a mesma operação que recuperar uma mensagem da caixa de correio.

Como vejo os emails que enviei?

Resend lista mensagens enviadas e agendadas no painel Emails, incluindo envios por SMTP. Abra uma mensagem para consultar metadados, prévia, HTML, texto simples e eventos de entrega.

Por que não consigo ver os emails que enviei?

No Resend, confira se o envio foi aceito e se os dados ainda estão dentro do prazo de retenção. No Outlook, verifique a pasta correta de Itens Enviados e as configurações de salvamento; o guia de emails enviados da Microsoft explica por que uma cópia enviada pode estar ausente.

Como recupero minhas mensagens enviadas?

Primeiro, diferencie uma cópia ausente na caixa de correio de logs expirados do provedor. Para investigações no Resend após o prazo de retenção, use o histórico de eventos que você armazenou; não crie um processo de suporte que pressuponha que o painel do provedor é um armazenamento permanente.

Use o Checklist de auditoria de fluxos de trabalho de negócios com IA para atribuir um responsável a cada gatilho de email, falha e etapa de recuperação; receba o checklist pela newsletter.