Un processus d'intégration reproductible commence par la frontière client. Déterminez quelle entité juridique, quels domaines, applications et administrateurs sont concernés avant de collecter des rapports ou de proposer des modifications DNS . Un service partagé ne doit pas déduire l'autorité du client à partir d'un domaine apparaissant dans une feuille de calcul de vente ou dans une recherche DNS publique.
Établir la limite du service
Nommez le sponsor client, le propriétaire technique, le dépositaire DNS , l'analyste MSP, l'approbateur de changement et le contact en cas d'incident. Enregistrez leurs responsabilités et leur couverture de secours. Vérifiez l’autorité via le processus d’intégration convenu et accordez uniquement l’accès limité nécessaire pour l’étape en cours. La lecture de rapports et la modification des enregistrements d'authentification sont des autorisations distinctes.
Créez un registre d'expéditeur qui inclut l'objectif commercial, le propriétaire de l'application, le domaine visible depuis, le domaine d'enveloppe, le domaine de signature et le cycle d'activité attendu. Incluez les services programmés et à faible volume. Une absence pendant une courte fenêtre d’observation ne constitue pas une preuve qu’un service n’est pas utilisé. RFC 9990 rapports agrégés décrire l'activité de message signalée ; il ne s’agit pas d’un inventaire d’applications faisant autorité.
Passer par une acceptation par étapes
Acceptez d’abord l’inventaire et la collecte de preuves. Évaluez ensuite les chemins d’envoi connus et expliquez les échecs. Proposez ensuite des modifications avec des conditions exactes de différence, d'approbation et de restauration. Enfin, vérifiez le flux prévu avec les messages provenant de l'application réelle et les résultats côté récepteur. DMARC compte sur alignement ainsi que SPF ou DKIM authentification sous RFC 9989, donc une étiquette de passe générique ne suffit pas.
Ne déplacez pas chaque domaine vers une stratégie d’application simplement parce que le modèle indique que l’intégration est terminée. Enregistrez les exceptions, les expéditeurs non résolus, les redirecteurs et les chemins de liste de diffusion. Définissez qui accepte le risque résiduel et quand les preuves seront examinées. Les décisions politiques doivent suivre les dépendances de messagerie et l'autorisation du client.
Gardez deux attentes d'intégration séparées
Supposons que l'application de facturation d'un client dispose d'un échantillon de passes alignées autorisé actuel, alors que son notificateur trimestriel n'a pas été exécuté et que son approbateur DNS alternatif n'est pas confirmé. Acceptez la preuve de facturation pour sa portée testée, conservez le notifiant comme non testé et résolvez le problème d'approbation avant de vous y fier. Une liste de contrôle d’admission complétée ne peut pas transformer ces lacunes en acceptation opérationnelle.
Il s’agit de décisions d’intégration hypothétiques, et non d’un runbook client fourni ou d’un contrôle d’exhaustivité exécuté. Pour chaque étape, enregistrez la personne responsable, les preuves exactes de l'acceptation et les conditions non résolues. Lors de la planification de la sortie, exigez la confirmation de la révocation de l'accès via le système responsable plutôt que la promesse qu'un futur script la supprimera. Aucune approbation du client, écriture DNS ou ingestion de rapport n’est revendiquée ici.
Remettre les opérations et planifier la sortie
Donnez au client un registre de domaine actuel, une configuration approuvée, des exceptions ouvertes et une voie de remontée. Spécifiez la disponibilité des rapports, la couverture de surveillance et les responsabilités de conservation. Expliquez ce que le MSP peut mesurer et ce qui dépend des clients, des hôtes DNS et des récepteurs. Une authentification réussie ne garantit pas le placement dans la boîte de réception.
Un plan de sortie doit identifier le format d'exportation, le destinataire autorisé, la révocation de l'accès, les preuves d'audit conservées et les responsabilités en matière de suppression. Ne supprimez pas automatiquement les enregistrements d’authentification utiles lors de l’offboarding : le client peut toujours en dépendre. Transférez la responsabilité technique, testez le flux de courrier continu et supprimez l'accès dans le cadre d'un plan approuvé. Examinez le service chaque fois que la propriété, les applications ou les flux critiques pour l'entreprise changent.