Envoyez depuis les deux. Gardez sur votre domaine racine l’adresse que vos destinataires voient, et déplacez l’identité technique d’envoi, c’est-à-dire le Return-Path et le domaine de signature DKIM, sur un sous-domaine réservé à un seul type de courrier.
Si cela se lit comme un choix binaire, c’est que « depuis quel domaine est-ce que j’envoie » représente en réalité quatre décisions distinctes, et que presque tous les guides en déplacent une sans dire laquelle. Une fois les quatre séparées, l’essentiel du désaccord des fils de discussion se dissout, et l’anxiété avec lui : si vous envoyez moins de 5 000 messages marketing par mois environ, ou si votre volume marketing ne domine pas le reste de votre courrier, la bonne réponse consiste à ne rien toucher et à passer l’après-midi sur votre liste.
Voici la décision complète, avant le raisonnement qui la sous-tend.
| Votre situation | Ce qu’il faut faire |
|---|---|
| Vous n’envoyez pas encore, ou moins de 5 000 messages marketing par mois environ | Restez sur le domaine racine. Publiez correctement SPF, DKIM et DMARC, et gardez la liste propre. Couper en deux un petit signal vous laisse deux identités trop peu observées au lieu d’une seule bien chaude. |
| Votre volume marketing représente plusieurs fois vos courriers d’entreprise et transactionnels réunis | Séparez. Enveloppe marketing et DKIM sur news.yourbrand.com, transactionnel sur txn.yourbrand.com, le courrier d’entreprise reste sur la racine, et tout From: visible reste sur la racine. |
| Vous envoyez déjà depuis la racine sans problème, avec un taux de spam dans Postmaster Tools sous 0,10 % | Ne migrez pas. Vous abandonneriez une identité d’envoi chaude pour acheter un bénéfice que vous ne pouvez pas mesurer aujourd’hui. Ajoutez le sous-domaine au prochain changement de plateforme, quand la montée en charge aura lieu de toute façon. |
| Vous envoyez déjà depuis la racine et vos réponses individuelles arrivent dans les spams | Séparez, en sachant que la séparation seule ne règle rien. Le comportement qui a causé les dégâts voyage avec vous. |
| Votre plateforme ne peut pas aligner sur un sous-domaine | Restez sur la racine, ou changez d’abord de palier chez la plateforme. Un sous-domaine qui ne peut pas aligner vaut moins qu’un domaine racine qui peut. |
| Prospection à froid | Un domaine distinct, pas un sous-domaine. Ici la réponse s’inverse vraiment, et cela vous coûte quelque chose. |
Un sous-domaine, c’est news.yourbrand.com. Un domaine sosie, c’est yourbrand-news.com
Un sous-domaine vit sous un domaine que vous possédez déjà, personne hors de votre organisation ne peut donc en créer un, alors qu’un domaine sosie ou « cousin » est un enregistrement distinct que les destinataires et les filtres n’ont aucun moyen de vous rattacher. La moitié des conseils contradictoires sur ce sujet vient de gens qui emploient le mot « domaine » pour les deux.
Votre domaine organisationnel est le nom enregistrable que vous payez, yourbrand.com. Tout ce qui se trouve à sa gauche est un sous-domaine que vous créez avec un enregistrement DNS et sans achat supplémentaire : news.yourbrand.com, txn.yourbrand.com, links.yourbrand.com. Un domaine cousin comme yourbrand-news.com ou yourbrandmail.com est un second enregistrement sans aucune relation cryptographique ni administrative avec le premier.
Cette distinction est l’argument le plus fort en faveur des sous-domaines, et elle n’a rien à voir avec la notation de réputation. Un sous-domaine ne peut pas être imité de l’extérieur. M3AAWG déconseille les domaines cousins pour exactement cette raison : ils ressemblent à des campagnes d’hameçonnage aux yeux des destinataires comme des systèmes antiabus, parce que c’est précisément ce que les attaquants enregistrent. Les trois enregistrements dont un nom d’envoi a besoin sont les mêmes dans les deux cas, et l’authentification des e-mails fonctionne à l’identique sur un sous-domaine.
Un mythe à écarter avant la mécanique. Changer le nom de la boîte devant le @, de info@ à hello@, n’est pas un sous-domaine et ne sépare rien. Tous les identifiants de réputation que publient les fournisseurs de messagerie sont un domaine ou une adresse IP.
Un message transporte quatre domaines, et un seul fait débat
Chaque message que vous envoyez expose quatre domaines modifiables indépendamment : le domaine From: visible, le domaine Return-Path de l’enveloppe contre lequel SPF est réellement vérifié, le domaine de signature DKIM dans la balise d= et le nom d’hôte de vos liens tracés. « Utilisez un sous-domaine » veut dire au moins quatre choses différentes selon celui qui bouge.
Ce cadre des quatre surfaces vient de Laura Atkins, chez Word to the Wise, et il dissout à lui seul l’essentiel de la discussion.
| Emplacement du domaine | Où il vit | Visible par le destinataire | À quoi il sert |
|---|---|---|---|
Domaine From: visible | l’en-tête From: | Oui, c’est l’adresse affichée dans la boîte | La cible d’alignement de DMARC, et ce que lisent les destinataires et les filtres grand public |
| Return-Path de l’enveloppe | le MAIL FROM de SMTP, affiché comme Return-Path: | Seulement s’ils ouvrent les détails | SPF est évalué contre lui et rien d’autre, plus le routage des bounces |
| Domaine de signature DKIM | d= dans l’en-tête DKIM-Signature | Non | L’identité qui assume la responsabilité du message, et ce à quoi est rattaché le rapport de réputation de domaine de Google |
| Hôte des liens et du tracking | les noms d’hôte du corps HTML | Dans la barre d’état, au survol | Lu dans le corps par les blacklists de domaines lors de l’inspection du contenu |
Trois de ces quatre peuvent être un sous-domaine pendant que le From: visible reste sur votre domaine racine. Ce n’est pas un compromis, c’est ce que les standards prévoient. L’exemple détaillé de M3AAWG associe un From: en service@mybrand.com à un Return-Path en bounce@bounce.mybrand.com, et il passe DMARC parce que l’alignement relâché exige seulement que les domaines organisationnels correspondent.
J’appelle l’audit ci-dessous le contrôle Unspam des quatre domaines : lisez quatre valeurs dans un seul message délivré et vous saurez exactement ce que votre configuration actuelle isole. Cela prend environ une minute avec l’Email Header Analyzer gratuit.
| Lisez ceci | Une séparation saine ressemble à ça | Si cela ressemble plutôt à ça |
|---|---|---|
From: | news@yourbrand.com | Le domaine de la plateforme elle-même, autrement dit vous n’envoyez pas du tout en votre nom |
Return-Path: | ...@news.yourbrand.com | ...@sendgrid.net, ...@mcsv.net, ...@hubspotemail.net : SPF ne peut pas aligner, et DMARC passe sur DKIM seul |
DKIM-Signature: d= | news.yourbrand.com ou yourbrand.com | Le domaine de la plateforme, autrement dit la réputation que vous construisez appartient à votre prestataire |
| hôte des liens tracés | links.yourbrand.com | Un hôte de tracking mutualisé du prestataire, vous partagez donc une surface de blacklist avec tous ses autres clients |
Cette dernière ligne est une décision distincte avec ses propres conséquences, traitée dans tracking des liens et délivrabilité.
Ce qu’un sous-domaine d’envoi isole, et ce qui passe outre
Un sous-domaine d’envoi vous achète une authentification séparée, un reporting séparé et un identifiant de réputation distinct que les récepteurs documentent eux-mêmes comme évaluable indépendamment. Ce qu’il ne vous achète pas, c’est un pare-feu, et ce n’est pas une page blanche.
Ce qui se sépare vraiment
SPF ne s’hérite pas. Chaque enregistrement SPF se trouve sur le nom exact auquel il s’applique, news.yourbrand.com est donc gouverné par son propre enregistrement ou par aucun.
DKIM est ce que le signataire choisit. La clé est récupérée à <selector>._domainkey.<the d= domain>, l’identité signataire est donc un choix de configuration délibéré plutôt qu’une propriété du message.
Le reporting se fait par domaine authentifié. Le rapport de réputation de domaine de Google ne couvre que le domaine exact utilisé pour l’authentification DKIM ou SPF, et les sous-domaines peuvent être ajoutés à Postmaster Tools comme propriétés indépendantes. Yahoo dit sans détour que chaque IP et chaque domaine DKIM a une réputation, et ses bonnes pratiques demandent aux expéditeurs de séparer les flux par fonction.
Les standards le recommandent nommément. La RFC 5863 conseille des sous-domaines d= différents pour des flux de trafic différents, et prend marketing.example.com et transaction.example.com en exemple, précisément pour que les récepteurs puissent faire des évaluations différenciées. Microsoft va plus loin et recommande un sous-domaine pour le courrier en masse, avec la raison énoncée franchement : vous ne voulez pas que les problèmes du courrier de ces services affectent la réputation du courrier envoyé par les utilisateurs de votre domaine principal. C’est le soutien documenté par un fournisseur le plus fort qui existe, et il vaut la peine de savoir que les consignes aux expéditeurs de Google n’emploient pas une seule fois le mot « sous-domaine ».
Ce qui franchit la frontière quoi qu’il arrive
Six mécanismes ignorent complètement la frontière du sous-domaine, et à eux seuls ils expliquent tous les cas où un expéditeur a fait la séparation correctement et s’est fait mal quand même.
| Mécanisme | Sens | Ce que cela veut dire |
|---|---|---|
| IP d’envoi mutualisées | Dans les deux sens | Deux sous-domaines sur un même pool d’IP ne sont séparés chez aucun récepteur qui filtre surtout sur l’IP |
| Hôte de tracking de clics mutualisé | Dans les deux sens | Un domaine From: irréprochable peut quand même être filtré sur l’hôte du lien, parce que les blacklists lisent les domaines dans le corps |
| Inscription de domaine sur blacklist | Du parent vers l’enfant | Une inscription du domaine enregistrable renvoie « listé » pour chaque sous-domaine situé dessous |
| Statut de conformité Google | De l’enfant vers le parent | La conformité est rapportée pour les domaines primaires seulement, à partir des données de leurs sous-domaines |
| Le seuil d’expéditeur en masse de Google | De l’enfant vers le parent | Les 5 000 messages par jour sont comptés sur tout le domaine primaire, et le classement n’expire jamais |
Un From: resté sur la racine | De l’enfant vers le parent | Si seule l’enveloppe a bougé, le domaine que les destinataires voient et contre lequel ils portent plainte reste votre racine |
L’arithmétique de Google rend le seuil d’expéditeur en masse concret : 2 500 messages par jour depuis votre racine plus 2 500 depuis un sous-domaine font de vous un expéditeur en masse, définitivement. Séparer les flux ne sépare pas ce comptage. L’ensemble complet des obligations qui en découlent se trouve dans les exigences pour expéditeurs de Gmail et Yahoo.
La protection est asymétrique, et elle joue dans le bon sens
Une inscription sur news.yourbrand.com n’inscrit pas automatiquement yourbrand.com, alors qu’une inscription sur yourbrand.com renvoie « listé » pour chaque sous-domaine situé dessous, y compris celui qui transporte vos reçus. Spamhaus liste au niveau du domaine principal et le joker n’agit que vers le bas.
Pour la plupart des expéditeurs cette asymétrie joue dans le bon sens, parce que le flux le plus susceptible de se faire inscrire est celui de masse, et que le courrier que vous voulez le moins perdre est tout le reste. Elle explique aussi pourquoi « un sous-domaine protège mon domaine principal » et « la séparation de réputation par sous-domaines n’existe pas » sont deux positions défendables : la première parle du sens qui marche, la seconde de celui qui ne marche pas.
La blacklist elle-même n’est qu’un mécanisme parmi plusieurs, et les contrôles de domaine qui la révèlent tournent à la demande plutôt qu’en continu. Parmi les domaines que nous testons, 6 % figurent sur une blacklist d’IP, et une inscription d’IP se fiche de savoir de lequel de vos domaines venait le message.
Ce que personne ne documente, c’est justement la partie que les expéditeurs veulent le plus connaître : le poids de la réputation d’un domaine parent sur celle d’un enfant dans la décision de filtrage elle-même. La RFC 5863 concède le point au lieu de le trancher, en observant qu’un récepteur pourrait n’utiliser qu’une portion droite de l’identifiant et que le signataire ne peut pas savoir laquelle. Traitez tout chiffre assuré à ce sujet comme une invention.
Ce qui arrive au courrier de vos salariés quand une campagne tourne mal
Le courrier quotidien de votre domaine racine peut vraiment commencer à arriver dans les spams à cause d’un envoi marketing, et les mécanismes sont énumérables, pas mystérieux. C’est l’échec qui rend toute la question intéressante, et celui que les guides concurrents sautent.
Il y a quatre voies. Des IP d’envoi mutualisées, les deux flux n’ayant donc jamais été séparés à la couche qui comptait. Un dossier de conformité tenu sur votre domaine primaire, alimenté par les données du sous-domaine. Une inscription sur blacklist tombée sur le domaine enregistrable et descendue par le joker. Et un From: visible qui n’a jamais quitté la racine, de loin la plus fréquente des quatre.
La forme que rapportent les expéditeurs est toujours la même : un flux de notifications à faible volume récolte une poignée de plaintes, ce qui fait un grand pourcentage sur un petit dénominateur, et les réponses de l’entreprise restent dans les spams pendant des semaines. L’alias « Send As » de Google Workspace aggrave la chose en plaçant le courrier des salariés et celui des campagnes sur la même identité visible, un schéma traité dans le guide de délivrabilité Mailchimp.
Les trois flux, et d’où chacun devrait partir
Séparez le courrier d’entreprise, le marketing et le transactionnel sur trois identités d’envoi, gardez les trois adresses From: visibles sur votre domaine racine, et traitez la prospection à froid comme un quatrième cas avec une autre réponse.
| Flux | From: visible | Return-Path | DKIM d= | Pourquoi |
|---|---|---|---|---|
| Courrier des salariés et individuel | you@yourbrand.com | domaine racine | yourbrand.com | Ne déplacez jamais ceci. C’est le courrier dont vous ne pouvez pas vous permettre de refaire le warm-up. |
| Marketing et newsletters | news@yourbrand.com | bounce@news.yourbrand.com | news.yourbrand.com | S’aligne sous DMARC relâché parce que les domaines organisationnels correspondent |
| Transactionnel | alerts@yourbrand.com | bounce@txn.yourbrand.com | txn.yourbrand.com | Pour qu’une mauvaise campagne ne puisse pas emporter les réinitialisations de mot de passe |
| Tracking de clics | sans objet | sans objet | sans objet | links.yourbrand.com, un sous-domaine différent de ceux d’envoi |
| Prospection à froid | domaine distinct | domaine distinct | domaine distinct | Autre réponse, autres raisons, et un vrai arbitrage |
Tenir les reçus et les réinitialisations de mot de passe à l’écart du volume des campagnes est la séparation qui paie le plus sûrement, et elle compte le plus pour les expéditeurs SaaS, chez qui un envoi promotionnel et un code de connexion passent par le même tuyau par défaut.
Il y a une subtilité qui mérite d’être nommée, parce qu’elle inverse le conseil habituel. L’heuristique des praticiens est un rapport, pas un absolu : l’isolement commence à valoir son prix quand le volume marketing représente plusieurs fois votre volume transactionnel. Cela implique que l’isolement est moins utile à faible volume, soit le contraire de ce qu’on raconte d’habitude aux débutants.
Pour la prospection à froid la réponse devient un domaine distinct
Pour la prospection à froid la réponse bascule du côté d’un domaine enregistré entièrement distinct, et la raison est mécanique : un enregistrement séparé coupe le lien de domaine organisationnel sur lequel reposent l’alignement DMARC, l’inscription sur blacklist au niveau du domaine principal et le comptage des messages par domaine primaire chez Google. Un sous-domaine laisse chacun de ces liens intact, ce qui fait tout l’intérêt d’un sous-domaine et tout le problème pour le courrier à froid.
Ce conseil a un coût qu’on énonce rarement à côté. M3AAWG déconseille exactement ce schéma, parce qu’un domaine qui n’est pas démontrablement relié à votre marque sonne comme de l’hameçonnage aux destinataires et aux systèmes antiabus. Le domaine distinct est donc un arbitrage que vous choisissez, pas une bonne pratique que vous suivez. Si vous envoyez à froid, le manuel de prospection à froid couvre le reste de la configuration.
Combien de sous-domaines font trop
Chaque sous-domaine d’envoi a besoin d’assez de volume régulier pour bâtir sa propre réputation, le plafond du découpage est donc fixé par votre volume et non par le nombre de flux que vous savez nommer. M3AAWG formule la contrainte directement : chaque segment a besoin d’un trafic suffisant et relativement régulier pour établir sa propre réputation.
Trop peu découper échoue d’une façon : une mauvaise campagne emporte vos réinitialisations de mot de passe. Trop découper échoue d’une façon pire. Spamhaus décrit de nombreux domaines et adresses IP changeant rapidement comme le schéma snowshoe, note que les expéditeurs de masse sérieux utilisent bien moins de domaines que les snowshoers, et traite en conséquence les domaines qui se comportent comme des snowshoers. La RFC 5863 fait le même point par l’autre bout, en avertissant qu’une granularité trop fine empêche des flux liés de profiter d’une réputation agrégée.
Deux ou trois sous-domaines d’envoi, nommés d’après le trafic qu’ils transportent, c’est là que presque tout le monde devrait s’arrêter.
Ce qu’il faut publier sur le sous-domaine, enregistrement par enregistrement
SPF et DKIM ne s’héritent pas du domaine parent et DMARC si, un nouveau sous-domaine d’envoi a donc besoin de son propre enregistrement SPF et le plus souvent de sa propre clé DKIM, tandis que l’enregistrement DMARC du parent le couvre déjà.
SPF va là où vont les bounces, pas là où est le From
SPF est évalué contre le domaine MAIL FROM de l’enveloppe, jamais contre l’en-tête From:, publiez donc l’enregistrement sur le nom auquel vos bounces reviennent. Si votre plateforme fait rebondir sur bounce.yourbrand.com, c’est ce nom qui a besoin de v=spf1, et le sous-domaine de votre en-tête From: n’a peut-être besoin d’aucun enregistrement SPF.
Un sous-domaine sans enregistrement SPF n’échoue pas à SPF, il renvoie none, un résultat différent avec le même effet pratique : DKIM doit porter l’alignement seul. Dans nos données de benchmark, 93 % publient un enregistrement SPF valide, et ce sont les 7 % qui n’en ont toujours pas qui se font prendre ici, parce qu’un sous-domaine d’envoi tout neuf rejoint ce groupe à l’instant où vous le créez.
Un vrai gain d’ingénierie se cache là-dedans. Chaque domaine reçoit son propre budget indépendant de dix résolutions, sortir l’include d’une plateforme marketing de votre enregistrement racine soulage donc la racine, et une permerror sur l’un ne touche pas l’autre. Si votre enregistrement racine frôle la limite, c’est la sortie la plus propre. Les détails sont dans le guide SPF, et le SPF Checker gratuit compte les résolutions sur le nom que vous lui indiquez.
DKIM ne compte sur le sous-domaine que si vous signez en tant que le sous-domaine
La clé DKIM est récupérée à <selector>._domainkey.<the d= domain>, et d= est ce que la plateforme signataire a en configuration, un sous-domaine n’a donc pas besoin de clé propre si vous signez délibérément avec la racine. C’est l’étape que les gens sautent : changer seulement le domaine From: visible ne suffit pas, parce que le courrier doit être signé en DKIM par le sous-domaine pour qu’une séparation existe.
Parmi les domaines que nous contrôlons, 90 % signent leur courrier avec une clé DKIM qui fonctionne et 10 % sans aucune. Confirmez sous quel nom le vôtre signe avec le DKIM Checker, et lisez le guide DKIM si vous choisissez un sélecteur pour la première fois.
DMARC couvre déjà le sous-domaine
Un enregistrement DMARC sur yourbrand.com gouverne déjà tous les sous-domaines sans enregistrement propre, en appliquant la politique sp= si cette balise est présente et la politique p= sinon. L’alignement est relâché par défaut, et c’est pourquoi From: news@yourbrand.com signé par d=news.yourbrand.com passe sans configuration particulière. Le mode strict (adkim=s, aspf=s) est l’option que vous activez, et il transforme votre choix de sous-domaine en contrainte dure et en échec auto-infligé courant, que le guide des échecs DMARC déroule cas par cas.
Deux pièges vivent dans la balise sp=, et les deux sont contre-intuitifs. sp= est ignorée sur tout enregistrement publié sur un sous-domaine, parce que la découverte de politique trouve cet enregistrement en premier et arrête de chercher. Et publier un enregistrement DMARC sur le sous-domaine remplace celui du parent pour ce nom, adresses de rapport comprises, omettre rua= vous aveugle donc précisément sur le flux que vous vouliez surveiller. Le guide DMARC couvre les balises en entier, et le DMARC Checker gratuit montre quel enregistrement un nom donné résout réellement.
Le geste utile pendant qu’un nouveau sous-domaine d’envoi chauffe, c’est p=reject sur la racine avec sp=none à côté, ce qui vous garde votre application pendant que le nouveau flux trouve ses marques. Un coût à connaître avant de le faire : sp=none n’importe où dans la chaîne arrête le traitement BIMI, un logo de marque ne s’affichera donc pas tant que cet enregistrement est en vie. Parmi les domaines que nous testons, 50 % publient désormais une politique DMARC et 50 % n’en ont toujours aucune, pour la moitié des expéditeurs la question n’a donc pas commencé.
Une note sur les standards, qui compte pour tout ce que vous lirez sur ce sujet. La RFC 9989 a remplacé la RFC 7489 en mai 2026, en troquant la Public Suffix List contre un parcours de l’arbre DNS, en supprimant la balise pct= et en rendant p= optionnelle. L’adoption côté récepteurs est une autre affaire : la documentation DMARC de Microsoft a été mise à jour en juillet 2026 et cite toujours la RFC 7489 et documente toujours pct=. Partez du modèle ancien de domaine organisationnel en pratique, et n’attrapez pas la nouvelle balise psd=n comme outil d’isolement, parce qu’elle casse l’alignement relâché contre le d= de votre parent et que personne n’a confirmé que les récepteurs l’honorent.
Réponses, MX et le bounce que personne ne voit
Aucun standard n’exige d’enregistrement MX sur un sous-domaine d’envoi, et c’est exactement le problème. Sans enregistrement MX, une réponse à news.yourbrand.com n’est pas rejetée bruyamment : le serveur de messagerie de l’expéditeur tente la livraison vers ce que l’enregistrement A de ce nom désigne, en général un serveur web qui n’écoute pas le courrier, la réponse reste donc dans une file de réessais et revient en bounce à la personne qui l’a écrite des jours plus tard, ou se fait avaler purement et simplement si quelque chose là-bas l’accepte. Dans les deux cas, elle ne vous parvient jamais.
La consigne de M3AAWG ne laisse aucune ambiguïté ici : tout domaine utilisé en Return-Path, From:, Sender ou Reply-To devrait avoir un enregistrement MX qui fonctionne, et abuse@ et postmaster@ doivent exister, être lues et ne jamais rebondir. C’est la raison pratique pour laquelle Klaviyo dit à ses clients de garder l’adresse From: sur le domaine racine. Pointez le MX lookup vers tout sous-domaine d’envoi que vous créez et confirmez que le courrier résout quelque part de réel.
Un nouveau sous-domaine a-t-il besoin de son propre warm-up
Oui, et la raison n’est pas que les récepteurs n’auraient jamais rencontré le sous-domaine. C’est que vous avez changé la combinaison de signaux qu’ils notaient déjà, et un nouveau domaine d’envoi associé à vos adresses IP existantes est une combinaison nouvelle. Iterable le présente comme une combinaison, ce qui est exactement juste.
Prévoyez deux à quatre semaines pour un sous-domaine ajouté à un programme déjà chaud, cohérent avec la montée en charge de la checklist de délivrabilité, et plutôt les six semaines que M3AAWG cite comme moyenne quand le volume ou l’audience sont neufs aussi. M3AAWG traite un changement de domaine dans un sens comme dans l’autre comme un motif de nouvelle montée en charge.
Le piège opérationnel le plus vif n’a rien à voir avec la durée. Certaines plateformes limitent le warm-up par IP et non par domaine, un nouveau sous-domaine affecté à une IP déjà chaude ne reçoit donc aucune montée en charge à moins que vous n’en construisiez une délibérément. Vérifiez ce que fait la vôtre avant de faire confiance à ses réglages par défaut.
Méfiez-vous de tout échelonnage précis qu’on vous donne, le nôtre compris. Aucun jeu de données publié ni déclaration de fournisseur n’appuie un calendrier de volume quotidien particulier pour un nouveau domaine d’envoi, et les chiffres incompatibles qui circulent, de dix par jour à mille par jour la première semaine, prouvent que personne ne mesure. Les variables qui décident vraiment sont votre volume cible en régime établi et le degré d’engagement de votre liste. Le guide de warm-up de domaine couvre la mécanique.
Migrer depuis la racine : le coût que personne ne chiffre
Déplacer un programme établi sur domaine racine vers un sous-domaine vous coûte une nouvelle montée en charge sur une nouvelle combinaison, et ne vous achète rien si le comportement d’envoi qui a causé votre problème vient avec.
Trois choses à vérifier avant de commencer. Une réputation inconnue démarre plus près de mauvaise que de neutre, selon Spamhaus, le nouveau nom n’est donc pas un départ à neuf. Un nouveau sous-domaine d’un domaine actuellement blacklisté est déjà listé avant son premier envoi, vérifiez donc d’abord la racine avec le Blacklist Checker de domaines. Et confirmez que le sous-domaine choisi ne porte aucun enregistrement A, CNAME ou MX hérité d’un projet antérieur.
Votre plateforme peut aussi décider à votre place, et deux cas reviennent sans cesse. Sur les IP mutualisées de HubSpot le return-path reste sur hubspotemail.net, SPF ne peut donc pas aligner sur votre sous-domaine : seuls les clients en IP dédiée peuvent configurer une adresse de retour d’enveloppe personnalisée, ce que couvre le guide de délivrabilité HubSpot. Amazon SES a besoin d’un sous-domaine MAIL FROM personnalisé avec exactement un enregistrement MX plus son propre enregistrement SPF avant que le Return-Path soit vraiment le vôtre, détaillé dans le guide Amazon SES. Un MAIL FROM personnalisé mal configuré vaut moins qu’un réglage par défaut qui fonctionne.
Si vous pouvez, faites la migration pendant un changement de plateforme, quand la montée en charge a lieu de toute façon et que vous ne la payez qu’une fois. Et pour répéter le cas dans lequel se trouvent réellement la plupart des lecteurs de cette section : si vous envoyez depuis votre domaine racine aujourd’hui, que votre taux de spam est sous 0,10 % et que rien n’arrive dans les spams, ne migrez pas.
Ce que votre ESP fait réellement du sous-domaine
La plupart des exigences de sous-domaine des plateformes existent parce que leur parcours d’intégration passe par une délégation CNAME ou par un return-path contrôlé par le prestataire, et non parce que quelqu’un aurait mesuré un gain de délivrabilité, et deux des plus grandes donnent des instructions directement opposées sur l’endroit où doit se trouver le From: visible.
| Plateforme | Où va le From: visible | Ce que le sous-domaine transporte vraiment |
|---|---|---|
| Klaviyo | Domaine racine, et elle vous le dit, parce que sinon les réponses cessent de vous parvenir | Return-Path et DKIM sur un sous-domaine send., plus un hôte de clics distinct |
| HubSpot | Doit correspondre au sous-domaine connecté | DKIM et le domaine d’envoi connecté, le return-path restant sur hubspotemail.net sur les IP mutualisées |
| Mailchimp | Aucune position dans un sens ni dans l’autre | Le Return-Path est toujours un domaine Mailchimp, DMARC passe donc sur DKIM seul |
| SendGrid | Le domaine racine est ce que vous tapez pendant la Domain Authentication | Un CNAME em####. généré automatiquement que vous n’avez jamais choisi |
| Amazon SES | Votre propre domaine | Un sous-domaine MAIL FROM personnalisé qui a besoin d’un enregistrement MX et de son propre SPF |
| Customer.io | Domaine racine, intact | Un sous-domaine de votre propre domaine spécifique au compte pour le return-path, SPF et la signature, nommé par eux et non par vous |
| MailerSend | N’importe quel sous-domaine d’un domaine vérifié | Rien par défaut : le courrier du sous-domaine est signé avec le domaine parent |
La ligne MailerSend mérite qu’on s’y arrête, parce que c’est le cas où suivre le conseil n’apporte littéralement rien : le courrier reste signé avec le domaine parent, aucune identité séparée n’existe donc jamais. Les prestataires se contredisent aussi eux-mêmes. La communauté de Klaviyo a publié les deux positions à quatorze mois d’écart, une réponse du support disant que la réputation s’attache au domaine racine et non au sous-domaine, une autre disant qu’un sous-domaine d’envoi isole l’activité marketing, et Mailgun se contredit entre deux de ses propres pages de documentation. Quand les prestataires se contredisent eux-mêmes, la règle du sous-domaine est une contrainte de leur architecture et non une loi de la délivrabilité, et la lecture honnête est que les deux réponses ont partiellement raison : l’isolement est réel pour l’identifiant de réputation DKIM et pour le sens des blacklists, et absent pour les IP d’envoi mutualisées et pour le dossier de conformité que Google tient sur votre domaine primaire.
Envoyer du courrier en masse depuis votre domaine racine ne nuit pas à votre SEO
Aucun moteur de recherche et aucun fournisseur de messagerie ne documente le moindre lien entre l’envoi d’e-mails et le classement dans la recherche, dans un sens comme dans l’autre, et l’indicateur que les gens nomment d’habitude n’en est pas un que Google conserve. Les règles de Google contre le spam dans la recherche ne mentionnent nulle part l’e-mail, les serveurs de messagerie ou les enregistrements d’authentification, et l’autorité de domaine est un score de prestataire tiers et non un signal Google.
La version exacte de l’inquiétude porte sur l’accessibilité, pas sur le classement. Une inscription de domaine sur blacklist peut être appliquée au niveau du résolveur pour quiconque se trouve derrière un pare-feu DNS bâti sur ces flux, ce qui rend votre site inaccessible à ces utilisateurs alors que vos positions restent exactement là où elles étaient. Les conditions d’utilisation de votre hébergeur ou de votre plateforme sont un troisième risque, distinct. Aucun de ces points n’est du SEO.
Vérifiez depuis quoi vous envoyez réellement
Passez le contrôle Unspam des quatre domaines sur le dernier message que votre programme a délivré : le domaine From: visible, le domaine Return-Path, la valeur d= de DKIM et l’hôte d’un lien tracé. La plupart des gens qui croient avoir séparé leurs flux n’ont en fait déplacé que le premier.
Vérifiez ensuite les noms eux-mêmes. Passez le domaine racine et chaque sous-domaine d’envoi séparément dans le diagnostic e-mail, parce qu’une racine propre ne vous dit rien d’un sous-domaine qui n’a ni enregistrement SPF ni MX. La moyenne mondiale est actuellement de 89/100, et un sous-domaine d’envoi tout neuf ne démarrera pas là.
Quand les enregistrements sont bons, envoyez le message plutôt que la théorie. Passez la campagne que vous êtes sur le point d’envoyer dans le test de spam Unspam gratuit et lisez le panneau d’authentification : si le Return-Path et les valeurs d= sont le sous-domaine que vous avez choisi et que le From: reste votre racine, la séparation est réelle, et vous verrez où le message arrive vraiment avant qu’un abonné ne le fasse.
