Améliorer la sécurité des e-mails via un enregistrement DMARC

Objectif

L'enregistrement Domain-based Message Authentication, Reporting, and Conformance (DMARC) est un mécanisme de sécurité e-mail. Il s'appuie sur le résultat des vérifications SPF et DKIM.

Découvrez comment fonctionne DMARC et comment le mettre en place pour votre service e-mail.

Prérequis

• Un des mécanismes d'authentification, SPF et/ou DKIM doit être configuré dans la zone DNS du nom de domaine de l'offre e-mail.

Accès à l'espace client OVHcloud

• Lien direct : Zones DNS
• Pour accéder à vos services : Web Cloud > Zones DNS > Sélectionnez votre nom de domaine

En pratique

Le DMARC permet au titulaire d’un nom de domaine de gérer la sécurité des e-mails émis avec son nom de domaine. Il a pour objectif :

• De déclarer, au serveur destinataire, les actions à mener en cas d’échec des mécanismes d'authentification SPF et/ou DKIM.
• De mieux maitriser l’usage de son nom de domaine et détecter les tentatives d’usurpation à l'aide des rapports envoyés en cas d’échec d’authentification des e-mails. Par ailleurs, il améliore également la sécurité en créant le lien entre les protocoles SPF et DKIM.

L' enregistrement DMARC contient des informations sur la politique à appliquer pour les e-mails malveillants qui tentent d'usurper votre nom de domaine.
DMARC interroge les mécanismes d'authentification SPF et DKIM pour vérifier les e-mails entrants.
Le résultat de ces vérifications SPF et/ou DKIM est traduit par DMARC en « mesures à prendre » lorsqu'un e-mail échoue aux contrôles. Ces mesures peuvent être la mise en quarantaine ou le rejet des e-mails concernés.

Comment le DMARC fonctionne-t-il ?

Pour bien comprendre comment fonctionne le DMARC, voici un exemple.

Lorsque l'adresse contact@mydomain.ovh envoie un e-mail vers l'adresse de destination recipient@otherdomain.ovh, le serveur de réception va interroger la zone DNS du nom de domaine émetteur mydomain.ovh pour lire les instructions de l'enregistrement DMARC.

L'enregistrement DMARC communique la politique à adopter en fonction du résultat des tests SPF et DKIM. Il peut également renseigner une ou des adresses e-mail (représentées dans notre exemple par l'adresse report@mydomain.ovh) servant à recevoir les rapports d'échecs d'e-mails envoyés depuis le nom de domaine mydomain.ovh.

Après lecture des instructions de l'enregistrement DMARC du nom de domaine mydomain.ovh par le serveur de réception de « otherdomain.ovh », les e-mails seront soit délivrés vers l'adresse recipient@otherdomain.ovh, soit marqués comme « SPAM » ou rejetés.

Configurer le DMARC

Il y a deux façons de configurer le DMARC dans votre zone DNS OVHcloud :

• Par l'outil de configuration DMARC. Cet enregistrement permet une configuration simplifiée du DMARC. Vous n'aurez qu'à compléter les champs avec les paramètres DMARC nécessaires à votre configuration. Cet enregistrement est lu comme un enregistrement TXT par les serveurs DNS.
• Par le biais d'un enregistrement TXT. Cet enregistrement standard peut être utilisé dans le cadre de la configuration du DMARC depuis l'espace client OVHcloud. Il vous permettra d'intégrer l'ensemble des balises de paramétrage DMARC, y compris celles absentes via l'enregistrement DMARC OVHcloud. Il nécessite toutefois de bien respecter les règles de syntaxe du protocole DMARC.

Enregistrement DMARC

Vous pouvez ajouter l'enregistrement DMARC à votre zone DNS depuis l'espace client OVHcloud. Pour cela, connectez-vous à votre espace client OVHcloud puis rendez-vous dans la partie Web Cloud. Dans la colonne de gauche, sélectionnez, dans la section Noms de domaine, le nom de domaine concerné puis cliquez sur l'onglet Zone DNS pour accéder à votre zone DNS.

Une fois votre zone DNS affichée, cliquez sur le bouton Ajouter une entrée puis sur « Champs mails » DMARC.

• Sous-domaine : cette entrée doit obligatoirement débuter par _dmarc. Si vous appliquez votre DMARC à l'ensemble du nom de domaine, n'inscrivez rien d'autre que _dmarc dans cette case. Si vous définissez votre DMARC à un sous-domaine de votre nom de domaine principal, ajoutez votre sous-domaine après _dmarc. Par exemple, si on doit appliquer le DMARC à un sous-domaine subdomain.mydomain.ovh, il faut saisir _dmarc.subdomain dans la case « sous-domaine » pour le nom de domaine mydomain.ovh.

Vous trouverez ci-dessous le descriptif exhaustif des balises utilisées pour l'enregistrement DMARC OVHcloud :

• Version (v=) : champ obligatoire déterminant la version du protocole DMARC.

• Règle pour le domaine (p=) : politique à adopter par le destinataire à la demande du titulaire du nom de domaine expéditeur. La politique s'applique au domaine interrogé et aux sous-domaines, sauf si la balise de sous-domaine sp= indique des instructions différentes. Les valeurs possibles sont les suivantes :

  • none : le titulaire du nom de domaine ne demande aucune action spécifique concernant la livraison des messages.
  • quarantine : en cas d'échec de la vérification du mécanisme DMARC, les e-mails doivent être considérés comme suspects par les destinataires. Selon les capacités du serveur destinataire, cela peut signifier « placer dans le dossier spam » et/ou « signaler comme suspect ».
  • reject : rejet des e-mails qui échouent à la vérification du mécanisme DMARC.

• Pourcentage des messages filtrés (pct=) (valeur comprise entre 0 et 100, la valeur par défaut est 100) : pourcentage du flux de messages auquel la politique DMARC doit être appliquée. Le but de la balise « pct » est de permettre aux titulaires de noms de domaine d'adopter une mise en œuvre lente du mécanisme DMARC.

• URI de création de rapports globaux (rua=) : adresses auxquelles les rapports doivent être envoyés (liste en texte brut séparé par des virgules). N'importe quel URI valide peut être spécifié. La mention « mailto:» doit précéder le destinataire e-mail (exemple : mailto:address@example.com).

• Règle pour les sous-domaines (sp=) : politique à adopter par le destinataire pour tous les sous-domaines. Elle s'applique uniquement aux sous-domaines du nom de domaine interrogé et non au domaine lui-même. Sa syntaxe est identique à celle de la balise « p » définie ci-dessus. Si cette balise est absente, la politique spécifiée par la balise « p » est appliquée pour les sous-domaines.

• Mode d'alignement pour SPF (aspf=) (la valeur par défaut est r) : indique le mode d'allignement SPF. Les valeurs sont les suivantes :

  • r(relaxed) pour le mode souple : les e-mails peuvent être, par exemple, envoyés depuis un sous-domaine du nom de domaine déclaré. On parle ici d'alignement partiel.
  • s(strict) pour le mode strict : les e-mails doivent être envoyés depuis le nom de domaine déclaré et uniquement celui-ci. Le résultat est donc « aligné ».

Enregistrement TXT

Vous pouvez ajouter l'enregistrement TXT à votre zone DNS depuis l'espace client OVHcloud puis rendez-vous dans la partie Web Cloud. Cliquez sur Noms de domaine puis choisissez le nom de domaine concerné. Positionnez-vous enfin sur l'onglet Zone DNS.

Une fois votre zone DNS affichée, cliquez sur le bouton Ajouter une entrée puis sur « Champs étendus » TXT.

• Sous-domaine : cette entrée doit obligatoirement débuter par _dmarc. Si vous appliquez votre DMARC à l'ensemble du nom de domaine, n'inscrivez rien d'autre que _dmarc dans cette case. Si vous définissez votre DMARC à un sous-domaine de votre nom de domaine principal, ajoutez votre sous-domaine après _dmarc. Par exemple, si on doit appliquer le DMARC à un sous-domaine subdomain.mydomain.ovh, il faut saisir _dmarc.subdomain dans la case « sous-domaine » pour le nom de domaine mydomain.ovh

Vous trouverez ci-dessous la liste des balises utilisées pour créer un enregistrement TXT avec les paramètres DMARC. Cette liste est complémentaire avec les balises mentionnées dans la section précédente « Enregistrement DMARC ».

• adkim (la valeur par défaut est r) : indique le mode d'alignement DKIM. Les valeurs sont les suivantes :

  • r(relaxed) pour le mode souple : les e-mails échouant à l'authentification DKIM sont marqués comme « indésirables » par le serveur destinataire.
  • s(strict) pour le mode strict : les e-mails échouant à l'authentification DKIM sont rejetés par le serveur destinataire.

• ruf (liste en texte brut séparée par des virgules) : adresses auxquelles les informations d'échec spécifiques au message doivent être signalées . Si cette balise est présente, le titulaire du nom de domaine expéditeur demande aux destinataires d'envoyer des rapports d'échec détaillés sur les e-mails qui échouent à l'évaluation DMARC de manière spécifique (voir la balise fo ci-dessous). Le format du message à générer doit suivre le format spécifié pour la balise rf. La mention « mailto:» doit précéder le destinataire e-mail (exemple : mailto:address@example.com).

• fo (texte brut ; la valeur par défaut est 0) : options du rapport d'échec détaillé. Les générateurs de rapports peuvent choisir de se conformer aux options demandées. Le contenu de cette balise doit être ignoré si une balise ruf (ci-dessus) n'est pas également spécifiée. La valeur de cette balise est une liste de caractères séparés par deux points (:) et qui indiquent les options de rapport d'échec suivants :

  • 0 : génère un rapport d'échec DMARC si tous les mécanismes d'authentification (DKIM ET SPF) ne parviennent pas à produire un résultat « pass » aligné.
  • 1 : génère un rapport d'échec DMARC si un mécanisme d'authentification (DKIM OU SPF) produit autre chose qu'un résultat « success » aligné.
  • d : génère un rapport d'échec DKIM si le mécanisme d'authentification DKIM échoue, quel que soit son alignement.
  • s : génère un rapport d'échec SPF si le mécanisme d'authentification SPF échoue, quel que soit son alignement.

• rf (valeurs en texte brut séparées par des virgules, la valeur par défaut est afrf) : cette balise indique le type de format attendu pour les rapports qui fournissent des détails spécifiques sur les échecs d'authentification des messages. Actuellement, seul afrf (Auth Failure Reporting Format) est pris en charge.

• ri (entier non signé de 32 bits en texte brut ; la valeur par défaut est 86400) : intervalle requis, en secondes, entre les rapports agrégés. Cette balise spécifie la fréquence à laquelle les destinataires des e-mails doivent générer des rapports agrégés sur les résultats d'évaluation DMARC pour le domaine concerné.

Exemples d'enregistrement

Premier exemple

Pour illustrer ce premier exemple, nous avons utilisé l'enregistrement DMARC dans la zone DNS et nous lui avons appliqué les paramètres suivants :

Nous obtenons le résultat suivant :

"v=DMARC1;p=quarantine;pct=100;rua=mailto:report@mydomain.ovh;aspf=s;"

La totalité des e-mails envoyés (pct=100) sont traités par les mécanismes d'authentification SPF et/ou DKIM. Les e-mails ayant échoué au test SPF sont automatiquement rejetés car "aspf=s" (mécanisme SPF en mode strict). Un rapport d'erreurs sur l'échec des mécanismes d'authentification SPF et/ou DKIM est envoyé à l'adresse report@mydomain.ovh (rua=mailto:report@mydomain.ovh).

Deuxième exemple

Pour ce deuxième exemple, nous avons utilisé un enregistrement TXT pour utiliser des balises qui ne sont pas disponibles via l'enregistrement DMARC simplifié.

Nous obtenons le résultat suivant :

"v=DMARC1; p=quarantine; pct=100; ruf=mailto:report@mydomain.ovh; fo=0; adkim=r; aspf=s; adkim=r; ri=86400"

• p=quarantine : les e-mails qui ne passent pas les tests DMARC sont traités comme « suspects ».

• pct=100 : la politique DMARC s'applique à 50% des messages provenant du flux d'e-mail du titulaire du nom de domaine.

• ruf=mailto:report@mydomain.ovh : adresse e-mail à laquelle les rapports d'échec détaillés doivent être envoyés via l'argument « mailto ».

• fo=0 : options de génération des rapports d'échec. La valeur « 0 » indique que des rapports d'échec DMARC doivent être générés uniquement si les mécanismes d'authentification SPF et DKIM échouent à produire un résultat aligné « pass ».

• adkim=r : le mode d'alignement d'identifiant DKIM requis par le titulaire du nom de domaine est "relaxed" (mode souple). Dans ce mode, DKIM doit fournir une signature valide et l'identifiant de l'en-tête "From" peut être partiellement aligné.

• aspf=s : le mode d'alignement d'identifiant SPF requis est « strict ». Cela signifie que l'identifiant SPF du nom de domaine aligné doit correspondre exactement à l'adresse IP émettrice du message.

• adkim=r : le mode d'alignement d'identifiant DKIM requis par le titulaire du nom de domaine est « relaxed » (mode souple). Dans ce mode, DKIM doit fournir une signature valide et l'identifiant de l'en-tête « From » peut être partiellement aligné.

• ri=86400 : définit l'intervalle demandé entre les rapports agrégés, en secondes. Dans ce cas, un rapport agrégé doit être généré au moins une fois toutes les 86400 secondes (soit une fois par jour).

Aller plus loin

Pour des prestations spécialisées (référencement, développement, etc), contactez les partenaires OVHcloud.

Si vous souhaitez bénéficier d'une assistance à l'usage et à la configuration de vos solutions OVHcloud, nous vous proposons de consulter nos différentes offres de support.

Échangez avec notre communauté d'utilisateurs.