Que doit évaluer une équipe produit avant de choisir un service SMTP gratuit ?

Définissez « gratuit » à partir du contrat en vigueur

Le mot gratuit peut désigner un quota permanent, un essai limité dans le temps, des crédits de bienvenue, des tests limités à des destinataires vérifiés ou une formule payante avec des crédits temporaires. Lisez la tarification et les conditions actuelles du fournisseur le jour de l’évaluation. Consignez la devise, la région, les taxes, l’exigence d’une carte de paiement, l’expiration de l’essai, les unités incluses, le comportement en cas de dépassement, le comportement en cas de suspension et les fonctionnalités qui disparaissent lors d’un passage à une formule inférieure. Ne vous fiez pas aux extraits de résultats de recherche, aux anciens comparatifs, aux captures d’écran ou à une conversation commerciale sans référence contractuelle durable. AWS SES, Resend et Mailgun publient sur leurs pages officielles des modèles tarifaires et des fonctionnalités incluses différents ; aucun ne doit être considéré comme interchangeable. Associez à la décision l’URL de la page examinée et la date de capture, et planifiez une nouvelle vérification avant le lancement, car les offres des fournisseurs peuvent changer. Un coût d’acquisition nul ne supprime ni les coûts d’ingénierie, de DNS, de surveillance, de confidentialité et d’incidents, ni le coût de migration.

Modélisez la charge en unités facturables et opérationnelles

Estimez les messages, destinataires, pièces jointes, octets, requêtes API ou SMTP, livraisons d’événements, e-mails entrants, contenus stockés, la durée de conservation des logs, les domaines, les membres de l’équipe et les environnements. Un message à plusieurs destinataires peut consommer le quota différemment d’une transaction à destinataire unique. Les nouvelles tentatives, le trafic de test, le warm-up, les bounces et les rejeux de webhooks peuvent ajouter du volume. Calculez la demande moyenne, à la minute de pointe, à l’heure de pointe, quotidienne, mensuelle et saisonnière, avec une marge pour la croissance et les incidents. Maintenez les contrôles de débit applicatifs en dessous des plafonds du fournisseur et protégez les tenants les uns des autres. Demandez ce qui se passe lorsqu’il ne reste plus aucune unité : rejet franc, report, facturation automatique, fonctionnalités dégradées ou perte silencieuse de logs. Une offre gratuite qui couvre les appels d’envoi mais exclut un historique d’événements exploitable, le support ou l’export des suppressions peut coûter plus cher en exploitation qu’une petite formule payante. Validez les compteurs observés sur le compte avec du trafic contrôlé avant la production.

Exigez une soumission SMTP sécurisée

Un service SMTP de production doit documenter la soumission protégée, les ports pris en charge, le comportement TLS, les mécanismes d’authentification, les attentes en matière de certificats, la portée des identifiants et leur rotation. Privilégiez le TLS obligatoire et échouez de manière sûre en cas d’absence de STARTTLS, d’échec de certificat, de nom d’hôte non concordant ou de protocole non pris en charge. Stockez les identifiants dans un système de gestion de secrets, jamais dans le code du navigateur, les applications mobiles, le code source, les images, les logs, les URL, les outils d’analyse, les tickets ou les prompts. Séparez les droits de production, de test, propres à chaque tenant et d’administration. Vérifiez si l’offre gratuite restreint les identifiants, les IP sources, les domaines, les régions ou les connexions simultanées. La RFC 8314 recommande d’abandonner les protocoles en clair au profit de TLS pour la soumission et l’accès, tandis que la RFC 4954 définit l’authentification SMTP comme une extension de protocole, et non comme une autorisation produit. L’application doit toujours autoriser l’événement métier, l’expéditeur, le tenant, le destinataire, le modèle et la catégorie de message avant d’ouvrir la connexion SMTP.

Vérifiez l’identité de l’expéditeur et la propriété DNS

Exigez un domaine From appartenant à l’organisation et un processus documenté de vérification de domaine. Inventoriez le SMTP MAIL FROM ou return path, le From visible, le domaine d= et le sélecteur DKIM, les IP d’envoi et la gestion des réponses. Publiez une seule politique SPF valide qui inclut le chemin réel, configurez la signature DKIM avec des clés protégées et évaluez l’alignement DMARC avec le domaine From visible. La vérification par le fournisseur prouve qu’un contrôle de configuration a réussi ; elle ne prouve ni le consentement des destinataires, ni un routage de production correct, ni la réputation, ni l’arrivée en boîte de réception. Identifiez quels enregistrements DNS appartiennent au fournisseur et lesquels restent dans la zone faisant autorité de l’organisation. Conservez les valeurs précédentes et les étapes de retour arrière. Évitez un domaine From appartenant uniquement au fournisseur pour votre identité de production, car cela réduit la portabilité et peut rendre l’alignement DMARC ou la continuité de la marque dépendants du fournisseur. Testez les messages bruts reçus pour chaque flux et chaque environnement.

Exigez des résultats exploitables par destinataire

Le service doit distinguer l’acceptation SMTP ou API, le refus par destinataire, le report temporaire, l’échec définitif, le bounce ultérieur, la plainte, la désinscription et la suppression côté fournisseur. Vérifiez comment ces résultats sont transmis, authentifiés, réessayés, ordonnés, conservés et exportés avec l’offre gratuite. Authentifiez les webhooks avant de les analyser, appliquez des contrôles de fraîcheur et de rejeu, enregistrez durablement les événements avant d’en accuser réception et associez-les aux tentatives appartenant à l’application. Stockez séparément les ensembles de destinataires acceptés et refusés. Réessayez les échecs temporaires éligibles avec un backoff borné, du jitter, un plafond de tentatives et une limite d’âge dans la file. Arrêtez les envois automatiques après un échec définitif d’adresse, une plainte ou une désinscription, dans la portée applicable. Un tableau de bord sans preuves exportables crée une dépendance opérationnelle. L’événement « délivré » d’un fournisseur décrit souvent l’acceptation par le serveur de destination, pas le dossier final de la boîte aux lettres. Les ouvertures et les clics relèvent de l’instrumentation de l’engagement et peuvent être faussés par les technologies de protection de la vie privée.

Examinez les limites qui n’apparaissent pas dans la tarification

Les pages de tarifs contiennent rarement l’intégralité du contrat opérationnel. Consultez la documentation actuelle sur le nombre de destinataires, la taille des messages, la taille des pièces jointes, le débit de connexion, les sessions simultanées, le débit de l’API, les domaines DNS, les modèles, les tentatives de webhook, la conservation des événements, la capacité de la liste de suppression et les restrictions de destinataires pendant l’essai. Déterminez si le support, les journaux d’audit, les IP dédiées, le traitement régional, les routes d’e-mails entrants ou les fonctionnalités de conformité nécessitent une formule payante. Testez le compte réel, car les comptes nouveaux ou en essai peuvent avoir des limites plus basses ou faire l’objet d’une revue manuelle. Consignez chaque limite avec une URL source et une date d’observation. Ne dimensionnez pas exactement au maximum ; gardez une marge pour les changements du fournisseur, les nouvelles tentatives et la reprise après incident. Si une application peut dépasser silencieusement une limite via des tableaux de destinataires ou des pièces jointes fournis par l’utilisateur, imposez d’abord une limite produit plus stricte. Considérez les limites non documentées ou floues comme un risque, et non comme une capacité illimitée.

Évaluez la confidentialité, la sécurité et les contrôles anti-abus

Cartographiez le contenu des messages, les données des destinataires, les en-têtes, les payloads d’événements, les adresses IP, les logs, les accès du support, les sauvegardes et les sous-traitants selon les régions. Réduisez au minimum les métadonnées personnalisées et évitez les secrets ou les données personnelles superflues dans les tags et les en-têtes. Vérifiez le comportement de conservation et de suppression pour les comptes gratuits, y compris après résiliation. Vérifiez l’isolation entre tenants, le contrôle d’accès par rôle, la MFA, l’historique d’audit, la rotation des identifiants, la signature des webhooks, l’autorisation des suppressions et la notification des incidents. Testez l’injection d’en-têtes, la sélection arbitraire de l’expéditeur, les destinataires en nombre excessif, les abus de pièces jointes, la consultation d’événements inter-tenant et le rejeu. Les offres gratuites sont des cibles fréquentes d’abus : les fournisseurs peuvent donc imposer des revues automatisées ou une suspension rapide, et le produit a besoin d’une file d’attente durable et d’un moyen sûr de mise en pause. Ne contournez jamais les contrôles anti-abus en faisant tourner des comptes, des domaines, des identifiants ou des IP. Conservez l’état du consentement et des suppressions en dehors du fournisseur, afin qu’une suspension ou une migration ne puisse pas faire disparaître les protections des destinataires.

Calculez le coût de sortie avant d’envoyer

Placez les champs propres au fournisseur derrière un adaptateur unique et gardez le modèle d’événements de l’application indépendant. Inventoriez l’hôte et l’authentification SMTP, les payloads d’API, les modèles, les domaines d’expéditeur, les return paths, les sélecteurs DKIM, les webhooks, les noms d’événements, les identifiants de message, les tags, les suppressions, les routes d’e-mails entrants et les logs. Exigez des exports des suppressions et de l’historique opérationnel dans des formats que le produit peut valider. Une migration doit préserver les clés d’événements métier, l’historique des tentatives, le consentement, la sécurité des destinataires et la propriété de l’expéditeur. Testez un second transport avec des identités contrôlées, mais ne le configurez pas comme contournement automatique en cas d’échec définitif lié au destinataire ou à la politique. Estimez les fenêtres de changement DNS, la rotation des identifiants, la conversion des modèles, le double traitement des webhooks, la prévention des doublons et la conservation des anciens événements. L’offre gratuite la moins chère peut être le mauvais choix lorsque la quitter implique de perdre des preuves, de changer d’identité d’expéditeur ou de reconstruire les contrôles de sécurité sous la pression d’un incident.

Menez une épreuve notée avant la production

Créez une matrice de test représentative : négociation TLS et échec de certificat, authentification et rotation, expéditeurs vérifiés et non autorisés, contenu texte simple et multipart, Unicode, pièces jointes, destinataires partiellement acceptés, réponses transitoires et définitives, timeout après DATA, bounces, plaintes, désinscriptions, rejeu de webhook, événements dans le désordre, épuisement du quota, expiration de la formule, export et fermeture du compte. Utilisez des destinataires contrôlés dédiés et jamais de vraies listes de clients. Notez séparément la sécurité, l’exactitude, les preuves, la capacité, la confidentialité, le support, la portabilité et le coût total. Bloquez le lancement en cas d’absence de vérification TLS, de secrets partagés sans rotation, d’exposition inter-tenant, d’absence de gestion des échecs définitifs, d’export des suppressions indisponible, de dépassement silencieux ou de conservation floue. Relancez l’épreuve lorsqu’une formule tarifaire, un chemin d’envoi, un domaine ou un contrat fournisseur change. Une formule gratuite peut convenir à une charge bornée et à faible risque uniquement lorsque ses contrôles et son plan de sortie atteignent le niveau attendu d’une dépendance payante.

Évaluez les formules actuelles de SendHQ

SendHQ ne propose aucune formule gratuite. Les nouveaux espaces de travail bénéficient d’un essai d’intégration contrôlé de 100 livraisons vers l’e-mail du compte ou une adresse de simulateur AWS SES. Pour connaître les prix, quotas et capacités actuels des formules payantes, consultez la page de tarification de SendHQ.

Questions fréquentes

Sources

• Tarifs d’Amazon Simple Email Service — Amazon Web Services
• Tarifs de Resend — Resend
• Tarifs de Mailgun — Mailgun
• RFC 8314 : Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access — RFC Editor
• RFC 4954 : SMTP Service Extension for Authentication — RFC Editor
• RFC 5321 : Simple Mail Transfer Protocol — RFC Editor
• RFC 7489 : Domain-based Message Authentication, Reporting, and Conformance — RFC Editor