MX, SPF, DKIM, DMARC chez LWS : le guide complet 2026

Vos e-mails professionnels peuvent être parfaitement légitimes et pourtant finir en spam, arriver avec retard ou être rejetés par certaines messageries. Dans la majorité des cas, le problème ne vient pas du texte du message, mais d’une configuration DNS incomplète ou incohérente autour de MX, SPF, DKIM et DMARC.

Chez LWS, ce point mérite une attention particulière, car la bonne configuration dépend du service réellement utilisé : LWS Panel, cPanel, VPS, ou encore une zone DNS gérée chez un prestataire externe comme Cloudflare. Autrement dit, il ne suffit pas de copier un bloc DNS trouvé dans un tutoriel générique. Il faut vérifier quel panneau contrôle votre zone DNS, quelles valeurs LWS vous fournit réellement et comment ces valeurs s’articulent avec vos outils d’envoi.

Concrètement, le MX sert à recevoir les e-mails, le SPF autorise les serveurs à envoyer au nom de votre domaine, le DKIM signe vos messages et le DMARC définit la politique à appliquer si l’authentification échoue. Si un seul de ces éléments est incohérent, vos messages peuvent être traités comme suspects, même si votre adresse utilise votre propre nom de domaine.

En 2026, cette configuration n’est plus un détail technique. Google indique que SPF ou DKIM sont attendus pour tous les expéditeurs, et que les expéditeurs plus volumineux doivent mettre en place SPF, DKIM et DMARC → l’authentification n’est plus optionnelle → une configuration incomplète augmente le risque de spam ou de rejet.

Pourquoi vos e-mails LWS arrivent en spam malgré une adresse professionnelle ?

Avoir une adresse comme [email protected] ne garantit pas que vos messages seront bien reçus. Pour Gmail, Outlook ou Yahoo, une adresse professionnelle n’est qu’un point de départ. Ce qui compte ensuite, c’est la capacité de votre domaine à prouver que l’e-mail envoyé est bien légitime.

La première cause fréquente est une configuration DNS incomplète. Un domaine peut recevoir des e-mails correctement grâce à un MX valide, tout en échouant sur l’envoi parce que le SPF n’autorise pas le bon serveur, que le DKIM n’est pas activé ou que le DMARC n’existe pas.

La deuxième cause fréquente est l’usage de plusieurs outils d’envoi non déclarés. Vous envoyez peut-être depuis le webmail LWS, mais votre site, un formulaire, un plugin WordPress ou un outil externe peuvent eux aussi envoyer des e-mails au nom de votre domaine.

Google recommande de maintenir un taux de spam signalé inférieur à 0,1 % et de ne pas atteindre 0,3 % → l’authentification technique réduit le risque de rejet → mais la réputation du domaine, le contenu du message et l’engagement des destinataires continuent d’influencer l’arrivée en boîte de réception.

Enfin, chez LWS, un piège fréquent vient du mauvais panel de gestion. Si votre domaine utilise des DNS externes, modifier la zone DNS dans LWS peut ne produire aucun effet.

Qu’est-ce qu’un enregistrement MX et à quoi sert-il vraiment ?

Un enregistrement MX, pour Mail Exchange, indique quel serveur doit recevoir les e-mails destinés à votre nom de domaine. Quand quelqu’un envoie un message à [email protected], ce sont les enregistrements MX qui disent à Internet où livrer cet e-mail.

Le MX sert donc au routage de la réception. Si ce réglage est absent, erroné ou pointe vers un ancien service, vous risquez des non-réceptions, des rebonds ou une réception sur la mauvaise plateforme.

Sa limite est importante : un MX correct ne remplace ni SPF, ni DKIM, ni DMARC.

• MX : reçoit les e-mails
• SPF : autorise certains serveurs à envoyer pour votre domaine
• DKIM : signe les messages sortants
• DMARC : indique quoi faire si l’authentification échoue

Autre point utile : chez LWS, la logique documentée passe souvent par un MX qui pointe vers mail.votredomaine.ext, avec un enregistrement A associé sur mail → le MX désigne une destination mail → l’enregistrement A permet de résoudre cette destination vers une IP.

Configurer les MX pour LWS Mail sans casser la réception

Avant de modifier vos MX, vérifiez quel service gère réellement votre messagerie et quelle zone DNS est autoritaire pour votre domaine.

• le MX du domaine pointe vers mail.votredomaine.ext
• le sous-domaine mail possède un enregistrement A
• cet enregistrement A pointe vers l’IP du serveur mail attribué à votre service

Cela ne signifie pas qu’une paire universelle du type mx1 / mx2 s’applique à tous les comptes LWS. Relevez les valeurs réellement affichées dans votre environnement.

• identifiez si votre domaine utilise les DNS LWS ou des DNS externes
• ouvrez l’administration du service mail concerné
• relevez l’IP serveur mail et les valeurs indiquées par LWS
• vérifiez si le MX attendu repose sur mail.votredomaine.ext
• contrôlez que l’enregistrement A de mail pointe bien vers le bon serveur

SPF : autoriser LWS à envoyer vos e-mails

Chez LWS, la documentation officielle donne notamment cet exemple pour un service mail LWS Panel :

v=spf1 mx:lws.fr ip4:172.67.68.219 a:mail.lws.fr a:mailphp.lws-hosting.com -all

Dans d’autres cas, LWS documente aussi une logique de type :

v=spf1 mx:MONDOMAINE.EXT a:mail.MONDOMAINE.EXT a:mailphp.lws-hosting.com -all

Ces valeurs doivent être lues comme des exemples liés à un service précis, pas comme une chaîne universelle à recopier sans vérification. Avant de publier un SPF, vérifiez toujours la valeur réellement fournie par votre environnement LWS.

Vous ne devez publier qu’un seul SPF par domaine.

• relevez la valeur recommandée dans votre service mail LWS
• vérifiez si d’autres outils envoient des e-mails pour votre domaine
• fusionnez les sources dans un seul enregistrement TXT
• supprimez les doublons éventuels
• attendez la propagation DNS
• testez ensuite le résultat

DKIM : signer vos e-mails sortants avec LWS

Le DKIM ajoute une signature cryptographique à vos e-mails sortants. Si vos DNS sont gérés ailleurs, l’activation côté service mail ne suffit pas si la clé publique n’est pas publiée dans la zone DNS réellement active.

• activez DKIM dans le panel adapté
• récupérez la valeur ou la clé publique si vos DNS sont externes
• vérifiez que l’enregistrement dkim._domainkey existe publiquement
• envoyez un e-mail test
• contrôlez dans les en-têtes que dkim=pass

Google recommande une clé DKIM de 1024 bits minimum et 2048 bits si votre fournisseur le permet → une clé plus robuste améliore la solidité de la signature → mieux vaut privilégier une configuration moderne quand elle est disponible.

DMARC : définir une politique de sécurité lisible et progressive

Le DMARC relie SPF et DKIM à une politique de sécurité exploitable. Son rôle est d’indiquer aux messageries destinataires quoi faire lorsqu’un message prétend venir de votre domaine sans réussir correctement l’authentification.

v=DMARC1; p=none; rua=mailto:[email protected]

• p=none → vous observez les flux et les échecs
• p=quarantine → vous commencez à traiter les messages suspects comme du spam
• p=reject → vous demandez le rejet des messages non conformes

Dans un contexte TPE ou freelance chez LWS, commencer en p=none est souvent le choix le plus prudent.

BIMI : le bonus branding à envisager en 2026

BIMI n’est pas une priorité tant que MX, SPF, DKIM et DMARC ne sont pas déjà propres. C’est un bonus branding, pas la première étape pour sortir vos e-mails du spam.

Vérifier sa configuration MX, SPF, DKIM et DMARC

• contrôlez le DNS public avec Google Admin Toolbox Dig ou DNS Checker
• vérifiez la cohérence générale avec MXToolbox
• envoyez un test réel avec mail-tester.com

Vous cherchez en général : spf=pass, dkim=pass et dmarc=pass.

Tableau comparatif : MX, SPF, DKIM, DMARC

Erreurs fréquentes chez LWS et comment les corriger

DNS modifiés au mauvais endroit
Si votre domaine utilise un DNS externe, modifier seulement LWS ne suffit pas.

Plusieurs SPF en même temps
Un domaine ne doit publier qu’un seul SPF. Plusieurs lignes distinctes peuvent invalider la politique.

Si le MX repose sur mail.votredomaine.ext, l’enregistrement A correspondant doit être correct lui aussi.

DKIM activé dans le panel mais absent publiquement
Cas classique si les DNS sont gérés ailleurs.

DMARC publié mais jamais exploité
Un p=none permanent sans lecture des rapports protège peu.

Configuration correcte mais spam persistant
Google indique qu’un taux de spam signalé supérieur à 0,1 % a déjà un impact négatif → l’authentification aide à établir la confiance → mais la réputation du domaine reste déterminante.

Section Top10hebergeursweb

LWS peut convenir si vous recherchez une solution française, accessible et relativement abordable pour une TPE, un freelance ou un site vitrine.

Pour prolonger cette réflexion, les articles suivants vous intéressent sûrement :

• LWS Webmail,
• Infomaniak Workspace,
• Email pro français vs Google Workspace,
• Migrer depuis Gmail.

Conclusion

Bien configurer MX, SPF, DKIM et DMARC chez LWS n’est pas une formalité. C’est la base qui permet à votre domaine de recevoir correctement les e-mails, d’authentifier ses envois et de limiter les classements en spam ou les rejets injustifiés.

Si vos e-mails arrivent encore en spam, il ne faut pas supposer trop vite que le problème vient uniquement de LWS. Dans la plupart des cas, l’explication se trouve dans un SPF incomplet, un DKIM non publié publiquement, un DMARC trop passif, un ancien service encore présent dans les MX ou un DNS modifié au mauvais endroit.

FAQ

Quels soX de LWS Mail nt les M?

La documentation LWS consultée ne permet pas d’affirmer une paire universelle du type mx1 / mx2. Dans le cas standard documenté, LWS utilise plutôt une logique où le MX pointe vers mail.votredomaine.ext.

Comment configurer le SPF chez LWS ?

Le SPF se publie comme un enregistrement TXT sur votre domaine. La bonne pratique consiste à publier un seul SPF, avec toutes les sources d’envoi légitimes regroupées dans la même ligne.

Pourquoi mes e-mails LWS arrivent-ils en spam ?

Le problème vient souvent d’une configuration incomplète ou incohérente : SPF incomplet, DKIM absent ou non publié, DMARC inexistant, DNS modifiés au mauvais endroit ou plusieurs outils d’envoi non déclarés.

DMARC est-il obligatoire en 2026 ?

Pas de manière identique pour tous les petits expéditeurs, mais il devient clairement un standard attendu. Pour les expéditeurs plus volumineux, Google demande SPF, DKIM et DMARC.

Comment vérifier DKIM sur un domaine LWS ?

Vérifiez que la clé publique DKIM est bien publiée dans le DNS public, puis envoyez un e-mail test et contrôlez que les en-têtes affichent dkim=pass.

Que faire si mon domaine LWS utilise Cloudflare pour les DNS ?

Dans ce cas, les enregistrements MX, SPF, DKIM et DMARC doivent être publiés chez Cloudflare, pas seulement dans l’espace LWS.