Resend

Resend est une API d’e-mail moderne, pensée d’abord pour les développeurs, avec un tableau de bord épuré et une configuration de domaine rapide. Elle convient parfaitement aux nouveaux projets qui veulent un e-mail transactionnel opérationnel en quelques minutes.

Choisissez Resend si vous démarrez un nouveau projet, appréciez les outils simples et envoyez un volume transactionnel faible à moyen. Son offre gratuite est modeste, mais suffit pour la plupart des formulaires de contact. Pour de très gros volumes au prix le plus bas, regardez du côté d’Amazon SES ; pour du marketing et du transactionnel hébergés dans l’UE, Brevo ou Mailjet. Voir la présentation des services d’envoi.

Prérequis

Un compte Resend.
Un domaine vérifié (Domains → Add domain). Sans domaine vérifié, vous ne pouvez envoyer que des e-mails de test depuis onboarding@resend.dev vers l’adresse de votre propre compte – voir Sandbox et limites.
Une clé API avec « Sending access » (et non « Full access ») : API Keys → Create API key → Permission: Sending access, éventuellement limitée à un seul domaine. C’est l’autorisation minimale dont Frontmail a besoin. Tester la connexion reconnaît une clé limitée à l’envoi et l’accepte.

Connexion dans Frontmail

Ouvrez Services d’envoi → Ajouter un service → Resend.
Remplissez les champs :

Champ	Où le trouver	Exemple
Clé API	API Keys (affichée une seule fois)	`re_123abc456def…`
Secret de signature du webhook	Webhooks → votre endpoint → Signing secret	`whsec_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`
E-mails par seconde (max.)	Facultatif ; 2/s par défaut (la limite d’équipe par défaut de Resend)	`2`

Cliquez sur Vérifier et enregistrer.
Le service est enregistré une fois la vérification réussie. Les identifiants sont chiffrés avec le chiffrement d’enveloppe d’AWS KMS.

DNS : SPF, DKIM et DMARC

Resend affiche les enregistrements sur la page du domaine. Pour example.com, ils ressemblent à ceci :

; DKIM
resend._domainkey.example.com.  TXT  "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…"

; SPF + gestion des rebonds sur le sous-domaine « send » (l’expéditeur d’enveloppe)
send.example.com.               MX   10 feedback-smtp.us-east-1.amazonses.com.
send.example.com.               TXT  "v=spf1 include:amazonses.com ~all"

; DMARC (recommandé par Resend, non créé automatiquement)
_dmarc.example.com.             TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Le sous-domaine send porte le SPF : vous n’avez donc pas à toucher à l’enregistrement SPF de votre domaine racine.
L’hôte MX contient la région choisie pour le domaine (us-east-1, eu-west-1, …).
Certains fournisseurs DNS ajoutent automatiquement le domaine – saisissez resend._domainkey et send comme noms d’hôte, et non les noms complets.
Démarrez DMARC en p=none, puis durcissez en p=quarantine / p=reject.

Régions

Lors de l’ajout d’un domaine, Resend vous permet de choisir sa région d’envoi – p. ex. Virginie du Nord (us-east-1), Irlande (eu-west-1), São Paulo (sa-east-1) ou Tokyo (ap-northeast-1). Le point de terminaison de l’API (api.resend.com) est le même pour toutes les régions : il n’y a donc pas de champ de région dans Frontmail, la région est une propriété du domaine. Pour la changer, ajoutez de nouveau le domaine avec la nouvelle région et mettez à jour le DNS.

Sandbox et limites

Sans domaine vérifié, vous ne pouvez envoyer que depuis onboarding@resend.dev et uniquement vers l’adresse e-mail de votre compte Resend. Tout le reste échoue avec 403 – You can only send testing emails to your own email address, que Frontmail traite comme une erreur d’authentification.
Offre gratuite : 3 000 e-mails par mois, 100 par jour, 1 domaine.
Limite de débit : 2 requêtes par seconde et par équipe par défaut ; la valeur par défaut de Frontmail pour Resend est donc de 2/s. Resend peut l’augmenter sur demande.
Le dépassement du quota quotidien ou mensuel renvoie 429 daily_quota_exceeded / monthly_quota_exceeded ; les nouvelles tentatives n’y changent rien avant la réinitialisation du quota, si bien que ces messages se terminent généralement en failed avec le crédit remboursé.

Webhooks (suivi de livraison)

Copiez l’URL du webhook depuis la page du service dans Frontmail (bouton de copie) :
```
https://api.frontmail.dev/webhooks/providers/resend/<token>
```
Dans Resend, ouvrez Webhooks → Add endpoint, collez l’URL et sélectionnez les événements :

Événement Resend	Événement Frontmail
`email.delivered`	`delivered`
`email.bounced` (`Permanent`)	`bounced` – ajoutée à la liste de suppression
`email.bounced` (`Transient` / autre)	enregistré comme rebond temporaire
`email.delivery_delayed`	enregistré sur le message
`email.complained`	`complained` – ajoutée à la liste de suppression
`email.opened`	`opened` (activez le suivi des ouvertures sur le domaine)
`email.clicked`	`clicked` (activez le suivi des clics sur le domaine)

Ouvrez l’endpoint, copiez le Signing secret (whsec_…) et collez-le dans le champ Frontmail Secret de signature du webhook.

Vérification de la signature : Resend envoie ses webhooks via Svix. Frontmail vérifie les en-têtes svix-id, svix-timestamp et svix-signature : HMAC-SHA256 de id.timestamp.body avec votre secret de signature, et refuse les requêtes dont l’horodatage s’écarte de plus de 5 minutes. Sans le secret, les événements ne sont pas vérifiés et sont ignorés.

Frontmail ajoute à chaque e-mail un tag contenant son identifiant de message pour que les événements puissent être associés.

Erreurs courantes

auth – le service est cassé (clé invalide ou supprimée, domaine non vérifié, restrictions du mode test, 401/403). Le service est marqué unhealthy ; le propriétaire reçoit un e-mail et une bannière dans le tableau de bord. Un service de secours défini sur le modèle prend le relais ; sinon le crédit est remboursé et le message attend dans la file d’attente des e-mails retenus en held_service_error, puis part automatiquement une fois le service réparé (revérifié à l’enregistrement et lors de la vérification d’état quotidienne).
permanent – ce message ne peut pas être envoyé (destinataire invalide, erreur de validation 422). Service de secours s’il est configuré, sinon failed et remboursé.
transient – 5xx, 429, délais dépassés. Relancé avec un délai exponentiel ; après la dernière tentative, failed et remboursé.

Réponse de Resend	Catégorie	Que faire
`401 missing_api_key` / `403 invalid_api_key`	auth	Créez une nouvelle clé Sending access et mettez à jour le service.
`403 validation_error` – The example.com domain is not verified	auth	Terminez la vérification du domaine dans Resend, ou corrigez le domaine d’expédition dans le modèle.
`403 validation_error` – You can only send testing emails to your own email address	auth	Vérifiez votre propre domaine ; l’expéditeur de test `resend.dev` n’est destiné qu’à votre propre boîte.
`422 validation_error` – Invalid `to` field	permanent	Voir destinataire invalide.
`422 invalid_attachment` / `422 validation_error` (autres champs)	permanent	Corrigez le modèle ou la pièce jointe ; voir Modèles HTML.
`429 rate_limit_exceeded`	transient	Trop de requêtes par seconde ; gardez E-mails par seconde (max.) à 2 ou demandez davantage à Resend.
`429 daily_quota_exceeded` / `monthly_quota_exceeded`	transient	Quota épuisé ; passez à une offre supérieure.
`500 internal_server_error`, délai dépassé	transient	Panne chez Resend – Frontmail relance.

Liste de contrôle

Domaine vérifié : TXT resend._domainkey + MX et TXT send
Enregistrement DMARC publié (p=none pour commencer)
Clé API avec uniquement Sending access
Tester la connexion réussit
Adresse d’expéditeur du modèle sur le domaine vérifié (pas resend.dev)
Endpoint de webhook avec delivered, bounced, complained (+ opened/clicked)
Secret de signature (whsec_…) copié dans Frontmail