Office 365 : comment améliorer la délivrabilité et la sécurité de vos e-mails ?

I. Présentation

Que ce soit avec Office 365 et Exchange Online, ou une autre solution de messagerie, lorsque l'on parle d'e-mails, il y a deux termes qui reviennent encore et encore, constamment : sécurité et délivrabilité.

En tant qu’administrateur infrastructure, on souhaite éviter autant que possible de recevoir les mails de type spam, phishing, contenant des pièces jointes frauduleuses. Alors on met en place des filtres anti-phishing, antispam. On cherche aussi à sécuriser les e-mails au départ de notre serveur de messagerie, et faire en sorte qu’ils soient sains. Et puis on souhaite enfin s’assurer que nos mails passent les filtres de sécurité des serveurs de messagerie distants sans encombre, et arrivent directement dans la boîte mail du destinataire, sans passer par la case spam.

Avec Office 365, il y a plusieurs manières (complémentaires) d’arriver à nos fins. L’une d’entre elles est de passer par le trio gagnant des enregistrements DNS : « SPF », « DKIM » et « DMARC ».

II. Prérequis

• Avoir un serveur Exchange Online, et les licences Office365 associées
• Un nom de domaine enregistré
• Un nom de domaine configuré dans Office 365
• PowerShell en version 5.1 ou +

III. Pourquoi l’enregistrement SPF n’est pas suffisant ?

Bon, je vous vois venir, vous allez me dire que lorsque vous configurez un nouveau domaine dans Office 365, vous devez obligatoirement configurer un enregistrement SPF dans votre zone DNS, et que cet enregistrement sert déjà à améliorer la sécurité et la délivrabilité de vos mails. Alors, à quoi bon s’embêter avec DKIM et DMARC ?

On va la faire courte : SPF est bien entendu nécessaire, mais n’est absolument pas suffisant. C’est là que DKIM et DMARC entrent en jeu.

Je vous explique.

A. SPF – Comment ça marche ?

SPF (ou Sender Policy Framework) est une norme adoptée à l’international qui permet de réduire les spams au niveau de votre serveur.

Concrètement, l’enregistrement SPF sert à authentifier l’expéditeur d’un courrier électronique. Cela permet de vérifier que le serveur qui envoie un mail à partir d’une adresse mail en @mondomaine.com est bien un serveur légitime.

Le nom de domaine de l’émetteur est extrait de l’en-tête du mail reçu (« MAIL FROM : »), et une requête DNS est émise sur ce domaine pour connaître la liste des serveurs de messagerie légitimes qui peuvent émettre des mails pour ce domaine précis. On compare alors cette liste de serveurs à l’adresse IP du serveur qui a émis le message.

Par exemple dans mon cas, comme mes domaines sont configurés sur Office 365, seuls les serveurs Exchange Online du tenant Office 365 sont autorisés à envoyer des mails à mon nom.

Du coup, si jamais quelqu’un essaye de se faire passer pour moi en envoyant un mail en mon nom, son serveur ne sera pas reconnu comme légitime et le mail pourra donc être classifié comme mail frauduleux / spam.

SPF est donc devenu un indispensable pour :

• Augmenter la délivrabilité globale de ses mails
• Se défendre contre l’usurpation d’identité de domaine, ainsi que l’usurpation d’adresse électronique (mail)

Cependant, SPF ne sait pas gérer les transferts de mail, et c’est là que les enregistrements DKIM entrent en jeu.

B. SPF – Les bonnes pratiques

L’enregistrement SPF est un enregistrement dans votre zone DNS publique de type TXT qui contient la liste des serveurs de messagerie autorisés à envoyer un mail pour votre domaine.

Voici une bonne pratique à respecter en toute circonstance : incluez toujours vos serveurs sous la forme server.mondomaine.com, ne listez pas les adresses IP une par une.

A. Vérifier la configuration SPF

Vous pouvez vérifier la validité de votre enregistrement SPF en utilisant cet outil gratuit.

Renseignez dans le champ votre nom de domaine, puis cliquez sur le bouton « Valider DNS ».

Vous obtiendrez alors un résultat complet de l’analyse de votre enregistrement SPF.

Dans mon cas, ma configuration SPF est validée, et le serveur spf.protection.outlook.com (correspondant à Office 365) est bien celui qui est déclaré. Tout est parfait! 🙂

 

IV. Comprendre et configurer DKIM

A. DKIM – Comment ça marche ?

DKIM est un acronyme pour Domain Keys Identified Mail. Cette technologie permet d’envoyer un message chiffré, et de s’assurer que celui-ci n’a subi aucune altération durant sa transition entre le serveur émetteur et le serveur récepteur.

Rassurez-vous, le contenu du mail n’est pas chiffré, et votre destinataire pourra continuer à lire le message sans vous demander de clé de déchiffrement.

Au moment où vous envoyez votre mail, le serveur émetteur le chiffre via sa clé DKIM privée. Le serveur récepteur va lui vérifier la clé DKIM publique (l’enregistrement DKIM de votre zone DNS), et comparer celle-ci avec ce qu’il a reçu. Si le test est concluant, alors le serveur émetteur est bien qui il prétend être, l’identité de l’émetteur est prouvée et le mail peut donc être délivré dans la boîte mail du destinataire.

DKIM permet donc de s’affranchir des attaques de type « man in the middle ».

Note : Cette signature DKIM se gère dans l’en-tête du mail envoyé. Cela est donc transparent pour l’utilisateur final. Comme cette signature reste dans l’en-tête, cela permet de continuer à certifier l’exactitude du mail initial si celui-ci est transféré à une tierce personne.

 

B. Pourquoi DKIM est aujourd’hui indispensable ?

Je vous conseille fortement de mettre en place DKIM en plus de vos enregistrements SPF. Pourquoi ?

Parce que DKIM prouve que le contenu du mail ainsi que les en-têtes n’ont subi aucune altération : le mail est donc authentique et légitime : personne ne l'a envoyé à votre place, et le serveur de messagerie distant est maintenant en capacité de le vérifier.

C. Configuration de DKIM pour votre domaine

Tout d’abord, ouvrez une console PowerShell et commencez par vous connecter à votre serveur Exchange Online :

Import-Module ExchangeOnlineManagement

Connect-ExchangeOnline

Avant de commencer, vérifions ensemble que mondomaine.com soit bien déclaré comme un nom de domaine utilisable par Exchange :

Get-AcceptedDomain

Vous devriez voir mondomaine.com dans la liste.

Nous allons ensuite initialiser la configuration DKIM de notre nom de domaine mondomaine.com :

New-DkimSigningConfig -DomainName mondomaine.com -Enabled $false

 

Note : Vous pouvez utiliser le paramètre -Keysize 2048 dans la commande précédente, pour forcer la taille de votre clé DKIM à 2048 bits. Pas de panique toutefois, si vous ne l'avez pas fait, vous pourrez toujours y apporter des modifications plus tard en production.

Bien. Maintenant, il nous reste à générer les enregistrements DNS « DKIM » que nous devrons ajouter dans notre zone DNS publique.

Pour cela, tapez la commande :

Get-DkimSigningConfig -Identity mondomaine.com | Format-List Selector1CNAME, Selector2CNAME

Dans mon cas, je vais donc devoir créer 2 enregistrements CNAME sur ma zone DNS :

Prenons 30 secondes pour analyser la structure des enregistrements selector1 et selector2 à créer. Ces deux enregistrements se composent comme suit :

selector<id>-<domaine>-<extension>._domainkey.<tenantOffice365>.onmicrosoft.com

Pour le domaine mondomaine.com, cela donnerait donc :

• selector1-mondomaine-com._domainkey.mondomaine.onmicrosoft.com
• selector2-mondomaine-com._domainkey.mondomaine.onmicrosoft.com

Il ne nous reste plus qu'à créer ces deux enregistrements CNAME dans notre zone DNS avec le paramétrage suivant :

• Nom : selector1._domainkey & selector2._domainkey
• TTL : 3 600 secondes

Note : Pensez bien à ajouter un point (.) à la fin du nom de domaine, pour indiquer que vous souhaitez pointer vers selector1-mondomaine-com._domainkey.mondomaine.onmicrosoft.com (domaine externe).

 

Attendez maintenant quelques secondes, le temps que votre zone DNS se réplique, puis lancez la commande suivante afin d’activer l’utilisation de DKIM pour mondomaine.com.

Set-DkimSigningConfig -Identity mondomaine.com -Enabled $true

Note : Si vous obtenez une erreur, soit une faute s’est glissée dans votre enregistrement DNS de type CNAME (pensez à bien vérifier le point final), soit vous n’avez pas attendu assez longtemps pour que la réplication de votre zone DNS soit effectuée.

D. Vérifier la configuration DKIM

Pour vérifier la bonne configuration de DKIM sur votre domaine, je vous conseille d’utiliser ce lien.

Renseignez l’un des 2 sélecteurs configurés, ainsi que votre nom de domaine, puis cliquez sur le bouton « Valider DNS ».

Note : Ne saisissez que selector1, l'outil va compléter automatiquement le reste de l'enregistrement DNS. Si vous saisissez selector1._domainkey, le test échouera.

Vous pouvez donc voir que dans mon cas l’enregistrement DKIM du sélecteur 1 est valide.

Note : Pensez bien à refaire cette étape pour chacun des sélecteurs DKIM configurés pour votre domaine.

Vous pouvez également, lorsque vous êtes connectés à votre serveur Exchange en PowerShell, exécuter la commande suivante :

Get-DkimSigningConfig -Identity mondomaine.com

Je n'obtiens pas d'erreur, mon domaine est donc correctement configuré avec DKIM.

V. Comprendre & configurer DMARC

A. DMARC – Comment ça marche ?

DMARC est un acronyme pour Domain-based Message Authentication, Reporting, and Conformance. DMARC utilise SPF et DKIM pour authentifier les expéditeurs d’emails, et fournit une protection supplémentaire.

En effet, SPF et DKIM permettent d’authentifier un expéditeur (ou non). Mais ils ne donnent aucune indication sur la conduite à tenir dans le cas d’une usurpation d’identité avérée.

C’est là que DMARC entre en jeu : lorsqu’on configure cet enregistrement DNS, on lui indique une politique à tenir. Cela permet au serveur de messagerie de savoir quoi faire de ces mails : faut-il les rejeter ? les mettre en quarantaine ? Ne rien faire mais l’historiser ?

A vous de le décider, et ça se passe dans DMARC.

B. Configuration de DMARC pour votre domaine

Afin de configurer DMARC pour votre domaine, il n’est pas nécessaire de faire des manipulations PowerShell : tout se passe dans votre zone DNS.

Il vous faut créer l’enregistrement TXT suivant dans votre zone DNS :

• Type : TXT
• Nom : _dmarc
• TTL : 3 600 secondes
• Valeur : « v=DMARC1 ; p=<policy>; rua=mailto:[email protected]; pct=100; adkim=s; aspf=s »

Quelques explications :

Pct=100 indique que cette règle s’applique à 100% des emails.

adkim=s indique que la règle d'alignement avec DKIM est stricte. Seuls les mails partant du domaine mondomaine.com sont valides. Les mails en provenance d'un sous-domaine de mondomaine.com ne sont pas considérés comme valides.

aspf=s indique que la règle d'alignement avec SPF est stricte. L'en-tête "De" du mail doit correspondre exactement au nom de domaine de la commande SMTP "MAIL FROM".

Le paramètre rua est optionnel. Si vous l'indiquez comme ici, cela permettra d'envoyer des rapports sur l'activité DMARC à l'adresse mail [email protected].

Vous pouvez remplacer <policy> par 3 valeurs. Il s’agit ici de configurer la stratégie à appliquer sur le serveur de messagerie si un mail est rejeté par DMARC :

• None : vous êtes en mode surveillance uniquement.
• Quarantine : les mails qui ne passent pas DMARC sont mis en quarantaine.
• Reject : les mails qui ne passent pas DMARC sont rejetés

Note : Je vous conseille de commencer par la stratégie none. Cela vous permet d’analyser l’impact de DMARC sur les mails reçus lorsque vous le passerez en mode quarantaine. On ne sait pas exactement la quantité de messages que l’on risque de perdre (non délivrés dans la boîte de réception du destinataire) via une stratégie DMARC restrictive, commencez donc par la stratégie de surveillance « none ».

C. Vérifier la configuration DMARC

Afin de vérifier que votre enregistrement DMARC est bien configuré sur votre zone, je vous invite à utiliser ce lien.

Renseignez alors le nom du domaine à vérifier, et cliquez sur le bouton « Valider DNS ».

Si vous avez suivi mes recommandations sur l’implémentation de DMARC, vous devriez donc avoir un enregistrement présent avec une stratégie de type « none ».

VI. Et si on regardait les en-têtes de nos mails ?

Avant de nous quitter, vérifions maintenant ce qui se passe dans l’en-tête des mails en sortie de notre serveur de messagerie.

Je me suis donc envoyé un mail de mon adresse [email protected] à mon adresse Gmail personnelle, puis j’ai affiché l’intégralité du message pour pouvoir consulter l’en-tête.

On peut voir que le mail a bien été envoyé à partir d’un serveur Exchange Office365, nommé FRA01-PR2-obe.outbound.protection.outlook.com, et qu’il a été réceptionné par le serveur mx.google.com.

On peut également voir 4 mentions importantes dans la section Authentication-Results :

• Dkim=pass
• Arc=pass
• Spf=pass
• Dmarc=pass

Ces mentions indiquent que la configuration SPF, DKIM et DMARC mise en place ensemble est fonctionnelle, et que ce mail est légitime. Autrement dit :

• Le serveur ayant envoyé le mail est bien un serveur autorisé et légitime pour envoyer des mails du domaine mondomaine.com
• Le mail a bien été envoyé par [email protected], il n’y a donc pas d’usurpation d’identité.

 

Note : On peut également voir deux points supplémentaires :

• L’échange du mail entre les deux serveurs de messagerie s’est bien effectué de façon sécurisée : le protocole TLS 1.2 a été utilisé pour cela.
• La politique DMARC actuellement mise en place pour ce domaine est sur « none », comme je vous le conseille dans un premier temps. Pour l’anecdote, elle va changer dans les prochains jours pour passer en « quarantine ».

VII. Conclusion

Vous n’avez maintenant plus aucune excuse pour ne pas correctement configurer vos enregistrements SPF, DKIM et DMARC.

Et si vous êtes amenés à expliquer à vos collègues ou à votre DSI l’intérêt de configurer ces enregistrements, retenez simplement que cela :

• Renforce la protection antispam & anti-phishing
• Augmente la sécurité de votre serveur de messagerie
• Permets de contrer les attaques « man in the middle » ainsi que l’usurpation de domaine et l’usurpation d’identité
• Favorise la délivrabilité de vos mails

Sachez enfin que Google, Microsoft et Yahoo travaille sur un nouveau standard pour toujours plus renforcer la sécurité et la délivrabilité des mails, j’ai nommé BIMI.