Skip to main content

Sign-in domains

Applies to: identity after 0.35, mail after 0.47 · Checked: 30.09.2026

SimpleTwo has no single domain registry (the product owner's decision of 28.09.2026). Each list has one owner:

  • identity keeps the sign-in domains — the domains people sign in with, and the owner of each;
  • the mail role keeps the accepted domains — which domains it takes mail for, and of what kind: mailboxes, aliases (receive only), relay;
  • the coordinator reads both lists and owns neither.

A domain's owner​

Every sign-in domain has exactly one owner:

  • identity — a person of that domain signs in with identity's own credentials (password, second factor, passkey);
  • a company provider (ADFS, Entra, Keycloak, a SAML IdP) — a person of that domain signs in through it only: no password here, no other provider.

A provider's domains field in the provider list is the same list, seen from the provider's side. The owner can be changed in either place, with one result:

  • naming a domain in a provider's domains gives it to that provider (from identity too); two providers cannot name one domain — such a write is refused;
  • dropping a domain from a provider's domains, or deleting the provider, gives the domain back to identity and keeps it on the list: it is still a domain people sign in with. Only a delete in the sign-in domains table removes it.

Domains are kept lower-case in their IDNA form: Пример.РФ is stored as xn--e1afmkfd.xn--p1ai.

Where it is in the console​

In the identity console, the Federation tab starts with the Sign-in domains card: the domains with an owner to choose on each row, a field for a new domain with its owner, and a delete button. Every change is an audit row (signin_domain.put, signin_domain.delete, signin_domain.apply for a change made through a provider).

The first fill​

The list is filled once — on its first read, while nothing has ever been written to it:

  1. the domains each provider had stored before — with that provider;
  2. the domains of existing account logins that contain @ — owned by identity.

The fill is one audit row, signin_domain.seed. Deleting every domain later does not fill the list again.

Checks against the mail domains​

Identity reads the mail role's accepted domains (GET /v1/service/domains, service token svc:identity) and keeps the answer for five minutes.

  • Sign-in codes by e-mail. The organisation's domains for this factor are identity's sign-in domains and every accepted mail domain of any kind, and their subdomains. An address in them is not accepted as a personal one. If the mail role does not answer, no code is sent.
  • An account's primary address. When the primary address is set or changed (by the coordinator, SCIM, or an account created through a provider), identity refuses it unless its domain is a mail domain of kind mailboxes or relay (during a migration the company's own domain relays to the old server, and people hired then need an address in it); an aliases domain does not qualify. The check runs only when the mail role is deployed and answers: without a mail role the installation has no mailboxes to check against, and a mail role that does not answer cannot say no — the write goes through and the service log keeps a warning. Guests and bots are not checked: mail gives them no mailbox. An unchanged address is not checked.

For integrations​

  • GET /v1/service/signin-domains — for svc:coordinator and svc:mail: {rev, domains: [{domain, upstream?}]}, sorted; no upstream means identity owns it.
  • GET /control/signin-domains, PUT /control/signin-domains/{domain} with the body {upstream?}, DELETE /control/signin-domains/{domain} — the console and the coordinator. The owner must exist; an unknown provider is a 400.