Choisissez l'identité de communication avant de modifier DNS
Une annonce scolaire a deux besoins opérationnels distincts : les destinataires doivent reconnaître l'expéditeur et l'itinéraire d'envoi doit s'authentifier correctement. Décidez si les diffusions doivent afficher une adresse sur le domaine de l'école ou une identité gérée par le fournisseur. Identifiez ensuite le produit et le compte SchoolMessenger réels. Ce guide couvre les options administratives de Communicate documentées par PowerSchool, et non tous les services partageant le nom SchoolMessenger.
Le Guide des options d'envoi PowerSchool, introduction présente deux arrangements et demande aux clients de coordonner leur choix et la complétion DNS avec le support SchoolMessenger Solutions. Planifiez cette coordination dans le cadre du changement. Le simple fait d'ajouter des enregistrements ne permet pas d'établir quel arrangement le fournisseur utilise pour vos diffusions.
Sélectionnez une fenêtre de test de routine avec le propriétaire des communications. Ne combinez pas le travail d’authentification initiale avec une fermeture météo, une alerte de sécurité ou toute autre annonce urgente. Préserver la procédure de communication d'urgence existante de l'organisation ; ce guide n'autorise pas une large diffusion ni ne prétend que l'authentification du courrier électronique garantit la livraison.
Conserver l'option fournisseur-domaine non résolue en cas de conflit de source
L'option 1 décrit les identités gérées par le fournisseur et aucune modification DNS du client. Cependant, sa configuration répertorie broadcasts@schoolmessengermail.com tandis que ses inconvénients nomment le texte broadcasts@schoolmessenger.com . Il répertorie également un domaine de signature sous schoolmessenger.com . Il s’agit de domaines sensiblement différents, l’article ne peut donc pas promettre en toute sécurité alignement pour la combinaison littérale telle qu'imprimée.
Ne choisissez pas silencieusement la version qui fait fonctionner le diagramme. Demandez à l'assistance de confirmer le domaine visible From, le domaine de l'enveloppe et DKIM domaine de signature pour le compte réel et l'option sélectionnée. Capturez un message reçu contrôlé et comparez ces identités avec la réponse. Conservez l’écart dans la feuille de calcul jusqu’à ce qu’il soit résolu.
Une adresse de réponse contrôlée par l'école peut renvoyer les réponses à l'école sans que le message soit authentifié en tant que domaine de l'école. Cela peut ou non répondre aux exigences de l'équipe de communication en matière de marque. Énoncez clairement ce compromis avant d’accepter une route fournisseur-domaine. La modification d'un nom d'affichage ne modifie pas le domaine utilisé par DMARC.
Passez en revue l'option de domaine personnalisé et ses exigences DNS
L'option 2 décrit le domaine du client pour From, l'enveloppe et DKIM . Ses noms de section « Modifications DNS requises » include:customerspf.schoolmessenger.com et un spe1 sélecteur CNAME pointant vers spe1._domainkey.spe.schoolmessenger.com . Sa limite déclarée est que la plate-forme ne traite pas les rebonds hors bande après le transfert vers un système destinataire. Confirmez l'applicabilité avec l'assistance plutôt que de traiter l'exemple publié comme une activation de compte.
L'option 2 copie explicitement En-tête de dans Répondre à. Choisissez une boîte aux lettres De surveillée et confirmez que ce comportement de réponse documenté correspond au flux de travail de l'école ; ne promettez pas de remplacement de réponse indépendant.
Obtenez la liste des domaines approuvés, le dossier d’assistance et l’heure d’activation prévue. Si plusieurs écoles ou unités administratives utilisent un domaine De différent, identifiez chacune explicitement. Ne présumez pas que la configuration du domaine principal du district couvre des domaines non liés ou qu'un sous-domaine utilise exactement les mêmes paramètres côté compte sans confirmation.
Exportez les enregistrements DNS existants avant d’apporter une modification proposée. Vérifiez si le nom du sélecteur spe1 est déjà occupé et à qui il appartient. En cas de collision, demandez à l'assistance une résolution prise en charge. Ne remplacez pas la clé d'un autre expéditeur et ne créez pas à la fois un CNAME et des données conflictuelles chez le même propriétaire. N'inventez pas de sélecteur alternatif : il doit correspondre à ce avec quoi le service signe.
Le propriétaire exact dans la zone client dépend du domaine approuvé et de l'interface DNS . Un formulaire peut accepter un nom relatif tandis qu'un autre en attend un complet. Vérifiez le propriétaire public résultant plutôt que de vous fier à une capture d'écran des champs de saisie. La cible du fournisseur est une infrastructure de vérification publique, et non une clé privée à copier dans un ticket.
Fusionner SPF sans supprimer les autres expéditeurs scolaires
Identifiez la stratégie au niveau du domaine réellement utilisé pour l'enveloppe. RFC 7208 , section 2.3 définit SPF’s COURRIER DE identité; il ne s'agit pas simplement de l'adresse qui apparaît à côté du nom d'affichage de l'école. Dans l'arrangement de domaine personnalisé pris en charge, les identités attendues et observées doivent correspondre, mais les enregistrer séparément afin qu'une incompatibilité de configuration soit visible.
Conservez l'autorisation pour d'autres systèmes légitimes, y compris le service de boîte aux lettres de l'école et tout expéditeur de candidatures approuvé de manière indépendante. Ajoutez uniquement l’autorisation SchoolMessenger requise à la politique révisée existante. La création d'un autre enregistrement v=spf1 chez le même propriétaire ne combine pas les stratégies et peut rendre le résultat invalide.
Examinez les recherches imbriquées par rapport à la section 4.6.4 RFC 7208 . Une courte inclusion peut faire référence à d'autres politiques, alors comptez le coût de l'évaluation plutôt que le nombre de mots visibles dans DNS . Ne copiez pas un exemple complet sur la stratégie existante, ne modifiez pas négligemment son qualificatif de terminal ou ne supprimez pas des services inconnus pour respecter la limite. Transmettez un conflit de stratégie à l'administrateur de messagerie.
Après la publication, comparez les réponses faisant autorité avec l'enregistrement avant et après approuvé. Conservez le temps d’observation et autorisez la mise en cache. Si un résolveur signale toujours une ancienne réponse, distinguez-la d’un enregistrement faisant autorité incorrect. La modification répétée d'un enregistrement correct peut rendre le diagnostic plus difficile.
Intégrez la propriété du rebond à la décision de lancement
Les réponses ordinaires et les erreurs de livraison servent à des fins différentes. Décidez où les réponses doivent parvenir au personnel de l’école, puis établissez séparément comment les administrateurs seront informés des échecs. Pour l’itinéraire de domaine personnalisé documenté, la limitation du rebond hors bande constitue un problème opérationnel même lorsque l’authentification réussit.
Demandez à l'assistance quelles sont les preuves disponibles pour les rejets synchrones, les échecs retardés et les adresses de destinataires invalides. Déterminez si l’équipe de messagerie de l’école doit surveiller une boîte aux lettres ou un autre mécanisme pris en charge. Ne présumez pas que la saisie d'une adresse de rebond dans un exemple crée une boîte aux lettres, que chaque échec apparaît dans le rapport de campagne ou que l'absence de rebond prouve la livraison.
Testez le dispositif approuvé de gestion des échecs sans utiliser le compte réel d'un étudiant ni distribuer d'informations familiales privées. Utilisez uniquement des destinations de test contrôlées par les administrateurs et une procédure convenue. Enregistrez qui conciliera les échecs de livraison avec la maintenance des données de contact et comment ils éviteront d'envoyer des suivis inutiles au mauvais public.
Inspecter une diffusion contrôlée depuis le récepteur final
Envoyez du contenu inoffensif via la voie de communication réelle à des destinataires externes contrôlés. Conservez l'identifiant de diffusion, l'ID du message et l'heure UTC. Si le personnel peut choisir plusieurs domaines d'expéditeur ou adresses de réponse, testez les combinaisons qui modifient sensiblement l'identité. N'envoyez pas une véritable annonce à l'échelle de l'école simplement pour obtenir des en-têtes.
Capture visible depuis, réponse à, Return-Path ou l'identité de l'enveloppe déclarée par le récepteur, chaque paire DKIM d= et s= et les résultats du récepteur fiable. RFC 6376 , section 3.5 explique les champs de domaine et de sélecteur utilisés pour la recherche de clé. Vérifiez que le sélecteur observé est résolu via le dossier public prévu et que la signature résultante est vérifiée.
Appliquer RFC 9989 , section 4.4, « Alignement des identifiants expliqué ». DMARC a besoin d’un résultat SPF ou DKIM réussi et aligné. Enregistrez quel mécanisme le fournit et quel mode d’alignement s’applique. Une signature techniquement valide sous un domaine de fournisseur non lié ne peut pas authentifier à elle seule le domaine visible de l'école.
Conservez la livraison, l’authentification et le routage des réponses comme résultats distincts. Le placement dans la boîte de réception ne constitue pas une preuve d'un alignement correct, et une exception de passerelle interne peut masquer un problème que les familles externes rencontrent encore. Un test transitant par un service de réexpédition peut également différer d'une livraison externe directe ; étiquetez l'itinéraire plutôt que de combiner ces résultats.
Utilisez la feuille de travail d'acceptation de l'option d'envoi
Créez un enregistrement d'évaluation distinct pour l'option SchoolMessenger et la feuille de calcul de rebond en utilisant les champs ci-dessous. Il enregistre le produit, l'option confirmée par le support, les identités exactes, les divergences de source, les preuves DNS , le propriétaire du rebond et les résultats des messages contrôlés. Le champ d'incertitude explicite de l'option 1 empêche un réviseur ultérieur de traiter des exemples publiés incohérents comme des faits de compte vérifiés.
Exiger l’approbation de l’administrateur de messagerie et du propriétaire des communications. L'administrateur vérifie DNS et l'authentification. Le propriétaire des communications vérifie l'expéditeur visible, la destination de réponse surveillée et le plan de récupération. Gardez un propriétaire distinct pour la gestion des rebonds si cette responsabilité n'incombe à aucune des deux personnes.
Exemple concret fictif : l'authentification réussit mais le flux de travail est incomplet
Cas écrit fictif uniquement : SMC-01 stipule l'option 2 From notices@district.example et une signature de passage d=district.example, s=spe1. Le résultat exact de l’enveloppe est inconnu ; la signature stipulée s'aligne exactement. Cependant, personne n’est propriétaire d’échecs retardés dans le cadre de la limitation de rebond documentée. Le propriétaire des communications et l'administrateur de messagerie doivent confirmer le traitement des réponses surveillé et un processus d'échec retardé pris en charge avant d'approuver le lancement opérationnel. Il s’agit d’hypothèses pédagogiques, et non de preuves tirées d’un récit ou d’une émission scolaire.
Récupérer et revérifier sans abaisser la politique de l'école
Si la nouvelle identité échoue, suspendez le changement d’identité prévu et coordonnez un retour au dernier accord d’envoi approuvé avec l’assistance. Maintenir les communications d'urgence selon le processus opérationnel établi. N'affaiblissez pas la politique DMARC de l'ensemble du domaine et n'ajoutez pas de larges listes autorisées simplement pour masquer une route non vérifiée.
Conservez les enregistrements de vérification publics pour les messages encore en cours jusqu'à ce que le propriétaire du courrier et le fournisseur conviennent qu'ils peuvent être retirés. Revérifiez après les changements de domaine, les changements d'options côté support, les migrations de boîtes aux lettres et les nouveaux flux de travail d'expéditeur. Le conflit d'identité de l'option 1, l'activation exacte du compte, DNS en direct, la preuve par message réel et le comportement de rebond restent en attente. Il s'agit d'un projet non publié en attente d'examen visuel et d'approbation humaine par la PME.
Séparez un message qui passe de la préparation à l'application
RFC 9989 La section 7.4 nécessite DKIM valide pour une publication de domaine p=reject et met en garde contre l'interopérabilité du courrier indirect. Un seul résultat SPF aligné ne justifie pas en soi le déploiement d’une politique de rejet. Examinez tous les itinéraires légitimes et la propriété des politiques séparément de la configuration de ce fournisseur.