Corriger les e-mails Resend qui partent dans les spams

Resend ne livre à un vrai destinataire qu’une fois un domaine vérifié : le piège du domaine d’envoi partagé qui attrape les utilisateurs de Klaviyo et de Mailchimp n’existe donc pas ici. Ce qui casse est plus étroit et plus facile à manquer : les enregistrements que Resend place sur le sous-domaine d’envoi, une politique DMARC que personne ne crée à votre place, une clé DKIM que vous ne pouvez pas renforcer, et un domaine dont tout l’historique d’envoi commence le jour de votre mise en production. Ce guide couvre le DNS que Resend génère réellement, le piège du bac à sable resend.dev, les IP dédiées face aux IP partagées, et la façon de tester un envoi réel avec Unspam.

Lancer un test de spam gratuit Comment tester vos envois

Pourquoi les e-mails Resend finissent dans les spams.

Personne n’a publié d’enregistrement DMARC, parce que Resend ne le fait pas

Vérifier un domaine écrit SPF et DKIM à votre place, puis s’arrête là. La page de dépannage antispam de Resend indique que DMARC n’est pas configuré automatiquement mais est fortement recommandé, et Deliverability Insights comporte un contrôle distinct sur la validité de l’enregistrement DMARC, qui échoue en silence sur chaque message. Depuis les règles pour expéditeurs en volume de Google et Yahoo, un domaine d’expéditeur sans politique DMARC est à lui seul un signal de filtrage. Publiez v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; sur _dmarc.votredomaine.com avant de regarder quoi que ce soit d’autre.

Votre premier envoi en production est le tout premier envoi de votre domaine

Chaque message envoyé pendant le développement est parti de resend.dev, qui porte la réputation de Resend et non la vôtre. Le jour où vous basculez l’adresse d’expéditeur vers votre propre domaine, Gmail voit un expéditeur entièrement nouveau, au volume que produit votre lancement. Le plan de montée en charge de Resend démarre à 150 e-mails maximum le premier jour et atteint 2 000 e-mails maximum au septième, et son calculateur étire la rampe jusqu’à 42 jours pour des objectifs plus élevés. Un lancement qui envoie plusieurs milliers de confirmations d’inscription depuis un domaine vérifié le matin même est exactement le scénario que ce plan existe pour éviter.

DKIM est en 1024 bits et vous ne pouvez pas le changer

Resend signe le courrier sortant avec des clés DKIM de 1024 bits et déclare clairement ne pas prendre en charge les clés de 2048 bits. C’est le plancher que les serveurs de réception restent tenus de valider : les signatures se vérifient donc normalement, mais il ne vous reste ni marge ni moyen de passer à une clé plus solide depuis le produit. Cela veut dire aussi que DKIM n’est pas un levier disponible quand un filtre d’entreprise comme Mimecast ou Proofpoint vous note à la baisse. Mettez vos efforts là où vous avez la main : une politique DMARC publiée, un sous-domaine avec son propre historique, et un contenu qui n’a pas besoin d’excuses.

Les campagnes et les réinitialisations de mot de passe partent du même domaine vérifié

Resend sépare l’envoi entre l’API Emails pour le transactionnel et Broadcasts pour le marketing, mais les deux partent du domaine que vous avez vérifié. Une newsletter qui récolte des plaintes entraîne vos réinitialisations de mot de passe avec elle, car pour un filtre il s’agit du même expéditeur. La recommandation de Resend est d’envoyer depuis un sous-domaine, pour que les fournisseurs de messagerie disposent d’une indication claire sur l’endroit où classer votre courrier. Vérifiez-en deux, par exemple notifications.votredomaine.com pour l’API et updates.votredomaine.com pour Broadcasts, et gardez-les séparés dès le premier jour.

Votre nombre de plaintes affiche presque zéro et ne veut rien dire

La documentation de Resend sur les suppressions indique que tous les fournisseurs de messagerie ne renvoient pas d’événement complained, en particulier Gmail et Google Workspace. Le chiffre que vous suivez dans le tableau de bord laisse donc de côté le fournisseur qui décide de l’essentiel de votre placement. Les suppressions valent en outre pour toute l’équipe : une adresse supprimée après un rebond marketing est ignorée sur tous vos domaines et sous-domaines, transactionnel compris, si bien qu’une réinitialisation de mot de passe peut ne jamais partir sans que rien ne le signale. Lisez votre vrai taux de spam Gmail dans Google Postmaster Tools et traitez le chiffre de Resend comme un plancher.

Le modèle pointe ailleurs que vers votre domaine d’envoi, ou pèse trop lourd

Deliverability Insights de Resend vérifie que les liens d’un message pointent vers le domaine depuis lequel il est envoyé, et un modèle dont tous les boutons aboutissent à un site marketing, à un raccourcisseur de liens ou à un traceur tiers échoue à ce contrôle à chaque envoi. Utilisez un sous-domaine de votre domaine d’envoi pour le suivi des clics plutôt qu’un raccourcisseur, et gardez au moins l’appel à l’action principal sur votre propre domaine. La taille compte aussi : Resend rappelle que Gmail limite chaque message à 102 Ko et qu’au-delà le reste du contenu est tronqué et masqué derrière un lien pour afficher le message entier, ce qui place votre lien de désabonnement à un clic supplémentaire.

Comment Resend authentifie vos e-mails.

Resend se distingue des autres plateformes d’envoi : tant qu’un domaine n’est pas vérifié, il n’envoie à personne d’autre qu’à l’adresse de votre propre compte, et la vérification elle-même écrit SPF et DKIM. Cela supprime le défaut d’alignement lié au domaine partagé dont souffrent d’autres plateformes et ne laisse que deux choses à réussir : le sous-domaine d’envoi et DMARC.

enregistrement	par défaut	le problème	la solution
SPF	La vérification du domaine génère un enregistrement TXT sur le sous-domaine send du domaine que vous avez ajouté, avec la valeur v=spf1 include:amazonses.com ~all. L’include et l’hôte de rebonds pointent tous deux vers amazonses.com : SPF authentifie donc l’infrastructure d’envoi d’Amazon.	Comme l’enregistrement vit sur send.votredomaine.com, SPF authentifie le sous-domaine et non votre domaine d’expéditeur. L’alignement souple, la valeur par défaut de DMARC, le compte malgré tout comme aligné. Ceux qui l’ignorent ajoutent un include Resend à leur enregistrement SPF racine, ce qui ne fait strictement rien, ou passent aspf=s et laissent DMARC reposer sur DKIM seul.	Publiez l’enregistrement exactement tel qu’il est généré, avec send comme seul hôte, puisque votre hébergeur DNS ajoute le domaine. Laissez votre enregistrement SPF racine intact, y compris votre include Google Workspace ou Microsoft 365, et ne mettez pas aspf=s.
DKIM	La vérification génère un enregistrement TXT sur resend._domainkey du domaine ajouté, contenant une clé publique de 1024 bits. Resend signe avec des clés de 1024 bits et ne prend pas en charge 2048 bits.	La valeur est assez longue pour que les interfaces DNS la tronquent, la découpent en plusieurs chaînes entre guillemets ou ajoutent leurs propres guillemets. Quand cela arrive, le domaine ne quitte jamais l’état pending et vous ne pouvez pas envoyer depuis lui, ce que les développeurs prennent en général pour une panne de Resend. Aucun chemin vers une clé plus solide n’existe dans le produit.	Copiez-collez la valeur au lieu de la retaper, utilisez resend._domainkey comme hôte sans ajouter le domaine, et réglez les enregistrements Cloudflare sur DNS only plutôt que sur proxied. Confirmez-la publiquement avec dns.email ou nslookup, puis vérifiez la valeur d= sur un vrai message : elle doit être votre propre domaine.
DMARC	Resend ne crée aucun enregistrement DMARC. Votre domaine se vérifie, envoie et se déclare en bonne santé sans qu’aucune politique ne soit publiée nulle part.	La liste de contrôle de Resend place l’authentification en premier et désigne DMARC comme le seul enregistrement qu’il ne crée pas, et Deliverability Insights signale un enregistrement absent ou invalide sur chaque message. Passer directement à une politique d’application est une erreur en soi : quarantine ou reject avant que tous les expéditeurs légitimes soient alignés et vous filtrez vos propres factures et le courrier de votre support.	Commencez par v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; sur _dmarc.votredomaine.com. Lisez les rapports, Resend maintient un analyseur DMARC gratuit et open source sur checkdmarc.email, confirmez que tous les expéditeurs légitimes sont alignés, puis passez à p=quarantine et p=reject.
Return-Path subdomain	Resend utilise le sous-domaine send de votre domaine vérifié pour le Return-Path, et c’est pourquoi l’enregistrement TXT de SPF et l’enregistrement MX de rebonds se trouvent tous deux sur send.votredomaine.com. La valeur MX dépend de la région, feedback-smtp.us-east-1.amazonses.com pour un domaine créé en Virginie du Nord et un autre hôte pour l’Irlande, São Paulo ou Tokyo : copiez donc la valeur exacte depuis l’onglet Records du domaine.	Certains clients de messagerie montrent le Return-Path aux destinataires : une valeur inventée est donc un problème de crédibilité, et Resend met spécifiquement en garde contre des valeurs comme testing. Publier cet enregistrement MX sur le domaine racine au lieu du sous-domaine est bien pire : cela prend le contrôle du courrier entrant de tout le domaine.	Gardez la valeur par défaut. Si vous devez la changer, passez custom_return_path à la création ou à la mise à jour du domaine : 63 caractères au maximum, uniquement des lettres, des chiffres et des traits d’union, commençant par une lettre et finissant par une lettre ou un chiffre.

Une fois ces enregistrements mis à jour, vérifiez qu’ils passent avec les outils gratuits d’Unspam : SPF checker, DKIM checker et DMARC checker.

Comment tester une campagne Resend avec Unspam.

Le tableau de bord de Resend vous dit ce qui est sorti de l’API et s’arrête à Delivered, ce qui, selon sa propre définition, signifie seulement que le serveur de réception a répondu 250 OK. Ensuite, le message peut aller en boîte de réception, dans les spams, dans une quarantaine d’entreprise ou nulle part, et Resend ne voit jamais lequel. La seule façon de le savoir est d’envoyer un vrai message par votre propre chemin de code vers des boîtes-témoins.

01
Récupérez votre adresse-témoin Unspam et votre Test ID

Lancez un test antispam gratuit ou un test de placement en boîte de réception dans Unspam et copiez l’adresse-témoin générée. Un test de placement fournit aussi un Test ID. Collez-le dans l’objet ou dans le corps avant d’envoyer, sinon le message atteint les boîtes-témoins sans jamais être rattaché à votre test. Les tests de placement livrent vers des boîtes-témoins chez Gmail, Outlook, Yahoo et cinq autres fournisseurs, et rapportent où chaque copie a atterri.
02
Envoyez depuis votre domaine vérifié, pas depuis resend.dev

Mettez dans from une adresse du domaine que vous avez vérifié, par exemple notifications@notifications.votredomaine.com. Laisser la valeur du guide de démarrage renvoie un 403 vous indiquant que vous ne pouvez envoyer des e-mails de test qu’à votre propre adresse, et un domaine d’expéditeur qui ne correspond pas exactement au domaine vérifié, sous-domaine compris, renvoie un 403 pour non-correspondance de domaine. La boîte elle-même n’a pas besoin d’exister, même si Resend recommande des adresses capables de recevoir des réponses.
03
Déclenchez-le par le vrai chemin de code

Appelez la même route d’API, le même Broadcast ou la même Automation que reçoivent vos clients, avec le même modèle, les mêmes liens et les mêmes en-têtes personnalisés. Un envoi ponctuel tapé à la main saute vos en-têtes List-Unsubscribe, votre balisage React Email rendu et la réécriture des liens si le suivi des clics est activé : il ne teste donc pas ce que vous expédiez vraiment.
04
Donnez à Unspam des identifiants SMTP pour les envois répétés

Pour des tests de placement programmés, donnez à Unspam les paramètres SMTP de Resend : hôte smtp.resend.com, port 587, nom d’utilisateur resend, mot de passe une clé d’API Resend. Créez une clé dédiée avec la permission sending_access et une restriction domain_id pour qu’elle ne puisse rien faire d’autre qu’envoyer depuis ce seul domaine, et copiez la valeur immédiatement, car Resend ne réaffiche jamais une clé. Unspam n’utilise ces identifiants que pour envoyer ses propres messages de test ; il ne lit ni vos contacts, ni vos journaux, ni votre tableau de bord Resend.
05
Lisez le rapport et corrigez ce qu’il signale

Unspam rapporte le score antispam, les résultats SPF, DKIM et DMARC du message réel, le dossier choisi par chaque fournisseur-témoin, les aperçus par client de messagerie et une heatmap. Confirmez que la valeur d= de DKIM est votre propre domaine et que DMARC passe au lieu d’être simplement absent. Corrigez ce qui est signalé, puis relancez le même envoi pour confirmer que le changement a déplacé le placement.

Le même test affiche votre campagne dans plus de 50 clients de messagerie réels, dont Gmail, Outlook, Apple Mail, iPhone et Android, chacun en mode clair et en mode sombre, grâce aux prévisualisations dans les clients de messagerie, pour confirmer le placement et le rendu en une seule passe.

Les fonctions Resend qui influencent discrètement la livraison.

L’enregistrement MX de Resend sur le domaine racine détourne votre courrier entrant

Les enregistrements d’envoi de Resend vont sur le sous-domaine send, et Resend souligne qu’un enregistrement MX n’affecte que le sous-domaine sur lequel il se trouve : celui posé sur send.votredomaine.com laisse donc tranquille votre boîte Google Workspace ou Microsoft 365. Déplacez cette valeur à la racine et vous redirigez le courrier de nimporte-qui@votredomaine.com vers l’hôte de rebonds de Resend au lieu de votre fournisseur de messagerie. Resend publie le même avertissement à propos de sa fonction de réception : ajouter un enregistrement MX de réception à l’apex achemine tous les messages du domaine vers Resend plutôt que vers votre fournisseur précédent, et c’est pourquoi il vous demande de placer la réception sur son propre sous-domaine (par exemple subdomain.votredomaine.com). Gardez chaque enregistrement Resend sur l’hôte exact affiché dans l’onglet Records du domaine et ne changez rien à l’apex.

L’hôte de rebonds dépend de la région, et les interfaces DNS le cassent

Un domaine est créé en Virginie du Nord (us-east-1), en Irlande (eu-west-1), à São Paulo (sa-east-1) ou à Tokyo (ap-northeast-1), et la valeur MX doit correspondre à cette région. Deux défaillances dominent : un enregistrement pointant vers une région différente de celle où le domaine a été créé, et un hébergeur DNS qui ajoute votre domaine, si bien que la valeur devient feedback-smtp.eu-west-1.amazonses.com.example.com. Ajoutez un point final pour marquer la valeur comme pleinement qualifiée. Changer de région n’est pas une modification : cela veut dire supprimer le domaine, l’ajouter de nouveau et republier tous les enregistrements.

Delivered ne veut pas dire boîte de réception

Resend marque un e-mail comme Delivered dès que le serveur du destinataire l’accepte avec une réponse 250 OK. Tout ce qui suit, boîte de réception, dossier spam, quarantaine d’entreprise ou rejet silencieux, se produit hors du champ de vision de Resend. Un tableau de bord rempli de lignes vertes Delivered est parfaitement compatible avec le fait que chacun de ces messages dorme dans les indésirables, et c’est pourquoi des équipes courent après ce problème pendant des semaines avant de tester le placement.

L’API Emails n’ajoute aucun en-tête List-Unsubscribe à votre place

Broadcasts et Automations gèrent le parcours de désabonnement automatiquement quand vous incluez un lien de désabonnement. Les envois transactionnels via l’API Emails ne le font pas, parce que Resend ne gère pas de listes de contacts pour eux : vous passez donc les en-têtes vous-même, List-Unsubscribe avec votre URL entre chevrons et List-Unsubscribe-Post avec la valeur List-Unsubscribe=One-Click. Votre point de terminaison doit répondre en GET comme en POST, et traiter la demande sous 48 heures.

Ce que rencontrent les expéditeurs Resend sur le terrain.

Les problèmes de délivrabilité que les expéditeurs Resend rencontrent le plus souvent, chacun avec la solution qui le règle.

Le domaine affiche Verified dans Resend, SPF et DKIM passent tous les deux, et Gmail met quand même tout dans les spams.

La vérification ne produit que SPF et DKIM. Elle ne publie pas DMARC, et Resend indique que DMARC n’est pas configuré automatiquement. Passer SPF et DKIM sans aucune politique DMARC sur le domaine d’expéditeur est exactement ce que visent les exigences de Google et Yahoo pour les expéditeurs en volume, et Deliverability Insights de Resend le signale sur chaque message que vous ouvrez.

La solution Publiez v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; sur _dmarc.votredomaine.com, puis ouvrez le panneau Insights sur un envoi réel et réglez tous les contrôles restants, en particulier la correspondance des URL des liens et l’expéditeur sans réponse.

J’ai sans arrêt un 403 domain is not verified en envoyant depuis localhost, même vers ma propre adresse.

Deux règles différentes se télescopent ici. Le domaine d’expéditeur doit correspondre exactement au domaine vérifié : un domaine vérifié comme sending.example.com rejette donc une requête qui dit example.com. Par ailleurs, si from vaut encore onboarding@resend.dev, le seul destinataire autorisé est l’adresse de votre compte Resend, si bien qu’une faute de frappe dans votre propre adresse produit ce qui ressemble à la même erreur.

La solution Ouvrez la page Domains et copiez la chaîne du domaine vérifié caractère par caractère dans from, puis vérifiez que la clé d’API n’est pas restreinte à un autre domaine par domain_id. Pendant le développement, envoyez à delivered@resend.dev, bounced@resend.dev, complained@resend.dev ou suppressed@resend.dev plutôt qu’à votre propre boîte.

J’ai ajouté tous les enregistrements dans Cloudflare il y a deux jours et le domaine est toujours en pending. Rien ne change quand je clique sur vérifier.

Trois causes expliquent la quasi-totalité de ces cas. L’hébergeur DNS a ajouté votre domaine à la valeur MX, produisant feedback-smtp.us-east-1.amazonses.com.example.com. Les enregistrements sont partis chez le bureau d’enregistrement alors que les serveurs de noms pointent ailleurs : rien de ce que vous avez publié n’est donc actif. Ou la région du MX ne correspond pas à celle où le domaine a été créé, parfois avec deux régions publiées en même temps.

La solution Interrogez les enregistrements publiquement avec dns.email ou nslookup plutôt que de faire confiance à l’interface DNS. Ajoutez un point final à la valeur MX pour la marquer pleinement qualifiée, supprimez les lignes de région en double, réglez les enregistrements sur DNS only plutôt que sur proxied, puis utilisez Restart verification.

Après avoir pointé l’enregistrement MX vers Resend, notre boîte Google Workspace n’a plus rien reçu.

L’enregistrement MX que Resend génère va sur le sous-domaine send. Publié à la racine, il devient le serveur de messagerie de tout le domaine : chaque message adressé à nimporte-qui@votredomaine.com part donc vers Resend et non plus vers Google Workspace ou Microsoft 365. Resend documente exactement cette défaillance et recommande un sous-domaine pour l’éviter.

La solution Supprimez l’enregistrement MX de la racine, rétablissez vos enregistrements MX Google Workspace ou Microsoft 365 exactement tels qu’ils étaient, et republiez le MX de Resend avec send comme hôte. Si send est déjà pris, Resend suggère send.sub.votredomaine.com.

Nous avons lancé, envoyé environ quatre mille confirmations d’inscription en une journée depuis un domaine vérifié le matin même, et la plupart sont parties dans les indésirables.

Tout ce qui précédait le lancement partait de resend.dev : votre propre domaine n’avait donc aucun historique d’envoi. Resend vous laisse la responsabilité de chauffer un domaine, contrairement aux IP dédiées, qu’il chauffe automatiquement. Son plan démarre à 150 e-mails maximum le premier jour et atteint 2 000 e-mails maximum au septième, et le calculateur étire la rampe jusqu’à 42 jours pour des objectifs plus élevés.

La solution Vérifiez le sous-domaine d’envoi des semaines avant le lancement et commencez à y faire passer du vrai trafic en petit volume. Suivez le plan de montée en charge, gardez le taux de bounce sous 4 % et le taux de spam sous 0,08 %, et limitez les envois non transactionnels aux personnes qui ont ouvert ou cliqué dans les six derniers mois, comme le recommande le guide d’hygiène d’audience de Resend.

La délivrabilité avec Resend, vos questions.

Pourquoi ai-je un 403 quand j’envoie à un client depuis onboarding@resend.dev ?

resend.dev est un expéditeur réservé aux tests. Il ne peut livrer qu’à l’adresse de votre compte Resend, et toute autre adresse renvoie un 403 indiquant que vous ne pouvez envoyer des e-mails de test qu’à votre propre adresse. Le guide de démarrage et la plupart des squelettes de framework arrivent avec cette valeur dans le code : elle survit donc jusqu’en préproduction plus souvent que personne ne l’avoue. Vérifiez un domaine, puis remplacez from par une adresse de ce domaine.

Resend configure-t-il SPF et DKIM à ma place ?

Oui. La vérification du domaine génère l’enregistrement TXT DKIM sur resend._domainkey et l’enregistrement TXT SPF sur le sous-domaine send, plus l’enregistrement MX du Return-Path, et vous publiez les trois chez votre hébergeur DNS. DMARC fait exception : Resend ne le crée pas et le dit. La vérification se termine en général dans les 15 minutes qui suivent la mise en ligne des enregistrements, même si les changements DNS peuvent mettre jusqu’à 72 heures à se propager dans le monde.

Ai-je besoin d’une IP dédiée avec Resend ?

Seulement au-delà d’un vrai volume. Les critères annoncés par Resend sont un abonnement actif Transactional Scale ou Marketing Pro et un volume d’envoi supérieur à 3 000 e-mails par jour, et il prévient qu’en dessous de 90 000 e-mails par mois cela peut ne pas suffire à garder les IP chaudes. En deçà, les IP partagées sont le meilleur choix, car elles arrivent déjà chauffées par d’autres expéditeurs. Resend n’expose pas non plus les adresses d’un pool : une IP dédiée ne peut donc pas servir à une mise en liste blanche.

Dois-je vérifier mon domaine racine ou un sous-domaine ?

Un sous-domaine. Resend le recommande pour deux raisons : cela isole la réputation d’envoi, si bien qu’un sous-domaine compromis peut être mis en quarantaine sans toucher à votre domaine principal, et cela donne aux fournisseurs de messagerie un signal clair sur la nature de ce courrier. Leur exemple est notifications.acme.com plutôt que acme.com. Ce contre quoi ils mettent en garde, c’est un domaine sosie comme acme-alerts.com, que les filtres lisent comme du hameçonnage.

Resend n’affiche presque aucune plainte pour spam, alors pourquoi mon courrier est-il dans les indésirables ?

Parce que le plus grand fournisseur de messagerie ne le dit jamais à Resend. La documentation de Resend sur les suppressions indique que tous les fournisseurs ne renvoient pas d’événement complained, en particulier Gmail et Google Workspace. Votre tableau de bord sous-estime donc le chiffre de toute la part de votre liste qui est chez Gmail. Inscrivez-vous à Google Postmaster Tools pour voir le vrai taux de spam, et lancez des tests de placement pour voir le dossier plutôt que de le déduire de l’engagement.

Puis-je utiliser une clé DKIM de 2048 bits avec Resend ?

Non. Resend signe le courrier sortant avec des clés DKIM de 1024 bits et ne prend pas en charge 2048 bits. Si une revue de sécurité ou une politique interne exige une signature en 2048 bits, c’est un blocage net et non un réglage, et la réponse est un autre chemin d’envoi pour ce courrier. Pour la délivrabilité ordinaire, ce n’est pas le problème à résoudre : les signatures de 1024 bits se vérifient toujours chez tous les grands fournisseurs.

Les informations sur la plateforme Resend ont été vérifiées à partir de la documentation publique en août 2026 et ont pu changer depuis. Resend est une marque de son propriétaire respectif. Unspam n’est ni affilié à Resend ni approuvé par Resend.

Testez votre prochaine campagne Resend avant vos abonnés.

Lancer un test de spam gratuit Test d’Inbox Placement