Sécurité et Microsoft 365

Pourquoi vos courriels vont aux pourriels ou peuvent être usurpés

Par l’équipe Montréal TI

Un client dit ne pas avoir reçu votre facture. Une infolettre arrive dans les pourriels. Un fournisseur reçoit un faux message qui semble provenir de votre domaine.

Ces situations sont différentes, mais elles partagent souvent un même point : les serveurs destinataires essaient de décider si le message est réellement autorisé à utiliser votre nom de domaine.

Pour trancher, les serveurs destinataires croisent plusieurs signaux. SPF, DKIM et DMARC comptent parmi les principaux.

Une adresse visible n’est pas une preuve d’identité

Le champ « De » d’un courriel ressemble à l’adresse inscrite sur une enveloppe. Sans mécanismes de validation, un expéditeur peut tenter d’afficher une adresse qu’il ne contrôle pas.

C’est ce qu’on appelle l’usurpation de courriel ou de domaine.

L’authentification du courriel aide les systèmes destinataires à vérifier :

  • quels serveurs sont autorisés à envoyer;
  • si le message a été signé par le domaine;
  • si les domaines techniques correspondent au domaine visible;
  • quoi faire lorsqu’un message échoue les vérifications.

Aucun mécanisme seul n’est suffisant. Ils fonctionnent ensemble.

SPF : quels serveurs peuvent envoyer pour le domaine?

SPF est un enregistrement DNS qui indique les sources autorisées à envoyer du courriel pour un domaine.

Il peut inclure :

  • Microsoft 365;
  • un système de facturation;
  • une plateforme d’infolettres;
  • un CRM;
  • un site Web;
  • un fournisseur de billets ou de formulaires;
  • un service de numérisation ou d’alerte.

Les problèmes fréquents :

  • une source légitime a été oubliée;
  • plusieurs enregistrements SPF existent alors qu’il ne devrait y en avoir qu’un;
  • l’enregistrement dépasse les limites techniques;
  • une ancienne plateforme reste autorisée;
  • le domaine technique utilisé par l’expéditeur ne correspond pas au domaine visible.

SPF vérifie surtout la source d’envoi. Il ne suffit pas, à lui seul, à protéger le nom affiché au destinataire.

DKIM : le message est-il signé par le domaine?

DKIM ajoute une signature cryptographique au message.

Le serveur destinataire utilise une clé publiée dans le DNS pour vérifier que :

  • le message provient d’un système autorisé à signer pour le domaine;
  • certaines parties importantes n’ont pas été modifiées pendant le transport.

Dans Microsoft 365, DKIM doit être activé pour chaque domaine personnalisé utilisé pour l’envoi.

Les problèmes fréquents :

  • DKIM n’a jamais été activé;
  • les enregistrements DNS sont absents ou incorrects;
  • un service tiers signe avec son propre domaine plutôt que le vôtre;
  • un système ajoute ou modifie du contenu après la signature;
  • une migration a laissé une ancienne configuration.

DMARC : que faire lorsque les vérifications échouent?

DMARC relie le domaine visible aux résultats SPF et DKIM.

Il permet au propriétaire du domaine de publier une politique :

  • observer seulement;
  • mettre en quarantaine les messages qui échouent;
  • les rejeter.

DMARC permet aussi de recevoir des rapports sur les sources qui utilisent le domaine.

Les rapports peuvent notamment révéler :

  • une plateforme légitime oubliée;
  • une mauvaise configuration;
  • un système ancien encore actif;
  • des tentatives d’usurpation;
  • un sous-domaine non protégé.

Passer directement à une politique de rejet sans inventaire peut bloquer des messages légitimes. Le déploiement devrait commencer par l’identification des sources, la correction de SPF et DKIM, puis l’augmentation contrôlée de la politique.

Pourquoi un courriel légitime arrive quand même aux pourriels

L’authentification n’est qu’une partie de la décision.

Les fournisseurs de messagerie examinent aussi :

  • réputation de l’adresse IP ou du domaine;
  • volume et variations d’envoi;
  • plaintes et taux de rejet;
  • liens et pièces jointes;
  • contenu répétitif ou trompeur;
  • liste de destinataires mal entretenue;
  • serveur compromis;
  • messages transférés ou modifiés;
  • nouvelles sources sans historique;
  • cohérence entre l’adresse visible, la signature et le chemin d’envoi.

Un message peut donc réussir SPF, DKIM et DMARC tout en étant filtré pour d’autres raisons. À l’inverse, un message mal authentifié peut parfois être livré selon les autres signaux du destinataire.

Le site Web et les applications sont souvent oubliés

Une entreprise configure Microsoft 365 correctement, puis un formulaire Web, un photocopieur ou un logiciel comptable commence à envoyer sous le même domaine.

Sans coordination, ces messages peuvent :

  • échouer l’authentification;
  • être rejetés;
  • arriver aux pourriels;
  • forcer un SPF trop complexe;
  • utiliser un mot de passe partagé;
  • envoyer par une ancienne boîte aux lettres;
  • exposer un compte si le service est compromis.

Chaque source d’envoi devrait avoir un propriétaire, une raison d’affaires, une méthode d’authentification et une date de revue.

Pourquoi l’usurpation reste possible même avec de bons filtres

Les filtres du destinataire protègent sa boîte. Ils ne remplacent pas la configuration de votre domaine.

Un attaquant peut aussi utiliser :

  • un domaine presque identique;
  • un nom d’affichage trompeur;
  • une boîte réellement compromise;
  • une chaîne de réponse volée;
  • un fournisseur légitime mal configuré;
  • un compte personnel qui imite un employé.

SPF, DKIM et DMARC réduisent l’usurpation directe du domaine, mais doivent être complétés par :

  • authentification multifacteur;
  • protection contre l’hameçonnage;
  • formation des employés;
  • validation indépendante des demandes financières;
  • surveillance des connexions et règles de transfert;
  • procédures de signalement.

Revue rapide du domaine de courriel

Une revue à portée définie devrait vérifier :

1. Quel service reçoit le courriel? 2. Quelles plateformes envoient avec le domaine? 3. Existe-t-il un seul enregistrement SPF valide? 4. DKIM est-il actif pour chaque domaine d’envoi? 5. DMARC existe-t-il et quelle politique applique-t-il? 6. Les rapports DMARC sont-ils reçus et analysés? 7. Les sous-domaines et domaines inutilisés sont-ils protégés? 8. Les connecteurs, relais et transferts sont-ils documentés? 9. Les anciens fournisseurs sont-ils encore autorisés? 10. Les en-têtes d’un message réel montrent-ils des résultats cohérents?

Le résultat devrait distinguer :

  • configuration correcte;
  • source légitime à corriger;
  • ancienne source à retirer;
  • risque d’usurpation;
  • problème de réputation ou de contenu;
  • action nécessitant un autre fournisseur.

Que faire lorsqu’un message est rejeté

Conservez :

  • le message de non-remise complet;
  • l’heure;
  • l’adresse de l’expéditeur et du destinataire;
  • le service utilisé pour envoyer;
  • les en-têtes d’un message reçu lorsque disponible;
  • les changements DNS récents;
  • un exemple qui fonctionne et un qui échoue.

Évitez de modifier plusieurs enregistrements DNS au hasard. Un correctif rapide peut rendre le diagnostic plus difficile ou interrompre une autre plateforme.

Une évaluation de sécurité Microsoft 365 peut inclure les identités, privilèges, règles de transfert, connecteurs et capacités de journalisation. Une revue DNS et d’authentification du courriel peut être définie séparément selon les systèmes d’envoi.

Lorsque plusieurs services envoient avec votre domaine, une relation de TI gérée ou cogérée peut aider à garder les propriétaires, les fournisseurs et les changements documentés au même endroit.

Communiquer avec Montréal TI pour examiner SPF, DKIM, DMARC, les sources d’envoi et les preuves de livraison.

Ressources liées

Clarifier la base courriel et domaine Revoir la confiance courriel