Déterminez ce que fait le service de sécurité sur votre itinéraire
Un nom de point de perception dans une console de sécurité de messagerie n'établit pas que le service est à l'origine des messages de votre organisation ou qu'il les signe avec votre domaine. Commencez par l’intégration réellement déployée. Identifiez la plate-forme de boîte aux lettres, la méthode d'analyse entrante, la portée de l'analyse sortante et tout relais SMTP distinct. Cet article fournit une méthode d’identification et de vérification d’itinéraire. Les preuves de première main disponibles n'établissent pas de point de perception universel SPF inclure ou domaine client DKIM installation.
La documentation WP actuelle sur docs.perception-point.io porte la marque FortiMail Workspace Security. C'est Page d'intégration sortante Microsoft 365 décrit l'analyse sortante via une connexion API Microsoft 365 , ajoutée à une intégration entrante existante. Cette fonction documentée est une inspection de sécurité et non une preuve d'une nouvelle identité d'envoi SMTP . Confirmez que ces instructions produit s'appliquent au déploiement avant d'utiliser leurs contrôles.
Tracez l'itinéraire et attribuez chaque responsabilité
Créez un court flux depuis l'application ou la boîte aux lettres jusqu'au destinataire final. Pour chaque composant, enregistrez s'il génère le message, soumet SMTP , relaie SMTP , signe DKIM , numérise une copie ou prend une décision de livraison côté destinataire. Demandez aux propriétaires de la plateforme de fournir des preuves de configuration plutôt que de vous fier au logo du produit dans le pied de page d'un e-mail.
Séparez au moins trois questions. Quel système transmet le message au destinataire ? Quel domaine le signe ? Quel service de sécurité l'inspecte ? Un produit peut remplir plus d’un rôle, mais ces rôles doivent être démontrés. Si le message est un courrier sortant Microsoft 365 ordinaire observé via une API, n’ajoutez pas la plage d’adresses IP entrantes non liées d’une passerelle à votre stratégie d’expéditeur simplement parce que la passerelle protège le locataire.
Distinguez également les messages générés par l'organisation des notifications générées par le service de sécurité lui-même. Un rapport ou une alerte envoyé par le produit peut utiliser un expéditeur et un itinéraire différents de ceux de l'e-mail d'un employé. N'utilisez pas les en-têtes d'une alerte comme preuve d'authentification pour une correspondance commerciale, ou inversement.
Interpréter les preuves numérisées dans ses limites
Pour l'itinéraire Microsoft 365 documenté, le fournisseur décrit les vérifications de l'analyse sortante activée et de l'étendue de la connexion sortante, avec des résultats visibles sur la page Analyses. Il indique que l'analyse sortante ne bloque pas les messages sortants et ne fournit pas de quarantaine sortante. Le procédure d'intégration avertit également que la portée sélectionnée peut affecter la configuration d'analyse existante. Demandez à l'administrateur de sécurité d'examiner cette étendue avant de modifier quoi que ce soit.
Ces observations peuvent établir qu'un message a été analysé dans une intégration nommée. Ils n'établissent pas d'autorisation SPF , une validité Signature DKIM ou DMARC alignement sur un récepteur externe. Conservez les résultats de l'analyse et les résultats du récepteur dans des champs de preuve distincts afin qu'un verdict sans équivoque ne remplace pas l'authentification.
Le documentation de l'en-tête du verdict indique que les en-têtes X-PERCEPTION-POINT répertoriés ne sont pas ajoutés par l'analyse de l'API Microsoft 365 ou Google Workspace et ne sont pas ajoutés aux e-mails sortants. Leur absence ne constitue donc pas en soi une preuve que l’analyse sortante a échoué. Leur présence sur un autre message ne les transforme pas non plus en décision DMARC d'un destinataire externe.
Configurez l'expéditeur réel uniquement après identification
Une fois que l'expéditeur SMTP et le service de signature sont connus, utilisez la procédure de configuration propriétaire applicable à ce service. Obtenez ses enregistrements de domaine émis et sa preuve d'activation. Si un déploiement vérifié utilise réellement un relais sortant supplémentaire, demandez les instructions actuelles d'authentification de domaine et de signature du relais pour ce locataire plutôt que d'extrapoler à partir du guide de sécurité entrant.
SPF autorise l'identité SMTP applicable et a des contraintes de sélection d'enregistrement et de recherche DNS sous RFC 7208. DKIM identifie un domaine de signature et sélecteur sous RFC 6376. DMARC associe une identité authentifiée transmise au domaine From visible sous RFC 9989. Une liste d’autorisation IP, un consentement API ou une analyse réussie des menaces ne remplace pas ces vérifications.
Évitez les listes autorisées larges comme raccourci de diagnostic. Cela peut modifier le traitement de sécurité local tout en masquant l’échec initial. Si le problème est un rejet du destinataire, conservez le code de rejet, l’heure, le système du destinataire prévu et un identifiant de message expurgé. Si le problème concerne la couverture de sécurité, examinez la portée de l'analyse et l'enregistrement d'analyse correspondant. Résolvez l'échec spécifique au lieu de traiter chaque problème de livraison comme une demande de modification SPF .
Feuille de travail de déploiement de Perception Point
Remplissez cette feuille de travail avant de proposer des enregistrements d'authentification :
- Nom du produit indiqué dans le locataire et le contrat : ____ ; documents applicables : ____.
- Plateforme de boîte aux lettres, locataire et région de déploiement : ____.
- Méthode d'intégration entrante : ____ ; méthode et portée de l’analyse sortante : ____.
- Application génératrice de messages et propriétaire : ____ ; Expéditeur ou relais SMTP : ____.
- Service de signature DKIM et propriétaire : ____ ; preuve le reliant à l'itinéraire: ____.
- Classification des notifications par rapport aux messages professionnels : ____.
- Test contrôlé ID de message et heure UTC : ____ ; enregistrement d'analyse correspondant : ____.
- Récepteur externe, visible depuis et domaine de l'enveloppe : ____.
- DKIM d= et s=: ____ ; Résultats SPF , DKIM et DMARC fiables : ____.
- Modification DNS proposée et source réelle de l'expéditeur : ____ ; hypothèses non étayées : ____.
- Décision pilote, propriétaire de la récupération et examinateur humain : ____.
Si l'expéditeur SMTP ou le propriétaire signataire est inconnu, la feuille de calcul n'est pas prête pour une modification DNS . Poursuivez l'enquête en lecture seule et demandez à l'administrateur responsable les preuves d'itinéraire manquantes.
Diagnostic fictif des en-têtes de verdict manquants
Exemple fictif uniquement : Summit Design permet l'analyse des API sortantes et envoie un message contrôlé. Son administrateur ne voit aucun en-tête de verdict X-PERCEPTION-POINT et suppose que le message a contourné la protection. La limitation d'en-tête documentée explique pourquoi cette attente n'est pas adaptée à cet itinéraire. L'équipe vérifie la couverture de sécurité de l'entrée d'analyse correspondante du message, puis examine séparément les résultats d'authentification du destinataire externe pour l'expéditeur réel de la boîte aux lettres.
L'ajout d'adresses IP de service de sécurité à la politique SPF de l'organisation ne répondrait à aucune des deux questions sans preuve que ces adresses IP transmettent le message sortant. L'équipe laisse DNS inchangé pendant qu'elle confirme l'itinéraire. Aucun déploiement Summit, console d'analyse, zone DNS ou message reçu n'a été testé pour ce manuscrit.
Portée et portes restantes
Le vaste sujet initial sur la configuration de l’expéditeur reste en suspens. Ce candidat identifie la frontière entre l'analyse documentée et les capacités d'envoi non vérifiées du domaine client ; il ne prétend pas que ces capacités sont universellement absentes. L'applicabilité réelle du produit, l'acheminement et la signature de la propriété, les instructions émises par le locataire le cas échéant, les preuves d'analyse et de réception en direct, l'examen rendu, l'approbation humaine de la PME et la publication restent en attente.
Enregistrez l'effet de portée avant de modifier la numérisation
Pour l'intégration documentée de l'API Microsoft 365 , le fournisseur prévient qu'une nouvelle sélection de domaines, groupes ou utilisateurs remplace la portée entrante, interne et sortante existante. Avec une intégration entrante en ligne existante, la sélection affecte uniquement la couverture sortante. Traitez cela comme une décision de couverture de sécurité exigeant son propriétaire, et non comme un correctif d'authentification.
Séparer l’acceptation des messages du déploiement de la politique
Un résultat SPF aligné peut satisfaire une évaluation de message, mais ne justifie pas à lui seul le déplacement d'un domaine entier vers le rejet. RFC 9989 La section 7.4 nécessite DKIM valide pour la publication de domaines p=reject et met en garde contre l'interopérabilité du courrier indirect. Inventoriez tous les expéditeurs légitimes et les itinéraires indirects avant que le propriétaire de la politique n’approuve l’application. Aucune modification DNS , opération de locataire ou test de message reçu n’a été exécuté pour cet article.