Vos emails professionnels arrivent en spam : comprendre SPF, DKIM et DMARC

Une facture envoyée à un client apparaît dans ses indésirables. Un message commercial arrive chez certains destinataires mais pas chez d’autres. Votre prestataire recommande alors SPF, DKIM et DMARC. Ces mécanismes sont importants, mais leur présence ne garantit pas la boîte de réception.

Pour résoudre le problème, il faut d’abord comprendre ce qu’ils vérifient, quels services envoient réellement des messages pour votre domaine et ce que montrent les réponses des destinataires. Modifier une ligne DNS sans inventaire peut aussi bloquer des envois légitimes.

Un email utilise plusieurs identités

L’adresse affichée à l’utilisateur dans le champ d’expéditeur n’est pas la seule identité du message. Le transport possède aussi une adresse d’enveloppe utilisée pour certaines opérations, et une signature DKIM peut annoncer son propre domaine. Ces valeurs peuvent différer dans un envoi légitime.

Cette distinction explique pourquoi « le message vient de mon domaine » reste une description incomplète. Il faut savoir de quelle identité on parle. Les en-têtes techniques permettent d’examiner ces informations, mais leur présentation varie selon le logiciel de messagerie.

Avant tout changement, récupérez un exemple réellement reçu, si possible avec ses en-têtes complets. Ne partagez pas publiquement les données personnelles qu’ils peuvent contenir. Relevez le résultat d’authentification et l’expéditeur utilisé par le service concerné.

Séparez aussi les flux. Les factures, les notifications de mot de passe, les réponses du support et les campagnes commerciales peuvent provenir de plateformes différentes. Un réglage correct pour la messagerie des salariés ne valide pas automatiquement la boutique ou le logiciel de facturation.

Le premier travail est donc un inventaire.

Pas une chasse au meilleur objet d’email.

SPF : autoriser les sources pour l’identité de transport

SPF permet de déclarer des sources autorisées à envoyer pour un domaine utilisé dans l’identité de transport, notamment MAIL FROM ou HELO selon le cas. Il ne vérifie pas directement, à lui seul, que l’adresse visible dans le champ From est celle que vous voulez protéger.

Les mécanismes de la politique peuvent faire intervenir des adresses IP ou des références à d’autres domaines. La spécification prévoit une limite de dix termes entraînant des recherches DNS parmi les mécanismes concernés. Ce n’est pas une permission d’empiler indéfiniment des services dans une ligne.

La configuration doit être cohérente pour le domaine concerné. Plusieurs politiques SPF séparées publiées comme si chacune s’appliquait indépendamment peuvent produire une erreur. Si un prestataire vous fournit un ajout, faites l’intégrer à la politique existante par une personne qui comprend les autres sources d’envoi.

Les transferts de messages peuvent également modifier le contexte de vérification. Un échec SPF observé après un transfert n’implique pas automatiquement que l’envoi initial était frauduleux. Il faut examiner la chaîne et les autres mécanismes.

Conservez enfin les paramètres avant modification. Un domaine peut contenir des envois rares mais importants, comme des notifications administratives. Leur faible volume ne les rend pas dispensables. L’inventaire doit couvrir ces cas avant une restriction.

DKIM : une signature, pas un chiffrement

DKIM utilise une signature associée à un domaine, avec une clé publique publiée dans le DNS. Le destinataire peut vérifier certains éléments signés du message. Le sélecteur permet notamment de retrouver la clé prévue pour cette signature.

DKIM ne chiffre pas le contenu de l’email. Une signature valide ne signifie pas que le message ne peut être lu par les intermédiaires ou qu’il est commercialement souhaitable. Elle renseigne sur l’authentification et l’intégrité des parties couvertes par la signature.

Les services d’envoi peuvent proposer une signature liée à votre domaine ou utiliser une identité qui leur appartient. Cette différence compte pour l’alignement DMARC. Suivez les instructions du prestataire concernant les clés et les enregistrements, puis vérifiez un message réellement envoyé.

Une rotation des clés doit être planifiée. Supprimer immédiatement une ancienne clé peut affecter des messages encore en circulation selon leur traitement. Les conditions exactes relèvent du service concerné : utilisez sa procédure plutôt qu’un calendrier inventé.

Si une signature échoue, examinez les transformations du message et la configuration. Une modification de certaines parties après signature peut expliquer le résultat. La présence d’un enregistrement DNS ne prouve pas que chaque message utilise correctement la clé publiée.

DMARC : relier le domaine visible aux authentifications

DMARC s’appuie sur SPF et DKIM, avec une exigence d’alignement avec le domaine visible dans From. Pour réussir, un chemin conforme peut reposer sur SPF aligné ou sur DKIM aligné ; il n’est pas nécessaire que les deux chemins réussissent simultanément dans tous les cas.

La politique publiée exprime une demande de traitement pour les messages qui échouent à DMARC. Les valeurs courantes comprennent l’observation, la mise en quarantaine et le rejet. Le destinataire conserve son propre traitement ; cette déclaration ne constitue pas une commande universelle imposant la même décision partout.

Les rapports agrégés peuvent aider à comprendre quelles sources utilisent votre domaine et quels résultats elles obtiennent. Ils demandent une analyse : une adresse IP inconnue peut être un prestataire oublié, un transfert ou une source illégitime. Le rapport ne remplace pas l’inventaire métier.

Une politique d’observation ne bloque pas à elle seule l’usurpation. Elle peut servir à préparer une configuration plus restrictive, en identifiant les flux légitimes qui doivent être corrigés. Passer directement au rejet sans ce travail peut interrompre vos propres messages.

En mai 2026, la RFC 9989 a remplacé les RFC 7489 et 9091 pour le protocole DMARC ; les rapports agrégés sont notamment décrits dans la RFC 9990. Pour une nouvelle configuration, utilisez une documentation actuelle et vérifiez les possibilités effectivement déployées par vos prestataires, plutôt que copier un ancien exemple sans contrôle.

Construire l’inventaire des expéditeurs

Listez la messagerie principale, la boutique, le CRM, les formulaires du site, la facturation, les outils de support et les campagnes. Pour chaque service, relevez le domaine visible utilisé, l’identité d’enveloppe prévue et les possibilités de signature avec votre domaine.

Identifiez une personne responsable de chaque flux. Lorsqu’un nouveau logiciel apparaît, son envoi doit être ajouté à la procédure de validation. Sinon, la configuration DNS devient une accumulation historique que personne ne sait expliquer.

Préparez un tableau avec le type de message, son destinataire de test, le résultat SPF, le résultat DKIM et le résultat DMARC. Un test sur un seul message n’est pas une certification complète, mais il fournit une base concrète pour repérer une erreur.

Vérifiez également les formulaires du site. Utiliser l’adresse du visiteur comme expéditeur visible peut poser des difficultés d’authentification. Une organisation prévue par votre prestataire, avec une adresse contrôlée et un champ de réponse adapté, peut éviter ce problème. Faites valider la configuration exacte avant modification.

Pour protéger les utilisateurs contre les fausses pages et messages, le dossier sur les risques de phishing rappelle que l’authentification d’un domaine ne dispense pas d’examiner la demande reçue et son contexte.

Pourquoi un message authentifié peut encore finir en spam

Les destinataires évaluent aussi la réputation, les plaintes, les comportements d’envoi et le contenu selon leurs règles. SPF, DKIM et DMARC répondent à une partie du problème. Ils ne transforment pas une liste mal constituée en audience intéressée.

La documentation Gmail distingue les exigences applicables aux expéditeurs et celles de certains envois en nombre vers ses comptes personnels. Ces règles ne doivent pas être présentées comme une règle identique de tous les fournisseurs. Vérifiez les consignes des destinataires qui représentent une part importante de votre activité.

Examinez les désinscriptions et les plaintes sur les flux commerciaux. Le fait qu’une adresse fonctionne techniquement ne prouve pas que la personne souhaite recevoir votre campagne. Une hausse brutale de volume ou une liste ancienne peut compliquer la délivrabilité.

Les rebonds apportent des informations, mais leur sens varie. Une adresse inexistante, un refus temporaire et un problème d’authentification ne doivent pas être regroupés dans une seule catégorie. Conservez le code et le message de retour, puis utilisez la documentation du prestataire pour les interpréter.

Ne réenvoyez pas indéfiniment un même message refusé. Une logique de reprise doit être adaptée à la nature du défaut. Si la configuration est incorrecte, il faut corriger la cause avant de multiplier les tentatives.

Tester sans se laisser tromper par un score

Un outil de contrôle peut analyser votre DNS et un email de test. Son résultat constitue une observation, pas une garantie commerciale. Il peut repérer une politique absente ou un défaut de signature sans reproduire la décision de chaque destinataire.

Réalisez des essais représentatifs : message transactionnel, réponse du support et campagne selon les flux réellement utilisés. Comparez les en-têtes et les retours. Si seul un outil échoue, concentrez l’analyse sur son identité et sa configuration.

Notez la date des modifications. Les enregistrements DNS ont des durées de cache ; tous les contrôles ne reflètent pas immédiatement le changement. La procédure doit laisser le temps prévu et distinguer l’ancienne observation de la nouvelle.

N’envoyez pas des tests en masse à des adresses aléatoires. Utilisez des destinataires de contrôle autorisés. Pour un problème touchant un client, demandez les informations utiles de manière appropriée, sans lui imposer de transmettre des données personnelles sans nécessité.

Un diagnostic robuste réunit trois preuves : configuration publiée, message effectivement signé ou autorisé, puis résultat observé chez le destinataire. Un seul de ces étages ne raconte pas tout le fonctionnement.

Durcir la politique sans casser les flux

Après l’inventaire, corrigez les sources légitimes qui n’obtiennent pas l’alignement attendu. Testez-les individuellement. Analysez ensuite les rapports disponibles pour vérifier qu’un flux important n’a pas été oublié.

Le passage à une politique plus restrictive doit suivre un plan adapté au domaine et au volume. Définissez la personne qui peut revenir au réglage précédent, les observations attendues et les flux à surveiller. Une modification un vendredi soir sans responsable disponible peut créer une interruption difficile à traiter.

Conservez une procédure de création de nouveaux expéditeurs. Elle doit vérifier les domaines, les signatures, les tests et les responsables. La délivrabilité se dégrade souvent par accumulation d’outils dont les réglages ne sont jamais revus.

Pour une organisation utilisant plusieurs sous-domaines, documentez les politiques et leurs interactions. Ne supposez pas qu’un réglage copié d’un domaine à l’autre produira exactement le même résultat. La configuration doit être examinée dans son contexte.

Les informations à transmettre à votre prestataire

Décrivez le flux concerné, le domaine d’envoi, l’heure du test, le destinataire et le message de retour. Fournissez les en-têtes selon un canal approprié et protégez les informations personnelles. Indiquez les changements récents de plateforme ou de DNS.

Demandez une réponse précise : l’échec concerne-t-il l’authentification, l’alignement, la réputation ou une autre règle du destinataire ? Quelles observations soutiennent ce diagnostic ? Quelle modification est proposée et comment sera-t-elle contrôlée ?

Une réponse « changez l’objet » ne suffit pas si le message est refusé pour une configuration d’authentification. À l’inverse, ajouter une signature ne règle pas automatiquement un problème de plaintes. La solution doit correspondre à la cause identifiée.

Une bonne délivrabilité se construit sur une identité cohérente, des envois attendus et une surveillance régulière. SPF, DKIM et DMARC forment une base technique importante. Leur valeur apparaît lorsqu’ils sont correctement utilisés par tous les flux, avec un inventaire et des tests, plutôt qu’une série de lignes DNS laissées sans suivi.

Prévoir le départ d’un outil d’envoi

Lorsqu’un service n’est plus utilisé, vérifiez qu’aucun flux rare ne dépend encore de lui avant de retirer ses autorisations. Une notification annuelle ou un rappel administratif peut échapper aux essais réalisés sur une semaine. Contactez le responsable du flux, contrôlez les dernières utilisations disponibles, puis planifiez le retrait. Conservez le nom de l’outil supprimé et la date de l’opération dans le journal de configuration.

Cette revue est également l’occasion de limiter les comptes capables de modifier le domaine. Une personne qui ne gère que le contenu d’une campagne n’a pas nécessairement besoin d’un accès complet au DNS. Séparer les rôles réduit les erreurs et facilite l’analyse si une modification inattendue apparaît. Enfin, rappelez à l’équipe qu’un message passant les contrôles d’authentification peut toujours contenir une demande trompeuse issue d’un compte légitime compromis : la cohérence du contexte reste importante pour les actions sensibles.