Memority Services DNS Domains
Memority provisions two dedicated tenant instances for each client: one for production use, and one for preproduction purposes such as staging or user acceptance testing.
Each service is available through a dedicated Memority service DNS domain.
Memority service DNS domains provide access to the following key features, among others:
Memority web portals, including the user portal and the administration portal.
Identity Provider portal, used for authentication and application federation.
Identity management API endpoints.
Certificate-based authentication.
These service domains will have a different name based on the Memority environment.
Memority Environments and Domain Structure
The domain structure (name) depends on the Memority environment in which we deploy the tenant. Memority supports two client-facing environments:
Production – for operational use.
Staging – for pre-production or User Acceptance Testing (UAT).
Each environment has its own domain naming convention. For example:
Production tenants typically use domains under
.memority.comStaging tenants use domains under
.stage.memority.cloud
The naming of the Memority services DNS domain is based on two parameters:
The technical tenant name, assigned at the start of the project.
The target environment, defined during setup.
Once these elements are confirmed, Memority generates the corresponding domains.
Domain Model Selection
The domain model must be selected during the initial tenant setup phase. This choice is final and cannot be changed later.
Two configuration models are available:
In most cases, the Memority-managed domain offers the most straightforward configuration. Memority handles all DNS and certificate management, which allows for a fully supported deployment.
Memority-Managed Domain
In this option, Memority provides and fully manages the DNS domain.
Key Characteristics
A standardized Memority domain naming convention is assigned to the tenant.
Memority creates automatically and maintains all required DNS records.
TLS certificates are issued and renewed automatically as part of the service.
Why choose this option
No DNS setup or maintenance is required on the client side; all DNS records stay up to date throughout the service lifecycle.
TLS certificates are fully managed by Memority, with no client involvement for issuance or renewal.
Domain Configuration Requirements
As part of the initial setup process, Memority assigns a unique technical tenant name for each client’s tenant. This technical name is used in the standard Memority DNS domain naming.
The tenant name will consist of lowercase letters only (a–z).
→ No digits, hyphens, or underscores are allowed.
Domain Naming Conventions by Environment
As part of the standard DNS setup, Memority applies different domain naming patterns depending on the environment type (production or staging).
Production Environment Tenants
In the production environment, DNS entries follow this naming pattern:
<app>.<tenantname>.memority.comWhere:
app= one of the standard Memority service modules:
my | sso | api | certauth | admintenantname= the technical tenant name (lowercase only, no digits or special characters).
Domain shortcut redirection:
For user convenience, Memority sets up redirects to simplify portal access.
https://<tenantname>.memority.com
→ Redirects tohttps://my.<tenantname>.memority.com
→ which in turn redirects tohttps://my.<tenantname>.memority.com/portal/<tenantname>
This redirect leads to the user management portal.
Staging Environment Tenants
In the staging environment, Memority uses a fixed DNS alias that includes .stage:
<app>.<tenantname>.stage.memority.cloudWhere:
<app>= one of the standard Memority service modules. (e.g.,my,sso,api,certauth,admin)<tenantname>= the technical tenant name used for staging purposes (usually matching the production tenant)stage= a fixed label in the DNS to indicate the staging environment
The word "stage" is a naming convention used in the DNS itself and is not related to the client environment tenant.
Domain shortcut redirection:
To simplify user access, Memority sets up convenient redirects:
https://<tenantname>.stage.memority.cloud
→ Redirects tohttps://my.<tenantname>.stage.memority.cloud
This redirect points to the user management portal, allowing users to access it without needing to specify the full my. subdomain.
Customer-Managed Domain (Custom FQDN)
In this case, Memority services are exposed under a custom DNS domain fully owned and operated by the client. This setup allows clients to integrate Memority within their own DNS infrastructure.
When Memority is deployed under a domain owned by the customer, the customer is responsible for creating the required DNS records and managing the TLS certificate.
Key Characteristics:
A custom access domain defined by the client.
Example:iam.clientdomain.comThe domain is a Memority services DNS domain that the client can fully:
Customize.
Own.
Operate.
The client is responsible for:
Creating and maintaining all required DNS records.
Managing the TLS certificate lifecycle.
For TLS certificate renewal:
Memority provides a Certificate Signing Request (CSR).
The client uses the CSR to obtain a TLS certificate from their chosen Certificate Authority (CA).
Why choose this option
Flexibility to align the Memority services DNS domain with the client’s internal standards and branding
Full ownership and control of both the DNS domain and the TLS certificate management
Domain Configuration Requirements
The client must complete these steps before Memority can deliver the client's tenant under a customer-managed domain. Timely completion of these steps is mandatory.
Failure to complete these actions may result in delivery delays for which the client remains responsible.
Before deployment, the client must complete the following requirements for each environment where Memority services will be exposed under a customer-managed domain:
Provide a client-owned subdomain dedicated to Memority services for each environment
One subdomain per environment is required (e.g.,
iam.clientdomain.com,iam-staging.clientdomain.com)The subdomain must follow Memority naming recommendations.
Provide a TLS certificate
For the initial deployment and each renewal, request a certificate using a CSR provided by Memority.
The certificate must:
Be a wildcard certificate.
Include the appropriate Subject Alternative Names (SAN).
Confirm requirements with your chosen Certificate Authority (e.g., DigiCert, GlobalSign, etc.).
Create the required DNS records
Set up public DNS entries pointing to Memority’s service IP addresses
IP addresses and record formats will be provided by Memority
Naming recommendation: Subdomains should clearly identify the environment and purpose (e.g., iam.clientdomain.com, iam-staging.clientdomain.com).
Memority will provide Security and validity requirements and your Certificate Authority must review them.
Client Custom DNS Domain Naming Recommendations:
When using a customer-managed Memority services DNS domain, Memority recommends the following naming convention:
<app>.<clientiamservicename>.<clientrootdomain>Where:
<app>= fixed subdomain provided by Memority (e.g.,my,sso,api,certauth,admin).<clientiamservicename>= client-chosen subdomain dedicated to Memority (e.g.,iam).<clientrootdomain>= the client's root domain, fully owned and controlled by the client
(e.g.,clientdomain.com).
For the rest of this document, we assume the domain follows this format:
<app>.iam.clientdomain.comTLS Certificate Requirements
Certificates must comply with the following technical requirements:
Field | Requirement |
|---|---|
Certificate Authority | Chosen by the customer |
Key Algorithm | RSA 2048 |
Signature Algorithm | SHA256withRSA (compliant with STD004) |
Validity | 1 year |
Common Name (CN) | The CN in the TLS certificate can be either:
The CN is not always a wildcard — it depends on the Certificate Authority and the certificate product. |
SANs (Subject Alt Names) |
Both SANs are mandatory and must be present in certificate. |
TLS Certificate Purchase Guidance
When purchasing a TLS certificate, the client must ensure the selected offer is compatible with the technical requirements listed above.
We provide the following guidance to help the client choose suitable TLS certificate offers. These recommendations are indicative only, as provider offerings may change over time.
Memority recommends choosing certificates that meet the following criteria:
Organizational Validation (OV) Level.
Wildcard and Multi-domain options available.
Memority also supports Domain Validation (DV) certificates. However, an OV certificate is recommended to provide better trust and assurance for end users.
Recommended Providers
The following table shares the commonly used and compatible Certificate Authorities and their mandatory options
Provider | Mandatory options |
|---|---|
The requested certificate should have the following structure:
If your users connect from older devices, request the cross-signed G5 chain from DigiCert and provide it to Memority with your certificate. See the warning below.** | |
| |
The requested certificate should have the following structure:
If your users connect from older devices, request the cross-signed R46/E46 chain from Sectigo and provide it to Memority with your certificate. See the warning below.** | |
The requested certificate should have the following structure: - Common Name (CN): Certificates ordered via Nameshield chain to the Sectigo R46/E46 roots. The warning below also applies.** |
*This configuration example applies when purchasing a Sectigo certificate via Nameshield. Other providers available through Nameshield may also be used if they comply with the technical requirements.
** Warning: Certificate compatibility with older client devices
Most public Certificate Authorities have migrated their issuance to new single-purpose root certificates. Older devices do not include these new roots in their trust stores. Only Android 14 and later can update the trust store without a full OS update, so devices running Android 10 to 13 without a manufacturer update keep a trust store from 2019 to 2023.
By default, Memority serves the standard certificate chain. Support for older devices is not enabled by default, so that you can choose to rely exclusively on modern root certificates. If your user population includes older devices, request their support explicitly when you provide your certificate. There is nothing to install on your side: Memority installs your certificate and its complete chain, including the cross-signed root, on the service
DigiCert issues all new certificates from its G5 root hierarchy. Devices running Android versions earlier than 14 do not trust the G5 roots natively. Request the cross-signed G5 root together with the intermediate certificate. DigiCert revoked two older cross-signed G5 roots on May 15, 2026, so make sure DigiCert delivers the current cross-signed versions.
Sectigo completed its migration to the R46/E46 root hierarchy in January 2026 and no longer issues or reissues certificates under its legacy chains. Certificates chained directly to R46 fail on Android 7 to 12. Request the cross-signed chain anchored on the AAA Certificate Services or USERTrust root instead.
With the complete cross-signed chain in place, Android 10+, iOS 10+, and Windows 7+ with automatic root updates enabled validate the certificates without issues.
DNS Entry Requirements
The client is responsible for creating public DNS A records that point to the IP addresses provided by Memority. These IP addresses are listed in a DNS configuration document shared by Memority during the setup phase. The document includes all the required entries for Memority services. It may also include additional records, such as DKIM, depending on the project scope.Currently, five DNS records are required:
my.iam.clientdomain.com
sso.iam.clientdomain.com
api.iam.clientdomain.com
certauth.iam.clientdomain.com
admin.iam.clientdomain.comA dedicated subdomain (such as iam.clientdomain.com) is mandatory.
Domain shortcut redirection:
To simplify user access, Memority sets up convenient redirects:
https://iam.clientdomain.com
→ Redirects tohttps://my.iam.clientdomain.com
Environment-specific usage
The client can use different domain configurations depending on the environment. For example, the client can :
Configure a customer-managed domain for the production tenant to match their corporate domain structure (e.g.,
iam.clientdomain.com).Use a Memority-managed domain for the staging tenant to simplify the setup (e.g.,
myclient.stage.memority.cloud).
The choice between these options depends on the project context, operational considerations, and domain ownership policies.