Field StoryATLASSIAN
The Domain Is Verified. That Is Not a Green Light to Enforce the Policy Everywhere.
- Author
- Alex Florian
- Published
- Updated
- Reading time
- 4 min
What domain verification does—and does not—establish in an Atlassian rollout.
The Atlassian rollout plan says the company domain is verified. With a Friday deadline approaching, someone asks whether the stronger sign-in policy can now apply to everyone.
Verification is genuine progress. It establishes control of the email domain—the part after the @. It doesn't, by itself, establish that every account is managed by the organization or that every affected user can operate under the new policy. Account claiming and the applicable authentication arrangements still matter. [1][2][3]
The difference becomes clearer when “everyone” turns into two people trying to start work on Monday.
One domain, two very different mornings
Take two hypothetical accounts. Both use the company's email domain and both have been confirmed as managed accounts. The first belongs to an employee who has completed the required enrollment and successfully tried the intended sign-in and recovery route. The second came from an acquired business and still depends on a recovery arrangement the rollout team hasn't tested.
| Illustrative account | What the rollout team knows | What that supports |
|---|---|---|
| Enrolled employee | Representative sign-in and recovery checks succeeded | A specific basis for proceeding under the tested policy |
| Acquired-business account | Managed status confirmed; recovery dependency unresolved | A remaining readiness question, despite the same verified domain |
Applying the policy to both may look consistent on a spreadsheet. It could leave the second person unable to regain access when the ordinary path fails. The domain status hasn't answered the question that matters in that moment.
There is an earlier possibility too: an eligible account might not yet have been claimed. Depending on how identities are provisioned and managed, claiming can follow different routes. The relevant evidence is the account's actual managed status, not an assumption that a successful domain-verification step completed every account action. [3]
Friday can contain a narrower, useful decision
I wouldn't treat the unresolved account as a reason to discard the security objective. Nor would I use the deadline as evidence that its recovery path works.
For this case, a staged decision is more useful: proceed with the group whose representative journeys have been tested, while assigning a specific test and decision time to the unresolved dependency. The delayed group remains visible, including the consequence of waiting. “Not yet” describes work still to complete, rather than an indefinite exemption.
The same reasoning applies to accounts used by software rather than people. Sending them an enrollment email doesn't establish that an integration has a supported authentication route. Their treatment should follow the service identity and the work relying on it, not assume that a policy designed for ordinary human sign-in can be applied unchanged. [1][2]
A deadline-focused update can then be concrete: which group can proceed, what prevents the next group from proceeding, and when the evidence should resolve that question. Leadership gets something it can act on without being asked to choose between blind enforcement and an open-ended delay.
Recovery and exceptions have different purposes
A narrow emergency route can be important for restoring access during an incident. A broad group permanently exempt from the policy is a different arrangement. Calling both “recovery” makes the second easier to leave behind after the migration.
For the acquired-business account, a temporary exception might be justified while the dependency is replaced. Its practical ending matters: someone has to complete the work, revisit the account, and remove the exception when the supported route exists. The word temporary doesn't perform those actions.
After rollout, repeated failures among similar accounts are useful feedback about what the initial tests missed. The response should improve that group's supported path rather than quietly make its workaround the normal architecture.
The verified domain can remain a completed line in the plan. The enforcement decision needs a different line: whether the affected people and services can use the policy and recover when something goes wrong. Separating those questions makes progress easier to explain—and less likely to be discovered through Monday-morning lockouts.