Resend vs Postmark : DX moderne contre deliverability éprouvée

Deux paris différents sur ce qui compte vraiment

Resend et Postmark sont tous les deux des API de transactional email conçues pour les développeurs. Ni l'un ni l'autre ne fait de campagnes marketing. Ni l'un ni l'autre n'essaie d'être une plateforme email tout-en-un. Ils font le même job : envoyer des emails transactionnels de manière fiable via une API propre.

Mais ils ont fait des paris différents sur ce qui compte le plus.

Resend a parié sur la developer experience. L'API est moderne, l'onboarding est rapide, et l'intégration React Email permet de construire ses templates email comme on construit le reste de son app. C'est un produit construit par des devs qui en avaient marre de l'état de l'outillage email et qui ont décidé de tout refaire from scratch.

Postmark a parié sur la deliverability. Ils ont passé plus de quinze ans à être obsédés par le placement en inbox, la vitesse d'envoi et la fiabilité du transactional email. Ils ont été parmi les premiers services email à séparer complètement le transactional du marketing, et toute leur réputation repose sur cette séparation.

Aucun des deux paris n'est mauvais. Mais celui qui compte le plus pour nous détermine lequel on devrait choisir.

Ce que Resend fait bien

La developer experience est véritablement best-in-class. Si on a déjà lu le comparatif Resend vs SendGrid, le côté Resend s'applique ici aussi : API propre, doc moderne, intégration rapide.

Le workflow React Email est le point fort. Les templates email sont des fichiers .tsx dans le codebase. On importe des composants, on passe des props, on utilise de la logique conditionnelle, on preview en local. Pas d'éditeur de templates séparé. Pas de context-switching vers un dashboard web. Les emails sont versionnés et déployés avec le reste du code.

Pour une équipe qui build déjà avec React ou Next.js, c'est un vrai gain de productivité. On arrête de maintenir deux mondes séparés — ses composants app et ses templates email — et on les fusionne en un seul.

L'API REST est minimale et bien pensée. Une poignée d'endpoints, des messages d'erreur clairs, un SDK TypeScript bien typé, et une documentation qu'on peut lire en une session. Le flow d'onboarding fait passer du signup au premier email envoyé en moins de cinq minutes. La vérification de domaine guide à travers le setup SPF, DKIM et DMARC sans présupposer qu'on est un expert en deliverability.

Le setup des webhooks est propre : on choisit les événements qui nous intéressent (delivered, bounced, opened, complained), on les pointe vers une URL, et c'est réglé. Pas de labyrinthe de configuration.

Resend ship aussi vite. Le produit ajoute des features à un rythme qui reflète une petite équipe focalisée et à l'écoute de ses utilisateurs. Le batch sending, les audiences et la gestion de domaines se sont tous améliorés rapidement.

Ce que Postmark fait bien

La deliverability. C'est le titre, et il est mérité.

Postmark publie ses stats de vitesse de livraison et d'uptime publiquement. Ils le font depuis des années. La boîte a été fondée en 2009 et a passé toute son existence à se concentrer sur le transactional email. Pas le marketing. Pas les newsletters. Juste les emails dont les utilisateurs ont vraiment besoin : resets de mot de passe, reçus, notifications, codes de double authentification.

Ce focus compte parce que la deliverability du transactional email dépend de la réputation de l'expéditeur, et la réputation de l'expéditeur dépend du type d'email qu'on envoie. L'email marketing génère plus de plaintes et de signalements spam. En refusant de mélanger marketing et transactional sur la même infrastructure, Postmark garde sa réputation d'envoi plus propre que les plateformes qui gèrent les deux.

Le résultat : les emails Postmark arrivent vite et atterrissent en inbox, pas en spam. Leur temps de livraison médian est constamment sous la seconde. Pour les emails time-sensitive — resets de mot de passe, codes 2FA, confirmations de commande — cette vitesse compte.

Le traitement des emails entrants est un autre domaine où Postmark prend l'avantage. On peut configurer un inbound email handling via Postmark : on reçoit des emails à une adresse et le contenu parsé est livré à l'app via webhook. C'est utile pour des features de reply-by-email, l'ingestion de tickets support, ou tout workflow où l'app doit recevoir et traiter des emails entrants. Resend ne propose pas encore ça comme feature core.

Le système de templates de Postmark est aussi solide, même s'il fonctionne différemment de React Email. On crée des templates avec le langage de templating de Postmark (similaire à Mustache/Handlebars) soit depuis leur dashboard, soit via l'API. Les templates supportent les layouts, les conditionnelles et l'itération. C'est moins dev-friendly que d'écrire des fichiers .tsx, mais c'est mature et bien documenté.

La feature Message Streams permet de séparer différents types d'email (transactional, broadcast) en flux distincts avec du tracking et du reputation management séparés. C'est un choix architectural réfléchi qui donne le contrôle sur comment les différents types d'email affectent la réputation d'envoi.

Developer experience : le vrai fossé

C'est là que le comparatif devient opiniâtre.

L'API de Resend a le goût de 2024. La structure des endpoints est plate et prévisible. Le SDK est petit, bien typé, et n'embarque pas de dépendances inutiles. Les messages d'erreur disent ce qui a foiré et comment le corriger. La doc est code-first et organisée par tâche, pas par ressource API. On peut tout lire en vingt minutes.

L'API de Postmark est propre et bien conçue pour son époque. Elle existe depuis plus longtemps et ça se voit — pas en mal, mais dans le sens "construit avec des conventions différentes". L'API marche bien, la documentation est complète, et les librairies officielles couvrent la plupart des langages. Mais l'expérience TypeScript est moins polie, et le modèle mental demande un peu plus d'apprentissage initial.

Là où ce fossé se montre vraiment, c'est dans la première heure d'intégration. Avec Resend, on passe de zéro au premier email envoyé en moins de cinq minutes. Avec Postmark, le setup reste simple, mais il y a plus de concepts à absorber (servers, message streams, sender signatures) avant d'envoyer.

Pour le développement au quotidien, l'écart se réduit. Les deux API sont stables et prévisibles une fois qu'on les comprend. Mais pour un fondateur solo qui évalue des fournisseurs email un samedi matin, l'onboarding "ça juste marche" de Resend crée une très forte première impression.

React Email : une vraie décision de workflow

Ce point mérite sa propre section parce que ce n'est pas qu'une feature — c'est un workflow.

Avec Resend, React Email est first-class. On installe @react-email/components, on construit ses templates comme des composants React, on les preview dans un dev server local, et on les passe directement à l'API Resend. Les templates vivent dans le repo, sont reviewées en pull request, et se déploient avec l'app. Pas de context-switching. Pas de dashboard séparé.

Avec Postmark, on a deux chemins. Soit on utilise leur système de templates intégré, ce qui veut dire éditer des templates dans le dashboard Postmark ou les synchroniser via l'API avec leur syntaxe de templating. Soit on rend ses composants React Email en HTML soi-même et on envoie le résultat via l'API Postmark. Ça marche, mais c'est une étape de plus. On perd l'intégration serrée et on doit gérer le pipeline de rendu soi-même.

Si l'équipe vit dans React et veut que les templates email fassent partie du codebase, Resend gagne ici de manière décisive. Si React Email nous est égal et qu'on est à l'aise avec une approche templates classique, le système de Postmark est mature et fiable.

Le comparatif pricing

Resend donne 100 emails par jour sur le free tier, jusqu'à 3 000 par mois. Le plan Pro est à $20/month pour 50 000 emails. Le pricing scale par volume avec des tiers simples et prévisibles. Pas de surprises.

Postmark offre un tier développeur avec 100 emails par mois gratuitement. Les plans payants commencent à $15/month pour 10 000 emails, $35/month pour 25 000, et montent à partir de là. Chaque batch d'emails supplémentaire a un coût unitaire clair.

À très faible volume, le free tier de Resend est plus généreux pour les envois quotidiens. À volume modéré (10 000-50 000 par mois), les tarifs sont compétitifs. À plus haut volume, la comparaison dépend des volumes exacts — le pricing par email de Postmark peut être moins cher pour certaines tranches, tandis que les tiers fixes de Resend peuvent l'être pour d'autres.

Pour un SaaS indé typique qui envoie quelques milliers d'emails transactionnels par mois, ni l'un ni l'autre ne va casser la tirelire. La différence de prix est assez faible pour ne pas driver la décision. On choisit sur le produit, pas sur le tarif.

Deliverability : là où Postmark a fait ses preuves

Les deux services délivrent les emails de manière fiable. Pour un SaaS classique qui envoie des resets de mot de passe et des emails de notification, les deux atterriront en inbox sans problème. Le setup SPF, DKIM et DMARC est bien géré par les deux plateformes.

Mais le track record de Postmark va plus loin. Ils publient leurs métriques de livraison publiquement et le font depuis des années. Leur infrastructure est construite exclusivement autour du transactional email, ce qui veut dire que chaque décision architecturale optimise pour le placement en inbox et la vitesse de livraison. Le temps de livraison médian sous la seconde n'est pas du marketing — c'est le reflet de choix d'infrastructure faits sur plus d'une décennie.

La deliverability de Resend est bonne out of the box. Leurs réglages par défaut sont solides, et ils gèrent bien le setup d'authentification. Mais c'est une boîte plus jeune avec un historique plus court. Pour la plupart des SaaS, ça ne change rien — les emails de reset de mot de passe arriveront très bien. Mais si on build quelque chose où la vitesse et la fiabilité de livraison des emails sont business-critical (notifications financières, alertes santé, codes de sécurité), le track record plus long de Postmark apporte plus de confiance.

Maturité des features : profondeur contre fraîcheur

Postmark a des features qui ne viennent qu'avec des années de développement focalisé. Le traitement des emails entrants, les message streams, le bounce management avec réactivation automatique, des analytics de livraison détaillées, le support SMTP relay, et un système de templates mature avec layouts. Ce ne sont pas des features flashy, mais elles représentent une profondeur qui prend du temps à construire.

Resend est plus récent et ship des features vite. Le batch sending, les audiences, la gestion de domaines et l'écosystème React Email se sont tous améliorés rapidement. Mais il y a des trous. L'inbound email n'est pas encore disponible. Certaines analytics de livraison avancées sont moins matures. Le produit est excellent pour ce qu'il fait, mais sa surface de features est plus étroite.

Ça compte si on choisit un fournisseur email pour le long terme. Postmark a moins de chances de nous surprendre avec une feature manquante dans deux ans. Resend a plus de chances de nous ravir par la qualité des features qu'il propose.

Inbound email : l'avantage discret de Postmark

Si le produit a besoin de recevoir et traiter des emails — du reply-by-email dans un helpdesk, des emails entrants pour créer des tickets, des reçus transférés à parser — Postmark a un système de traitement d'inbound email intégré. Les emails envoyés à l'adresse configurée sont parsés et livrés au endpoint webhook avec des données structurées : headers, body, pièces jointes, tout est extrait et prêt à être utilisé.

Resend ne propose pas l'inbound email handling comme feature core. Si on en a besoin, il faudra un service séparé ou une approche complètement différente.

Pour beaucoup de SaaS, l'inbound email est hors sujet. Mais pour ceux qui en ont besoin, l'avoir intégré à son fournisseur de transactional email simplifie la stack. Un vendor de moins, une intégration de moins, une facture de moins.

Quand choisir Resend

• On build avec React ou Next.js et on veut les templates email comme composants dans le codebase.
• La developer experience et un API design moderne sont des priorités hautes pour l'équipe.
• On veut l'onboarding et l'intégration les plus rapides possibles.
• On préfère une API propre et minimale à une large couverture de features.
• On est fondateur solo ou petite équipe et on veut que l'email se fonde naturellement dans la stack.
• On veut aller vite et le workflow React Email colle à la façon dont on build déjà.

Quand choisir Postmark

• La deliverability et le placement en inbox sont business-critical pour le produit.
• On veut la confiance d'un fournisseur avec 15+ ans de focus sur le transactional email.
• On a besoin du traitement des emails entrants intégré à son fournisseur email.
• La maturité des features et la stabilité comptent plus qu'une DX cutting-edge.
• On est à l'aise avec des templates email classiques et React Email n'est pas un besoin.
• On veut des message streams pour gérer différents types d'email avec des réputations séparées.
• On a besoin du support SMTP relay pour des systèmes legacy en plus d'une API REST.

Verdict

Resend c'est la meilleure developer experience. Postmark c'est le pari deliverability le plus sûr.

Si on est une équipe dev-first qui build une app moderne et qu'on veut une infra email à la hauteur du reste de la stack, Resend est le choix naturel. Le workflow React Email seul vaut le coup si l'équipe travaille en React. L'API est plus propre, l'onboarding est plus rapide, et tout le produit donne l'impression d'avoir été construit par des gens qui comprennent comment on travaille.

Si on build quelque chose où la livraison des emails est mission-critical et qu'on veut le fournisseur avec le track record le plus long et le plus focalisé en transactional email, Postmark a gagné cette confiance. Quinze ans d'obsession pour la deliverability, un engagement public à séparer le transactional du marketing, et des features comme l'inbound processing qui viennent d'une expertise de domaine profonde.

Pour la plupart des projets SaaS indés, les deux choix sont bons. On ne regrettera pas Resend, et on ne regrettera pas Postmark. La question c'est si on optimise sa stack email pour le plaisir de builder avec ou pour la confiance dans la livraison. Les deux sont des priorités valides. On choisit celle qui colle à la nôtre.