Partie 2 de la série « Sécurité web dans l'UE : 10 étapes pour une meilleure note »
Le problème
Quelqu'un envoie un e-mail depuis ceo@votre-domaine.com à votre client. L'e-mail contient une demande de paiement. Il ne vient pas de vous.
Sans DMARC : Le serveur de messagerie du destinataire n'a aucun moyen de vérifier si le domaine de l'expéditeur est légitime. L'e-mail arrive dans la boîte de réception.
Avec DMARC configuré à reject : Le serveur de messagerie vérifie SPF et DKIM, détermine que l'e-mail n'est pas autorisé, et le rejette. Il n'est jamais délivré.
46,8% des sites web européens ont un enregistrement DMARC. Mais 63% d'entre eux définissent la politique à none — c'est-à-dire sans application. Le domaine reste usurpable, comme si DMARC n'était pas configuré du tout.
Ce que nous observons dans le benchmark
Sur plus de 700 000 sites web européens :
- SPF : 75,7% — la plupart ont les bases en place
- DKIM : 31,1% — moins d'un sur trois signe ses e-mails
- DMARC : 46,8% — mais parmi ceux-ci :
policy=none: 63% (surveillance uniquement, ne bloque rien)policy=quarantine: 17% (dirige vers le spam)policy=reject: 20% (rejette directement — la seule protection efficace)
Et puis les erreurs de configuration : quarantaine, rejet, keiner, brak, beleidsnaam — des fautes de frappe qui font que l'enregistrement est entièrement ignoré. Le standard DMARC est strict : une seule faute dans le champ de politique et toute la configuration est écartée.
Qu'est-ce que DMARC ?
DMARC (Domain-based Message Authentication, Reporting & Conformance) s'appuie sur SPF et DKIM :
- SPF vérifie : Ce serveur de messagerie est-il autorisé à envoyer au nom de mon domaine ?
- DKIM vérifie : Le message a-t-il été altéré en transit ?
- DMARC dit : Que doit-il se passer quand SPF et DKIM échouent ?
Sans DMARC, chaque serveur de messagerie destinataire décide seul. Avec DMARC, c'est vous qui décidez.
Les trois étapes
Étape 1 : Configurer DMARC à none (Jour 1)
Créez un enregistrement TXT pour _dmarc.votre-domaine.com :
v=DMARC1; p=none; rua=mailto:dmarc-reports@votre-domaine.com
p=none— aucune application, surveillance uniquementrua=mailto:...— les serveurs destinataires envoient les rapports agrégés ici
Les rapports vous montrent qui envoie des e-mails en votre nom. Vous découvrirez souvent des outils de newsletter, des systèmes CRM ou des services tiers que vous aviez oubliés.
Attendez 2 à 4 semaines. Analysez les rapports. Assurez-vous que tous les expéditeurs légitimes sont alignés SPF ou DKIM.
Étape 2 : Passer à quarantine (Semaine 3-4)
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@votre-domaine.com
p=quarantine— les e-mails non authentifiés vont dans le dossier spampct=10— seuls 10% des e-mails sont traités ainsi (déploiement progressif)
Surveillez les rapports. Pas de plaintes ? Augmentez pct à 50, puis 100.
Étape 3 : Passer à reject (Semaine 5-6)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@votre-domaine.com
Désormais, les e-mails usurpés sont rejetés. Votre domaine est protégé.
SPF et DKIM doivent être corrects
DMARC ne fonctionne que si au moins SPF ou DKIM est correctement configuré :
SPF : Un enregistrement TXT pour votre-domaine.com listant tous les serveurs de messagerie autorisés :
v=spf1 include:_spf.google.com include:spf.brevo.com -all
Le -all à la fin est critique — il signifie « rejeter tous les autres ». ~all (tilde) est un softfail et est souvent ignoré.
DKIM : Votre fournisseur de messagerie génère une paire de clés. La clé publique est publiée comme enregistrement TXT sous selector._domainkey.votre-domaine.com. Demandez à votre fournisseur — la plupart ont un guide de configuration.
Erreurs courantes
1. Oublier les expéditeurs tiers. Plateformes de newsletter (Mailchimp, Brevo), systèmes de tickets (Zendesk, Freshdesk), CRM (HubSpot) — tous envoient des e-mails en votre nom. Tous doivent être inclus dans votre enregistrement SPF ou signer avec DKIM.
2. Ignorer les sous-domaines. DMARC s'applique aux sous-domaines par défaut. Si marketing.votre-domaine.com envoie des e-mails, il doit être couvert aussi. Utilisez sp=reject pour une politique de sous-domaine séparée.
3. Ne pas lire les rapports. Les rapports agrégés DMARC en XML ne sont pas lisibles par un humain. Utilisez un analyseur de rapports gratuit (dmarcian, Postmark DMARC Tool) pour comprendre ce qui se passe.
Contexte réglementaire
- NIS2 Art. 21(2)(j) exige des mesures pour la « sécurité de la chaîne d'approvisionnement » — cela inclut la sécurisation des communications par e-mail avec les partenaires et fournisseurs.
- RGPD Art. 32 exige des « mesures techniques appropriées » — l'usurpation d'e-mail permet le phishing, qui mène à des violations de données.
- DORA Art. 7 exige du secteur financier qu'il identifie et classifie tous les risques TIC — les attaques par e-mail sont parmi les plus courantes.
Vérifiez votre domaine
SiteGuardian vérifie SPF, DKIM, DMARC, STARTTLS et MTA-STS en une seule analyse — et vous montre non seulement si les enregistrements existent, mais s'ils fonctionnent réellement :
La semaine prochaine dans la Partie 3 : Content Security Policy — la défense la plus efficace contre les XSS, absente sur 89% des sites web de l'UE.
Cet article fait partie de la série « Sécurité web dans l'UE : 10 étapes pour une meilleure note ». Données du SiteGuardian EU Web Security Benchmark couvrant plus de 700 000 sites web européens.