Pasienter kan se den samme logoen på en avtalepåminnelse, en registreringsmelding og en e-post med portaltilgang selv når tre forskjellige søknader sender dem. Identifiser tjenesten bak hver melding. Deretter tester du både e-postidentiteten og applikasjonens virkemåte som gjør varselet nyttig og trygt.
Identifiser utløseren og destinasjonen
For avtaler, registrer hvilken planleggingshendelse som utløser en melding og hvordan en omplanlegging eller kansellering påvirker påminnelser i kø. For registrering, registrer applikasjonen som er ansvarlig for å matche meldingen til den tiltenkte personen. For portaltilgang, identifiser kontotjenesten og den godkjente koblingen eller kodens livssyklus. Hold den faktiske e-postleverandøren og leietakeren ved siden av hver applikasjon, ikke bare portalens nettstedsadresse.
Registrer Fra-domenet, konvoluttidentiteten, DKIM domene og velger for hver rute. Inspiser svardestinasjonen og den godkjente portalverten som separate felt. En gyldig signatur under tjenestedomenet fastslår ikke at en lenke er sikker, aktuell eller beregnet på mottakeren. Omvendt, en kjent portal-URL beviser ikke at e-posten var autorisert.
Test livssyklusendringer med fiktive poster
Opprette godkjente syntetiske avtale- og registreringssaker. Tren en ny avtale, omplanlegg, kansellering, duplikatregistreringsforsøk og forespørsel om portaltilgang der testmiljøet tillater det. Bekreft hvilke meldinger som faktisk vises, om foreldede påminnelser er undertrykt av applikasjonen og om koblinger fører til den forventede testportalen.
For meldinger om kontotilgang, bruk ikke-funksjonelle demonstrasjonsverdier eller en adskilt godkjent testkonto. Ikke oppbevar brukbare pasienttilgangslenker eller koder som generelle autentiseringsbevis. En e-post med forsinket tilgang kan passere DKIM mens tokenet har utløpt; som er et program-livssyklusutfall, ikke bevis på en autentiseringsfeil.
Skill tre typer feil
Hvis DKIM mislykkes eller ingen justert bane eksisterer, bør e-post- og serviceteam undersøke signering, identitet og meldingsendringer. Hvis en påminnelse har feil tid, bør den planleggende eieren undersøke hendelsesversjoner og tidssonehåndtering. Hvis meldingen når en utdatert adresse, bør registrerings- og identitetsteam følge den godkjente mottakerkorrigeringsprosessen. Ikke løs de to siste problemene ved å slappe av DMARC politikk.
Ta vare på en kort testpost som inneholder syntetisk saks-ID, hendelsestid, avsenderidentitet, observert autentisering, søknadsresultat og eier. Bruk minimalt med redigerte bevis. E-postoverskrifter kan fortsatt inneholde personlige adresser og ruteinformasjon, så behandle dem i henhold til organisasjonens tilgangs- og oppbevaringsregler i stedet for å anta at overskrifter er offentlige.
Definer akseptbeslutningen
Krev en korrekt sendeidentitet pluss forventet applikasjonsatferd for hver meldingsfamilie. Et signaturpass alene kan ikke godkjenne portalreisen. Bekreft den godkjente gjenopprettingsbanen med tjenesteeieren når påminnelser eller tilgangsvarsler mislykkes, uten å opprette en ikke-godkjent alternativ kommunikasjonskanal.
Det fiktive kartet nedenfor etterlater med hensikt portaltilgangseksemplaret med en leverandør-domenesignatur som ikke er nøyaktig på linje. Dens angitte kryptografiske gyldighet illustrerer hvorfor det ikke er tilstrekkelig å lete bare etter DKIM =pass. Produksjonsberedskap trenger faktiske servicebevis og relevant SPF eller DKIM justering, ikke den skriftlige premissen.
Sjekk på nytt etter utskifting av planlegger, endringer i registrering, migrering av identitetsleverandører, nye portalverter og endringer i sender-domene. Inkluder unntak med lavt volum som kansellerte avtaler og gjenopprettede kontoer. Dette er en operasjonell verifiseringsmetode, ikke en påstand om at noen helseplattform eller EmailAuth -produkt allerede implementerer disse kontrollene.
Kontroller den skriftlige ruteboken
Alle rader bruker reserverte fiktive domener, foreslåtte eiere og fastsatte DKIM resultater. Selector demo1 er en illustrativ etikett, ikke en installert nøkkel. SPF resultater, andre signaturer, oppdagelse av DNS policy, faktisk mottak og applikasjonssuksess er ukjent. Ingen nøkler, signerte meldinger, testutførelse eller leveringsbevis leveres.
- avtale: Fra appointments.care.example ; POST FRA ukjent; DKIM d=appointments.care.example, selector demo1, antatt bestått; foreslått eier Planleggingseier. Neste handling: Bekreft denne leietakerens støttede signeringsbane og dens separate søknadsgodkjenningskriterier.
- registrering: Fra registration.care.example ; POST FRA ukjent; DKIM d=registration.care.example, selector demo1, antatt bestått; foreslått eier Registrering eier. Neste handling: Bekreft denne leietakerens støttede signeringsbane og dens separate søknadsgodkjenningskriterier.
- portaltilgang: Fra access.care.example ; POST FRA ukjent; DKIM d=provider.example.net, selector demo1, antatt pass; foreslått eier Identitetstjenesteeier. Neste handling: Bekreft denne leietakerens støttede signeringsbane og dens separate søknadsgodkjenningskriterier.
En antatt bestått signatur hvis d= samsvarer nøyaktig med From, gir en strengt justert bane for den hypotetiske meldingen. En urelatert d= gir ingen justert bane fra den signaturen. Ukjent SPF eller andre signaturer forhindrer en samlet feilvurdering for sistnevnte sak. Disse skriftlige premissene etablerer ingen live-konfigurasjon eller innboksplassering.
Sammenlign tre livssyklusbeslutninger
Bruk fiktiv portalsak P-02 i en foreslått testleietaker. Avtaleversjon 1 kl. 09:00 GST kanselleres før påminnelsen i køen sendes ut: selv et fastsatt DKIM pass etterlater en planleggingsfeil. En registreringsmelding adressert til feil syntetisk konto er en mottakerkartleggingsfeil. En tilgangskobling med antatt utløp 09:10 GST observert kl. 09:12 GST må evalueres i henhold til programmets utløpsregler; autentisering forlenger ikke gyldigheten. Planlegging, registrering og identitetseiere registrerer hver sitt forventede resultat og en egen observasjon. Her er disse observasjonene ikke levert, så ingen er en bestått test. Ikke kopier levende tokens, pasientlenker eller brukbare koder inn i bevispakken.
Hold bevisgrensene eksplisitt
RFC 9989 Avsnitt 4.4 og 5.3.5 skiller autentisering og justering; Avsnitt 5.4 overlater meldingshåndtering til mottakerens retningslinjer. Avsnitt 7.4 krever gyldig DKIM i stedet for SPF alene for domenepublisering p=reject og advarer mot avvisning for domener hvis brukere legger ut på e-postlister på Internett. Dekkede kanoniserte bytes bestemmer DKIM integritet under RFC 6376 seksjoner 3.4–3.7 og 6.1. Ingen av mekanismene validerer klinisk, pedagogisk eller juridisk autoritet. Samle autorisert gjeldende bevis for en faktisk distribusjon; de operasjonelle sjekklistene her er anbefalinger, ikke en jurisdiksjonsspesifikk samsvarsvurdering.