A legal practice can have a working staff mailbox while its document-sharing notices fail. Matter updates, document invitations and direct client correspondence may originate from different accounts and systems. Treat each as a separate service before tightening domain policy. The useful output is a route map with an accountable matter-system owner, tested identity and an agreed recovery path, not a green badge for the firm's domain.
Separate four questions
RFC 9989 describes validation of a domain's use in email, not proof that a named lawyer approved the content. Ask separately whether the domain authenticates, whether the recipient is correct, whether the document is access-controlled and whether the communication is authorised for the matter. A signed notice can still invite the wrong person or link to an over-shared document. DMARC does not encrypt a legal attachment or determine professional confidentiality obligations.
Map the routes that actually matter
Use a row for the case-management system's matter update, another for the document platform's invitation, and another for client correspondence through staff mailboxes. Record the business owner, vendor tenant, visible From domain, envelope domain, DKIM signing domain and selector, reply destination, deadline and recovery contact. Keep matter names and client identifiers out of the general authentication inventory. Store restricted evidence separately when necessary.
A supplier's name is not approval to send for the practice. Require the service owner to identify the configured account and its purpose. Ask whether a notice changes identity when the user resends it manually, when an invitation expires or when the system routes a reply through a shared mailbox. A document-access test and a notification-authentication test are different checks, and both may be necessary for acceptance.
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.
- Matter update: From matters.legal.example; MAIL FROM unknown; DKIM d=matters.legal.example, selector demo1, assumed pass; proposed owner Practice operations owner. Next action: Verify the case-management tenant and matter-event mapping.
- Document invitation: From documents.legal.example; MAIL FROM unknown; DKIM d=documents.legal.example, selector demo1, assumed pass; proposed owner Document-platform owner. Next action: Verify invitation access independently of sender identity.
- Client correspondence: From clients.legal.example; MAIL FROM unknown; DKIM d=provider.example.net, selector demo1, assumed pass; proposed owner Messaging owner. Next action: Confirm a supported aligned route before changing policy.
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.
Run a matter-safe acceptance test
Have the service owner create a fictitious matter and a harmless document in an approved test tenant. Send the notification to controlled recipients through each real workflow, including expiration and resend paths. Retain the receiving system's trusted authentication results, relevant headers, message and event identifiers, and the time the invitation became usable. Confirm that only the intended test recipient can open the document. Do not submit real client files merely to test mail identity.
If a path fails, hold that path's migration or enforcement change and ask its owner for an aligned configuration supported by the supplier. Avoid a blanket allowlist for all mail from the vendor. Close the test only when the route authenticates as intended, the invitation reaches the controlled recipient within the practice's chosen deadline and the access test succeeds. Preserve unresolved legal or retention questions for the practice's qualified adviser; this procedure is not a legal compliance determination.
Stop an over-shared invitation independently
Assume fictitious matter L-01 has a harmless document and an invitation with stipulated aligned DKIM. The intended test recipient can open it, but a second unauthorized test account can also open it. The access test fails even though mail identity passed. The document owner follows the approved access-remediation process and retests both allowed and denied cases; the mail team does not weaken authentication as a workaround. Expired and resent invitation paths each need fresh checks. No actual document, invitation or permission was created or changed, and no legal confidentiality conclusion is asserted.
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.