Un fournisseur peut accepter votre volume mensuel tout en limitant le débit après une panne de tunnel de paiement. Comparez le contrat d'envoi avec le travail que votre application doit rattraper.
Qu'est-ce que l'e-mail transactionnel ?
L'e-mail transactionnel accompagne une transaction ou une activité de compte du destinataire, comme un reçu ou une réinitialisation de mot de passe. C'est la finalité du message qui détermine sa catégorie. Le nombre de destinataires et le déclenchement automatique ne rendent pas un contenu promotionnel transactionnel.
Que devez-vous évaluer ?
Comparez les capacités dont votre application a besoin, puis testez les chemins d'échec avant de vous engager.
- Délivrabilité et outils de réputation. Pouvez-vous authentifier votre domaine avec SPF, DKIM et DMARC facilement ? Des IP dédiées sont-elles disponibles si vous en avez besoin, avec des conseils pour les préchauffer ?
- Qualité de l'API et du SDK. L'API est-elle bien documentée, avec des SDK officiels dans les langages que vous utilisez ?
- SMTP et HTTP ensemble. Vérifiez quelle interface de soumission votre environnement d'exécution prend en charge. Les clients SMTP existants peuvent utiliser un relais ; une HTTP API convient aux applications qui soumettent des requêtes structurées.
- Templates. Les templates côté serveur avec substitution de variables vous permettent de modifier le texte sans redéployer et de conserver une mise en forme cohérente entre les messages.
- Webhooks et événements. Les événements webhook en temps réel pour la livraison, l'ouverture, le clic, le rebond et la plainte sont le moyen de garder vos propres enregistrements à jour et de déclencher une logique de suivi.
- Analytique. Vues agrégées des taux de livraison, de rebond et d'engagement, plus un journal consultable pour enquêter sur un message individuel.
- Gestion des suppressions. Le fournisseur doit automatiquement supprimer les rebonds durs et les plaintes afin que votre application puisse arrêter les envois bloqués par ces signaux. Demandez comment les listes de suppression sont gérées et si vous pouvez les consulter.
- Évolutivité. Le service supportera-t-il votre volume de pointe (lancement de produit, pic saisonnier) sans intervention manuelle ni limitation inattendue du débit ?
- Tarification. Comprenez le modèle (par message, par palier, volume inclus) et le seuil de dépassement. Calculez le coût pour votre volume prévu et vos périodes de pointe.
- Support. Quand les e-mails cessent de partir à 2 h du matin, comment joignez-vous un humain, et en combien de temps répond-il ? Vérifiez le niveau de support inclus dans le forfait que vous achèteriez réellement.
- Conformité. Confirmez que le fournisseur respecte les exigences de traitement des données et les exigences régionales auxquelles votre entreprise est soumise avant de vous engager.
Quand choisir un service de relais SMTP ?
Choisissez un relais SMTP quand votre application construit déjà les messages e-mail et prend en charge un serveur de messagerie configurable. Choisissez une HTTP API quand vous avez besoin de champs de requête structurés ou de templates stockés.
Pour Bird, comparez les chemins de soumission et de reprise avant de choisir l'interface :
| Décision ou échec | Relais SMTP | HTTP email API |
|---|---|---|
| Authentification | Nom d'utilisateur bird, clé API comme mot de passe, avec le scope emails. Utilisez TLS sur l'hôte SMTP régional. | Clé API dans l'en-tête Authorization: Bearer, avec le scope emails. |
| Réponse de soumission | Le 250 final contient l'identifiant du message mis en file d'attente. Enregistrez-le avec l'événement applicatif. | 202 contient l'identifiant du message accepté. Enregistrez-le avec l'événement applicatif. |
| Responsabilité de la réessai | Votre application ou le client SMTP gère les réessais de soumission. Réutilisez X-Bird-Idempotency-Key pour le même message logique. | Votre application ou SDK gère les réessais de soumission. Réutilisez Idempotency-Key pour le même message logique. |
| Expiration | Avant de réessayer un envoi non abouti, votre application vérifie si son lien ou son code est encore valide. | Effectuez la même vérification avant de soumettre une nouvelle requête. |
| Hypothèses de débit | Vérifiez les limites de connexions simultanées séparément des quotas d'envoi. Davantage de connexions ouvertes n'établissent pas un débit d'envoi autorisé. | Réglez le rythme des requêtes API en utilisant les en-têtes de limitation du débit de la réponse. Le débit de requêtes et le volume de destinataires sont des grandeurs différentes. |
| Preuves d'événement | Suivez les événements destinataire après la réponse de mise en file d'attente. Bird réessaie les livraisons différées. | Suivez les mêmes événements destinataire après l'acceptation. Bird réessaie les livraisons différées. |
| Sélection du pool | La configuration SMTP de la clé API sélectionne le pool. Une clé non configurée utilise le pool par défaut de l'organisation. | Définissez ip_pool_id par envoi, ou utilisez le pool par défaut de l'organisation. |
Le guide du relais SMTP fournit les paramètres de connexion et le traitement des réponses. La référence d'envoi HTTP définit la requête et la réponse API. Les deux interfaces utilisent le même pipeline e-mail, y compris la gestion des suppressions et la signature.
L'acceptation par le transport signifie que Bird a mis le message en file d'attente. L'événement email.delivered ultérieur signifie que le serveur destinataire l'a accepté. Ni l'un ni l'autre n'établit le placement en boîte de réception ou la lecture.
Conservez votre propre enregistrement d'envoi au-delà de la fenêtre de rétention d'idempotence, car un réessai ultérieur peut créer un autre message. Un report est déjà en cours de réessai par Bird ; créer un autre envoi duplique un travail encore en cours.
Les IP dédiées sont facultatives pour l'une ou l'autre interface. Vérifiez les exigences de pool et de préchauffage avant d'acheminer un pic à travers un pool dédié.
Quelles capacités publiées devez-vous comparer ?
Vérifiez l'interface documentée derrière chaque fonctionnalité. Recevoir un e-mail analysé, stocker son contenu et exposer un API de conversation sont des capacités différentes.
| Fournisseur | Soumission | Preuves destinataire | Infrastructure de réception et d'envoi |
|---|---|---|---|
| Bird | Envoi HTTP et SMTP | Événements, journal des messages et suppressions | Boîtes aux lettres et fils de discussion ; pools d'IP dédiées |
| Amazon SES | SendEmail API et SMTP | Destinations d'événements et liste de suppression du compte | Règles de réception dans les régions prises en charge ; IP dédiées standard ou gérées |
| SendGrid | Mail Send API et SMTP | Event Webhook et Email Activity | Webhook Inbound Parse ; pools d'IP |
| Mailgun | Messages API et SMTP | Événements de livraison et enregistrements de rebond | Routes pour transférer ou stocker le courrier ; pools d'IP |
| Postmark | Email API et SMTP | Webhooks et suppressions de flux | Webhook entrant ; éligibilité aux IP dédiées |
| Resend | Email API et SMTP | Événements webhook et journaux API | Contenu reçu et réponses ; IP dédiées gérées |
Confirmez l'éligibilité et la rétention pour le forfait que vous achèteriez. Un lien vers une fonctionnalité n'établit ni un débit autorisé ni un engagement de délai de reprise.
Pour le contenu stocké, vérifiez quels corps, en-têtes, pièces jointes et enregistrements d'événements restent consultables. Pour la résidence des données, obtenez le périmètre publié de stockage et de traitement, y compris les exceptions. Un point de terminaison régional seul n'établit pas ce contrat.
Qu'est-ce qui change à dix millions d'envois par mois ?
Le trafic de pointe et la capacité de reprise déterminent le débit d'envoi requis. Le volume mensuel seul ne suffit pas.
Sur un mois illustratif de 30 jours, dix millions de messages à destinataire unique représentent en moyenne environ 3,86 messages par seconde. Un pic de 100 000 messages en dix minutes nécessite environ 167 par seconde. Évaluez le pic séparément de l'enveloppe mensuelle.
Après une interruption de dix minutes à 100 nouveaux messages par seconde, votre application a 60 000 envois en attente. Si le nouveau travail continue à 100 par seconde, résorber cet arriéré en vingt minutes exige 50 par seconde supplémentaires. L'objectif de reprise est donc de 150 messages acceptés par seconde, hors réessais ou délais du serveur destinataire.
Vérifiez comment chaque fournisseur comptabilise le travail. Les quotas SES comptent les destinataires et s'appliquent séparément par région. Ils comprennent un quota journalier glissant et un débit d'acceptation. SES avertit également que l'acceptation réelle peut être inférieure au débit maximal du compte.
Les limites Resend distinguent le débit de requêtes API des quotas de volume d'e-mails. Les en-têtes de limitation du débit de Bird indiquent le quota de requêtes effectif. Convertissez la taille de vos lots en requêtes avant de comparer l'un ou l'autre avec le débit de destinataires du scénario.
Comment tester la reprise après incident ?
Testez comment votre application reprend après un échec de soumission ou une indisponibilité de son gestionnaire de webhooks. La page de statut du fournisseur fournit le contexte de l'incident ; vos enregistrements de messages établissent le travail restant.
| Fournisseur | Contrat publié de limites ou d'erreurs | Statut officiel |
|---|---|---|
| Bird | Quotas effectifs et en-têtes de réessai | Statut Bird |
| Amazon SES | Quotas d'envoi | Santé des services AWS |
| SendGrid | Limites de débit API | Statut SendGrid |
| Mailgun | Contrat d'erreurs et de limitation du débit API | Statut Mailgun |
| Postmark | Contrat de réponse et d'erreurs API | Statut Postmark |
| Resend | Limites d'utilisation | Statut Resend |
Mettez en pause un worker de test, accumulez les tâches puis reprenez dans la limite effective du compte. Mesurez le temps d'attente de la tâche éligible la plus ancienne. Les tâches de réinitialisation expirées nécessitent un chemin de nouvelle requête plutôt qu'un rejeu automatique.
Préservez chaque identifiant d'événement métier tout au long de la reprise. Vérifiez le contrat d'envoi en doublon du fournisseur avant de réessayer une soumission incertaine. Postmark ne documente aucune fonctionnalité de clé d'idempotence, son intégration nécessite donc des garde-fous applicatifs. La rétention des réponses complétées de Bird est de trois heures. La reprise au-delà de cette fenêtre nécessite votre propre enregistrement d'événement.
Associez les événements destinataire ultérieurs aux identifiants de message enregistrés. L'acceptation par le serveur destinataire n'établit ni le placement en boîte de réception ni la lecture. Le cycle de vie de l'e-mail transactionnel API explique ces résultats distincts.
Que faut-il inclure dans la comparaison des prix ?
Comparez les inclusions publiées pour le forfait, la période de facturation et la devise exacts que vous achèteriez. Séparez le volume d'envoi de l'infrastructure et de la rétention qu'il nécessite.
| Source tarifaire du fournisseur | Inclusions à vérifier pour votre charge de travail |
|---|---|
| Tarifs Bird | Enveloppe d'envoi, dépassement, infrastructure dédiée, contenu conservé et support |
| Tarifs Amazon SES | Usage sortant et entrant, frais de données, IP dédiées et fonctionnalités optionnelles |
| Tarifs SendGrid | Volume du forfait, dépassement, éligibilité aux IP dédiées, rétention d'activité et support |
| Tarifs Mailgun | Volume d'envoi, rétention des journaux et des messages, IP dédiées et support |
| Tarifs Postmark | Enveloppe d'envoi, volume supplémentaire, options de rétention et éligibilité aux IP dédiées |
| Tarifs Resend | Enveloppes d'envoi et de réception, dépassement, rétention et éligibilité aux IP dédiées |
Vérifiez si une enveloppe annoncée compte les requêtes, les messages ou les destinataires. Notez les fonctionnalités exclues à côté du forfait plutôt que de supposer qu'elles sont incluses. Les comparaisons de fournisseurs de Bird présentent les comparaisons produit séparées.
Questions fréquentes
Quelle est la différence entre l'e-mail transactionnel et l'e-mail marketing ?
L'e-mail transactionnel accompagne une transaction ou une activité de compte. L'e-mail marketing fait la promotion d'un produit ou diffuse du contenu par abonnement. La finalité du message détermine la distinction, y compris lorsque les deux sont automatisés.
Un même fournisseur peut-il gérer à la fois l'e-mail transactionnel et l'e-mail marketing ?
Un fournisseur peut servir les deux flux. Vérifiez séparément la politique de catégorie, les identités d'envoi authentifiées et la sélection du pool d'IP. Une infrastructure partagée peut exposer les e-mails opérationnels aux problèmes de réputation liés au trafic marketing.
Ai-je besoin d'une IP dédiée ?
Pas au départ. Les pools d'IP partagées conviennent aux volumes faibles et vous épargnent le préchauffage d'IP. Une IP dédiée prend tout son sens quand votre volume est suffisamment élevé et régulier pour maintenir sa propre réputation. Choisissez un fournisseur qui vous permet de commencer en mutualisé et de passer au dédié quand les chiffres le justifient.
Où se situe Bird
Vous pouvez soumettre via le SMTP ou l'HTTP API. Publiez des templates pour du contenu réutilisable. Abonnez-vous aux événements destinataire. Inspectez les messages individuels dans le journal des e-mails.
Sélectionnez les pools d'IP indépendamment de la catégorie du message. Suivez les conseils de préchauffage lors des changements de volume d'envoi. Utilisez la checklist opérationnelle pour tester la gestion des doublons et la reprise.
Comment faire le choix final ?
- Faites correspondre les interfaces documentées et les contrôles destinataire aux besoins de votre application.
- Confirmez les quotas effectifs pour le trafic de pointe et la reprise de l'arriéré.
- Testez la gestion des échecs en vous appuyant sur les enregistrements de messages et d'événements métier sauvegardés.
- Comparez les inclusions publiées, la rétention et le support pour le forfait que vous achèterez.