1. Integrate the application

CNAME records and subdomain delegation

You can set up a subdomain for a Sitecore Search integration by using Sitecore certificates or your own certificates.

When you create a subdomain, you avoid common web tracking barriers and enhance the reliability of visitor tracking on your website.

  • Avoid tracking blocks - ad blockers and intelligent tracking prevention (ITP) technologies commonly block cookies from third-party domains, affecting services like Search that rely on cookies for anonymous visitor tracking. To circumvent this, you can create a subdomain, like rfk.yourdomain.com, allowing Search to store cookies under your domain. This approach prevents Search cookies from being flagged as third-party, ensuring uninterrupted tracking and reporting through your dedicated subdomain.

  • Simplify authentication - when Search runs on your subdomain, requests originate from your domain, which improves compatibility with browser-based tracking and first-party scenarios. This supports browser-based usage and removes extra authentication steps, but is not an API security control and does not enforce CORS or restrict request origins.

Note

Subdomain setup is usually required for production environments to support browser-based tracking and first-party integrations. For non-production environments, this setup is usually not required unless there is specific testing or validation needed. For example, end-to-end testing of browser-based behavior.

Choosing a subdomain strategy depends on the level of control and management you want to retain of your DNS (Domain Name System) configuration. The following sections provide an overview of CNAME records and subdomain delegation.

Note

The subdomain uses your domain nickname and is included in the SSL certificate generated during setup. Ensure your nickname follows the supported naming rules.

CNAME records

One strategy is to use a CNAME record, a type of DNS record that maps an alias name to a true or canonical domain name. Here, you create a subdomain, like <yournickname>.rfk.<yourdomain>.com, and then use a CNAME record to point the subdomain to a Search domain. Sitecore Search provides the CNAME records.

This is a relatively simple setup. You can choose this method when you want to maintain control over your broad DNS settings. You direct visitor traffic from a branded subdomain to Search without changing the overall structure of your domain's DNS.

Here's an example of this strategy as configured in Search:

Table showing CNAME details.

Subdomain delegation

Another strategy is to use subdomain delegation, where you allow Search to manage your subdomain. You can create a subdomain, like <yournickname>.rfk.<yourdomain>.com and then point it to name servers provided by Search.

Important

Subdomains used with Sitecore Search follow the format: <nickname>.rfk.<yourdomain>.

The .rfk. segment is required and cannot be removed or replaced with a single-level subdomain (for example, nickname-rfk.yourdomain.com is not supported).

<yournickname> – a unique identifier for your subdomain.See Nickname requirements for supported formats and restrictions.

This is a relatively advanced setup. You can choose this method when you want Search to fully control the DNS records for your subdomain. By allowing this, Search can precisely control and customize the subdomain's DNS settings, without impacting the DNS management of your main domain.

Here's an example of this strategy as configured in Search:

Table showing nameserver details such as type, hostname value, and time-to-live (TTL) value.

Websites connected to this domain

The Websites connected to this domain setting can be accessed via Administration > Domain Settings > Websites connected to this domain. It is used to associate your website hostnames with a Search domain. This supports domain association and delegated trust for browser-based integrations that use a Search subdomain.

This setting associates website hostnames with the Search domain for domain recognition and trust, and supports browser-based integrations that rely on first-party behavior.

This setting does not:

  • Act as an API allow-list.

  • Control CORS (Cross-Origin Resource Sharing) behavior.

  • Restrict or validate the origin of API requests.

  • Apply to backend or API-key-based calls.

If you have suggestions for improving this article, let us know!