SPF, DKIM et DMARC pour Customer.io.
Customer.io authentifie votre domaine à l'ancienne, de manière transparente : pas d'assistant en un clic ni de délégation faisant tout transiter par des CNAME. La plateforme vous fournit un petit ensemble d'enregistrements DNS à publier sur un sous-domaine d'envoi dédié, puis les vérifie. Vous ajoutez un unique enregistrement MX comportant deux noms d'hôte (ce qui donne à Customer.io un Return-Path personnalisé sur votre domaine pour les retours de rebond et de spam), un enregistrement SPF TXT utilisant le mécanisme partagé include:customeriomail.com, ainsi qu'un enregistrement DKIM TXT dont Customer.io génère la clé pour vous. DMARC constitue un quatrième enregistrement que vous ajoutez vous-même, sur votre domaine racine. L'ensemble se gère dans Workspace Settings, sous Email, sur la page Sending Domains. Une fois que SPF et DKIM affichent tous deux le vert, Customer.io envoie pleinement au nom de votre propre domaine au lieu de s'appuyer sur customeriomail.com.
Pourquoi authentifier Customer.io ?
Customer.io est une plateforme de messagerie comportementale à fort volume — newsletters, campagnes de cycle de vie, parcours transactionnels — de sorte que presque chaque compte franchit les seuils d'expéditeur en masse qui déterminent désormais le placement en boîte de réception. 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 Microsoft a commencé à imposer la même chose sur le courrier à fort volume vers Outlook.com/Hotmail/Live en 2025. Customer.io est plus strict que la plupart des ESP à ce sujet : il n'enverra pas depuis un domaine tant que SPF et DKIM ne sont pas tous deux vérifiés — un domaine non authentifié ne peut tout simplement pas envoyer, et si l'un des enregistrements se casse par la suite, les envois échouent. Il existe également un véritable avantage d'alignement qui mérite qu'on le mette en place. Parce que Customer.io provisionne un Return-Path personnalisé sur votre propre sous-domaine d'envoi (c'est à cela que sert l'enregistrement MX), la vérification SPF s'exécute par rapport à votre domaine, et pas seulement customeriomail.com — donc, contrairement à la configuration par défaut de Mailchimp ou Klaviyo, où seul DKIM peut porter DMARC, un domaine Customer.io correctement configuré peut passer DMARC sur les deux mécanismes. C'est la configuration résiliente qui survit au transfert, et cela signifie que la réputation d'envoi que vous bâtissez s'accumule sur votre propre domaine.
La réalité SPF pour Customer.io
Customer.io est un authentique fournisseur « include » — vous publiez un unique enregistrement SPF TXT contenant le mécanisme partagé include:customeriomail.com (l'enregistrement complet est v=spf1 include:customeriomail.com ~all, se terminant par ~all exactement comme l'affiche le tableau de bord de Customer.io). Mais deux réalités propres à Customer.io changent où et comment vous l'ajoutez. Premièrement, cet enregistrement ne va pas sur votre domaine racine — Customer.io recommande (et attend de fait) un sous-domaine d'envoi dédié tel que mail.yourbrand.com ou email.yourbrand.com, et les enregistrements SPF, DKIM et MX y résident tous. C'est délibéré : parce que l'enregistrement MX place le Return-Path de Customer.io sur votre sous-domaine, l'expéditeur d'enveloppe est sur votre domaine, donc SPF s'ALIGNE réellement et peut contribuer à un passage DMARC — ce que les ESP propriétaires du Return-Path ne peuvent pas faire. Deuxièmement, l'include n'est pas plat. Une consultation en direct de customeriomail.com renvoie v=spf1 ip4:50.31.36.179 include:sendgrid.net ~all, et sendgrid.net imbrique à son tour include:ab.sendgrid.net — donc include:customeriomail.com se résout en environ 3 consultations DNS vers la limite de 10 fixée par la RFC 7208, et non la seule que la plupart des guides prétendent. Le garder sur son propre sous-domaine d'envoi isole entièrement ce coût du budget SPF de votre domaine racine, ce qui est tout l'intérêt de l'approche par sous-domaine. Conservez exactement un enregistrement SPF sur le sous-domaine d'envoi, et n'y fusionnez pas d'autres expéditeurs — ce sous-domaine appartient à Customer.io.
Deux façons de le configurer
Sous-domaine d'envoi dédié (recommandé)
- Tous les enregistrements de Customer.io — MX, SPF et DKIM — résident sur un seul sous-domaine comme mail.yourbrand.com
- Le Return-Path personnalisé basé sur MX reste sur le sous-domaine, de sorte qu'il ne peut jamais interférer avec votre courrier entrant principal
- Le include:customeriomail.com imbriqué à ~3 consultations reste en dehors du budget SPF de 10 consultations de votre domaine racine
- Le volume marketing/cycle de vie bâtit une réputation sur un sous-domaine isolé, protégeant votre domaine racine
Authentifier votre domaine racine (à éviter)
- Customer.io n'exige pas le domaine racine et ne le recommande pas
- L'enregistrement MX à deux hôtes siégerait sur votre racine, en concurrence avec votre véritable MX entrant
- L'include imbriqué consomme ~3 des 10 consultations SPF de votre racine, aux côtés de Google Workspace, M365 et de tout autre expéditeur
- Un seul envoi marketing bruyant peut faire chuter la réputation d'envoi de tout votre domaine
Étape par étape
- 1
Ouvrez la page Sending Domains
Connectez-vous, cliquez sur l'icône Settings et allez dans Workspace Settings → Email → Sending Domains. Cette page unique gère l'ajout d'un domaine, l'affichage de ses enregistrements DNS et leur vérification. SPF, DKIM, MX et le CNAME de suivi des liens y sont tous affichés ; DMARC ne l'est pas — vous l'ajoutez séparément chez votre hébergeur DNS.
- 2
Ajoutez votre sous-domaine d'envoi
Cliquez sur Add Sending Domain et saisissez un sous-domaine dédié, pas votre racine — mail.yourbrand.com ou email.yourbrand.com est la convention. C'est l'envoi depuis un sous-domaine qui permet à Customer.io d'y placer un Return-Path personnalisé, et cela garde l'enregistrement MX hors de votre domaine racine.
- 3
Affichez les enregistrements DNS
Sur l'onglet Authentication du domaine, Customer.io affiche les enregistrements exacts à publier : un enregistrement MX comportant deux noms d'hôte, un enregistrement SPF TXT, un enregistrement DKIM TXT (la clé est générée pour votre compte) et — sur l'onglet Link Tracking — un CNAME facultatif pour le suivi des liens de marque. Copiez chaque Host/Name et Value exactement comme affiché ; le sélecteur DKIM et les deux noms d'hôte MX sont spécifiques à votre compte.
- 4
Ajoutez l'enregistrement MX à deux hôtes
Chez votre hébergeur DNS, sur le sous-domaine d'envoi (hôte mail), créez l'unique enregistrement MX avec les deux noms d'hôte que Customer.io indique, à la priorité qu'il spécifie. Cet MX n'existe que pour donner à Customer.io un Return-Path/adresse de rebond personnalisé sur votre domaine — il ne reçoit pas votre courrier normal, et parce qu'il est sur un sous-domaine, il ne peut pas affecter la distribution entrante vers votre domaine racine.
- 5
Ajoutez l'enregistrement SPF TXT
Sur le même sous-domaine (hôte mail), ajoutez un enregistrement TXT : v=spf1 include:customeriomail.com ~all. Conservez uniquement cet enregistrement SPF sur le sous-domaine et n'y ajoutez pas les mécanismes d'autres expéditeurs — ce sous-domaine appartient à Customer.io. Terminez par ~all comme l'affiche le tableau de bord.
- 6
Ajoutez l'enregistrement DKIM TXT
Ajoutez l'enregistrement DKIM TXT exactement comme Customer.io l'a généré : l'hôte est un sélecteur sous votre sous-domaine (comme selector._domainkey.mail) et la valeur est v=DKIM1; k=rsa; p=<clé publique>. Il s'agit d'un enregistrement TXT que vous collez, pas d'un CNAME — il est donc statique, et Customer.io ne le fait pas tourner silencieusement pour vous.
- 7
Facultatif : ajoutez le CNAME de suivi des liens
Si vous voulez que les liens à clic suivi soient marqués à votre domaine plutôt qu'à customeriomail.com, ajoutez le CNAME affiché sur l'onglet Link Tracking (un sous-domaine de suivi pointant vers Customer.io). Ce n'est pas requis pour l'authentification, mais l'omettre laisse les liens suivis sur customeriomail.com, ce qui affaiblit l'alignement de marque.
- 8
Publiez votre enregistrement DMARC sur la racine
Customer.io ne crée jamais DMARC. Ajoutez un enregistrement TXT à _dmarc sur votre domaine RACINE (pas le sous-domaine d'envoi) : v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com. p=none est en mode surveillance seule, donc rien ne change pendant que vous confirmez l'alignement ; le sous-domaine d'envoi hérite automatiquement de cette politique.
- 9
Cliquez sur Verify domain
De retour sur l'onglet Authentication, cliquez sur Verify (les coches grises passent au vert lorsque les enregistrements se résolvent). La propagation prend généralement quelques minutes mais peut aller jusqu'à 24–48 heures. Il vous faut des coches vertes sur SPF et DKIM en particulier — Customer.io exige impérativement les deux avant d'envoyer depuis le domaine ; les enregistrements MX et de suivi des liens prennent en charge le Return-Path et la marque, mais SPF+DKIM sont la condition d'accès.
- 10
Envoyez un test et lisez les en-têtes
Envoyez une campagne ou un broadcast depuis une adresse From sur le sous-domaine authentifié, ouvrez-le dans Gmail et choisissez ⋮ → Show original. Confirmez SPF: PASS (enveloppe sur votre sous-domaine), DKIM: PASS avec d=yourbrand.com (pas customeriomail.com) et DMARC: PASS. Passez ensuite le sous-domaine dans une vérification de la santé du domaine pour confirmer que chaque enregistrement se résout.
Enregistrements à ajouter
Customer.io 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 |
|---|---|---|
| MX | mxa.customeriomail.comPremier de deux noms d'hôte sur un unique enregistrement MX — le Return-Path personnalisé de Customer.io pour les retours de rebond/spam, sur le sous-domaine d'envoi. À titre indicatif : copiez les deux noms d'hôte et la priorité exacts depuis l'onglet Authentication. | |
| MX | mxb.customeriomail.comSecond nom d'hôte sur le même enregistrement MX. À titre indicatif — utilisez la valeur et la priorité exactes que Customer.io affiche. | |
| TXT | v=spf1 include:customeriomail.com ~allSPF sur le sous-domaine d'envoi — un enregistrement SPF par hôte. include:customeriomail.com s'imbrique en ~3 consultations (via sendgrid.net → ab.sendgrid.net) ; se termine par ~all comme l'affiche le tableau de bord. | |
| TXT | selector._domainkey.mail | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…(public key from Customer.io)DKIM TXT — Customer.io génère la paire de clés et affiche la valeur complète à coller. À titre indicatif : le sélecteur et la clé réels sont propres à chaque compte sur l'onglet Authentication. C'est un TXT statique, pas un CNAME délégué. |
| CNAME | customeriomail.comSuivi facultatif des liens de marque, sur un sous-domaine de suivi — copiez l'hôte/la cible exacts depuis l'onglet Link Tracking. Non requis pour la vérification SPF/DKIM. | |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.comVous l'ajoutez vous-même sur le domaine RACINE — Customer.io ne le crée jamais. Un seul par domaine ; le sous-domaine d'envoi en hérite. Commencez à p=none. |
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 Customer.io sur ce budget.
Customer.io utilise 3 de vos 10 requêtes ; les mécanismes ip4: et ip6: sont gratuits.
DKIM
DKIM pour Customer.io est un enregistrement TXT que vous publiez, pas un CNAME délégué. Lorsque vous ajoutez un domaine d'envoi, Customer.io génère une paire de clés DKIM pour celui-ci et vous présente un unique enregistrement DKIM TXT : l'hôte est un sélecteur sous votre sous-domaine d'envoi (comme selector._domainkey.mail.yourbrand.com) et la valeur est v=DKIM1; k=rsa; p=<clé publique>. Vous collez ce TXT exactement tel qu'affiché ; Customer.io conserve la clé privée correspondante et signe votre courrier sortant avec elle sous la forme d=yourbrand.com — donc la signature s'aligne sur votre domaine et peut porter un passage DMARC. Deux choses distinguent cela du DKIM délégué par CNAME utilisé par SendGrid ou Microsoft 365. Premièrement, parce qu'il s'agit d'un enregistrement TXT statique plutôt que d'un CNAME pointant vers le fournisseur, Customer.io ne fait pas tourner la clé silencieusement en coulisses — si vous régénérez ou faites tourner la clé dans le tableau de bord, vous devez republier vous-même la nouvelle valeur TXT, sans quoi la signature se casse. Deuxièmement, DKIM n'est ici ni facultatif ni « au mieux » : Customer.io exige que SPF et DKIM soient tous deux vérifiés avant d'envoyer depuis le domaine, et si le DKIM TXT est absent, tronqué ou déformé par votre panneau DNS, le domaine repasse à l'état non vérifié et les envois s'arrêtent. Publiez l'enregistrement sur le sous-domaine d'envoi exactement comme Customer.io le formate, attendez la propagation, puis cliquez sur Verify.
DMARC
DMARC est un enregistrement de politique distinct que Customer.io ne crée pas pour vous — vous le publiez vous-même, et il va sur votre domaine RACINE, pas sur le sous-domaine d'envoi. Ajoutez un enregistrement TXT à _dmarc.yourbrand.com commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com. p=none est en mode surveillance seule : il ne change rien à la distribution pendant que les destinataires vous envoient par e-mail des rapports agrégés (rua) afin que vous puissiez confirmer que Customer.io passe SPF et DKIM alignés sur votre domaine. C'est là que la conception par sous-domaine de Customer.io porte ses fruits — DMARC utilise l'alignement relâché par défaut (aspf=r, adkim=r), donc la signature DKIM sur mail.yourbrand.com et le SPF/Return-Path sur ce sous-domaine s'alignent tous deux sur votre domaine organisationnel yourbrand.com, et votre courrier Customer.io passe DMARC sur les deux mécanismes. Conservez exactement un enregistrement _dmarc sur la racine ; votre sous-domaine d'envoi hérite automatiquement de la politique parente, donc n'ajoutez pas un second enregistrement _dmarc sur le sous-domaine (en ajouter un là est une erreur courante qui peut casser l'héritage). Surveillez les rapports rua pendant une semaine ou deux, jusqu'à ce que chaque source légitime — Customer.io plus vos autres expéditeurs — s'authentifie, puis durcissez la politique vers p=quarantine et, à terme, p=reject.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas aux seules coches du tableau de bord — confirmez-le sur un vrai message. Dans l'onglet Authentication de Customer.io, vous voulez des coches vertes sur SPF et DKIM (les deux enregistrements dont Customer.io conditionne l'envoi) ; le MX prend en charge le Return-Path et le CNAME prend en charge les liens de marque. Envoyez ensuite un broadcast ou une campagne depuis une adresse From sur le sous-domaine authentifié, ouvrez-le dans Gmail et choisissez ⋮ → Show original : vous recherchez SPF: PASS avec l'enveloppe/Return-Path sur votre sous-domaine, DKIM: PASS signé par d=yourbrand.com (l'échec révélateur est d=customeriomail.com, signifiant que le DKIM personnalisé n'a pas pris) et DMARC: PASS. Contrôlez ponctuellement les enregistrements bruts avec dig TXT mail.yourbrand.com, dig TXT selector._domainkey.mail.yourbrand.com et dig TXT _dmarc.yourbrand.com. Enfin, passez le sous-domaine d'envoi dans la vérification de la santé du domaine de Qualisend pour confirmer que le SPF (et ses consultations imbriquées), le DKIM TXT, le MX et votre DMARC racine se résolvent tous proprement, et une fois que les rapports agrégés commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC — Customer.io devrait apparaître comme une source alignée et passante.
Pièges courants
- Casse l'authentification
Customer.io exige impérativement que SPF ET DKIM soient tous deux vérifiés avant d'envoyer depuis un domaine — la plupart des ESP envoient sur une authentification partielle, pas Customer.io. Si l'un des enregistrements est absent ou déformé, le domaine s'affiche comme non vérifié et les envois échouent, ils ne se contentent pas de paraître sans marque.
- Configuration DNS
Publiez tout sur un SOUS-DOMAINE D'ENVOI dédié (mail.yourbrand.com), jamais votre racine. L'enregistrement MX à deux hôtes en particulier doit rester sur le sous-domaine — placez-le sur votre racine et vous redirigeriez la gestion des rebonds pour tout votre domaine et risqueriez votre véritable courrier entrant.
- Couverture
L'enregistrement MX ne sert pas à recevoir votre courrier normal — il n'existe que pour donner à Customer.io un Return-Path personnalisé sur votre domaine pour les retours de rebond et de spam. Ne vous alarmez pas à l'idée que vous « changez votre MX » ; il est sur un sous-domaine qu'aucune boîte aux lettres humaine n'utilise.
- Configuration DNS
include:customeriomail.com n'est PAS une seule consultation DNS — une consultation en direct montre qu'il imbrique include:sendgrid.net, qui imbrique include:ab.sendgrid.net, donc il se résout en environ 3 consultations. Sur un sous-domaine dédié, c'est isolé ; si vous le repliez un jour dans un SPF racine partagé, il entre en concurrence avec tout autre expéditeur face à la limite de 10 consultations.
- Configuration DNS
DKIM ici est un enregistrement TXT statique, pas un CNAME qui tourne automatiquement. Customer.io ne le fait pas tourner pour vous — si vous régénérez la clé dans le tableau de bord, vous devez republier la nouvelle valeur TXT, sinon la signature se casse.
- Configuration DNS
Doublement du champ Host sur les sous-domaines : de nombreux registraires ajoutent automatiquement votre zone, donc saisir mail.yourbrand.com produit mail.yourbrand.com.yourbrand.com. Saisissez uniquement le libellé que le panneau attend (mail, selector._domainkey.mail) s'il ajoute le domaine à votre place.
- Couverture
Placez DMARC sur la RACINE (_dmarc.yourbrand.com), pas sur le sous-domaine d'envoi. Le sous-domaine hérite de la politique racine via l'alignement relâché ; ajouter un second _dmarc sur le sous-domaine est une erreur courante qui peut casser l'héritage.
- Configuration DNS
Omettre le CNAME de suivi des liens ne pose pas de problème pour l'authentification, mais vos liens à clic suivi restent sur customeriomail.com au lieu de votre domaine — ce qui affaiblit l'alignement de marque et peut paraître moins digne de confiance aux destinataires et aux filtres.
Construisez votre enregistrement SPF
Customer.io 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 Customer.io — 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.