• Accueil / Marketing Cloud / SPF, DKIM, DMARC?…

SPF, DKIM, DMARC? Démystifier les domaines authentifiés par l’expéditeur – Le blog de Markus Slabina, principalement lié à Salesfoce, qui couvre les meilleures pratiques, des conseils et des astuces. La majorité des articles se concentre sur les scénarios Marketing Cloud et Cross-Cloud.14 minutes de lecture


Savez-vous comment sécuriser votre domaine d’envoi d’e-mails? Il s’agit d’une étape importante dans la mise en œuvre de tout marketing automation système ou serveur de messagerie. Vous êtes-vous déjà demandé ce que signifient SPF, DKIM et DMARC et comment cela aide vos e-mails à atteindre la boîte de réception de vos abonnés?

Informations générales

Il est beaucoup plus pratique de taper «markus.codes» dans votre navigateur plutôt que «46.101.151.122», non?! C’est ce que le système de noms de domaine (DNS) vous permet de faire. Si vous vous demandez ce que cela a à voir avec l’envoi d’e-mails authentifiés – tous les mécanismes ci-dessus (SPF, DKIM, DMARC) sont basés sur le système de noms de domaine (DNS) et des entrées spécifiques à une soi-disant «zone» qui représente fondamentalement une une partie de l’espace de noms de domaine, donc essentiellement, cela pourrait être un domaine entier comme « markus.codes » ou un sous-domaine comme « email.markus.codes ».

Il existe plusieurs serveurs DNS à travers le monde qui gèrent chacun un sous-ensemble de toutes les informations DNS disponibles. Votre ordinateur utilise un serveur DNS spécifique (par exemple 8.8.8.8 qui est l’un des serveurs DNS de Google) pour toutes les résolutions de noms. Si ce serveur ne dispose pas de ces informations, il contacte un autre serveur DNS, qui peut répondre ou demander à un autre serveur. Le DNS est donc un système hiérarchique mondial et décentralisé.

Si vous utilisez un système d’automatisation du marketing tel que Salesforce Marketing Cloud, il est très probable que vous deviez configurer ces enregistrements lors de la configuration ou tout votre domaine est délégué au fournisseur. Pour les clients Marketing Cloud, c’est le cas lors de la configuration d’un «domaine privé» ou d’un «package d’authentification de l’expéditeur». Cependant, ces configurations ajoutent quelques autres choses à vos enregistrements DNS qui sont nécessaires pour d’autres fonctionnalités de la plate-forme. Le package d’authentification de l’expéditeur de Marketing Cloud, par exemple, ajoute également des entrées pour garantir une image de marque cohérente sur toute la plate-forme / l’unité commerciale en utilisant un sous-domaine de votre domaine d’expéditeur désigné pour l’encapsulation de liens dans les e-mails, l’hébergement de CloudPages, l’hébergement d’actifs de portefeuille tels que des images via un CDN, etc. . Même si vous laissez votre fournisseur ou votre service informatique configurer ces enregistrements, il est essentiel de comprendre l’impact de ces enregistrements et quelles directives sont nécessaires pour garantir que les mesures d’authentification ont l’effet souhaité et comment vous pouvez obtenir des informations sur l’utilisation de votre domaine.

Mais passons maintenant aux mesures spécifiques pertinentes pour l’envoi d’e-mails authentifiés.

Cadre de politique de l’expéditeur (SPF)

Le Sender Policy Framework permet aux propriétaires de domaine de définir quelles adresses IP et quels noms d’hôte (représentant les serveurs de messagerie) sont autorisés à envoyer des e-mails en utilisant le domaine en question comme expéditeur dans l’adresse «enveloppe de». Ces adresses sont placées dans un enregistrement SPF qui est publié dans le DNS et demandé par les serveurs de messagerie qui reçoivent un e-mail de ce domaine. Cependant, ce n’est pas obligatoire, mais la plupart des serveurs de messagerie modernes et tous les fournisseurs de messagerie les plus utilisés les vérifient.

Composition d’un enregistrement SPF

Un enregistrement SPF est essentiellement un enregistrement TXT publié dans le DNS, qui contient les informations suivantes:

  • version de l’enregistrement SPF (par exemple v = spf1)
  • adresses IP autorisées (par exemple, ip4: 46.101.151.122)
  • hôtes autorisés (par exemple, inclure: cust-spf.exacttarget.com)
  • politique à appliquer (soit -all, ~ all ou + all), indiquant si les e-mails non autorisés doivent être bloqués, acceptés mais marqués comme échoués ou autorisés à être livrés

Un exemple d’enregistrement pourrait ressembler à ceci:

v=spf1 ip4:46.101.151.122 include:cust-spf.exacttarget.com -all

Avantages de l’utilisation du SPF

  • Amélioration de la délivrabilité de la boîte de réception
  • Réduction du risque d’utilisation malveillante de votre domaine (usurpation d’identité / hameçonnage)

Messagerie identifiée par clés de domaine (DKIM)

Ce mécanisme d’authentification ajoute la possibilité de laisser le serveur destinataire vérifier si un e-mail a été correctement signé de manière cryptographique. Pour ce faire, la clé publique de la signature numérique est placée dans une entrée TXT du DNS et chaque serveur autorisé à envoyer des e-mails à partir de ce domaine doit connaître la clé privée de cette paire de clés de signature. L’e-mail est ensuite signé et la signature ajoutée à l’e-mail sans être visible par le destinataire, sauf si l’e-mail brut est consulté. Si plusieurs systèmes sont utilisés, il est possible d’ajouter des sélecteurs aux enregistrements DKIM afin que les clés privées n’aient pas besoin d’être partagées entre les systèmes. Comme pour SPF, la vérification des signatures DKIM n’est pas obligatoire, mais tous les principaux fournisseurs de services de messagerie vérifient tous les e-mails qu’ils reçoivent pour une signature DKIM valide.

Composition d’un enregistrement DKIM

Comme déjà mentionné, un enregistrement DKIM est essentiellement un enregistrement TXT publié dans le DNS. Les parties les plus importantes sont:

  • version du protocole (par exemple v = DKIM1)
  • clé publique encodée en base64 (par exemple p = MIGfMA0GCSqGSIb3DQE…)
  • mécanisme cryptographique utilisé pour décoder la signature (ex: k = rsa)

Un exemple d’entrée pourrait ressembler à ceci:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ...

Avantages de l’utilisation de DKIM

  • Amélioration de la délivrabilité de la boîte de réception
  • Réduction du risque d’utilisation malveillante de votre domaine (usurpation d’identité / hameçonnage)
  • S’assure que le contenu de l’e-mail n’a pas été tempéré

Authentification, rapport et conformité des messages basés sur le domaine (DMARC)

DMARC est un système qui fonctionne au-dessus de SPF et DKIM et vous permet de définir une politique sur la manière dont un fournisseur de services de messagerie doit traiter les e-mails qui ne sont pas conformes à SPF et DKIM. Mais à mon avis, la meilleure chose à propos de DMARC est les capacités de reporting supplémentaires. Il vous permet de définir les destinataires des rapports d’utilisation et d’utilisation abusive du domaine, afin que vous ou un administrateur de votre organisation soyez informé de la personne qui envoie des e-mails en votre nom. Comme vous l’avez peut-être deviné, les fournisseurs de messagerie n’ont pas à prendre en compte les enregistrements DMARC, mais la plupart le font. Il existe deux types de rapports fournis avec DMARC:

RUA – Rapports agrégés

  • un résumé quotidien
  • aperçu du trafic de messagerie
  • inclut les adresses IP des systèmes qui ont tenté d’envoyer en votre nom

Exemple de rapport RUA:

Dans les «métadonnées du rapport» en haut, vous pouvez voir des informations sur la période sur laquelle porte le rapport et qui vous l’a soumis. La section «politique publiée» vous indique quelle politique l’expéditeur connaît pour votre domaine, c’est donc tout ce que le fournisseur de messagerie a récupéré à partir du DNS. Cela devrait être exactement le même que celui que vous avez configuré dans vos enregistrements – cependant, en raison de la nature du fonctionnement du DNS, vos mises à jour peuvent prendre jusqu’à 48 heures avant d’être visibles pour tous les fournisseurs de services de messagerie dans le monde.

La section des enregistrements affiche alors tous les résultats qui sont rapportés par le fournisseur contenant l’IP source, à partir de l’en-tête et les résultats de la vérification d’authentification.



  
    google.com
    noreply-dmarc-support@google.com
    https://support.google.com/a/answer/2466580
    12345678912345678900
    
      1595894400
      1595980799
    
  
  
    markus.codes
    r
    r
    

reject reject 100 xxx.xxx.xxx.xxx 1 none pass pass markus.codes markus.codes pass 50dkim1 markus.codes pass

RUF – Rapports médico-légaux immédiats

  • envoyé en temps réel
  • envoyé uniquement pour les e-mails dont l’authentification a échoué
  • comprend les en-têtes de message
  • inclut le message d’origine (uniquement vrai pour certains fournisseurs de services de messagerie)

Composition d’un enregistrement DMARC

Comme pour tous les mécanismes décrits dans cet article, DMARC est également un enregistrement TXT publié dans le DNS. Les parties les plus importantes sont:

  • version du protocole (par exemple v = DMARC1)
  • politique à appliquer aux e-mails qui échouent SPF et / ou DKIM (par exemple p = rejet)
    • aucun: DKIM est uniquement utilisé pour la création de rapports
    • quarantaine: la plupart des fournisseurs remettent l’e-mail dans des dossiers de courrier indésirable / spam
    • rejeter: dire aux fournisseurs de rejeter le message (-> rebond; pas de livraison de la boîte de réception)
  • destinataire des rapports rua (par exemple rua = mailto: domainadmin@markus.codes)
  • destinataire des rapports ruf (par exemple ruf = mailto: domainadmin@markus.codes)
  • pourcentage d’e-mails sur lesquels appliquer les règles DMARC (par exemple pct = 100 – ce paramètre par défaut est 100%, si vous implémentez DMARC pour des systèmes déjà en cours d’exécution, vous voudrez peut-être augmenter progressivement cette valeur)

Un exemple d’entrée pourrait ressembler à ceci:

v=DMARC1; p=reject; rua=mailto:domainadmin@markus.codes; ruf=mailto:domainadmin@markus.codes; pct=100

Avantages de l’utilisation de DMARC

  • tous les avantages de SPF et DKIM (si ces enregistrements sont correctement configurés)
  • des instructions supplémentaires pour le service de messagerie fournissent
  • signalement de l’utilisation et du mauvais usage du domaine

Recommandation

Si vous avez la possibilité de traiter automatiquement les rapports entrants ou si vous n’avez qu’un petit volume d’e-mails (comme pour un domaine de messagerie personnel), configurez rua- aussi bien que reporting ruf. Si vous ne vérifiez les rapports que manuellement, ruf peut être un meilleur choix pour vous, car vous ne recevez le rapport que si un envoi échoue à l’authentification, ce qui réduit le risque de manquer des informations aussi importantes.

Comment vérifier si ces enregistrements sont déjà configurés?

Comme les serveurs DNS sont disponibles dans le monde entier et que tout le monde est autorisé à les interroger, vous pouvez facilement vérifier ces enregistrements avec l’outil de votre choix. Je vais décrire comment vous pouvez récupérer ces enregistrements en utilisant les systèmes MacOS / Linux / Unix en utilisant la commande dig, mais lorsque vous travaillez sur une machine Windows, cela peut également être fait en utilisant une syntaxe légèrement différente en utilisant la commande nslookup.

Vérifier les enregistrements SPF

Pour interroger un domaine pour les enregistrements SPF, ouvrez le terminal et entrez la commande suivante (remplacez markus.codes par le domaine de votre choix):

dig markus.codes TXT

Le résultat montre un tas d’informations, mais la partie intéressante est contenue dans la «SECTION RÉPONSE»:

;; ANSWER SECTION:
markus.codes.		3600	IN	TXT	"v=spf1 include:cust-spf.exacttarget.com -all"

Afin de ne voir que le contenu des enregistrements, utilisez la commande suivante:

dig markus.codes +short TXT

Gardez à l’esprit que tous les enregistrements TXT configurés pour ce domaine sont affichés et pas seulement l’enregistrement SPF.

"v=spf1 include:cust-spf.exacttarget.com -all"

Vérifier les enregistrements DKIM

La recherche d’entrées DKIM est un peu plus difficile car vous êtes libre de choisir les sélecteurs. Donc, si vous connaissez le sélecteur utilisé, il est assez simple et similaire à la requête d’enregistrement SPF. Si vous ne connaissez pas le sélecteur, il est possible de le découvrir en fonction du système que vous utilisez. Si un package d’authentification de l’expéditeur de Marketing Cloud est utilisé, le sélecteur ressemble généralement à ceci:

[stacknumber]dkim1._domainkey

Il y a quelque temps, il s’agissait d’enregistrements TXT directement, mais pour faciliter la rotation des clés, cela a changé pour l’utilisation d’enregistrements CNAME qui délèguent l’enregistrement à un autre hôte, de sorte que Salesforce est en mesure de modifier régulièrement la paire de clés de chiffrement pour améliorer encore la sécurité. Si la nouvelle manière est déjà implémentée, cela peut être vu à partir de la réponse. Alors allez-y et tapez ce qui suit (changez à nouveau le domaine et le sélecteur en fonction de vos besoins):

dig 50dkim1._domainkey.markus.codes TXT

Encore une fois, la partie intéressante est contenue dans la «SECTION RÉPONSE» ou si vous ajoutez le +short-option seul le contenu de l’enregistrement est affiché:

;; ANSWER SECTION:
50dkim1._domainkey.markus.codes. 3600 IN CNAME	50dkim1._domainkey.s50.exacttarget.com.
50dkim1._domainkey.s50.exacttarget.com.	300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."

Dans la première ligne de la réponse, vous pouvez voir la délégation à Salesforce / ExactTarget et dans la deuxième ligne, vous pouvez voir l’enregistrement DKIM lui-même.

Vérifier les enregistrements DMARC

L’examen des enregistrements DMARC est aussi simple que des enregistrements SPF, car nous connaissons l’ensemble du domaine à interroger dans ce cas. Entrez donc la commande suivante (remplacez markus.codes par votre domaine de choix):

dig _dmarc.markus.codes TXT

Encore une fois, vérifiez la «SECTION RÉPONSE» du résultat ou utilisez le +short option:

;; ANSWER SECTION:
_dmarc.markus.codes.	3600	IN	TXT	"v=DMARC1; p=reject; rua=mailto:domainadmin@markus.codes; ruf=mailto:domainadmin@markus.codes; pct=100"





Source de l’article traduit automatiquement en Français