Resend email : avis, tarifs et limites pour un SaaS

Resend email est un choix solide pour une petite équipe produit qui veut relier inscriptions, reçus et réinitialisations de mot de passe à son application sans alourdir l’intégration. La contrepartie se joue en production : l’offre gratuite s’arrête à 100 emails par jour, et l’application doit gérer les messages refusés pour dépassement de quota. Choisissez Resend pour son workflow de développement ; dimensionnez l’abonnement selon vos pics d’activité et choisissez le prestataire selon vos exigences en matière de données.

Vérifié à partir des pages publiques de Resend consacrées aux tarifs, à la documentation et à la sécurité le 13 novembre 2026. Cet avis porte sur les workflows documentés, les limites et les calculs de facturation ; il ne repose ni sur des tests dans un compte connecté ni sur des mesures de placement en boîte de réception.

Resend email : à quoi sert la plateforme ?

Resend est un service d’acheminement d’emails que votre application appelle via une API, une interface de programmation, ou via SMTP, le protocole standard d’envoi de courrier électronique. Il envoie des messages individuels déclenchés par des événements et des campagnes marketing Broadcasts, gère les contacts et les modèles, remonte les événements de livraison et reçoit des emails que votre application peut traiter. Votre produit reste responsable de déterminer qui doit recevoir un reçu, si une demande de réinitialisation est valide et comment réagir à un échec d’envoi. La documentation de démarrage décrit les modes d’envoi et les intégrations disponibles selon le langage.

À quelles équipes Resend convient-il ? Quand passer son chemin ?

Resend s’adresse aux fondateurs et aux développeurs qui veulent gérer l’email comme un autre service applicatif : versionner le modèle, fournir les données de l’événement, envoyer le message et traiter le résultat. Le cas le plus convaincant est celui d’un petit SaaS dont l’application et les emails transactionnels sont gérés par les mêmes personnes.

Le choix dépend de l’effort d’intégration, de la gestion des échecs, de la responsabilité du marketing et des contraintes sur les données. Il ne repose pas sur une affirmation sans preuve selon laquelle un prestataire placerait davantage de messages en boîte de réception.

Ne migrez pas si votre prestataire actuel fonctionne et si vous ne savez pas quel problème Resend résoudra. Une API plus agréable ne suffit pas, à elle seule, à justifier le déplacement d’un trafic email établi. Postmark mérite de figurer dans votre sélection si la séparation des infrastructures d’envoi est une exigence ; Amazon SES aussi, si votre équipe veut garder la main dans AWS.

Si une personne du marketing doit piloter au quotidien les parcours d’accueil, comparez Loops, dont le produit est centré sur les emails du cycle de vie des clients SaaS. Resend propose désormais aussi Automations : comparez le parcours réel que cette personne devra maintenir, plutôt que de vous appuyer sur l’idée dépassée que Resend se limite aux messages envoyés par API.

Alternatives à Resend : dans quels cas les privilégier ?

Twilio SendGrid : privilégiez-le si votre utilisation actuelle d’Email API, de SMTP et de Marketing Campaigns répond déjà à vos besoins. Conservez-le tant que le coût de maintenance de cette configuration ne dépasse pas un bénéfice précis attendu de la migration.

Postmark : privilégiez-le lorsque la séparation entre trafic transactionnel et campagnes est déterminante. Sa documentation Message Streams décrit des infrastructures IP distinctes. C’est une différence d’architecture concrète, pas une promesse de meilleurs résultats pour votre domaine.

Mailgun : retenez-le dans votre sélection si vos besoins incluent la validation des adresses et le routage, en plus de l’envoi. Pour ce profil d’acheteur, ces outils supplémentaires comptent davantage qu’une syntaxe agréable pour l’appel d’envoi.

Amazon SES : privilégiez-le si vos ingénieurs exploitent déjà AWS et veulent y intégrer l’email. Comparez l’effort de mise en œuvre dans son ensemble, supervision et gestion des incidents comprises.

Loops : privilégiez-le si la décision d’achat part des parcours d’accueil, d’activation et de réactivation gérés par la personne responsable du cycle de vie client du SaaS. Faites une démonstration du même parcours dans les deux produits avant de choisir.

Pour choisir plus largement une plateforme de campagnes, l’avis sur GetResponse traite d’un autre besoin que celui du transport des emails d’une application.

API email de Resend : de l’événement produit au message

Le principal atout de Resend est le chemin court entre un événement applicatif et un message construit à partir d’un modèle. Son SDK Node.js reçoit un expéditeur, un destinataire, un objet et un contenu, puis renvoie un résultat contenant des données ou une erreur. D’autres guides de démarrage documentent Python, PHP, Ruby, Go, Rust, Java et .NET : adopter le service n’impose pas d’adopter React.

Prenons un reçu envoyé après un paiement réussi. Votre application enregistre le paiement, prépare les données du reçu, demande l’envoi à Resend et associe l’identifiant du message renvoyé à ce paiement. Le support peut ensuite enquêter sur le reçu sans devoir chercher uniquement par nom de client. Le guide de démarrage Node.js présente l’opération d’envoi sous-jacente.

Modèles d’emails Resend : qui doit maîtriser le contenu ?

React Email permet aux développeurs de construire le contenu des emails avec des composants React. Resend prend en charge les messages gérés dans le code comme les modèles hébergés. Son guide d’intégration React Email décrit l’aperçu local, la sortie HTML ou texte brut et le transfert vers les modèles hébergés Templates.

Pour un reçu, gardez la mise en page dans le code si les modifications doivent suivre le processus de revue de l’application. Si une personne extérieure à l’équipe technique doit corriger le texte, un modèle hébergé peut mieux répartir les responsabilités : l’application fournit les variables et la personne responsable du contenu modifie le message. La documentation Templates décrit l’éditeur, l’historique des versions et l’envoi à partir de l’identifiant d’un modèle publié.

L’intérêt est de savoir clairement qui prend en charge chaque modification. Aucune de ces approches ne justifie de valider un email de réinitialisation de mot de passe sur son seul aperçu. Avant le lancement, testez le lien, son expiration et le contenu dans les clients mail utilisés par vos clients.

Une nouvelle tentative doit garder son identité

Resend prend en charge les clés d’idempotence : ces identifiants permettent à une requête d’envoi répétée de renvoyer le résultat initial au lieu de déclencher un nouvel email. La protection documentée dure 24 heures. Pour le workflow de reçu, dérivez la clé de l’événement correspondant et conservez le même contenu de requête lors des nouvelles tentatives. Le guide sur l’idempotence précise la durée de protection et l’erreur produite lorsqu’une même clé accompagne une charge utile différente.

Votre application doit tenir compte de cette limite. Si une tâche est rejouée après expiration, vous devez disposer de votre propre trace durable indiquant si l’envoi du reçu a déjà été demandé. La déduplication du prestataire protège utilement les nouvelles tentatives ; elle ne constitue pas un historique permanent des événements métier.

SMTP facilite la migration des applications existantes

Resend convient aussi aux applications qui utilisent déjà SMTP. Ses paramètres SMTP indiquent smtp.resend.com, le nom d’utilisateur resend et la clé API comme mot de passe. Le port 465 utilise TLS implicite ; le port 587, STARTTLS. Choisissez le mode de chiffrement correspondant dans votre client mail ou votre framework.

Vous pouvez ainsi conserver votre code de génération des emails tout en changeant leur transport. La contrepartie concerne le diagnostic : Resend indique ne pas fournir de journaux du serveur SMTP, même si les messages envoyés par SMTP apparaissent dans le tableau Emails. Si vous devez régulièrement déboguer les connexions, intégrez cette contrainte à votre décision de migration.

Configuration du domaine : prévoir l’authentification dès le lancement

Resend exige un domaine d’envoi vérifié. Sa configuration doit figurer dans la liste des tâches de lancement, au même titre que l’intégration API. C’est dans le DNS, le système qui publie les enregistrements de votre domaine, que vous autorisez le service à envoyer en votre nom.

SPF identifie les infrastructures autorisées à envoyer. DKIM ajoute une signature cryptographique aux messages. DMARC indique aux systèmes destinataires comment traiter les messages qui ne respectent pas la politique d’authentification du domaine. Ces fonctions sont distinctes : un badge vert de vérification du domaine ne remplace pas une configuration DMARC réfléchie.

Pour un nouveau SaaS, voici une configuration pratique :

1. 1

   Choisir l’expéditeur et la région d’envoi

   Ajoutez un domaine dans la page Domains de Resend. Pour un nouvel expéditeur, utilisez un sous-domaine dédié tel que account.example.com ; choisissez la région d’envoi adaptée à vos destinataires.

2. 2

   Publier les enregistrements générés

   Recopiez les configurations DKIM et SPF de Resend chez votre fournisseur DNS, exactement comme elles sont présentées. Vérifiez le domaine avant de brancher les envois destinés aux clients. Évitez de les remplacer par un enregistrement générique trouvé dans un tutoriel.

3. 3

   Ajouter DMARC et séparer les usages d’envoi

   Configurez DMARC après la vérification. Envisagez un sous-domaine marketing distinct pour gérer indépendamment les paramètres des newsletters et ceux des emails transactionnels.

4. 4

   Préserver la réputation acquise lors de la migration

   Si vous disposez déjà d’une adresse d’envoi établie, tenez compte de son historique dans votre migration. Resend recommande de conserver une telle adresse plutôt que de la remplacer systématiquement par un nouveau sous-domaine.

Le guide de configuration du domaine détaille les étapes ; les recommandations sur les domaines vérifiés expliquent l’exception liée à la migration et les paramètres de suivi distincts. Pour réinitialiser un mot de passe, privilégiez un lien direct et clair plutôt que le suivi de chaque clic sous prétexte que l’option existe.

Événements de livraison et emails entrants : boucler le workflow

Resend transmet à votre application des informations après l’appel d’envoi. C’est ce qui rend le service utile lorsqu’un client signale qu’un reçu n’est jamais arrivé. Les webhooks sont des notifications HTTPS envoyées à votre application lorsqu’un événement survient. Le guide des webhooks de Resend documente les événements de livraison, de rebond, d’ouverture et de clic, la vérification des requêtes, leur rejeu et le stockage des données d’événements dans votre propre base.

Pour le workflow de reçu, vérifiez les requêtes webhook, rattachez chaque événement à l’identifiant de message enregistré et rendez le traitement des événements répétable sans effet indésirable. Un rebond doit créer un état exploitable par le support, au lieu de disparaître dans un journal que personne ne consulte. Conservez cet historique dans votre propre système s’il doit survivre à la durée de rétention du prestataire.

« Livré » ne signifie pas « vu dans la boîte de réception ». Resend définit ce statut comme la remise au serveur mail du destinataire. Sa documentation de gestion des emails distingue les messages livrés, en rebond, retardés, en échec et bloqués par la liste de suppression. Appuyez-vous sur ces distinctions pour expliquer un échec à un client.

Les outils de délivrabilité aident au diagnostic sans prouver le placement

Deliverability Insights de Resend recherche notamment les incohérences de domaine dans les liens, l’absence de DMARC et l’absence de contenu en texte brut. Ces contrôles sont utiles sur les éléments du message que vous maîtrisez. Ils ne démontrent pas un taux de placement en boîte de réception.

La liste de suppression empêche également de poursuivre les envois vers des adresses ayant généré un rejet définitif ou une plainte. La limite à retenir est que la suppression s’applique à toute l’équipe : une adresse inscrite est ignorée sur l’ensemble de vos domaines et sous-domaines, pour les emails transactionnels comme pour les Broadcasts. La documentation sur les suppressions précise aussi que Gmail/Google Workspace ne remonte pas les événements de plainte.

Si vous combinez marketing et transactionnel, la conséquence est concrète : déplacer un destinataire bloqué vers un autre sous-domaine d’envoi ne rétablira pas l’envoi de son email de réinitialisation de mot de passe. Cherchez la raison du blocage et prévoyez une voie de récupération du compte. Ne retirez pas l’adresse de la liste pour relancer l’envoi sans examen.

La réception d’emails est également documentée

Resend prend en charge les emails entrants sur un domaine vérifié ou sur son sous-domaine géré resend.app. Le guide de réception décrit les notifications webhook, la récupération du contenu et des pièces jointes, le transfert et les réponses en fil de discussion.

Une réponse à un reçu de commande illustre bien l’intérêt : associez le message entrant à la commande, récupérez son contenu, puis créez une tâche pour le support. L’infrastructure de réception vous évite d’exploiter vous-même la collecte des emails. Vous restez responsable du traitement des pièces jointes, de la confiance accordée à l’expéditeur et des modifications qu’un message entrant peut déclencher dans le produit.

Broadcasts et contacts : expliciter l’intention marketing

Resend peut gérer la newsletter et les annonces produit d’une petite équipe sans obliger un développeur à construire un outil de campagnes de toutes pièces. Broadcasts propose un éditeur, la planification, le ciblage des contacts et le suivi des performances. Le guide Broadcasts décrit les workflows dans le tableau de bord comme par API.

Pour annoncer une fonctionnalité, importez ou ajoutez les contacts consentants, regroupez les destinataires visés dans un Segment, choisissez le Topic approprié, préparez le message, vérifiez le fonctionnement de la désinscription et programmez le Broadcast. Un Segment est votre regroupement interne ; un Topic correspond à une préférence que le destinataire peut gérer.

Si une ancienne intégration fait référence aux Audiences, revoyez son fonctionnement. Resend utilise désormais des Contacts globaux et des Segments : une même adresse email peut appartenir à plusieurs segments tout en ne comptant que comme un seul Contact. Son guide de migration des Audiences indique que l’API Audiences est dépréciée. C’est un point important lorsqu’un ancien code considère qu’une désinscription ne concerne qu’une audience donnée.

Resend documente aussi Automations, avec des déclencheurs personnalisés, des conditions, des délais et des étapes d’attente d’un événement. Une séquence de bienvenue peut donc résider dans Resend plutôt qu’entièrement dans le code de l’application. Avant d’y transférer un programme de cycle de vie client, cartographiez ses déclencheurs et conditions de sortie réels : pouvoir dessiner une séquence ne détermine pas qui la maintiendra.

Tarifs Resend : Pro est le point de départ pragmatique

L’offre Pro d’entrée de gamme coûte $20 par mois pour 50,000 emails, sans plafond quotidien et avec 10 domaines. Free inclut 3,000 emails par mois, avec un plafond de 100 par jour et 3 domaines. Cette limite quotidienne se fait sentir avant le quota mensuel : un lancement hypothétique avec 60 inscriptions et deux messages par inscription exige 120 envois dans la journée. La page des tarifs affiche aussi Scale à partir de $90 par mois pour 100,000 emails et des offres Enterprise sur mesure.

Prix de l’API Resend : comparer les volumes proposés avant les dépassements

Si toute son enveloppe incluse est utilisée, Pro d’entrée de gamme revient à $0.40 pour 1,000 emails : $20 divisés par 50,000, multipliés par 1,000. Avec seulement 5,000 emails réellement utilisés, le même abonnement revient à $4 pour 1,000. Ces calculs portent sur les volumes inclus, pas sur un prix par email effectivement arrivé en boîte de réception.

La grille tarifaire lisible par machine du prestataire mentionne aussi Pro à $35 pour 100,000 emails. À ce volume, conserver l’offre Pro d’entrée de gamme avec les dépassements activés coûterait $20 + 50 × $0.90 = $65. Choisissez le volume Pro supérieur avant de supposer que les dépassements ou Scale constituent nécessairement l’étape suivante.

Le marketing fait l’objet d’un compteur distinct : Free couvre 1,000 contacts ; Pro marketing commence à $40 par mois pour 5,000 ; Enterprise est sur mesure. Les envois Broadcasts sont illimités dans la limite du nombre de contacts autorisé et ne consomment pas le quota transactionnel. Envoyer une newsletter via /emails utilise en revanche ce quota et laisse la gestion des désinscriptions à votre implémentation.

Pour le public visé ici, commencez par Pro transactionnel payant lorsque les pics en production peuvent dépasser Free. Ajoutez de la capacité marketing lorsque la liste de contacts le nécessite. Évaluez Scale pour ses fonctions d’exploitation, comme son option d’IP dédiée, plutôt que de déduire de son nom qu’il offre le moyen le moins cher d’acheter davantage d’envois.

Les limites qui peuvent faire basculer le choix

Les principales contraintes de Resend concernent la responsabilité de la livraison, la rétention, les limites partagées et les données stockées. Elles comptent davantage que l’élégance du premier appel API.

Les refus pour quota relèvent de votre application

Resend décompte les emails envoyés et reçus du quota transactionnel, et chaque destinataire compte séparément. Le quota quotidien de Free est réinitialisé à minuit UTC. Les dépassements payants sont désactivés tant qu’un administrateur ne les active pas ; un envoi refusé pour quota renvoie une erreur, et Resend ne le met pas en file d’attente et ne le retente pas. Ces règles figurent explicitement dans sa documentation sur les limites des comptes.

Placez les tâches qui peuvent être retentées dans votre propre file d’attente et déclenchez des alertes sur les erreurs de quota. Pour les réinitialisations de mot de passe, vérifiez la validité du jeton avant de relancer une ancienne tâche. Un message envoyé après la réinitialisation du quota peut ne plus avoir d’utilité.

Un abonnement payant n’augmente pas automatiquement les requêtes par seconde

Tous les comptes démarrent à 10 requêtes par seconde et par équipe, partagées entre les clés API et les domaines. Créer une autre clé n’ajoute pas une nouvelle réserve. L’envoi par lots permet de regrouper jusqu’à 100 emails dans une requête, mais votre file d’attente doit toujours respecter la limite de requêtes. Resend indique qu’un changement d’offre ne la relève pas automatiquement ; un débit supérieur nécessite un échange distinct avec le support.

Il faut distinguer capacité et débit. La capacité détermine combien de messages peuvent être envoyés dans le mois. Le débit détermine combien de requêtes votre application peut effectuer pendant un pic. Prévoyez le budget et l’architecture pour les deux.

La rétention ne remplace pas votre historique d’audit permanent

Free, Pro et Scale conservent les données des emails et des journaux pendant 30 jours ; Enterprise propose une rétention flexible. Gardez votre propre historique d’événements si une contestation de reçu ou une enquête du support peut survenir plus tard. Conservez aussi l’événement métier indépendamment de la fenêtre d’idempotence de 24 heures du prestataire.

La suppression anticipée est elle aussi limitée. Les indications publiques de Resend sur le traitement des données précisent qu’il n’existe pas d’API pour supprimer un email individuel ; retirer un message envoyé avant l’échéance nécessite de contacter le support, et les messages reçus ne peuvent pas être retirés avant la fin de la période de rétention. Le service convient mal à un workflow exigeant une suppression immédiate par programmation.

Envoyer depuis l’Europe ne signifie pas y stocker les données

Resend propose des régions d’envoi en Virginie du Nord, en Irlande, à São Paulo et à Tokyo. Sa documentation sur les régions distingue le lieu d’envoi du lieu de stockage.

Les données clients, dont le contenu des messages, les journaux de livraison, les charges utiles des webhooks et les données de compte, sont stockées aux États-Unis. Resend indique qu’aucun paramètre ne permet de déplacer ces données stockées vers l’UE. Sa page RGPD expose sa position en matière de conformité, décrit son auto-évaluation et explique l’accord de traitement des données standard ainsi que les clauses de transfert. Ces déclarations ne transforment pas un domaine d’envoi en Irlande en stockage exclusivement européen.

Resend déclare également une conformité SOC 2 Type II ; sa page publique précise la période couverte, tandis que le rapport lui-même nécessite une connexion. La présentation de la sécurité énumère les protections par chiffrement et indique que HIPAA est « en cours ». Il s’agit ici de déclarations du prestataire examinées dans cet article, pas d’un audit de conformité indépendant.

Si un stockage exclusivement dans l’UE ou un dispositif HIPAA disponible dès maintenant est une exigence ferme de vos achats, ne validez pas Resend sur la seule base du menu des régions d’envoi ou des badges de sécurité. Clarifiez l’exigence exacte avant l’intégration.

Verdict : choisir Resend si l’équipe maîtrise les cas limites

Resend est un choix solide pour une petite équipe produit qui cherche un parcours cohérent entre modèles, envoi par API ou SMTP, événements de livraison et campagnes marketing occasionnelles. Sa valeur tient à la réduction du travail d’intégration, tout en vous laissant la maîtrise du comportement du produit.

Le choix s’inverse lorsque le stockage aux États-Unis ne respecte pas vos exigences, que les diagnostics au niveau SMTP sont indispensables ou que votre application ne peut pas gérer correctement les erreurs de quota et les nouvelles tentatives. Un ancien prestataire qui fonctionne reste également un bon choix lorsqu’une migration n’apporte aucun gain concret.

Pour l’implémentation de la semaine prochaine, faites passer un parcours de réinitialisation de mot de passe et un parcours de reçu par l’authentification du domaine, le refus pour quota, les requêtes en double, la gestion des rebonds et la recherche par le support. Ajoutez une estimation du volume du jour le plus chargé. Choisissez Resend lorsque chaque point d’échec a un responsable identifié et un comportement attendu, pas simplement lorsque l’email de bienvenue s’affiche bien.

Questions fréquentes

Le nom recoupe l’expression anglaise courante « resend an email », c’est-à-dire renvoyer un email. Les réponses ci-dessous distinguent le produit des actions effectuées dans une messagerie.

Quels services gratuits choisir pour envoyer des emails ?

Pour une application, Resend est un point de départ raisonnable si les limites quotidiennes et mensuelles de Free conviennent. Une enveloppe gratuite ne suffit pas en production si un pic de lancement peut l’épuiser ; dimensionnez le service selon la journée la plus chargée.

Comment renvoyer un email dans le nouvel Outlook ?

Dans le nouvel Outlook, ouvrez les Éléments envoyés, sélectionnez le message, puis utilisez le menu des options supplémentaires et Actions avancées → Renvoyer le message. Vérifiez le brouillon avant l’envoi. Les instructions de renvoi de Microsoft décrivent cette fonction de messagerie ; elle n’a aucun lien avec l’API de Resend.

En anglais, faut-il écrire « resent » ou « Resend » ?

« Resend » signifie envoyer à nouveau ; « resent » est sa forme au passé. Avec une majuscule, Resend est aussi le nom de la plateforme email examinée ici.

Comment rappeler un email déjà envoyé ?

Ne considérez pas la plateforme Resend comme un outil de rappel de messagerie. Outlook dispose d’une fonction de rappel distincte, soumise à des restrictions de compte et d’organisation ; l’explication de Microsoft sur le rappel précise qu’elle ne permet pas de rappeler des messages envoyés à des comptes externes ou personnels.

Comment renvoyer un email que j’ai déjà envoyé ?

Dans Outlook, utilisez l’action sur le message envoyé décrite ci-dessus. Dans une application, déterminez s’il s’agit d’une nouvelle tentative du même événement ou d’un nouvel envoi volontaire ; réutiliser une clé d’idempotence Resend pendant sa fenêtre de protection empêche un doublon.

Puis-je récupérer un email déjà envoyé ?

Si vous souhaitez consulter un message Resend, utilisez la page Emails et les détails du message pendant la période de rétention. Si vous souhaitez retirer la copie du destinataire, consulter ou supprimer votre propre enregistrement n’équivaut pas à rappeler un message dans une messagerie.

Comment consulter les emails que j’ai envoyés ?

Resend répertorie les messages envoyés et programmés dans son tableau de bord Emails, y compris les envois SMTP. Ouvrez un message pour consulter ses métadonnées, son aperçu, son HTML, son texte brut et ses événements de livraison.

Pourquoi mes emails envoyés n’apparaissent-ils pas ?

Dans Resend, vérifiez si l’envoi a été accepté et si ses données sont encore dans la période de rétention. Dans Outlook, vérifiez le bon dossier Éléments envoyés et les paramètres d’enregistrement ; le guide Microsoft sur les emails envoyés explique pourquoi une copie peut manquer.

Comment retrouver mes messages envoyés ?

Distinguez d’abord une copie manquante dans votre messagerie de journaux expirés chez le prestataire. Pour enquêter sur Resend au-delà de sa période de rétention, utilisez l’historique d’événements que vous avez conservé ; ne construisez pas un processus de support qui suppose que le tableau de bord du prestataire est un stockage permanent.

Utilisez la checklist d’audit des workflows métier avec l’IA pour attribuer un responsable à chaque déclencheur d’email, échec et étape de récupération ; recevez la checklist via la newsletter.