Mails dans les spams chez OVH

Sommaire

1. Pourquoi un domaine tout neuf finit dans les spams
2. Établir l’état des lieux avant toute modification
3. Ajouter l’enregistrement DMARC
4. Contrôler le SPF, et pourquoi il ne faut pas le durcir tout de suite
5. Vérifier la signature DKIM
6. Le nom de l’expéditeur et la signature en image
7. Sécuriser le compte et contrôler le résultat
8. Récapitulatif avant / après

1. Pourquoi un domaine tout neuf finit dans les spams

Un indépendant qui démarre son activité achète un nom de domaine, ouvre une adresse professionnelle, rédige une présentation de ses services et l’envoie à ses premiers contacts. Le message n’arrive jamais. Ou plutôt si, mais dans un dossier que personne ne consulte.

La messagerie du destinataire se pose deux questions à la réception : cet expéditeur est-il bien celui qu’il prétend être, et le connaît-on déjà ? Un domaine créé le mois dernier ne peut répondre oui ni à l’une ni à l’autre. S’y ajoutent souvent des réglages incomplets, laissés en l’état parce que personne n’a expliqué qu’ils existaient.

Depuis février 2024, Google et Yahoo exigent de tout expéditeur au minimum une authentification SPF ou DKIM, et une politique DMARC publiée pour les gros volumes. Un petit expéditeur sans DMARC n’est pas rejeté pour autant, mais cette absence pèse dans la note de réputation, et sur un domaine sans historique cette note est tout ce dont dispose le filtre pour décider.

Bonne nouvelle : dans la grande majorité des cas, le problème se règle en une seule ligne ajoutée à la zone DNS.

2. Établir l’état des lieux avant toute modification

Avant de corriger, il faut savoir ce qui passe déjà et ce qui ne passe pas. La méthode la plus fiable ne demande aucun outil payant.

Envoyer un message depuis l’adresse concernée vers une adresse Gmail. Ouvrir ce message dans Gmail, cliquer sur les trois points en haut à droite, puis sur « Afficher l’original ». Une page s’ouvre avec trois lignes en haut : SPF, DKIM et DMARC, chacune suivie de PASS, FAIL ou d’une mention d’absence.

C’est le diagnostic complet, en dix secondes, et il servira aussi de contrôle final une fois les corrections faites. Conserver une capture de cette page : elle constitue l’état initial.

Un service comme mail-tester.com donne une note plus détaillée, contenu du message compris, et complète utilement ce premier relevé.

3. Ajouter l’enregistrement DMARC

C’est la correction la plus rentable, et souvent la seule qui manque. DMARC est l’enregistrement qui indique aux messageries quoi faire des messages qui se présentent au nom du domaine sans réussir les contrôles. Sans lui, SPF et DKIM peuvent parfaitement fonctionner sans que personne n’en tire de conclusion.

Dans l’espace client OVHcloud, se rendre dans la partie Web Cloud, section Noms de domaine, sélectionner le domaine, puis l’onglet de la zone DNS. Les libellés des menus changent au fil des refontes de l’interface, la logique reste la même.

Ajouter une entrée de type TXT avec :

Sous-domaine :

_dmarc

TTL :

valeur par défaut

Valeur :

v=DMARC1; p=none; rua=mailto:postmaster@ledomaine.lu

Remplacer ledomaine.lu par le domaine réel, et vérifier que l’adresse indiquée après rua existe bel et bien : c’est là qu’arriveront les rapports.

La mention p=none signifie : ne rien bloquer, se contenter d’observer. C’est volontaire. On ne durcit une politique qu’après avoir constaté pendant quelques semaines que tous les envois légitimes passent. Passer directement à p=reject sur une configuration mal connue, c’est prendre le risque de faire disparaître ses propres factures.

Si les serveurs DNS du domaine ne sont pas ceux d’OVHcloud, l’enregistrement doit être créé chez l’hébergeur qui gère réellement la zone, pas chez le bureau d’enregistrement.

4. Contrôler le SPF, et pourquoi il ne faut pas le durcir tout de suite

Le SPF liste les serveurs autorisés à envoyer au nom du domaine. Sur une offre de messagerie OVHcloud, il ressemble à ceci :

v=spf1 include:mx.ovh.com ~all

Deux pièges classiques. Le premier : il ne doit exister qu’un seul enregistrement SPF par domaine, deux lignes concurrentes invalident l’ensemble. Le second : le tilde de ~all signifie « échec souple », c’est-à-dire « ce n’est probablement pas moi, mais ne jetez pas ». La version stricte -all demande de rejeter.

La tentation est grande de passer tout de suite en -all. Prudence : beaucoup d’indépendants rédigent leurs messages depuis un logiciel qui les fait sortir par un autre serveur que celui de l’hébergeur, sans le savoir. Une plateforme de facturation, un formulaire de site, un outil de newsletter font pareil. Chaque serveur légitime doit figurer dans le SPF avant de fermer la porte, sinon on se bloque soi-même.

La bonne séquence : publier DMARC en p=none, lire les rapports pendant deux à quatre semaines, identifier tous les serveurs qui envoient réellement, les ajouter, et seulement alors durcir.

5. Vérifier la signature DKIM

DKIM appose une signature cryptographique sur chaque message sortant. La clé publique correspondante doit être présente dans la zone DNS.

Sur une offre MX Plan, OVHcloud gère cette clé sous forme d’alias, avec un enregistrement du type ovhmo-selector-1._domainkey pointant vers l’infrastructure de signature. Il s’active depuis la section E-mails de l’espace client, et sa présence se contrôle depuis la zone DNS.

Le retour de Gmail, dans la page « Afficher l’original » vue plus haut, indique si la signature est valide. Si DKIM affiche PASS et que DMARC affiche quand même un échec, c’est en général que le domaine de la signature ne correspond pas au domaine affiché dans l’expéditeur, cas fréquent lorsque les messages sont composés chez un fournisseur et expédiés par un autre.

6. Le nom de l’expéditeur et la signature en image

Deux détails de présentation pèsent plus lourd que leur apparence ne le laisse croire.

Le nom affiché. Quand le destinataire voit contact@ledomaine.lu au lieu du prénom et du nom, le message a l’allure d’un envoi automatique. Ce nom se règle dans les paramètres du compte de messagerie ou du logiciel utilisé, pas dans le DNS, et l’opération prend une minute.

La signature sous forme d’image. Une signature composée d’un visuel de cinquante kilo-octets avec trois lignes de texte autour coche plusieurs cases défavorables d’un coup : ratio image sur texte déséquilibré, information illisible pour un filtre, et affichage bloqué par défaut chez une bonne partie des destinataires, qui ne verront donc ni le téléphone ni l’adresse. La correction consiste à reprendre le texte contenu dans l’image et à le saisir comme véritable texte dans la signature. La mise en forme et les couleurs restent possibles, un petit logo aussi, mais l’information doit exister sous forme de caractères.

7. Sécuriser le compte et contrôler le résultat

Tant qu’on est dans l’espace client, deux gestes méritent d’être faits dans la foulée.

Activer la double authentification sur le compte de l’hébergeur. Un mot de passe seul donne accès au domaine, aux boîtes mail et à la facturation, et un domaine détourné, c’est une identité professionnelle qui change de main.

Vérifier qu’un site, même minimal, répond à l’adresse du domaine. Un domaine qui envoie des messages de présentation commerciale et qui ne mène qu’à une page d’attente de l’hébergeur est le profil type du domaine jetable. Une page unique avec le nom, l’activité et un moyen de contact suffit à faire la différence, pour les filtres comme pour les prospects qui iront vérifier.

Compter quelques heures pour que les modifications DNS se propagent, parfois jusqu’à vingt-quatre. Renvoyer ensuite un message vers l’adresse Gmail de test et rouvrir « Afficher l’original » : les trois lignes doivent afficher PASS.

Reste le facteur temps. La réputation d’un domaine se construit sur des échanges réels. Dans les premières semaines, mieux vaut écrire à des correspondants qui répondront, et éviter les envois groupés à des dizaines de destinataires inconnus.

8. Récapitulatif avant / après

DMARC
Avant :

aucun enregistrement _dmarc

Après :

TXT sur _dmarc, valeur v=DMARC1; p=none; rua=mailto:postmaster@ledomaine.lu

SPF
Avant :

v=spf1 include:mx.ovh.com ~all

Après :

inchangé dans un premier temps, complété plus tard des autres serveurs d'envoi, puis durci en -all

DKIM
Avant :

à vérifier dans la zone

Après :

alias présent et signature validée à la réception

Nom affiché
Avant :

l'adresse mail

Après :

prénom et nom

Signature
Avant :

image

Après :

texte, logo réduit en complément

Compte hébergeur
Avant :

mot de passe seul

Après :

double authentification active

Noter les valeurs relevées dans la colonne « avant » avant d’appliquer quoi que ce soit. C’est ce qui permet de revenir en arrière sans réfléchir si un envoi se met à échouer dans l’heure qui suit.

Conclusion

Un mail qui part dans les spams n’est presque jamais un problème de contenu. C’est un problème d’identité : le domaine n’a pas encore prouvé qu’il est bien le sien. Les quatre lignes décrites ici apportent cette preuve, et le reste vient avec le temps et les échanges.

Avertissement de responsabilité : les manipulations décrites concernent une configuration de messagerie hébergée chez OVHcloud à la date de publication. Les interfaces et les libellés évoluent. Chacun reste responsable des modifications appliquées à sa propre zone DNS, et il est vivement conseillé de relever l’existant avant toute intervention. En cas de doute sur la configuration d’envoi réellement utilisée, se faire accompagner coûte moins cher qu’une semaine de messages perdus.

À propos : article rédigé en septembre 2026. Les exigences citées pour Google et Yahoo sont celles entrées en vigueur en février 2024, telles que publiées dans les directives aux expéditeurs de Google. Le fonctionnement de DMARC est défini par la RFC 7489. Les chemins d’accès dans l’espace client correspondent à l’interface OVHcloud en vigueur à la date de rédaction.