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.

Only use a Shared SAN Certificate if you specifically need more than one domain to work over FTPS. Additional custom domains do not support FTPS.

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, following the same pattern as your Primary Custom Domain. See Custom Domain DNS Records for the CNAME value to use, which depends on whether you're using a Files.com-managed certificate or your own.

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.

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. The original [subdomain].hosted-by-files.com address continues to work alongside your custom domain.

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

Custom Domains do not get their own dedicated IP addresses. If your site already has dedicated IP addresses from its Primary Custom Domain, your additional domains share those same IP addresses, and the correct certificate is selected using Server Name Indication (SNI). SNI is supported by modern web browsers, API clients, and WebDAV clients, but the FTP protocol does not support SNI, even in its FTPS form.

Because of this, site alias Custom Domains do not work over FTP or FTPS. Only your site's Primary Custom Domain can be used to connect over FTPS. If you need more than one domain to work over FTPS, use a Shared SAN Certificate instead.

Using a Shared SAN Certificate for FTPS Access

Managing a single Subject Alternative Name (SAN) certificate yourself is the only way to give more than one domain access over FTPS. With this approach, you configure each domain as an alternate address for your Primary Custom Domain, using one SAN certificate that covers all of them and shares the Primary Custom Domain's dedicated IP addresses.

Consider this approach only if you specifically need FTPS access from more than one domain. For most other cases, such as branding Public Hosting links or adding a secondary web address, use additional custom domains instead, since Files.com manages a separate certificate for you automatically.

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.

Only domains which are explicitly listed in your certificate can be used as a custom domain for your Files.com site.

Do not use a wildcard, such as *.example.com, which is not compatible with 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

You cannot use a Wildcard SSL certificate with the Custom Domain feature. Only domains which are explicitly listed in your certificate can be used as a custom domain for your Files.com site.

Configure Your Custom Domain

Create the CNAME records for each custom domain you will use for your site. All of the domains that will be used with your custom domain will use the same CNAME record value - an address that contains your subdomain name in the form s-[subdomain].di.app.files.com.

With your SAN certificate in hand, you can upload it as you would when configuring a single custom domain. After uploading your SSL certificate, you must activate it.

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.