Pourquoi Vous Devriez Utiliser un Sous-domaine pour Envoyer des E-mails

June 1, 2026 by Mailer À Emporter

Vous craignez qu'un sous-domaine d'envoi ne montre un domaine différent ? Ce n'est pas le cas — les destinataires voient toujours votre domaine racine, et la délivrabilité s'améliore. Voici pourquoi, et comment configurer mtg.yourdomain.com.

Envoyez votre email transactionnel à partir d’un sous-domaine comme mtg.yourdomain.com — pas à partir de votre domaine racine, et pas à partir d’un nom d’hôte qui est déjà un CNAME. C’est un petit changement DNS, et cela améliore considérablement la délivrabilité.

« Mais mon email ne semblera-t-il pas provenir d’un domaine différent ? »

C’est la première chose dont tout le monde s’inquiète, alors réglons-la d’emblée : non, ce ne sera pas le cas. Utiliser un sous-domaine pour envoyer ne change rien à ce que vos destinataires voient. L’adresse De : dans leur boîte de réception est toujours you@yourdomain.com — votre domaine racine, votre marque, exactement comme aujourd’hui.

Le sous-domaine fonctionne en arrière-plan, au niveau de la couche d’authentification que les fournisseurs de boîtes de réception (et non les humains) inspectent. Ce qui change réellement, c’est que votre courrier commence à passer SPF, DKIM et DMARC correctement, de sorte que davantage de courrier atteint la boîte de réception au lieu du dossier spam. L’échange est donc simple : rien de visible ne change pour vos clients, et davantage de votre courrier les atteint réellement.

En bref — vos destinataires voient toujours votre domaine racine, et votre délivrabilité s’améliore. C’est toute l’histoire ; le reste de cet article n’est que le pourquoi et le comment.

(La version technique : le sous-domaine est votre envelope-from / Return-Path, qui est le domaine que SPF vérifie. L’en-tête De : que votre destinataire voit est défini par votre application et reste votre domaine racine. Plus de détails ci-dessous.)

Comprendre le problème

Pourquoi ne puis-je pas utiliser mon domaine racine s’il s’agit d’un CNAME ?

De nombreux fournisseurs d’hébergement (Heroku, Build.io, Cloudflare, Netlify, et autres) vous demandent de pointer votre domaine vers eux avec un enregistrement CNAME afin qu’ils puissent mettre fin à SSL et router le trafic. Cela fonctionne très bien pour votre site Web. Mais cela crée un conflit difficile pour l’email.

DNS a une règle, définie dans RFC 1034 §3.6.2 : si un nom a un enregistrement CNAME, il ne peut avoir aucun autre enregistrement d’un autre type. Un CNAME signifie « ce nom n’est qu’un alias pour ce nom — allez chercher là pour tout. » Il n’y a pas de place pour l’enregistrement TXT qui contient votre politique SPF, ou pour les enregistrements MX, à ce même nom.

Donc si yourdomain.com est un CNAME pointant vers votre hôte, vous ne pouvez littéralement pas ajouter SPF à celui-ci. DNS ne l’autorisera pas.

Quel est le conflit CNAME, et pourquoi DNS fonctionne-t-il de cette façon ?

Un CNAME est une redirection au niveau DNS. Lorsqu’un résolveur cherche yourdomain.com et trouve un CNAME, il abandonne le nom d’origine et poursuit la cible. Autoriser d’autres enregistrements à côté d’un CNAME serait ambigu — quelle réponse gagne ? La spécification résout l’ambiguïté en interdisant la combinaison. Ce n’est pas une limitation du fournisseur ; c’est ainsi que DNS est défini.

Mon site fonctionne bien à mon domaine — pourquoi l’email serait-il différent ?

Le trafic web n’a besoin que du CNAME : un navigateur demande « où est yourdomain.com ? », suit l’alias et se connecte. L’email a besoin d’enregistrements supplémentaires au domaine — SPF (un enregistrement TXT) et souvent DKIM et une politique DMARC — afin que les serveurs récepteurs puissent vérifier que le courrier est autorisé. Le CNAME qui fait fonctionner votre site est exactement ce qui bloque ces enregistrements. Même nom, exigences différentes.

Qu’est-ce qui se passe réellement si j’envoie sans SPF ?

SPF est l’un des principaux signaux que les fournisseurs de boîtes de réception utilisent pour décider que vous êtes qui vous dites être. Sans enregistrement SPF :

Les fournisseurs de boîtes aux lettres (Gmail, Outlook, Yahoo) sont beaucoup plus susceptibles d’envoyer votre courrier vers le spam — ou de le rejeter.
Vous ne pouvez pas réussir DMARC, qui ferme de plus en plus la boîte de réception.
Vos messages ressemblent au courrier non authentifié que les spammeurs envoient.

Le courrier pourrait toujours être envoyé, mais une part significative ne sera pas reçue.

La solution du sous-domaine

Quel sous-domaine dois-je utiliser ? Le nom a-t-il de l’importance ?

Nous recommandons mtg.yourdomain.com. Le libellé exact n’affecte pas la délivrabilité — email. ou notifications. fonctionneraient aussi — mais mtg.yourdomain.com est clair, facile à retenir, et garde votre envoi MailerToGo proprement nommé. Ce qui importe, c’est que ce soit un nom que vous contrôlez directement (pas lui-même un CNAME vers un tiers), afin que vous puissiez ajouter les enregistrements SPF, DKIM et d’envoi dont il a besoin.

Si j’envoie à partir de `mtg.example.com`, les destinataires verront-ils cela à la place de `example.com` ?

Non — et c’est l’inquiétude que nous avons réglée au début, maintenant avec le mécanisme. Il y a deux adresses « de » différentes sur chaque email :

Envelope-from (également appelé MAIL FROM ou Return-Path) : l’adresse que l’infrastructure d’envoi utilise. C’est le domaine que SPF vérifie, et c’est là que votre sous-domaine habite.
En-tête De : : l’adresse que le destinataire voit réellement dans sa boîte de réception. Ceci est défini par votre application, indépendamment du domaine d’envoi.

Vous envoyez donc via mtg.example.com (envelope-from) tandis que vos destinataires voient hello@example.com ou Acme Support <support@example.com> sur la ligne De :. Le sous-domaine authentifie ; votre adresse de marque reste visible.

Les réponses vont-elles au sous-domaine ou à ma véritable adresse ?

Les réponses suivent l’en-tête De : (ou un Reply-To: explicite que vous définissez) — pas le envelope-from. Définissez De : ou Reply-To : sur votre véritable boîte de réception surveillée (par exemple support@example.com) et les réponses y arrivent comme prévu. Le sous-domaine n’a jamais à recevoir du courrier.

L’utilisation d’un sous-domaine affecte-t-elle la réputation de mon domaine ?

Oui — en votre faveur. L’envoi à partir d’un sous-domaine isole la réputation de votre courrier transactionnel/marketing de votre domaine racine. Si une campagne a jamais une période difficile, elle est contenue à mtg.example.com plutôt que de traîner vers le bas example.com (et l’email quotidien de vos employés). L’isolation de réputation est une fonctionnalité, pas un effet secondaire.

Puis-je utiliser le même sous-domaine pour les emails transactionnels et marketing ?

Vous pouvez, mais il est généralement préférable de les séparer — par exemple mtg.example.com pour transactionnel (reçus, réinitialisations de mot de passe) et news.example.com pour marketing. Le courrier transactionnel est hautement fiable et peu plaignant ; le courrier marketing attire naturellement plus de plaintes et de désinscriptions. Les scinder vous permet de garder vos reçus et réinitialisations critiques isolés des variations de réputation marketing.

Configuration

Comment configurer MailerToGo pour utiliser un sous-domaine ?

Ajoutez le sous-domaine (pas votre domaine racine) comme votre domaine d’envoi dans le tableau de bord MailerToGo, puis publiez les enregistrements DNS qu’il vous donne. MailerToGo affichera les enregistrements exacts pour votre sous-domaine.

Quels enregistrements DNS dois-je ajouter ?

Au sous-domaine, vous ajouterez SPF et DKIM (et nous recommandons une politique DMARC à la racine). Un ensemble typique ressemble à :

; SPF — autorise MailerToGo à envoyer pour le sous-domaine
mtg.yourdomain.com.   TXT   "v=spf1 include:_spf.mailertogo.net ~all"

; MX — route les rebonds/return-path du sous-domaine vers MailerToGo
mtg.yourdomain.com.   MX    10 smtp.us-west-1.mailertogo.net.

; DKIM + DMARC — publiez les enregistrements exacts affichés dans votre tableau de bord MailerToGo
; (DKIM est un CNAME avec un sélecteur par compte ; une politique DMARC de sous-domaine est
;  fournie pour vous, par exemple p=reject)

Utilisez les valeurs précises de votre tableau de bord — le sélecteur DKIM et la région SMTP (smtp.<region>.mailertogo.net) sont spécifiques à votre compte.

Dois-je changer quelque chose dans le code de mon application ?

Deux petites choses. Premièrement, pointez votre mailer vers MailerToGo en utilisant les identifiants du sous-domaine. Avec Rails :

# config/environments/production.rb
config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = {
  address:         ENV["MAILERTOGO_SMTP_HOST"],   # smtp.<region>.mailertogo.net
  port:            ENV.fetch("MAILERTOGO_SMTP_PORT", 587).to_i,
  user_name:       ENV["MAILERTOGO_SMTP_USER"],
  password:        ENV["MAILERTOGO_SMTP_PASSWORD"],
  authentication:  :plain,
  enable_starttls: true   # enforce TLS on port 587
}

Deuxièmement — et c’est la partie qui fait fonctionner le sous-domaine — définissez le envelope-from (return_path) sur le sous-domaine tout en gardant les De : et Reply-To : que vos destinataires voient et auxquels ils répondent sur votre domaine racine :

class NotifierMailer < ApplicationMailer
  def welcome(user)
    mail(
      to:          user.email,
      from:        "Acme <hello@yourdomain.com>",   # what recipients see
      reply_to:    "support@yourdomain.com",        # where replies go
      return_path: "bounces@mtg.yourdomain.com"     # envelope-from: what SPF checks
    )
  end
end

Rails (via la gemme Mail) utilise return_path comme envelope-from, donc SPF est validé contre mtg.yourdomain.com — où votre enregistrement SPF habite — tandis que les De:/Reply-To restent sur yourdomain.com. Même marque pour vos destinataires, DMARC aligné, meilleure délivrabilité.

Comment vérifier que le sous-domaine fonctionne ?

Confirmez que les enregistrements sont résolus : dig TXT mtg.yourdomain.com (SPF), dig MX mtg.yourdomain.com, et le CNAME DKIM de votre tableau de bord.
Envoyez un message de test à un compte Gmail, ouvrez Afficher l’original, et vérifiez que SPF et DKIM affichent tous les deux PASS et que DMARC affiche l’alignement.
Regardez le statut du domaine dans le tableau de bord MailerToGo passer à vérifié.

Avancé et signaux de confiance

L’alignement DMARC fonctionne-t-il avec un sous-domaine ?

Oui. DMARC supporte l’alignement organisationnel par défaut : un message envoyé à partir de mtg.example.com s’aligne avec une politique DMARC publiée à example.com, parce qu’ils partagent le même domaine organisationnel. Vous publiez DMARC une fois à la racine et votre sous-domaine hérite de l’alignement — aucune politique séparée n’est nécessaire.

DKIM signe-t-il avec le sous-domaine ou le domaine racine ?

DKIM signe avec le domaine que vous publiez la clé sous — ici, le sous-domaine (mtg.yourdomain.com). C’est exactement ce que vous voulez : la signature DKIM, le envelope-from, et le sous-domaine s’alignent tous, et cette combinaison s’aligne avec votre politique DMARC racine.

J’ai déjà SPF sur ma racine pour Google Workspace / Microsoft 365 — ai-je toujours besoin d’un sous-domaine ?

Oui, et le sous-domaine garde les choses propres. SPF a une limite stricte de 10 recherches DNS ; entasser chaque expéditeur (Google, Microsoft, votre ESP, MailerToGo) dans un seul enregistrement SPF racine risque de dépasser la limite et de casser SPF pour tout. Envoyer votre courrier d’application à partir d’un sous-domaine avec son propre enregistrement SPF contourne la limite et garde votre courrier d’entreprise (Google/Microsoft) et votre courrier d’application indépendants.

La version courte

Utilisez un sous-domaine comme mtg.yourdomain.com pour l’envoi. Vos destinataires voient toujours votre adresse de domaine racine — rien de visible ne change pour eux — et votre délivrabilité augmente. C’est ainsi que les grands expéditeurs le font (GitHub, Stripe et AWS envoient tous le courrier transactionnel à partir de sous-domaines) : cela contourne le conflit CNAME, garde SPF/DKIM/DMARC propres, et protège la réputation de votre domaine racine.