Publiez SPF, activez DKIM sur chaque service d’envoi, puis ajoutez un enregistrement DMARC en mode p=none avec un flux de rapports (rua). C’est la seule séquence sûre. Une fois les rapports propres pendant plusieurs semaines, montez vers p=quarantine, puis vers p=reject.
Le piège numéro un n’est pas technique, c’est humain : oublier un expéditeur (outil marketing, CRM, passerelle de facturation) qui enverra soudain des e-mails rejetés le jour où vous passez en
p=reject.
Avant de toucher au moindre enregistrement DNS, faites l’inventaire complet des services qui envoient des e-mails au nom de votre domaine. C’est la cause la plus fréquente de blocages lors du durcissement d’une politique DMARC. Évitez ensuite deux erreurs classiques : publier plusieurs enregistrements SPF distincts (un seul est autorisé) et dépasser la limite de 10 recherches DNS imposée par le protocole, qui provoque un échec silencieux appelé permerror.
Points clés
Un déploiement SPF, DKIM et DMARC réussi repose sur l’inventaire préalable des expéditeurs et une montée progressive vers p=reject via les rapports rua.
| Point | Détails |
|---|---|
| Inventaire avant tout | Listez tous les services d’envoi (marketing, CRM, facturation) avant de modifier le DNS. |
| Un seul enregistrement SPF | Consolidez tous les expéditeurs dans un unique v=spf1, sous la limite de 10 recherches DNS. |
| DKIM par service | Générez un sélecteur distinct pour chaque plateforme signant au nom du domaine. |
| DMARC progressif | Démarrez en p=none avec rua, puis montez vers p=quarantine et p=reject. |
| Accompagnement technique | IT-Pascaud audite la configuration DNS existante et pilote la montée en politique stricte. |
Table des matières
- Spf, dkim, dmarc : à quoi sert chaque protocole ?
- Comment SPF, DKIM et DMARC s’articulent entre eux
- Quelle procédure suivre pour déployer SPF, DKIM et DMARC ?
- Comment rédiger et corriger un enregistrement SPF ?
- Comment configurer DKIM et gérer les clés de signature ?
- Comment rédiger un enregistrement DMARC et faire évoluer sa politique ?
- Comment vérifier et surveiller votre configuration ?
- Que faire face aux erreurs SPF, DKIM et DMARC les plus fréquentes ?
- Ce que l’expérience terrain change dans un déploiement DMARC
- Sécurisez la délivrabilité de vos e-mails avec un audit ciblé
- Sources
Spf, dkim, dmarc : à quoi sert chaque protocole ?
Ces trois protocoles ne font pas la même chose, et confondre leurs rôles est la première source d’erreur de configuration.
SPF (Sender Policy Framework) est un enregistrement TXT publié dans le DNS de votre domaine. Il liste les serveurs autorisés à envoyer des e-mails en votre nom. Un serveur récepteur consulte cette liste et refuse ou marque comme suspect tout message venant d’une adresse IP absente de la liste. Exemple minimal : v=spf1 include:_spf.google.com ~all.
DKIM (DomainKeys Identified Mail) fonctionne différemment : il signe cryptographiquement le contenu du message côté expéditeur. La clé publique correspondante est publiée dans le DNS sous la forme selector._domainkey.votredomaine.fr. Le serveur récepteur récupère cette clé, vérifie la signature, et s’assure que le message n’a pas été altéré en transit.
DMARC (Domain-based Message Authentication, Reporting and Conformance) chapeaute les deux. Il ne vérifie rien lui-même : il définit une politique (que faire si SPF ou DKIM échoue) et vérifie que le domaine visible dans le champ « From » correspond à celui validé par SPF ou DKIM. C’est ce qu’on appelle l’alignement.
Concrètement :
- SPF répond à la question « ce serveur a-t-il le droit d’envoyer pour ce domaine ? »
- DKIM répond à « ce message a-t-il été modifié depuis son envoi ? »
- DMARC répond à « que faire si l’un des deux échoue, et qui prévenir ? »
Ces trois protocoles combinés sécurisent le nom de domaine de l’organisation contre l’usurpation, chacun couvrant une faille que les deux autres ne voient pas, comme le rappelle l’AFNIC dans son analyse de l’authentification email.
Comment SPF, DKIM et DMARC s’articulent entre eux
Un serveur récepteur applique les vérifications dans un ordre précis. D’abord SPF, sur l’adresse technique MAIL FROM. Ensuite DKIM, sur la signature cryptographique du message. Enfin DMARC, qui regarde si l’un des deux a réussi et si le domaine validé correspond au domaine affiché dans le « From » visible par le destinataire.
Le point que beaucoup de responsables informatiques ignorent : DMARC ne demande pas que SPF et DKIM passent tous les deux. Un seul suffit, à condition qu’il soit aligné avec le domaine visible.
- L’alignement peut être strict (le domaine doit correspondre exactement) ou relaxed (un sous-domaine du domaine principal suffit).
- La plupart des déploiements utilisent l’alignement relaxed, plus tolérant aux architectures multi-domaines.
- Un message qui passe SPF mais échoue à l’alignement sera tout de même considéré comme un échec DMARC.
Un message transféré (forwarding, liste de diffusion) casse presque toujours SPF, parce que le serveur relais n’est pas dans votre liste autorisée. DKIM survit souvent à ce transfert puisque la signature reste attachée au contenu. C’est pour cette raison que DKIM est le mécanisme le plus robuste face aux forwards, et que des protocoles complémentaires comme SRS ou ARC existent pour préserver l’authentification quand un message transite par un tiers.
La terminologie précise de ces mécanismes est fixée par trois documents de référence : le RFC 7208 pour SPF, le RFC 6376 pour DKIM et le RFC 9989 pour DMARC, qui définit les tags d’alignement et la syntaxe des politiques.
Quelle procédure suivre pour déployer SPF, DKIM et DMARC ?
Le déploiement se fait en cinq étapes, jamais dans le désordre. Sauter une étape, notamment l’inventaire, est ce qui casse la production le jour du passage en p=reject.
- Inventoriez tous les expéditeurs. Listez chaque plateforme qui envoie des e-mails pour votre domaine : outil marketing, CRM, serveur de facturation, passerelle de support, serveurs internes. Un outil marketing oublié est la cause numéro un de blocage lors du durcissement.
- Publiez un enregistrement SPF consolidé. Un seul enregistrement
v=spf1qui regroupe tous les expéditeurs identifiés, avec un~all(soft fail) pour commencer. - Activez DKIM sur chaque service. Générez les clés, publiez les sélecteurs correspondants, et vérifiez que chaque plateforme signe correctement ses messages.
- Publiez DMARC en mode
p=none. Ajoutez une adresseruapour recevoir les rapports agrégés. Laissez tourner ce mode plusieurs semaines pour observer sans rien bloquer. - Montez progressivement la politique. Passez à
p=quarantineavec unpctréduit (par exemple 10 %), puis augmentez, avant de basculer surp=reject.
La durée par phase varie selon le volume d’e-mails et le nombre d’expéditeurs à coordonner. Une petite entreprise avec quelques outils peut aller plus vite ; un groupe avec plusieurs filiales et prestataires marketing doit consacrer plus de temps à la phase de surveillance.
Conseil de pro : Prévenez l’équipe marketing avant de toucher au moindre enregistrement. Ce sont souvent leurs outils d’envoi (newsletters, campagnes automatisées) qui se retrouvent bloqués en premier, et c’est rarement l’informatique qui le découvre en premier.
Si vous gérez également la zone DNS de votre hébergement, notre guide de configuration de nom de domaine détaille comment éditer un enregistrement TXT sans casser les autres services déjà en place.
Comment rédiger et corriger un enregistrement SPF ?
L’enregistrement SPF se publie comme un simple TXT à la racine du domaine. Pour Google Workspace, l’exemple type est v=spf1 include:_spf.google.com ~all. Si vous ajoutez un serveur de facturation en plus, vous étendez le même enregistrement, vous n’en créez pas un second : v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 ~all.
- Un domaine ne peut avoir qu’un seul enregistrement
v=spf1. Deux enregistrements distincts invalident systématiquement la vérification SPF. - Chaque
include,a,mx,ptr,existsetredirectconsomme une recherche DNS. La limite fixée par le RFC 7208 est de 10 recherches au total, au-delà, le résultat devient unpermerror. - Les grandes organisations avec de nombreux expéditeurs consolident leurs
includeou utilisent des services d’aplatissement SPF (flattening) qui remplacent une chaîne d’includes par une liste directe d’adresses IP.
Pour diagnostiquer un permerror, utilisez dig TXT votredomaine.fr ou un vérificateur SPF en ligne, comptez le nombre de lookups déclenchés par chaque mécanisme, et fusionnez les include redondants. La limite des 10 recherches DNS est souvent invisible tant que personne n’ajoute un nouvel outil d’envoi, ce qui en fait un bug qui apparaît des mois après le déploiement initial.
Conseil de pro : Documentez chaque ajout d’expéditeur dans un fichier partagé avec la date et le nombre de lookups qu’il consomme. C’est le seul moyen de repérer avant coup que vous approchez de la limite.
Comment configurer DKIM et gérer les clés de signature ?
DKIM demande trois actions : générer une paire de clés, installer la clé privée sur votre serveur d’envoi (ou activer la fonction chez votre fournisseur), et publier la clé publique dans le DNS sous la forme selector._domainkey.votredomaine.fr.
Le nom du sélecteur suit rarement une norme unique. Certains fournisseurs imposent leur propre convention (google._domainkey, s1._domainkey), d’autres vous laissent choisir librement (selector1, mail2024). Notez chaque sélecteur actif dans votre documentation interne, surtout si plusieurs plateformes signent pour le même domaine.
- Privilégiez une clé de 2048 bits quand la plateforme le permet ; une clé de 1024 bits reste fonctionnelle mais offre une marge de sécurité plus faible.
- Prévoyez une rotation régulière des clés, avec un plan de retour en arrière si la nouvelle clé pose un problème de propagation DNS.
- Vérifiez la signature dans l’en-tête
DKIM-Signaturede vos messages envoyés, via un client mail en mode « afficher la source » ou un vérificateur en ligne.
Conseil de pro : Si plusieurs services signent au nom du même domaine (envoi transactionnel, marketing, support), utilisez un sélecteur distinct par service. Cela permet de révoquer la clé d’un seul outil sans casser la signature des autres.
Une signature DKIM mal configurée n’est presque jamais visible immédiatement, elle échoue seulement quand un serveur intermédiaire modifie le contenu du message (ajout d’un pied de page, reformatage), ce qui casse l’intégrité vérifiée par la signature.
Comment rédiger un enregistrement DMARC et faire évoluer sa politique ?
L’enregistrement DMARC se publie en TXT sous _dmarc.votredomaine.fr. Un point de départ prudent ressemble à ceci : v=DMARC1; p=none; rua=mailto:rapports@votredomaine.fr; sp=none; pct=100.
Chaque tag a un rôle précis :
pdéfinit la politique appliquée aux messages échouant l’alignement :none(aucune action, observation pure),quarantine(mis en spam), oureject(rejeté).ruaindique l’adresse qui recevra les rapports agrégés quotidiens, la base de votre analyse.rufdéclenche des rapports forensiques détaillés par message, rarement utilisés en pratique à cause du volume et de la sensibilité des données transmises.pctfixe le pourcentage de messages concernés par la politique, utile pour monter en charge progressivement (pct=10puispct=50avantpct=100).adkimetaspfdéfinissent le mode d’alignement, strict (s) ou relaxed (r), pour DKIM et SPF respectivement.spapplique une politique distincte pour les sous-domaines, utile si un sous-domaine sert à des usages différents (tests, plateforme marketing séparée) et ne doit pas hériter automatiquement de la politique du domaine principal.
Il est recommandé de démarrer en p=none avec rua actif, d’analyser les rapports pendant plusieurs semaines, puis de monter vers p=quarantine avant p=reject, comme le détaille le guide de configuration de Proofpoint. Publier DMARC, même en p=none, bloque déjà une partie des tentatives d’usurpation grossières tout en construisant la visibilité nécessaire pour durcir sans casser vos propres envois.
Comment vérifier et surveiller votre configuration ?
La vérification passe par deux canaux : les outils en ligne de commande et la lecture des rapports DMARC.
dig TXT votredomaine.fretdig TXT selector._domainkey.votredomaine.frconfirment que vos enregistrements SPF et DKIM sont bien publiés et lisibles.- Les vérificateurs en ligne (SPF, DKIM, DMARC) simulent une vérification côté serveur récepteur et signalent les erreurs de syntaxe avant qu’elles ne causent un vrai rejet.
- Les collecteurs de rapports DMARC parsent automatiquement les fichiers XML envoyés par
ruaet les transforment en tableaux lisibles, plutôt que de les ouvrir manuellement.
Dans l’en-tête technique d’un message reçu, le champ Authentication-Results affiche le verdict de chaque protocole : spf=pass, dkim=pass, dmarc=pass (ou fail). C’est le premier endroit à consulter quand un destinataire signale un message classé en spam.
Un calendrier de surveillance simple fonctionne bien :
- Analyse quotidienne des rapports
ruapendant toute la phasep=none. - Synthèse hebdomadaire pour repérer les expéditeurs récurrents en échec.
- Vérification systématique avant et après chaque changement de fournisseur d’envoi (nouveau CRM, nouvel outil marketing).
Conseil de pro : Automatisez le tri des rapports dès la phase p=none. Lire des fichiers XML à la main devient vite ingérable au-delà de quelques dizaines d’e-mails par jour.
Que faire face aux erreurs SPF, DKIM et DMARC les plus fréquentes ?
Les blocages viennent presque toujours des mêmes causes, faciles à corriger une fois identifiées.
- Permerror SPF : comptez vos lookups avec un outil de diagnostic, remplacez les
includenon essentiels par desip4/ip6directs quand c’est possible. - Enregistrements SPF multiples : fusionnez-les en un seul
v=spf1, un domaine ne doit jamais en publier deux. - Signature DKIM invalide : vérifiez le nom exact du sélecteur, le TTL de propagation DNS et l’encodage de la clé publique copiée depuis votre fournisseur.
- DMARC qui bloque des e-mails légitimes : repassez temporairement en
p=none, identifiez l’expéditeur manquant dans les rapportsrua, corrigez SPF ou DKIM pour ce service, puis remontez la politique. - Messages transférés qui échouent : c’est un cas connu où SPF casse structurellement ; DKIM compense généralement, et des mécanismes comme SRS ou ARC existent pour les scénarios de transfert répété, comme le documente Microsoft dans son guide d’authentification email.
Aucun de ces protocoles ne remplace une protection anti-malware classique : ils réduisent l’usurpation de domaine, pas les menaces transportées dans les pièces jointes ou les liens malveillants, comme le rappelle Check Point dans son explication de l’authentification email.
Ce que l’expérience terrain change dans un déploiement DMARC
Sur le papier, SPF, DKIM et DMARC forment une checklist DNS de trois lignes. En pratique, l’obstacle n’est presque jamais technique, il est organisationnel : personne dans l’entreprise ne sait exactement combien de services envoient des e-mails en son nom. Un ancien outil de facturation abandonné depuis deux ans, un plugin CRM configuré par un stagiaire parti depuis longtemps, une plateforme d’événements utilisée une fois par an, tous ces expéditeurs oubliés se rappellent brutalement à vous le jour où vous passez en p=reject.
C’est là qu’un accompagnement technique fait la différence : IT-Pascaud audite la zone DNS existante, identifie les expéditeurs actifs et dormants, génère et publie les clés DKIM pour chaque plateforme, configure l’enregistrement DMARC en mode surveillance, puis suit les rapports jusqu’à ce que la politique stricte devienne sans risque. Basée au Mans, l’agence accompagne des PME et associations qui n’ont ni le temps ni l’équipe interne pour suivre ce type de projet DNS jusqu’au bout, un projet qui échoue rarement sur la technique et souvent sur l’abandon en cours de route.
Sécurisez la délivrabilité de vos e-mails avec un audit ciblé
Un domaine mal configuré au niveau SPF, DKIM et DMARC laisse la porte ouverte à l’usurpation, et pénalise directement la délivrabilité de vos campagnes légitimes. IT-Pascaud propose un audit d’authentification email qui part de votre configuration DNS actuelle, identifie les manques (SPF absent, DKIM non signé, DMARC inexistant ou trop permissif) et construit un plan d’action concret pour chaque expéditeur identifié.
L’accompagnement inclut la génération des clés DKIM, la rédaction des enregistrements DNS, la mise en place de la collecte de rapports DMARC et le suivi jusqu’à la politique stricte. Le bénéfice concret pour vos équipes : moins d’e-mails classés en spam par erreur, une meilleure réputation d’envoi auprès des grands fournisseurs, et une protection réelle contre les tentatives de phishing usurpant votre domaine. Consultez notre page services de création et sécurisation de site internet pour démarrer un audit préalable avant toute modification DNS, une étape que nous recommandons systématiquement avant de toucher aux enregistrements existants.
Sources
Pour valider vos enregistrements avant chaque changement DNS majeur, gardez ces références sous la main :
- Protégez vos e‑mails grâce au DNS : SPF, DKIM, DMARC (AFNIC)
- RFC 9989 — DMARC (Internet Standards Track)
- SPF, DKIM and DMARC: Setup Guide (Proofpoint)
- Email authentication for Microsoft 365 (Microsoft Docs)
Recommandation
- Configurer un nom de domaine : guide PME 2026 – IT-Pascaud
- IT-Pascaud: Actualités
- Tutoriel hébergement web : réussir votre site professionnel – IT-Pascaud
