Vos courriels tombent dans les indésirables : SPF, DKIM et DMARC expliqués une fois pour toutes

Une soumission de 30 000 $ envoyée un mardi matin. Le client ne répond pas. Trois jours plus tard, au téléphone, il la retrouve dans ses indésirables. Personne n'a rien cassé, aucun message d'erreur n'est revenu, votre logiciel affiche « envoyé » avec une coche verte. C'est le mode d'échec le plus coûteux de toute l'infrastructure d'une PME : silencieux des deux côtés.

Presque toujours, la cause est la même. Le serveur qui a reçu votre message a posé trois questions à votre domaine, et votre domaine a mal répondu à au moins une des trois. Les réponses vivent dans votre DNS, sous forme de trois enregistrements : SPF, DKIM et DMARC. On a déjà couvert leur existence en montant une adresse courriel à votre nom de domaine. Ici, on va plus loin, parce que c'est là que ça casse.

Vous trouverez ici ce que chaque enregistrement fait réellement, la raison pour laquelle la plupart des PME s'arrêtent à mi-chemin sans le savoir, et ce que vous pouvez vérifier vous-même cet après-midi. Les lignes à copier-coller, elles, sont déjà partout sur le web, et c'est bien le problème.

La réponse courte, pour les pressés

SPF, DKIM et DMARC sont trois enregistrements DNS qui répondent à trois questions du serveur qui reçoit votre courriel : quels serveurs ont le droit d'envoyer pour ce domaine (SPF), le message a-t-il été modifié en route (DKIM), et que faire quand la réponse ne concorde pas avec le nom affiché dans le champ expéditeur (DMARC). Les deux premiers n'authentifient pas le nom que votre client voit : c'est DMARC qui fait le lien, et c'est lui que presque personne ne termine. Publier p=none, la valeur de départ, ne demande rien au serveur de réception ; la norme IETF de mai 2026 (RFC 9989) la définit comme l'absence de préférence exprimée par le propriétaire du domaine. La protection commence à p=quarantine, puis à p=reject. Depuis le 1er février 2024, Gmail exige de tout expéditeur au minimum SPF ou DKIM, et les trois au-delà de 5 000 messages par jour.

Trois questions, dans l'ordre

Le serveur qui reçoit votre courriel ne vous connaît pas. Il connaît une adresse IP qui se connecte, une enveloppe SMTP, un en-tête From affiché à l'écran, et votre DNS, qu'il peut interroger. Avec ça, il décide en quelques millisecondes s'il livre, s'il classe en indésirable ou s'il refuse.

Première question : est-ce que cette machine a le droit d'envoyer pour ce domaine ? SPF est votre réponse publiée, une ligne de texte dans votre DNS qui commence par v=spf1 et énumère les serveurs autorisés. Pour une PME qui envoie uniquement par Google Workspace, Google publie l'exemple minimal : v=spf1 include:_spf.google.com ~all. Le ~all final dit au serveur de réception de marquer comme suspect ce qui vient d'ailleurs, et c'est la terminaison que Google recommande.

Deuxième question : est-ce que ce message est bien celui qui a été signé au départ ? DKIM est une paire de clés. La privée reste sur votre serveur d'envoi et appose une signature dans l'en-tête de chaque message ; la publique est publiée dans votre DNS et sert au serveur de réception à vérifier cette signature. Si un caractère du message a changé en route, la vérification échoue. Google exige une clé d'au moins 1024 bits pour livrer à un compte Gmail personnel et recommande 2048 quand le fournisseur DNS le prend en charge.

Troisième question : et si ça ne concorde pas ? DMARC est la seule des trois qui vous permet de répondre. Sans lui, chaque serveur de réception improvise selon ses propres règles.

Pourquoi SPF et DKIM ne protègent pas votre nom

Voici le point que presque toutes les explications escamotent, et il est décisif. SPF vérifie l'adresse de l'enveloppe SMTP, celle de la commande MAIL FROM, invisible pour votre destinataire. DKIM vérifie le domaine qui a signé, indiqué par la balise d= dans la signature. Ni l'un ni l'autre ne regarde le nom affiché dans le champ From, le seul que votre client lit.

La norme le dit en toutes lettres : SPF et DKIM fournissent une authentification au niveau du domaine, mais ne sont pas directement associés au domaine du champ From. Un fraudeur peut donc envoyer un message parfaitement authentifié pour son domaine, tout en affichant le vôtre à l'écran. Les deux vérifications passent. Le message a l'air propre.

DMARC est ce qui referme la porte. Il exige l'alignement : le domaine qui a passé SPF ou DKIM doit correspondre à celui affiché dans le champ From. Un domaine sans DMARC a beau avoir SPF et DKIM impeccables, il ne demande jamais cette correspondance, et la fausse facture à votre nom passe.

Deuxième conséquence, moins connue : la redirection casse SPF, pas DKIM. Quand un de vos clients fait suivre son adresse d'association ou d'ancien employeur vers sa vraie boîte, le message arrive d'une IP qui n'est pas dans votre SPF, et SPF échoue. La signature DKIM, elle, survit généralement au relais. La norme en tire une règle explicite : un domaine qui publie p=reject ne doit pas se fier au seul SPF et doit signer ses messages en DKIM. Un SPF seul suffit à Gmail, mais il ne suffit pas à monter les échelons.

Rester à p=none pour toujours, l'erreur la plus répandue

Publier un enregistrement DMARC prend cinq minutes. C'est ce qui fait sa popularité et son inutilité. La quasi-totalité des PME publient v=DMARC1; p=none, cochent la case, et n'y retouchent jamais.

Or p=none ne protège rien, et ce n'est pas une interprétation. La RFC 9989, passée en mai 2026 du statut de spécification informative à celui de norme de l'IETF, définit les trois valeurs ainsi : none signifie que le propriétaire du domaine n'exprime aucune préférence, quarantine qu'il considère ces messages comme suspects, reject qu'il y voit une utilisation clairement invalide de son nom. Vous n'avez donc pas trois niveaux de sévérité, vous en avez deux, précédés d'un mode observation.

Ce mode observation a une vraie fonction, mais elle est temporaire. En none, avec une balise rua pointant vers une boîte dédiée, vous recevez des rapports quotidiens qui listent tout ce qui envoie en affichant votre domaine, y compris les services que vous aviez oubliés. Google recommande une semaine de lecture de ces rapports avant de passer à quarantine sur un petit pourcentage. La norme est plus prudente pour un domaine dont les employés écrivent à des listes de diffusion : un mois en none, puis un mois en quarantine, en comparant les résultats avant d'aller plus loin.

Un détail à connaître si vous suivez de vieux tutoriels : la balise pct, qui servait à n'appliquer la politique qu'à un pourcentage des messages, a été retirée par la RFC 9989 et versée aux archives. Google la documente et la recommande encore pendant le déploiement. Les deux positions coexistent, et les serveurs qui l'appliquent encore la respectent, mais c'est une pièce en voie de disparition sur laquelle il ne faut pas bâtir sa stratégie.

Le vrai obstacle : tout ce qui envoie en votre nom

Si vous restez bloqué en none, ce n'est presque jamais par paresse. C'est parce que monter d'un cran ferait tomber du courrier légitime, et que personne ne sait exactement lequel.

Faites l'inventaire : votre suite courriel, le formulaire de contact de votre site, votre logiciel de facturation, votre système de prise de rendez-vous, votre plateforme d'infolettre, votre CRM, votre outil de signature électronique, votre boutique en ligne. Chacun envoie en affichant votre domaine. Chacun doit donc être autorisé dans votre SPF et signer en DKIM avec votre domaine, sinon il échoue à DMARC et se fait mettre en quarantaine le jour où vous montez la politique.

Deux limites cassent cet inventaire en silence. Un domaine ne peut avoir qu'un seul enregistrement SPF applicable ; si le serveur en trouve deux, la vérification retourne une erreur permanente et vos deux configurations tombent ensemble. Et un enregistrement SPF ne peut déclencher plus de dix requêtes DNS pendant son évaluation. Les directives include, a, mx, ptr, exists et redirect comptent, y compris celles imbriquées chez vos fournisseurs, dont vous ne voyez pas le contenu. Dépassement : erreur permanente, tout le SPF est mort. Vous branchez un septième outil, votre interface ne signale rien, et votre courriel commence à tomber.

C'est pour ça que l'ordre compte. On ne monte pas la politique DMARC d'abord. On lit les rapports, on autorise chaque expéditeur légitime un par un, on vérifie qu'il ne reste rien d'inexpliqué, et seulement ensuite on serre la vis.

Ce que DMARC ne fera pas pour vous

Une politique p=reject protège votre nom de domaine exact. Elle ne protège pas votre marque, et la norme est franche là-dessus : les attaques par nom d'affichage et les domaines visuellement similaires sont hors de son champ.

Concrètement, un fraudeur qui enregistre votre-entreprise.net au lieu de votre-entreprise.ca, ou qui met simplement « Comptabilité Votre Entreprise » comme nom d'affichage devant une adresse Gmail quelconque, passe à travers votre DMARC sans le toucher. Vous avez fermé une porte, une seule, et c'est la plus utilisée. Il en reste d'autres, qui relèvent de la surveillance des domaines proches et de la formation de vos employés, pas du DNS.

Vérifier vous-même, en dix minutes

Vous n'avez besoin de rien acheter pour savoir où vous en êtes. L'outil Check MX de la boîte à outils d'administration de Google prend un nom de domaine et retourne les problèmes critiques, l'absence de DKIM ou de DMARC, et les plages d'adresses IP effectivement autorisées par votre SPF, directives include résolues. Un piège à connaître : pour vérifier DKIM, il faut lui fournir votre sélecteur, le préfixe de l'enregistrement, qui est google par défaut chez Workspace. Sans lui, l'outil rapporte une absence de DKIM sur un domaine qui en a un.

Envoyez ensuite un message à une adresse Gmail que vous contrôlez et ouvrez l'original du message. La ligne Authentication-Results donne les trois verdicts d'un coup.

Enfin, si votre DMARC n'a pas de balise rua, ajoutez-la aujourd'hui vers une boîte dédiée. Les rapports arrivent en XML compressé, illisibles à l'œil, et plusieurs services gratuits les affichent en clair. C'est le seul moyen de savoir qui envoie en votre nom en ce moment, et on y découvre presque toujours au moins un outil que personne dans l'entreprise ne savait encore actif.

Ce qu'il faut retenir

Les trois enregistrements ne sont pas trois cases à cocher d'importance égale. SPF et DKIM sont des prérequis techniques : ils authentifient une machine et un message, pas votre nom. DMARC est le seul qui protège l'identité que vos clients voient, et il ne commence à protéger quoi que ce soit qu'à partir de quarantine.

Le travail n'est pas de publier les enregistrements, ça se fait dans l'après-midi. Le travail, c'est de connaître tous les outils qui envoient en votre nom, de les autoriser proprement, puis de monter la politique en surveillant les rapports. C'est le même genre de maintenance discrète que la sécurité de votre site : rien ne clignote quand elle manque, jusqu'au jour où une soumission n'arrive pas.

→ Faites vérifier votre configuration courriel dans un audit