Présentation des services d’envoi

Un service d’envoi est une connexion entre Frontmail et un fournisseur d’e-mail. Frontmail n’envoie jamais d’e-mails depuis sa propre infrastructure à votre place – il rend votre modèle et transmet le message à votre fournisseur : la délivrabilité, la réputation de l’expéditeur et les tarifs du fournisseur restent sous votre contrôle.

Fournisseurs pris en charge

Fournisseur	Type	Idéal pour	Webhooks de livraison
SMTP (Seznam, Zoho, serveur personnalisé)	`smtp`	Boîtes aux lettres existantes, vos propres serveurs de messagerie	–
Mailgun	`mailgun`	E-mails transactionnels, région UE ou États-Unis	✓
Amazon SES	`ses`	Gros volumes à bas coût, utilisateurs d’AWS	✓ (via SNS)
Postmark	`postmark`	Envoi transactionnel rapide	✓
Mailjet	`mailjet`	Transactionnel basé dans l’UE	✓
Brevo	`brevo`	Basé dans l’UE, offre gratuite généreuse	✓
Resend	`resend`	API pensée pour les développeurs	✓
Gmail (OAuth)	`gmail`	Boîtes personnelles / Google Workspace	–
Outlook / Microsoft 365 (OAuth)	`outlook`	Boîtes Outlook.com et Microsoft 365	–

Les services personnels (boîtes SMTP, Gmail, Outlook) se configurent rapidement et envoient depuis votre vraie boîte aux lettres, mais ont des limites quotidiennes basses et aucun suivi de livraison. Les fournisseurs transactionnels demandent une configuration DNS, mais passent à l’échelle, vous fournissent les événements de livraison, de rebond et d’ouverture, et offrent une meilleure délivrabilité.

Ajouter un service

Les propriétaires, administrateurs et développeurs gèrent les services dans Services d’envoi.

Cliquez sur Ajouter un service et choisissez le fournisseur.
Pour Gmail et Outlook, cliquez sur Connecter Gmail / Connecter Outlook / Microsoft 365 et autorisez l’accès dans la fenêtre du fournisseur. Pour les autres, saisissez les identifiants et cliquez sur Vérifier et enregistrer – Frontmail les vérifie auprès du fournisseur (sans envoyer d’e-mail) avant de les enregistrer. Enregistrer sans vérifier est disponible si vous préférez vérifier plus tard. Les identifiants sont chiffrés avec AWS KMS (chiffrement d’enveloppe, AES-256-GCM) et ne sont plus jamais affichés – vous pouvez seulement les remplacer.
Sur la page du service, Tester la connexion relance la même vérification à tout moment.
Configurez éventuellement l’URL du webhook affichée sur la page du service (voir plus bas).
Votre premier service devient automatiquement le service par défaut ; utilisez Définir par défaut pour en changer. Les modèles sans service explicite – et les appels API sans service_id – l’utilisent. Supprimer un service utilisé par des modèles les fait basculer sur le service par défaut.

Expéditeur par défaut (From)

Chaque service peut avoir une Adresse d’expéditeur par défaut et un Nom d’expéditeur par défaut (dans le formulaire d’ajout et sur la page du service, sous Paramètres). L’adresse d’expéditeur de chaque e-mail est déterminée dans cet ordre :

E-mail de l’expéditeur / Nom de l’expéditeur dans les paramètres du modèle (peuvent contenir des paramètres),
l’adresse / le nom d’expéditeur par défaut du service,
pour Gmail et Outlook, le compte connecté ; pour SMTP, le nom d’utilisateur s’il s’agit d’une adresse e-mail.

Tant que l’e-mail de l’expéditeur du modèle est vide, l’éditeur de modèles indique quel expéditeur sera utilisé. Modifier uniquement l’expéditeur par défaut ne relance pas le test de connexion. Si aucune étape ne fournit d’adresse, les envois de test échouent avec sender_not_configured et les envois réels échouent définitivement (le crédit est remboursé).

Service de secours (failover)

Chaque modèle a un service principal et un service de secours facultatif, tous deux choisis dans l’éditeur de modèles sous Paramètres → Envoi (Service et Service de secours). L’expéditeur essaie d’abord le service principal. S’il échoue avec une erreur d’authentification ou une erreur permanente, le même message est immédiatement envoyé via le service de secours. La chronologie du message affiche un événement failover, et l’Historique indique quel service l’a réellement envoyé.

Les erreurs temporaires (délais d’attente dépassés, limitation de débit, 5xx) ne déclenchent pas de basculement – elles sont d’abord relancées sur le service principal, car elles se résolvent généralement d’elles-mêmes.

Gestion des erreurs du fournisseur

Frontmail classe chaque erreur du fournisseur dans l’une de trois catégories :

Catégorie	Exemples	Ce que fait Frontmail
Authentification	clé API invalide ou révoquée, jeton OAuth expiré (Google `invalid_grant`), SMTP `535`	Marque le service comme défaillant (En panne), envoie un e-mail au propriétaire et aux administrateurs, affiche une bannière dans le tableau de bord. Envoie via le service de secours s’il existe ; sinon rembourse le crédit et conserve le message en `held_service_error`.
Permanente	destinataire invalide, expéditeur ou domaine non vérifié, message refusé par une règle	Essaie le service de secours s’il existe ; sinon le message passe en `failed` et le crédit est remboursé. Les rebonds définitifs (hard bounces) ajoutent l’adresse à la liste de suppression.
Temporaire	délai dépassé, connexion réinitialisée, `5xx` du fournisseur, limitation `429`, SMTP `421`/`450`/`451`	Relance avec un délai exponentiel (en respectant les limites de débit du fournisseur). Si toutes les tentatives échouent, le message passe en `failed` et le crédit est remboursé.

Chaque guide de fournisseur liste ses erreurs courantes et leur classement.

Messages retenus à cause d’une erreur du service

Les messages en held_service_error attendent dans la file d’attente des e-mails retenus avec les messages retenus faute de crédits, avec le motif service. Dès que le service fonctionne de nouveau – après la mise à jour des identifiants, la reconnexion OAuth ou une vérification d’état réussie – ils sont libérés automatiquement : un crédit est de nouveau réservé et ils sont envoyés dans l’ordre d’origine. Vous pouvez aussi les libérer ou les supprimer manuellement. Ils expirent comme les autres messages retenus (Free 3 jours, forfaits payants 14 jours) et vous recevez un e-mail avant que cela n’arrive.

Vérifications d’état

Chaque jour : Frontmail vérifie chaque service (la même vérification que Tester la connexion).
Immédiatement après une erreur d’authentification pendant un envoi.
À l’enregistrement : chaque fois que vous modifiez les identifiants ou reconnectez OAuth.

Un service est healthy (Opérationnel), unhealthy (En panne) ou unknown (Non vérifié). Quand un service tombe en panne, les propriétaires et les administrateurs reçoivent un e-mail et le tableau de bord affiche la bannière Un service d’envoi ne fonctionne pas avec un bouton Réparer le service jusqu’à son rétablissement ; vous recevez un autre e-mail quand il fonctionne de nouveau et que ses messages retenus ont été libérés.

Webhooks de livraison

Les fournisseurs transactionnels peuvent indiquer ce qui s’est passé après avoir accepté le message. Copiez l’URL du webhook depuis la page du service (qui liste aussi les événements à activer) dans la console de votre fournisseur :

https://api.frontmail.dev/webhooks/providers/<type>/<token>

<type> est le type de fournisseur du tableau ci-dessus (p. ex. mailgun), <token> est un jeton aléatoire propre au service – traitez l’URL entière comme un secret. Frontmail vérifie en outre la signature du fournisseur lorsque celui-ci la prend en charge.

Les événements sont convertis en statuts de message et en statistiques :

Événement du fournisseur	Frontmail
delivered	statut `delivered`
hard bounce	statut `bounced` + adresse ajoutée à la liste de suppression
soft bounce	événement uniquement (le fournisseur réessaie)
plainte pour spam	statut `complained` + adresse ajoutée à la liste de suppression
ouverture / clic	événements `opened` / `clicked` dans la chronologie et les statistiques

Sans webhooks, un message s’arrête au statut sent – ce qui signifie que le fournisseur l’a accepté.