SPF, DKIM et DMARC avec l'hébergement CURIAWEB

SPF, DKIM et DMARC font partie des procédures les plus importantes pour l'authentification des e-mails. Ils aident les serveurs de messagerie récepteurs à évaluer si un message a effectivement été envoyé par des systèmes autorisés et si le domaine d'expéditeur utilisé correspond au message.

Avec un hébergement CURIAWEB normal, les enregistrements DNS nécessaires pour SPF, DKIM et DMARC sont par principe configurés automatiquement. Si vous envoyez vos e-mails exclusivement via l'infrastructure de messagerie habituelle de CURIAWEB et que la zone DNS est gérée chez CURIAWEB, vous n'avez normalement pas besoin de créer ces enregistrements vous-même.

Important : Ne modifiez pas les enregistrements SPF, DKIM ou DMARC au hasard. Une mauvaise configuration peut empêcher les e-mails légitimes de passer leur authentification, ce qui nuit à leur délivrabilité ou entraîne leur classement comme spam.

Que font SPF, DKIM et DMARC ? #

Les trois procédés remplissent des fonctions différentes et se complètent mutuellement.

Procédure	Tâche
FPS	Détermine quels serveurs ou adresses IP sont autorisés à envoyer des e-mails pour un domaine.
DKIM	Appose aux messages sortants une signature cryptographique qui peut être vérifiée via une clé publique dans le DNS.
DMARC	Associe SPF et DKIM au domaine d'expédition visible et publie une politique pour la vérification DMARC.

En termes simples, l'interaction peut se présenter ainsi :

E-mail sortant
       ↓
SPF
Le chemin d'envoi est-il autorisé ?
       +
DKIM
La signature cryptographique est-elle valide ?
       ↓
DMARC
Au moins une authentification réussie correspond-elle au domaine d'expédition visible ?
       ↓
Appliquer la politique DMARC

SPF avec l'hébergement CURIAWEB normal #

FPS représente Sender Policy Framework. L'enregistrement SPF est publié en tant qu'enregistrement TXT dans le DNS d'un domaine.

Avec un hébergement CURIAWEB normal, l'enregistrement SPF est créé automatiquement dans la zone DNS.

Une configuration standard typique de CURIAWEB ressemble par exemple à ceci :

v=spf1 +a +mx +ip4:144.76.63.89 ~all

Les différents composants ont des fonctions différentes :

composant	Sens
v=spf1	Marque l'enregistrement TXT comme version SPF 1.
+a	Autorisez les systèmes déterminés par le mécanisme A.
+mx	Autorisez les systèmes déterminés via les enregistrements MX du domaine.
+ip4:144.76.63.89	Autoriser cette adresse IPv4 pour l'envoi.
~tous	Les autres sources d'expédition non enregistrées au préalable reçoivent un softfail SPF.

Important : L'enregistrement SPF présenté ici est un exemple de configuration d'hébergement CURIAWEB normale. Ne le copiez pas sur un autre domaine ou dans un autre environnement d'hébergement sans vérifier au préalable le chemin d'acheminement réel des e-mails.

Que signifie ~tous? #

Das ~ avant tous désigne dans SPF un Échec partiel.

Par conséquent, le domaine indique que les systèmes qui ne sont pas pris en compte par les mécanismes précédents ne sont pas censés être des sources d'expédition régulières. Cependant, le traitement final d'un tel message relève du système destinataire et de ses contrôles ultérieurs.

Cela se distingue par exemple de :

-tous

Le signe moins désigne un SPF Échec.

Vous ne devez donc pas simplement modifier un enregistrement SPF existant à partir de ~tous sur -tous modifier. Une politique plus stricte n'a de sens que si l'ensemble de l'environnement d'expédition est connu et correctement pris en compte.

DKIM pour l'hébergement CURIAWEB #

DKIM représente DomainKeys Identified Mail.

Alors que SPF autorise le chemin d'acheminement, DKIM fonctionne avec une signature cryptographique.

En termes simplifiés, DKIM se compose de deux parties :

Clé DKIM privée
→ se trouve sur le système émetteur
→ signe le courrier électronique sortant

Clé DKIM publique
→ est publiée dans le DNS
→ permet au destinataire d'effectuer la vérification

La clé privée ne doit pas être accessible au public. Seule la partie publique se trouve dans le DNS.

À quoi ressemble un enregistrement DKIM ? #

DKIM utilise un soi-disant Sélecteur. Cela permet à un domaine d'utiliser différentes clés DKIM et de remplacer les clés ultérieurement.

Un nom DNS DKIM suit fondamentalement ce schéma :

selector._domainkey.example.ch

L'enregistrement TXT correspondant contient entre autres la clé publique.

Schématiquement, un enregistrement DKIM ressemble par exemple à ceci :

v=DKIM1; k=rsa; p=PUBLIC_KEY

La clé publique réelle est nettement plus longue et est générée automatiquement pour le domaine concerné.

Attention : N'utilisez jamais la clé DKIM d'un autre domaine et ne copiez pas d'enregistrements DKIM entre domaines. Chaque paire de clés appartient à la configuration DKIM spécifique du domaine.

Normalement, tu n'as pas besoin de créer DKIM toi-même. #

Dans le cadre d'une configuration d'hébergement CURIAWEB standard, DKIM est configuré automatiquement.

Par conséquent, si votre domaine utilise la zone DNS CURIAWEB et que les e-mails sont envoyés via l'infrastructure de messagerie prévue à cet effet, vous ne devez pas créer en plus votre propre enregistrement DKIM.

Plusieurs sélecteurs DKIM sont techniquement tout à fait possibles. Ils ne devraient cependant être présents que si les systèmes d'envoi correspondants signent effectivement avec ces clés de sélecteur.

Que vérifie DKIM ? #

Lors de l'envoi, le message est signé avec la clé privée DKIM. Le serveur de messagerie récepteur lit, entre autres, le domaine utilisé et le sélecteur à partir de la signature DKIM.

Grâce à ce sélecteur, il peut récupérer la clé publique correspondante dans le DNS et vérifier la signature.

Un résultat DKIM réussi peut par exemple être :

dkim=pass

apparaître dans les résultats d'authentification d'un message reçu.

Que signifie une erreur DKIM ? #

Une erreur DKIM peut avoir différentes causes. Par exemple, la clé publique peut être manquante, un mauvais sélecteur peut être utilisé ou le message ou les composants signés pertinents peuvent avoir été modifiés après la signature de telle sorte que la signature ne puisse plus être validée avec succès.

Une erreur DKIM doit donc être étudiée à l'aide du message concret et de son chemin d'acheminement.

DMARC pour l'hébergement CURIAWEB #

DMARC représente Domain-based Message Authentication, Reporting and Conformance.

DMARC s'appuie sur SPF et DKIM, mais ajoute un point crucial : la relation avec le domaine que le destinataire voit comme expéditeur dans le champ visible De :-champ d'e-mail voit.

Avec un hébergement CURIAWEB normal, un enregistrement DMARC est également créé automatiquement.

La configuration standard de CURIAWEB est la suivante :

v=DMARC1; p=none;

Que signifie v=DMARC1; p=none;? #

Dans cette configuration de base, l'enregistrement se compose de deux informations essentielles.

composant	Sens
v=DMARC1	Marque l'entrée comme version DMARC 1.
p=aucun	Ne publiez pas de politique DMARC visant à mettre en quarantaine ou à rejeter les messages échoués sur la seule base de cette politique DMARC.

p=aucun cela ne signifie pas pour autant que SPF ou DKIM sont désactivés. De même, cela ne signifie pas qu'un filtre anti-spam destinataire doit accepter un message suspect.

Les autres contrôles de sécurité et anti-spam du système destinataire n'en sont pas affectés.

Où se trouve l'enregistrement DMARC ? #

DMARC est enregistré en tant qu'enregistrement TXT sous le nom d'hôte spécial _dmarc publié.

Pour un domaine tel que :

example.ch

l'enregistrement DMARC est-il configuré en conséquence sous :

_dmarc.example.ch

récupéré.

Que sont p=aucun, p=quarantaine et p=rejeter? #

DMARC connaît différentes politiques de domaine.

Politique	Importance fondamentale
p=aucun	Aucune instruction de quarantaine ou de rejet basée sur DMARC.
p=quarantaine	Les messages qui échouent à la vérification DMARC doivent être traités en conséquence comme suspects par le système récepteur, typiquement par une mise en quarantaine ou un traitement comme courrier indésirable.
p=rejeter	Les messages qui ne parviennent pas à passer la validation DMARC doivent être rejetés.

Important : Ne vous contentez pas de configurer un domaine p=aucun sur p=quarantaine ou p=rejeter Euh. Tout d'abord, il faut s'assurer que tous les systèmes d'expédition légitimes sont correctement authentifiés via SPF et/ou DKIM et qu'ils atteignent l'alignement DMARC nécessaire.

Que signifie l'alignement DMARC ? #

DMARC ne se contente pas de vérifier si SPF ou DKIM réussit quelque part dans un message. La relation avec le domaine d'expédition visible est également déterminante.

Cette relation est considérée comme Alignement qualifié.

Simplifié :

Expéditeur visible :
info@example.ch

SPF :
Vérification du chemin d'envoi de l'expéditeur de l'enveloppe concerné

DKIM :
Vérification de la signature DKIM et du domaine de signature

DMARC :
Une authentification réussie correspond-elle au domaine de l'expéditeur visible ?

Cela fait en sorte, entre autres, que DMARC empêche un attaquant d'authentifier correctement sa propre domaine tout en utilisant un domaine tiers comme expéditeur visible et de présenter cette authentification comme une preuve pour ce domaine tiers.

Est-ce que le SPF et le DKIM doivent tous les deux réussir ? #

Pour un test DMARC réussi, il n'est pas strictement nécessaire que SPF et Que DKIM soit à la fois réussi et aligné.

DMARC peut fondamentalement réussir si au moins l'un des deux mécanismes d'authentification réussit et que la correspondance requise avec le domaine de l'expéditeur visible est établie.

En bref : SPF et DKIM sont deux méthodes d'authentification différentes. DMARC associe leurs résultats au domaine d'expédition visible.

Pourquoi CURIAWEB utilise-t-il par défaut p=aucun? #

Une adresse de domaine peut utiliser d'autres systèmes que le serveur de messagerie d'hébergement normal pour l'envoi de courriers. Il peut s'agir par exemple de services de newsletters, de boutiques en ligne, de systèmes CRM, de logiciels de comptabilité, de systèmes de tickets ou de services cloud externes.

Une politique DMARC globalement renforcée peut devenir problématique si ces sources d'envoi légitimes ne sont pas correctement intégrées dans la structure d'authentification.

La configuration par défaut avec :

v=DMARC1; p=none;

évitez par conséquent toute consigne globale visant à placer en quarantaine ou à rejeter les messages dont la vérification DMARC a échoué sur la seule base de cette politique.

Si une politique DMARC plus stricte est souhaitée pour un domaine, il convient d'abord d'analyser l'ensemble du paysage d'expédition.

Quand faut-il adapter la configuration automatique ? #

Tant que vous utilisez exclusivement l'infrastructure de messagerie Curiaweb normale, il n'y a généralement aucune raison de modifier les entrées configurées automatiquement.

Cependant, un examen ou une adaptation peut s'avérer nécessaire dès que des systèmes supplémentaires envoient des e-mails avec ton domaine comme expéditeur.

Des exemples typiques sont :

• Plateformes de newsletter et de marketing
• Systèmes CRM
• services SMTP externes
• Microsoft 365 ou d'autres plateformes de messagerie externes
• Systèmes de support et de tickets
• Boutiques en ligne et services d'e-mails transactionnels
• Filtrage sortant SpamExperts

Ces services peuvent avoir leurs propres exigences en matière de SPF, DKIM ou DMARC.

Ne pas écraser les enregistrements DNS existants #

Si un fournisseur externe exige par exemple un mécanisme SPF supplémentaire, l'enregistrement SPF existant ne doit pas être simplement supprimé et remplacé par l'exemple d'enregistrement du fournisseur.

Avec SPF, toutes les sources d'envoi réellement autorisées doivent être prises en compte dans une politique SPF valide.

Attention : Plusieurs enregistrements TXT distincts, chacun commençant par v=spf1 commencer, ne sont pas la méthode appropriée pour autoriser plusieurs services d'expédition. Les mécanismes nécessaires doivent être regroupés dans une politique SPF commune.

Le DKIM peut également changer avec les systèmes d'envoi externes #

Un service d'expédition externe peut utiliser son propre sélecteur DKIM et exiger qu'un enregistrement DNS supplémentaire soit créé à cet effet.

Cela ne signifie pas automatiquement que l'enregistrement CURIAWEB-DKIM existant doit être supprimé.

Plusieurs sélecteurs DKIM peuvent exister en parallèle si différents systèmes signent chacun avec leur clé associée.

SpamExperts nécessite une attention particulière #

Lorsque le filtrage sortant SpamExperts est utilisé, le chemin d'envoi des e-mails ne correspond plus entièrement à la configuration standard normale de CURIAWEB.

En particulier, l'enregistrement SPF doit alors correspondre à l'infrastructure sortante de SpamExperts.

Nous expliquons la configuration correspondante séparément sous Configurer et vérifier correctement SPF pour SpamExperts.

DKIM peut également être configuré séparément dans le filtrage sortant de SpamExperts. Une signature DKIM existante du système d'envoi doit alors être prise en compte.

Important : N'utilisez donc pas simplement la configuration CURIAWEB-SPF ou DKIM normale comme modèle pour le filtrage sortant de SpamExperts. C'est le chemin d'acheminement réel qui détermine les paramètres d'authentification requis.

SpamExperts vérifie SPF, DKIM et DMARC pour les e-mails entrants #

SpamExperts utilise également SPF, DKIM et DMARC lors de l'analyse des messages entrants.

Ces vérifications servent à inclure des informations sur l'authenticité d'un message entrant ou de son domaine d'expédition dans la décision de filtrage.

Les contrôles d'émetteurs correspondants doivent par principe rester activés.

Nous expliquons cela plus en détail sous Paramètres du filtre SpamExperts : pourquoi la configuration par défaut est généralement le meilleur choix.

Vérifier SPF, DKIM et DMARC dans cPanel #

Dans CURIAWEB, vous pouvez contrôler les paramètres DNS liés aux e-mails dans cPanel.

Ouvrez pour cela :

cPanel → E-mail → Délivrabilité des e-mails

Des informations relatives à SPF et DKIM ainsi que des problèmes de configuration détectés peuvent notamment y être affichés pour les domaines concernés.

Pour un contrôle direct de la zone DNS, vous pouvez également Éditeur de zone utiliser.

Vous trouverez un guide détaillé à ce sujet sous Utilisation de l'éditeur de zones DNS dans cPanel.

Détecter SPF dans le DNS #

L'enregistrement SPF est un enregistrement TXT dont le contenu commence par :

v=spf1

commence.

Dans une configuration CURIAWEB normale, il peut par exemple ressembler à ceci :

v=spf1 +a +mx +ip4:144.76.63.89 ~all

Identifier DKIM dans le DNS #

Les enregistrements DKIM se trouvent sous un nom d'hôte avec :

._domainkey.

Par exemple, de manière schématique :

selector._domainkey.example.ch

Le sélecteur spécifique et la clé publique dépendent de la configuration de votre domaine.

Détecter DMARC dans le DNS #

L'enregistrement TXT DMARC se trouve à l'adresse :

_dmarc.example.ch

Pour la configuration standard de CURIAWEB, le contenu est :

v=DMARC1; p=none;

Vérifier l'authentification avec un e-mail de test #

En plus de la vérification DNS, vous pouvez envoyer un e-mail réel par le canal d'expédition normal, puis examiner ses en-têtes de message complets ou ses résultats d'authentification.

Selon le service de messagerie de réception, il peut s'agir par exemple de résultats tels que :

spf=pass
dkim=pass
dmarc=pass

être affiché.

L'affichage exact varie selon le serveur de messagerie destinataire.

Conseil pratique : Pour un test probant, utilisez exactement la voie d'expédition que vous utilisez également en production. Un e-mail de test envoyé via un autre service SMTP ne prouve en rien que la configuration normale de CURIAWEB fonctionne correctement.

Que faire en cas de spf=fail? #

Si un message légitime reçoit une erreur SPF, il convient d'abord d'examiner le chemin d'acheminement réel.

Vérifiez en particulier si le message a été envoyé via le serveur de messagerie prévu et si des services d'expédition externes supplémentaires sont utilisés.

Dans le cadre d'un hébergement CURIAWEB normal, il convient également de vérifier si l'enregistrement SPF configuré automatiquement est toujours complet.

Que faire en cas de dkim=fail? #

En cas d'erreur DKIM, il convient de vérifier quel système a signé le message, quel sélecteur a été utilisé et si la clé publique correspondante est correctement publiée dans le DNS.

Si le domaine ou sa configuration DNS a récemment été transféré vers un autre fournisseur, il convient de vérifier en particulier si les enregistrements DKIM nécessaires ont été entièrement repris.

Que faire en cas de dmarc=fail? #

Une erreur DMARC ne signifie pas automatiquement que SPF et DKIM ont tous deux complètement échoué.

L'alignement avec le domaine de l'expéditeur visible est également déterminant.

C'est pourquoi, en cas de problème DMARC, il convient d'analyser conjointement SPF, DKIM, le domaine d'envoi visible (From) et le service d'expédition réellement utilisé.

Être particulièrement vigilant après un changement de DNS #

SPF, DKIM et DMARC se trouvent dans le DNS. Par conséquent, si les serveurs de noms d'un domaine sont modifiés ou si la zone DNS est transférée vers un autre fournisseur, les enregistrements DNS nécessaires pour les e-mails doivent également y être correctement présents.

Un site web peut fonctionner sans problème après une migration DNS, tandis que l'authentification des e-mails reste défectueuse.

Par conséquent, après une migration DNS, ne vérifiez pas seulement les enregistrements A, AAAA ou MX, mais aussi les enregistrements TXT pertinents.

Erreurs courantes avec SPF, DKIM et DMARC #

Erreur	Conséquence possible
Enregistrement SPF automatique écrasé	Le serveur de messagerie CURIAWEB ou d'autres systèmes légitimes risquent de ne plus être correctement autorisés.
Plus de paramètres SPF distincts créés	Impossible d'évaluer correctement le SPF.
Enregistrement DKIM oublié lors du transfert DNS	Les signatures DKIM ne peuvent plus être vérifiées avec succès.
Mauvais sélecteur DKIM	Le destinataire ne trouve pas la clé publique correspondant à la signature.
DMARC trop tôt sur p=rejeter posé	Les messages légitimes qui ne sont pas correctement authentifiés ou dont l'alignement est incorrect peuvent être rejetés.
Service de messagerie externe ajouté, mais DNS non configuré	SPF, DKIM ou DMARC peuvent échouer pour ses messages.
Configuration SpamExperts confondue avec l'hébergement standard	L'authentification ne correspond peut-être pas au canal d'expédition réel.

Quand devriez-vous modifier vous-même SPF, DKIM ou DMARC ? #

Dans une configuration d'hébergement CURIAWEB normale, la réponse est généralement : pas du tout.

Un ajustement manuel est surtout nécessaire lorsque la voie d'expédition change ou que des systèmes supplémentaires doivent envoyer des e-mails au nom de votre domaine.

Il faut donc toujours clarifier en premier lieu avant d'apporter des modifications :

1. Quels systèmes envoient réellement des e-mails pour le domaine ?
2. Quel serveur de messagerie ou service SMTP est utilisé ?
3. Quelles sont les exigences SPF pour ces systèmes ?
4. Quel système signe avec DKIM ?
5. Quels sélecteurs DKIM sont utilisés ?
6. L'alignement requis pour DMARC est-il présent ?
7. Quelle politique DMARC est actuellement publiée ?

Résumé #

SPF, DKIM et DMARC constituent ensemble une base importante pour l'authentification des e-mails.

Avec un hébergement CURIAWEB normal, les enregistrements DNS correspondants sont en principe configurés automatiquement.

L'enregistrement SPF dans la configuration standard de CURIAWEB peut par exemple ressembler à ceci :

v=spf1 +a +mx +ip4:144.76.63.89 ~all

DKIM est configuré automatiquement pour le domaine et permet la signature cryptographique et la vérification des messages sortants.

L'enregistrement DMARC créé par défaut est le suivant :

v=DMARC1; p=none;

Tant que tu utilises exclusivement l'infrastructure de messagerie normale de CURIAWEB, tu ne devrais normalement pas modifier ces paramètres.

Une adaptation individuelle devient particulièrement nécessaire lorsque des systèmes externes tels que des services de newsletter, des plateformes CRM, Microsoft 365, des services SMTP externes ou le filtrage sortant SpamExperts envoient des e-mails au nom de votre domaine.

Ce qui importe toujours, c'est le chemin d'acheminement réel. C'est pourquoi SPF, DKIM et DMARC ne doivent pas être configurés à l'aide de valeurs d'exemple générales, mais en fonction de l'infrastructure de messagerie réellement utilisée.