An employee domain supports more than messages sent from the default webmail screen. Staff may send through delegated mailboxes, CRM integrations, approved mobile clients, support systems or external mailing lists. A policy based only on a successful test from one mailbox overlooks that wider service.
Begin with how people use the domain. The aim is to validate legitimate sending and make an informed policy decision while keeping routine correspondence workable.
Map identities and responsibilities
Create one record for each meaningful route. Include the sending platform and account, visible From identity, envelope return address, signing domain, owner and approval status. A shared mailbox and a supplier-operated HR platform may use the same From domain while requiring different configuration and ownership checks.
Use role and service interviews to supplement report analysis. Ask staff who participate in professional associations, researchers who post to mailing lists and teams that use delegated addresses. Avoid collecting personal content merely to discover the route.
The sender-inventory guide provides the operating model. Ownership should identify who can change or retire the service, not just who recognises its provider's name.
Keep authentication and business approval separate
An application's message can pass raw authentication for an unrelated provider domain without passing DMARC for the employee From domain. Conversely, under RFC 9989 §5.4, a passing aligned message does not establish that the organisation approved that application account or that its content is trustworthy.
Test the actual supported route. Retain the visible From domain, SPF-evaluated identity, DKIM d domain and trusted receiver results under RFC 8601 §7.1. A screenshot showing a public DKIM key does not establish that every employee or connected service uses it.
Under RFC 9989 §5.3.5, one aligned passing SPF or DKIM path can satisfy a message’s DMARC pass condition when an applicable policy exists. For full participation, RFC 9989 §8 includes aligned SPF and DKIM, reporting and policy publication. Keep these two questions distinct in the acceptance record.
Build a readiness matrix by route
The following matrix is fictional and illustrates decisions, not a tenant assessment:
- Route: Standard employee mailbox; Evidence: Received tests and routine reports support the expected identities; Decision before a policy change: Retain baseline and monitor
- Route: Delegated finance mailbox; Evidence: Direct test exists; delegated application path not tested; Decision before a policy change: Verify the missing path
- Route: CRM sending as a staff address; Evidence: Raw DKIM pass uses an unrelated provider domain; Decision before a policy change: Correct supported alignment and retest
- Route: Staff member posting to an association list; Evidence: List modifies the original message; Decision before a policy change: Assess indirect-flow behaviour and policy suitability
- Route: Seasonal HR application; Evidence: Owner confirmed; no representative sending evidence; Decision before a policy change: Arrange a proportionate test or retain the gap
A healthy first row does not close the others. A route should not become approved merely because it contributes little volume to a domain-wide chart.
Keep the test scope explicit. Testing one authorised mobile client does not certify every possible client, delegate or third-party integration.
Take general-purpose interoperability seriously
Current RFC 9989 §7.4 advises that domains hosting users who may post to Internet mailing lists should not publish reject. Its guidance addresses the consequences of indirect paths, including changed messages and mail forwarded by other systems.
For such domains that nevertheless consider reject, That section recommends at least a month at none, then an equally long quarantine period, comparing disposition results. It also recommends policies against users posting to Internet mailing lists and/or informing users that participation may be hindered if the domain chooses reject.
This guidance should influence the policy decision before a rollout. It is not a problem solved by announcing that all legitimate employee mail must eventually pass unchanged through every intermediary.
A separate domain or subdomain for a different sending purpose can sometimes clarify ownership and configuration. Assess the real discovery and alignment relationships and the impact on users; separation by itself does not repair an application's signing or make a mailing list preserve the original message.
Review a precise policy diff
Document which domain and subdomains the proposed change affects. Record the current complete policy and the intended new value. Explain whether the change affects requested handling, alignment, reporting or another setting.
Do not tighten several independent settings merely to achieve a more restrictive-looking record. Each should have its own evidence and purpose. Use the policy-selection guide and subdomain discovery guidance to check scope.
Assign approval to someone accountable for the affected business communication. The approval record should name known limitations, the recovery owner and the evidence that would trigger a reassessment.
Verify outcomes and investigate exceptions
After a change, test the defined routes and review available receiver feedback. A receiving system can apply its own analysis and policy; publishing reject does not force one universal handling outcome under RFC 9989 §5.4.
For a delivered example, examine trusted authentication evidence. For a rejection, keep the full returned text and sending-platform details. Protect mailbox content and employee information when sharing samples for investigation.
Keep an exception tied to a route, business purpose, owner and review date. A broad exemption based only on a provider name can outlive the original problem and authorise more than intended. An unknown source remains an investigation item until evidence establishes its role.
Maintain the domain as staff workflows change
Onboarding a CRM, changing a gateway, delegating a subdomain or enabling a new sending feature can alter the evidence. Make those changes part of the service-owner process rather than waiting for the next domain-wide policy project.
Employee mail succeeds when legitimate people and approved services can communicate through supported routes with clear identity evidence. A useful DMARC programme improves that evidence continuously and chooses policy with the domain's general-purpose role understood.
Keep the next action specific
In the employee-route fixture, a verified default mailbox does not clear the delegated finance or seasonal HR rows. The CRM identity needs its own alignment evidence; the association list needs policy-suitability review, not a promise to preserve every signature. Keep route gaps and accepted limitations visible. No employee mailbox, tenant or list was tested.