Un site professionnel bien sécurisé peut quand même voir ses emails finir en spam — ou pire, être usurpé par un tiers qui envoie des messages frauduleux « au nom de » votre domaine. La cause est presque toujours la même : l’absence ou la mauvaise configuration de trois enregistrements DNS que peu de sites ont réellement mis en place correctement : SPF, DKIM et DMARC.
Sommaire
- Sommaire
- Pourquoi vos emails arrivent en spam (ou n’arrivent pas)
- SPF : qui a le droit d’envoyer au nom de votre domaine
- DKIM : la signature qui prouve que le message n’a pas été modifié
- DMARC : la politique qui dit quoi faire en cas d’échec
- Les erreurs les plus fréquentes
- Ce que je mets en place
- Voir aussi
Sommaire
- Pourquoi vos emails arrivent en spam (ou n’arrivent pas)
- SPF : qui a le droit d’envoyer au nom de votre domaine
- DKIM : la signature qui prouve que le message n’a pas été modifié
- DMARC : la politique qui dit quoi faire en cas d’échec
- Les erreurs les plus fréquentes
- Ce que je mets en place
Pourquoi vos emails arrivent en spam (ou n’arrivent pas)
Gmail, Outlook et les autres grands fournisseurs de messagerie reçoivent des volumes massifs de tentatives de phishing et d’usurpation de domaine. Pour trier le légitime du frauduleux, ils vérifient systématiquement trois choses à la réception d’un email : le serveur émetteur est-il autorisé à envoyer pour ce domaine (SPF), le contenu a-t-il été altéré en chemin (DKIM), et que faire si l’un des deux échoue (DMARC). Sans ces enregistrements, vos emails transactionnels — confirmation de commande, réinitialisation de mot de passe, formulaire de contact — partent avec une présomption de suspicion, et un domaine sans DMARC est une cible facile pour l’usurpation.
SPF : qui a le droit d’envoyer au nom de votre domaine
Le SPF (Sender Policy Framework) est un enregistrement TXT qui liste les serveurs autorisés à envoyer des emails pour votre domaine — votre hébergeur, votre outil d’emailing, votre CRM. Un serveur qui n’est pas dans cette liste et qui tente d’envoyer « en votre nom » sera rejeté ou marqué comme suspect par le destinataire.
- Un seul enregistrement SPF par domaine — en ajouter un second ne l’additionne pas, ça casse la vérification
- Chaque service d’envoi doit y figurer — hébergement, plateforme e-commerce, outil de newsletter, CRM commercial
- Une limite de 10 lookups DNS à ne pas dépasser sous peine d’échec silencieux de la vérification
DKIM : la signature qui prouve que le message n’a pas été modifié
DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque email envoyé, vérifiable via une clé publique publiée dans votre DNS. Contrairement au SPF qui vérifie le serveur émetteur, DKIM vérifie l’intégrité du message lui-même : si le contenu a été altéré entre l’envoi et la réception, la signature ne correspond plus et l’email est signalé. C’est aussi ce qui permet à un message de rester valide même s’il transite par un serveur relais non listé dans le SPF.
DMARC : la politique qui dit quoi faire en cas d’échec
SPF et DKIM vérifient chacun un aspect du message, mais ni l’un ni l’autre ne dit au destinataire quoi faire en cas d’échec. C’est le rôle de DMARC : il définit une politique (ignorer, mettre en quarantaine, rejeter) et surtout il renvoie des rapports qui révèlent qui envoie des emails avec votre domaine — y compris les tentatives d’usurpation dont vous n’avez pas connaissance.
p=none— observation seule, aucun email n’est bloqué, utile en phase de mise en placep=quarantine— les emails suspects partent en spam plutôt qu’en boîte de réceptionp=reject— les emails qui échouent SPF et DKIM sont purement rejetés, la protection la plus stricte
Passer directement en p=reject sans être passé par none puis quarantine est le meilleur moyen de bloquer ses propres emails légitimes si la configuration SPF/DKIM n’est pas parfaite.
Les erreurs les plus fréquentes
- Aucun DMARC du tout — SPF et DKIM sont en place mais sans politique, le domaine reste usurpable
- Un service d’envoi oublié dans le SPF après l’ajout d’un nouvel outil marketing ou CRM
- Deux enregistrements SPF distincts laissés par deux prestataires différents, qui s’annulent
- Une clé DKIM jamais renouvelée après un changement de plateforme d’envoi
Ces trois enregistrements se configurent au niveau du DNS, au même endroit que les erreurs plus générales que j’ai détaillées dans nom de domaine et DNS : les erreurs de configuration qui coûtent cher — la délivrabilité email est un cas particulier, mais la rigueur de configuration est la même.
Ce que je mets en place
Sur chaque projet, je vérifie systématiquement que SPF, DKIM et DMARC sont en place et cohérents avec tous les services qui envoient réellement des emails au nom du domaine — hébergement, formulaires du site, outils marketing. Je fais monter la politique DMARC progressivement (none → quarantine → reject) en m’appuyant sur les rapports reçus, pour ne jamais bloquer un email légitime au passage. C’est un chantier qui rejoint naturellement les bonnes pratiques de sécurité générale d’un site, voir RGPD et sécurité : ce qu’un site web doit respecter.