← Blog

Envoi d'e-mails à partir des domaines de vos clients

August 14, 2026 by Courrier À Emporter
Construction d'un helpdesk, d'un CRM ou d'une plateforme qui envoie au nom des domaines de vos clients ? Comment choisir entre envoyer depuis votre propre domaine et provisionner DKIM pour le leur, et comment éviter le rejet 550 « expéditeur inacceptable ».

Si vous construisez une application multi-tenant (un helpdesk, un CRM, ou toute plateforme qui envoie des e-mails au nom de vos clients), vous finissez par vous poser cette question : les e-mails doivent-ils provenir de votre domaine ou du leur ? Si vous vous trompez, les messages rebondissent avec 550 sender is unacceptable. Voici le modèle qui fonctionne sur MailerToGo.

Les deux approches

1. Expéditeur de la plateforme (point de départ recommandé)

Envoyez depuis votre propre domaine (par exemple support@votreapp.com) et mettez l’adresse du client dans Reply-To. Cela fonctionne immédiatement, ne nécessite aucune configuration DNS pour le client, et maintient la délivrabilité entièrement sous votre contrôle. C’est ce que font Zendesk, Intercom et la plupart des helpdesks SaaS par défaut.

2. Domaine du client (meilleure marque et délivrabilité)

Provisionnez une clé DKIM pour le domaine du client afin que le courrier soit signé en tant que le sien. Cela nécessite que le client ajoute des enregistrements DNS, mais cela offre une cohérence de marque et, une fois que DKIM et DMARC s’alignent sur leur propre domaine, une meilleure délivrabilité.

La plupart des plateformes proposent les deux : commencez chaque tenant sur l’expéditeur de la plateforme, et laissez les clients passer à leur propre domaine quand ils sont prêts.

Ce qui se passe si vous omettez le provisionnement DKIM

C’est le piège. Si votre application envoie depuis un domaine client qui n’a pas de clé DKIM provisionnée sur MailerToGo, l’une de deux choses se produit : le message est rejeté (550 sender is unacceptable), ou l’expéditeur de l’enveloppe est réécrit vers votre domaine par défaut comme solution de secours.

Aucune des deux n’est quelque chose sur lequel construire. Un rejet signifie des e-mails clients perdus. Une réécriture silencieuse de l’enveloppe signifie que votre alignement DMARC se casse tranquillement. Nous avons vu cet exact échec dans la réalité : une application envoyant en tant que info@domaineduclient.com sans DKIM provisionné, et tous les messages rebondissent 550 sender is unacceptable.

Ne comptez pas sur la solution de secours. Décidez l’expéditeur dans votre propre code.

Le modèle recommandé : choisissez l’expéditeur vous-même

Suivez, par client, si son domaine d’envoi est vérifié sur MTG. Choisissez MAIL FROM en conséquence, et basculez vers votre domaine de plateforme quand ce n’est pas le cas :

# Ruby
PLATFORM_DOMAIN = "votreapp.com"

def sender_for(customer)
  if customer.sending_domain_verified?
    { from: "support@#{customer.domain}" }                 # signé en tant que le sien
  else
    { from: "support@#{PLATFORM_DOMAIN}",                  # votre domaine
      reply_to: customer.support_address }                 # les réponses les atteignent toujours
  end
end

// Node
const PLATFORM_DOMAIN = "votreapp.com";

function senderFor(customer) {
  return customer.sendingDomainVerified
    ? { from: `support@${customer.domain}` }
    : { from: `support@${PLATFORM_DOMAIN}`, replyTo: customer.supportAddress };
}

Quelques points à bien maîtriser :

Provisionner le domaine d’un client

Quand un client souhaite que le courrier soit envoyé en tant que son propre domaine :

  1. Ajoutez un sous-domaine d’envoi sur MailerToGo. Utilisez un sous-domaine dédié comme mtg.domaineduclient.com plutôt que le domaine racine. Cela isole la réputation d’envoi et c’est le modèle sur lequel MTG est construit. Voir Pourquoi MailerToGo envoie depuis mtg.votredomaine.com.
  2. Faites en sorte que le client publie les enregistrements DNS. Le chemin le plus simple est un seul enregistrement NS délégué : MailerToGo gère alors SPF, DKIM et DMARC pour ce sous-domaine pour eux. Le chemin manuel, publier vous-même les enregistrements TXT SPF, DKIM et DMARC, est également pris en charge si le client préfère posséder les enregistrements. Voir Utilisez un sous-domaine pour envoyer des e-mails.
  3. Vérifiez, puis activez le drapeau. Une fois que MTG signale le domaine vérifié, définissez sending_domain_verified = true pour ce client et commencez à envoyer en tant que son domaine.

Jusqu’à ce que l’étape 3 soit complétée, gardez le client sur votre expéditeur de plateforme. Les nouveaux tenants peuvent envoyer dès le premier jour, et passer à leur propre domaine sans temps d’arrêt.

TL;DR