Resend: correo transaccional, precios y límites para tu SaaS

Resend es una buena opción para un equipo de producto pequeño que quiere conectar los registros, recibos y restablecimientos de contraseña con su aplicación sin complicar la integración. La contrapartida aparece al operar en producción: el plan gratuito se limita a 100 correos diarios y la aplicación debe gestionar los mensajes rechazados por superar las cuotas. Elige Resend por su flujo de trabajo para desarrolladores; dimensiona el plan según los picos de demanda y elige al proveedor según tus requisitos sobre los datos.

Verificado con las páginas vigentes de precios, documentación y seguridad de Resend el 13 de noviembre de 2026. Este análisis evalúa los flujos documentados, los límites y los cálculos de facturación; no se basa en pruebas con una sesión iniciada ni en mediciones de llegada a la bandeja de entrada.

¿Para qué sirve la plataforma de correo de Resend?

Resend es un servicio de envío de correo al que tu aplicación accede mediante una API, una interfaz de programación, o SMTP, el protocolo estándar de envío de correo. Envía mensajes individuales activados por eventos y campañas de marketing con Broadcasts, gestiona contactos y plantillas, informa de los eventos de entrega y recibe correos entrantes para que tu aplicación los procese. Tu producto sigue decidiendo quién debe recibir un recibo, si una solicitud de restablecimiento es válida y qué hacer cuando falla un mensaje. La documentación de primeros pasos explica las vías de envío y las integraciones con los lenguajes compatibles.

¿Para quién es recomendable y quién debería descartarlo?

Resend encaja con fundadores y desarrolladores que quieren tratar el correo como otro servicio de su aplicación: versionar la plantilla, aportar los datos del evento, enviar el mensaje y gestionar el resultado. Su caso más claro es un SaaS pequeño en el que las mismas personas se encargan de la aplicación y de sus correos transaccionales.

La decisión depende del esfuerzo de integración, la gestión de fallos, quién se ocupa del marketing y las restricciones sobre los datos. No depende de afirmar, sin pruebas, que un proveedor consigue que más mensajes lleguen a la bandeja de entrada.

No migres si tu proveedor actual funciona y no puedes concretar qué problema resolverá Resend. Una API más ordenada no basta, por sí sola, para trasladar un tráfico de correo consolidado. Postmark merece estar entre las opciones si necesitas infraestructuras de envío separadas; Amazon SES, si tu equipo quiere mantener el control dentro de AWS.

Si una persona de marketing se ocupará a diario de las secuencias de incorporación de usuarios, compara Loops, cuyo producto se centra en el correo del ciclo de vida de un SaaS. Resend también cuenta ahora con Automations, así que conviene comparar la secuencia real que esa persona tendrá que mantener, en lugar de partir de la idea ya desactualizada de que Resend solo envía mensajes por API.

Alternativas a Resend: cuándo conviene cada una

Twilio SendGrid: elígelo si tus operaciones actuales con Email API, SMTP y Marketing Campaigns ya cubren tus necesidades. Consérvalo mientras el coste de mantener esa configuración no supere un beneficio concreto de migrar.

Postmark: elígelo si separar el tráfico transaccional del de campañas es un requisito decisivo. Su documentación de Message Streams describe infraestructuras IP separadas: es una diferencia arquitectónica concreta, no una promesa de mejores resultados para tu dominio particular.

Mailgun: inclúyelo entre tus opciones cuando necesites validación y enrutamiento de correo además del envío. Para ese perfil de comprador, esas herramientas adicionales pesan más que una sintaxis cómoda para enviar mensajes.

Amazon SES: elígelo si tus ingenieros ya se encargan de las operaciones en AWS y quieren integrar el correo en ese entorno. Compara el esfuerzo total de implementación, incluida la supervisión y la gestión de incidentes.

Loops: elígelo cuando la compra parta de las secuencias de incorporación, activación y recuperación de usuarios que gestiona quien se ocupa del ciclo de vida del SaaS. Antes de decidir, reproduce la misma secuencia en ambos productos.

Si buscas una plataforma de campañas más amplia, el análisis de GetResponse aborda una decisión de compra distinta de la elección del servicio que transportará el correo de tu aplicación.

API de Resend Email: del evento del producto al mensaje

La mayor fortaleza de Resend es lo poco que separa un evento de la aplicación de un mensaje basado en una plantilla. Su SDK de Node.js recibe remitente, destinatario, asunto y contenido, y devuelve un resultado con datos o un error. También hay guías de inicio documentadas para Python, PHP, Ruby, Go, Rust, Java y .NET; adoptar el servicio no obliga a adoptar React.

Pensemos en el recibo de un pago completado. Tu aplicación registra el pago, prepara los datos del recibo, solicita a Resend que lo envíe y guarda el identificador del mensaje junto a ese pago. Así, una persona de soporte puede investigar el recibo sin buscar únicamente por el nombre del cliente. La guía de inicio de Node.js muestra la operación de envío correspondiente.

Plantillas de Resend: decide quién se encarga del texto

React Email permite a los desarrolladores crear contenido de correo a partir de componentes de React. Resend admite tanto mensajes gestionados en código como plantillas alojadas; su guía de integración con React Email documenta la vista previa local, la generación de HTML o texto sin formato y la carga en las plantillas alojadas de Templates.

En un recibo, conviene mantener el diseño en código si los cambios deben pasar por la revisión de la aplicación. Si alguien ajeno a ingeniería necesita corregir el texto, una plantilla alojada puede repartir mejor las responsabilidades: la aplicación aporta las variables y la persona responsable del contenido edita el mensaje. La documentación de Templates describe el editor, el historial de versiones y el envío mediante el ID de una plantilla publicada.

La ventaja es que cada cambio tiene un responsable claro. Ninguna de las dos opciones justifica aprobar un correo de restablecimiento de contraseña solo por su vista previa. Antes del lanzamiento, prueba el enlace, su caducidad y el contenido en los clientes de correo que utilizan tus usuarios.

Los reintentos necesitan un identificador

Resend admite claves de idempotencia, identificadores que hacen que una solicitud de envío repetida devuelva el resultado original en vez de enviar otro correo. La protección documentada dura 24 horas. Para el flujo de recibos, deriva la clave del evento del recibo y mantén estable el contenido de la solicitud al reintentar. La guía de idempotencia define tanto ese plazo como el error que se produce al usar la misma clave con un contenido distinto.

Ese plazo marca un límite que tu aplicación debe respetar. Si una tarea vuelve a ejecutarse después, necesitas un registro duradero propio que indique si ya se solicitó el recibo. La deduplicación del proveedor protege durante los reintentos, pero no sustituye un historial permanente de eventos del negocio.

SMTP facilita trasladar aplicaciones existentes

Resend también sirve para aplicaciones que ya utilizan SMTP. Su configuración SMTP especifica smtp.resend.com, el usuario resend y la clave de API como contraseña. El puerto 465 utiliza TLS implícito; el 587, STARTTLS. Configura el cifrado correspondiente en tu cliente de correo o framework.

Así puedes conservar el código que genera los mensajes y cambiar solo el transporte. La limitación para el diagnóstico es concreta: Resend indica que no proporciona registros del servidor SMTP, aunque los mensajes enviados por SMTP aparecen en la tabla Emails. Si depurar las conexiones es una necesidad habitual, tenlo en cuenta antes de migrar.

Configuración del dominio: la autenticación forma parte del lanzamiento

Resend exige verificar el dominio de envío, y esa configuración debe figurar en la lista de lanzamiento junto a la integración con la API. En el DNS, el sistema que publica los registros de tu dominio, autorizas al servicio a enviar en tu nombre.

SPF identifica la infraestructura autorizada para enviar. DKIM añade una firma criptográfica a los mensajes. DMARC indica a los sistemas receptores cómo tratar los mensajes que incumplen la política de autenticación del dominio. Son funciones distintas: un indicador verde de dominio verificado no sustituye una configuración deliberada de DMARC.

Para un SaaS nuevo, una configuración práctica sería:

1. 1

   Elige el remitente y la región de envío

   Añade un dominio en la página Domains de Resend. Para un remitente nuevo, usa un subdominio con una función clara, como account.example.com; elige la región de envío adecuada para tus destinatarios.

2. 2

   Publica los registros generados

   Copia las configuraciones DKIM y SPF de Resend en tu proveedor de DNS exactamente como se muestran. Verifica el dominio antes de conectar los envíos dirigidos a clientes. No las sustituyas por un registro genérico copiado de un tutorial.

3. 3

   Añade DMARC y separa las finalidades de envío

   Configura DMARC después de la verificación. Valora usar un subdominio independiente para marketing, de modo que puedas gestionar por separado la configuración del boletín y la del correo transaccional.

4. 4

   Conserva la reputación adquirida al migrar

   Si ya tienes una dirección de envío consolidada, planifica la migración teniendo en cuenta ese historial. Resend recomienda conservar una dirección con trayectoria en lugar de sustituirla automáticamente por un subdominio nuevo.

La guía de configuración del dominio detalla la secuencia; las indicaciones sobre dominios verificados explican la excepción al migrar y las opciones de seguimiento independientes. Para restablecer una contraseña, prioriza un enlace limpio y directo frente a registrar cada clic solo porque exista esa opción.

Eventos de entrega y correo entrante: cierra el circuito

Resend aporta información a tu aplicación después de la llamada de envío, algo útil cuando un cliente dice que su recibo no llegó. Los webhooks son notificaciones HTTPS que se envían a tu aplicación cuando ocurre un evento. La guía de webhooks documenta eventos de entrega, rebote, apertura y clic, la verificación de solicitudes, la repetición de eventos y su almacenamiento en tu propia base de datos.

En el flujo de recibos, verifica las solicitudes de los webhooks, asocia cada evento con el identificador de mensaje guardado y asegúrate de que repetir su procesamiento no cause problemas. Un rebote debe generar un estado que permita actuar a soporte, en lugar de perderse en un registro que nadie consulta. Conserva ese historial en tu sistema si necesitas que dure más que el periodo de retención del proveedor.

Entregado no significa visto en la bandeja de entrada. Resend define ese estado como la entrega al servidor de correo del destinatario. Su documentación de gestión de correos distingue los estados entregado, rebotado, retrasado, fallido y suprimido. Usa esas diferencias al explicar un fallo a un cliente.

Las herramientas de entregabilidad ayudan a diagnosticar, pero no prueban la llegada a la bandeja de entrada

Deliverability Insights de Resend detecta problemas como dominios que no coinciden en los enlaces, ausencia de DMARC o falta de contenido en texto sin formato. Son comprobaciones útiles sobre el mensaje que controlas. No permiten establecer un porcentaje de llegada a la bandeja de entrada.

Su lista de supresión también impide seguir enviando a direcciones que generan rebotes permanentes o quejas. El alcance relevante es la supresión para todo el equipo: una dirección incluida se omite en todos tus dominios y subdominios, tanto en correo transaccional como en Broadcasts. La documentación de supresiones también advierte que Gmail/Google Workspace no devuelve eventos de queja.

Si combinas marketing y correo transaccional, hay una consecuencia práctica: trasladar a un destinatario suprimido a otro subdominio de envío no hará que vuelva a recibir su correo de restablecimiento de contraseña. Investiga el motivo de la supresión y ofrece una vía para recuperar la cuenta. No elimines la supresión y reenvíes sin más.

La recepción de correo también está documentada

Resend permite recibir correo en un dominio verificado o en su subdominio gestionado resend.app. La guía de recepción describe las notificaciones por webhook, la recuperación del contenido y los adjuntos, el reenvío y las respuestas en un mismo hilo.

Un flujo útil es la respuesta al recibo de un pedido: vincula el mensaje entrante con el pedido, recupera su contenido y crea una tarea de soporte. La infraestructura de recepción te evita operar por tu cuenta la entrada de correo. Sigues siendo responsable de los adjuntos, de la confianza que otorgas al remitente y de los cambios que un mensaje entrante puede provocar en el producto.

Broadcasts y contactos: deja clara la intención de marketing

Resend puede gestionar el boletín y los anuncios de producto de un equipo pequeño sin obligar al desarrollador a crear desde cero un sistema de envío de campañas. Broadcasts ofrece editor, programación de envíos, selección de contactos destinatarios y seguimiento de resultados. La guía de Broadcasts describe los flujos tanto en el panel como mediante la API.

Para anunciar una función, importa o añade contactos que hayan dado su consentimiento, agrupa a los destinatarios en un Segment, elige el Topic adecuado, prepara el mensaje, comprueba cómo funciona la baja y programa el Broadcast. Un Segment es una agrupación interna; un Topic es una preferencia que puede controlar el destinatario.

Si una integración antigua menciona Audiences, revisa sus supuestos. Resend utiliza ahora Contacts globales y Segments: una dirección puede pertenecer a varios segmentos y contar como un solo Contact. Su guía de migración de Audiences indica que la API de Audiences está obsoleta. Esto importa si el código antiguo trata una baja como algo limitado a una audiencia concreta.

Resend también documenta Automations, con activadores personalizados, condiciones, retrasos y pasos que esperan a que ocurra un evento. Por tanto, una secuencia de bienvenida puede residir en Resend en lugar de depender por completo del código de la aplicación. Antes de trasladar un programa de ciclo de vida, identifica sus activadores y condiciones de salida reales: poder dibujar una secuencia no resuelve quién la mantendrá.

Precios de Resend: Pro es el punto de partida práctico

El plan Pro inicial de Resend cuesta $20 al mes por 50,000 correos, sin límite diario de mensajes y con 10 dominios. Free ofrece 3,000 al mes, con un máximo de 100 al día y 3 dominios. Ese tope diario importa antes que la cuota mensual: un lanzamiento hipotético con 60 registros y dos mensajes por registro requiere 120 envíos ese día. La página de precios vigente también incluye Scale desde $90 al mes por 100,000 correos y planes Enterprise personalizados.

Precios de la API de Resend: revisa el selector de volumen antes de pagar excedentes

Si se utiliza toda la cuota incluida, el Pro inicial equivale a $0.40 por 1,000 correos: $20 dividido entre 50,000 y multiplicado por 1,000. Si solo se envían 5,000 correos, la misma suscripción equivale a $4 por 1,000. Estos cálculos describen el coste de la cuota, no el precio por entrega efectiva en la bandeja de entrada.

La tabla de precios legible por máquinas del proveedor también incluye Pro a $35 por 100,000 correos. Con ese volumen, mantener el Pro inicial con los excedentes habilitados costaría $20 + 50 × $0.90 = $65. Elige la asignación mayor de Pro antes de dar por hecho que pagar excedentes o pasar a Scale es la siguiente compra razonable.

El marketing se factura por separado: Free cubre 1,000 contactos; Pro para marketing parte de $40 al mes por 5,000; Enterprise es personalizado. Los envíos con Broadcasts son ilimitados dentro de la asignación de contactos y no consumen la cuota transaccional. Enviar un boletín a través de /emails sí consume cuota transaccional y deja la gestión de las bajas en manos de tu implementación.

Para este perfil de lector, conviene empezar con Pro transaccional de pago si los picos de producción pueden superar Free. Añade capacidad de marketing cuando la lista de contactos lo necesite. Evalúa Scale por sus funciones operativas, como la opción de IP dedicada, en lugar de interpretar su nombre como prueba de que es la forma más barata de comprar más envíos.

Limitaciones que pueden cambiar la decisión

Las principales restricciones de Resend tienen que ver con la responsabilidad sobre la entrega, la retención, los límites compartidos y los datos almacenados. Pesan más que lo elegante que parezca la primera llamada a la API.

Tu aplicación es responsable de los rechazos por cuota

Resend contabiliza tanto el correo enviado como el recibido en la cuota transaccional, y cada destinatario cuenta por separado. La cuota diaria de Free se restablece a medianoche UTC. Los excedentes de pago están desactivados hasta que un administrador los habilita; un envío rechazado por cuota devuelve un error y Resend no lo pone en cola ni lo reintenta. Estas reglas aparecen expresamente en su documentación de límites de cuenta.

Coloca las tareas que admitan reintentos en tu propia cola y genera alertas ante los fallos de cuota. Para restablecer contraseñas, comprueba la validez del token antes de reintentar una tarea antigua. Un mensaje enviado cuando se restablezca el límite puede haber dejado de ser útil.

Pagar un plan no aumenta automáticamente las solicitudes por segundo

Todas las cuentas empiezan con 10 solicitudes por segundo por equipo, compartidas entre claves de API y dominios. Crear otra clave no crea una cuota independiente. El envío por lotes permite incluir hasta 100 correos en una solicitud, pero tu cola debe seguir respetando el límite de solicitudes. Resend indica que cambiar a un plan superior no lo aumenta automáticamente; para obtener más capacidad de procesamiento hay que hablar por separado con soporte.

Esta es la diferencia entre capacidad total y ritmo de procesamiento. La primera indica cuántos mensajes caben en el mes. El segundo, cuántas solicitudes puede hacer tu aplicación durante un pico. Presupuesta y diseña para ambos.

La retención no sustituye tu registro permanente de auditoría

Free, Pro y Scale conservan los datos de correos y registros durante 30 días; Enterprise ofrece retención flexible. Guarda tu propio historial de eventos si una disputa sobre un recibo o una investigación de soporte puede llegar más tarde. Conserva también el evento del negocio con independencia del plazo de idempotencia de 24 horas del proveedor.

La eliminación anticipada también tiene restricciones. Las indicaciones públicas de Resend sobre tratamiento de datos señalan que no existe una API para eliminar un correo individual; para borrar antes de tiempo los mensajes enviados hay que recurrir a soporte, y los recibidos no se pueden eliminar antes de que termine el periodo de retención. No encaja bien con un flujo que exija eliminación programática inmediata.

Enviar desde Europa no implica almacenar allí los datos

Resend ofrece regiones de envío en el norte de Virginia, Irlanda, São Paulo y Tokio. Su documentación de regiones distingue entre el lugar de envío y el de almacenamiento.

Los datos de los clientes, incluidos el contenido de los mensajes, los registros de entrega, los datos de los webhooks y los registros de las cuentas, se almacenan en Estados Unidos. Resend indica que no existe una opción que traslade esos datos almacenados a la UE. Su página sobre el RGPD expone su postura de cumplimiento, describe la autoauditoría y explica el acuerdo de tratamiento de datos estándar y las cláusulas de transferencia. Esas declaraciones no convierten un dominio de envío en Irlanda en almacenamiento exclusivo en la UE.

Resend también declara cumplimiento de SOC 2 Type II; la página pública identifica el periodo del informe, pero para acceder al propio informe hay que iniciar sesión. La presentación de seguridad enumera las protecciones de cifrado y marca HIPAA como «En curso». Son declaraciones del proveedor revisadas para este análisis, no una auditoría de cumplimiento independiente.

Si el almacenamiento exclusivo en la UE o un acuerdo HIPAA disponible actualmente son requisitos de compra obligatorios, no apruebes Resend basándote en su menú de regiones de envío ni en sus distintivos de seguridad. Aclara el requisito exacto antes de integrar el servicio.

Veredicto: elige Resend si tu equipo puede gestionar los puntos de fallo

Resend es una buena opción para un equipo de producto pequeño que busca un recorrido coherente entre plantillas, envío por API o SMTP, eventos de entrega y campañas de marketing ocasionales. Su valor está en reducir el trabajo de integración mientras el comportamiento del producto sigue bajo tu control.

La decisión cambia si el almacenamiento en Estados Unidos incumple tus requisitos, si el diagnóstico a nivel SMTP es esencial o si tu aplicación no puede gestionar con seguridad los fallos de cuota y los reintentos. Un proveedor anterior que funciona también sigue siendo una buena elección cuando migrar no ofrece una ventaja concreta.

Para la implementación de la próxima semana, lleva un flujo de restablecimiento de contraseña y otro de recibos por la autenticación de dominio, el rechazo por cuota, las solicitudes duplicadas, la gestión de rebotes y la consulta desde soporte. Incluye una estimación del volumen del día de mayor demanda. Elige Resend cuando puedas identificar al responsable y el comportamiento esperado en cada punto de fallo, no solo cuando el correo de bienvenida se vea bien.

Preguntas frecuentes

El nombre coincide con la acción de «reenviar un correo» en inglés. Estas respuestas distinguen el producto de las acciones de un buzón.

¿Qué servicios gratuitos son recomendables para enviar correos?

Para una aplicación, Resend es un punto de partida razonable si los límites diarios y mensuales de Free encajan. Una cuota gratuita no basta para producción si un pico de lanzamiento puede agotarla; dimensiona el servicio según el día de mayor actividad.

¿Cómo se reenvía un mensaje en el nuevo Outlook?

En el nuevo Outlook, abre Elementos enviados, selecciona el mensaje y utiliza el menú de más opciones y Acciones avanzadas → Reenviar mensaje. Revisa el borrador antes de enviarlo. Las instrucciones de Microsoft para reenviar describen esta función del buzón; no tiene relación con la API de Resend.

¿En inglés se dice resent o resend?

«Resend» significa volver a enviar; «resent» es su pasado. Resend, con mayúscula inicial, es también la marca de la plataforma de correo analizada aquí.

¿Cómo puedo anular un correo que ya envié?

No uses la plataforma Resend como si fuera una herramienta para recuperar mensajes de un buzón. Outlook tiene una función de recuperación independiente con restricciones de cuenta y organización; la explicación de Microsoft indica que no permite recuperar mensajes enviados a cuentas externas o personales.

¿Cómo vuelvo a enviar un correo que ya envié?

En Outlook, usa la acción sobre el mensaje enviado descrita arriba. En una aplicación, decide si se trata de un reintento del evento original o de un nuevo envío deliberado; reutilizar una clave de idempotencia de Resend dentro de su plazo de protección evita un duplicado.

¿Puedo recuperar un correo que ya envié?

Si quieres consultar un mensaje de Resend, utiliza su página Emails y los detalles del mensaje dentro del periodo de retención. Si quieres eliminar la copia del destinatario, consultar o borrar tu propio registro no equivale a recuperar un mensaje de su buzón.

¿Cómo puedo ver los correos que he enviado?

Resend muestra los mensajes enviados y programados en su panel Emails, incluidos los enviados por SMTP. Abre un mensaje para consultar los metadatos, la vista previa, el HTML, el texto sin formato y los eventos de entrega.

¿Por qué no aparecen los correos que he enviado?

En Resend, comprueba si se aceptó el envío y si sus datos siguen dentro del periodo de retención. En Outlook, revisa la carpeta correcta de Elementos enviados y las opciones de guardado; la guía de correo enviado de Microsoft explica por qué puede faltar una copia enviada.

¿Cómo recupero mis mensajes enviados?

Primero distingue entre una copia que falta en el buzón y unos registros del proveedor que han caducado. Para investigar en Resend más allá de su periodo de retención, utiliza el historial de eventos que hayas guardado; no diseñes un proceso de soporte que dé por hecho que el panel del proveedor es un almacenamiento permanente.

Usa la AI Business Workflow Audit Checklist para asignar un responsable a cada activador de correo, fallo y paso de recuperación; consigue la lista a través del boletín.