SPF et DMARC : les 2 tests email que chaque audit devrait inclure
Le site de votre client est irréprochable. Mais ses emails atterrissent en spam. SPF et DMARC prennent 30 secondes à vérifier et peuvent éviter des catastrophes de délivrabilité — ou des attaques de phishing.
- SPF et DMARC sont des enregistrements DNS qui authentifient les expéditeurs d'emails — sans eux, n'importe qui peut envoyer des emails en se faisant passer pour votre domaine
- Depuis février 2024, Gmail et Outlook exigent SPF et DMARC pour les expéditeurs de masse — l'absence de ces enregistrements impacte directement la délivrabilité
- Ces vérifications prennent 30 secondes et peuvent éviter des catastrophes : factures perdues, contacts manqués, attaques de phishing sur vos clients
Imaginez la scène : votre client vous appelle. Il a lancé une campagne email pour présenter ses nouveaux services. Résultat ? Zéro réponse. Les messages atterrissent en spam, ou pire, des escrocs envoient des emails frauduleux depuis son domaine à ses propres clients.
La plupart des audits de sites web vérifient le SSL, les performances, le SEO, l'accessibilité. Mais ils ignorent deux enregistrements DNS qui prennent 30 secondes à vérifier et qui peuvent littéralement sauver une entreprise : SPF et DMARC.
Ce ne sont pas des détails techniques obscurs. Ce sont des boucliers invisibles qui protègent la crédibilité email d'un domaine. Et depuis février 2024, Gmail et Outlook les exigent explicitement. Si votre audit ne les vérifie pas, il manque quelque chose d'essentiel.
Qu'est-ce que SPF ? (Sender Policy Framework)
SPF est un enregistrement DNS de type TXT qui liste les serveurs autorisés à envoyer des emails au nom d'un domaine. Quand un serveur reçoit un email prétendant venir de votre-client.com, il consulte l'enregistrement SPF de ce domaine pour vérifier si le serveur expéditeur est bien dans la liste des expéditeurs autorisés.
Si le serveur n'est pas dans la liste, l'email peut être marqué comme spam ou rejeté. C'est aussi simple que ça.
Comment ça fonctionne, étape par étape :
- Un email est envoyé depuis server.hosting.com prétendant venir de votre-client.com
- Le serveur destinataire interroge le DNS : quel est l'enregistrement SPF de votre-client.com ?
- Il compare l'IP du serveur expéditeur avec la liste SPF
- Si l'IP est autorisée : l'email passe. Sinon : spam ou rejet selon la politique
Exemple d'enregistrement SPF (Google Workspace) :
v=spf1 include:_spf.google.com ~all
Le mécanisme `~all` indique "rejeter en douceur" (softfail) les emails non listés. Le mécanisme `-all` est plus strict et les rejette complètement. Évitez `+all` qui autorise n'importe qui à envoyer — c'est comme ne pas avoir de SPF du tout.
Qu'est-ce que DMARC ? (Domain-based Message Authentication, Reporting & Conformance)
DMARC va plus loin que SPF seul. Il s'appuie sur SPF et DKIM (une autre méthode d'authentification qui signe cryptographiquement les emails) pour définir une politique claire : que faire quand un email échoue à l'authentification ?
Sans DMARC, même si SPF dit "cet email est suspect", chaque serveur de messagerie décide lui-même quoi faire. Avec DMARC, vous donnez des instructions claires.
Les 3 politiques DMARC :
- p=none — Mode surveillance : l'email passe mais vous recevez des rapports. C'est le point de départ recommandé.
- p=quarantine — Les emails suspects vont en spam. C'est le palier intermédiaire.
- p=reject — Les emails non authentifiés sont rejetés complètement. C'est le niveau maximum de protection.
Exemple d'enregistrement DMARC :
v=DMARC1; p=quarantine; rua=mailto:dmarc@votredomaine.com; pct=100
L'attribut `rua` permet de recevoir des rapports agrégés par email — ils vous indiquent qui essaie d'envoyer des emails en se faisant passer pour votre domaine. Un outil précieux pour détecter des tentatives d'usurpation avant qu'elles ne causent des dégâts.
Pourquoi c'est critique pour vos clients
La question n'est pas "est-ce utile ?", c'est "quel est le coût de ne pas l'avoir ?"
En février 2024, Google et Microsoft ont annoncé de nouvelles exigences pour les expéditeurs d'emails en masse. SPF et DMARC ne sont plus optionnels pour atteindre les boîtes Gmail et Outlook. Un domaine sans ces enregistrements voit ses taux d'ouverture chuter et ses emails finir en spam systématiquement.
Sans SPF ni DMARC, n'importe qui peut envoyer des emails en prétendant être votre-client.com. Des escrocs peuvent contacter les clients de votre client, ses fournisseurs, son banquier — avec son nom de domaine. Le préjudice réputationnel peut être irréversible.
Les fournisseurs de messagerie maintiennent des scores de réputation pour chaque domaine. Un domaine sans SPF/DMARC accumule moins de "confiance". Sur le long terme, même les emails légitimes finissent en spam. C'est un problème qui s'aggrave avec le temps.
Les 3 erreurs les plus courantes
Erreur n°1 : Aucun enregistrement SPF
Le cas le plus fréquent, surtout sur des domaines anciens ou peu maintenus. Le domaine envoie des emails (via Gmail, Mailchimp, ou le CMS) sans aucun enregistrement SPF. Chaque email non authentifié est un risque de délivrabilité et de phishing.
Erreur n°2 : SPF trop permissif avec +all
Un enregistrement SPF qui se termine par `+all` autorise littéralement n'importe quel serveur à envoyer des emails pour ce domaine. C'est pire que de ne pas avoir de SPF : ça donne une fausse impression de sécurité. Cherchez `+all` dans les enregistrements SPF de vos clients — c'est une alerte rouge.
Erreur n°3 : DMARC bloqué en p=none indéfiniment
Commencer par `p=none` est la bonne approche (mode surveillance). Mais de nombreux domaines y restent bloqués pour toujours. Sans passer à `p=quarantine` puis `p=reject`, DMARC n'offre aucune protection réelle — il observe sans jamais agir.
Comment vérifier SPF et DMARC en 30 secondes
Pas besoin d'outils sophistiqués. Deux commandes en ligne de commande (ou des outils web) suffisent :
Vérifier SPF avec dig :
Vérifier DMARC avec dig :
Outils en ligne gratuits :
- MXToolbox (mxtoolbox.com) — analyse SPF, DMARC et DKIM avec des explications
- Google Admin Toolbox (toolbox.googleapps.com) — outil officiel Google
- DMARC Analyzer (dmarcanalyzer.com) — analyse et générateur d'enregistrements
Ce qu'il faut chercher :
- SPF présent : l'enregistrement TXT commence par v=spf1
- SPF pas de +all : le mécanisme final doit être ~all ou -all
- DMARC présent : l'enregistrement TXT de _dmarc. commence par v=DMARC1
- DMARC pas en none indéfiniment : idéalement p=quarantine ou p=reject
Comment Orilyt va tester SPF et DMARC
Les vérifications SPF et DMARC font partie du Batch 1 des nouveaux tests multi-CMS d'Orilyt, en cours de développement.
Ces tests seront entièrement externes : une simple requête DNS, sans accès admin, sans plugin, compatible avec tous les CMS (WordPress, Wix, Squarespace, Shopify, site sur-mesure...). Si le domaine existe, le test fonctionne.
- Vérification DNS externe : aucun accès au site nécessaire
- Compatible tous CMS : WordPress, Webflow, Shopify, site sur-mesure
- Inclus automatiquement dans chaque audit Orilyt
- Recommandation FIA générée : Fait, Impact, Action — prête à présenter au client
L'objectif : que chaque rapport Orilyt inclue automatiquement une section "Email & Sécurité" avec le statut SPF, DMARC, et une recommandation claire si l'un des deux est absent ou mal configuré.
L'audit email : le quick win que personne ne regarde
SPF et DMARC sont probablement les vérifications les plus négligées dans un audit web traditionnel. Elles ne sont pas visibles dans le navigateur, elles n'affectent pas le score PageSpeed, et pourtant elles ont un impact business direct : emails perdus, usurpation d'identité, réputation dégradée.
Pour un freelance ou une agence, inclure ces vérifications dans chaque audit, c'est à la fois un avantage concurrentiel et un service rendu aux clients. Combien de PME ont des enregistrements SPF inexistants ou mal configurés ? La réponse vous surprendrait.
La bonne nouvelle : les corriger prend 10 minutes chez l'hébergeur. Mais pour ça, encore faut-il les détecter. C'est exactement ce qu'Orilyt va faire automatiquement dans chaque audit.