Postmark ou Mailgun : quelle API email pour votre SaaS ?

Email transactionnel pour SaaS

Pour une équipe SaaS qui envoie des reçus, des liens de connexion et des alertes produit, Postmark convient lorsque le volume reste lisible dans ses paliers et que vous voulez choisir entre trois niveaux de service. Mailgun offre plusieurs outils opérationnels autour de l’envoi, notamment le routage entrant, la validation d’adresses et des régions d’hébergement aux États-Unis ou dans l’Union européenne. À 10 000 messages par mois, Postmark Basic et Mailgun Basic coûtent chacun 15 $ par mois. À 50 000, comparez Postmark Basic à 55 $ et Mailgun Foundation à 35 $ par mois, avec des durées de journal différentes. Le choix dépend donc aussi de ce que votre équipe doit inspecter et traiter.

Repères de prix et de fonctionnement

Chaque montant correspond à un plan et à un volume donnés ; ces montants ne sont pas additionnés. Les prix sont mensuels. Pour Postmark, le volume de 10 000 emails ouvre trois choix tarifaires, alors que les montants à 50 000 et 125 000 différencient également Basic, Pro et Platform. Mailgun Basic couvre 10 000 emails par mois, Foundation en couvre 50 000 et Scale en couvre 100 000. Sur Foundation et Scale, les prix mensuels après le premier mois sont respectivement 35 $ et 90 $.

L’offre gratuite Postmark comprend 100 messages mensuels et n’autorise pas les dépassements. Elle sert à valider un flux peu volumineux, mais ne constitue pas une enveloppe quotidienne. Mailgun Free inclut 100 messages par jour, un domaine d’envoi personnalisé et un jour de conservation des journaux. Pour un produit qui envoie régulièrement des notifications, comparez bien la limite quotidienne avec vos pointes de trafic et la limite mensuelle avec votre prévision de facturation.

Postmark : choisir un palier selon l’usage

Postmark structure son tarif autour du nombre d’emails expédiés par mois et de trois plans payants. À 10 000 emails, Basic coûte 15 $ par mois, Pro 16,50 $ et Platform 18 $. La différence de prix entre ces paliers ne suffit pas à décider : l’équipe doit comparer les fonctions dont elle a réellement besoin et l’espace de suivi prévu dans le plan. Pour un volume de 50 000 emails, les prix mensuels sont 55 $ en Basic, 60,50 $ en Pro et 66 $ en Platform. À 125 000 emails, ils passent respectivement à 115 $, 126,50 $ et 138 $ par mois.

Les dépassements sont facturés par tranche de 1 000 emails au tarif propre au plan : 1,80 $ en Basic, 1,30 $ en Pro et 1,20 $ en Platform. Une prévision utile sépare le volume habituel des pics liés aux inscriptions, aux renouvellements ou à une panne nécessitant des messages de statut. Si ces pics sont récurrents, calculez la facture avec le palier adapté au volume mensuel prévu plutôt que de retenir le seul prix d’entrée.

Le traitement des emails entrants mérite une vérification au niveau du plan. Postmark présente cette fonction sur ses plans supérieurs, mais il faut déterminer le palier qui la couvre pour le flux précis de votre produit. Ce point compte si les clients répondent à des notifications, si une adresse sert à recevoir des pièces jointes ou si votre application transforme un email entrant en événement. Dessinez le parcours : adresse de réception, règles de routage, service qui consomme le contenu et comportement prévu en cas d’échec.

Sur Basic, la conservation des données est de 45 jours. Cette durée peut convenir à une équipe qui résout les incidents rapidement et exporte les éléments nécessaires à son suivi interne. Pour une enquête qui implique plusieurs services ou une longue période d’observation, intégrez la conservation à l’évaluation du plan et aux processus de support. La possibilité d’examiner un événement après sa survenue facilite le diagnostic d’un reçu manquant ou d’un lien d’accès qui n’arrive pas à destination.

Postmark s’envisage donc quand vous pouvez prévoir votre volume et que le couple plan, dépassement répond à votre profil d’envoi. Il faut aussi séparer les emails indispensables au fonctionnement du produit des campagnes non transactionnelles : ce choix éditorial et technique détermine les événements, les modèles et les mesures à suivre. Avant de retenir une formule, cartographiez ces catégories et confrontez-les au niveau de traitement entrant et de rétention nécessaire.

Mailgun : routage, contrôles et régions

Mailgun combine l’envoi par API ou relais SMTP avec des fonctions de réception et de validation. Son plan gratuit autorise 100 emails par jour, un domaine d’envoi personnalisé et un jour de journaux. Basic coûte 15 $ par mois pour 10 000 emails, avec un jour de journaux et les emails supplémentaires à partir de 1,80 $ par tranche de 1 000. Foundation coûte 35 $ par mois après son premier mois pour 50 000 emails ; il conserve les journaux pendant cinq jours et facture les messages additionnels à partir de 1,30 $ par 1 000.

Scale coûte 90 $ par mois après le premier mois et inclut 100 000 emails, 30 jours de journaux et 5 000 validations. Le palier convient à une équipe qui doit rapprocher les événements d’envoi et les décisions de validation sur une période plus longue. Pour comparer des factures, gardez les volumes distincts : à 50 000 emails, le repère Mailgun est Foundation à 35 $ par mois ; à 100 000, le repère est Scale à 90 $. Aucun de ces repères ne représente à lui seul le prix de validations additionnelles.

La validation aide à contrôler les adresses avant un envoi. Une équipe peut prévoir cette étape lors de la création d’un compte, d’un changement d’adresse ou de l’import d’une liste autorisée. Le nombre de validations incluses sur Scale est de 5 000. Déterminez si ces contrôles concernent les utilisateurs actifs, les invitations ou des adresses fournies dans un processus d’import ; leur rythme influencera le niveau de consommation. Gardez aussi un chemin de secours lorsque la validation ne peut pas aboutir, afin de ne pas bloquer silencieusement une action de l’utilisateur.

Le routage entrant de Mailgun peut s’inscrire dans un traitement applicatif des réponses. Une équipe produit peut ainsi prévoir un flux dédié à une adresse de support automatisée ou à une fonctionnalité de réponse par email. Avant l’activation, définissez les domaines et adresses concernés, les règles qui distribuent les messages, le format transmis à votre application et le traitement des contenus inattendus. Ces décisions réduisent le risque qu’un email entrant soit envoyé au mauvais service ou traité sans contrôle.

Les options d’hébergement aux États-Unis et dans l’Union européenne donnent un critère concret aux équipes qui doivent sélectionner une région pour leurs flux. Documentez où votre application traite les événements associés et qui peut consulter les journaux ; choisir une région d’envoi fait partie d’une décision plus large sur l’architecture et les accès. Mailgun propose également des IP dédiées, des analytics de délivrabilité et SAML SSO. Évaluez ces fonctions par rapport à vos besoins d’exploitation, à votre gestion des identités et au niveau de contrôle recherché sur l’envoi.

Les validations, la réception, les analytics et la fédération d’identité sont utiles seulement si elles s’insèrent dans un processus connu. Attribuez un responsable aux alertes de délivrabilité, décidez quand une adresse est revalidée et définissez les personnes autorisées à modifier la configuration. Les journaux durent un jour sur Basic, cinq sur Foundation et 30 sur Scale : cette progression peut peser dans le choix lorsque l’équipe d’astreinte a besoin de remonter un incident plusieurs jours après son apparition.

Dépassements, journaux et IP : comparer le coût d’exploitation

Le tarif de dépassement donne une indication sur la facture lorsque l’usage franchit le volume du plan. Postmark propose trois prix par 1 000 emails supplémentaires : 1,80 $ en Basic, 1,30 $ en Pro et 1,20 $ en Platform. Mailgun Basic commence à 1,80 $ par 1 000, tandis que Foundation commence à 1,30 $. Ces unités ne disent pas à elles seules quel outil sera moins cher : le plan choisi, les messages inclus et le dépassement réel doivent être lus ensemble.

La durée des journaux peut affecter le temps nécessaire au diagnostic. Un jour de conservation sur Mailgun Free ou Basic laisse une fenêtre courte pour analyser une plainte remontée tardivement. Foundation offre cinq jours et Scale 30 jours. Postmark Basic conserve les données 45 jours par défaut. Comparez ces durées au délai réel entre un envoi et un ticket client, puis vérifiez le mode de consultation des informations dont l’équipe de support a besoin. Un historique plus long est utile seulement si quelqu’un peut s’en servir et si la politique de votre équipe autorise cet accès.

Mailgun met les IP dédiées dans la liste de ses fonctions. Elles peuvent entrer dans l’évaluation d’un flux dont l’équipe veut gérer séparément l’identité d’expédition. La sélection doit inclure la manière dont les envois sont répartis, qui surveille les indicateurs et comment l’organisation traite les changements d’infrastructure. Pour Postmark, fondez votre choix sur les conditions qui s’appliquent au plan envisagé et à votre volume, sans supposer que les modalités d’un autre fournisseur sont identiques. Dans les deux cas, prévoyez une personne responsable de la configuration DNS et de son suivi.

Comment choisir pour une équipe SaaS

Postmark peut convenir à une équipe qui choisit un palier clair selon son volume et qui valorise une fenêtre de journal longue sur Basic. Mailgun correspond aux équipes qui veulent regrouper l’envoi avec des capacités de validation ou de routage entrant, ou qui doivent choisir une région d’hébergement aux États-Unis ou dans l’Union européenne. Dans les deux cas, préparez un essai avec des messages représentatifs : un reçu, une réinitialisation de mot de passe et une alerte de service. Vérifiez la création d’événements, les erreurs et les informations visibles par les personnes qui répondent aux tickets.

Votre prévision doit distinguer la moyenne et les pointes. Un SaaS qui envoie peu de messages la plupart des jours peut générer un grand nombre d’emails lors d’une migration de comptes ou d’un incident. Notez ces scénarios, estimez leur fréquence et comparez le résultat au seuil mensuel. Si vous utilisez une validation d’adresse, comptabilisez cette opération séparément des emails envoyés afin de ne pas confondre deux usages et leurs tarifs.

Migration et configuration DNS

Commencez la migration par l’inventaire des usages : types de messages, modèles, événements déclencheurs, adresses d’expédition, réponses entrantes et personnes qui consultent les journaux. Repérez les emails critiques qui doivent conserver leur contenu et leur comportement. Pour chacun, documentez le service émetteur, les variables du modèle, le destinataire prévu et la manière dont l’application réagit à un échec. Cette carte permet de comparer les deux API sur des parcours réels plutôt que sur une liste générale de fonctions.

Créez ensuite les domaines et identifiants nécessaires dans le nouvel outil, puis configurez les enregistrements DNS demandés par le fournisseur, notamment ceux liés à l’authentification de l’expéditeur. Faites valider la configuration avant d’augmenter le trafic. Les noms et valeurs des entrées DNS dépendent du fournisseur et du domaine utilisé ; recopiez les paramètres attribués à votre compte dans votre zone DNS, puis contrôlez leur résolution. Gardez une trace du propriétaire du domaine et de la procédure de modification afin de pouvoir revenir sur un changement incorrect.

Faites basculer un flux à la fois, par exemple les reçus avant les alertes de sécurité. Surveillez les erreurs côté application, les événements de livraison et les retours du support. Lorsque des réponses entrantes sont traitées, testez aussi le chemin de réception et le routage vers votre application. Une migration progressive révèle les dépendances oubliées sans déplacer simultanément tous les messages. Conservez les anciens modèles et la configuration précédente pendant la période de transition décidée par votre équipe.

Avant le basculement global, assurez-vous que chaque équipe sait où trouver les journaux, comment relancer une tâche et à qui signaler une anomalie. Après la migration, retirez les anciennes clés d’API selon votre procédure de sécurité et mettez à jour les documents internes. Ce travail de clôture évite qu’un ancien service continue d’envoyer un type de message en parallèle du nouveau fournisseur.

Questions fréquentes