SPF, DKIM et DMARC pour SocketLabs.
SocketLabs authentifie votre domaine au sein de son On-Demand Portal, et sa configuration est réellement différente de celle d'un fournisseur du type « collez cette ligne SPF ». Chaque message que vous envoyez est déjà authentifié SPF et signé DKIM au moment où il quitte la plateforme — mais par défaut cette authentification appartient au domaine propre de SocketLabs, email-od.com, ce qui explique pourquoi le courrier non configuré porte la mention « via email-od.com » et ne peut pas s'aligner sur votre domaine pour DMARC. Pour que SocketLabs envoie au nom de votre domaine, vous ajoutez deux enregistrements sous Configuration → Domain Management : un CNAME de Custom Bounce Domain (qui déplace le return-path sur votre propre sous-domaine afin que SPF s'aligne) et un enregistrement DKIM (un seul CNAME, ou un sélecteur TXT généré, pour que DKIM signe au nom de votre domaine). Une politique DMARC distincte complète l'ensemble. La subtilité importante : la voie SPF recommandée par SocketLabs est le CNAME du bounce domain, et non l'ajout de include:email-od.com à votre SPF racine.
Pourquoi authentifier SocketLabs ?
Authentifier SocketLabs n'est pas une simple formalité — cela détermine si votre courrier atteint la boîte de réception, tout court. Depuis février 2024, Gmail et Yahoo exigent que chaque expéditeur en masse (environ 5 000 messages et plus par jour) passe SPF, DKIM et DMARC avec alignement, et Microsoft a commencé à appliquer les mêmes règles au courrier à fort volume vers Outlook.com/Hotmail en 2025. Le piège spécifique à SocketLabs : par défaut, il authentifie SPF sur son bounce domain email-od.com et signe DKIM avec d=email-od.com. Les deux contrôles PASS sur email-od.com, mais ni l'un ni l'autre ne s'aligne sur votre domaine From, si bien que DMARC échoue à l'alignement, les destinataires voient une étiquette « via email-od.com », et la réputation d'envoi que vous construisez se dilue avec celle de tous les autres expéditeurs SocketLabs non authentifiés au lieu de s'accumuler sur votre propre domaine. Mettre en place un bounce domain personnalisé (SPF s'aligne) plus un DKIM personnalisé (DKIM s'aligne) comble cet écart en deux enregistrements — DMARC passe alors sur les deux mécanismes, l'étiquette « via » disparaît, et votre domaine devient propriétaire de sa réputation.
La réalité SPF pour SocketLabs
SocketLabs est techniquement un fournisseur « include » — include:email-od.com existe et se vérifie via DNS (il se résout en un seul enregistrement plat, v=spf1 ip4:142.0.176.0/20 ip4:… ~all, avec uniquement des plages ip4 et aucun include imbriqué, de sorte qu'il coûterait exactement UNE de vos 10 recherches SPF) — mais ce n'est PAS la voie SPF recommandée par SocketLabs et, à lui seul, il ne produit pas d'alignement DMARC. Voici pourquoi : SPF est évalué par rapport au domaine du return-path (bounce/enveloppe), et non par rapport à votre adresse From visible. Par défaut, le return-path de SocketLabs est email-od.com, donc le contrôle SPF interroge l'enregistrement d'email-od.com et votre SPF racine n'est jamais consulté pour le courrier SocketLabs. SocketLabs implémente plutôt SPF via un Custom Bounce Domain : vous publiez un CNAME sur un sous-domaine de votre propre domaine — par ex. email.yourdomain.com CNAME tracking.socketlabs.com — et comme tracking.socketlabs.com publie lui-même v=spf1 include:email-od.com ~all, déplacer le return-path sur votre sous-domaine fait à la fois PASSER SPF (il hérite des IP autorisées de SocketLabs via ce CNAME) ET L'ALIGNE sur votre domaine organisationnel, le tout sans modifier votre enregistrement SPF racine existant. C'est pourquoi la configuration recommandée n'ajoute aucune recherche à votre SPF racine. Le mécanisme include:email-od.com est une option de ceinture et bretelles : vous pouvez l'ajouter à votre SPF racine (il y autorise aussi les IP d'envoi, au coût d'une recherche) mais il ne donne pas l'alignement à lui seul et n'est pas requis une fois le custom bounce domain en place. Comme toujours, conservez exactement UN enregistrement SPF TXT par domaine — si vous ajoutez l'include, fusionnez-le dans votre unique ligne v=spf1 plutôt que de publier un second enregistrement.
Deux façons de le configurer
CNAME de Custom Bounce Domain (recommandé)
- Déplace le return-path sur un sous-domaine de votre domaine, de sorte que SPF à la fois passe et S'ALIGNE pour DMARC
- N'ajoute aucune recherche DNS à votre SPF racine — il n'y a rien à fusionner ni à aplatir
- Le CNAME vers tracking.socketlabs.com hérite automatiquement des IP autorisées de SocketLabs ; vous ne le re-modifiez jamais quand les IP changent
- Le même CNAME de sous-domaine peut être réutilisé pour marquer en marque blanche vos liens de suivi d'engagement (ouvertures/clics)
include:email-od.com sur votre SPF racine (optionnel)
- Vous ajoutez vous-même v=spf1 include:email-od.com ~all à votre SPF racine
- Coûte une de vos 10 recherches DNS SPF (email-od.com est un enregistrement plat uniquement ip4, donc exactement une)
- Autorise les IP d'envoi sous votre domaine mais N'aligne PAS SPF à lui seul — le return-path reste email-od.com sauf si vous configurez aussi le CNAME de bounce
- Un complément au mieux, jamais un substitut au custom bounce domain
Étape par étape
- 1
Ouvrir Domain Management
Connectez-vous à l'On-Demand Portal, cliquez sur Configuration dans le menu de gauche, choisissez Domain Management, puis sélectionnez le domaine d'envoi que vous souhaitez authentifier (ou cliquez pour l'ajouter). Tout ce qui suit se trouve sur la fiche de ce domaine.
- 2
Démarrer Custom Bounce Domain & SPF
Sur le domaine, ouvrez « Custom Bounce Domain and SPF Authentication ». SocketLabs génère un enregistrement CNAME sur un sous-domaine de votre domaine (quelque chose comme email.yourdomain.com ou bounce.yourdomain.com) dont la cible est tracking.socketlabs.com. C'est ainsi que SocketLabs implémente SPF — il déplace votre return-path sur votre propre domaine afin que SPF s'aligne.
- 3
Publier le CNAME du bounce domain
Chez votre hébergeur DNS, créez un CNAME : Host = le sous-domaine que SocketLabs affiche (par ex. email), Value = tracking.socketlabs.com. Ne le changez pas en enregistrement TXT ou A, et ne touchez pas à votre enregistrement SPF racine existant — c'est ce CNAME qui porte SPF.
- 4
Choisir votre méthode DKIM
De retour sur le domaine, ouvrez la section DKIM. Vous avez deux options : la fonctionnalité CNAME DKIM Signing (la plus simple — SocketLabs détient et fait tourner la clé pour vous) ou la méthode Advanced/TXT via le DKIM Key Generator (vous choisissez un sélecteur et publiez un enregistrement TXT de clé publique). Choisissez-en une ; vous n'avez pas besoin des deux.
- 5
Publier l'enregistrement DKIM
Pour la méthode CNAME, ajoutez un CNAME : Host = dkim._domainkey, Value = dkim._domainkey.email-od.com. Pour la méthode TXT, ajoutez un enregistrement TXT à Host = <selector>._domainkey (le sélecteur que vous avez choisi dans le générateur, alphanumérique et de moins de 10 caractères) avec la valeur v=DKIM1; k=rsa; p=… que SocketLabs affiche. Dans les deux cas, DKIM signera désormais au nom de votre domaine.
- 6
Ajouter l'enregistrement DMARC
SocketLabs ne crée pas DMARC pour vous. Ajoutez un enregistrement TXT à Host = _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 — vous le durcirez plus tard.
- 7
Vérifier dans le portail
Retournez dans Domain Management et cliquez sur « Verify Bounce » pour le custom bounce domain et « Verify » pour DKIM. Le statut du bounce domain devrait indiquer authenticated et DKIM devrait indiquer active. La propagation prend généralement quelques minutes, mais SocketLabs peut prendre jusqu'à 24–48 heures pour confirmer les enregistrements.
- 8
Envoyer un test et lire les en-têtes
Envoyez un message depuis une adresse du domaine configuré vers un compte Gmail, ouvrez-le, et choisissez ⋮ → Afficher l'original. Vous voulez SPF: PASS affichant votre sous-domaine de bounce (pas email-od.com), DKIM: PASS avec d=yourdomain.com, et DMARC: PASS. La mention « via email-od.com » devrait avoir disparu.
Enregistrements à ajouter
SocketLabs 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 | tracking.socketlabs.comCustom Bounce Domain — c'est ce qui porte et ALIGNE SPF. Le libellé du sous-domaine (email/bounce/…) est celui que SocketLabs attribue ; réutilisez-le aussi pour le marquage en marque blanche du suivi d'engagement. | |
| CNAME | dkim._domainkey | dkim._domainkey.email-od.comCNAME DKIM (recommandé, le plus simple) — SocketLabs détient et fait tourner la clé. Le sélecteur est dkim ; d= devient votre domaine, donc DKIM s'aligne. |
| TXT | sl2026._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ…(public key from the DKIM Key Generator)Alternative à la méthode CNAME — n'utilisez la voie DKIM Advanced/TXT que si vous voulez contrôler la clé. Le sélecteur (sl2026 ici) est votre choix : alphanumérique, moins de 10 caractères. Valeur illustrative — le générateur utilise par défaut une clé de 2048 bits, générée par compte. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVous l'ajoutez vous-même — SocketLabs ne le crée jamais. Un par domaine ; commencez à p=none, puis durcissez en quarantine/reject. |
| TXT | @ | v=spf1 include:email-od.com ~allCeinture et bretelles OPTIONNEL uniquement. Non requis si vous configurez le custom bounce domain, et il n'aligne pas SPF à lui seul. Coûte 1 recherche ; fusionnez-le dans votre unique ligne SPF racine si vous l'utilisez. |
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 SocketLabs sur ce budget.
La configuration recommandée de SocketLabs ajoute 0 requête — les 10 restent disponibles pour les expéditeurs qui, eux, ont besoin d'un include:.
DKIM
SocketLabs signe chaque message par défaut, mais avec d=email-od.com, qui ne s'aligne pas sur votre domaine — c'est donc le DKIM personnalisé qui fait réellement fonctionner DKIM pour vous, et il y a deux façons de le configurer. La fonctionnalité CNAME DKIM Signing est la plus simple : vous publiez un seul CNAME, Host = dkim._domainkey.yourdomain.com pointant vers dkim._domainkey.email-od.com, et comme il s'agit d'un CNAME (et non d'une clé que vous collez), SocketLabs garde le contrôle des clés privée et publique et les fait tourner pour vous — vous ne modifiez plus jamais le DNS. Le sélecteur est simplement dkim, et une fois vérifié, SocketLabs signe votre courrier avec d=yourdomain.com afin que DKIM s'aligne. La méthode Advanced/TXT vous donne plus de contrôle : dans Domain Management, vous exécutez le DKIM Key Generator, choisissez un sélecteur (alphanumérique, moins de 10 caractères, par ex. sl2026), et SocketLabs génère la paire de clés — stockant la clé privée dans votre compte et vous remettant la clé publique à publier sous forme d'enregistrement TXT à <selector>._domainkey.yourdomain.com au format v=DKIM1; k=rsa; p=…. Le générateur utilise par défaut une clé de 2048 bits (une option 1024 bits existe, mais laissez-la à 2048 — la clé plus robuste est la norme moderne et SocketLabs recommande de ne pas l'abaisser). Il existe aussi une variante « apportez votre propre enregistrement TXT » où vous fournissez une clé privée générée en externe. Une exigence stricte de la voie TXT : le portail ne vous laissera pas enregistrer tant qu'il ne peut pas résoudre votre clé publique publiée depuis le DNS, et une fois enregistrée, la clé publique n'est plus affichée dans le portail — publiez-la donc d'abord. Une réserve qui s'applique aux DEUX méthodes : votre signature DKIM personnalisée n'est appliquée qu'aux messages dont l'adresse From (la Purported Responsible Address) correspond exactement au domaine configuré — le courrier envoyé depuis tout autre domaine From retombe sur la signature par défaut email-od.com et ne s'alignera pas, alors configurez DKIM pour chaque domaine depuis lequel vous envoyez.
DMARC
DMARC est un enregistrement TXT de politique distinct que SocketLabs ne crée pas — vous le publiez vous-même chez votre hébergeur DNS. Ajoutez un enregistrement TXT à _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 pendant que vous observez les rapports agrégés (rua) pour confirmer que le courrier SocketLabs passe SPF et DKIM alignés sur votre domaine. Comme le custom bounce domain vous donne l'alignement SPF et le DKIM personnalisé l'alignement DKIM, un domaine SocketLabs correctement configuré passe DMARC sur les DEUX mécanismes — la configuration résiliente qui survit au transfert, puisqu'un transfert qui casse SPF laisse tout de même une signature DKIM alignée. Surveillez les rapports pendant une semaine ou deux, assurez-vous que chaque expéditeur légitime (SocketLabs plus tout autre outil sur le domaine) s'authentifie, puis durcissez la politique en p=quarantine et finalement p=reject. Conservez exactement un enregistrement _dmarc pour l'ensemble du domaine organisationnel, quel que soit le nombre d'expéditeurs que vous utilisez ; n'ajoutez jamais un second enregistrement DMARC uniquement pour SocketLabs.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas aux seuls badges « authenticated » et « active » du portail — confirmez-le sur un message réel. Envoyez un test depuis une adresse du domaine configuré vers une boîte Gmail, ouvrez-le, et choisissez ⋮ → Afficher l'original : vous voulez SPF: PASS affichant votre sous-domaine de bounce (par ex. email.yourdomain.com, PAS email-od.com), DKIM: PASS avec d=yourdomain.com, et DMARC: PASS. Le signe révélateur d'un échec est SPF/DKIM affichant encore email-od.com, ce qui signifie que le bounce domain et/ou le DKIM personnalisé ne sont pas encore actifs, ou que vous avez envoyé depuis un domaine From non configuré. Vous pouvez contrôler les enregistrements bruts avec dig CNAME email.yourdomain.com (doit se résoudre en tracking.socketlabs.com), dig CNAME dkim._domainkey.yourdomain.com (ou dig TXT <selector>._domainkey.yourdomain.com pour la méthode TXT), et dig TXT _dmarc.yourdomain.com. Passez ensuite votre domaine dans le contrôle de santé du domaine de Qualisend pour confirmer que chaque enregistrement se résout proprement, et une fois que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC — SocketLabs devrait apparaître comme une source alignée et entièrement conforme.
Pièges courants
- Couverture
L'étiquette par défaut « via email-od.com » signifie que vous n'êtes pas encore aligné : tant que vous ne configurez pas À LA FOIS un custom bounce domain et un DKIM personnalisé, SocketLabs s'authentifie comme email-od.com, donc SPF et DKIM passent mais DMARC échoue à l'alignement. L'étiquette ne disparaît qu'une fois que les deux pointent vers votre domaine.
- Configuration DNS
Ajouter include:email-od.com à votre SPF racine n'est PAS la solution à lui seul. Il autorise les IP d'envoi mais le return-path reste email-od.com sauf si vous publiez le CNAME du bounce domain — et c'est le CNAME de bounce, pas l'include, qui aligne réellement SPF. Ne sautez pas le CNAME en pensant que l'include suffit.
- Couverture
Le DKIM personnalisé ne signe que le courrier dont l'adresse From correspond exactement au domaine configuré (la Purported Responsible Address). Envoyez depuis un domaine From différent et SocketLabs retombe silencieusement sur la signature par défaut email-od.com, donc DKIM ne s'alignera pas — configurez chaque domaine d'envoi.
- Configuration DNS
Certains fournisseurs DNS n'acceptent pas de tiret bas dans un host CNAME, ce qui bloque la méthode CNAME dkim._domainkey. Si le vôtre le refuse, utilisez plutôt la voie DKIM Advanced/TXT (DKIM Key Generator) — l'enregistrement TXT de clé publique contourne la limitation du tiret bas dans les CNAME.
- Configuration DNS
Le proxy Cloudflare casse les deux CNAME : réglez le CNAME du bounce domain et le CNAME DKIM sur « DNS only » (nuage gris). Un CNAME proxifié en nuage orange ne se résoudra pas en tracking.socketlabs.com / email-od.com et la vérification échoue.
- Couverture
Les sous-comptes s'authentifient séparément. Le modèle de sous-comptes de SocketLabs implique que chaque sous-compte a besoin de son propre custom bounce domain et de sa propre authentification DKIM — authentifier le compte principal ne les couvre pas.
- Configuration DNS
La vérification peut traîner 24–48 heures. La propagation prend généralement quelques minutes, mais SocketLabs re-contrôle le CNAME/TXT avec un délai, donc « authenticated »/« active » peut ne pas basculer immédiatement même quand votre DNS est déjà correct — vérifiez avec Afficher l'original plutôt que d'attendre le badge.
- Configuration DNS
Doublement du champ Host : les registrars qui ajoutent automatiquement votre domaine transforment dkim._domainkey.yourdomain.com en dkim._domainkey.yourdomain.com.yourdomain.com. Saisissez uniquement le libellé (email, dkim._domainkey, <selector>._domainkey) si votre panneau ajoute le domaine à votre place.
- Casse l'authentification
Conservez exactement un enregistrement SPF et un enregistrement DMARC par domaine. Si vous ajoutez le include:email-od.com optionnel, fusionnez-le dans votre unique ligne v=spf1 — deux enregistrements SPF constituent un PermError, tout comme un second enregistrement _dmarc.
Construisez votre enregistrement SPF
SocketLabs 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 SocketLabs — 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.