Dans ce guide, nous allons voir comment configurer SPF, DKIM et DMARC sur un nom de domaine afin de renforcer l'authentification et améliorer la recevabilité des emails envoyés depuis ce domaine.
Avant d'ajuster votre configuration, deux choses doivent être prises en considération :
- Pour que les changements que vous appliquez sur DirectAdmin soient pris en compte, les serveurs de noms utilisés pour votre domaine doivent être ceux par défaut. Pour savoir comment vérifier et ajuster les serveurs de nom, rendez-vous sur ce lien : https://www.behostings.com/client/index.php?rp=/knowledgebase/82/D%C3%A9finir-mes-serveurs-de-noms-nameservers-pour-mon-domaine.html
- Les enregistrements SPF et DKIM sont automatiquement ajoutés et configurés dans votre zone DNS lors de la création d'un domaine. Dans la majorité des cas, vous n'avez donc rien à faire. Si vous faites des modifications pour SPF, veillez à ajouter des options sans retirer celles déjà configurées. En effet, l'option SPF préconfigurée autorise notre passerelle sortante à relayer les emails des domaines configuré sur votre hébergement. Si elle est retirée, cela empêchera la bonne réception de vos emails qui partent de nos serveurs.
Pourquoi ces protocoles existent et pourquoi il est important de les utiliser
Tous les emails aujourd’hui sont échangés entre les différents serveurs via le protocole SMTP (Simple Mail Transfer Protocol). Ce protocole a été établi en Août 1982, loin des considérations de sécurité et de risque d’usurpation d’identité.
Le protocole définit un champ expéditeur qui est un simple champ texte, sans aucune vérification d’authenticité de l’expéditeur.
Il était possible possible d’envoyer un mail depuis bill.gates@microsoft.com sans difficulté jusque récemment.
Cela pose évidemment de graves problèmes de sécurité. Une personne mal intentionnée pouvait facilement se faire passer pour une autre, par exemple un de vos fournisseurs, et envoyer un mail demandant de changer le numéro de compte sur lequel vous payez les factures…
SPF (Sender Policy Framework) a commencé à être créé en 2006 (https://www.rfc-editor.org/rfc/rfc4408) et a été implémenté de manière universelle en 2014 https://www.rfc-editor.org/rfc/rfc7208). Il permet à un domaine d'emails de communiquer via sa zone DNS les adresses IP qui sont autorisées à envoyer du courrier pour ce nom de domaine.
DKIM (DomainKeys Identified Mail) a été créé en 2007 suite à la collaboration entre Yahoo et Cisco sur leurs projets respectifs visant à renforcer l'authentification de l'envoi d'emails. C'est une technologie basée sur des clés privées et publiques. Elle signe numériquement les emails envoyés à l'aide une clé privée présente sur le serveur d'envoi. Lors de la réception de l'email, cette signature est comparée à la clé publique présente dans les enregistrements DNS du domaine d'envoi d'emails.
DMARC (Domain-based Message Authentication, Reporting & Conformance) a été créé en 2015 (https://www.rfc-editor.org/rfc/rfc7489) et permet de renforcer la sécurité de SPF et de DKIM en ajoutant des règles de rejet des emails frauduleux, d'envoi de rapports sur les tentatives d'usurpation et plus encore.
Faire appel à un technicien pour configurer vos DNS
Le site de Behostings regroupe plusieurs articles (y compris celui-ci) vous permettant de comprendre comment configurer votre hébergement et vos DNS. Cependant, notre équipe technique peut s'en charger pour vous dans le cadre d'un support infogérance facturé 19,99€ HTVA.
Préliminaire important : comment lire un enregistrement DNS?
Un enregistrement DNS sera montré de différentes manières selon les interfaces de configuration, mais la syntaxe universelle est celle d'une ligne texte qui peut ressembler à ceci :
www.exemple.com. 1200 IN A 1.2.3.4
www.exemple.com. est le nom d'hôte concerné (un hôte est un serveur dans le jargon des administrateurs réseau). Il sera suivi d'un point pour indiquer qu'il n'y a rien après. Lorsque l'on écrit le nom d'hôte sans le point, c'est alors le sous-domaine qui est utilisé comme nom d'hôte. Ici, s'il n'y avait pas de point, l'hôte serait exemple.com.exemple.com.
1200 est le temps en secondes durant lequel l'enregistrement DNS sera gardé en vie dans un cache avant que les serveurs DNS ne fassent une nouvelle requête aux serveurs DNS du domaine pour savoir s'il existe toujours ou s'il a été modifié. Dans cet exemple-ci, ce temps est de 1200 secondes, soit 20 minutes.
En d'autres termes, ici, si on veut modifier ou supprimer cet enregistrement DNS, il faudra 20 minutes pour que nos modifications soient propagées vers l'ensemble des serveurs DNS. Mais si aucun enregistrement A n'était présent et qu'on en ajoute un comme celui-ci, les changements seront appliqués et propagés immédiatement avec un possible délai de quelques minutes.
IN A indique qu'il s'agit d'un enregistrement qui pointe vers une IPv4. Il existe plusieurs types d'enregistrements. Ceux qui nous intéressent sont les TXT. Pour plus d'informations sur les enregistrements DNS, rendez vous sur notre article sur les DNS.
1.2.3.4 est le dernier champ, c'est la valeur de l'enregistrement. Dans ce cas-ci, c'est l'IPv4 vers laquelle le nom d'hôte doit pointer.
Dans ce guide, nous allons faire référence aux enregistrements DNS sous cette forme afin d'éviter toute confusion causée par des interfaces différentes.
SPF
SPF est l'acronyme de Sender Policy Framework. C'est un protocole qui permet d'éviter qu'un serveur mail frauduleux envoie du courrier en se faisant passer pour un autre domaine.
Mon domaine est exemple.com et le serveur mail que j'utilise pour l'envoi de mes mails est mail.exemple.com. Cet hôte mail.exemple.com est aussi le MX de mon domaine. Configurer correctement l'enregistrement SPF suivant :
exemple.com. 1200 IN TXT "v=spf1 a mx ~all"
- va valider que le MX du domaine, mail.exemle.com peut envoyer des mails venant de @exemple.com.
- va empêcher qu'un serveur mail mail.bidule.com puisse envoyer un mail qui semblerait légitime de la part de alex@exemple.com.
L'enregistrement SPF dans sa zone DNS :
Voici à quoi peut ressembler un enregistrement SPF simple :
exemple.com. 1200 IN TXT "v=spf1 a mx ip4:1.2.3.4 ~all"
L'enregistrement SPF se place dans un enregistrement de type TXT qui pointe sur le domaine principal. Dans notre exemple, comme nous souhaitons envoyer des mails depuis ...@exemple.com, l'enregistrement TXT doit pointer sur exemple.com. Il faut ajouter un point à la fin car sans le point, c'est un sous-domaine qui serait ajouté. L'enregistrement pointerait alors sur exemple.com.exemple.com.
Dans le champ valeur, plusieurs options peuvent être ajustées.
v=
Le "v", suivi d'un "=" permet de définir la version de spf. Aujourd'hui, c'est la version 1 qui est utilisée. il faut donc commencer la ligne avec v=spf1.
ip:, ip4: et ip6:
Cette option, permet de définir depuis quelle(s) adresse(s) ip les emails du domaine, ici exemple.com, peuvent êtres envoyés. Cette option peut être ajoutée autant de fois que vous le désirez en séparant chaque itération par un espace.
Exemple : exemple.com. 1200 IN TXT "v=spf1 ip4:1.2.3.4 ~all"exemple.com. 1200 IN TXT "v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ip6:2001:db8::1234:5 ~all"
Il est également possible de spécifier un sous-réseau entier.
Exemple :exemple.com. 1200 IN TXT "v=spf1 ip4:1.2.3.0/24 ~all"
a:
Cette option permet d'ajouter un ou plusieurs hôtes dont les adresses ip renseignées dans l'enregistrement A de leur zone DNS sont autorisées à envoyer du courrier pour notre domaine principal, exemple.com. Cette option peut être ajoutée autant de fois que vous le désirez en séparant chaque itération par un espace.
Exemple :exemple.com. 1200 IN TXT "v=spf1 a:mail.exemple.com ~all"exemple.com. 1200 IN TXT "v=spf1 a:mail01.exemple.com a:mail02.exemple.com ~all"
include: (option plus avancée et plus compliquée)
Cette option va permettre de lire toutes règles d'autorisation SPF d'un autre domaine et de les appliquer également sur notre domaine principal, exemple.com. Les champs qui sont lus depuis l'enregistrement et appliqués sont les champs ip:, ip4:, ip6:, a:, include:, a et mx.
Par exemple :
J'ai deux domaines : exemple.com et exemple.org. Chaque domaine envoie et reçoit des emails respectivement via mail.exemple.com et mail.exemple.org. Je veux que les emails qui partent de ...@exemple.com puissent également utiliser le serveur mail mail.exemple.org.
Dans la zone DNS d'exemple.org j'ai l'enregistrement suivant :
exemple.org. 1200 IN TXT "v=spf1 ip4:1.2.3.4 a:mail.exemple.org ~all"
Il est ensuite possible d'écrire la zone DNS pour exemple.com de cette façon :
exemple.com. 1200 IN TXT "v=spf1 ip4:5.6.7.8 a:mail.exemple.com include:exemple.org ~all"
Dans ce cas, toutes les autorisations SPF du domaine exemle.org seront également lues et appliquées pour les mails envoyés depuis le serveur mail mail.exemple.com.
a et mx
Ces option peuvent être ajoutées et n'ont pas de valeur associée. Elles ne prennent donc pas de ":" ou de "=" après.
L'option "a" indique qu'il est autorisé d'envoyer des emails depuis les adresses ip indiquées dans l'enregistrement A de la zone DNS de notre domaine principal exemple.com.
Par exemple : si on a un enregistrement mail01.exemple.com. 1200 IN A 1.2.3.4, alors, ajouter simplement un "a" dans les options SPF autorisera l'adresse ip 1.2.3.4 à envoyer de emails pour notre domaine principal.
Exemple :exemple.com. 1200 IN TXT "v=spf1 a ~all"
L'option "mx" indique qu'il est autorisé d'envoyer des mails depuis les adresses ip des domaines indiquées dans le ou les enregistrements MX de la zone DNS.
Par exemple, si on a un enregistrement exemple.com. 1200 IN MX 10 mailserver.superserveur.com, alors, ajouter simplement un "mx" dans les options SPF autorisera l'adresse ip liée à mailserver.superserveur.com à envoyer des emails pour notre domaine principal.
Exemple :exemple.com. 1200 IN TXT "v=spf1 mx ~all"
Dans la majorité des cas (sauf si un service externe est utilisé) il va de soi d'activer ces options.
-all, ~all, ?all et +all
Cette option permet de définir ce qui doit être appliqué pour les emails qui ne suivent pas les directives configurées dans l'enregistrement SPF d'un domaine.
-all interdit tout. C'est la règle la plus stricte et elle peut venir avec ses inconvénients. Le mail qui ne respecte pas les règles SPF sera rejeté par le serveur mail du destinataire.~all autorise la réception d'un mail qui échoue la vérification SPF mais le marque comme suspect. C'est la règle utilisée le plus couramment. Elle également appelée "SoftFail".?all est neutre. Le score de spam ne devrait pas augmenter si les règles précédemment indiquées ne sont pas respectées lors de l'envoi d'un mail. C'est une option utile si vous n'êtes pas certain d'avoir bien indiqué l'ensemble des adresses ip et hôtes autorisés dans les options SPF.+all autorise tout. C'est la règle la plus laxiste.
Configurer le SPF dans l'interface DirectAdmin utilisée par Behostings
Pour vous rendre dans l'interface de configuration de SPF dans les DNS, veuillez suivre la marche à suivre ci-dessous.
Si aucun enregistrement SPF n'est présent, il faut en ajouter un via le bouton "Ajouter un enregistrement". Et ensuite choisir les options TXT, puis SPF.
Dans l'interface DirectAdmin, la création d'enregistrement SPF est facilitée grâce à des champs distincts pour chaque option. Dans le dernier champ "Valeur" se trouve la ligne de valeur telle que nous venons d'apprendre à l'écrire ci-dessus.
Après avoir lu ce document, vous devriez bien vous y retrouver dans cette interface. Des boutons "?" vous guideront au besoin.
DKIM
DKIM est l'acronyme de "DomainKeys Identified Mail". C'est une technologie de signature numérique des email permettant de s'assurer que seul le serveur possédant la clé privée soit autorisé à envoyer des emails pour le domaine concerné.
Pour implémenter DKIM (et de manière plus générale, les technologies de signature numérique), il est nécessaire d'avoir une paire de clés : une clé privée et une clé publique.
Dans le cas de DKIM, la clé privée se trouve sur le serveur d'envoi de mails et la clé publique se trouve dans les enregistrements DNS. Tout mail envoyé sera signé numériquement en utilisant la clé privée. Un mail signé de cette façon peut alors être vérifié en utilisant la clé publique accessible dans les enregistrements DNS.
L'enregistrement DNS pour DKIM
Voici à quoi ressemble un enregistrement DNS pour une configuration DKIM.
x._domainkey.exemple.com. 1200 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw0H31fV1gI2uaaxumYhyeKPst46WeuLr4wQH1hvxEWiQ4REs4bPfP9vTSezAbA/bbgkovtvKiqs4igSbBFKt+SEQEqh/2XkaeUJuvrGokFDc+t62azzmPUCOlbGv1aTzmrvWdiBNiwf79wqjMGRhlqWIY8TpXBvdwx2WcqBL1WzGNQgel+9thU6mpeyglqn9GSHZTke+cA+XqlhEjycjWDnJXmQOOI1sTQuK+Jjo23fpzmvmupaUReiPJ7PM77hLfuHpc/q5Am/v3Gkxw8n0SsXCvUzoA2NTg3IIXYDSWFTx3FXEFMvHj/9Ba2YQyWCrxwxRKkyVoNM4Rn+cJCh0nwIDAQAB"
Notez ici que les options de l'enregistrement DKIM doivent être séparées par des points-virgules.
x._domainkey
C'est le sous-domaine vers lequel il faut faire pointer l'enregistrement DKIM. Dans l'exemle ci-dessus, si mon domaine principal est exemple.com, alors cet enregistrement pointera alors vers x._domainkey.exemple.com.
"x" est le sélecteur DKIM. Selon la configuration du serveur, le sélecteur peut être différent. Par défaut sur DirectAdmin, le sélecteur est "x".._domainkey suit directement le sélecteur et doit être écrit tel quel car c'est ce qui indique que l'enregistrement est un enregistrement servant à DKIM.
v=
Cette option permet de définir la version de DKIM utilisée. Aujourd'hui, c'est la version 1 qui est utilisée. Il faut donc écrire v=DKIM1.
k=
Cette option permet de définir le type de clé présent dans la signature DKIM. Généralement, c'est le type rsa qui est utilisé.
p=
Cette option indique la clé publique utilisée pour vérifier les mails envoyés et signés avec la clé privée.
D'autres options peuvent être ajoutées et ajustées mais celles-ci sont les 3 principales.
Créer un enregistrement DKIM à partir de DirectAdmin
Si votre enregistrement DKIM a été supprimé par erreur ou s'il est problématique, voici comment en créer un nouveau. Rendez-vous dans "Comptes E-mail", (désactivez si DKIM est activé) et activez à nouveau DKIM.
DMARC
DMARC est l'acronyme de "Domain-based Message Authentication, Reporting & Conformance". Cette option, inventée plus tard que SPF et DKIM, est placée elle aussi dans un enregistrement DNS et permet d'ajouter des règles s'appliquant aux messages qui ne passent pes les vérifications SPF et DKIM.
Cette option est utile par exemple lorsque l'administrateur d'un serveur mail veut avoir des rapports suite à des tentatives d'usurpations ou s'il veut indiquer aux serveurs de réception d'email de rejeter tout mail ne passant pas la vérification SPF ou DKIM ou les deux.
Attention : si les configurations SPF ou DKIM de votre domaine ne sont pas bien configurées, ajouter un enregistrement DMARC trop strict peut empêcher la recevabilité de vos emails. Il faut donc l'utiliser avec précaution.
L'enregistrement DNS pour DMARC
Un enregistrement DMARC peut ressembler à ceci :
_dmarc.exemple.com. 1200 IN TXT "v=DMARC1 p=reject rua=postmaster@exemple.com"
L'enregistrement DMARC est un enregistrement de type TXT qui pointe sur le sous-domaine _dmarc. Il comprendra ensuite plusieurs options.
v= (obligatoire)
Cette option, comme pour SPF et DKIM, indique la version de DMARC à utiliser. Aujourd'hui, c'est la version 1 qui est utilisée. On indiquera donc v=DMARC1.
p= (obligatoire)
Cette option (qui vient de policy), indique la politique à appliquer lorsqu'un message sortant échoue aux vérifications SPF et DKIM.
- p=none : dans ce cas, aucune politique ne s'applique en cas d'échec. C'est l'option la plus sûre si vous n'êtes pas certain de vos configurations SPF ou DKIM.
- p=quarantine : cette option indique au serveur de réception de placer le mail qui échoue les vérification SPF ou DKIM dans les spams du destinataire.
- p=reject : cette option indique au serveur de réception qu'il doit rejeter le mail qui échoue les vérifications SPF ou DKIM.
rua=
Cette option est l'acronyme de "Reporting URI of Aggregate reports". Elle permet de désigner une adresse mail à laquelle on souhaite recevoir les rapports DMARC. Ces rapports fournissent des informations sur le volume de messages reçus, combien ont réussi l’authentification DMARC, et combien ont échoué. Par défaut ces emails de rapport sont envoyés une fois pas jour.
Exemple :_dmarc.exemple.com. 1200 IN TXT "v=DMARC1 p=quarantine rua=postmaster@exemple.com"
ruf=
Cette option est l'acronyme de "Reporting URI of Forensic reports". Elle permet également de désigner une adresse mail à laquelle on souhaite recevoir les rapports DMARC. Seulement, ici, les rapports sont envoyés presque immédiatement après l'envoi d'un message qui échoue les vérifications SPF ou DKIM. Cela peut générer un grand nombre de mails et devrait être configuré sur une boite mail séparée sur un serveur capable de supporter cette potentielle grande charge de mails.
Exemple :_dmarc.exemple.com. 1200 IN TXT "v=DMARC1 p=quarantine ruf=postmaster@exemple.com"
pct=
Cette option vient de percentage et désigne le pourcentage de mails pour lesquels utiliser DMARC. Pour l'appliquer à 100% des mails, l'option ressemblera à pct=100.
Exemple :_dmarc.exemple.com. 1200 IN TXT "v=DMARC1 p=quarantine ruf=postmaster@exemple.com pct=100"
aspf=
Cette option vient de alignement SPF et permet d'ajuster le niveau de rigueur à appliquer pour les échecs de vérification SPF. Les deux options possibles sont s pour strict et r pour relaxed.
Dans les deux cas, le mail doit réussir la vérification SPF et DKIM. Mais dans le cas de "s" pour strict, le domaine de l'email de l'expéditeur doit correspondre parfaitement au domaine défini dans l'enregistrement SPF pour réussir la vérification DMARC. Autrement, lorsque l'on défini le paramètre sur "r" pour relaxed, le domaine de l'adresse mail de l'expéditeur et le domaine défini dans l'enregistrement SPF peuvent ne correspondre que partiellement.
Exemple :_dmarc.exemple.com. 1200 IN TXT "v=DMARC1 p=quarantine ruf=postmaster@exemple.com pct=100 aspf=s"
adkim=
Tout comme l'option précédente, cette option vient de alignement DKIM et permet d'ajuster le niveau de rigueur à appliquer pour les échecs de vérification DKIM. Les deux options possibles sont s pour strict et r pour relaxed.
Dans les deux cas, le mail doit réussir la vérification SPF et DKIM. Mais dans le cas de "s" pour strict, le domaine de l'email de l'expéditeur doit correspondre parfaitement au domaine défini dans l'enregistrement DKIM pour réussir la vérification DMARC. Autrement, lorsque l'on défini le paramètre sur "r" pour relaxed, le domaine de l'adresse mail de l'expéditeur et le domaine défini dans l'enregistrement DKIM peuvent ne correspondre que partiellement.
Exemple :_dmarc.exemple.com. 1200 IN TXT "v=DMARC1 p=quarantine ruf=postmaster@exemple.com pct=100 aspf=s adkim=r"