A portal can accept an application while its receipt fails, or send reminders successfully while status updates use a forgotten relay. The citizen experiences a broken service in either case. Treat receipts, reminders and status notifications as three independently owned routes before relying on a combined authentication metric.
Tie each notification to a state transition
For a receipt, identify the application event that creates it and the identifier that connects it to the submission. For an appointment reminder, record the scheduling system, time zone and rescheduling behavior. For a status update, identify the case-management transition and the authoritative place where the citizen can verify it. Keep notification time separate from the underlying event time.
Map each event to the sending application, vendor tenant, From domain, envelope sender, DKIM domain and selector. The web portal's domain and TLS certificate do not show which system sends email. An application integration can select a different provider for each notification family, even when all messages share the same visual design.
Design tests around changes, not only the happy path
Use fictional applications and authorized test mailboxes. Trigger a submission, changed appointment, cancelled appointment and status change in an approved test environment where available. Inspect the final message bytes and the receiver's trustworthy authentication result. Confirm that links and displayed references lead to the expected official service, without including real citizen case details in general test logs.
A reminder queued before rescheduling can be correctly signed and still describe an obsolete appointment. Domain authentication does not resolve that application defect. Track the notification's originating event and version so operations can distinguish stale content from an identity failure. Similarly, a duplicate receipt should be investigated as an event or retry issue instead of automatically being classified as spoofing.
Decide who stops a broken journey
The application owner should judge whether the citizen can continue safely when email is unavailable. The scheduling owner should handle reminder discrepancies, and case operations should handle status notices. Define the approved alternate status-checking path and escalation contact before tightening policy. Do not promise an alternative channel unless it is genuinely supported and staffed.
If a sender is unaligned, verify the service's actual custom-domain capability and tenant-generated records. Change only the approved identity path, test it, and keep a dated rollback plan. Avoid broad SPF additions made solely because a source IP looks familiar. A provider can authenticate its own domain while failing to establish alignment with the public service's From domain.
Monitor completeness rather than just percentages
Record which notification families were observed, which were tested, and which remain unverified. Include infrequent lifecycle events and local-language variants when they use different templates or systems. Use aggregate reports to identify patterns within their actual reporting coverage, then investigate missing or failing routes with service evidence. Refresh the map after portal upgrades, scheduler changes, vendor replacement and changes to the From domain. No specific statutory notification deadline is asserted here.
Work through three written route records
These reserved example domains, selectors, roles and passing DKIM premises are fictional. No signed message, key, cryptographic verification, DNS lookup, SMTP transaction or live service test is supplied or executed for these cases. No test code or external specimen is needed to inspect the reasoning below.
- receipt: visible From domain receipts.civic.example; DKIM d=receipts.civic.example; selector demo1; assume DKIM pass solely for this written case. SPF MAIL FROM identity and result unknown; other signatures unknown; actual policy discovery and delivery unknown. Proposed owner: Application service owner. Next action: Obtain an authorized sample and trusted receiver result for this exact tenant.
- appointment reminder: visible From domain appointments.civic.example; DKIM d=appointments.civic.example; selector demo2; assume DKIM pass solely for this written case. SPF MAIL FROM identity and result unknown; other signatures unknown; actual policy discovery and delivery unknown. Proposed owner: Scheduling owner. Next action: Confirm this separate route and its business event rather than inheriting the first route’s result.
- status notice: visible From domain status.civic.example; DKIM d=provider.example.net; selector demo3; assume DKIM pass solely for this written case. SPF MAIL FROM identity and result unknown; other signatures unknown; actual policy discovery and delivery unknown. Proposed owner: Case management owner. Next action: Ask the verified supplier for this tenant’s supported aligned signing path; do not broaden authorization to its entire network.
For the first two stipulated signatures, d= exactly equals the From domain, so the identifier satisfies strict as well as relaxed alignment. Given the stipulated successful DKIM result, an aligned authentication path exists for those hypothetical messages. The third signer is deliberately unrelated to the author domain and cannot provide that aligned path. Do not call the third message a DMARC failure: aligned SPF or another aligned passing DKIM signature could still satisfy the mechanism, and those inputs are unknown. Do not infer real deployment or inbox placement from any row.
A cryptographic signature authenticates a signing domain’s responsibility, not the truth or authorization of every instruction. Changes to covered canonicalized bytes can invalidate a signature; not every visible edit necessarily changes the signed input. Authentication and application-level acceptance remain separate.
Resolve a stale-reminder example
Assume fictional case C-01 appointment version 1 was 10:00 GST and version 2 moves it to 11:00 GST on the same day. An already queued version-1 reminder is stipulated to pass aligned DKIM. Its identity result does not make 10:00 current. The scheduling owner should apply the approved cancellation or replacement rule, verify the current appointment in the official portal and check whether a correction was actually delivered. If the message instead carries version 2 but no trusted authentication evidence, investigate the mail route separately. No real case, message, rescheduling job or correction send was used here.
Apply the standards without claiming compliance
RFC 9989 Sections 4.4 and 5.3.5 support the alignment and mechanism distinction. Its Section 7.4 warns about indirect-mail interoperability: domains using p=reject must use valid DKIM, not SPF alone, and general-purpose mailing-list use needs particular care. A route inventory is not itself permission to enforce reject. RFC 6376 Sections 3.4–3.7 and 6.1 describe signed inputs and verification. RFC 9990 Section 3.1 provides reporting context, not per-recipient arrival proof. RFC 5321 Section 4.2.5 distinguishes server acceptance responsibility from later delivery outcomes. Sector workflow choices here are editorial recommendations; legal scope, factor suitability and local authorization need their own accountable review.