SPF, DKIM et DMARC pour Mailtrap.
Mailtrap authentifie votre domaine via une vérification de domaine basée sur des CNAME, et non en vous faisant coller une ligne SPF partagée. Dans son produit Email Sending, vous ajoutez un domaine d'envoi et Mailtrap vous fournit cinq enregistrements DNS sur la page Domain Verification : un CNAME de Domain Verification (qui couvre aussi le SPF/return-path), deux CNAME DKIM sur les sélecteurs rwmt1._domainkey et rwmt2._domainkey, un CNAME facultatif de Custom Tracking Domain pour un suivi des ouvertures/clics à votre marque, et un enregistrement DMARC TXT. Une fois ceux-ci résolus, Mailtrap signe et envoie sous votre propre domaine, DMARC passe sur un DKIM aligné (et sur SPF via votre propre return-path), et vous n'avez jamais à publier ni à maintenir un include SPF brut. Un point qui déroute au premier abord : cela ne s'applique qu'à Mailtrap Email Sending — le bac à sable Email Testing, distinct, capture les messages dans une boîte de réception factice et ne nécessite aucun DNS.
Pourquoi authentifier Mailtrap ?
Vérifier votre domaine d'envoi dans Mailtrap, c'est la porte entre la boîte de réception et le dossier spam — et Mailtrap l'impose avant même d'accepter d'envoyer du courrier de production. Tant qu'un domaine n'est pas vérifié, Mailtrap restreint un flux Email Sending aux messages de test adressés à l'adresse e-mail de votre propre compte ; les vrais destinataires sont bloqués. Au-delà de cela, le calendrier compte : depuis février 2024, Gmail et Yahoo exigent de chaque expéditeur en masse (environ 5 000 messages par jour et plus) qu'il passe SPF, DKIM et DMARC avec alignement, et en 2025 Microsoft a commencé à appliquer la même exigence pour Outlook/Hotmail/Live — en acheminant d'abord le courrier en masse non conforme vers les indésirables, puis en évoluant vers un rejet pur et simple. Comme Mailtrap est un expéditeur transactionnel/API, un flux non vérifié signifie que votre courrier soit ne part pas, soit part faiblement attribuable à votre domaine — pas de DKIM aligné, pas de passage DMARC, et une réputation mutualisée avec l'infrastructure partagée de Mailtrap plutôt que la vôtre. Terminer la vérification du domaine règle tout d'un coup : les deux sélecteurs DKIM rwmt signent en d=yourdomain.com pour que DKIM s'aligne, le CNAME de Domain Verification place le return-path de Mailtrap sur votre propre domaine pour que SPF passe et s'aligne aussi, DMARC passe sur les deux mécanismes, et la réputation d'envoi que vous construisez revient à votre domaine.
La réalité SPF pour Mailtrap
Mailtrap est un fournisseur de vérification de domaine basé sur des CNAME, donc pour votre domaine racine il n'y a AUCUN include SPF à ajouter — et la documentation de Mailtrap le dit clairement : « La vérification SPF de votre courrier est couverte par l'enregistrement de vérification de domaine. Il n'est pas nécessaire d'ajouter un enregistrement SPF séparé sur votre domaine d'envoi. » Voici le mécanisme. Lorsque vous vérifiez un domaine d'envoi, l'un des CNAME que Mailtrap vous fournit est l'enregistrement de Domain Verification, qui fait aussi office d'hôte de return-path/bounce sur votre propre domaine et délègue la recherche SPF à l'infrastructure d'envoi de Mailtrap. Le véritable enregistrement SPF actif de Mailtrap se trouve à _spf.smtp.mailtrap.live (v=spf1 ip4:45.158.83.0/24 ip4:5.181.200.0/24 … ~all) — mais vous ne le publiez jamais vous-même ; le CNAME de Domain Verification s'y résout à votre place. Comme cet hôte de return-path se situe sous votre propre domaine vérifié, SPF passe et s'aligne à votre domaine organisationnel sous alignement souple, ce qui constitue un réel avantage par rapport aux expéditeurs CNAME purement DKIM (Mailchimp, Klaviyo) où SPF ne peut jamais s'aligner. Deux choses à savoir. Premièrement, ignorez tout ancien conseil recommandant d'ajouter include:_spf.mailtrap.io — ce nom d'hôte ne se résout pas du tout en enregistrement SPF, et même l'hôte d'infra correct (_spf.smtp.mailtrap.live) n'est pas quelque chose que vous collez sur votre racine ; l'ajouter manuellement ne ferait que gaspiller l'une de vos 10 recherches DNS SPF pour rien. Deuxièmement, si votre DNS est sur Google Cloud DNS, sa console propose encore un type d'enregistrement « SPF » hérité — Mailtrap vous dit explicitement de l'ignorer (il est obsolète) et d'ajouter les quatre CNAME plus le DMARC TXT normalement. Effet net sur votre SPF racine : Mailtrap ajoute zéro recherche DNS, donc il s'empile proprement avec Google Workspace, Microsoft 365 ou tout autre expéditeur que vous listez déjà.
Deux façons de le configurer
Vérifier un sous-domaine d'envoi dédié (p. ex. mail.yourdomain.com)
- Isole la réputation Mailtrap/transactionnelle de l'e-mail humain sur votre domaine racine, de sorte qu'une erreur d'envoi ne puisse pas plomber votre domaine principal.
- DKIM signe en d=mail.yourdomain.com et, sous l'alignement DMARC souple, s'aligne quand même à votre domaine organisationnel — donc DMARC passe.
- Le CNAME de Domain Verification place le return-path sur le sous-domaine, de sorte que SPF passe et s'aligne là aussi.
- Vous ajoutez toujours les quatre CNAME plus un DMARC TXT ; votre SPF racine reste intact, sans ajouter aucune recherche DNS.
Vérifier le domaine racine/organisationnel (yourdomain.com)
- Le plus simple si Mailtrap est votre seul expéditeur ou votre expéditeur principal et que vous voulez que le courrier parte visiblement du domaine nu.
- DKIM et le return-path se situent directement sur le domaine organisationnel, de sorte que l'alignement est exact plutôt que dépendant du mode souple.
- La réputation est partagée avec tout le reste de ce que vous envoyez depuis la racine — pesez cela si du courrier humain Google Workspace ou Microsoft 365 y réside aussi.
- Toujours zéro recherche ajoutée à votre SPF racine, puisque Mailtrap utilise le CNAME de Domain Verification, pas un include à la racine.
Étape par étape
- 1
Ouvrez Email Sending, pas Email Testing
Connectez-vous sur mailtrap.io et assurez-vous d'être dans le produit Email Sending (la section de la barre latérale pour le courrier sortant réel), pas Email Testing (le bac à sable qui capture les messages pour l'assurance qualité et ne nécessite aucun DNS). La vérification de domaine n'existe que pour Email Sending.
- 2
Ajoutez votre domaine d'envoi
Dans la navigation de gauche, allez dans Sending Domains et cliquez sur Add Domain. Saisissez le domaine depuis lequel vous enverrez (p. ex. yourdomain.com, ou un sous-domaine comme mail.yourdomain.com si vous voulez isoler le courrier transactionnel). Mailtrap génère les enregistrements DNS pour ce nom exact.
- 3
Ouvrez la page Domain Verification
Sélectionnez le nouveau domaine pour ouvrir sa page Domain Verification. Vous verrez les enregistrements à publier, chacun étiqueté par son rôle : Domain Verification (CNAME), DKIM (deux CNAME), Custom Tracking / Domain Tracking (CNAME) et DMARC (TXT). Notez les colonnes Type, Name et Value — les Name et Value sont générés pour votre compte.
- 4
Ajoutez le CNAME de Domain Verification
Créez l'enregistrement Domain Verification en tant que CNAME en utilisant les Name et Value exacts affichés par Mailtrap. Cet unique enregistrement prouve à la fois la propriété et couvre le SPF/return-path — c'est pourquoi vous ne publiez pas d'enregistrement SPF séparé. Conservez le type CNAME ; ne le convertissez pas en TXT ni en A.
- 5
Ajoutez les deux CNAME DKIM
Créez deux enregistrements CNAME : Name rwmt1._domainkey → Value rwmt1.dkim.mailtrap.io, et Name rwmt2._domainkey → Value rwmt2.dkim.mailtrap.io (utilisez les valeurs exactes de votre tableau de bord). Deux sélecteurs permettent à Mailtrap de faire tourner les clés DKIM sans que vous ne touchiez de nouveau au DNS. Ce sont ces CNAME qui signent votre courrier en d=yourdomain.com et portent le passage DMARC.
- 6
Ajoutez le CNAME de Custom Tracking Domain
Créez le CNAME de suivi (Mailtrap affiche généralement un Name comme mt-link) pointant vers la Value qu'il fournit. Il sert le suivi des ouvertures/clics et les liens de désinscription depuis votre propre domaine plutôt qu'un hôte Mailtrap. C'est le seul enregistrement que vous pouvez ignorer si vous n'utilisez pas le suivi des liens, mais l'ajouter garde les liens suivis à votre marque et évite la réputation de domaine partagé d'un hôte de suivi Mailtrap générique.
- 7
Ajoutez l'enregistrement DMARC TXT
Créez un unique enregistrement TXT au Name _dmarc avec la valeur affichée par Mailtrap (une politique v=DMARC1; p=none; …). Si votre domaine a déjà un enregistrement _dmarc, n'en ajoutez PAS un second — un domaine doit avoir exactement un enregistrement DMARC ; conservez plutôt celui existant.
- 8
Corrigez le doublement d'hôte et désactivez le proxy Cloudflare
De nombreux registraires ajoutent automatiquement votre domaine, alors saisissez uniquement le libellé (rwmt1._domainkey, pas rwmt1._domainkey.yourdomain.com) pour éviter le doublement — même si quelques panneaux veulent la forme complète avec postfixe, alors adaptez-vous à ce que votre hébergeur attend. Sur Cloudflare, réglez chaque CNAME sur DNS only (nuage gris) ; Cloudflare active le proxy par défaut, et un CNAME proxifié en nuage orange ne se résoudra pas vers Mailtrap, donc la vérification échoue.
- 9
Revérifiez le DNS dans Mailtrap
De retour sur la page Domain Verification, cliquez sur Re-check DNS Records. Mailtrap effectue aussi une vérification automatique périodique, donc les enregistrements passent de Missing (rouge) à Verified (vert) au fur et à mesure de leur propagation — généralement quelques minutes, mais comptez de 15 minutes à 24–48 heures. Certains enregistrements se vérifient avant d'autres ; attendez qu'ils soient tous verts.
- 10
Envoyez un test et lisez les en-têtes
Envoyez un message depuis une adresse du domaine vérifié, ouvrez-le dans Gmail et choisissez ⋮ → Show original. Confirmez DKIM : PASS signé par yourdomain.com (sélecteur rwmt1 ou rwmt2), SPF : PASS, et DMARC : PASS — tous alignés à votre domaine, pas à un hôte mailtrap.io.
Enregistrements à ajouter
Mailtrap 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 |
|---|---|---|
| CNAME | (Mailtrap-generated verification host) | (per-account target, e.g. under smtp.mailtrap.live)Enregistrement Domain Verification — à titre indicatif. Mailtrap affiche les Name et Value exacts propres à votre compte sur la page Domain Verification. Ce CNAME couvre aussi le SPF/return-path, c'est pourquoi aucun enregistrement SPF séparé n'est nécessaire. |
| CNAME | rwmt1._domainkey | rwmt1.dkim.mailtrap.ioClé DKIM 1 (rotation automatique). Copiez la valeur exacte depuis votre tableau de bord ; certains hébergeurs DNS ont besoin de la forme avec postfixe rwmt1._domainkey.yourdomain.com. |
| CNAME | rwmt2._domainkey | rwmt2.dkim.mailtrap.ioClé DKIM 2 — le second sélecteur permet à Mailtrap de faire tourner les clés. Utilisez la cible exacte affichée dans votre tableau de bord. |
| CNAME | mt-link | (per-account tracking target)Custom Tracking Domain — hôte/cible à titre indicatif. Active le suivi des ouvertures/clics à votre marque et les liens de désinscription sur votre domaine. Facultatif mais recommandé ; les Name/Value exacts sont affichés par compte. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comPolitique DMARC — une par domaine. Mailtrap pré-remplit une valeur p=none ; conservez un seul enregistrement _dmarc et durcissez vers quarantine/reject plus tard. |
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 Mailtrap sur ce budget.
La configuration recommandée de Mailtrap ajoute 0 requête — les 10 restent disponibles pour les expéditeurs qui, eux, ont besoin d'un include:.
DKIM
Le DKIM est géré par deux enregistrements CNAME — rwmt1._domainkey et rwmt2._domainkey — que Mailtrap génère pour votre domaine, pointant respectivement vers rwmt1.dkim.mailtrap.io et rwmt2.dkim.mailtrap.io (copiez les valeurs exactes depuis la page Domain Verification). Comme il s'agit de CNAME délégués à Mailtrap — et non de TXT que vous collez — Mailtrap détient les clés privées et utilise les deux sélecteurs pour faire tourner les clés publiées derrière eux sans que vous ayez jamais à modifier de nouveau le DNS. Il n'y a aucune clé publique DKIM à copier et aucun sélecteur à inventer. Le DKIM est le mécanisme qui fait le gros du travail pour DMARC ici : une fois les CNAME résolus, Mailtrap signe le courrier sortant en d=yourdomain.com, de sorte que la signature s'aligne à votre domaine organisationnel et satisfait DMARC à elle seule — indépendamment du transfert, qui peut casser SPF. Quelques aspects pratiques : conservez le type d'enregistrement CNAME (un TXT là où un CNAME est attendu casse la validation) ; saisissez uniquement le libellé (rwmt1._domainkey) si votre panneau ajoute automatiquement le domaine, ou la forme complète rwmt1._domainkey.yourdomain.com sinon ; et sur Cloudflare, réglez les deux sur DNS only (nuage gris) pour qu'ils se résolvent vers les cibles mailtrap.io. Vous ajoutez les deux CNAME, cliquez sur Re-check DNS Records, et les lignes DKIM passent au vert.
DMARC
Le DMARC est un enregistrement de politique distinct sur votre domaine, et Mailtrap l'inclut dans le jeu d'enregistrements de la page Domain Verification — généralement pré-rempli comme v=DMARC1; p=none; … . Publiez-le sous forme d'enregistrement TXT à _dmarc.yourdomain.com. p=none est en mode surveillance seule : il ne change rien à la délivrabilité pendant que vous confirmez, à partir des rapports agrégés (rua), que le courrier Mailtrap passe DKIM (et SPF) aligné à votre domaine. Comme Mailtrap vous fournit à la fois un DKIM aligné (les sélecteurs rwmt) et un return-path aligné (le CNAME de Domain Verification), un domaine correctement vérifié passe DMARC sur les deux mécanismes — la configuration résiliente qui survit au transfert. Surveillez les rapports pendant une ou deux semaines, assurez-vous que chaque expéditeur légitime s'authentifie, puis durcissez vers p=quarantine et à terme p=reject. Deux règles : conservez exactement un enregistrement _dmarc pour tout le domaine, quel que soit le nombre d'expéditeurs que vous utilisez — si vous en avez déjà un, n'ajoutez pas la deuxième copie de Mailtrap, gardez simplement le vôtre — et pointez rua vers une boîte aux lettres (ou un service d'analyse de rapports DMARC) que vous surveillez réellement, sinon p=none ne vous sert à rien.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas au badge vert « Verified » de la page Domain Verification à lui seul — il confirme uniquement que les enregistrements se résolvent, pas qu'un vrai message s'authentifie. Envoyez-vous un test depuis une adresse du domaine vérifié, ouvrez-le dans Gmail et choisissez ⋮ → Show original : vous voulez DKIM : PASS signé par yourdomain.com avec le sélecteur rwmt1 ou rwmt2, SPF : PASS, et DMARC : PASS, tous affichant votre domaine plutôt qu'un hôte mailtrap.io. Dans Mailtrap, utilisez le bouton Re-check DNS Records pour forcer une vérification au lieu d'attendre le sondage périodique. Vous pouvez contrôler ponctuellement les enregistrements bruts avec dig CNAME rwmt1._domainkey.yourdomain.com et dig TXT _dmarc.yourdomain.com. Passez ensuite votre domaine dans le contrôle de santé de domaine de Qualisend pour confirmer que le CNAME de Domain Verification, les deux sélecteurs DKIM, le CNAME de suivi et l'enregistrement DMARC se résolvent tous proprement et que votre SPF racine reste sous la limite des 10 recherches — et une fois que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC, où Mailtrap devrait apparaître comme une source alignée et conforme.
Pièges courants
- Couverture
Email Testing vs Email Sending : la vérification de domaine n'existe que pour le produit Email Sending. Le bac à sable Email Testing capture les messages dans une boîte factice pour l'assurance qualité et ne nécessite aucun enregistrement DNS — si vous cherchez une configuration DNS sous Email Testing, vous n'êtes pas au bon endroit.
- Configuration DNS
Il n'y a aucun enregistrement SPF à ajouter. Le CNAME de Domain Verification de Mailtrap couvre déjà le SPF/return-path, alors ne collez pas include:_spf.mailtrap.io (il ne se résout pas) ni include:_spf.smtp.mailtrap.live (l'hôte d'infra interne de Mailtrap) sur votre racine — le faire gaspille une recherche SPF et la documentation de Mailtrap dit explicitement qu'un enregistrement SPF séparé n'est pas nécessaire.
- Configuration DNS
Le proxy Cloudflare casse la vérification : réglez chaque CNAME Mailtrap sur DNS only (nuage gris). Cloudflare active le proxy nuage orange par défaut, et un CNAME proxifié ne se résoudra pas vers les cibles mailtrap.io / mailtrap.live, donc les enregistrements ne se vérifient jamais.
- Configuration DNS
Doublement du champ hôte : de nombreux registraires ajoutent automatiquement votre domaine, si bien que rwmt1._domainkey peut devenir rwmt1._domainkey.yourdomain.com.yourdomain.com. Saisissez uniquement le libellé si le panneau ajoute le domaine ; à l'inverse, quelques hébergeurs (certains panneaux de type Squarespace) veulent la forme complète avec postfixe — adaptez-vous à ce qu'attend votre fournisseur.
- Configuration DNS
Chaque enregistrement est un CNAME sauf DMARC (TXT) — ne changez pas les types. Sur Google Cloud DNS en particulier, ignorez le type d'enregistrement « SPF » hérité de la console ; Mailtrap note qu'il est obsolète. Ajoutez les quatre CNAME et l'unique DMARC TXT.
- Couverture
Tant que le domaine n'est pas Verified, Mailtrap ne permet à un flux Email Sending que de délivrer des messages de test à l'adresse e-mail de votre propre compte. Les envois de production vers de vrais destinataires restent bloqués, alors terminez la vérification avant de brancher Mailtrap sur le trafic réel de votre application.
- Configuration DNS
Conservez un seul enregistrement DMARC et un seul enregistrement SPF. Si vous envoyez aussi via Google Workspace, Microsoft 365, SendGrid, etc., n'ajoutez pas un second _dmarc ni un second SPF TXT — Mailtrap n'ajoute rien à votre SPF racine, alors gardez simplement vos enregistrements uniques existants.
- Couverture
La vérification n'est pas instantanée : la propagation peut prendre de 15 minutes à 24–48 heures, et Mailtrap revérifie selon son propre calendrier. Utilisez Re-check DNS Records pour forcer une vérification, et attendez-vous à ce que certains enregistrements passent au vert avant d'autres.
Construisez votre enregistrement SPF
Mailtrap 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 Mailtrap — 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.