Pourquoi une API d'e-mail bat le SMTP brut

Envoyer directement via SMTP a l'air simple et a de vrais coûts cachés :

• Aucune visibilité sur le fait qu'un e-mail a été livré ou a rebondi.
• Des problèmes de délivrabilité — la réputation de ton IP et la configuration SPF/DKIM/DMARC doivent toutes être correctes ou les e-mails atterrissent silencieusement dans les spams. Même un e-mail correct vers une adresse valide est jeté si le domaine expéditeur n'a pas de confiance établie, et un domaine neuf n'a aucun historique de réputation de toute façon.
• Aucun réessai intégré pour les échecs transitoires.

Resend et les fournisseurs similaires abstraient ça derrière un appel d'API et gèrent l'infrastructure de délivrabilité comme leur produit.

await resend.emails.send({
  from: "[email protected]",
  to: user.email,
  subject: "Confirmez votre e-mail",
  html: renderConfirmationEmail(confirmationCode),
});

La visibilité qu'un envoi brut ne te donne pas compte directement pour un vrai flux : si un e-mail de confirmation rebondit durement parce que l'adresse n'existe pas, l'application peut le savoir et inviter l'utilisateur à la corriger, plutôt que l'utilisateur ne reçoive jamais rien et suppose que l'application est cassée.

L'envoi d'e-mails passe par l'outbox transactionnel plutôt que d'être appelé en ligne dans un handler de requête — si l'API a un échec transitoire, l'outbox réessaie plus tard au lieu que la confirmation soit silencieusement et définitivement perdue à l'instant où un appel a échoué.

Une adresse d'envoi no-reply dédiée est un signal délibéré au destinataire comme aux fournisseurs de mail que cette adresse n'accepte pas de réponses — ça garde les réponses hors d'une boîte non surveillée, et c'est le pattern standard et reconnaissable pour les messages automatisés par opposition à une vraie personne qui écrit.