Sophos Email : configurer l'authentification de l'expéditeur et Smart Banners

Sophos Email contrôle les messages entrants à l’aide de DMARC, SPF et DKIM. Il peut également détecter les anomalies d’en-tête et de domaine. Ces contrôles ne déterminent pas à eux seuls le traitement du message : la Email Security policy concernée définit les types d’échec, leur ordre et les actions à appliquer. Les Smart Banners présentent le résultat aux destinataires et peuvent leur proposer des actions sûres.

Procédure rapide recommandée : Dans My Products > Email Security > Policies, ouvrez la Email Security policy concernée, puis configurez sous Settings > Inbound > Authentication les actions à exécuter en cas d’échec de DMARC, SPF ou DKIM. Dans un premier temps, choisissez Quarantine plutôt que Reject pour les échecs critiques, classez les conditions de haut en bas, puis examinez Header anomaly, Domain anomaly et End-user message settings. Comparez les messages de test légitimes et ceux en échec dans Message History avant d’ajouter des exceptions ou d’appliquer des actions plus strictes.

Préparer le périmètre, les tests et le retour arrière

Avant toute modification, identifiez les domaines et boîtes aux lettres protégés, les services d’envoi légitimes connus et un groupe de test restreint. Consignez :

la politique concernée, sa position et si elle est Enforced ;
la direction Inbound et les utilisateurs, groupes et domaines attribués ;
les règles DMARC, SPF, DKIM et de contrôle de l’expéditeur actuelles, dans leur ordre exact ;
les entrées existantes dans la liste d’autorisation et les exceptions validées par l’entreprise ;
les actions d’origine, le texte des bannières et les options proposées aux utilisateurs finaux ;
les expéditeurs et destinataires de test, ainsi que les résultats attendus.

Pour revenir à la configuration initiale, rétablissez l’ordre des règles, les actions et les options de bannière consignés, ou placez une nouvelle politique pilote sur Policy Bypassed. Pendant le pilote, ne modifiez qu’un seul ensemble cohérent de règles à la fois afin de pouvoir attribuer clairement tout résultat inattendu.

Avertissement : Ne prenez jamais une exception d’authentification comme prétexte pour désactiver l’analyse antimalware. Même un expéditeur autorisé ou correctement authentifié peut utiliser un compte compromis ou envoyer du contenu malveillant. Limitez chaque exception au problème d’authentification avéré et au périmètre strictement nécessaire, et laissez tous les autres contrôles de protection actifs.

Bien comprendre DMARC, SPF et DKIM

Ces trois méthodes répondent à des questions différentes :

SPF compare le serveur de messagerie émetteur aux hôtes, adresses IP et réseaux autorisés dans le DNS pour le domaine utilisé dans la commande MAIL FROM de l’enveloppe.
DKIM valide la signature numérique d’un message à l’aide de la clé publique publiée dans le DNS par le domaine signataire.
DMARC vérifie si SPF ou DKIM réussit et si le domaine correspondant est aligné sur le domaine visible dans l’en-tête From. Sans enregistrement DMARC valide et sans contrôle SPF ou DKIM exploitable, Sophos ne peut pas évaluer DMARC complètement.

Le commutateur affiché dans la politique commande l’action en cas d’échec ; les contrôles d’authentification eux-mêmes sont toujours exécutés. Cet article porte uniquement sur l’évaluation des messages entrants. Il ne crée ni n’héberge les enregistrements DNS de vos domaines sortants et n’active pas la signature DKIM des messages sortants.

Configurer Message Authentication

Ouvrez My Products > Email Security > Policies, sélectionnez la bonne politique Email Security, puis vérifiez son groupe cible et sa position.
Ouvrez Settings > Inbound > Authentication.
Activez les actions requises en cas d’échec pour DMARC, SPF et DKIM.
Pour chaque contrôle, cliquez sur Add Rule, puis sélectionnez un type d’échec et l’action correspondante.
Classez les conditions du cas le plus précis au cas le plus général. Sophos les examine de haut en bas et applique la première correspondance.
Enregistrez la politique et vérifiez qu’elle est Enforced pour les destinataires de test.

Sophos recommande Quarantine pour chaque catégorie de Message Authentication. Ce réglage convient également à un pilote, car le message reste disponible pour analyse et peut être libéré de manière contrôlée. Reject refuse le message pendant le traitement ; Sophos ne permet pas de consulter les en-têtes bruts des messages rejetés. Tag subject line marque le message et le transmet aux étapes de traitement suivantes. Deliver signifie également que le message passe à la couche d’analyse suivante, et non qu’il est nécessairement livré dans la boîte aux lettres. Include In End User Quarantine rend un message mis en quarantaine accessible dans la quarantaine de l’utilisateur.

Évaluer les types d’échec avec discernement

Pour DMARC, Hard failure signifie que ni SPF ni DKIM ne réussit avec l’alignement requis. Le réglage par défaut est Conform to sender policy : le traitement suit donc la politique DMARC de l’expéditeur. Les autres cas proposés sont p=none, Unsupported, Temporary failure et Permanent failure. Ici, Unsupported ne concerne que le Gateway mode, tandis que M365 bestguesspass ne concerne que le M365 Mailflow mode. Une règle p=none distincte est surtout utile lorsque Hard failure reste réglé sur Conform to sender policy.

Pour SPF, les cas disponibles en plus de Hard failure sont Soft failure, Neutral, Unsupported, Temporary failure et Permanent failure. Pour DKIM, Unsupported, Temporary failure et Permanent failure complètent Hard failure. Une erreur DNS temporaire peut disparaître sans intervention ; une erreur permanente indique que l’enregistrement publié ne peut pas être interprété. Aucun de ces résultats ne doit être automatiquement considéré comme la preuve d’une usurpation.

Ordre de traitement et Sender check

Les contrôles de Message Authentication s’exécutent dans l’ordre affiché dans la politique. Pour évaluer DMARC, Sophos effectue les contrôles SPF et DKIM nécessaires, quelles que soient les actions configurées en cas d’échec de ces contrôles. DMARC échoue si ni SPF ni DKIM ne réussit avec l’alignement requis. S’il existe plusieurs règles d’échec, la première règle correspondante, lue de haut en bas, s’applique toujours.

Si une règle DMARC, SPF ou DKIM correspond et que son action est Quarantine ou Reject, le traitement de cette branche s’arrête. Si les trois contrôles réussissent dans une configuration qui utilise ces actions, les contrôles d’anomalie d’en-tête ne sont pas poursuivis et le message est livré. L’ordre a donc un effet réel sur la sécurité ; il ne s’agit pas d’un simple classement visuel dans le portail.

Sous Sender check, Sophos ajoute deux contrôles d’anomalie :

Header anomaly protège vos propres domaines contre l’usurpation depuis l’extérieur. Ce contrôle se déclenche uniquement lorsque le domaine de l’en-tête From visible correspond à l’un des domaines configurés dans le compte Sophos Fusion (anciennement Sophos Central) et que cette adresse d’en-tête diffère de l’adresse MAIL FROM de l’enveloppe SMTP. Tous les domaines du compte sont contrôlés, pas seulement celui du destinataire.
Domain anomaly détecte les domaines d’expéditeur qui ne possèdent ni enregistrement MX ni enregistrement A.

Pour ces deux contrôles, vous pouvez sélectionner Tag subject line, Quarantine, Reject ou Deliver ; Tag subject line est le réglage par défaut documenté. Pendant le pilote, utilisez le marquage ou la quarantaine et examinez les transferts légitimes, les systèmes CRM, les plateformes de gestion des tickets et les services d’envoi externes avant d’activer Reject.

Configurer Smart Banners

Sous End-user message settings, activez séparément chaque type de bannière, adaptez son texte prédéfini et sélectionnez les actions à proposer aux utilisateurs. Ces réglages s’appliquent aux messages externes entrants, qu’ils soient au format HTML ou texte brut. Les messages Sophos, tels que les récapitulatifs de quarantaine, ne reçoivent pas de Smart Banner.

La couleur et le message de la bannière dépendent de la liste d’autorisation et du résultat DMARC :

Trusted est verte : l’expéditeur figure dans la liste d’autorisation et le message a réussi la vérification DMARC.
External est jaune : l’expéditeur a réussi la vérification DMARC, mais ne figure pas dans la liste d’autorisation ; il y figure, mais Trusted est désactivé ; ou il ne possède aucun enregistrement DMARC, de sorte qu’aucun résultat positif ou négatif ne peut être établi.
Untrusted est orange : une politique DMARC existe, mais le message n’a pas réussi la vérification DMARC.

Une bannière aide à prendre une décision, mais ne prouve pas que le message est inoffensif. Même une bannière verte ne remplace ni l’analyse du contenu ni la prudence lors de l’ouverture des liens et des pièces jointes.

Activer les actions utilisateur en toute sécurité

Pour chaque bannière, vous pouvez proposer Allow sender, Block sender et Report Spam messages to Sophos. Allow et Block ouvrent une page de confirmation et mettent à jour la liste personnelle de l’utilisateur ; Report transmet le message à SophosLabs en tant que spam.

Le guide sur les exceptions Inbound Allow/Block explique l’interaction entre les entrées personnelles et globales et leur sécurisation par l’authentification, l’export, l’import et le retour arrière.

Pour que Allow sender et Block sender fonctionnent dans la bannière HTML, ouvrez Global Settings > Products and Services > Email > User Settings, activez d’abord Release/Delete, puis Allow/Block List, et enregistrez. Les liens Allow et Block ne sont pas proposés dans les bannières en texte brut.

Les messages sortants doivent être acheminés via Sophos Fusion lorsque les liens des Smart Banners sont utilisés. Sophos recommande de mettre ce routage en place avant d’activer End-user message settings ; sinon, les destinataires externes risquent de voir la bannière dans les réponses ou les messages transférés. En HTML, elle s’affiche en couleur en haut du message ; en texte brut, elle apparaît au début du corps. Une bannière existante peut rester visible lorsqu’un message reçoit une réponse ou est transféré en interne.

Valider le résultat dans Message History

Pour chaque périmètre de politique concerné, envoyez à un destinataire pilote des messages entrants contrôlés :

un message légitime censé réussir l’authentification ;
un message légitime passant par un service de transfert ou d’envoi connu ;
lorsque cela peut être fait sans risque, un message provenant de votre propre domaine de test et présentant un échec d’authentification volontairement provoqué et documenté.

Ne falsifiez pas d’e-mail de production et ne modifiez pas les enregistrements DNS d’un tiers pour effectuer un test. Dans Message History, effectuez une recherche par expéditeur, destinataire et plage horaire, ouvrez le message, puis comparez la politique appliquée, la catégorie, les détails d’authentification ou de contrôle de l’expéditeur et l’action réellement exécutée. Pour les messages livrés, vérifiez aussi le type, le texte, la couleur et les actions visibles de la bannière, en HTML comme en texte brut. Le résultat est correct lorsque les messages légitimes atteignent l’étape d’analyse suivante ou la boîte aux lettres prévue, que les échecs déclenchent la première action configurée correspondante et qu’aucune action utilisateur inattendue n’est proposée.

Procéder méthodiquement au dépannage

Échec DMARC ou DKIM inattendu : Conservez les en-têtes bruts et les détails du contrôle de l’expéditeur. Vérifiez si une passerelle en amont, une clause de non-responsabilité, une liste de diffusion ou un circuit de transfert a modifié le corps ou les en-têtes signés. Lorsque Sophos EMS se trouve notamment derrière un autre système principal de sécurité de la messagerie, ces modifications peuvent invalider DKIM et l’alignement DMARC ; l’échec seul ne prouve alors pas l’existence d’un risque.
Action incorrecte malgré une règle correspondante : Vérifiez d’abord le périmètre, l’application et l’ordre des politiques, puis parcourez les règles d’échec de haut en bas. Une règle générale placée plus haut peut masquer une règle précise située plus bas.
Header anomaly pour un service légitime : Comparez l’en-tête From visible au MAIL FROM de l’enveloppe et identifiez lequel de vos domaines a correspondu. Corrigez d’abord la configuration d’envoi ou l’alignement. N’envisagez une exception d’authentification très ciblée que si cette correction est impossible et si le service est identifié avec certitude.
Domain anomaly pour un message légitime : Testez séparément la résolution des enregistrements MX et A du domaine expéditeur. Ne répondez pas à un problème DNS temporaire par une règle d’autorisation globale et permanente.
Bannière absente : Vérifiez que la bonne politique et le bon type de bannière sont actifs, que le message est externe et entrant, et qu’il ne s’agit pas d’un message système Sophos.
Allow/Block absent ou inopérant : Vérifiez Release/Delete et Allow/Block List dans User Settings, le format HTML et le routage sortant via Sophos. Ces liens ne sont pas disponibles en texte brut.

Ce n’est qu’après cette analyse que vous devez modifier l’ordre, l’action ou l’entrée strictement nécessaire et la plus ciblée dans la liste d’autorisation, puis répéter le même test. Si le résultat reste incertain, rassemblez le Message-ID, l’horodatage, l’expéditeur, le destinataire, le nom de la politique, l’action exécutée et les en-têtes bruts complets en vue d’une escalade, plutôt que de contourner largement l’authentification ou la protection antimalware.