Le problème : usurpation d'identité par email
Sans protection, un attaquant peut envoyer un email apparaissant comme venant de compta@votreentreprise.fr, alors qu'il est envoyé depuis son propre serveur en Russie. Vos clients reçoivent un faux RIB, votre banque reçoit une fausse demande de virement, et tout cela passe les filtres anti-spam basiques.
Trois enregistrements DNS standards résolvent ce problème. Tous les fournisseurs (OVH, Gandi, Microsoft 365, Google Workspace) les supportent.
SPF : qui a le droit d'envoyer en mon nom
SPF (Sender Policy Framework) est un enregistrement TXT qui liste les serveurs autorisés à envoyer des emails depuis votre domaine. Si l'email vient d'ailleurs, le destinataire le rejette ou le marque comme spam.
Exemple pour Microsoft 365 :
- Type :
TXT - Nom :
@(racine du domaine) - Valeur :
v=spf1 include:spf.protection.outlook.com -all
Le -all à la fin signifie « rejette tout email venu d'ailleurs ». C'est le mode strict, recommandé.
DKIM : signature cryptographique des emails
DKIM (DomainKeys Identified Mail) signe chaque email sortant avec une clé privée. Le destinataire vérifie la signature avec la clé publique publiée dans votre DNS. Si la signature ne correspond pas, l'email est rejeté.
DKIM se configure dans l'interface admin de votre fournisseur email (Microsoft 365, Google Workspace, OVH Email Pro). Il génère pour vous deux enregistrements CNAME à coller dans votre DNS :
selector1._domainkey.votredomaine.frselector2._domainkey.votredomaine.fr
5 minutes par domaine, le bénéfice est massif.
DMARC : la politique qui rend SPF + DKIM contraignants
DMARC (Domain-based Message Authentication, Reporting and Conformance) dit aux serveurs de réception : « Si SPF ou DKIM échoue, voilà ce que tu fais ». Trois politiques :
p=none: rapport seulement, on ne bloque pas. Mode d'observation.p=quarantine: emails suspects mis en spam.p=reject: emails suspects rejetés. C'est la cible.
Exemple d'enregistrement DMARC :
- Type :
TXT - Nom :
_dmarc - Valeur :
v=DMARC1; p=quarantine; rua=mailto:dmarc@votredomaine.fr; pct=100
L'adresse rua reçoit des rapports quotidiens des fournisseurs (Google, Outlook). Vous voyez qui envoie en votre nom et d'où.
La séquence de déploiement en 10 minutes
- Vérifier l'état actuel sur mxtoolbox.com/SuperTool.aspx avec votre domaine. Vous saurez ce qui existe déjà.
- Ajouter SPF avec
-alldans votre DNS. - Activer DKIM dans l'interface admin de votre messagerie.
- Ajouter DMARC d'abord en
p=nonepour observer, pendant 2 semaines. - Lire les rapports DMARC pour identifier les services légitimes (votre CRM, votre outil emailing) qu'il faut autoriser dans SPF.
- Passer DMARC en
p=quarantinepuisp=rejectau bout de 2 mois.
L'erreur classique à éviter
Passer directement à p=reject sans phase d'observation. Conséquence : les emails légitimes envoyés par votre CRM, votre outil de signature électronique ou votre logiciel comptable sont rejetés. Vos clients ne reçoivent plus rien et vous découvrez le problème 3 semaines plus tard.
La phase p=none de 2 semaines évite ce scénario. C'est un investissement en patience qui se rentabilise.
À retenir
Ce que Scryptoura fait pour vous
Notre offre Cybersécurité et notre Diagnostic Découverte incluent l'audit complet de votre configuration email et la mise en place de SPF/DKIM/DMARC. Si vous gérez votre domaine en interne, on vous accompagne sur les rapports DMARC les premières semaines.