Les patients peuvent voir le même logo sur un rappel de rendez-vous, un message d'inscription et un e-mail d'accès au portail même lorsque trois applications différentes les envoient. Identifiez le service derrière chaque message. Testez ensuite à la fois son identité de messagerie et le comportement de l'application qui rend la notification utile et sûre.
Identifiez le déclencheur et la destination
Pour les rendez-vous, enregistrez quel événement de planification déclenche un message et comment une replanification ou une annulation affecte les rappels en file d'attente. Pour l'inscription, enregistrez l'application chargée de faire correspondre le message à la personne prévue. Pour accéder au portail, identifiez le service de compte et le lien ou le cycle de vie du code approuvé. Conservez le fournisseur de messagerie et le locataire réels à côté de chaque application, et pas seulement l'adresse du site Web du portail.
Enregistrez le domaine De, l'identité de l'enveloppe, DKIM domaine et sélecteur pour chaque itinéraire. Inspectez la destination de la réponse et l’hôte de portail approuvé dans des champs distincts. Une signature valide sous le domaine de service n'établit pas qu'un lien est sûr, actuel ou destiné au destinataire. À l’inverse, une URL de portail familière ne prouve pas que l’e-mail a été autorisé.
Tester les changements du cycle de vie avec des enregistrements fictifs
Créez des dossiers de rendez-vous et d’inscription synthétiques approuvés. Effectuez un nouveau rendez-vous, un report, une annulation, une tentative d'inscription en double et une demande d'accès au portail lorsque l'environnement de test le permet. Vérifiez quels messages apparaissent réellement, si les rappels obsolètes sont supprimés par l'application et si les liens mènent au portail de test attendu.
Pour les messages d'accès au compte, utilisez des valeurs de démonstration non fonctionnelles ou un compte de test approuvé séparé. Ne conservez pas de liens ou de codes d’accès patient utilisables dans les preuves d’authentification générales. Un e-mail à accès différé peut transmettre DKIM alors que son jeton a expiré ; il s'agit d'un résultat du cycle de vie de l'application et non d'une preuve d'un défaut d'authentification.
Séparez trois types d’échec
Si DKIM échoue ou qu’aucun chemin aligné n’existe, les équipes de messagerie et de service doivent enquêter sur les modifications de signature, d’identité et de message. Si un rappel est associé à une heure incorrecte, le responsable de la planification doit examiner les versions des événements et la gestion des fuseaux horaires. Si le message atteint une adresse obsolète, les équipes d'enregistrement et d'identité doivent suivre le processus de correction du destinataire approuvé. Ne résolvez pas les deux derniers problèmes en vous relaxant DMARC politique.
Conservez un court enregistrement de test contenant l'ID de cas synthétique, l'heure de l'événement, l'identité de l'expéditeur, l'authentification observée, le résultat de la demande et le propriétaire. Utilisez un minimum de preuves expurgées. En-têtes d'e-mails peuvent toujours contenir des adresses personnelles et des informations de routage, alors traitez-les conformément aux règles d'accès et de conservation de l'organisation plutôt que de supposer que les en-têtes sont publics.
Définir la décision d'acceptation
Exigez une identité d’envoi correcte ainsi que le comportement d’application attendu pour chaque famille de messages. Un laissez-passer signé à lui seul ne peut pas approuver le voyage sur le portail. Confirmez le chemin de récupération approuvé avec le propriétaire du service lorsque les rappels ou les notifications d'accès échouent, sans créer de canal de communication alternatif non approuvé.
La carte fictive ci-dessous laisse intentionnellement au spécimen d'accès au portail une signature de domaine de fournisseur qui ne s'aligne pas exactement. Sa validité cryptographique stipulée illustre pourquoi la recherche uniquement de DKIM =pass est insuffisante. L'état de préparation à la production nécessite des preuves de service réelles et les SPF ou DKIM alignement, pas la prémisse écrite.
Revérifiez après le remplacement du planificateur, les modifications d'enregistrement, la migration du fournisseur d'identité, les nouveaux hôtes de portail et les modifications de domaine d'expéditeur. Incluez les exceptions à faible volume telles que les rendez-vous annulés et les comptes récupérés. Il s'agit d'une méthode de vérification opérationnelle et non d'une affirmation selon laquelle une plateforme de soins de santé ou un produit EmailAuth implémente déjà ces contrôles.
Inspecter le grand livre de route écrit
Toutes les lignes utilisent des domaines fictifs réservés, des propriétaires proposés et des résultats DKIM stipulés. Le sélecteur demo1 est une étiquette illustrative, pas une clé installée. Les résultats SPF , les autres signatures, la découverte de la politique DNS , la réception réelle et le succès de l'application sont inconnus. Aucune clé, message signé, exécution de test ou preuve de livraison n'est fourni.
- rendez-vous : à partir de appointments.care.example ; COURRIER DE inconnu; DKIM d=appointments.care.example, sélecteur démo1, réussite supposée ; Propriétaire proposé Propriétaire de la planification. Action suivante : Vérifiez le chemin de signature pris en charge par ce locataire et ses critères d'acceptation d'application distincts.
- inscription : à partir de registration.care.example ; MAIL D'inconnu ; DKIM d=registration.care.example, sélecteur démo1, réussite supposée ; propriétaire proposé Propriétaire d'enregistrement. Action suivante : Vérifiez le chemin de signature pris en charge par ce locataire et ses critères d'acceptation d'application distincts.
- accès au portail : depuis access.care.example ; MAIL D'inconnu ; DKIM d=provider.example.net, sélecteur démo1, réussite supposée ; Propriétaire proposé Propriétaire du service d'identité. Action suivante : Vérifiez le chemin de signature pris en charge par ce locataire et ses critères d'acceptation d'application distincts.
Une signature de passage supposée dont d= correspond exactement à From fournit un chemin strictement aligné pour ce message hypothétique. Un d= sans rapport ne fournit aucun chemin aligné à partir de cette signature. SPF inconnu ou d'autres signatures empêchent un verdict d'échec global dans ce dernier cas. Ces prémisses écrites n’établissent aucune configuration en direct ni placement dans la boîte de réception.
Comparez trois décisions de cycle de vie
Utilisez le cas de portail fictif P-02 dans un client test proposé. Le rendez-vous version 1 à 09h00 GST est annulé avant que son rappel en file d'attente ne soit émis : même un pass DKIM stipulé laisse un défaut de planification. Un message d'enregistrement adressé au mauvais compte synthétique est un défaut de mappage des destinataires. Un lien d'accès avec une expiration supposée à 09h10 GST observée à 09h12 GST doit être évalué selon les règles d'expiration de l'application ; l'authentification ne prolonge pas la validité. Les propriétaires de planification, d'enregistrement et d'identité enregistrent chacun leur résultat attendu et une observation distincte. Ici, ces observations ne sont pas fournies, donc aucune n'est un test réussi. Ne copiez pas les jetons actifs, les liens patients ou les codes utilisables dans le paquet de preuves.
Gardez les limites des preuves explicites
RFC 9989 Les sections 4.4 et 5.3.5 distinguent l'authentification et l'alignement ; La section 5.4 laisse la gestion des messages à la politique du destinataire. La section 7.4 nécessite DKIM valide plutôt que SPF uniquement pour la publication de domaines p=reject et met en garde contre le rejet des domaines dont les utilisateurs publient sur des listes de diffusion Internet. Les octets canonisés couverts déterminent l’intégrité DKIM selon les sections 3.4 à 3.7 et 6.1 de RFC 6376 . Aucun des deux mécanismes ne valide l’autorité clinique, éducative ou juridique. Recueillir des preuves actuelles autorisées pour un déploiement réel ; les listes de contrôle opérationnelles présentées ici sont des recommandations et non une évaluation de la conformité spécifique à une juridiction.