SPF, DKIM et DMARC pour Resend.
Resend est une API d'e-mail pensée avant tout pour les développeurs, qui authentifie votre domaine à l'aide d'un petit ensemble d'enregistrements DNS générés pour chaque domaine — et non d'une ligne SPF partagée à coller. Lorsque vous ajoutez un domaine, Resend affiche trois enregistrements : un TXT DKIM sur resend._domainkey (une clé de signature qu'il génère pour vous), plus un TXT SPF et un enregistrement MX qui résident tous deux sur un sous-domaine send. faisant office de return path. En coulisses, Resend s'appuie sur Amazon SES, mais il masque les CNAME Easy-DKIM de SES derrière sa propre clé DKIM unique. Une fois ces trois enregistrements résolus, Resend signe le courrier au nom de votre propre domaine — DKIM s'aligne en mode strict sur d=yourdomain.com, SPF s'aligne en mode relâché via le sous-domaine send, et DMARC réussit sur les deux.
Pourquoi authentifier Resend ?
Authentifier votre domaine Resend fait toute la différence entre la boîte de réception et le dossier spam — et tant que vous ne l'avez pas fait, vous ne pouvez envoyer que depuis le domaine de test partagé de Resend, onboarding@resend.dev, qui ne vous appartient nullement. Depuis février 2024, Gmail et Yahoo exigent de chaque expéditeur en volume (environ 5 000 messages par jour et plus) qu'il réussisse SPF, DKIM et DMARC avec alignement, et Microsoft a commencé à appliquer les mêmes règles au courrier à fort volume entrant dans Outlook/Hotmail en 2025. Resend est généralement branché sur le courrier même que ces règles jugent le plus sévèrement — réinitialisations de mot de passe, reçus, codes de vérification, et de plus en plus les diffusions marketing — où un seul passage au spam casse un parcours d'inscription. Resend rend cela particulièrement propre : parce qu'il place le SPF/return path sur un sous-domaine send. de VOTRE domaine (plutôt que de posséder un domaine de rebond comme le font Mailchimp ou l'ancienne configuration de SendGrid), SPF s'aligne réellement en mode relâché, et le sélecteur DKIM resend signe au nom de votre propre domaine, de sorte que DKIM s'aligne en mode strict. Publiez les enregistrements et un domaine Resend réussit DMARC sur les deux mécanismes — la configuration résiliente qui survit au transfert. Ignorez-les et le courrier part soit en tant que resend.dev, soit non authentifié, avec une réputation mutualisée sur une infrastructure partagée.
La réalité SPF pour Resend
Resend est un fournisseur par compte bâti sur Amazon SES, il n'y a donc AUCUN include partagé pour votre domaine racine — et c'est voulu. Lorsque vous ajoutez un domaine, Resend provisionne un sous-domaine send. (le domaine MAIL FROM personnalisé / d'enveloppe de SES) et y place l'enregistrement SPF : send.yourdomain.com reçoit v=spf1 include:amazonses.com ~all, et le MX correspondant (feedback-smtp.{region}.amazonses.com) capte les rebonds et les plaintes. Le SPF de votre domaine racine n'est jamais touché — Resend n'y ajoute AUCUNE recherche DNS. Deux choses rendent cela meilleur que la plupart des ESP. Premièrement, parce que le return path est un sous-domaine de votre propre domaine plutôt qu'un domaine de rebond appartenant à Resend, SPF s'aligne pour DMARC en mode relâché (send.yourdomain.com partage le domaine organisationnel yourdomain.com). Deuxièmement, Resend n'utilise pas les trois sélecteurs CNAME Easy-DKIM de SES — il génère sa propre clé DKIM et publie un unique TXT sur resend._domainkey.yourdomain.com, signant avec d=yourdomain.com, de sorte que DKIM s'aligne en mode strict. La réalité est donc la suivante : rien ne va sur votre SPF racine, le include:amazonses.com que vous voyez n'a sa place que sur le sous-domaine send, et c'est DKIM (et non un include racine) qui porte l'alignement le plus fort. Si un vieux tutoriel vous dit d'ajouter include:amazonses.com à votre racine, ignorez-le — cela ne fait rien pour Resend, consomme l'une des 10 recherches SPF de votre racine et autorise inutilement l'ensemble de SES à envoyer au nom de votre apex.
Étape par étape
- 1
Ajoutez votre domaine (et choisissez une région)
Connectez-vous sur resend.com, ouvrez Domains dans la navigation de gauche et cliquez sur Add Domain. Saisissez votre domaine d'envoi — soit votre apex (yourdomain.com), soit, de préférence, un sous-domaine d'envoi dédié comme updates.yourdomain.com — puis choisissez la région AWS la plus proche de vos utilisateurs (N. Virginia us-east-1, Ireland eu-west-1, São Paulo sa-east-1 ou Tokyo ap-northeast-1). La région est intégrée à l'hôte MX et ne peut pas être modifiée par la suite sans supprimer et rajouter le domaine, alors choisissez délibérément.
- 2
Ouvrez l'onglet Records
Resend génère les enregistrements DNS pour vous et les liste sous l'onglet Records/DNS du domaine : un TXT DKIM (resend._domainkey), un TXT SPF sur le sous-domaine send et un MX sur le sous-domaine send. Si vous exploitez déjà un service sur send.yourdomain.com, utilisez l'option Custom Return Path pour choisir un sous-domaine différent avant de copier les enregistrements.
- 3
Ajoutez l'enregistrement TXT DKIM
Chez votre hébergeur DNS, créez un enregistrement TXT avec l'hôte resend._domainkey et la longue valeur de clé publique que Resend affiche (commençant par p=). C'est l'enregistrement qui aligne strictement votre courrier sur d=yourdomain.com, alors collez la valeur exactement — une clé partiellement collée ou re-encadrée de guillemets est la raison la plus fréquente pour laquelle un domaine à l'air correct échoue tout de même à DKIM. Notez qu'il se trouve au niveau du sélecteur sur votre racine (ou votre sous-domaine d'envoi), et non sous send.
- 4
Ajoutez le TXT SPF sur le sous-domaine send
Créez un enregistrement TXT avec l'hôte send (c.-à-d. send.yourdomain.com) et la valeur v=spf1 include:amazonses.com ~all. Cela autorise l'enveloppe SES pour le return path — laissez votre SPF racine tel quel et n'ajoutez PAS include:amazonses.com à celui-ci. Si votre registraire ajoute automatiquement le domaine, saisissez uniquement send, et non send.yourdomain.com.
- 5
Ajoutez l'enregistrement MX sur le sous-domaine send
Créez un enregistrement MX avec l'hôte send, une priorité de 10 et la valeur feedback-smtp.{region}.amazonses.com correspondant à la région que vous avez choisie (p. ex. feedback-smtp.us-east-1.amazonses.com). Ajoutez un point final à la valeur pour que votre registraire n'y accole pas votre domaine. Ce MX ne reçoit que les retours de rebond/plainte de SES — il ne change pas l'endroit où votre courrier entrant normal est distribué.
- 6
Publiez un enregistrement DMARC
Resend recommande une politique DMARC mais ne la crée pas pour vous. Ajoutez un enregistrement TXT à l'hôte _dmarc avec v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance seule, donc rien ne change à la distribution pendant que vous confirmez l'alignement. Conservez exactement un seul enregistrement _dmarc par domaine.
- 7
Cliquez sur Verify DNS Records
De retour dans Resend, cliquez sur Verify DNS Records. La propagation prend généralement quelques minutes mais peut aller jusqu'à 72 heures ; le statut bascule sur Verified une fois que les trois enregistrements se résolvent. S'il stagne, revérifiez l'absence d'un hôte doublé, d'un MX à la région incompatible ou d'un point final manquant, puis relancez la vérification.
- 8
Envoyez un vrai test et lisez les en-têtes
Le statut Verified dans le tableau de bord ne prouve pas que le courrier est aligné. Envoyez un message depuis une adresse de votre domaine vérifié (pas @resend.dev) vers un compte Gmail, ouvrez-le et choisissez ⋮ → Afficher l'original. Vous voulez SPF : PASS (mailed-by un hôte send.yourdomain.com), DKIM : PASS avec signed-by : yourdomain.com et le sélecteur resend, et DMARC : PASS — le tout pointant vers votre domaine, et non resend.dev ou amazonses.com.
Enregistrements à ajouter
Resend génère les valeurs exactes dans son assistant de configuration — celles-ci illustrent la forme de ce que vous ajouterez chez votre hébergeur DNS.
| Type | Hôte | Valeur |
|---|---|---|
| TXT | resend._domainkey | p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…(long public key from Resend)Clé publique DKIM, sélecteur resend, sur votre domaine racine/d'envoi — cela aligne strictement le courrier sur d=yourdomain.com. À titre d'illustration ; la vraie clé de 1024 bits est générée par domaine et affichée comme une unique chaîne p=… (sans préfixe v=DKIM1) — collez-la exactement telle qu'affichée. |
| TXT | send | v=spf1 include:amazonses.com ~allSPF pour le sous-domaine send (l'enveloppe SES / MAIL FROM). Réside sur send.yourdomain.com, PAS sur votre racine — n'ajoutez pas include:amazonses.com au SPF de votre apex. |
| MX | send | feedback-smtp.us-east-1.amazonses.comReturn path pour les rebonds/plaintes de SES — priorité 10, sur le sous-domaine send, avec un point final. Spécifique à la région : la région correspond à celle que vous avez choisie lors de l'ajout du domaine (us-east-1 / eu-west-1 / sa-east-1 / ap-northeast-1). |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVous l'ajoutez vous-même — Resend présente une politique recommandée mais ne l'écrit jamais dans le DNS. Un seul par domaine ; commencez à p=none, puis resserrez. |
Conservez exactement un seul enregistrement SPF (v=spf1) TXT sur votre domaine racine — fusionnez-y tous vos expéditeurs. Avoir deux enregistrements SPF constitue en soi une erreur.
Le budget de 10 requêtes DNS
SPF est plafonné à une limite stricte de 10 requêtes DNS — dépassez-la et il renvoie une permerror et cesse de valider partout. Voici ce que coûte la configuration de Resend sur ce budget.
La configuration recommandée de Resend ajoute 0 requête — les 10 restent disponibles pour les expéditeurs qui, eux, ont besoin d'un include:.
DKIM
DKIM est l'enregistrement le plus important d'une configuration Resend, et c'est là que Resend s'écarte discrètement d'Amazon SES brut. Même si Resend s'appuie sur SES, il ne vous fournit PAS les trois sélecteurs CNAME Easy-DKIM de SES. À la place, Resend génère sa propre paire de clés DKIM par domaine et vous donne un unique enregistrement TXT : hôte resend._domainkey.yourdomain.com, valeur la clé publique (une chaîne p=… qu'il affiche dans l'onglet Records), sélecteur resend. Resend conserve la clé privée correspondante et signe chaque message avec d=yourdomain.com; s=resend. Parce que ce d= est votre propre domaine — et non amazonses.com ni un domaine appartenant à Resend — DKIM s'aligne en mode strict pour DMARC, et il continue de réussir même lorsqu'un message est transféré (c'est précisément là que SPF a tendance à casser). Deux remarques pratiques. Premièrement, il s'agit d'un enregistrement TXT que vous publiez, et non d'une délégation CNAME, donc Resend ne peut pas faire pivoter la clé en silence comme le font les fournisseurs CNAME — si vous effectuez un jour une rotation, vous republiez la nouvelle valeur. Deuxièmement, collez la valeur exactement telle que Resend l'affiche. Parce que Resend signe avec une clé de 1024 bits, la valeur p= est une unique chaîne d'environ 216 caractères qui tient sous la limite TXT de 255 caractères par chaîne du DNS — donc, contrairement aux clés 2048 bits plus longues que certains fournisseurs vous remettent, elle n'est PAS scindée en plusieurs chaînes entre guillemets ; collez-la comme une seule valeur ininterrompue. Une copie partielle, un espace inséré, ou une paire de guillemets supplémentaire que votre panneau DNS enroule autour de la chaîne est la cause numéro un d'un domaine qui semble configuré mais échoue tout de même à une vérification DKIM. L'enregistrement DKIM se trouve au niveau du sélecteur sur votre racine (ou sur votre sous-domaine d'envoi) — et non sous le sous-domaine send où résident SPF et le MX.
DMARC
DMARC est un enregistrement de politique distinct que Resend recommande mais ne crée pas pour vous — vous l'ajoutez chez votre hébergeur DNS. Publiez un enregistrement TXT sur _dmarc.yourdomain.com commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance seule : il ne change rien à la distribution mais indique aux destinataires de vous envoyer des rapports agrégés (rua) afin que vous puissiez confirmer que le courrier Resend réussit SPF et DKIM alignés sur votre domaine. Resend se comporte bien ici — vous obtenez un alignement SPF relâché via le sous-domaine send ET un alignement DKIM strict via le sélecteur resend — vous devriez donc voir des réussites DMARC propres presque immédiatement, et vous pouvez sans risque ajouter adkim=s (alignement DKIM strict) si vous le souhaitez, puisque d=yourdomain.com correspond exactement à votre domaine From. Surveillez les rapports pendant une semaine ou deux, assurez-vous que chaque expéditeur légitime (Resend plus tout hébergeur de boîtes aux lettres ou autres outils) s'authentifie, puis faites monter la politique de p=none à p=quarantine et enfin p=reject. Conservez exactement un seul enregistrement _dmarc pour l'ensemble du domaine organisationnel, quel que soit le nombre d'expéditeurs que vous exploitez — n'ajoutez jamais un second enregistrement DMARC uniquement pour Resend.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas au seul badge vert Verified de Resend — il signifie uniquement que les trois enregistrements se sont résolus, pas qu'un vrai message s'aligne. Envoyez un test depuis une adresse de votre domaine vérifié (par exemple no-reply@yourdomain.com, et surtout PAS une adresse @resend.dev) vers un compte Gmail, ouvrez-le et choisissez ⋮ → Afficher l'original. Vous voulez SPF : PASS avec mailed-by affichant un hôte send.yourdomain.com, DKIM : PASS avec signed-by : yourdomain.com et le sélecteur resend, et DMARC : PASS — le tout attribué à votre domaine plutôt qu'à resend.dev ou amazonses.com. Si DKIM apparaît comme votre domaine mais que SPF affiche amazonses.com sans s'aligner, vérifiez que les enregistrements du sous-domaine send sont bien en place. Vous pouvez contrôler ponctuellement les enregistrements bruts avec dig TXT resend._domainkey.yourdomain.com, dig TXT send.yourdomain.com et dig MX send.yourdomain.com. Enfin, passez le domaine dans le contrôle de santé de domaine de Qualisend pour confirmer que chaque enregistrement se résout et que votre SPF racine reste sous la limite de 10 recherches, et une fois que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC — Resend/Amazon SES devrait y apparaître comme une source alignée et réussie.
Pièges courants
- Couverture
Les enregistrements de Resend résident sur le sous-domaine send, pas sur votre racine. Les registraires qui ajoutent automatiquement le domaine transforment send en send.yourdomain.com.yourdomain.com et resend._domainkey en un hôte doublé — saisissez uniquement les libellés (send, resend._domainkey) et laissez le panneau ajouter le domaine.
- Couverture
La valeur MX est spécifique à la région et doit correspondre à celle que vous avez choisie lors de l'ajout du domaine. Un domaine en eu-west-1 avec un MX feedback-smtp en us-east-1 ne se vérifiera pas — et vous ne pouvez pas changer la région d'un domaine après sa création ; supprimez-le et rajoutez-le dans la nouvelle région, puis mettez à jour le MX.
- Couverture
Ajoutez un point final à la valeur MX (feedback-smtp.{region}.amazonses.com.) pour que votre registraire n'accole pas votre domaine et ne produise pas feedback-smtp.us-east-1.amazonses.com.yourdomain.com.
- Casse l'authentification
N'ajoutez pas include:amazonses.com à votre SPF RACINE. Le SPF de Resend a sa place sur le sous-domaine send ; un include racine ne fait rien pour Resend, gaspille l'une de vos 10 recherches SPF racine et autorise l'ensemble d'Amazon SES à envoyer au nom de votre apex.
- Configuration DNS
Resend est bâti sur SES mais n'utilise PAS les trois CNAME Easy-DKIM de SES — il publie un unique TXT DKIM (sélecteur resend) qu'il génère. Ne cherchez pas de sélecteurs CNAME ; collez l'unique clé TXT exactement, car une clé partiellement collée ou re-encadrée de guillemets est la première raison pour laquelle DKIM échoue encore sur un domaine « configuré ». C'est une clé de 1024 bits, donc la valeur tient dans une seule chaîne — ne la scindez pas.
- Couverture
Les adresses partagées @resend.dev (onboarding@resend.dev, delivered@resend.dev, etc.) servent uniquement à essayer l'API — elles ne sont pas votre domaine et ne vous donnent aucun alignement SPF/DKIM. Vous devez ajouter et vérifier votre propre domaine pour envoyer en votre nom.
- Configuration DNS
Ce sont des enregistrements TXT et MX, pas des CNAME, il n'y a donc pas de piège du nuage orange (proxy) de Cloudflare — mais si Cloudflare a déjà créé automatiquement un SPF sur votre racine, laissez-le tel quel ; le SPF de Resend est distinct et réside sur le sous-domaine send.
- Couverture
Si vous exploitez déjà du courrier ou un service sur send.yourdomain.com (un SPF, un MX ou un sous-domaine existant), utilisez la fonctionnalité Custom Return Path de Resend pour choisir un sous-domaine de return path différent au lieu d'entrer en collision avec ce qui s'y trouve.
Construisez votre enregistrement SPF
Resend n'a pas besoin d'un include: SPF sur votre domaine racine — utilisez le générateur pour assembler un enregistrement propre et unique pour vos autres expéditeurs, en le limitant à une seule ligne.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF Resend — FAQ
Lectures complémentaires
Une fois publié, confirmez que tout se résout correctement avec la vérification de l'état du domaine, puis identifiez qui envoie en votre nom grâce à l'analyseur de rapports DMARC. Parcourez toutes les sources d'envoi dans le générateur. L'authentification ne représente toutefois que la moitié de la délivrabilité — une IP ou un domaine d'envoi inscrit sur une liste vous fait toujours atterrir dans les spams, quelle que soit la propreté de votre SPF ; il vaut donc la peine de surveiller les listes noires avec la surveillance des listes noires.
Authentifié — maintenant, gardez votre liste propre
Réussir SPF, DKIM et DMARC vous mène jusqu'à la boîte de réception ; une liste propre vous y maintient. Vérifiez la vôtre — commencez gratuitement avec 100 crédits, sans carte bancaire.