In addition to your site's single Primary Custom Domain, you can reach your site through more than one domain. There are two ways to do this, either by defining new Custom Domains in your site, or by supplying your own SSL certificate to support multiple domain names. Site Administrators can configure either approach.

Use additional Custom Domains for most cases. Attach any number of independently configured domains, each scoped to a specific purpose (such as branding Public Hosting) and each with its own automatically managed SSL certificate. This option is simple to configure and lets you limit how each domain is used.

Using a Shared SAN Certificate for FTPS Access requires you to manage a single Subject Alternative Name (SAN) certificate yourself, covering every domain you want to use as an alternate address for your Primary Custom Domain.

For FTPS, each additional domain can use its own dedicated IP addresses and certificate. Use a Shared SAN Certificate when the domains should share the Primary Custom Domain's addresses and one certificate instead.

Additional Custom Domains

Custom Domains used in addition to your Primary Custom Domain are individually configured. By default, your site automatically issues and renews an SSL certificate for each domain through Let's Encrypt, so you don't manage a shared certificate at all. This is different from the Shared SAN Certificate approach, where every domain relies on one certificate that you obtain and renew yourself. You are not required to reissue or update anything when you add or remove an additional Custom Domain.

You can also upload your own certificate for a Custom Domain if you need to manage it yourself. This certificate only needs to cover that one domain name.

Each Custom Domain also needs its own CNAME record. Copy the exact target displayed for that domain under DNS Configuration in the SSL Certificates settings. Targets can differ between domains on the same site, so use each domain's displayed value to route connections to the addresses serving its certificate. See Custom Domain DNS Records for DNS configuration guidance.

Destinations

Every Custom Domain has a Destination, which determines how it can be used.

Setting the destination to Site Alias means the domain behaves like a second entry point to your main site, reaching the web interface, API, and WebDAV just like your Primary Custom Domain. The exception is Yubikey, WebAuthn, and FIDO 2FA methods, which can only be set up through your Primary Custom Domain.

A Site Alias with its own dedicated IP addresses can also present its own certificate for FTPS and its own SFTP host keys. This lets you consolidate several SFTP services on one Files.com site while keeping their hostnames and trusted host keys distinct. The domains still lead to the same site, with the same users and permissions; use Child Sites when you need separate site settings and content.

Setting the destination to Public Hosting means the domain serves Public Hosting content only, either for all of your publicly hosted folders or for one you select; see Binding a Public Hosting Domain to One Folder below for how that restriction works.

Setting the destination to Inbound S3 means the domain serves the S3-compatible endpoint. This works through any S3-compatible client or SDK, using the same Access Key ID and Secret Access Key you already use with s3.files.com.

Setting the destination to Unassigned disables the domain without deleting it. When you delete a publicly hosted folder that is assigned to a custom domain, your site automatically sets the domain's destination to Unassigned. An unassigned domain does not route any traffic.

Binding a Public Hosting Domain to One Folder

When you set an additional custom domain's destination to Public Hosting and bind it to a specific publicly hosted folder, that folder is the only link on your site that can use the custom domain name address. Attempting to access other publicly hosted folders, or any of your site's other URLs with that domain name will display an error. By default, the original [subdomain].hosted-by-files.com address continues to work alongside your custom domain.

Enable the bound folder's option to serve it only on its custom domain when its content must have a separate browser origin from other hosted folders. The shared hosting address no longer serves that folder, so update links and integrations to use the custom-domain URLs. Keep the folder's CORS setting disabled or limit it to origins you trust to receive the content. See Public Hosting for how this works with password protection, site login, and publishing permissions.

Share Links and Inboxes are unaffected by additional custom domains; their generated links continue to use your site's Primary Custom Domain. See Share Links, Inboxes, and Emailed Links below.

Dedicated IP Addresses and FTPS

Additional Custom Domains use Server Name Indication (SNI) by default, allowing each domain to present its own certificate on shared addresses. Creating or attaching an SSL certificate does not allocate dedicated IP addresses to the domain. Modern browsers, API clients, and WebDAV clients support SNI.

An additional domain can have its own set of dedicated IP addresses. These let Files.com present that domain's FTPS certificate without relying on SNI, and let it identify which SFTP host keys to present before a user signs in. For several domains sharing the Primary Custom Domain's addresses over FTPS, use a Shared SAN Certificate.

To allocate addresses, a Site Administrator opens the Custom Domains table in the Custom Domain settings and selects Add Dedicated IPs for the domain. Choose 1 IP Address or 2 IP Addresses, then submit. This action is available for any destination while the domain has no dedicated addresses.

Allocation is a one-time choice for each domain. After allocation, the action disappears and the Dedicated IP Addresses column shows the assigned addresses. Copy the domain's updated CNAME target from DNS Configuration in the SSL Certificates settings and update its record at your DNS provider. Update any firewall allowlists that need to reach the new addresses. Custom Domain DNS Records explains how to configure the record.

Dedicated-IP allowances are pooled across a Parent Site and all its Child Sites. Each allocated set counts toward that allowance, whether it contains one or two addresses. The message Cannot allocate another set of dedicated IP addresses for this plan. means the pool is exhausted. Contact Files.com if you need additional capacity. A temporary allocation-capacity error asks you to try again in an hour or two; contact support if it persists.

Deleting an additional Custom Domain releases its dedicated addresses. There is no separate release action while keeping the domain, and setting its destination to Unassigned does not release them. Plan changes to client connections and DNS before deleting a domain.

The allocation action assigns addresses from Files.com; it does not transfer an existing server's addresses. If retaining existing addresses is part of your migration, coordinate that requirement with Files.com before changing DNS. Bring Your Own IP covers migrations using an address range your organization owns.

Using a Shared SAN Certificate for FTPS Access

With a single Subject Alternative Name (SAN) certificate, you configure each domain as an alternate address for your Primary Custom Domain, using one certificate that covers all of them and shares the Primary Custom Domain's dedicated IP addresses.

Use this approach when you need FTPS access from several domains on the same addresses and can manage their shared certificate. For independently managed certificates, use additional custom domains with dedicated IP addresses for each domain that needs FTPS. Additional domains used for web access or Public Hosting can use SNI without their own dedicated addresses.

SSL Certificates for Multiple Domains

In order to access Files.com from multiple custom addresses this way, you'll need to manage your own SSL certificate that uses Subject Alternative Name (SAN) covering all of the domains you want to use. The easiest way to generate a CSR for multiple domains is with the Files.com web interface. When you are generating the CSR, supply any Additional Domains the certificate needs to cover. Files.com will remove any duplicates and will remove the primary domain from the list if it was included.

Every domain you configure must be covered by your certificate. Files.com supports wildcard certificates such as *.example.com for a matching configured hostname, but a wildcard certificate does not make every matching subdomain an address for your site. Define each hostname you intend to use in Files.com.

You can use other tools to generate your certificate without the Files.com web interface Generate CSR feature. While these tools commonly let you specify the key type when generating the certificate, only RSA key types are compatible with Files.com.

Plan Ahead to Minimize Downtime

You can minimize the downtime involved in switching from a Files.com certificate to your own SSL certificate by setting your CNAME records to a low TTL before you make the switch. Set the Time-To-Live (TTL) duration for your CNAME DNS records to no more than 60 seconds.

Since you will be providing your own SSL certificate, upload your new certificate to your site prior to changing the custom domain.

When you are ready to activate your new certificate, do so immediately after changing your CNAME records. With a sufficiently low TTL, you will likely see only a few minutes of disruption before your certificate will be served for your site.

You Are Responsible for Renewing Your Certificate

Because you must supply your own SSL Certificate in order to use your site with multiple domains this way, you are responsible for renewing the certificate. Plan to renew any expiring SSL Certificate prior to its expiration date and time.

Once your SSL Certificate Provider has provided you with your renewed SSL Certificate, import the certificate (and its intermediate certificates) just as you imported the previous one. You can activate the new certificate before the old certificate expires.

Applying and activating a renewed SSL Certificate will not change your custom domain or its dedicated IP addresses.

SAN Certificates Are Not Wildcard Certificates

A certificate can cover several explicitly named domains through its SAN entries or matching subdomains through a wildcard. Files.com supports both forms of certificate coverage. Certificate coverage and site configuration serve different purposes: the certificate validates the encrypted connection, while the configured hostname determines which address Files.com serves. For example, a certificate for *.example.com can cover your configured files.example.com domain without enabling anything.example.com as another address for your site.

Configure Your Custom Domain

Upload and activate your SAN certificate as you would when configuring a single custom domain.

In the SSL Certificates settings, find each domain under DNS Configuration. Create a CNAME record for each domain using the exact target displayed alongside that domain. Copy these values from Files.com to ensure each address reaches the service configured to present your certificate.

Complete the setup of your custom domain by updating your custom domain setting in Files.com with the primary domain address. You can only choose one domain to be the Primary Custom Domain of your site. This domain must be included in your SAN list.

Accessing Your Site by Primary Custom Domain

Once you've completed configuring your custom domain with the SAN certificate, the appropriate CNAME records, and the main custom domain setting, you can access the site through the web URL that matches your custom domain setting. When you do, Files.com serves the certificate that includes all of the domains you wish to use.

Accessing Your Site by Secondary Custom Domain

Once you've finished setting up your custom domain, you can log in via web, API, WebDAV, or FTPS at the alternate domain addresses from your certificate. When you do, you'll be served the certificate that lists your primary domain as the "Common name" and your other domains in the "Alternative names".

You can also access your site through SFTP at the secondary addresses, but because SFTP does not use SSL certificates, this won't provide the certificate you configured.

Changing the Primary Custom Domain When Using a Shared SAN Certificate

If your site is configured with multiple custom domains using a SAN SSL certificate, you can change which domain is set as the Primary Custom Domain without losing access to your other domains. This is useful when phasing out an older domain or shifting to a new brand identity while maintaining continuity for users and integrations.

To switch to a different primary domain, go to the Custom Domain setting in your Files.com site and update it with the new domain. The new primary must be one of the domains already listed in your SSL certificate and properly configured in DNS. Once saved, it becomes the domain used in all newly generated links and emails.

Existing Share Links and Inbox URLs that were generated using the previous primary domain will continue to work as long as that domain remains valid in your certificate and its DNS is correctly configured. Users can continue accessing the site from both the old and new domains, provided both are included in your certificate and properly routed. However, all system-generated links and emails will now use the newly selected primary domain.

SSO return URLs will also reflect the change in primary domain. In most cases, no action is needed if your identity provider (such as Okta or Azure AD) accepts the new domain as part of the return URL. If your IdP is configured to allow only specific domains or return URLs, update its settings to include the new primary domain to avoid login issues. This step is only necessary in stricter SSO configurations that enforce domain-level validation for authentication callbacks.

Regardless of which approach you use to add more domains to your site, Share Links and Inboxes always use your Primary Custom Domain address to generate links.

The same is true of any links Files.com emails on your behalf, including Inbox and Share Link invitations, email notifications, new user welcome emails, password recovery emails, and site alert emails. There is no way to override this behavior.

Using Child Sites for Multiple Custom Domains

Child sites offer a simple way to support multiple brands for your users by creating a separate site for each domain.

A child site is an entirely separate site that is associated with your primary account. Each child site's content and its settings, such as remote servers, logos, and custom domain are separate from all your other sites. Parent site users can be granted access to any of your child sites.

Each child site's custom domain can use a Files.com-managed SSL certificate. Branding a child site with a custom domain also means that generated URLs (such as with share links, inboxes, public hosted, or emailed links) will always match the child site's custom domain.

To share the same content across multiple sites, use copy automations within the parent site to copy data to child site folders. Another option is to add the parent site as a remote server within a child site, and then either mount a parent folder in the child or sync folders between the child and parent.