Envoyer des e-mails depuis le bon domaine : identité de l'expéditeur et contrôles anti-spam

Ce que signifie « envoyer depuis le bon domaine »

« Envoyer des e-mails depuis le bon domaine » signifie que votre message a l'apparence et se vérifie comme s'il provenait réellement du domaine de votre entreprise (par exemple @votreentreprise.com), et non d'un domaine de service aléatoire ou d'une adresse non assortie.

Votre identité d'expéditeur est l'ensemble des éléments qui indiquent au destinataire et au fournisseur de boîte mail qui vous êtes. Cela inclut le nom affiché (comme « Alex de Acme »), l'adresse e-mail ([email protected]) et le domaine après le @ (acme.com). Ces éléments doivent correspondre à ce que les gens attendent de votre entreprise.

Il est utile de distinguer deux choses :

• Ce que vous mettez dans le champ From visible.
• Quel système envoie réellement l'e-mail.

Un outil de newsletter, un CRM, un help desk ou votre propre application enverra via ses serveurs. C'est normal. Ce qui compte, c'est que ces serveurs soient autorisés à envoyer au nom de votre domaine.

En pratique, « bon domaine » signifie généralement que votre configuration est cohérente de bout en bout : l'adresse From visible utilise votre domaine (pas @gmail.com et pas l'adresse par défaut d'un fournisseur), les réponses arrivent là où vous l'attendez (Reply-To conforme à votre plan), et les fournisseurs de boîte mail peuvent vérifier que le message est autorisé pour votre domaine (SPF, DKIM et DMARC).

Pourquoi c'est important ? Les fournisseurs d'Inbox cherchent à protéger les utilisateurs contre les expéditeurs usurpés. Si votre message prétend venir de "From: [email protected]" mais que le système d'envoi ne peut pas prouver qu'il est autorisé à représenter votre domaine, cela paraît suspect. Ce décalage peut réduire la confiance, pousser vos e-mails en spam ou ajouter des étiquettes "via" qui font hésiter les destinataires.

Un cas fréquent : vous configurez votre outil de newsletter pour afficher From: [email protected], mais vous n'avez jamais vérifié acme.com dans l'outil. Pour un fournisseur de boîte mail, cela peut ressembler à une usurpation d'identité. La solution n'est généralement pas de réécrire l'e-mail, mais d'aligner le domaine et la configuration d'expédition.

Pourquoi les e-mails « mauvais domaine » atterrissent en spam

Les fournisseurs de boîte de réception sont payés pour être méfiants. Ils cherchent en permanence à détecter les messages qui prétendent venir d'une marque mais sont envoyés par quelqu'un d'autre. Le spoofing et le phishing commencent souvent par le domaine d'expéditeur.

Quand votre e-mail semble provenir d'un domaine mais que le système d'envoi est lié à un autre, les fournisseurs considèrent cela comme un signal d'alerte. Même si l'objet et le contenu sont corrects, une discordance de domaine peut rappeler une tentative d'usurpation.

Beaucoup de filtrage repose sur la vérification d'identité. Les fournisseurs comparent ce que le message prétend être (le From visible) avec ce que disent les en-têtes (d'où il vient réellement et si l'expéditeur est autorisé). Si les signaux ne concordent pas, l'endroit le plus sûr pour le message est souvent le dossier spam. Parfois il finit dans Promotions ou Courrier indésirable, mais la cause racine reste la confiance.

La réputation compte aussi. Un domaine tout neuf, ou qui n'a pas envoyé beaucoup d'e-mails, n'a pas d'historique. La confiance se construit quand les destinataires ouvrent, répondent et ne signalent pas comme spam. Si vous envoyez depuis un domaine différent de celui attendu, vous perdez cette confiance et vous vous retrouvez à dépendre de la réputation du système qui envoie réellement.

Voici quelques situations « mauvais domaine » qui attirent souvent la suspicion :

• Votre adresse From utilise votre domaine, mais le fournisseur envoie via un domaine partagé ou non lié.
• Un outil remplace silencieusement votre adresse par une valeur par défaut comme [email protected].
• Reply-To est votre domaine, mais les rebonds et les signaux de livraison vont ailleurs.
• Vous utilisez un sous-domaine pour l'envoi, mais il n'est pas aligné avec ce que vous affichez en From.

C'est pourquoi les e-mails peuvent atterrir en spam même quand rien ne semble visiblement cassé. La plupart des contrôles se font en coulisses, et les fournisseurs vous disent rarement quelle discordance a fait pencher la balance.

Exemple : vous lancez une petite campagne depuis [email protected], mais votre outil est configuré pour envoyer depuis acme-mailer.com. Les destinataires voient « Acme » dans la boîte de réception, mais le fournisseur voit des signaux d'identité mélangés. Le message peut être filtré avant même d'être lu.

Signes indiquant que vos messages ne proviennent pas de votre domaine

La plupart des gens regardent le nom affiché et supposent que tout va bien. Les boîtes de réception regardent plus que ce que vous avez tapé dans le composer. Si des éléments clés d'identité pointent vers un domaine différent, votre e-mail peut sembler vous usurper.

Indices courants :

• Les destinataires voient « via » ou « envoyé pour le compte de » à côté de votre nom. Cela signifie souvent qu'un autre service effectue l'envoi et que votre domaine n'est pas entièrement autorisé.
• L'adresse From affiche votre domaine, mais quand quelqu'un clique sur Répondre, la réponse va vers un domaine ou un système inattendu.
• Les messages de rebond arrivent à une adresse inconnue. Cela indique un Return-Path différent, qui est un signal d'authenticité important.
• Votre outil e-mail alerte sur l'authentification, par exemple « domaine non vérifié » ou « DKIM manquant ».
• Des e-mails de test atterrissent dans Promotions ou Spam plus souvent que d'habitude.

Un contrôle rapide : envoyez un e-mail test à deux boîtes que vous contrôlez (par exemple une Gmail et une Outlook) et comparez les détails d'expéditeur affichés. Si l'une affiche « on behalf of », ou si le comportement de réponse change, vous avez une discordance.

Exemple : vous envoyez une newsletter depuis [email protected] via un nouveau fournisseur. Le destinataire voit « Your Brand via provider-mail.com » et les réponses vont à [email protected]. Même si votre message est légitime, cette identité scindée est un signal rouge pour les filtres et déroute les lecteurs.

Si vous observez ces signes, faites une pause avant votre prochaine campagne. Vérifiez From, Reply-To et les paramètres de bounce/Return-Path, ainsi que les avertissements dans le tableau de bord de votre fournisseur.

Les trois adresses à vérifier : From, Reply-To, Return-Path

Quand on parle d'e-mails depuis le bon domaine, on entend souvent plus que ce qui est visible. Trois « adresses » différentes peuvent être impliquées dans un message. Si elles ne correspondent pas à votre domaine (ou entre elles), les fournisseurs de boîte mail peuvent considérer l'e-mail comme suspect.

From : ce que voient les destinataires

L'adresse From est ce que les lecteurs voient dans leur boîte. Elle doit correspondre à votre marque et au domaine que vous souhaitez utiliser (par exemple [email protected]). Si le From indique votrecompany.com mais que le message est en réalité envoyé « pour le compte de » un autre domaine, les filtres peuvent le détecter.

Vérifiez aussi le nom de l'expéditeur (par exemple « Facturation Votre Entreprise »). S'il change souvent, semble aléatoire ou ne correspond pas à votre site et votre signature, les gens hésiteront. Une moindre interaction peut nuire à la délivrabilité au fil du temps.

Reply-To : où vont les réponses

Reply-To indique aux applications e-mail où envoyer les réponses. Souvent, il doit correspondre au From. Il peut être différent pour une bonne raison, par exemple envoyer du marketing depuis une adresse tout en routant les réponses vers une boîte support partagée.

Restez cohérent et intentionnel. Un Reply-To pointant vers un domaine totalement différent peut ressembler à du phishing, surtout si le From affiche votre marque.

Return-Path : l'adresse de rebond (souvent cachée)

Return-Path sert pour les rebonds et les erreurs de livraison. Beaucoup de fournisseurs la définissent automatiquement et elle peut utiliser un domaine système ou un sous-domaine. C'est normal, mais cela doit rester aligné avec votre configuration d'envoi. Si Return-Path pointe vers un endroit inattendu, c'est souvent le signe que l'outil envoie via le mauvais domaine ou une identité non vérifiée.

Pour diagnostiquer, ouvrez les en-têtes complets d'un message que vous vous êtes envoyé (souvent « afficher la source » ou « message d'origine »). Cherchez :

• From : montre-t-il bien votre domaine ?
• Reply-To : est-il prévu et aligné avec la marque ?
• Return-Path : correspond-il à votre fournisseur ou au domaine d'envoi configuré ?
• « Mailed-by » / « Sent-by » / « on behalf of » : l'un d'eux affiche-t-il un domaine différent ?

Si l'un de ces éléments ne correspond pas à ce que vous avez prévu, vous avez quelque chose de concret à corriger dans les paramètres de votre fournisseur.

Bases de l'authentification d'expéditeur (SPF, DKIM, DMARC) sans jargon

Si vous voulez des e-mails depuis le bon domaine, il faut plus que le bon nom From. Les fournisseurs de boîte vérifient aussi si votre service d'envoi est autorisé à envoyer pour votre domaine et si le message a été altéré en route.

En clair :

• SPF est une règle dans les paramètres de votre domaine qui liste les serveurs autorisés à envoyer des e-mails pour votre domaine.
• DKIM est une signature ajoutée à chaque message que les destinataires peuvent vérifier avec une clé publiée dans les paramètres de votre domaine.
• DMARC est une politique qui indique aux fournisseurs ce qu'il faut faire si SPF ou DKIM échouent, et où envoyer des rapports.

Ce que signifie « alignement » (et pourquoi ça compte)

L'alignement n'est qu'un jeu de correspondance. Le domaine que voit votre lecteur dans le From visible doit correspondre au domaine prouvé par SPF ou DKIM, ou au moins appartenir à la même famille de domaines.

Si votre adresse From est [email protected], mais que le message s'authentifie en tant qu'autre domaine (comme le domaine partagé d'un outil), certains fournisseurs le considéreront comme suspect même si l'e-mail est par ailleurs correct. Les sous-domaines peuvent fonctionner (par exemple mail.company.com) tant qu'ils sont configurés pour s'aligner avec ce que vous affichez en From.

À quoi s'attendre quand vous changez ces réglages

SPF, DKIM et DMARC sont des enregistrements DNS. Vous les ajoutez ou modifiez là où votre domaine est géré (souvent votre registrar ou l'hébergeur DNS). Deux réalités pratiques :

• Les modifications peuvent prendre du temps à se propager. Certaines mises à jour apparaissent rapidement, d'autres prennent des heures.
• Les petites erreurs de saisie cassent tout. Espaces en trop, guillemets manquants ou placer l'enregistrement au mauvais endroit peuvent faire échouer les contrôles.

Une façon simple de s'en souvenir : SPF répond « Ce serveur est-il autorisé ? », DKIM répond « Le message a-t-il été correctement signé ? », et DMARC répond « Que faire si ces réponses ne correspondent pas à ce que le destinataire attend ? »

Procédure pas à pas : confirmer que votre fournisseur envoie en tant que votre domaine

Pour envoyer des e-mails depuis le bon domaine, deux choses doivent correspondre : le domaine visible (votre From) et le domaine que votre outil d'envoi est autorisé à utiliser.

Vérification simple en 5 étapes

Avant de toucher au DNS, clarifiez ce que vous envoyez et quel outil l'envoie.

1. Notez précisément le domaine From que vous voulez utiliser (par exemple [email protected]). Soyez précis : yourdomain.com et mail.yourdomain.com sont différents.
2. Identifiez le système qui envoie l'e-mail. Est-ce votre fournisseur de boîte, un outil marketing ou votre appli (réinitialisations de mot de passe, reçus, alertes) ? Chacun nécessite sa propre configuration.
3. Trouvez la section d'authentification de domaine de l'outil. Cherchez des libellés comme « Authenticate domain », « Sending domains » ou « Email DNS records ».
4. Ajoutez ou vérifiez SPF et DKIM dans votre DNS. SPF autorise le service. DKIM signe le message.
5. Ajoutez une politique DMARC basique et commencez en mode monitoring pour voir ce qui échoue avant de bloquer quoi que ce soit.

Après publication des changements DNS, attendez un peu, puis utilisez le bouton de vérification de l'outil d'envoi s'il en propose un.

Envoyer un test et confirmer l'alignement

Envoyez un e-mail test vers une boîte personnelle (Gmail convient). Dans les détails du message, cherchez « mailed-by » et « signed-by ». Idéalement, ils correspondent à votre domaine (ou à un sous-domaine approuvé). S'ils affichent un domaine différent que vous ne contrôlez pas, vous n'envoyez toujours pas en tant que votre domaine.

Exemple : un fondateur utilise une appli construite par IA pour les inscriptions, et les e-mails de réinitialisation arrivent « via un domaine de plateforme aléatoire ». Cela signifie généralement que l'appli envoie via un compte fournisseur par défaut, pas via votre domaine vérifié. Corrigez cela en connectant le service d'envoi correct, en authentifiant le domaine là-bas et en mettant à jour les paramètres From de l'appli pour qu'ils correspondent.

Si l'outil indique « authentifié » mais que les tests échouent, les causes habituelles sont des fautes de frappe DNS, l'ajout d'enregistrements sur le mauvais domaine, ou plusieurs enregistrements SPF au lieu d'un seul.

Sous-domaines et outils multiples : garder tout aligné

Les sous-domaines permettent de séparer les types de mails sans changer votre domaine principal. Une configuration courante utilise un sous-domaine pour les newsletters, un autre pour les reçus, et le domaine principal pour les e-mails personnels. Bien fait, cela protège la réputation : si un envoi marketing reçoit des plaintes, cela n'affectera pas automatiquement les réinitialisations de mot de passe ou les reçus.

Un schéma typique :

• news.yourdomain.com pour les campagnes marketing
• billing.yourdomain.com pour les factures et reçus
• app.yourdomain.com pour les messages transactionnels comme les codes de connexion et alertes
• yourdomain.com pour les e-mails personne-à-personne (support, ventes, fondateurs)

Cette séparation vaut la peine quand vous envoyez à grande échelle ou avez des messages transactionnels critiques qui doivent arriver de façon fiable. Si vous n'envoyez que des annonces occasionnelles, un seul domaine peut être plus simple.

Les problèmes surviennent quand l'alignement dérive entre les outils. Vous pouvez définir le From pour qu'il ait l'air correct, mais une pièce cachée (comme le domaine de rebond ou Return-Path) peut provenir d'un sous-domaine différent ou du domaine partagé d'un fournisseur. Un sous-domaine mal configuré peut rompre l'alignement et rendre les boîtes de réception méfiantes.

Pour maintenir les e-mails depuis le bon domaine entre plusieurs outils, définissez une règle cohérente et appliquez-la partout : plateforme marketing, service d'e-mail de l'appli, CRM et boîte de support. Décidez quels domaines From sont approuvés pour chaque type de mail et évitez les valeurs par défaut auto-sélectionnées par les outils.

Il est aussi utile de garder une note interne simple : quels domaines From sont approuvés pour chaque type d'envoi, quel outil possède chaque sous-domaine, qui met à jour les enregistrements DNS/authentification, et quoi tester après un changement.

Exemple : votre produit envoie des codes de connexion depuis [email protected], mais votre plateforme marketing envoie depuis [email protected] alors que son domaine de rebond est encore bounce.vendor-mail.com. Tout semble correct dans la ligne From, et pourtant la délivrabilité chute après une campagne. La solution n'est pas de « changer le texte ». C'est d'aligner les pièces du domaine d'envoi pour que chaque outil utilise ce que vous avez prévu.

Erreurs courantes qui causent une discordance de domaine

La plupart des problèmes de « discordance de domaine » ne sont pas des hacks sophistiqués. Ce sont de petites configurations cumulées jusqu'à ce que les fournisseurs de boîte de réception cessent de vous faire confiance.

Une erreur fréquente est d'utiliser un domaine de messagerie gratuit (comme une adresse webmail personnelle) tout en brandant le message au nom de votre entreprise. Même si le nom affiché est correct, le domaine ne correspond pas à votre marque.

Une autre erreur courante concerne SPF. Les équipes ajoutent un deuxième (ou troisième) enregistrement SPF quand elles connectent un nouvel outil. SPF doit être un seul enregistrement qui inclut tous les expéditeurs approuvés. Plusieurs enregistrements SPF peuvent s'annuler.

Les problèmes DKIM sont aussi faciles à manquer. Une clé peut être désactivée lors d'un changement de fournisseur, rester en état non-signé, ou casser après une migration de domaine. Quand DKIM ne signe pas, vous perdez un des signaux d'identité les plus solides.

Autres erreurs qui créent rapidement des discordances :

• Activer une politique DMARC stricte (par ex. reject) avant d'avoir confirmé que tous les expéditeurs légitimes sont alignés.
• Mélanger différents domaines From entre modèles et automatisations, si bien que votre marque change selon le message envoyé.
• Supposer qu'un badge « domaine vérifié » signifie que les enregistrements DNS sont parfaitement corrects, alors que des éléments peuvent manquer ou être publiés au mauvais endroit.

Petit exemple : une startup utilise [email protected] pour les réponses clients, mais son outil marketing envoie des newsletters depuis [email protected] et une automatisation utilise un autre domaine From. En même temps, ils ont ajouté un nouvel enregistrement SPF pour l'outil marketing au lieu de mettre à jour l'existant. Certains messages passent, d'autres échouent, et le placement en boîte devient incohérent.

Si vous voyez ce schéma, choisissez vos domaines d'envoi, assurez-vous que chaque outil est inclus dans un seul enregistrement SPF, confirmez que DKIM signe activement et gardez DMARC en surveillance jusqu'à ce que toutes les sources légitimes soient alignées.

Liste de contrôle rapide avant d'envoyer votre prochaine campagne

Avant d'appuyer sur envoyer, faites un rapide contrôle pour confirmer que votre e-mail est bien envoyé en tant que votre domaine (et non « pour le compte de » un domaine fournisseur). C'est le moyen le plus rapide pour attraper les petits réglages qui mènent au spam.

Envoyez-vous un message test vers une boîte Gmail ou Outlook et ouvrez les détails du message (« Afficher l'original », « Voir la source » ou « En-têtes du message »). Vous cherchez deux choses : les adresses visibles correspondent à ce que vous attendez, et les résultats d'authentification indiquent PASS et s'alignent avec votre domaine.

Checklist simple :

• L'adresse From est la vôtre et cohérente avec votre domaine de marque ou le sous-domaine choisi.
• Reply-To est intentionnel et ne surprend pas.
• SPF inclut le service qui transmet réellement le message.
• DKIM est activé, signe et s'aligne avec la même famille de domaines que le From.
• DMARC existe et les rapports (si activés) arrivent.

Après réception du test, recherchez un résumé d'authentification : SPF PASS, DKIM PASS et DMARC PASS. Confirmez aussi que le domaine affiché pour ces PASS correspond à la même famille de domaines que votre adresse From visible.

Exemple : votre From est [email protected], mais dans les en-têtes vous voyez DKIM signé par acme-mailer.com et DMARC en échec. Cela signifie généralement que votre fournisseur n'est pas configuré pour signer au nom d'acme.com, ou que vos enregistrements DNS sont incomplets.

Scénario d'exemple et étapes suivantes si ça va encore en spam

Une petite startup démarre avec un domaine tout neuf et utilise un outil tiers pour envoyer les e-mails d'onboarding. Ils mettent le nom From à leur marque, mais les e-mails semblent « bizarres » dans les boîtes. Certains destinataires voient une étiquette « via », les réponses sont rares et des utilisateurs signalent que le message est en spam.

En général, cela se résume à une discordance entre ce que vous voyez dans le client e-mail et ce que les systèmes vérifient en coulisses. Même si le From visible semble correct, le domaine d'envoi réel (souvent reflété par Return-Path et les domaines de signature) peut être différent. Avec un domaine neuf, cette discordance suffit à rendre les filtres méfiants.

Ce qu'ils ont changé :

• Mise à jour du paramètre From du fournisseur pour utiliser leur vrai domaine (pas un domaine partagé ou par défaut).
• Ajout ou correction des enregistrements SPF, DKIM et DMARC dans le DNS pour le domaine exact qui envoie.
• Séparation des envois par usage : un sous-domaine dédié pour le marketing, tout en gardant le domaine principal pour le courrier personnel.
• Vérification des en-têtes pour confirmer que Return-Path et le domaine DKIM correspondent à leur configuration.

En moins d'une semaine, ils ont constaté moins de rebonds, moins d'étiquettes « via », un meilleur placement en boîte et un branding plus cohérent selon les clients. Les réponses ont aussi augmenté parce que les destinataires faisaient davantage confiance à ce qu'ils voyaient.

Si vos paramètres semblent corrects mais que les messages vont encore en spam, suivez cette démarche de dépannage pratique :

1. Demandez à votre fournisseur quel domaine est utilisé pour le Return-Path et la signature DKIM.
2. Vérifiez le DNS pour des enregistrements SPF dupliqués ou conflictuels.
3. Confirmez que vous n'envoyez pas depuis plusieurs outils sans aligner l'authentification.
4. Passez en revue les changements récents : nouveau domaine, nouvelle plage d'IP ou pic soudain de volume.
5. Pour des destinataires en entreprise, demandez à leur équipe IT quel règle ou signal a déclenché la décision de spam.

Si une appli construite par IA envoie mal (en-têtes incorrects, domaines codés en dur, clés exposées ou flux d'authentification cassés), FixMyMess at fixmymess.ai peut réaliser un audit gratuit et aider à corriger le code et la configuration pour que votre identité d'expéditeur corresponde à ce que les récepteurs vérifient.