Comment fonctionne l’e-mail : un guide technique complet sur les protocoles, les étapes et l’architecture

L’e-mail reste l’épine dorsale de la communication numérique pour les entreprises et les particuliers, pourtant ses mécanismes sous-jacents sont mal compris par la plupart de ses utilisateurs. À sa base, la distribution d’e-mails est un processus de relais en plusieurs étapes régi par une chaîne précise de protocoles — SMTP pour la transmission, les enregistrements DNS MX pour le routage, et IMAP ou POP3 pour la récupération — chacun s’exécutant en séquence pour acheminer un message du client de l’expéditeur vers la boîte de réception du destinataire en quelques secondes.

Comprendre cette architecture n’est pas purement académique. Les administrateurs système, les développeurs et toute personne gérant un environnement de messagerie doivent saisir comment ces composants interagissent pour diagnostiquer les échecs de distribution, renforcer la posture de sécurité, configurer correctement les serveurs et éviter le dossier spam. Ce guide couvre l’ensemble du tableau technique, y compris les cas limites et les modes de défaillance que les articles d’introduction omettent systématiquement.

Composants clés de l’infrastructure e-mail

Avant de retracer le cycle de vie d’un seul e-mail, il est essentiel d’identifier les systèmes distincts impliqués. Chacun joue un rôle non négociable, et une mauvaise configuration dans l’un d’eux peut silencieusement interrompre la distribution.

Client e-mail (MUA — Mail User Agent)

Le Mail User Agent (MUA) est l’interface par laquelle un utilisateur compose, envoie et lit des e-mails. Les exemples incluent Microsoft Outlook, Apple Mail, Mozilla Thunderbird et les clients basés sur navigateur comme l’interface web de Gmail. Le MUA ne distribue pas l’e-mail directement au destinataire. Son rôle est de transmettre le message à un Mail Submission Agent (MSA), fonctionnant généralement sur le port 587 avec authentification, qui le transmet ensuite au serveur SMTP sortant.

Une incompréhension architecturale courante consiste à traiter le MUA et le serveur SMTP comme une seule unité. Ce n’est pas le cas. Le MUA est un client ; l’infrastructure SMTP est la couche de transport.

Serveur de messagerie (MTA — Mail Transfer Agent)

Le Mail Transfer Agent (MTA) est le logiciel serveur responsable du relais des e-mails entre les systèmes. Postfix, Exim, Sendmail et Microsoft Exchange sont les MTA les plus largement déployés. Un MTA peut agir à la fois comme expéditeur et comme récepteur, selon la direction de la transaction. C’est le MTA qui effectue les recherches DNS, établit des connexions SMTP vers des serveurs distants et met les messages en file d’attente pour une nouvelle tentative en cas d’échec de distribution.

Agent de distribution du courrier (MDA)

Souvent négligé dans les explications simplifiées, le Mail Delivery Agent (MDA) est le composant qui prend un message accepté par le MTA récepteur et le place dans la boîte aux lettres correcte de l’utilisateur sur le disque. Dovecot et Courier sont des MDA courants. Le MDA applique les quotas de boîte aux lettres, applique les règles de filtrage côté serveur (scripts Sieve) et écrit le message dans le format de stockage approprié (Maildir ou mbox).

DNS et enregistrements MX

Le Domain Name System est l’épine dorsale de routage de l’e-mail. Sans un enregistrement MX (Mail Exchange) valide, aucun serveur externe ne peut localiser où distribuer le courrier pour un domaine donné. Les enregistrements MX portent une valeur de priorité — les nombres plus faibles indiquent une priorité plus élevée — permettant aux administrateurs de configurer des serveurs de messagerie primaires et de secours. Le MTA expéditeur interroge les enregistrements MX, puis résout le nom d’hôte résultant en une adresse IP via un enregistrement A ou AAAA avant d’initier une connexion.

Le processus de distribution d’e-mails : étape par étape

Étape 1 : Composition et soumission du message

L’utilisateur rédige un message dans son MUA, en spécifiant l’adresse du destinataire, la ligne d’objet, le contenu du corps et les éventuelles pièces jointes. Les pièces jointes et le contenu HTML sont encodés à l’aide de MIME (Multipurpose Internet Mail Extensions), qui encapsule les données binaires dans un format encodé en base64 sûr pour la transmission via SMTP basé sur du texte. Un message avec une pièce jointe PDF, par exemple, est divisé en plusieurs parties MIME : une pour le corps du texte et une pour le binaire encodé.

Lorsque l’utilisateur clique sur « Envoyer », le MUA ouvre une connexion authentifiée et chiffrée vers le serveur de messagerie sortant — généralement sur le port 587 (STARTTLS) ou le port 465 (SMTPS). L’authentification via SASL (Simple Authentication and Security Layer) empêche les abus de relais non autorisés.

Étape 2 : Handshake SMTP et transfert de message

Le MTA expéditeur initie une session SMTP avec un handshake formel :

1. Le client envoie `EHLO` (Extended HELO), s’identifiant par nom d’hôte.
2. Le serveur répond avec ses capacités (par ex., STARTTLS, AUTH, limites SIZE).
3. Le client émet `MAIL FROM:<sender@domain.com>` pour déclarer l’expéditeur de l’enveloppe.
4. Le client émet `RCPT TO:<recipient@domain.com>` pour déclarer le destinataire.
5. Le client envoie `DATA`, suivi de l’intégralité des en-têtes et du corps du message.
6. La session se termine par `QUIT`.

Ce dialogue SMTP est identique que la connexion soit entre un client et son serveur de soumission, ou entre deux MTA relayant du courrier sur Internet.

Étape 3 : Résolution DNS et recherche MX

Avant que le MTA expéditeur puisse se connecter au serveur du destinataire, il doit résoudre la destination. Le processus suit une séquence stricte :

1. Interroger DNS pour les enregistrements MX du domaine du destinataire (par ex., `example.com`).
2. Recevoir un ou plusieurs enregistrements MX, chacun avec un nom d’hôte et une valeur de priorité.
3. Résoudre le nom d’hôte MX en une adresse IP via un enregistrement A (IPv4) ou AAAA (IPv6).
4. Tenter la connexion au premier hôte MX de priorité la plus élevée (numéro le plus bas).

Cas limite critique : Si aucun enregistrement MX n’existe pour un domaine, la RFC 5321 spécifie que le MTA expéditeur doit se rabattre sur l’enregistrement A du domaine et tenter la distribution directement. Ce comportement est souvent exploité dans les domaines mal configurés et peut conduire à des chemins de distribution inattendus. De plus, si l’enregistrement MX pointe vers un CNAME, cela viole la RFC 2181 et peut provoquer des échecs de distribution avec des MTA stricts.

Étape 4 : Relais SMTP de serveur à serveur

Une fois l’adresse IP résolue, le MTA expéditeur établit une connexion TCP sur le port 25 vers le MTA du destinataire. Le port 25 est réservé à la communication de serveur à serveur et est généralement bloqué par les FAI pour les connexions résidentielles afin d’empêcher le spam provenant des plages IP grand public.

Dans les environnements d’entreprise et cloud, l’e-mail peut traverser plusieurs sauts de relais avant d’atteindre sa destination. Chaque relais ajoute un en-tête `Received:` au message, créant une piste d’audit traçable. L’examen de ces en-têtes est la méthode principale pour diagnostiquer les retards de distribution et identifier où un message a été retenu ou rejeté.

Le chiffrement opportuniste STARTTLS est négocié à cette étape si les deux serveurs le prennent en charge. Si le serveur récepteur n’annonce pas STARTTLS, la plupart des MTA se rabattront sur une transmission non chiffrée plutôt que d’échouer la distribution — une faiblesse de sécurité connue que MTA-STS (Mail Transfer Agent Strict Transport Security) est conçu pour résoudre en imposant des connexions chiffrées.

Étape 5 : Acceptation, filtrage et évaluation du spam

Lorsque le MTA récepteur accepte le message, il ne le place pas immédiatement dans la boîte de réception de l’utilisateur. Une série de vérifications se produit :

• SPF (Sender Policy Framework) : Le serveur récepteur interroge le DNS du domaine de l’expéditeur pour un enregistrement TXT listant les adresses IP d’envoi autorisées. Si l’IP d’envoi n’est pas listée, la vérification SPF échoue.
• DKIM (DomainKeys Identified Mail) : Le serveur expéditeur signe cryptographiquement les en-têtes et le corps du message avec une clé privée. Le serveur récepteur récupère la clé publique correspondante depuis DNS et vérifie la signature. Une signature DKIM valide prouve que le message n’a pas été altéré en transit.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) : Relie SPF et DKIM. Le propriétaire du domaine publie une politique DMARC spécifiant quoi faire avec les messages qui échouent à l’authentification — `none` (surveillance uniquement), `quarantine` (envoyer en spam), ou `reject` (rejeter le message). DMARC permet également des rapports agrégés et forensiques.

Après les vérifications d’authentification, le message passe par des moteurs de filtrage de contenu et de score de spam (SpamAssassin, Rspamd ou systèmes propriétaires). Des scores sont attribués en fonction des anomalies d’en-tête, des recherches de listes noires (RBL/DNSBL), des modèles de contenu et de la réputation de l’expéditeur. Les messages dépassant le seuil sont acheminés vers le dossier indésirable ou rejetés.

Étape 6 : Stockage et récupération de la boîte aux lettres

Les messages qui passent tous les filtres sont transmis au MDA, qui les écrit dans la boîte aux lettres de l’utilisateur. Les deux formats de stockage dominants sont :

• Maildir : Chaque message est stocké comme un fichier individuel dans une structure de répertoires. Préféré pour sa résilience — un message corrompu n’affecte pas les autres.
• mbox : Tous les messages d’un dossier sont concaténés dans un seul fichier. Plus simple mais sujet à la corruption et aux problèmes de verrouillage lors d’accès simultanés.

Le client e-mail du destinataire récupère ensuite le message en utilisant soit IMAP soit POP3.

Étape 7 : Récupération par le client via IMAP ou POP3

La dernière étape de la distribution est le client qui extrait le message du serveur de boîte aux lettres. Le choix du protocole a des implications opérationnelles significatives.

Comparaison des protocoles IMAP, POP3 et SMTP

IMAP est le choix correct pour pratiquement tous les déploiements modernes. Il conserve les messages sur le serveur, synchronise l’état lu/non lu, la structure des dossiers et les indicateurs sur chaque appareil connecté en temps réel. La suppression d’un message sur un téléphone est immédiatement reflétée dans le client de bureau.

POP3 télécharge les messages sur l’appareil local et, par défaut, les supprime du serveur. Cela avait du sens à l’ère de l’accès mono-appareil et du stockage serveur limité, mais cela crée de sérieux problèmes dans les environnements multi-appareils et élimine la sauvegarde côté serveur. POP3 doit être considéré comme un protocole legacy pour les nouveaux déploiements.

Architecture de sécurité des e-mails : SPF, DKIM et DMARC en profondeur

Ces trois mécanismes forment une pile d’authentification en couches. Déployer seulement un ou deux d’entre eux laisse des failles exploitables.

SPF — Autorisation au niveau de l’enveloppe

SPF valide l’expéditeur de l’enveloppe (l’adresse `MAIL FROM` utilisée dans le dialogue SMTP, et non l’en-tête `From:` visible par les utilisateurs). Un enregistrement SPF typique ressemble à :

“`

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

“`

Le `~all` softfail permet aux messages provenant d’IP non listées d’être acceptés mais signalés. Le `-all` hardfail demande aux serveurs récepteurs de les rejeter complètement. SPF seul ne protège pas l’en-tête `From:` visible, qui est ce que les utilisateurs voient réellement — c’est pourquoi DMARC est nécessaire.

DKIM — Intégrité cryptographique des messages

DKIM signe un ensemble défini d’en-têtes (généralement `From`, `To`, `Subject`, `Date`) et un hachage du corps du message. La signature est intégrée dans un en-tête `DKIM-Signature:`. Le sélecteur et le domaine dans cet en-tête pointent vers un enregistrement TXT DNS contenant la clé publique. Si le message est modifié après la signature — même un seul caractère dans le corps — la vérification de la signature échoue.

Note opérationnelle importante : Les logiciels de liste de diffusion et certaines configurations de transfert modifient le contenu des messages (ajout de pieds de page, réécriture d’en-têtes), ce qui casse les signatures DKIM. Il s’agit d’une interaction connue entre DKIM et les gestionnaires de listes de diffusion qui nécessite une configuration soigneuse.

DMARC — Application des politiques et alignement

DMARC introduit le concept d’alignement des identifiants : le domaine dans l’en-tête `From:` doit s’aligner avec le domaine authentifié par SPF ou le domaine de signature DKIM. Cela comble la lacune que SPF seul laisse ouverte. Une politique `reject` est la configuration la plus forte :

“`

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=s

“`

`adkim=s` et `aspf=s` imposent un alignement strict, nécessitant une correspondance exacte du domaine plutôt qu’une correspondance de domaine organisationnel.

Sujets avancés : MTA-STS, DANE et ARC

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS permet à un domaine de publier une politique via HTTPS déclarant que les connexions entrantes doivent utiliser TLS et spécifiant quels certificats sont acceptables. Contrairement à STARTTLS, qui est opportuniste et peut être supprimé par un attaquant de type man-in-the-middle, MTA-STS impose le chiffrement. Les MTA expéditeurs qui prennent en charge MTA-STS mettent en cache la politique et refusent de distribuer à un serveur qui ne peut pas la satisfaire.

DANE (DNS-Based Authentication of Named Entities)

DANE utilise des enregistrements TLSA signés par DNSSEC pour lier un certificat TLS spécifique ou une clé publique à un nom d’hôte de serveur de messagerie. Cela élimine la dépendance au modèle de confiance des Autorités de Certification commerciales pour l’authentification des serveurs. L’adoption de DANE est en croissance dans les secteurs gouvernementaux et financiers européens, mais reste limitée dans les déploiements grand public en raison du prérequis de DNSSEC sur les domaines expéditeur et récepteur.

ARC (Authenticated Received Chain)

ARC a été développé pour résoudre le problème de transfert qui casse DMARC. Lorsqu’un message est transféré via un intermédiaire (comme une liste de diffusion ou un alias e-mail), l’alignement SPF et DKIM d’origine peut être rompu. ARC préserve une chaîne d’en-têtes `Received:` authentifiés, permettant au serveur récepteur final d’évaluer l’état d’authentification à chaque saut et de prendre une décision de distribution plus éclairée.

Échecs courants de distribution d’e-mails et diagnostic

Comprendre l’architecture rend le dépannage systématique plutôt que spéculatif.

Symptôme : L’e-mail rebondit avec « 550 5.7.1 Message rejected »

• Cause : Hardfail SPF, rejet DMARC ou mise sur liste noire de l’IP.
• Diagnostic : Vérifiez le message de rebond pour la raison spécifique du rejet. Exécutez `dig TXT yourdomain.com` pour inspecter SPF. Interrogez MX Toolbox ou similaire pour le statut de liste noire.

Symptôme : E-mail distribué dans le dossier spam

• Cause : Softfail SPF, DKIM manquant, faible réputation de l’expéditeur ou déclencheurs de contenu.
• Diagnostic : Examinez l’en-tête `X-Spam-Status` dans le message reçu. Vérifiez que la signature DKIM est active. Vérifiez que l’enregistrement PTR (DNS inverse) pour l’IP d’envoi correspond au nom d’hôte SMTP EHLO.

Symptôme : E-mail retardé avec « 451 Temporary failure »

• Cause : Le serveur récepteur est temporairement indisponible ou limite le débit de l’expéditeur.
• Diagnostic : Le MTA expéditeur mettra en file d’attente et réessaiera automatiquement selon son calendrier de nouvelles tentatives. Vérifiez les journaux MTA pour la file d’attente de nouvelles tentatives. Les erreurs 451 persistantes des grands fournisseurs indiquent souvent des problèmes de réputation IP.

Symptôme : La signature DKIM échoue à la vérification sur le serveur récepteur malgré un enregistrement DNS correct

• Cause : Message modifié en transit (pied de page de liste de diffusion ajouté, en-tête réécrit par un relais).
• Diagnostic : Utilisez un outil de vérification DKIM sur la source brute du message. Vérifiez si la balise `h=` dans l’en-tête DKIM-Signature inclut des en-têtes qui ont été modifiés.

Architecture e-mail pour les environnements hébergés

Pour les entreprises et les développeurs déployant leur propre infrastructure de messagerie, l’environnement d’hébergement affecte directement la délivrabilité et la sécurité. Un environnement VPS Hosting donne un contrôle total sur la configuration MTA, les enregistrements PTR et la réputation IP — des facteurs que les environnements partagés ne peuvent pas fournir. L’exécution de Postfix ou Exim sur un VPS permet un réglage précis des limites de débit, des politiques TLS et des mécanismes d’authentification.

Les organisations nécessitant des e-mails transactionnels à volume élevé ou une isolation complète des locataires voisins bénéficient des Serveurs Dédiés, où l’IP d’envoi est exclusivement attribuée et non partagée avec d’autres clients. La réputation IP sur un serveur dédié est entièrement sous le contrôle de l’opérateur.

Pour les petites opérations qui ne nécessitent pas un MTA autogéré, l’Hébergement E-mail fournit un environnement de messagerie entièrement géré avec SPF, DKIM et DMARC préconfigurés, supprimant la charge opérationnelle de la maintenance du logiciel de serveur de messagerie.

La sécurisation des connexions webmail et client de messagerie nécessite des certificats TLS valides. Les certificats auto-signés génèrent des avertissements client et peuvent provoquer des échecs d’authentification dans les configurations MUA strictes. Le déploiement de Certificats SSL de confiance sur les noms d’hôtes des serveurs de messagerie (par ex., `mail.yourdomain.com`) est une base non négociable pour tout environnement de messagerie en production.

La configuration du domaine est tout aussi fondamentale. Les enregistrements MX, les enregistrements TXT SPF, les enregistrements TXT DKIM et les enregistrements TXT DMARC résident tous dans DNS. Une gestion DNS précise et fiable via un fournisseur d’Enregistrement de Domaine avec un éditeur DNS robuste est essentielle pour maintenir des enregistrements corrects de routage et d’authentification du courrier.

Analyse des en-têtes d’e-mail : lire la piste d’audit

Chaque e-mail porte un ensemble d’en-têtes qui documentent son parcours complet. Ceux-ci sont ajoutés en ordre chronologique inverse — l’en-tête `Received:` le plus en haut est le saut le plus récent. Une chaîne d’en-têtes typique ressemble à :

“`

Received: from mail.example.com (mail.example.com [203.0.113.10])

by mx.google.com with ESMTPS id …

for <recipient@gmail.com>; Mon, 10 Jun 2024 09:15:32 -0700

Received: from [192.168.1.5] (dynamic-pool.isp.net [98.76.54.32])

by mail.example.com with ESMTPSA id …

for <recipient@gmail.com>; Mon, 10 Jun 2024 09:15:29 -0700

“`

En-têtes clés pour le diagnostic :

• `Return-Path:` — L’adresse de l’expéditeur de l’enveloppe utilisée pour les notifications de rebond. Doit s’aligner avec SPF.
• `Authentication-Results:` — Ajouté par le serveur récepteur, documente le résultat des vérifications SPF, DKIM et DMARC.
• `X-Originating-IP:` — Souvent ajouté par les services webmail pour enregistrer l’adresse IP du client.
• `Message-ID:` — Un identifiant globalement unique attribué par le MTA d’origine. Utilisé pour corréler les entrées de journal entre les serveurs.
• `MIME-Version:` et `Content-Type:` — Définissent la structure MIME du corps du message.

Matrice de décision technique et points clés

Utilisez cette liste de contrôle lors de la configuration ou de l’audit d’un environnement de messagerie :

DNS et routage

• Les enregistrements MX sont publiés avec des valeurs de priorité correctes et pointent vers des noms d’hôtes valides, pas des CNAME
• Les enregistrements A/AAAA pour les noms d’hôtes MX se résolvent correctement
• L’enregistrement PTR (DNS inverse) pour l’IP d’envoi correspond au nom d’hôte SMTP EHLO

Pile d’authentification

• L’enregistrement TXT SPF est publié avec `-all` ou `~all` et couvre toutes les sources d’envoi légitimes
• Les clés DKIM sont au minimum 2048 bits ; le sélecteur est publié dans DNS et la signature est active sur le MTA
• La politique DMARC est publiée avec au minimum `p=quarantine` ; les rapports agrégés (`rua`) sont configurés
• Le mode d’alignement DMARC est défini sur `s` (strict) pour les domaines haute sécurité

Sécurité du transport

• STARTTLS est activé sur toutes les connexions SMTP entrantes et sortantes
• La politique MTA-STS est publiée si l’application stricte de TLS est requise
• Un certificat TLS valide signé par une CA est installé sur le nom d’hôte du serveur de messagerie

Configuration de réception

• IMAP est utilisé plutôt que POP3 pour tous les déploiements multi-appareils
• IMAP sur SSL/TLS sur le port 993 est imposé ; le port en clair 143 est désactivé ou restreint
• Le filtrage spam côté serveur (Rspamd ou SpamAssassin) est configuré avec des ensembles de règles à jour

Surveillance opérationnelle

• Les rapports agrégés DMARC sont examinés régulièrement pour détecter les expéditeurs non autorisés
• La file d’attente MTA est surveillée pour les messages différés indiquant des problèmes de distribution
• L’IP d’envoi est vérifiée par rapport aux principales RBL (Spamhaus ZEN, Barracuda, SORBS) de manière planifiée

FAQ

Quelle est la différence entre les ports SMTP 25, 465 et 587 ?

Le port 25 est utilisé exclusivement pour le relais MTA de serveur à serveur et est bloqué par la plupart des FAI pour les utilisateurs finaux. Le port 587 est le port de soumission désigné pour les connexions client-serveur authentifiées et utilise STARTTLS pour la négociation du chiffrement. Le port 465 est le port SMTPS legacy qui encapsule l’intégralité de la session SMTP dans SSL/TLS dès le départ ; il a été brièvement déprécié mais est maintenant formellement réattribué pour la soumission authentifiée avec TLS implicite sous la RFC 8314.

Pourquoi mon e-mail passe-t-il SPF mais échoue quand même DMARC ?

DMARC nécessite un alignement des identifiants entre le domaine authentifié et le domaine de l’en-tête `From:`. SPF authentifie l’expéditeur de l’enveloppe (`MAIL FROM`), qui peut différer de l’en-tête `From:` visible. Si ces domaines ne s’alignent pas (selon le mode d’alignement configuré), DMARC échoue même lorsque SPF réussit. La solution est de s’assurer que le domaine de l’en-tête `From:` correspond au domaine authentifié par SPF, ou de configurer la signature DKIM avec le domaine `From:` afin que l’alignement DKIM satisfasse DMARC à la place.

Qu’est-ce qui cause l’échec de vérification d’une signature DKIM valide sur le serveur récepteur ?

Les causes les plus courantes sont : le corps du message ou les en-têtes signés ont été modifiés en transit (pieds de page de liste de diffusion, réécriture d’en-têtes par des relais) ; l’enregistrement TXT DNS pour le sélecteur DKIM a été supprimé ou modifié après la signature ; ou la clé publique dans DNS ne correspond pas à la clé privée utilisée pour signer le message. Vérifiez toujours en utilisant la source brute du message, pas une copie transférée.

Quelle est la différence pratique entre IMAP et POP3 pour un environnement professionnel ?

IMAP synchronise l’état complet de la boîte aux lettres — indicateurs lu/non lu, structure des dossiers, éléments envoyés, brouillons — sur chaque appareil en temps réel, avec les messages restant sur le serveur. POP3 télécharge les messages sur un appareil et les supprime du serveur par défaut, rendant impossible l’accès à ces messages depuis un second appareil. Pour toute entreprise dont les employés accèdent aux e-mails sur plus d’un appareil, POP3 crée des silos de données et élimine la rétention des messages côté serveur. IMAP est le seul choix approprié.

Comment diagnostiquer pourquoi un e-mail légitime a été distribué dans le dossier spam ?

Récupérez la source brute du message depuis le dossier spam et examinez l’en-tête `Authentication-Results:` pour vérifier les résultats SPF, DKIM et DMARC. Recherchez les en-têtes `X-Spam-Status:` ou `X-Spam-Score:` ajoutés par le filtre du serveur récepteur pour identifier quelles règles ont été déclenchées. Vérifiez que l’IP d’envoi dispose d’un enregistrement PTR correspondant, n’est listée sur aucune RBL, et que le domaine d’envoi dispose d’une pile d’authentification complète. Une signature DKIM manquante ou défaillante combinée à un résultat SPF neutre est la cause la plus fréquente de courrier légitime scoré comme spam.