Tester le SPF, le DKIM et le DMARC de votre domaine
Tester le SPF, le DKIM et le DMARC de votre domaine prend moins d’une minute et explique la plupart des messages professionnels qui finissent dans les indésirables. Ces trois enregistrements servent à prouver qu’un e-mail parti de votre domaine vient réellement de vous. Quand ils manquent ou se contredisent, Gmail, Outlook et Yahoo prennent la décision la plus prudente : ils écartent le message.
Gratuit, sans inscription, résultat en moins d’une minute.
Ce qui se passe entre votre clic sur Envoyer et la boîte du destinataire
Quand votre serveur remet un message au serveur de votre client, rien dans le protocole d’origine n’empêche l’expéditeur d’écrire ce qu’il veut dans le champ From. N’importe qui, depuis n’importe quel serveur du monde, peut expédier un message affichant [email protected].
Les fournisseurs ont donc ajouté trois contrôles, publiés dans le DNS de votre domaine — le même annuaire public qui indique où trouver votre site.
- SPF : la liste des serveurs autorisés à expédier pour vous.
- DKIM : une signature cryptographique posée sur chaque message.
- DMARC : la consigne à appliquer quand un des deux contrôles échoue.
Un serveur destinataire consulte les trois en quelques millisecondes, avant même de regarder le contenu : une facture parfaitement rédigée mais non authentifiée passe derrière une publicité correctement signée.
SPF : qui a le droit d’écrire en votre nom
Le serveur qui reçoit votre message demande à votre domaine s’il vous autorise à écrire en son nom ; c’est précisément le rôle du SPF. La réponse est un enregistrement TXT publié à la racine du domaine, du type v=spf1 include:_spf.google.com include:mail.monhebergeur.cm -all.
Chaque include ajoute un service autorisé : votre hébergeur, votre suite bureautique, votre plateforme d’envoi de newsletters, votre logiciel de facturation. La fin de la ligne compte autant que le reste.
-all: tout serveur non listé est rejeté. C’est le réglage visé une fois la liste complète.~all: échec doux, le message est accepté mais marqué suspect. Utile pendant la mise en place.+all: tout le monde est autorisé, ce qui revient à ne pas avoir de SPF du tout.
Deux pièges reviennent sans cesse. Le premier : publier deux enregistrements SPF sur le même domaine, ce qui les invalide tous les deux. Le second : dépasser dix résolutions DNS, limite fixée par la norme, en empilant les include — au-delà, le contrôle échoue même quand l’expéditeur est légitime.
DKIM : la signature qui voyage avec le message
Le SPF valide un serveur, jamais un contenu. Le DKIM comble ce trou. Au départ, votre serveur calcule une empreinte du message et la chiffre avec une clé privée. Le destinataire récupère la clé publique correspondante dans votre DNS, à une adresse du type google._domainkey.votre-domaine.cm, et vérifie que l’empreinte correspond.
Deux conséquences concrètes : un message modifié en cours de route perd sa signature, et celle-ci survit aux transferts — un message relayé par une liste de diffusion peut casser le SPF tout en gardant un DKIM valide.
Le mot google dans l’exemple s’appelle le sélecteur. Chaque service en utilise un qui lui est propre, ce qui permet de signer depuis plusieurs plateformes sans conflit. L’outil interroge les sélecteurs les plus répandus — Google Workspace, Microsoft 365, cPanel, Zoho, SendGrid, entre autres — et vous indique ceux qui répondent.
DMARC : la consigne que vous donnez aux serveurs destinataires
SPF et DKIM produisent un verdict, mais ne disent pas quoi en faire. C’est le rôle du DMARC, publié sur _dmarc.votre-domaine.cm, par exemple v=DMARC1; p=none; rua=mailto:[email protected]. La valeur de p est la seule décision vraiment structurante.
| Politique | Effet sur un message non authentifié | Quand l’adopter |
|---|---|---|
p=none | Aucun ; vous recevez seulement des rapports. | Les premières semaines, pour observer. |
p=quarantine | Le message part dans les indésirables. | Quand tous vos envois légitimes sont conformes. |
p=reject | Le message est refusé avant livraison. | Objectif final, une fois les rapports propres. |
Le DMARC ajoute une exigence que beaucoup découvrent tard : l’alignement. Le domaine visible par le destinataire doit correspondre au domaine validé par le SPF ou par la signature DKIM. Un formulaire de contact qui expédie depuis le serveur de votre site en affichant l’adresse du visiteur passe le SPF et échoue au DMARC : la mécanique est correcte, l’identité ne l’est pas.
Passer directement à p=reject risque de bloquer vos propres factures ; rester à p=none pendant des années ne protège de rien.
Tester SPF, DKIM et DMARC en une seule opération
Entrez votre nom de domaine sur la page d’analyse gratuite : le diagnostic interroge le DNS public, sans toucher à votre zone ni demander le moindre mot de passe. Vous obtenez en clair :
- le contenu exact de votre enregistrement SPF, le nombre de résolutions consommées et le mode de fin de ligne ;
- la liste des sélecteurs DKIM trouvés, avec la taille de chaque clé ;
- votre politique DMARC, l’adresse de réception des rapports et les règles d’alignement ;
Un e-mail correctement authentifié qui part malgré tout en spam signale souvent un problème de réputation d’adresse IP : la page vérifier si une IP est sur liste noire traite ce cas précis.
Ce que nous constatons sur les domaines camerounais
Sur les domaines d’entreprises basées à Yaoundé et à Douala, quatre situations reviennent presque toujours.
- Une messagerie hébergée chez Google ou Microsoft, mais un SPF resté celui de l’ancien hébergeur : les messages partent d’un serveur que le domaine ne reconnaît plus.
- Un site WordPress qui envoie les notifications de commande depuis le serveur web, sans être déclaré dans le SPF.
- Aucun DKIM, parce que l’activation se fait dans la console d’administration et non chez le registrar, étape que personne ne pense à franchir.
- Un DMARC posé en
p=noneil y a trois ans, avec une adresse de rapports que plus personne ne relève.
Ces corrections se font dans la zone DNS, en quelques minutes, et produisent un effet visible sous 24 à 48 heures. Si votre zone est éclatée entre plusieurs prestataires, commencez par le diagnostic DNS de votre domaine pour savoir quels serveurs de noms font autorité. Et si personne en interne ne veut prendre la main, un hébergeur basé au Cameroun les met en place avec vous, dans votre fuseau horaire et dans votre langue.
Questions fréquentes
Pourquoi mes e-mails arrivent-ils en spam alors que mon site fonctionne ?
Le site et la messagerie sont deux services distincts, même sous le même nom de domaine. Un site parfaitement accessible peut cohabiter avec une messagerie sans SPF ni DKIM. Les filtres anti-spam ne regardent pas votre site : ils vérifient l’authentification du message, la réputation du serveur expéditeur et la cohérence entre l’adresse affichée et le serveur réel. Corrigez ces trois points et la délivrabilité remonte sans toucher au site.
Combien de temps faut-il pour qu’une correction SPF prenne effet ?
Une modification d’enregistrement TXT se propage en fonction de la durée de vie déclarée dans la zone, généralement entre une et vingt-quatre heures. Les serveurs qui avaient déjà consulté votre ancien enregistrement gardent la réponse en mémoire jusqu’à expiration de ce délai. Pour aller plus vite, abaissez la durée de vie à trois cents secondes la veille de l’intervention, puis remettez-la à sa valeur normale une fois le changement vérifié.
Puis-je avoir deux enregistrements SPF si j’utilise deux services d’envoi ?
Non. La norme n’autorise qu’un seul enregistrement SPF par domaine ; deux lignes rendent le contrôle invalide et vos messages perdent leur authentification. Il faut fusionner les deux en une ligne unique en additionnant les mécanismes include, puis vérifier que le total reste sous la limite de dix résolutions DNS. Un test après fusion confirme que la ligne est bien lue.
Le DKIM est-il vraiment nécessaire si le SPF est correct ?
Oui, pour deux raisons. Le SPF échoue dès qu’un message est transféré ou relayé, alors que la signature DKIM survit à ces trajets. Surtout, le DMARC exige qu’au moins un des deux contrôles soit à la fois valide et aligné avec votre domaine : sans DKIM, vous dépendez entièrement du SPF, donc du chemin qu’emprunte le message. Les deux ensemble rendent votre authentification stable.
Que faire des rapports DMARC que je reçois ?
Ce sont des fichiers XML compressés, envoyés chaque jour par les grands fournisseurs. Ils listent les adresses IP qui ont expédié en votre nom et le résultat des contrôles. Ouvrez-les avec un service de lecture gratuit : vous y repérez vos propres services oubliés — logiciel de facturation, boutique en ligne, prestataire de newsletters — et les tentatives d’usurpation. Une fois toutes vos sources reconnues, vous pouvez durcir la politique sans risque.
Ce test modifie-t-il quelque chose sur mon domaine ?
Non. L’analyse est en lecture seule : elle interroge des serveurs DNS publics et lit des informations que n’importe qui peut déjà consulter. Aucun accès à votre hébergement n’est demandé, aucun enregistrement n’est créé ni modifié, aucun e-mail n’est envoyé en votre nom. Vous repartez avec un état des lieux et la liste des corrections à effectuer chez votre hébergeur ou votre registrar.
Votre site mérite-t-il mieux que son hébergement actuel ?
CCN Technologies héberge et sécurise sites et messageries depuis Yaoundé : HTTP/2, en-têtes de sécurité posés par défaut, SSL automatique, isolation CloudLinux, sauvegardes quotidiennes et une équipe joignable dans votre fuseau horaire.