Améliorer la délivrabilité de vos emails en protégeant votre marque : guide complet SPF, DKIM et DMARC

Pourquoi vos emails finissent en spam (ou n’arrivent jamais)

Vous avez soigneusement rédigé votre proposition commerciale. Vous cliquez sur « Envoyer ». Côté technique, tout semble normal — pas de message d’erreur, l’email apparaît dans vos envoyés. Pourtant, votre prospect ne répond pas. Une relance plus tard, vous découvrez qu’il n’a jamais reçu votre message. Ou pire : il l’a retrouvé dans ses spams, coincé entre une fausse loterie et une publicité douteuse.

Ce scénario, des milliers d’entreprises le vivent chaque jour sans même le savoir.

Le problème de la « boîte noire »

Contrairement à un courrier postal qui revient avec la mention « N’habite pas à l’adresse indiquée », un email qui n’arrive pas ne génère souvent aucune alerte. Votre serveur l’a bien envoyé, le serveur destinataire l’a bien reçu… puis l’a silencieusement écarté. Pas de notification, pas de bounce, rien.

C’est ce qu’on appelle le soft fail silencieux : l’email est techniquement délivré, mais jamais présenté au destinataire.

Les impacts concrets pour votre entreprise

Les conséquences dépassent largement le cadre technique :

• Perte de chiffre d’affaires : devis non reçus, relances ignorées, opportunités manquées
• Dégradation de la relation client : factures « jamais reçues », confirmations de commande absentes, support client injoignable
• Atteinte à votre image professionnelle : quand vos emails arrivent en spam, votre nom de domaine se retrouve associé aux arnaques et au phishing
• Perte de temps opérationnelle : « Vous avez bien reçu mon email ? » devient une question récurrente

Pourquoi les filtres anti-spam se méfient de vous

Les fournisseurs de messagerie (Gmail, Outlook, Orange…) font face à un volume colossal de tentatives de fraude. Pour protéger leurs utilisateurs, ils appliquent une logique simple : tout email non authentifié est suspect.

Concrètement, quand votre email arrive sur un serveur destinataire, celui-ci se pose trois questions :

1. L’expéditeur est-il autorisé à envoyer des emails pour ce domaine ?
2. Le message a-t-il été altéré pendant son transit ?
3. Que faire si la vérification échoue ?

Si votre domaine ne fournit pas de réponses claires à ces questions, le serveur destinataire applique le principe de précaution : direction spam, voire suppression pure et simple.

Le cercle vicieux de la mauvaise réputation

Chaque email marqué comme spam par un destinataire, chaque message non authentifié, chaque tentative d’usurpation de votre domaine par un tiers… tout cela dégrade votre réputation d’expéditeur.

Et cette réputation est persistante. Les grands fournisseurs maintiennent des scores de confiance par domaine. Une fois votre réputation entamée, même vos emails légitimes deviennent suspects. Remonter la pente peut prendre des semaines, voire des mois.

La bonne nouvelle ? Les outils pour reprendre le contrôle existent. Ils s’appellent SPF, DKIM et DMARC.

L’usurpation d’email : une menace invisible pour votre entreprise

Imaginez : un de vos clients reçoit un email provenant apparemment de votre adresse, avec votre signature, lui demandant de régler une facture sur un nouveau RIB. Il s’exécute. Quelques jours plus tard, il vous relance pour savoir pourquoi sa commande n’est pas expédiée. Vous n’avez jamais envoyé cet email. Vous n’avez jamais reçu ce paiement.

Ce scénario n’est pas de la science-fiction. C’est le quotidien de milliers d’entreprises victimes de spoofing.

Le spoofing : usurper votre identité sans pirater vos systèmes

Contrairement à ce qu’on pourrait croire, un attaquant n’a pas besoin d’accéder à votre boîte mail pour envoyer des emails en votre nom. Le protocole SMTP, conçu dans les années 80, n’intègre aucun mécanisme d’authentification natif. N’importe qui peut techniquement envoyer un email avec l’adresse expéditeur de son choix.

C’est comme envoyer une lettre postale en inscrivant l’adresse de quelqu’un d’autre au dos de l’enveloppe. Simple, efficace, et redoutablement trompeur.

Le spoofing se décline en plusieurs variantes :

• Usurpation exacte : l’attaquant utilise précisément votre adresse (contact@votre-entreprise.fr)
• Usurpation de domaine cousin : il enregistre un domaine proche (votre-entreprlse.fr avec un « L » à la place du « i »)
• Usurpation du nom affiché : l’adresse technique est différente, mais le nom affiché est « Votre Entreprise »

Les attaques qui exploitent votre réputation

Votre nom de domaine a une valeur : celle de la confiance que vos clients, partenaires et fournisseurs lui accordent. Les attaquants le savent et l’exploitent.

La fraude au président (BEC)

Le Business Email Compromise cible spécifiquement les entreprises. L’attaquant se fait passer pour un dirigeant ou un fournisseur de confiance pour obtenir un virement frauduleux. Ces attaques sont souvent précédées d’une phase de reconnaissance : l’attaquant étudie votre organigramme, votre façon de communiquer, vos prestataires habituels.

Le phishing ciblé

Vos clients reçoivent un email « de votre part » les invitant à mettre à jour leurs informations de paiement, à télécharger une facture piégée, ou à cliquer sur un lien malveillant. Votre crédibilité devient l’arme de l’attaquant.

L’empoisonnement de réputation

Certains attaquants utilisent votre domaine pour envoyer des campagnes de spam massives. Résultat : votre domaine se retrouve sur des listes noires, et vos emails légitimes ne passent plus.

Des conséquences bien réelles

Les dégâts d’une usurpation d’identité email dépassent largement le cadre technique :

• Pertes financières directes : virements frauduleux, parfois de plusieurs dizaines de milliers d’euros
• Perte de confiance : même si vous n’êtes pas responsable, c’est votre nom qui apparaît dans l’arnaque
• Responsabilité juridique floue : en cas de litige, prouver votre bonne foi peut s’avérer complexe
• Temps et énergie : gérer la crise, prévenir les clients, restaurer votre réputation

Pourquoi vous êtes concerné, quelle que soit votre taille

Une idée reçue persiste : « Je suis une petite structure, je n’intéresse pas les pirates. » C’est faux, et même l’inverse.

Les PME et TPE sont des cibles privilégiées précisément parce qu’elles sont souvent moins bien protégées que les grands groupes. Les attaquants privilégient le volume : envoyer 10 000 tentatives de phishing en usurpant des domaines de petites entreprises est plus rentable que de cibler une multinationale bardée de protections.

De plus, vos partenaires et clients vous font confiance. Cette confiance, non protégée techniquement, devient une vulnérabilité.

La solution : prouver cryptographiquement votre identité

La bonne nouvelle, c’est qu’il existe aujourd’hui des mécanismes standardisés pour authentifier vos emails de manière irréfutable. Ces mécanismes permettent aux serveurs destinataires de vérifier que :

• L’email provient bien d’un serveur autorisé par vous
• Le contenu n’a pas été modifié en transit
• Vous avez défini une politique claire en cas d’échec

Ces trois piliers portent des noms : SPF, DKIM et DMARC. Ensemble, ils forment un bouclier technique qui protège à la fois votre délivrabilité et votre réputation.

SPF, DKIM, DMARC : le trio gagnant de l’authentification email

Vous l’avez compris : sans authentification, vos emails sont suspects par défaut et votre domaine est vulnérable à l’usurpation. La solution repose sur trois protocoles complémentaires qui, ensemble, forment un système de protection robuste.

Avant de plonger dans les détails techniques de chacun, prenons un peu de hauteur pour comprendre leur logique commune et leur articulation.

Une analogie simple : le courrier recommandé

Imaginez que vous envoyez un document officiel important. Pour garantir son authenticité, vous pourriez :

1. Déclarer à La Poste la liste des personnes habilitées à envoyer du courrier en votre nom → c’est le rôle de SPF
2. Apposer un sceau de cire unique que seul vous possédez, prouvant que le document n’a pas été falsifié → c’est le rôle de DKIM
3. Laisser des instructions claires au destinataire : « Si le sceau est brisé ou l’expéditeur non autorisé, refusez le courrier et prévenez-moi » → c’est le rôle de DMARC

Chaque mécanisme répond à une question précise. Ensemble, ils couvrent l’ensemble de la chaîne de confiance.

SPF : qui est autorisé à envoyer ?

SPF (Sender Policy Framework) permet de déclarer publiquement quels serveurs ont le droit d’envoyer des emails pour votre domaine.

Concrètement, vous publiez un enregistrement DNS qui liste les adresses IP ou les services autorisés. Quand un serveur destinataire reçoit un email prétendant venir de votre domaine, il consulte cet enregistrement et vérifie si l’IP d’envoi y figure.

Ce que SPF vérifie : l’adresse IP du serveur d’envoi.

Ce que SPF ne vérifie pas : le contenu du message, ni l’adresse « From » affichée au destinataire.

DKIM : le message est-il authentique ?

DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque email envoyé. Cette signature, générée avec une clé privée que vous seul possédez, est vérifiable par n’importe qui grâce à une clé publique publiée dans vos DNS.

Le serveur destinataire peut ainsi s’assurer de deux choses :

• L’email a bien été envoyé (ou du moins signé) par le propriétaire du domaine
• Le contenu n’a pas été modifié en transit

Ce que DKIM vérifie : l’intégrité du message et l’authenticité de la signature.

Ce que DKIM ne vérifie pas : que le serveur d’envoi était autorisé, ni ce qu’il faut faire en cas d’échec.

DMARC : que faire en cas de problème ?

DMARC (Domain-based Message Authentication, Reporting and Conformance) est la pièce maîtresse qui coordonne SPF et DKIM. Il permet de :

• Définir une politique : que doit faire le destinataire si SPF et DKIM échouent ? (laisser passer, mettre en spam, rejeter)
• Exiger un alignement : l’adresse « From » visible doit correspondre au domaine vérifié par SPF ou DKIM
• Recevoir des rapports : les serveurs destinataires vous envoient des statistiques sur les emails reçus en votre nom

Ce que DMARC apporte : une politique claire et de la visibilité sur ce qui circule au nom de votre domaine.

Pourquoi les trois sont indispensables

Chaque protocole pris isolément présente des limites :

Protocole	Seul, il…	Combiné, il…
SPF	Vérifie l’IP, mais pas l’adresse visible	Confirme que le serveur est autorisé
DKIM	Signe le message, mais sans instruction en cas d’échec	Prouve l’intégrité et l’authenticité
DMARC	N’existe pas sans SPF ou DKIM	Coordonne, aligne et rapporte

Un attaquant peut contourner SPF seul en utilisant un serveur autorisé pour un autre domaine. Il peut ignorer DKIM si aucune politique DMARC n’est définie. Mais face aux trois combinés, avec une politique stricte et un alignement exigé, l’usurpation devient techniquement impossible à réaliser sans être détectée.

Le flux de vérification côté destinataire

Quand un serveur reçoit un email prétendant venir de @votre-domaine.fr, voici ce qui se passe :

1. Vérification SPF : l’IP d’envoi est-elle autorisée dans les DNS de votre-domaine.fr ?
2. Vérification DKIM : la signature est-elle valide et correspond-elle à une clé publiée par votre-domaine.fr ?
3. Évaluation DMARC :
   • Au moins un des deux (SPF ou DKIM) est-il valide et aligné avec l’adresse « From » ?
   • Si non, quelle politique appliquer (none, quarantine, reject) ?
4. Décision finale : délivrer, mettre en spam, ou rejeter
5. Rapport : envoyer un rapport au propriétaire du domaine (si demandé)

Un investissement rentable

La mise en place de ces trois protocoles représente un effort initial modéré — quelques enregistrements DNS à configurer — pour des bénéfices durables :

• Meilleure délivrabilité : vos emails légitimes sont authentifiés et mieux acceptés
• Protection de marque : l’usurpation de votre domaine devient détectable et bloquable
• Visibilité : vous savez enfin ce qui s’envoie au nom de votre domaine
• Conformité : de plus en plus de partenaires et de plateformes exigent ces protections

SPF : définir qui a le droit d’envoyer vos emails

SPF est généralement le premier protocole à mettre en place. C’est aussi le plus simple à comprendre : vous déclarez publiquement la liste des serveurs autorisés à envoyer des emails pour votre domaine. Tout le reste est suspect.

Le principe : une liste blanche dans vos DNS

SPF fonctionne via un enregistrement DNS de type TXT placé à la racine de votre domaine. Cet enregistrement contient une liste de règles décrivant les sources d’envoi légitimes.

Quand un serveur destinataire reçoit un email prétendant venir de @votre-domaine.fr, il interroge les DNS de votre-domaine.fr, récupère l’enregistrement SPF, et vérifie si l’adresse IP du serveur émetteur correspond à l’une des sources autorisées.

C’est un mécanisme déclaratif et public : n’importe qui peut consulter votre enregistrement SPF pour savoir qui est autorisé à envoyer en votre nom.

Anatomie d’un enregistrement SPF

Un enregistrement SPF ressemble à ceci :

v=spf1 mx a include:_spf.google.com ip4:203.0.113.42 -all

Décortiquons chaque élément :

Le préfixe obligatoire

• v=spf1 : identifie l’enregistrement comme étant du SPF version 1 (la seule en vigueur). Sans ce préfixe, l’enregistrement est ignoré.

Les mécanismes d’autorisation

Ce sont les règles qui définissent les sources légitimes :

• a : autorise l’adresse IP associée à l’enregistrement A de votre domaine (votre serveur web, typiquement)
• mx : autorise les serveurs définis dans vos enregistrements MX (vos serveurs de réception email)
• ip4:203.0.113.42 : autorise explicitement une adresse IPv4 spécifique
• ip6:2001:db8::1 : même chose pour une adresse IPv6
• include:_spf.google.com : inclut les règles SPF d’un autre domaine (ici Google Workspace)

Le qualifieur final

La directive finale indique quoi faire des emails provenant de sources non listées :

• -all (tiret) : hard fail — rejeter catégoriquement
• ~all (tilde) : soft fail — marquer comme suspect, mais accepter (souvent direction spam)
• ?all (interrogation) : neutre — aucune indication, traiter comme non authentifié
• +all : tout autoriser — à ne jamais utiliser, cela revient à désactiver SPF

Les qualifieurs en détail : -all vs ~all

Ce choix est crucial et source de nombreuses erreurs.

~all (soft fail) est souvent recommandé en phase de déploiement. Il permet d’identifier les problèmes sans bloquer brutalement des emails légitimes oubliés. Les serveurs destinataires considèrent l’échec comme un indice de spam, pas comme une preuve.

-all (hard fail) est la configuration cible pour une protection maximale. Elle indique clairement : « Tout email ne provenant pas de mes sources autorisées est frauduleux, rejetez-le. »

En pratique : commencez par ~all le temps de vérifier que toutes vos sources légitimes sont bien déclarées, puis passez à -all une fois la configuration stabilisée.

Le mécanisme include : déléguer l’autorisation

Dès que vous utilisez un service tiers pour envoyer des emails (newsletter, CRM, facturation, marketing automation…), vous devez l’inclure dans votre SPF.

Chaque prestataire publie son propre enregistrement SPF. Le mécanisme include: permet de l’incorporer dans le vôtre :

v=spf1 include:_spf.google.com include:sendgrid.net include:mailjet.com -all

Quand le serveur destinataire évalue votre SPF, il résout récursivement chaque include pour vérifier si l’IP d’envoi correspond.

La limite des 10 lookups DNS

C’est la contrainte technique la plus importante à connaître : un enregistrement SPF ne peut pas générer plus de 10 requêtes DNS lors de son évaluation.

Chaque mécanisme suivant consomme un lookup :

• include: → 1 lookup (+ les lookups de l’enregistrement inclus)
• a → 1 lookup
• mx → 1 lookup (+ 1 par serveur MX résolu)
• redirect= → 1 lookup

Les mécanismes suivants ne consomment pas de lookup :

• ip4: et ip6: → 0 lookup (adresses directes)
• all → 0 lookup

Pourquoi cette limite ? Elle existe pour éviter les attaques par déni de service. Un attaquant pourrait créer des chaînes d’includes infinies pour surcharger les serveurs DNS.

En cas de dépassement, l’évaluation SPF échoue avec un permerror, ce qui peut entraîner le rejet de vos emails légitimes.

Exemple concret : une PME classique

Prenons une entreprise qui :

• Héberge son site web et envoie quelques emails transactionnels depuis son serveur (IP : 203.0.113.10)
• Utilise Google Workspace pour la messagerie quotidienne
• Utilise Brevo (ex-Sendinblue) pour ses newsletters
• Utilise Tiime pour sa facturation

Son enregistrement SPF pourrait ressembler à :

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:spf.brevo.com include:spf.tiime.fr ~all

Décompte des lookups :

• ip4: → 0
• include:_spf.google.com → 1 (+ ceux de Google, environ 3)
• include:spf.brevo.com → 1 (+ ceux de Brevo)
• include:spf.tiime.fr → 1 (+ ceux de Tiime)

Il est essentiel de vérifier le nombre total avec un outil dédié (nous y reviendrons au chapitre 8).

Les erreurs fréquentes à éviter

Quelques pièges classiques :

• Plusieurs enregistrements SPF : il ne doit y avoir qu’un seul enregistrement TXT commençant par v=spf1. Si vous en avez plusieurs, SPF échoue.
• Oublier un prestataire : chaque service qui envoie des emails en votre nom doit être inclus, sinon ses envois échoueront.
• Dépasser les 10 lookups : avec de nombreux prestataires, on atteint vite la limite. Il existe des techniques d’optimisation (aplatissement, SPF macros) pour les cas complexes.
• Rester en ~all indéfiniment : le soft fail est une étape transitoire, pas une configuration finale.
• Oublier IPv6 : si vos serveurs envoient aussi en IPv6, les adresses doivent être déclarées via ip6:.

SPF seul ne suffit pas

Malgré son utilité, SPF présente une limite fondamentale : il vérifie l’IP du serveur d’envoi, mais pas l’adresse « From » affichée au destinataire.

Un attaquant pourrait envoyer un email depuis un serveur autorisé pour son domaine, tout en affichant votre adresse dans le champ « From » visible. SPF seul ne détecte pas cette usurpation.

C’est précisément pourquoi DKIM et DMARC sont indispensables pour compléter le dispositif.

DKIM : signer numériquement vos messages

Si SPF répond à la question « qui est autorisé à envoyer ? », DKIM répond à une question complémentaire : « ce message est-il authentique et intact ? ». Grâce à la cryptographie asymétrique, DKIM permet de prouver qu’un email a bien été envoyé (ou validé) par le propriétaire du domaine, et qu’il n’a pas été modifié en transit.

Le principe : une signature cryptographique

DKIM repose sur un mécanisme de clé publique / clé privée :

1. Vous générez une paire de clés cryptographiques
2. La clé privée reste secrète, stockée sur votre serveur d’envoi
3. La clé publique est publiée dans vos DNS, accessible à tous
4. Chaque email sortant est signé avec la clé privée
5. Le destinataire vérifie la signature avec la clé publique

Si la signature correspond, le destinataire a la certitude que :

• L’email a été signé par quelqu’un possédant la clé privée du domaine
• Le contenu signé n’a pas été altéré depuis la signature

Ce que DKIM signe exactement

DKIM ne signe pas l’intégralité de l’email. La signature porte sur :

• Certains en-têtes : From, To, Subject, Date, et d’autres selon la configuration
• Le corps du message : le contenu textuel et/ou HTML

La liste des en-têtes signés est indiquée dans la signature elle-même. C’est un point important : un en-tête non signé peut être modifié sans invalider la signature.

Anatomie d’une signature DKIM

Quand un email est signé, un en-tête DKIM-Signature est ajouté. Voici un exemple simplifié :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=votre-domaine.fr; s=selector1;
    h=from:to:subject:date:message-id;
    bh=abc123...=;
    b=xyz789...=

Décortiquons les éléments clés :

• v=1 : version du protocole DKIM
• a=rsa-sha256 : algorithme de signature (RSA avec hachage SHA-256)
• c=relaxed/relaxed : mode de canonicalisation (tolérance aux modifications mineures d’espaces et de casse)
• d=votre-domaine.fr : le domaine qui signe (crucial pour l’alignement DMARC)
• s=selector1 : le sélecteur, permettant d’avoir plusieurs clés pour un même domaine
• h=from:to:subject:... : liste des en-têtes inclus dans la signature
• bh=abc123... : hash du corps du message
• b=xyz789... : la signature cryptographique elle-même

Le sélecteur : gérer plusieurs clés

Le sélecteur est une notion propre à DKIM qui offre une grande flexibilité. Il permet de :

• Utiliser des clés différentes pour des services différents (une pour votre serveur, une pour votre outil marketing…)
• Effectuer une rotation de clés sans interruption de service
• Identifier la source d’un email signé

La clé publique est publiée dans un enregistrement DNS à l’adresse :

selecteur._domainkey.votre-domaine.fr

Par exemple, si votre sélecteur est google, la clé sera cherchée dans :

google._domainkey.votre-domaine.fr

L’enregistrement DNS de la clé publique

L’enregistrement TXT contenant la clé publique ressemble à ceci :

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

Les éléments :

• v=DKIM1 : version du protocole
• k=rsa : type de clé (RSA est le plus courant)
• p=MIGf... : la clé publique encodée en base64

Certains enregistrements incluent des paramètres optionnels :

• t=s : mode strict, le domaine de signature doit correspondre exactement au domaine du From
• t=y : mode test, indique que DKIM est en cours de déploiement

Le processus de vérification

Quand un serveur destinataire reçoit un email avec une signature DKIM :

1. Il extrait le domaine (d=) et le sélecteur (s=) de la signature
2. Il interroge les DNS pour récupérer la clé publique à selecteur._domainkey.domaine
3. Il recalcule le hash du corps et des en-têtes signés
4. Il vérifie que la signature correspond au hash recalculé avec la clé publique
5. Si tout correspond → DKIM pass. Sinon → DKIM fail.

Modes de canonicalisation : simple vs relaxed

Les emails peuvent subir des modifications mineures en transit : ajout d’espaces, changement de casse dans les en-têtes, retours à la ligne modifiés. La canonicalisation définit comment normaliser le message avant vérification.

Simple : très strict, la moindre modification invalide la signature. Recommandé uniquement si vous maîtrisez toute la chaîne d’envoi.

Relaxed : plus tolérant, ignore les différences d’espaces et de casse. C’est le mode recommandé pour la plupart des usages, d’où le c=relaxed/relaxed fréquent (le premier pour les en-têtes, le second pour le corps).

DKIM avec les services tiers

Quand vous utilisez un service externe pour envoyer des emails (Google Workspace, Microsoft 365, Brevo, Mailchimp…), deux options existent :

Signature par le domaine du prestataire

Par défaut, le prestataire signe avec son propre domaine. L’email passe DKIM, mais le domaine de signature (d=) ne correspond pas à votre domaine d’expéditeur. Cela pose un problème pour l’alignement DMARC.

Signature avec votre domaine (recommandé)

La plupart des prestataires permettent de configurer DKIM avec votre propre domaine :

1. Le prestataire vous fournit une clé publique et un sélecteur
2. Vous publiez l’enregistrement DNS correspondant
3. Le prestataire signe les emails avec la clé privée associée
4. Les emails passent DKIM et l’alignement DMARC

Exemple avec Google Workspace : Google vous demande de créer un enregistrement google._domainkey.votre-domaine.fr contenant la clé publique qu’il vous fournit.

Taille des clés : 1024 vs 2048 bits

Les clés DKIM existent en différentes tailles :

• 1024 bits : historiquement standard, encore accepté mais considéré comme le minimum
• 2048 bits : recommandé aujourd’hui pour une sécurité robuste
• 4096 bits : très sécurisé, mais peut poser des problèmes (certains DNS limitent la taille des enregistrements TXT)

Un point d’attention : les clés 2048 bits génèrent des enregistrements TXT longs, parfois divisés en plusieurs chaînes. Vérifiez que votre hébergeur DNS les gère correctement.

Les limites de DKIM seul

Comme SPF, DKIM présente des limites quand il est utilisé isolément :

• Pas de politique définie : si DKIM échoue, le serveur destinataire ne sait pas quoi faire. Laisser passer ? Rejeter ?
• Pas d’obligation d’alignement : un attaquant peut signer avec son domaine tout en affichant votre adresse en From
• Pas de reporting : vous n’avez aucune visibilité sur les résultats des vérifications

C’est DMARC qui va combler ces lacunes en coordonnant SPF et DKIM avec une politique explicite et des rapports détaillés.

DMARC : reprendre le contrôle avec une politique claire

SPF vérifie l’origine, DKIM garantit l’intégrité. Mais sans instructions claires, les serveurs destinataires restent livrés à eux-mêmes face à un échec d’authentification. DMARC vient compléter le dispositif en apportant trois éléments essentiels : une politique explicite, un alignement obligatoire, et des rapports détaillés.

Le principe : coordonner et instruire

DMARC (Domain-based Message Authentication, Reporting and Conformance) est un protocole qui s’appuie sur SPF et DKIM pour :

1. Exiger un alignement entre le domaine visible (From) et le domaine authentifié
2. Définir une politique : que faire si l’authentification échoue ?
3. Collecter des rapports : recevoir des statistiques sur les emails envoyés en votre nom

Sans DMARC, un attaquant peut exploiter les failles de SPF et DKIM pris isolément. Avec DMARC, vous reprenez le contrôle sur ce qui circule au nom de votre domaine.

L’alignement : la pièce maîtresse

L’alignement est le concept central de DMARC. Il vérifie que le domaine visible par le destinataire (l’adresse « From ») correspond au domaine authentifié par SPF ou DKIM.

Pourquoi c’est crucial

Imaginons un attaquant qui :

• Envoie un email depuis son propre serveur (SPF valide pour son domaine)
• Signe l’email avec sa propre clé DKIM (DKIM valide pour son domaine)
• Mais affiche votre adresse dans le champ « From »

Sans DMARC, cet email passe SPF et DKIM. Avec DMARC, l’absence d’alignement entre le domaine du From (votre-domaine.fr) et le domaine authentifié (domaine-attaquant.com) provoque un échec.

Alignement SPF

Pour que l’alignement SPF soit valide, le domaine du Return-Path (ou envelope from) doit correspondre au domaine du From visible.

Alignement DKIM

Pour que l’alignement DKIM soit valide, le domaine de signature (d= dans la signature DKIM) doit correspondre au domaine du From visible.

Mode strict vs relaxed

DMARC propose deux modes d’alignement :

• Strict (s) : correspondance exacte requise. mail.votre-domaine.fr ne s’aligne pas avec votre-domaine.fr
• Relaxed (r) : correspondance au niveau du domaine organisationnel. mail.votre-domaine.fr s’aligne avec votre-domaine.fr

Le mode relaxed est le défaut et convient à la plupart des configurations.

Anatomie d’un enregistrement DMARC

L’enregistrement DMARC est un enregistrement DNS de type TXT, placé à l’adresse _dmarc.votre-domaine.fr :

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@votre-domaine.fr; pct=100; adkim=r; aspf=r

Détaillons chaque paramètre :

Les paramètres obligatoires

• v=DMARC1 : identifie l’enregistrement comme DMARC (obligatoire, doit être en premier)
• p= : la politique à appliquer (obligatoire)

La politique (p=)

C’est le cœur de DMARC. Trois valeurs possibles :

• p=none : aucune action, mais collecte des rapports. C’est le mode observation.
• p=quarantine : les emails en échec doivent être traités comme suspects (généralement mis en spam)
• p=reject : les emails en échec doivent être rejetés purement et simplement

Les paramètres de reporting

• rua=mailto:adresse@domaine.fr : adresse pour recevoir les rapports agrégés (format XML, envoyés quotidiennement)
• ruf=mailto:adresse@domaine.fr : adresse pour recevoir les rapports forensiques (détails sur chaque échec individuel)

Note : tous les fournisseurs n’envoient pas de rapports ruf pour des raisons de confidentialité.

Les paramètres optionnels

• pct= : pourcentage d’emails auxquels appliquer la politique (utile pour un déploiement progressif). Par défaut : 100.
• adkim= : mode d’alignement DKIM, s (strict) ou r (relaxed). Par défaut : r.
• aspf= : mode d’alignement SPF, s (strict) ou r (relaxed). Par défaut : r.
• sp= : politique pour les sous-domaines. Par défaut : hérite de p=.
• fo= : conditions de génération des rapports forensiques (0, 1, d, s).

Les rapports DMARC : votre tableau de bord

L’un des apports majeurs de DMARC est la visibilité qu’il offre. Les rapports agrégés (RUA) vous permettent de savoir :

• Quelles adresses IP envoient des emails pour votre domaine
• Combien d’emails passent ou échouent SPF, DKIM, et l’alignement
• Quels fournisseurs de messagerie reçoivent ces emails

Format des rapports agrégés

Les rapports RUA sont des fichiers XML envoyés quotidiennement par les principaux fournisseurs (Google, Microsoft, Yahoo…). Ils ressemblent à ceci (simplifié) :

<feedback>
  <record>
    <source_ip>203.0.113.42</source_ip>
    <count>127</count>
    <policy_evaluated>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </record>
</feedback>

En pratique, ces rapports sont difficiles à lire manuellement. Des outils spécialisés les agrègent et les visualisent (nous y reviendrons au chapitre 8).

Ce que les rapports révèlent

En analysant vos rapports DMARC, vous pouvez découvrir :

• Des services légitimes que vous aviez oubliés (l’outil de ticketing qui envoie en votre nom…)
• Des tentatives d’usurpation de votre domaine
• Des problèmes de configuration (SPF ou DKIM mal paramétré pour un prestataire)

Stratégie de déploiement : la montée progressive

Un déploiement DMARC réussi se fait par étapes.

Passer directement à `p=reject` sans préparation risque de bloquer vos propres emails légitimes.

Étape 1 : Mode observation (p=none)

v=DMARC1; p=none; rua=mailto:dmarc@votre-domaine.fr

Objectif : collecter des données sans impacter la délivrabilité. Analysez les rapports pendant 2 à 4 semaines pour identifier toutes vos sources légitimes.

Étape 2 : Quarantaine progressive (p=quarantine, pct=)

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@votre-domaine.fr 

Commencez avec un faible pourcentage (10%), puis augmentez progressivement (25%, 50%, 100%) en vérifiant que vos emails légitimes ne sont pas impactés.

Étape 3 : Rejet total (p=reject)

v=DMARC1; p=reject; rua=mailto:dmarc@votre-domaine.fr; adkim=r; aspf=r

Une fois que vous avez confirmé que toutes vos sources légitimes sont correctement configurées, passez en politique de rejet. C’est l’état final qui offre la protection maximale.

Cas particulier : les sous-domaines

Par défaut, la politique DMARC s’applique aussi aux sous-domaines. Mais vous pouvez définir une politique spécifique avec le paramètre `sp=` :

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@votre-domaine.fr

Ici, le domaine principal est en rejet strict, mais les sous-domaines sont en quarantaine. Utile si vous avez des sous-domaines avec des configurations email moins matures.

Une bonne pratique de sécurité : si vous n’envoyez jamais d’emails depuis un sous-domaine, configurez-le avec p=reject pour empêcher son usurpation.

DMARC et les mailing lists : un point d’attention

Les listes de diffusion posent un défi particulier. Quand vous envoyez un email à une liste :

1. Votre email arrive sur le serveur de la liste
2. Le serveur le redistribue à tous les abonnés
3. L’IP d’envoi change (SPF échoue)
4. Le message peut être modifié (DKIM échoue si le corps est altéré)

Avec une politique DMARC stricte, vos emails aux listes de diffusion peuvent être rejetés. La solution technique existe (ARC, Authenticated Received Chain), mais son adoption reste inégale. C’est un cas à surveiller dans vos rapports.

Résumé : les trois piliers de DMARC

Pilier	Question	Réponse DMARC
Politique	Que faire si l’authentification échoue ?	none / quarantine / reject
Alignement	Le domaine visible correspond-il au domaine authentifié ?	SPF et/ou DKIM aligné
Reporting	Que se passe-t-il en mon nom ?	Rapports RUA et RUF

DMARC transforme SPF et DKIM, qui sont des mécanismes passifs, en un système actif de protection et de surveillance.

Mise en place pas à pas : de la théorie à la pratique

Vous connaissez maintenant les principes de SPF, DKIM et DMARC. Passons à l’action. Ce chapitre vous guide dans l’implémentation concrète, étape par étape, en commençant par l’inventaire de vos sources d’envoi jusqu’à la politique DMARC en mode rejet.

Étape 1 : inventorier toutes vos sources d’envoi

Avant de toucher à vos DNS, vous devez identifier tous les services qui envoient des emails en votre nom. C’est l’étape la plus importante et souvent la plus négligée.

Les sources évidentes

• Votre serveur de messagerie principal (Exchange, Google Workspace, Microsoft 365…)
• Votre serveur web (emails transactionnels : confirmations, notifications…)

Les sources souvent oubliées

• CRM et marketing : Brevo, Mailchimp, HubSpot, ActiveCampaign…
• Facturation et comptabilité : Tiime, Pennylane, QuickBooks…
• Support client : Zendesk, Freshdesk, Crisp…
• Outils internes : Notion (notifications), Slack (invitations), GitLab (notifications de CI/CD)…
• Formulaires web : si votre site envoie des emails via un SMTP externe
• Prestataires ponctuels : plateformes d’emailing pour un événement, outils RH pour le recrutement…

Comment les identifier ?

Quelques méthodes complémentaires :

• Interrogez vos équipes : marketing, commercial, RH, support technique
• Analysez vos en-têtes d’emails : envoyez-vous des emails de test et examinez les headers
• Consultez vos factures SaaS : tout outil qui vous facture un envoi d’email est une source potentielle
• Activez DMARC en mode none : les rapports révéleront les sources que vous auriez oubliées

Étape 2 : configurer SPF

Une fois l’inventaire établi, vous pouvez construire votre enregistrement SPF.

Construction de l’enregistrement

Partez de ce squelette :

v=spf1 [vos sources] -all

Ajoutez chaque source identifiée :

Source	Mécanisme à ajouter
Votre serveur (IP fixe)	ip4:203.0.113.10
Google Workspace	include:_spf.google.com
Microsoft 365	include:spf.protection.outlook.com
Brevo	include:spf.brevo.com
Mailchimp	include:servers.mcsv.net
Mailjet	include:spf.mailjet.com
OVH	include:mx.ovh.com

Remarque : chaque prestataire documente son include SPF. Consultez leur documentation ou support.

Exemple complet

Pour une entreprise utilisant Google Workspace, Brevo et un serveur dédié :

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:spf.brevo.com -all

Vérifier le nombre de lookups

Avant de publier, vérifiez que vous ne dépassez pas les 10 lookups DNS. Utilisez un outil comme MXToolbox

Si vous dépassez la limite, des techniques d’optimisation existent (aplatissement SPF, segmentation par sous-domaine).

Publication dans les DNS

Créez un enregistrement TXT à la racine de votre domaine :

Type	Nom	Valeur	TTL
TXT	@	v=spf1 ip4:... include:... -all	3600

Conseil : commencez avec ~all (soft fail) le temps de valider, puis passez à -all une fois stabilisé.

Étape 3 : configurer DKIM

La configuration DKIM varie selon que vous maîtrisez votre serveur d’envoi ou que vous utilisez un service tiers.

Cas 1 : service tiers (Google Workspace, Microsoft 365…)

Le prestataire gère la signature. Vous devez simplement publier la clé publique qu’il vous fournit.

Exemple avec Google Workspace :

1. Dans la console d’administration Google, accédez à Applications > Google Workspace > Gmail > Authentifier les emails
2. Sélectionnez votre domaine et cliquez sur Générer un nouvel enregistrement
3. Choisissez la longueur de clé (2048 bits recommandé)
4. Google vous fournit un enregistrement DNS à créer :

Type	Nom	Valeur
TXT	google._domainkey	v=DKIM1; k=rsa; p=MIIBIjANBgkq...

5. Une fois l’enregistrement publié et propagé, activez la signature dans la console Google

Exemple avec Microsoft 365 :

1. Dans le Centre d’administration Exchange, accédez à Protection > DKIM
2. Microsoft génère deux enregistrements CNAME :

Type	Nom	Valeur
CNAME	selector1._domainkey	selector1-votre-domaine-fr._domainkey.votre-tenant.onmicrosoft.com
CNAME	selector2._domainkey	selector2-votre-domaine-fr._domainkey.votre-tenant.onmicrosoft.com

3. Publiez les CNAME et activez DKIM dans l’interface

Cas 2 : serveur autogéré (Postfix, Exim…)

Vous devez installer et configurer un service de signature DKIM.

Avec OpenDKIM sur Debian :

Installation

apt install opendkim opendkim-tools

Génération d’une paire de clés

opendkim-genkey -s selector1 -d votre-domaine.fr -b 2048

Fichiers générés :

selector1.private → clé privée (à protéger)

selector1.txt → enregistrement DNS à publier

Configuration minimale dans /etc/opendkim.conf :

Domain votre-domaine.fr
KeyFile /etc/opendkim/keys/selector1.private
Selector selector1
Socket inet:8891@localhost
Canonicalization relaxed/relaxed

Intégration avec Postfix dans `/etc/postfix/main.cf` :

smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

Publiez ensuite le contenu de `selector1.txt` dans vos DNS.

Répéter pour chaque source d’envoi

Chaque prestataire qui envoie en votre nom doit signer avec votre domaine. Configurez DKIM pour chacun d’entre eux (Brevo, Mailchimp, etc.) en suivant leur documentation respective.

Étape 4 : configurer DMARC

Une fois SPF et DKIM en place, vous pouvez activer DMARC.

Commencer en mode observation

Créez un enregistrement TXT pour _dmarc.votre-domaine.fr :

v=DMARC1; p=none; rua=mailto:dmarc@votre-domaine.fr

Type	Nom	Valeur	TTL
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@votre-domaine.fr	3600

Cette configuration :

• N’impacte pas la délivrabilité (p=none)
• Vous envoie des rapports quotidiens sur tout ce qui circule en votre nom

Analyser les rapports

Attendez 1 à 2 semaines pour collecter suffisamment de données. Les rapports XML sont verbeux. Utilisez un outil dédié pour les analyser (voir chapitre 8), ou à minima un parser en ligne.

Recherchez :

• Les sources légitimes qui échouent (SPF ou DKIM mal configuré)
• Les sources inconnues qui réussissent (prestataire oublié ?)
• Les sources inconnues qui échouent (tentatives d’usurpation)

Corriger les problèmes identifiés

Pour chaque source légitime en échec :

• Échec SPF : ajoutez le mécanisme manquant dans votre enregistrement SPF
• Échec DKIM : configurez la signature DKIM pour ce prestataire
• Échec d’alignement : vérifiez que le domaine du Return-Path ou de la signature DKIM correspond à votre domaine

Passer en quarantaine progressive

Une fois les sources légitimes corrigées :

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@votre-domaine.fr

Surveillez vos rapports et augmentez progressivement le pourcentage : 25% → 50% → 100%.

Passer en rejet

Quand vous êtes confiant sur votre configuration :

v=DMARC1; p=reject; rua=mailto:dmarc@votre-domaine.fr; adkim=r; aspf=r

C’est votre configuration cible. Les emails non authentifiés et non alignés seront rejetés.

Étape 5 : sécuriser les sous-domaines inutilisés

Les attaquants peuvent usurper des sous-domaines que vous n’utilisez pas pour l’email. Protégez-les explicitement.

Pour un sous-domaine qui n’envoie jamais d’email :

SPF :

Type	Nom	Valeur
TXT	sousdomaine	v=spf1 -all

DMARC : Le sous-domaine hérite par défaut de la politique du domaine parent. Si votre domaine principal est en p=reject, les sous-domaines sont protégés.

Pour une protection explicite :

Type	Nom	Valeur
TXT	_dmarc.sousdomaine	v=DMARC1; p=reject

Récapitulatif des enregistrements DNS

Pour un domaine exemple.fr utilisant Google Workspace et Brevo :

Type	Nom	Valeur
TXT	@	v=spf1 include:_spf.google.com include:spf.brevo.com -all
TXT	google._domainkey	v=DKIM1; k=rsa; p=MIIBIjANBgkq...
TXT	brevo._domainkey	v=DKIM1; k=rsa; p=MIGfMA0GCS...
TXT	_dmarc	v=DMARC1; p=reject; rua=mailto:dmarc@exemple.fr

Checklist de déploiement

Avant de considérer votre configuration comme finalisée :

• Toutes les sources d’envoi légitimes sont inventoriées
• SPF inclut toutes les sources et ne dépasse pas 10 lookups
• DKIM est configuré et actif pour chaque source
• DMARC est en mode p=reject avec reporting activé
• Les sous-domaines inutilisés sont protégés
• Les rapports DMARC sont surveillés régulièrement
• Les tests de délivrabilité passent (mail-tester, MXToolbox)

Vérifier et monitorer : les outils indispensables

La configuration est en place, mais comment savoir si elle fonctionne ? Et comment détecter une dérive dans le temps ? Ce chapitre présente les outils essentiels pour valider votre configuration, tester votre délivrabilité, et surveiller ce qui circule au nom de votre domaine.

Outils de vérification ponctuelle

Ces outils permettent de valider votre configuration à un instant T. À utiliser après chaque modification et périodiquement pour s’assurer que tout reste en ordre.

MXToolbox

Site : https://mxtoolbox.com

MXToolbox est la référence pour diagnostiquer les configurations email. Plusieurs outils pertinents :

• SPF Record Lookup : analyse votre enregistrement SPF, compte les lookups DNS, détecte les erreurs de syntaxe
• DKIM Lookup : vérifie qu’une clé publique est bien publiée pour un sélecteur donné
• DMARC Lookup : valide la syntaxe et les paramètres de votre enregistrement DMARC
• Email Health Report : rapport complet sur la santé email de votre domaine (MX, SPF, DKIM, DMARC, blacklists…)

Astuce : l’outil SuperTool (mxtoolbox.com/supertool) permet d’enchaîner plusieurs vérifications en une seule requête. Tapez simplement votre domaine pour un diagnostic global.

Mail-tester

Site : https://www.mail-tester.com

Mail-tester adopte une approche différente : vous envoyez un vrai email à une adresse générée, et l’outil analyse tout ce qu’il reçoit.

Le rapport détaille :

• Le score de délivrabilité global (sur 10)
• La validité SPF et l’alignement
• La validité DKIM et l’alignement
• La présence et la validité DMARC
• L’analyse du contenu (mots déclencheurs de spam, ratio texte/HTML…)
• La présence sur des listes noires

C’est l’outil idéal pour tester « en conditions réelles » : il simule exactement ce que voit un serveur destinataire quand il reçoit votre email.

DMARC Analyzer (check gratuit)

Site : https://www.dmarcanalyzer.com/fr/dmarc/dmarc-record-check/

Outil simple et efficace pour valider la syntaxe de votre enregistrement DMARC et comprendre chaque paramètre. L’interface explique clairement ce que signifie votre configuration actuelle.

Google Admin Toolbox

Site : https://toolbox.googleapps.com/apps/checkmx/

Proposé par Google, cet outil vérifie la configuration MX et email d’un domaine. Particulièrement pertinent si vous utilisez Google Workspace, car il détecte les problèmes de configuration spécifiques à cet environnement.

Outils d’analyse des rapports DMARC

Les rapports DMARC agrégés (RUA) sont des fichiers XML peu lisibles à l’œil nu. Ces outils les transforment en tableaux de bord exploitables.

Solutions gratuites

DMARC Report Analyzer (dmarcian)

Site : https://dmarcian.com/dmarc-xml-parser/

Permet d’uploader manuellement un rapport XML et d’obtenir une visualisation claire. Utile pour analyser ponctuellement un rapport, mais fastidieux si vous recevez des dizaines de rapports par jour.

Postmark DMARC

Site : https://dmarc.postmarkapp.com

Service gratuit qui :

• Vous fournit une adresse dédiée pour recevoir vos rapports RUA
• Agrège et analyse automatiquement tous les rapports reçus
• Envoie un résumé hebdomadaire par email

Configuration : remplacez l’adresse dans votre enregistrement DMARC :

v=DMARC1; p=none; rua=mailto:votre-hash@dmarc.postmarkapp.com

Idéal pour démarrer : simple, gratuit, et suffisant pour la plupart des PME.

Solutions payantes (pour aller plus loin)

Pour les organisations avec des volumes importants ou des besoins avancés :

• dmarcian : tableaux de bord détaillés, historique long, alertes, accompagnement
• Valimail : automatisation de la mise en conformité, intégration enterprise
• Agari : analyse avancée des menaces, protection de marque
• OnDMARC (Red Sift) : visualisation claire, recommandations automatiques

Ces solutions se justifient quand vous gérez plusieurs domaines, de gros volumes d’envoi, ou que vous avez besoin d’un historique et d’alertes sophistiquées.

Outils de test d’envoi

Au-delà de la configuration DNS, il est utile de tester l’envoi réel depuis chaque source.

Vérifier les en-têtes d’un email reçu

Envoyez-vous un email de test, puis examinez les en-têtes complets :

• Gmail : ouvrez l’email → menu ⋮ → « Afficher l’original »
• Outlook : ouvrez l’email → Fichier → Propriétés → « En-têtes Internet »
• Thunderbird : Affichage → En-têtes → Complets

Recherchez les en-têtes d’authentification :

Authentication-Results: mx.google.com;
    spf=pass (google.com: domain of contact@votre-domaine.fr designates 203.0.113.10 as permitted sender)
    dkim=pass header.d=votre-domaine.fr
    dmarc=pass (p=REJECT sp=REJECT)

Chaque ligne doit indiquer pass. Un fail ou softfail signale un problème à corriger.

Google Postmaster Tools

Site : https://postmaster.google.com

Si une part significative de vos destinataires utilise Gmail, cet outil est précieux. Après vérification de votre domaine, vous accédez à :

• Taux de spam : pourcentage d’emails marqués comme spam par les utilisateurs Gmail
• Réputation du domaine : score global attribué par Google (High, Medium, Low, Bad)
• Réputation des IP : pour vos IP d’envoi identifiées
• Authentification : taux de succès SPF, DKIM, DMARC
• Erreurs de livraison : problèmes techniques rencontrés

Un incontournable pour surveiller votre délivrabilité vers Gmail dans la durée.

Microsoft SNDS

Site : https://sendersupport.olc.protection.outlook.com/snds/

L’équivalent Microsoft pour surveiller votre réputation auprès d’Outlook, Hotmail et Live. Moins détaillé que Google Postmaster Tools, mais utile si vous envoyez beaucoup vers des adresses Microsoft.

Alertes automatiques

Certains outils permettent de configurer des alertes :

• dmarcian / OnDMARC : alerte en cas de pic d’échecs ou de nouvelle source détectée
• UptimeRobot / Pingdom : vérification périodique de vos enregistrements DNS (alerte si supprimé ou modifié)
• Scripts personnalisés : un cron qui vérifie vos enregistrements DNS et vous alerte en cas de changement

Les erreurs courantes qui plombent votre délivrabilité

Même avec les meilleures intentions, certaines erreurs de configuration reviennent fréquemment. Elles peuvent réduire à néant vos efforts d’authentification, voire aggraver votre situation. Ce chapitre recense les pièges les plus courants et comment les éviter.

Erreurs SPF

Plusieurs enregistrements SPF

C’est l’erreur n°1. La norme est claire : un seul enregistrement SPF par domaine. Si vous avez plusieurs enregistrements TXT commençant par v=spf1, le résultat est un permerror et SPF échoue systématiquement.

Mauvais :

v=spf1 include:_spf.google.com -all
v=spf1 include:spf.brevo.com -all

Correct :

v=spf1 include:_spf.google.com include:spf.brevo.com -all

Comment ça arrive ? Souvent lors de l’ajout d’un nouveau prestataire : on crée un nouvel enregistrement au lieu de modifier l’existant. Vérifiez toujours vos DNS avant et après modification.

Dépasser la limite des 10 lookups

Chaque include:, a, mx consomme un ou plusieurs lookups DNS. Au-delà de 10, SPF échoue avec un permerror.

Symptôme : des emails légitimes sont rejetés alors que l’IP est bien dans votre SPF.

Solutions :

• Supprimer les includes inutilisés : ce prestataire que vous n’utilisez plus depuis 2 ans…
• Utiliser des IP directes : ip4: et ip6: ne consomment pas de lookup
• Aplatir le SPF : remplacer les includes par les IP qu’ils contiennent (nécessite une maintenance régulière)
• Segmenter par sous-domaine : utiliser des sous-domaines dédiés pour certains prestataires

Rester en ~all indéfiniment

Le soft fail (~all) est utile en phase de test, mais ne constitue pas une protection réelle. Les serveurs destinataires traitent le soft fail comme un simple indice, pas comme une instruction ferme.

Le problème : beaucoup d’entreprises configurent SPF avec ~all « en attendant » et n’y reviennent jamais. Des années plus tard, leur domaine reste vulnérable.

La règle : une fois votre configuration validée, passez à -all. C’est la seule façon d’indiquer clairement que les sources non autorisées doivent être rejetées.

Oublier IPv6

Votre serveur envoie peut-être en IPv6 sans que vous le sachiez. Si seule l’IPv4 est déclarée dans votre SPF, les envois IPv6 échoueront.

Vérification : consultez les en-têtes de vos emails envoyés. Si vous voyez une adresse IPv6 dans le champ Received:, ajoutez-la à votre SPF :

v=spf1 ip4:203.0.113.10 ip6:2001:db8::1 include:_spf.google.com -all

Syntaxe incorrecte

Des erreurs de syntaxe subtiles peuvent invalider tout l’enregistrement :

• Espace manquant entre les mécanismes
• Guillemets mal placés dans l’interface DNS
• Caractères invisibles copiés-collés depuis un document Word
• v=spf1 mal orthographié (vspf1, v=spf 1…)

Bonne pratique : validez systématiquement votre syntaxe avec MXToolbox après chaque modification.

Erreurs DKIM

Clé publique non publiée ou mal formatée

Vous avez configuré la signature DKIM côté serveur, mais la clé publique n’est pas (ou mal) publiée dans les DNS. Résultat : DKIM échoue systématiquement.

Causes fréquentes :

• Enregistrement DNS créé sur le mauvais domaine ou sous-domaine
• Sélecteur mal orthographié (google._domainkey vs goolge._domainkey)
• Clé tronquée (les clés 2048 bits sont longues, certains interfaces DNS les coupent)
• Guillemets ou espaces parasites dans la valeur

Bonne pratique : utilisez un service dédié (Postmark DMARC, dmarcian) pour la réception et l’analyse des rapports.

Sous-domaines non protégés

Votre domaine principal est en p=reject, mais qu’en est-il de test.votre-domaine.fr ou dev.votre-domaine.fr ?

Par défaut, les sous-domaines héritent de la politique du domaine parent. Mais si vous avez configuré sp=none ou si votre politique est mal comprise, vos sous-domaines peuvent rester vulnérables.

Les attaquants le savent : ils ciblent souvent des sous-domaines obscurs (mail2.votre-domaine.fr, old.votre-domaine.fr) que personne ne surveille.

Bonne pratique : auditez régulièrement vos sous-domaines et protégez explicitement ceux qui n’envoient pas d’email avec v=spf1 -all.

Alignement trop strict prématurément

Passer en alignement strict (adkim=s, aspf=s) avant d’avoir validé toute la chaîne peut casser des flux légitimes.

Exemple : vous envoyez depuis newsletter.votre-domaine.fr mais la signature DKIM utilise d=votre-domaine.fr. En mode relaxed, ça passe. En mode strict, l’alignement échoue.

Recommandation : restez en mode relaxed (adkim=r, aspf=r) sauf besoin spécifique de sécurité renforcée.

Erreurs organisationnelles

Ne pas documenter la configuration

Six mois après la mise en place, qui se souvient pourquoi tel include est présent dans le SPF ? Quel sélecteur DKIM correspond à quel prestataire ?

Sans documentation :

• Les modifications deviennent risquées (peur de casser quelque chose)
• Les audits sont fastidieux
• Le départ d’un collaborateur emporte le savoir

Bonne pratique : maintenez un document simple listant :

• Chaque source d’envoi et son include SPF / sélecteur DKIM
• La date de mise en place
• Le contact technique chez le prestataire

Ne pas tester après chaque modification

Un changement DNS anodin peut avoir des effets de bord inattendus. Un espace en trop, un guillemet mal fermé, et c’est toute votre authentification qui s’effondre.

Règle absolue : après chaque modification DNS liée à l’email, validez avec MXToolbox et envoyez un email de test analysé par Mail-tester.

Ignorer les rapports DMARC

Configurer rua= et ne jamais consulter les rapports, c’est comme installer une alarme et ne jamais regarder les notifications.

Les rapports DMARC vous alertent sur :

• Des prestataires oubliés qui échouent soudainement
• Des tentatives d’usurpation de votre domaine
• Des dérives de configuration (IP qui change, clé expirée…)

Minimum vital : consultez un résumé hebdomadaire, même rapide.

FAQ