// comment corriger
Resend « domain is not verified » : corrigez les enregistrements DNS et les erreurs 403
Resend refuse d'envoyer tant que votre domaine n'est pas vérifié. Corrigez DKIM, SPF et MX sur le sous-domaine send, les statuts pending ou failed et les 403.
Ce que ça veut dire
Resend n'envoie que depuis des domaines qui vous appartiennent et que vous avez vérifiés grâce à des enregistrements DNS. Si vous envoyez depuis un domaine non vérifié, ou qui n'est pas vérifié exactement tel qu'il est écrit dans votre adresse From, l'API répond par une erreur 403. Le message indique généralement que le domaine n'est pas vérifié et vous invite à l'ajouter et à le vérifier sur la page Domains de Resend.
Un 403 voisin apparaît quand vous envoyez depuis le domaine de test resend.dev à une autre adresse que celle de votre propre compte : le domaine de test ne livre qu'à vous.
Sur la page Domains, chaque domaine a un statut. Les principaux sont :
- not_started : le domaine a été ajouté mais vous n'avez pas cliqué sur « Verify DNS Records ».
- pending : Resend cherche encore les enregistrements.
- verified : vous pouvez envoyer.
- failed : Resend n'a pas trouvé les enregistrements en 72 heures.
- temporary_failure : le domaine était vérifié, mais un enregistrement a disparu. Resend revérifie pendant 72 heures, puis le marque en failed.
Pourquoi cela arrive
- Enregistrements non ajoutés, ou ajoutés au mauvais nom. Les enregistrements de Resend se trouvent sur des noms comme
resend._domainkeyet un sous-domaine d'envoi (par défautsend). Si votre interface DNS ajoute votre domaine, saisir le nom complet le double ; voir enregistrement DNS ajouté au mauvais nom. - Domaine From différent. Vous avez vérifié
updates.yourdomain.commais vous envoyez depuisyourdomain.com, ou l'inverse. Chaque domaine et sous-domaine se vérifie séparément. - La valeur DKIM a été coupée ou modifiée au collage (caractères manquants, guillemets en plus, retours à la ligne).
- Enregistrements supprimés plus tard, par exemple lors d'une migration DNS, ce qui mène au statut temporary_failure. Voir enregistrements email perdus après un changement d'hébergeur DNS.
- Pas encore visibles. Les enregistrements ont été ajoutés récemment.
Comment vérifier
- Dans Resend, ouvrez le domaine et son onglet Records. Notez le type, le nom et la valeur de chaque enregistrement ; c'est la seule source fiable, car la liste d'enregistrements peut varier d'un domaine à l'autre (les domaines plus récents peuvent recevoir des enregistrements CNAME au lieu de TXT et MX pour le SPF).
- Vérifiez ce que voit Internet. Pour une configuration typique :
dig +short TXT resend._domainkey.yourdomain.com dig +short MX send.yourdomain.com dig +short TXT send.yourdomain.com
Comparez chaque réponse avec l'onglet Records. - Lancez le scanner de domaine de Delivmail sur votre domaine pour voir les enregistrements SPF, DKIM et DMARC publiés.
- Comparez, caractère par caractère, le domaine From de votre code avec le nom du domaine vérifié.
Comment corriger
- Ajoutez tous les enregistrements de l'onglet Records. Une configuration typique ressemble à ceci (vos valeurs seront différentes, copiez-les depuis Resend) :
resend._domainkey.yourdomain.com TXT "p=MIGfMA0GCSqGSIb3DQEB..." send.yourdomain.com MX 10 feedback-smtp.<region>.amazonses.com send.yourdomain.com TXT "v=spf1 include:amazonses.com ~all"
- Placez le MX sur le sous-domaine send, jamais sur la racine. L'ajouter à
yourdomain.comenverrait votre courrier entrant au gestionnaire de rebonds de Resend. Vos enregistrements MX actuels pour votre boîte mail ne changent pas. - Ne fusionnez pas ce SPF avec votre SPF racine. Il appartient au sous-domaine
send, qui est le domaine de Return-Path utilisé par Resend. Votre SPF racine n'est pas modifié. - Chez Cloudflare, laissez les éventuels enregistrements CNAME en « DNS only ».
- Cliquez sur Verify DNS Records dans Resend. Si le statut est failed, corrigez les enregistrements et relancez la vérification.
- Faites correspondre l'adresse From au domaine vérifié, ou vérifiez le domaine que vous utilisez réellement. Utiliser un sous-domaine par type d'email est une bonne pratique ; voir authentification email des sous-domaines.
- Ajoutez un DMARC si votre domaine n'en a pas, en commençant par
p=none; voir aucun enregistrement DMARC sur votre domaine.
Vérifier que c'est corrigé
Attendez que dig renvoie les valeurs attendues (de quelques minutes à quelques heures selon votre hébergeur DNS et le TTL) et que le domaine affiche verified. Envoyez ensuite un email via Resend à l'adresse unique de la page d'accueil de Delivmail. Le rapport doit montrer un DKIM valide pour votre domaine, un SPF valide sur le sous-domaine send et un DMARC valide. Renvoyez ensuite au destinataire d'origine. Laissez les enregistrements en place : en supprimer un plus tard fait passer le domaine en temporary_failure.
Vérifiez que c'est corrigé
Une modification DNS peut prendre de quelques minutes à quelques heures. Ensuite, envoyez un nouvel email de test ou scannez à nouveau votre domaine.
Fiches liées
- Aucun enregistrement SPF sur votre domaineVotre domaine n'indique pas quels serveurs ont le droit d'envoyer des emails en son nom. Ajoutez un enregistrement TXT et les destinataires sauront distinguer vos vrais emails des faux.
- Erreur SPF : trop de requêtes DNS (permerror)Le SPF autorise au maximum 10 requêtes DNS. Au-delà, tout l'enregistrement est cassé et les destinataires le considèrent comme invalide. Voici comment l'alléger.
- Plusieurs enregistrements SPF sur un même domaineUn domaine ne doit avoir qu'un seul enregistrement SPF. Avec deux ou plus, le SPF échoue pour tous vos emails. Fusionnez-les en une seule ligne.
- Échec SPF : le serveur d'envoi n'est pas autoriséVotre domaine a un enregistrement SPF, mais le serveur qui a envoyé votre email n'y figure pas. Trouvez quel service a envoyé l'email et ajoutez-le.
- Aucune signature DKIM sur vos emailsLe DKIM ajoute une signature numérique qui prouve qu'un email vient bien de votre domaine. Activez-le chez votre fournisseur de messagerie et publiez sa clé dans le DNS.