Qu'est-ce que SPF ?

SPF (Sender Policy Framework) est un enregistrement DNS qui indique quels serveurs de messagerie sont autorisés à envoyer des courriels au nom de votre domaine. Lorsqu'un serveur de messagerie destinataire reçoit un message prétendant provenir de [email protected], il consulte l'enregistrement SPF de votre domaine pour vérifier si l'adresse IP du serveur expéditeur figure sur la liste approuvée. Sinon, le message risque davantage d'être marqué comme pourriel ou rejeté.

SPF est publié sous forme d'enregistrement TXT à la racine de votre domaine. Un enregistrement SPF typique pour Google Workspace ressemble à : v=spf1 include:_spf.google.com ~all.

Qu'est-ce que DKIM ?

DKIM (DomainKeys Identified Mail) est une méthode d'authentification du courriel qui signe cryptographiquement vos messages sortants afin que les destinataires puissent vérifier qu'ils n'ont pas été altérés en transit. Votre fournisseur de messagerie génère une paire de clés publique/privée — la clé privée signe les courriels sortants, et la clé publique est publiée dans votre DNS sous forme d'enregistrement TXT à un sous-domaine de sélecteur précis comme google._domainkey.votredomaine.com.

Les serveurs destinataires récupèrent la clé publique, vérifient la signature et utilisent le résultat comme l'un des signaux indiquant si le message est légitime. DKIM fonctionne de pair avec SPF et DMARC pour une authentification complète du courriel.

Qu'est-ce que DMARC ?

DMARC (Domain-based Message Authentication, Reporting and Conformance) est une politique DNS qui indique aux serveurs de messagerie destinataires quoi faire lorsqu'un courriel échoue à l'authentification SPF ou DKIM — et où envoyer les rapports sur les échecs d'authentification. Elle s'appuie sur SPF et DKIM plutôt que de les remplacer.

Un enregistrement DMARC de base ressemble à : v=DMARC1; p=none; rua=mailto:[email protected]. La politique (p=) peut être none (surveillance seulement), quarantine (envoyer le courrier suspect aux pourriels) ou reject (bloquer complètement).

Quelle est la différence entre SPF, DKIM et DMARC ?

SPF indique quels serveurs peuvent envoyer du courrier pour votre domaine, DKIM prouve cryptographiquement qu'un message n'a pas été modifié, et DMARC indique aux destinataires quoi faire lorsque les vérifications SPF ou DKIM échouent et demande des rapports.

Voyez-le ainsi :

• SPF = la liste d'invités. « Ces serveurs sont autorisés à envoyer du courrier depuis mon domaine. »
• DKIM = le sceau inviolable. « Ce message est arrivé exactement comme je l'ai envoyé. »
• DMARC = le règlement et la vérification. « Si la liste d'invités ou le sceau échoue, voici quoi faire — et envoyez-moi un rapport. »

Les trois sont des enregistrements DNS. Ensemble, ils forment la pile moderne d'authentification du courriel et sont exigés par les grands fournisseurs comme Google et Yahoo pour les expéditeurs de masse.

Pourquoi mes courriels aboutissent-ils dans les pourriels ?

La cause la plus fréquente est une authentification du courriel manquante ou mal configurée — précisément SPF, DKIM ou DMARC. Les serveurs de messagerie destinataires (Gmail, Outlook, etc.) attribuent un pointage à chaque message et acheminent ceux ayant un faible pointage vers le dossier des pourriels. Une authentification manquante, des domaines d'expéditeur incohérents, une faible réputation ou un contenu de type pourriel font tous baisser le pointage.

Pour diagnostiquer, vérifiez votre domaine avec un outil comme le vérificateur gratuit de MXHelper. Vous verrez généralement un ou plusieurs de ces problèmes :

• Aucun enregistrement SPF — les serveurs destinataires ne peuvent pas vérifier vos serveurs d'envoi
• Aucune signature DKIM — les messages ne sont pas signés cryptographiquement
• Aucune politique DMARC — votre domaine est vulnérable à l'usurpation
• Envoi depuis un serveur absent de votre enregistrement SPF

Corrigez d'abord l'authentification, puis examinez le contenu (aucune expression de type pourriel, un ratio texte/liens équilibré, une version en texte brut incluse).

Comment vérifier l'authentification du courriel de mon domaine ?

Utilisez un outil gratuit de recherche DNS qui interroge vos enregistrements SPF, DKIM et DMARC. MXHelper le fait en un clic — saisissez votre domaine et il vérifie les trois mécanismes d'authentification ainsi que les enregistrements MX, avec des explications en langage clair des problèmes détectés.

Vous pouvez aussi vérifier manuellement avec dig ou nslookup :

• SPF : dig TXT votredomaine.com
• DMARC : dig TXT _dmarc.votredomaine.com
• DKIM : dig TXT <sélecteur>._domainkey.votredomaine.com (le sélecteur varie selon le fournisseur)

Pourquoi mon enregistrement SPF échoue-t-il ?

Les quatre raisons les plus courantes d'un échec SPF sont :

• Plusieurs enregistrements SPF sur le même domaine — un seul est permis. Fusionnez-les en un seul enregistrement avec plusieurs mécanismes include:.
• Plus de 10 requêtes DNS — SPF impose une limite stricte. Chaque include:, a, mx, etc. compte. La dépasser provoque une erreur permanente (permerror).
• Envoi depuis un serveur absent de l'enregistrement — cela arrive généralement en ajoutant de nouveaux services de courriel transactionnel (Mailchimp, SendGrid, etc.) sans mettre à jour le SPF.
• Erreurs de syntaxe — préfixe v=spf1 manquant, fautes de frappe dans les includes ou enregistrements mal entre guillemets.

Qu'est-ce que la limite de 10 requêtes SPF ?

Les enregistrements SPF sont limités à 10 requêtes DNS lors de l'évaluation ; dépasser la limite fait échouer toute la vérification SPF avec une « permerror ». Chaque mécanisme include:, a, mx, ptr et exists: de votre enregistrement compte comme une requête, et les mécanismes include: imbriqués comptent de façon cumulative.

Si vous atteignez cette limite, les options comprennent : supprimer les includes inutilisés, utiliser des services d'aplatissement SPF (qui développent les includes en plages d'adresses IP au prix d'un fardeau d'entretien) ou regrouper les services d'envoi.

Comment configurer DMARC ?

Ajoutez un enregistrement TXT au sous-domaine _dmarc de votre domaine, avec une valeur comme v=DMARC1; p=none; rua=mailto:[email protected].

Étape par étape :

• Connectez-vous à votre fournisseur DNS (Cloudflare, GoDaddy, Namecheap, etc.)
• Ajoutez un nouvel enregistrement TXT
• Hôte/Nom : _dmarc (la plupart des fournisseurs ajoutent automatiquement le domaine)
• Valeur : v=DMARC1; p=none; rua=mailto:[email protected]
• Enregistrez et attendez la propagation DNS (généralement moins d'une heure)

Commencez par p=none pour la surveillance seulement. Après avoir examiné les rapports pendant 2 à 4 semaines, resserrez vers p=quarantine ou p=reject. MXHelper générera l'enregistrement exact pour vous à partir d'un court formulaire.

Quelle est la différence entre p=none, p=quarantine et p=reject ?

Ces trois politiques DMARC indiquent aux serveurs de messagerie destinataires comment traiter les messages qui échouent à l'authentification.

• p=none — surveillance seulement. Les destinataires signalent les échecs mais n'agissent pas. À utiliser lors du premier déploiement de DMARC.
• p=quarantine — les messages en échec vont au dossier des pourriels. À utiliser une fois que vous avez examiné les rapports et corrigé les expéditeurs légitimes.
• p=reject — les messages en échec sont bloqués complètement. La plus forte protection contre l'usurpation ; à n'utiliser que lorsque vous êtes certain que toutes vos sources d'envoi légitimes réussissent l'authentification.

La plupart des domaines progressent de none → quarantine → reject sur des semaines ou des mois, à mesure que la confiance s'installe.

Que signifient ~all et -all dans SPF ?

~all est un « échec souple » — les destinataires devraient accepter le message mais le marquer comme suspect. -all est un « échec strict » — les destinataires devraient rejeter le message complètement.

La plupart des domaines devraient commencer avec ~all le temps d'acquérir la certitude que tous les expéditeurs légitimes figurent dans l'enregistrement. Une fois certain, passer à -all offre une meilleure protection contre l'usurpation. Il existe aussi ?all (neutre, aucune opinion) et +all (autoriser n'importe quoi, à ne jamais utiliser).

Qu'est-ce qu'un sélecteur DKIM ?

Un sélecteur DKIM est une étiquette qui indique quelle clé publique DKIM utiliser, ce qui permet à un domaine de publier plusieurs clés DKIM en même temps. L'emplacement DNS complet d'un enregistrement DKIM est <sélecteur>._domainkey.<domaine>, par exemple google._domainkey.exemple.com.

Les fournisseurs de messagerie utilisent des sélecteurs différents :

• Google Workspace : google
• Microsoft 365 : selector1 et selector2
• Zoho : configurable, souvent zoho
• Mailgun, SendGrid, etc. : chacun génère le sien

Plusieurs sélecteurs permettent de signer le courrier de plusieurs services d'envoi sans conflit.

Puis-je avoir plusieurs enregistrements SPF sur un domaine ?

Non. Le RFC 7208 interdit explicitement d'avoir plus d'un enregistrement SPF par domaine, et la plupart des serveurs destinataires traitent les enregistrements multiples comme une permerror (faisant échouer toutes les vérifications SPF).

Si vous devez autoriser plusieurs services d'envoi, regroupez-les dans un seul enregistrement SPF à l'aide de plusieurs mécanismes include:, par exemple : v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all.

Ai-je besoin des trois : SPF, DKIM et DMARC ?

Oui, pour une délivrabilité sérieuse du courriel, vous devriez publier les trois. Chacun protège contre différentes attaques :

• SPF protège contre les serveurs non autorisés qui envoient au nom de votre domaine
• DKIM protège contre la modification des messages en transit
• DMARC les relie avec une politique d'application et des rapports

Depuis 2024, Google et Yahoo exigent les trois pour les expéditeurs qui livrent plus de 5 000 messages par jour à leurs utilisateurs. Même pour les domaines à faible volume, avoir les trois améliore nettement la délivrabilité et protège contre l'usurpation.

Qu'est-ce qu'un enregistrement MX ?

Un enregistrement MX (Mail Exchanger) est une entrée DNS qui indique à Internet quels serveurs de messagerie sont responsables de la réception du courriel pour votre domaine. Lorsqu'une personne envoie un message à [email protected], son serveur interroge vos enregistrements MX pour savoir où le livrer.

Les enregistrements MX ont une valeur de priorité — les nombres plus bas sont préférés. Par exemple, Google Workspace utilise des enregistrements MX comme 1 aspmx.l.google.com, 5 alt1.aspmx.l.google.com, et ainsi de suite. Le serveur de messagerie principal est essayé en premier ; les serveurs de secours ne le sont que si le principal est injoignable.

Combien de temps prend la propagation DNS ?

Les changements DNS se propagent généralement en 15 minutes à quelques heures, bien que le maximum technique soit déterminé par la valeur TTL (durée de vie) de votre enregistrement.

En pratique :

• La plupart des fournisseurs DNS modernes (Cloudflare, AWS Route 53, Google Cloud DNS) propagent les changements en moins de 5 minutes
• Les registraires plus anciens avec des TTL plus longs (1 heure, 24 heures) prennent plus de temps
• Les caches DNS du navigateur et du système d'exploitation peuvent conserver d'anciennes valeurs pendant quelques heures, peu importe le TTL
• Certains FAI et réseaux d'entreprise mettent le DNS en cache de façon plus agressive

Pour forcer un test, utilisez un résolveur DNS public comme dig @1.1.1.1 votredomaine.com afin de contourner les caches locaux.

MXHelper est-il gratuit ?

Oui, MXHelper est entièrement gratuit, sans inscription requise. Le site est financé par de la publicité discrète. Il n'y a aucune offre premium ni mur payant — chaque fonctionnalité est offerte à chaque visiteur.

MXHelper conserve-t-il les domaines que je vérifie ?

Non. Nous n'enregistrons les noms de domaine que vous vérifiez dans aucune base de données. Les requêtes peuvent apparaître brièvement dans les journaux d'accès standard du serveur web (ce qui est vrai de tout site web) et sont automatiquement supprimées après 30 jours. Nous les utilisons uniquement pour l'analyse globale du trafic et le diagnostic de sécurité. Consultez notre politique de confidentialité pour tous les détails.