A citizen can receive mail from a central department, an agency portal and a contracted reminder service during one application. A successful mailbox migration proves little about the latter two. Map the service journey before changing authentication policy, with ownership at the point where the citizen depends on the message.
Follow the service rather than the organisation chart
Choose one public-service journey, such as applying for a permit. List the submission receipt, requests for more information, appointment notices and final decision notification. Record the application that triggers each message, the service provider, its tenant, visible From address, envelope sender, DKIM domain and selector, and the responsible business owner. A departmental address book does not reveal all of these systems.
Separate domain registration control, delegated DNS control and application administration. An agency may own its application while the parent department publishes its records; a contractor may configure signing while neither can approve the other's changes. Name both the service owner who accepts the user impact and the technical owner who can execute a change. Do not treat a familiar government-looking display name as evidence of either authority.
Establish the delegated-domain boundary
For each delegated agency domain, inspect its actual DNS and applicable DMARC policy rather than assuming the central domain setting covers it as intended. Record whether it sends, receives or exists only as a web address. Document the contractor's authorized sending scope and its end date. Custom DKIM setup and envelope identity should be verified against the particular tenant, not copied from another agency's configuration.
The route map below deliberately includes a contractor assumed to have a passing signature under the provider's domain but does not exactly align with the agency From domain. The corrective task is to investigate the approved aligned path, not to authorize every address owned by that provider. Obtain fresh values from the verified service, stage the narrow change and test the real route before broader enforcement.
Protect service continuity during a change
Schedule tests around low-frequency but consequential flows, including an application rejection or request for missing documents. A monthly bulk newsletter is not an adequate substitute. Agree with service operations how a failed test is escalated, how citizens can independently check their application status and who can stop the rollout. Do not send real citizen records to test recipients.
Use a dated change record with before-state evidence, expected identity, approver, operator and rollback action. Retire contractor access and signing authority through a coordinated offboarding plan after confirming queued and recurring messages have moved. Review the route map whenever an agency is delegated new DNS control, a portal changes supplier or a central mailbox migration begins. Any government mandate or retention obligation requires jurisdiction-specific legal verification; this guide makes no universal regulatory claim.
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.
- citizen portal: visible From domain portal.civic.example; DKIM d=portal.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: Digital services owner. Next action: Obtain an authorized sample and trusted receiver result for this exact tenant.
- delegated agency: visible From domain agency.civic.example; DKIM d=agency.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: Agency communications owner. Next action: Confirm this separate route and its business event rather than inheriting the first route’s result.
- contractor reminders: visible From domain notices.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: Contract manager. 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.
Assign a concrete release decision
For fictional permit journey P-01, the digital-services owner accepts receipt coverage, the agency owner accepts decision-notice coverage and the contract manager obtains the reminder tenant configuration. The DNS operator implements only an approved exact diff; application access alone does not authorize that diff. If the contractor cannot demonstrate an aligned route, keep that route unresolved and pause the affected policy change rather than declaring the whole journey ready. Record an approved alternative status-checking path and its staffing before promising continuity. None of those owners or artifacts is verified 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.