Délivrabilité des emails : comprendre SPF, DKIM, DMARC et le spam score

Envoyer un email ne suffit pas à garantir qu’il sera reçu. Entre votre serveur et la boîte de réception de votre destinataire, une série de filtres évaluent la légitimité de votre message, la réputation de votre domaine et la qualité du contenu. Un email peut très bien être envoyé sans erreur technique et ne jamais être vu.

Cet article explique les mécanismes d’authentification des emails (SPF, DKIM, DMARC), le calcul du spam score, les listes noires de domaines et les bonnes pratiques pour maintenir une bonne délivrabilité. Il fait écho à notre page sur l’automatisation des emails dans un logiciel métier, où nous détaillons comment ces configurations s’intègrent dans un système d’envoi sur mesure.

Email marketing vs email transactionnel : deux réalités de délivrabilité

Avant d’entrer dans les détails techniques, il est utile de distinguer deux catégories d’emails aux enjeux de délivrabilité très différents.

Les emails marketing (newsletters, campagnes promotionnelles, relances commerciales) sont envoyés en masse à des listes de contacts. Ils sont soumis aux règles anti-spam les plus strictes car ils ressemblent structurellement aux spams que les filtres cherchent à bloquer : même expéditeur, même contenu, plusieurs milliers de destinataires simultanés.

Les emails transactionnels (confirmations de commande, réinitialisations de mot de passe, alertes de statut, rappels d’échéance) sont déclenchés par une action précise dans un logiciel, pour un destinataire identifié. Ils ont naturellement un taux d’ouverture plus élevé et sont mieux perçus par les filtres, à condition que leur infrastructure d’envoi soit correctement configurée.

Comment les fournisseurs de messagerie évaluent vos emails

Quand un email arrive sur un serveur destinataire (Gmail, Outlook, Orange…), plusieurs vérifications se déroulent en quelques millisecondes avant que le message soit délivré :

1. Vérification de l’expéditeur : le serveur vérifie que le domaine et l’adresse d’envoi sont autorisés à envoyer des emails (SPF, DKIM, DMARC).
2. Réputation du domaine et de l’IP : le serveur consulte des bases de réputation et des listes noires pour évaluer l’historique du domaine expéditeur.
3. Analyse du contenu : le contenu de l’email est scoré selon des règles qui détectent les patterns typiques des spams.
4. Comportement des destinataires : si les destinataires précédents ont signalé vos emails comme spam ou ne les ont jamais ouverts, cela pèse négativement sur les envois suivants.

SPF : autoriser les serveurs légitimes

Le SPF (Sender Policy Framework) est un enregistrement DNS de type TXT qui liste les adresses IP ou les services autorisés à envoyer des emails au nom de votre domaine.

v=spf1 include:tipimail.com include:_spf.google.com ~all

Quand un serveur destinataire reçoit un email de @votre-domaine.fr, il consulte cet enregistrement pour vérifier que le serveur expéditeur y figure. Si ce n’est pas le cas, l’email peut être marqué comme suspect ou rejeté.

DKIM : signer cryptographiquement vos emails

Le DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à l’en-tête de chaque email. Cette signature est générée par le serveur expéditeur à partir d’une clé privée, et vérifiable par le serveur destinataire via une clé publique publiée dans vos DNS.

Cette mécanique garantit deux choses : l’email provient bien du domaine déclaré, et son contenu n’a pas été altéré en transit. Un email sans signature DKIM n’est pas rejeté systématiquement, mais son absence pèse sur le score de confiance attribué par les filtres.

La configuration DKIM se fait côté plateforme d’envoi (Tipimail, Brevo, Mailgun…) et requiert l’ajout d’un enregistrement DNS TXT sur votre domaine. C’est une opération ponctuelle, réalisée une fois lors de la mise en place du système d’envoi.

DMARC : la politique d’authentification

Le DMARC (Domain-based Message Authentication, Reporting and Conformance) est le troisième protocole de la chaîne. Il s’appuie sur SPF et DKIM pour définir ce que le serveur destinataire doit faire quand un email échoue ces vérifications.

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@votre-domaine.fr

La politique (p=) peut être :

• none : surveillance uniquement, aucun email n’est bloqué (utile en phase de démarrage)
• quarantine : les emails suspects sont déplacés en spam
• reject : les emails suspects sont rejetés et jamais délivrés

DMARC inclut aussi un mécanisme de reporting : les serveurs destinataires envoient des rapports agrégés à l’adresse définie dans rua, ce qui permet de détecter des envois non autorisés depuis votre domaine (usurpation d’identité, phishing).

Le spam score : l’évaluation du contenu

Même avec SPF, DKIM et DMARC correctement configurés, le contenu de l’email est analysé par les filtres anti-spam. Chaque règle enfreinte ajoute des points à un score global. Au-delà d’un seuil (généralement 5 sur 10 dans SpamAssassin, outil de référence), l’email est catégorisé comme spam.

Parmi les règles qui font monter le score :

• Ratio image/texte déséquilibré : un email composé principalement d’images et peu de texte est un pattern classique de spam.
• Mots déclencheurs (“gratuit”, “urgent”, “offre limitée”, “cliquez ici”) dans l’objet ou le corps du message.
• Liens vers des domaines à mauvaise réputation : un seul lien vers un domaine blacklisté peut faire rejeter l’email entier.
• Absence d’en-têtes standards : un email sans List-Unsubscribe, sans texte alternatif (text/plain) ou sans balise de désinscription est suspect pour les filtres.
• Objet en majuscules ou contenant des caractères spéciaux excessifs.

Des outils comme Mail Tester permettent d’analyser un email avant envoi et d’identifier les règles qui dégradent son score.

Les listes noires de domaines

Les listes noires (ou “blacklists”) sont des bases de données qui référencent les domaines et adresses IP connus pour envoyer du spam. Les principaux acteurs sont Spamhaus, Barracuda, SURBL et MX Toolbox.

Un domaine peut se retrouver en liste noire pour plusieurs raisons :

• Taux de plaintes trop élevé : si trop de destinataires signalent vos emails comme spam, votre domaine est rapidement signalé.
• Envoi vers des adresses invalides (hard bounces) : envoyer massivement à des adresses inexistantes est un signal fort d’une liste mal entretenue.
• Domaine récent : un domaine créé il y a moins de 6 mois est par définition moins fiable pour les filtres. Il faut construire sa réputation progressivement.
• Partage d’IP avec des expéditeurs problématiques : sur une IP mutualisée (serveurs SMTP partagés), la réputation des autres expéditeurs vous affecte aussi.

Pour vérifier si votre domaine est listé : MX Toolbox Blacklist Check. En cas de listing, chaque blacklist a une procédure de demande de suppression (délisting) à suivre après avoir corrigé la cause.

Les bounces : savoir si votre email est arrivé

Un bounce est un échec de livraison. Il en existe deux types aux conséquences très différentes.

Le hard bounce se produit quand l’adresse de destination est définitivement invalide (domaine inexistant, boîte supprimée). Ces adresses doivent être immédiatement exclues de vos listes d’envoi : les conserver et continuer à envoyer dégrade rapidement votre réputation.

Le soft bounce est temporaire (boîte pleine, serveur temporairement indisponible). Une stratégie de retry automatique peut s’appliquer, mais après plusieurs tentatives infructueuses l’adresse doit être traitée comme un hard bounce.

Un système d’envoi bien construit remonte ces informations via les webhooks de la plateforme d’envoi (Tipimail, Brevo…) et les enregistre dans votre logiciel. Vous disposez ainsi, pour chaque email envoyé, d’un historique de statuts : délivré, ouvert, cliqué, hard bounce, soft bounce, rejeté, filtré. Ce suivi alimente directement la logique métier : ne pas relancer un contact en hard bounce, alerter un administrateur en cas d’erreur répétée sur un dossier.

Bonnes pratiques pour maintenir une délivrabilité saine

Au-delà de la configuration technique, quelques pratiques editoriales et opérationnelles protègent durablement votre réputation d’expéditeur.

Gérer les listes proprement : supprimer les adresses en hard bounce immédiatement, honorer les demandes de désinscription sous 10 jours (obligation légale RGPD), ne pas réactiver des contacts inactifs depuis plus de 2 ans sans opt-in explicite.

Échauffer un nouveau domaine ou une nouvelle IP : commencer par de petits volumes (50 à 100 emails par jour), augmenter progressivement sur 4 à 6 semaines. Les filtres analysent l’historique et font davantage confiance à un expéditeur dont le volume augmente régulièrement.

Séparer les usages : les emails transactionnels et les emails marketing ont des comportements très différents. Les envoyer depuis des sous-domaines distincts (notifications@ et newsletter@) protège la réputation du transactionnel si une campagne marketing génère des plaintes.

Surveiller les métriques : taux d’ouverture en dessous de 15%, taux de plaintes au-dessus de 0,1%, bounces supérieurs à 2% sont des signaux d’alerte à traiter rapidement.

Tester avant d’envoyer : des outils comme Mail Tester ou GlockApps permettent de simuler la réception d’un email sur les principaux fournisseurs et d’identifier les problèmes de configuration avant le déploiement.

Références

Les protocoles d’authentification sont documentés par leurs organismes de standardisation et par les grands acteurs de la messagerie :

• RFC 7208 : Sender Policy Framework (SPF) — spécification officielle du protocole SPF
• RFC 6376 : DomainKeys Identified Mail (DKIM) — spécification officielle du protocole DKIM
• RFC 7489 : DMARC — spécification officielle du protocole DMARC
• Google : bonnes pratiques pour les expéditeurs d’emails — recommandations de Gmail pour la délivrabilité, particulièrement importantes depuis les nouvelles exigences de 2024 (volume > 5 000 emails/jour)
• Sarbacane : guide de la délivrabilité — ressource pratique en français sur les bonnes pratiques d’envoi
• MX Toolbox : diagnostic et blacklist check — outils de diagnostic en ligne (SPF, DKIM, DMARC, blacklists)
• SpamAssassin