- Shipped
- September 3, 2026 at 1:32 AM UTC
- Author
- Kamo
- Commit
- a5843fa
A domain typed into the create form is a CLAIM, not a host. Ownership is proven by a DNS TXT record afterwards and a certificate is issued after that, so between the two an org has rows naming a hostname that does not resolve. Every member-facing link in an email read that hostname off the org's first domain row with nothing checked — not ownership, not the certificate, not even is_active. Harmony Home Loans is the reported case: every row on harmonyhomeloans.net has ownership_verified and ssl_confirmed null and no subdomain of it exists in DNS, so a new member's verification link — the one thing they must click before the account works at all — pointed at nothing. An org is reachable on its provider's host whatever state its own domain is in, so OrgEntryDomainResolver answers with the org's own domain once verified, else the nearest securityProvider up the chain that has one (a reseller's tenants belong on the reseller's login screen), else the platform's, which always resolves. The conditions are the ones **************** routes on, deliberately: a link that disagrees with where signing in actually lands is a link to nowhere. It replaces five byte-identical open-coded copies — in member creation, email verification, document notifications and both lead notifiers — which is how they all carried the same bug, and how fixing one would have left four still mailing dead links. The old fallback loop was worse than unchecked: it accepted ALIAS rows and pasted them onto their parent, so an org whose first row was `api` produced login.api.<domain>. **************** keeps its own-domain-only semantics — it builds a deep link INTO the workspace behind an existing domain-complete gate, and skipping is the right answer there — but now says so with OrgDomains.primaryDomain rather than a sixth copy.