Comment configurer correctement SPF, DKIM et DMARC dans Plesk ?

Dans ce guide, je te montre étape par étape comment SPF DKIM et DMARC dans Plesk afin que tes e-mails soient authentifiés de manière fiable. Tu obtiendras des procédures claires pour les enregistrements DNS, les commutateurs Plesk et les méthodes de test qui te permettront d'améliorer la délivrabilité et de bloquer les expéditeurs abusifs.

Points centraux

• SPF détermine quels systèmes sont autorisés à envoyer du courrier pour ton domaine.
• DKIM signe les messages sortants et les protège contre les manipulations.
• DMARC relie SPF/DKIM aux directives et aux rapports.
• Plesk fournit des assistants et des modèles DNS pour un démarrage rapide.
• Suivi des rapports DMARC aiguise ta politique dans l'entreprise.

Vérifier les conditions préalables dans Plesk

Avant de définir les paramètres, je vérifie le serveur de messagerie utilisé en Plesk et la gestion du DNS. Sous Linux, je travaille généralement avec Postfix, sous Windows avec SmarterMail, car ces services fournissent des fonctions SPF, DKIM et DMARC. Je contrôle en outre si le domaine gère ses zones DNS dans le DNS de Plesk ou s'il se trouve chez un fournisseur externe, car je peux alors enregistrer les entrées en dehors de Plesk doit être complété. Pour un fonctionnement sans problème, je garde le nom d'hôte, le Reverse DNS et les certificats TLS valides propres, car les serveurs de distribution vérifient ces points. Une base de départ propre permet d'économiser beaucoup de temps par la suite et renforce le Réputation.

Configurer SPF dans Plesk - étape par étape

Pour le démarrage, j'ouvre "Outils et paramètres" → "Paramètres DNS" et je recherche un enregistrement TXT commençant par v=spf1 commence à être utilisé. S'il manque, je le mets, par exemple : v=spf1 a mx include:yourmailprovider.de -allpour que les systèmes autorisés puissent envoyer des messages et que tous les autres soient bloqués. Si le domaine utilise des expéditeurs supplémentaires tels que Microsoft 365, Google Workspace ou des services de newsletter, j'ajoute les adresses appropriées. include-de leur documentation. Après l'enregistrement, je compte jusqu'à 48 heures pour que la modification ait un effet global et je teste l'enregistrement avec un vérificateur SPF via un e-mail de test envoyé à une boîte aux lettres sélectionnée. Tu trouveras une présentation compacte de l'interaction des mécanismes dans le guide compactLe site web de la Commission européenne présente les principaux scénarios.

Activer DKIM dans Plesk - voici comment procéder

Pour DKIM je vais dans "Outils & paramètres" → "Paramètres du serveur de messagerie" et j'active l'option permettant de signer les e-mails sortants. Ensuite, au niveau du domaine, j'ouvre "Sites & Domaines" → Domaine → "Mail" → "Paramètres" et je vérifie si la signature est activée par domaine. Si je gère le DNS en externe, j'exporte les informations fournies par Plesk et je les inscris comme enregistrements TXT auprès du fournisseur DNS (attention aux noms des sélecteurs). Après 24-48 heures au maximum, les destinataires devraient valider les signatures DKIM, ce que je confirme en envoyant un e-mail test à une boîte de vérification DKIM ou en effectuant une vérification des en-têtes. Une signature valide renforce Délivrabilité perceptible.

Définir la politique DMARC et utiliser les rapports

Maintenant, je mets DMARC sous forme d'enregistrement TXT sur _dmarc.tondomaine.tld avec la valeur v=DMARC1 ; p=quarantine ; rua=mailto:[email protected] ; ruf=mailto:[email protected] ; adkim=s ; aspf=s. Les tags p, rua et appel gèrent la politique et le reporting, tandis que adkim/aspf définir l'orientation stricte (strict). Dans la pratique, je commence souvent par p=noneJ'évalue les rapports pendant deux à quatre semaines, puis je passe à l'étape suivante. quarantaine ou rejeter s'affiche. Les rapports montrent quels systèmes envoient des mails en ton nom et où SPF ou DKIM échouent, ce qui permet des corrections directes. Une séquence d'étapes plus approfondie décrit Mise en œuvre de DMARC avec des exemples concrets.

Propagation du DNS, tests et meilleures pratiques

Toute modification de l'ADN prend du temps, c'est pourquoi je prévois jusqu'à 48 heures pour les changements mondiaux. Propagation est lancée. Durant cette phase, j'envoie des e-mails de test à des boîtes aux lettres externes et je vérifie les résultats d'authentification dans l'en-tête pour spf=pass, dkim=pass et dmarc=pass. Si un mail reçoit un softfail ou neutreje contrôle les mécanismes SPF, les sélecteurs DKIM et l'alignement de l'Envelope-From (Return-Path) sur From :. Lors de l'utilisation de redirections, j'observe les résultats de DMARC, car SPF s'y brise souvent ; DKIM compense en général. J'évite ~all et, pour les configurations productives, mise systématiquement sur des -tout.

Balises et valeurs DMARC - tableau compact

J'utilise l'aperçu suivant pour DMARC paramétrer rapidement et de manière résiliente et éviter les erreurs d'interprétation. Je garde les valeurs cohérentes sur les domaines et sous-domaines principaux et je documente les modifications de manière compréhensible. Pour les domaines productifs, j'applique un alignement strict et j'active toujours les rapports d'agrégation. Rapports médico-légaux (appel), je les planifie conformément à la protection des données. En fixant des directives claires, on stabilise Réputation du domaine de manière durable.

Jour	Signification	Valeurs possibles	Recommandation
p	Politique du domaine principal	none, quarantine, reject	Démarrer avec none, puis augmenter à reject
sp	Politique des sous-domaines	none, quarantine, reject	sp=reject pour les configurations de production
rua	Rapports d'agrégation	mailto:adresse	Utiliser sa propre adresse de reporting
appel	Rapports médico-légaux	mailto:adresse	Activer uniquement si nécessaire
adkim	Alignement DKIM	r (relaxé), s (strict)	adkim=s pour une attribution claire
aspf	Alignement SPF	r (relaxé), s (strict)	aspf=s pour réduire les fausses alertes
pct	Pourcentage d'application	0-100	Serrage progressif avec pct

Intégrer des expéditeurs externes : Microsoft 365, Google, services de newsletter

Si un domaine utilise des chemins d'expédition supplémentaires, je complète les includes SPF pour Microsoft 365, Google Workspace, Mailgun, SendGrid ou les outils de newsletter exactement comme documenté. Pour chaque service, je vérifie si une clé DKIM propre est active et si le domaine From est vraiment signé. J'évite les doublons ou les trop nombreux include-cascades, car SPF est limité à dix lookups DNS. Si le budget des lookups n'est pas suffisant, je consolide les émetteurs ou je déplace certains flux vers des sous-domaines avec leur propre politique DMARC. De cette manière, je garde SPF allégé et je sécurise les Signatures à partir de

Contrôles approfondis et choix du serveur

Pour les e-mails entrants, j'active dans Plesk la vérification de SPF, DKIM et DMARC, afin que le serveur filtre rapidement les spams. Sur Linux, ces contrôles sont disponibles par défaut, tandis que sur Windows, la mise en œuvre se fait avec SmarterMail. Je veille à ce que les mises à jour du serveur de messagerie soient propres, afin que les routines de signature et l'analyseur syntaxique restent à jour. En cas de problèmes de faux positifs, j'adapte les seuils de scoring, mais jamais les Politique de son propre domaine. C'est ainsi que je maintiens un niveau de protection élevé et que je garantis la livraison d'expéditeurs légitimes.

Erreurs fréquentes et solutions rapides

Si un "SPF permerror", il y a généralement une erreur de syntaxe ou la limite de recherche a été dépassée. Si DKIM échoue, je contrôle le sélecteur, l'enregistrement de la clé publique et la fin de la valeur TXT avec des guillemets corrects. Si DMARC échoue failje vérifie d'abord l'alignement : From-Domain, Return-Path et DKIM-d= doivent correspondre. Si SPF s'interrompt lors de redirections, je me fie à DKIM et maintenir le statut de la signature stable. Avec cet ordre, je résous la plupart des problèmes de distribution sans avoir à chercher longtemps.

Modèles DNS et automatisation dans Plesk

Si je gère un grand nombre de domaines, j'utilise l'attribut Modèle DNS dans Plesk et j'y dépose des enregistrements standard pour SPF, DKIM et DMARC. Les nouveaux domaines reçoivent ainsi immédiatement des valeurs par défaut solides qu'il me suffit d'affiner. J'applique également les modifications prévues, comme un DMARC plus strict, à l'ensemble du domaine via des modèles et des scripts. Pour les rotations des clés DKIM, je travaille avec deux sélecteurs afin de pouvoir changer progressivement. Ainsi, le fonctionnement reste cohérent sur des dizaines de domaines et maintenable.

Evaluer les rapports DMARC et renforcer la politique

Après la mise en service, j'évalue quotidiennement les rapports d'agrégation et j'identifie Sourcesqui envoient des messages sans autorisation au nom du domaine. Je bloque les IP inattendues et nettoie les outils obsolètes avant d'affûter la politique. Le changement de p=none à l'adresse suivante : quarantaine et plus tard sur rejeter j'exécute avec pct par étapes, afin de mesurer les effets de manière contrôlée. Si des expéditeurs légitimes apparaissent dans le rapport "Échec", je corrige les inclusions SPF ou j'active ma propre clé DKIM. Cette routine renforce la Réputation visible et réduit le spoofing.

Comprendre correctement l'alignement (alignment)

Avec cela, DMARC je veille à ce que l'alignement soit correct. Sur SPF compte le domaine dans l'Envelope-From (Return-Path) ou l'identité HELO/EHLO, qui doit correspondre au domaine From visible (strict : identique, relaxed : même domaine d'organisation). Pour DKIM je vérifie le d=-Attribut de la signature : il doit pointer vers le même domaine (strict) ou vers le même domaine d'organisation (relaxed). Dans la pratique, je m'assure que :

• le chemin de rebond utilisé (chemin de retour) utilise un domaine qui correspond au domaine From ou est délibérément transféré sur un sous-domaine avec sa propre politique DMARC,
• tous les fournisseurs tiers le domaine From signer (DKIM), et pas seulement leur propre domaine d'expédition,
• lors des retransmissions, la signature DKIM reste intacte pour compenser les ruptures de SPF

En cas d'absence d'alignement, les récepteurs DMARC signalent une erreur malgré un SPF/DKIM valide. dmarc=fail. C'est pourquoi je vérifie dans les en-têtes des e-mails les champs Résultats de l'authentification, Chemin de retour et les paramètres DKIM. Je vois ainsi rapidement si c'est SPF ou DKIM qui fournit l'alignement et où je dois faire des améliorations.

Gestion des clés et paramètres DNS

Pour les DKIM-j'ai opté pour des clés de 2048 bits. Dans Plesk je peux définir la longueur de la clé par domaine ; j'augmente rapidement les anciennes clés de 1024 bits. Si nécessaire, je divise les longs enregistrements DKIM-TXT en plusieurs segments entre guillemets pour que le serveur DNS les délivre correctement. En outre, je définis des TTL-valeurs de temps : Dans les phases de déploiement, je passe à 300-900 secondes, en production j'utilise 1-4 heures. Ainsi, je réagis de manière flexible aux changements sans trop charger les caches.

Le Rotation je le fais sans défaillance avec deux sélecteurs :

1. Créer un nouveau sélecteur dans Plesk et publier la clé publique sous forme de TXT dans le DNS.
2. Changer l'expéditeur pour le nouveau sélecteur et observer le monitoring (montrer l'en-tête) s=nouveau sélecteur).
3. Lorsque tous les flux ont été modifiés, supprimer l'ancien sélecteur dans le DNS et le désactiver dans Plesk.

Pour les fournisseurs tiers, je les utilise lorsque c'est possible, délégué les enregistrements DKIM (par exemple, CNAME sur le sélecteur du fournisseur). Ainsi, je garde le contrôle dans ma zone et je fais tourner les clés sans risquer des ruptures opérationnelles.

les cas spéciaux : Redirections, listes de diffusion et passerelles

Dans des environnements réels, je vois régulièrement des redirections, des listes de diffusion ou des passerelles de sécurité qui réécrivent les courriers. Dans ce cas, je suis particulièrement attentif aux conséquences :

• RedirectionsSPF se casse souvent parce que l'IP de redirection ne figure pas dans le SPF du domaine expéditeur. Je me fie ici à DKIMqui fournit la protection du contenu. Si la signature reste inchangée, DMARC existe via l'alignement DKIM.
• Listes de diffusionDe nombreuses listes modifient le sujet ou le pied de page et rompent ainsi la signature DKIM. Dans de tels cas, je planifie l'alignement relatif et je vérifie si la liste utilise SRS/ARC ou ses propres signatures. Si possible, j'utilise un sous-domaine avec sa propre politique DMARC pour les listes.
• Passerelles de sécuritéLes passerelles qui re-signent les messages ou réécrivent l'Envelope-From doivent être correctement alignées sur le domaine de l'expéditeur. Je documente leur rôle et les ancre dans le SPF (ip4/ip6) ou via include pour que l'alignement soit maintenu.

Rencontrer des mails avec spf=fail par un transfert, ce n'est pas automatiquement critique, tant que dkim=pass et que l'alignement DKIM est correct. J'évalue l'ensemble des Authentication-Results au lieu d'isoler chaque signal.

IP partagées, HELO/EHLO et rDNS

Si plusieurs domaines partagent la même IP sortante, je mise sur une connexion propre. rDNS et des noms HELO/EHLO cohérents. Le pointeur inverse pointe vers un FQDN (par exemple mail.hosting-example.tld), dont l'enregistrement A renvoie à la même IP. Le MTA répond avec exactement le même nom. Je veille à ce que le Certificat SMTP-TLS correspond au nom HELO (SNI, si plusieurs noms sont servis). Pour chaque domaine expéditeur, je m'assure en outre que SPF/DKIM/DMARC sont entièrement et correctement alignés - l'IP commune seule n'affecte pas DMARC tant que l'authentification est efficace.

Pour les expéditeurs dédiés (p. ex. e-mail transactionnel vs marketing), j'aime bien séparer les deux via des sous-domaines et des IP propres en option. Cela aide à Gestion de la réputationL'utilisation de l'outil DMARC, qui simplifie l'analyse des rapports DMARC et minimise les interférences, permet d'améliorer la qualité des rapports.

Monitoring et déploiement dans la pratique

Pour assurer un fonctionnement sans faille, je combine des activités Analyse DMARC avec des étapes de déploiement claires :

• Ligne de base2-4 semaines p=none, collecter tous les rapports d'agrégation (rua), identifier les sources d'erreur.
• Nettoyage: supprimer les expéditeurs non autorisés, nettoyer les inclusions SPF, activer DKIM sur tous les systèmes légitimes.
• Mettre: Avec pct progressivement à quarantaine, plus tard sur rejeter augmenter, mesurer les effets en pourcentage.
• Alerte: définir des seuils (nouvelles IP, taux d'échec par fournisseur, nouveaux domaines From) et mettre en place des notifications.
• Documentation: garder les sélecteurs, le TTL, les durées d'exécution des clés, le budget SPF et les responsabilités sous contrôle de version.

Je vérifie chaque semaine le Budget de recherche SPF (max. 10 mécanismes avec requêtes DNS) et consolide les inclusions. Les mécanismes critiques comme ptr ou +tout je n'utilise pas de produits chimiques ; ip4/ip6, a, mx et ciblées include restent les moyens de choix. C'est ainsi que je garde la configuration stable et auditable.

Vérification rapide pour chaque domaine

A la fin de chaque établissement, je fais une course fixe Vérifier par : Enregistrement SPF présent, budget de recherche inférieur à dix, mécanismes correctement triés, -tout active. Signature DKIM valide, sélecteur documenté, longueur de clé suffisante, rotation prévue. DMARC avec enregistrement TXT valable, alignement strict, boîtes aux lettres de reporting accessibles et archivées. Afficher les e-mails de test spf=pass, dkim=pass et dmarc=pass dans l'en-tête. Cet ordre me permet de conserver des configurations reproductibles et avec peu d'erreurs.

Résumé de la pratique pour un succès rapide

Je démarre chaque projet avec des objectifs clairs NormesSPF : maintenir le SPF au plus bas, activer DKIM pour chaque expéditeur et déployer DMARC avec reporting. Ensuite, deux à quatre semaines de monitoring permettent d'éliminer les points aveugles et de mettre en place des directives. J'intègre des services externes de manière contrôlée, je documente les inclusions et je contrôle le budget de recherche. J'utilise des modèles DNS pour plusieurs domaines et je planifie des rotations de clés DKIM pour que les signatures restent fraîches. Je résume des idées pratiques utiles et des conseils de dépannage dans mes "conseils de dépannage". Conseils Plesk 2025 pour que tu puisses avoir une forte Délivrabilité tu atteindras.