Skip to main content

Custom Domain DNS Records

The Custom Domain for your site requires you to configure specific DNS records for your domain. The specific steps vary depending on your DNS provider.

CNAME Records

CNAME records connect your custom domain to your Files.com site. CNAME records for your custom domain are not managed by Files.com, because they are for a domain that you control. You will need both administrator access to your Files.com site and access to your account with the DNS provider for your domain to configure CNAME records.

Common DNS providers used by Files.com customers include CloudflareExternal LinkThis link leads to an external website and will open in a new tab, GoDaddyExternal LinkThis link leads to an external website and will open in a new tab, NameCheapExternal LinkThis link leads to an external website and will open in a new tab, Amazon Route 53External LinkThis link leads to an external website and will open in a new tab, HostingerExternal LinkThis link leads to an external website and will open in a new tab, Microsoft Azure DNSExternal LinkThis link leads to an external website and will open in a new tab, and Google Cloud DNSExternal LinkThis link leads to an external website and will open in a new tab. As long as your DNS entries are resolvable by the public, they can be used with Files.com.

Configuring Your CNAME Record

Once you have chosen your custom domain, the next step is to set up a CNAME DNS record with your DNS provider. The CNAME record's value will depend on whether your custom domain will use an SSL certificate provided by Files.com or your own SSL certificate.

If you plan to use SSL certificates managed by Files.com, your CNAME record must point at your subdomain address. If you are using your own custom SSL certificate your CNAME will point to an address that contains your subdomain name in the form s-[subdomain].di.app.files.com.

We recommend using the shortest allowable TTL value for your CNAME record.

We strongly recommend setting the TTL (Time to Live) for your custom domain CNAME records as low as permitted by your DNS provider, usually between 30 and 60 seconds. The DNS performance increase provided by large TTL values (many systems will default to 14400 seconds, or even 86400 seconds) is negligible compared to the risk of waiting hours or days for addresses to propagate. A short TTL minimizes the disruption when you change the DNS record, such as when switching between your own SSL certificate and a Files.com-controlled certificate.

You will encounter much higher recommendations elsewhere (even up to 24 hours) for the TTL of CNAME records, but the negligible performance gains are offset by the potential disruption. When you're making changes to the address used by your customers, employees, and vendors to access your site, you don't want them waiting up to 24 hours to see the change. A low TTL helps updates happen faster.

Multiple CNAMEs

You can have any number of CNAME records pointing at your site, one for each domain you add, whether it's an Additional Custom Domain or a domain covered by a Shared SAN Certificate. See Multiple Custom Domains for how those two approaches differ and which one to use.

Unregistered CNAMEs

Some customers have discovered that it is possible to configure a CNAME record from a domain they control to their .files.com subdomain without configuring it in Files.com as a custom domain. We strongly recommend against this practice because it will not result in a valid SSL certificate for the custom domain, and it will not provision any dedicated IP addresses.

Some customers do this for domains that will be accessed only through SFTP because SFTP doesn't use SSL certificates at all. This method of pointing a domain is unsupported.

Using DNS A Records Instead of CNAME (also called flattened CNAME)

Manually configured A records are not supported. However, some DNS providers, such as Cloudflare, automatically "flatten" CNAMEs defined on the root of a domain to return A records rather than a hostname when the CNAME is resolved.

The DNS provider internally performs the additional queries needed to determine the actual IP and returns the result, just as if the CNAME was an A record. Flattening a CNAME can be helpful for modern web development, allowing you to use the root of your domain as the address for a service.

You can use a flattened CNAME for your site's custom domain. The DNS record must be configured to refresh rapidly, ideally every 60 seconds. To avoid accidentally blocking legitimate access, do not use any proxying for your flattened CNAME records.

CAA Records

One pitfall with A Records and CNAME flattening is that they make CAA records a potential issue as well. If you use a CNAME, none of this section applies, because the CNAME automatically makes CAA records always work correctly.

A CAA Record is a security feature of the DNS system that allows domain name owners to restrict which issuers are allowed to issue SSL Certificates for a given domain.

If you are not using a valid CNAME record, and your Custom Domain has a CAA record set in your DNS, you might need to either update your CAA record to allow our Certificate Authority to issue certificates or provide your own certificate.

We issue certificates through a popular Certificate Authority called Let's EncryptExternal LinkThis link leads to an external website and will open in a new tab.

If you have a CAA DNS record for your custom domain, you need to create another CAA record with the value letsencrypt.org so we can issue the certificate.

If you need any help with this process, let us know the service you're using to manage your DNS records.

Avoid Proxying Services for CNAMEs

For a provider like Cloudflare, which also offers a proxying service in addition to DNS, disable proxying for your flattened CNAME records. Files.com does not support being wholly behind Cloudflare on your main site subdomain (though we do support this for public web hosting shares).

Proxies route all visitor traffic through a small set of shared IP addresses belonging to the proxy provider. Your site can no longer see the actual IP address each visitor is connecting from, so it can't tell abusive traffic from legitimate traffic at the origin. Blocking abuse then blocks everyone else sharing that IP too.

Proxying doesn't add any benefit for a custom domain. Customers who enable it usually expect DDoS protection, a web application firewall, content caching, or a hidden origin IP, but Files.com already handles all of that: TLS is terminated at your site's own dedicated IP addresses, and there's no cacheable static content for a proxy to speed up, since Files.com is a file transfer platform, not a static website. Enabling proxying just removes the visibility Files.com needs to protect your site.

Proxying also affects your own ability to allowlist or log connections by IP address, since every proxied visitor shows up as the proxy provider's IP instead of their real one. Protocols like FTP are also likely to stop working correctly when proxied.

If your custom domain already has dedicated IP addressesExternal LinkThis link leads to an external website and will open in a new tab, enabling proxying releases them, since Files.com can no longer confirm traffic is reaching your site directly through them.