Pourquoi vos emails sont acceptés, partent en spam ou sont rejetés (SPF, DKIM, DMARC et Jabatus)

La déli­vra­bi­li­té des emails est un enjeu majeur pour toute entre­prise, site web ou adresse pro­fes­sion­nelle. Com­prendre pour­quoi un email arrive en boîte de récep­tion, finit en spam ou est reje­té per­met d’éviter de nom­breux pro­blèmes de com­mu­ni­ca­tion.

Après avoir expli­qué com­ment confi­gu­rer SPF, DKIM et DMARC pour évi­ter les emails en spam, il est essen­tiel d’aller plus loin et de com­prendre com­ment les ser­veurs de récep­tion prennent réel­le­ment leurs déci­sions.

Dans cet article, nous allons voir com­ment fonc­tionne la déli­vra­bi­li­té des emails, quels cri­tères sont ana­ly­sés par les ser­veurs de mes­sa­ge­rie, et pour­quoi, chez o2switch, l’utilisation de Jaba­tus (le sys­tème d’en­voi des emails sor­tant) joue un rôle clé dans ce processus.

Ain­si, lorsqu’un email arrive sur un ser­veur de récep­tion, il passe, au préa­lable, par une série de contrôles auto­ma­tiques. Le ser­veur ne se contente pas de lire le conte­nu du mes­sage : il éva­lue sur­tout le niveau de confiance qu’il peut accor­der à l’expéditeur ou l’expéditrice.

Cette déci­sion repose sur plu­sieurs cri­tères com­bi­nés, qui per­mettent de déter­mi­ner si l’email est légi­time, dou­teux ou clai­re­ment frau­du­leux. Pas­sons en revue ces dif­fé­rents critères.

Premier critère : l’authentification avec SPF, DKIM et DMARC

Le pre­mier élé­ment ana­ly­sé est la pré­sence et la cohé­rence de SPF, DKIM et DMARC.

Si SPF est valide, le ser­veur véri­fie que l’email pro­vient bien d’un ser­veur auto­ri­sé à envoyer des mes­sages pour le domaine.
Si DKIM est valide, il confirme que le mes­sage n’a pas été modi­fié en cours de route et qu’il est bien signé par le domaine expé­di­teur.
Si DMARC est pré­sent, il indique clai­re­ment au ser­veur quoi faire si SPF ou DKIM échouent.

Lorsque SPF, DKIM et DMARC sont cor­rec­te­ment confi­gu­rés et cohé­rents entre eux, l’email part avec un fort niveau de confiance.

À l’inverse, si SPF ou DKIM échouent et qu’aucun DMARC n’est pré­sent pour don­ner des ins­truc­tions, le ser­veur de récep­tion devient méfiant et applique des règles strictes par défaut, sou­vent défa­vo­rables à l’expéditeur.

Pre­nons un exemple concret. Si vous envoyez un email avec pour objet « Fac­ture de jan­vier », ceci n’est pas sus­pect en soi. Pour­tant, un filtre anti­spam peut déci­der de le trai­ter avec pru­dence selon le contexte glo­bal. Si l’email pro­vient d’un domaine récent ou peu connu, avec peu d’historique d’envoi, si l’authentification est incom­plète (SPF ou DKIM par­tiel­le­ment valides, DMARC absent ou en mode obser­va­tion), ou si le conte­nu ne cor­res­pond pas clai­re­ment à l’objet, le niveau de confiance baisse. Par exemple, un mes­sage inti­tu­lé « Fac­ture de jan­vier » qui ne contient aucune fac­ture en pièce jointe, mais seule­ment un lien externe à cli­quer, cor­res­pond à un scé­na­rio très cou­rant de phi­shing. Le filtre peut éga­le­ment tenir compte du com­por­te­ment d’envoi, comme un volume inha­bi­tuel ou un script nou­vel­le­ment ins­tal­lé, ain­si que du fait que le des­ti­na­taire n’ait jamais échan­gé avec ce domaine aupa­ra­vant. Dans ce cas, le ser­veur anti­spam ne bloque pas for­cé­ment l’email, mais peut ajou­ter un aver­tis­se­ment ou un pré­fixe dans l’objet pour pré­ve­nir l’utilisateur (donc, l’ob­jet du mail est modi­fié). Cette modi­fi­ca­tion, bien que légi­time du point de vue de la sécu­ri­té, change le mes­sage ori­gi­nal et peut rendre la signa­ture DKIM invalide.

Donc, il est impor­tant, déjà, de vous assu­rer que SPF, DKIM et DMARC soient bien confi­gu­rés, pour sécu­ri­ser l’au­then­ti­fi­ca­tion de vos envois. 

Deuxième critère : la réputation du domaine et du serveur

Les four­nis­seurs de mes­sa­ge­rie main­tiennent une répu­ta­tion pour chaque domaine et chaque ser­veur d’envoi, un peu comme un his­to­rique de comportement.

Un domaine qui envoie régu­liè­re­ment des emails légi­times, peu signa­lés comme spam, béné­fi­cie d’une bonne répu­ta­tion. Ses mes­sages ont alors plus de chances d’être accep­tés et livrés en boîte de réception.

À l’inverse, un domaine sans his­to­rique, mal confi­gu­ré ou ayant géné­ré des plaintes est consi­dé­ré comme plus ris­qué. Même avec SPF, DKIM et DMARC, une mau­vaise répu­ta­tion peut conduire à un clas­se­ment en spam.

En plus du domaine, les four­nis­seurs de mes­sa­ge­rie éva­luent la répu­ta­tion du ser­veur d’envoi, c’est-à-dire l’adresse IP depuis laquelle l’email est envoyé. Cette répu­ta­tion est indé­pen­dante de celle du domaine et repose sur l’historique de l’IP elle-même.

Un ser­veur peut avoir une mau­vaise répu­ta­tion pour plu­sieurs rai­sons. Il peut avoir été uti­li­sé par le pas­sé pour envoyer du spam, avoir héber­gé des sites com­pro­mis, ou avoir ser­vi à des envois mas­sifs mal maî­tri­sés. Sur des infra­struc­tures mutua­li­sées, il suf­fit par­fois que plu­sieurs uti­li­sa­teurs aient eu de mau­vaises pra­tiques pour que l’IP d’envoi soit sur­veillée de près par les four­nis­seurs de mes­sa­ge­rie. Résul­tat : même un email par­fai­te­ment rédi­gé et cor­rec­te­ment authen­ti­fié peut être clas­sé en spam sim­ple­ment parce qu’il pro­vient d’un ser­veur jugé peu fiable.
À l’inverse, un ser­veur dont les IP envoient régu­liè­re­ment des emails légi­times, peu signa­lés comme spam, béné­fi­cie d’une bonne répu­ta­tion. Les emails envoyés depuis ces IP ins­pirent davan­tage confiance et ont plus de chances d’arriver en boîte de récep­tion.

Lorsqu’un pro­blème de répu­ta­tion ser­veur est iden­ti­fié, il est rare­ment pos­sible de le cor­ri­ger seul, car l’utilisateur ne maî­trise pas direc­te­ment l’IP d’envoi. La solu­tion consiste alors à s’appuyer sur une infra­struc­ture d’envoi contrô­lée, main­te­nue et sur­veillée par l’hébergeur ou par un pres­ta­taire spé­cia­li­sé.
Cela passe par l’utilisation du ser­veur SMTP recom­man­dé, l’envoi via une pas­se­relle offi­cielle, et l’évitement des envois directs depuis des scripts ou des confi­gu­ra­tions non stan­dard. L’objectif est de faire tran­si­ter les emails par des IP dont la répu­ta­tion est sui­vie, net­toyée et pro­té­gée dans le temps.
La répu­ta­tion d’un ser­veur se recons­truit pro­gres­si­ve­ment, grâce à des envois régu­liers, cohé­rents et bien authen­ti­fiés. C’est pour cette rai­son que le choix du ser­veur d’envoi est aus­si impor­tant que la confi­gu­ra­tion du domaine dans une stra­té­gie de déli­vra­bi­li­té email.

C’est pré­ci­sé­ment sur ce point que cer­tains héber­geurs, comme o2switch, ont fait le choix de mettre en place une pas­se­relle d’envoi dédiée afin de maî­tri­ser la répu­ta­tion des IP et d’améliorer dura­ble­ment la déli­vra­bi­li­té des emails. C’est là qu’in­ter­vient Jaba­tus, le sys­tème d’en­voi propre à o2switch.

Troisième critère : la cohérence globale de l’email

Le ser­veur véri­fie éga­le­ment la cohé­rence de l’ensemble du mes­sage. Il observe si l’adresse d’expéditeur cor­res­pond bien au domaine uti­li­sé, si les en-têtes tech­niques sont logiques et si l’email ne tente pas de mas­quer son ori­gine réelle.

Un email peut être tech­ni­que­ment valide mais inco­hé­rent, par exemple s’il est envoyé depuis un ser­veur auto­ri­sé mais sans signa­ture DKIM cor­recte. Ce type d’incohérence aug­mente for­te­ment le risque de clas­se­ment en spam.

Ima­gi­nons que l’on envoie un email avec l’adresse d’expéditeur facturation@mon-domaine.fr. À pre­mière vue, l’email semble légi­time. L’adresse est pro­fes­sion­nelle et cor­res­pond bien au nom de domaine affi­ché.
Mais en ana­ly­sant l’email, le ser­veur de récep­tion constate que le mes­sage a été envoyé depuis un ser­veur appar­te­nant à un tout autre domaine, par exemple autre​-ser​veur​.xyz (au lieu de mon​-domaine​.fr).

Ain­si, même si le SPF de ce ser­veur est auto­ri­sé, le mes­sage est incohérent :

• L’a­dresse affi­chée est celle d’un expé­di­teur pro­ve­nant d’un domaine professionnel
• Mais le ser­veur d’en­voi réel est externe
• La signa­ture DKIM est signée sur un domaine différent

Donc pour les ser­veur de récep­tion, ces signaux sont contra­dic­toires. Le mes­sage n’est pas expli­ci­te­ment frau­du­leux, mais il manque de cohé­rence glo­bale. Le risque de phi­shing ou d’u­sur­pa­tion d’i­den­ti­té est jugé éle­vé. L’email est pla­cé en spam, par précaution.

Quatrième critère : le contenu et le comportement d’envoi

Même lorsque l’authentification tech­nique est cor­recte, les ser­veurs de récep­tion ana­lysent éga­le­ment ce qui est envoyé et com­ment cela est envoyé. Le conte­nu du mes­sage et le com­por­te­ment d’envoi per­mettent d’affiner l’évaluation du niveau de confiance.

Côté conte­nu, les filtres cherchent sur­tout à détec­ter des sché­mas à risque, et non des mots iso­lés. Un email peut être jugé sus­pect s’il pré­sente un déca­lage entre l’objet et le corps du mes­sage, s’il incite for­te­ment à cli­quer sur des liens externes, ou s’il adopte des for­mu­la­tions cou­ram­ment uti­li­sées dans les ten­ta­tives de fraude. La struc­ture du mes­sage est éga­le­ment prise en compte : emails très courts, absence de signa­ture, liens mas­qués ou for­mats inha­bi­tuels aug­mentent la méfiance, même si le mes­sage est tech­ni­que­ment valide.

Le com­por­te­ment d’envoi est tout aus­si impor­tant. Les ser­veurs observent le rythme, le volume et la régu­la­ri­té des envois. Un domaine qui envoie habi­tuel­le­ment quelques emails par jour et qui se met sou­dai­ne­ment à en envoyer des cen­taines en quelques minutes déclenche des méca­nismes de pro­tec­tion. De la même manière, l’envoi d’emails à de nom­breux des­ti­na­taires qui n’ont jamais inter­agi avec le domaine aug­mente le risque de clas­se­ment en spam.

Ces signaux ne suf­fisent pas, à eux seuls, à blo­quer un email bien authen­ti­fié. En revanche, lorsqu’ils s’ajoutent à une répu­ta­tion moyenne ou à une confi­gu­ra­tion par­tiel­le­ment cor­recte, ils peuvent faire bas­cu­ler la déci­sion vers le spam. C’est pour­quoi, pour un site clas­sique ou une adresse pro­fes­sion­nelle, le conte­nu et le com­por­te­ment d’envoi doivent res­ter cohé­rents et pré­vi­sibles afin de pré­ser­ver dura­ble­ment la délivrabilité.

Ain­si, un email est accep­té et arrive en boîte de récep­tion lorsque SPF et DKIM sont valides, que DMARC est pré­sent et cohé­rent, que le domaine pos­sède une répu­ta­tion cor­recte et que l’ensemble du mes­sage est jugé fiable. Le ser­veur estime alors que l’expéditeur est iden­ti­fié, légi­time et digne de confiance.

Un email est géné­ra­le­ment pla­cé en spam lorsque SPF ou DKIM sont absents ou par­tiel­le­ment incor­rects, que DMARC est absent ou impré­cis, ou que la répu­ta­tion du domaine est moyenne. Le ser­veur ne bloque pas tota­le­ment le mes­sage, mais pré­fère le mettre à l’écart par pré­cau­tion. C’est le scé­na­rio le plus fré­quent en cas de confi­gu­ra­tion incom­plète de SPF, DKIM et DMARC.

Le rejet inter­vient lorsque les signaux sont clai­re­ment néga­tifs. Cela se pro­duit par exemple si SPF et DKIM échouent, et que DMARC indique expli­ci­te­ment que les emails non conformes doivent être reje­tés. Dans ce cas, l’email est refu­sé avant livrai­son et n’apparaît même pas dans le dos­sier spam du destinataire.

Le rôle clé de DMARC dans cette décision

DMARC est l’élément qui fait la dif­fé­rence entre une déci­sion floue et une déci­sion maî­tri­sée. Sans DMARC, le ser­veur de récep­tion décide seul, selon ses propres règles.

Avec DMARC, c’est le pro­prié­taire du domaine qui donne les consignes. DMARC per­met donc de reprendre le contrôle sur la manière dont les emails sont traités.

La spécificité d’o2switch : pourquoi l’utilisation de Jabatus est un avantage ?

Une fois ces prin­cipes tech­niques com­pris, il est impor­tant de tenir compte des spé­ci­fi­ci­tés de l’hébergeur uti­li­sé.
Chez o2switch, la confi­gu­ra­tion de SPF, DKIM et DMARC s’appuie sur une infra­struc­ture d’envoi maî­tri­sée, conçue par o2switch pour ren­for­cer la sécu­ri­té, la cohé­rence tech­nique et la déli­vra­bi­li­té des emails.

o2switch a mis en place Jaba­tus, son sys­tème interne d’envoi et de rou­tage des emails sor­tants. Jaba­tus est la pas­se­relle SMTP offi­cielle par laquelle doivent tran­si­ter les emails envoyés un héber­ge­ment chez o2switch.

Son rôle est de cen­tra­li­ser les envois, de sécu­ri­ser l’infrastructure et de garan­tir que les emails partent depuis des ser­veurs et des adresses IP recon­nues et autorisées.

Qu’est-ce que Jabatus exactement ?

Jaba­tus est un ser­veur d’envoi contrô­lé par o2switch, inté­gré à leur infra­struc­ture. Lorsqu’un email est envoyé via Jaba­tus, celui-ci s’assure que le mes­sage est envoyé depuis des IP offi­cielles, décla­rées et main­te­nues par o2switch.

Cela per­met de garan­tir la cohé­rence entre le ser­veur d’envoi, le domaine expé­di­teur et les méca­nismes d’authentification SPF, DKIM et DMARC.

Comment o2switch met en place Jabatus ?

Du côté DNS, o2switch sim­pli­fie la ges­tion en uti­li­sant un méca­nisme SPF basé sur un include. Le domaine auto­rise ain­si auto­ma­ti­que­ment toutes les IP d’envoi offi­cielles d’o2switch, pré­sentes et futures, sans avoir à les décla­rer manuellement.

Du côté ser­veur, les emails envoyés depuis l’hébergement passent par Jaba­tus, qui uti­lise ces IP auto­ri­sées et applique la signa­ture néces­saire. Cette com­bi­nai­son per­met à o2switch d’ajuster ses infra­struc­tures, de faire évo­luer ses IP et de pro­té­ger la répu­ta­tion glo­bale des domaines héber­gés, sans inter­ven­tion de l’utilisateur.

Pourquoi Jabatus améliore la délivrabilité ?

Même avec un SPF, un DKIM et un DMARC cor­rec­te­ment confi­gu­rés, la qua­li­té de déli­vra­bi­li­té dépend aus­si du che­min emprun­té par l’email. En pas­sant par Jaba­tus, les mes­sages uti­lisent une infra­struc­ture recon­nue et cohé­rente, ce qui réduit for­te­ment les risques de clas­se­ment en spam ou de rejet.

Chez o2switch, la déli­vra­bi­li­té repose donc sur une approche glo­bale qui com­bine confi­gu­ra­tion DNS et infra­struc­ture d’envoi maîtrisée.

La FAQ o2switch explique com­ment cela se passe et com­ment faire avec l’au­then­ti­fi­ca­tion SPF et DKIM des mails, pour amé­lio­rer la déli­vra­bi­li­té des email. (La FAQ met d’ailleurs le doigt, sur le fait que les IA donnent une confi­gu­ra­tion de Jaba­tus erronée).

Donc, la déli­vra­bi­li­té email ne repose jamais sur un seul cri­tère, mais sur un équi­libre glo­bal de confiance. Les ser­veurs de récep­tion éva­luent à la fois l’identité tech­nique de l’expéditeur, la répu­ta­tion du domaine et du ser­veur d’envoi, la cohé­rence glo­bale du mes­sage, ain­si que le conte­nu et le com­por­te­ment d’envoi.
SPF, DKIM et DMARC consti­tuent la base indis­pen­sable pour prou­ver l’identité de l’expéditeur. La répu­ta­tion, construite dans le temps, per­met de confir­mer que ces emails sont légi­times et atten­dus. La cohé­rence tech­nique garan­tit que tous les signaux racontent la même his­toire, sans contra­dic­tion entre le domaine affi­ché, le ser­veur uti­li­sé et les signa­tures appli­quées. Enfin, le conte­nu et le rythme d’envoi viennent affi­ner la déci­sion, en détec­tant les com­por­te­ments inha­bi­tuels ou à risque.
Chez o2switch, cette logique s’inscrit dans une approche glo­bale de la déli­vra­bi­li­té. L’utilisation de Jaba­tus per­met de maî­tri­ser le che­min d’envoi des emails, de s’appuyer sur des IP sur­veillées et recon­nues, et d’assurer une par­faite cohé­rence avec SPF, DKIM et DMARC. Cette infra­struc­ture ne rem­place pas une bonne confi­gu­ra­tion ni de bonnes pra­tiques, mais elle en ren­force l’efficacité et la fia­bi­li­té.

On peut résu­mer en disant qu’une confi­gu­ra­tion propre, une infra­struc­ture maî­tri­sée et un com­por­te­ment d’envoi cohé­rent sont les clés pour que les emails arrivent là où ils sont atten­dus : en boîte de réception.