Patients may see the same logo on an appointment reminder, a registration message and a portal-access email even when three different applications send them. Identify the service behind each message. Then test both its email identity and the application behavior that makes the notification useful and safe.
Identify the trigger and the destination
For appointments, record which scheduling event triggers a message and how a reschedule or cancellation affects queued reminders. For registration, record the application responsible for matching the message to the intended person. For portal access, identify the account service and the approved link or code lifecycle. Keep the actual email provider and tenant alongside each application, not only the portal's website address.
Record the From domain, envelope identity, DKIM domain and selector for every route. Inspect the reply destination and the approved portal host as separate fields. A valid signature under the service domain does not establish that a link is safe, current or intended for the recipient. Conversely, a familiar portal URL does not prove that the email was authorized.
Test lifecycle changes with fictional records
Create approved synthetic appointment and registration cases. Exercise a new appointment, reschedule, cancellation, duplicate registration attempt and portal-access request where the test environment permits. Confirm which messages actually appear, whether stale reminders are suppressed by the application and whether links lead to the expected test portal.
For account-access messages, use nonfunctional demonstration values or a segregated approved test account. Do not retain usable patient access links or codes in general authentication evidence. A delayed access email may pass DKIM while its token has expired; that is an application-lifecycle outcome, not proof of an authentication defect.
Separate three kinds of failure
If DKIM fails or no aligned path exists, the mail and service teams should investigate signing, identity and message changes. If a reminder has the wrong time, the scheduling owner should investigate event versions and time-zone handling. If the message reaches an outdated address, registration and identity teams should follow the approved recipient-correction process. Do not solve the last two issues by relaxing DMARC policy.
Retain a short test record containing the synthetic case ID, event time, sender identity, observed authentication, application outcome and owner. Use minimal redacted evidence. Email headers can still contain personal addresses and routing information, so treat them according to the organisation's access and retention rules rather than assuming headers are public.
Define the acceptance decision
Require a correct sending identity plus the expected application behavior for each message family. A signature pass alone cannot approve the portal journey. Confirm the approved recovery path with the service owner when reminders or access notifications fail, without creating an unapproved alternate communication channel.
The fictional map below intentionally leaves the portal-access specimen with a provider-domain signature that does not exactly align. Its stipulated cryptographic validity illustrates why looking only for DKIM=pass is insufficient. Production readiness needs actual service evidence and the applicable SPF or DKIM alignment, not the written premise.
Recheck after scheduler replacement, registration changes, identity-provider migration, new portal hosts and sender-domain changes. Include low-volume exceptions such as cancelled appointments and recovered accounts. This is an operational verification method, not a claim that any healthcare platform or EmailAuth product already implements these controls.
Inspect the written route ledger
All rows use reserved fictional domains, proposed owners and stipulated DKIM results. Selector demo1 is an illustrative label, not an installed key. SPF results, other signatures, DNS policy discovery, actual receipt and application success are unknown. No keys, signed messages, test execution or delivery evidence are supplied.
- appointment: From appointments.care.example; MAIL FROM unknown; DKIM d=appointments.care.example, selector demo1, assumed pass; proposed owner Scheduling owner. Next action: Verify this tenant’s supported signing path and its separate application acceptance criteria.
- registration: From registration.care.example; MAIL FROM unknown; DKIM d=registration.care.example, selector demo1, assumed pass; proposed owner Registration owner. Next action: Verify this tenant’s supported signing path and its separate application acceptance criteria.
- portal access: From access.care.example; MAIL FROM unknown; DKIM d=provider.example.net, selector demo1, assumed pass; proposed owner Identity service owner. Next action: Verify this tenant’s supported signing path and its separate application acceptance criteria.
An assumed passing signature whose d= exactly matches From supplies a strictly aligned path for that hypothetical message. An unrelated d= supplies no aligned path from that signature. Unknown SPF or other signatures prevent an overall failure verdict for the latter case. These written premises establish no live configuration or inbox placement.
Compare three lifecycle decisions
Use fictional portal case P-02 in a proposed test tenant. Appointment version 1 at 09:00 GST is cancelled before its queued reminder is emitted: even a stipulated DKIM pass leaves a scheduling defect. A registration message addressed to the wrong synthetic account is a recipient-mapping defect. An access link with an assumed 09:10 GST expiry observed at 09:12 GST must be evaluated under the application’s expiry rules; authentication does not extend validity. Scheduling, registration and identity owners each record their expected outcome and a separate observation. Here those observations are not supplied, so none is a passed test. Do not copy live tokens, patient links or usable codes into the evidence packet.
Keep the evidence boundaries explicit
RFC 9989 Sections 4.4 and 5.3.5 distinguish authentication and alignment; Section 5.4 leaves message handling to receiver policy. Section 7.4 requires valid DKIM rather than SPF alone for domains publishing p=reject and warns against reject for domains whose users post to Internet mailing lists. Covered canonicalized bytes determine DKIM integrity under RFC 6376 Sections 3.4–3.7 and 6.1. Neither mechanism validates clinical, educational or legal authority. Collect authorized current evidence for an actual deployment; the operational checklists here are recommendations, not a jurisdiction-specific compliance assessment.