Skip to main content
You can configure a custom domain for your Data Provider instance so that customers interact with a familiar branded domain (e.g., consent.acme-corp.com). This domain will be used for:
  • Hosted consent authorization screens
  • Optional consumer consent dashboard
  • API endpoints (HTTPS and optional mTLS)
  • Outgoing email (for OTPs and notifications)
You can always view the active domain for your Data Provider in the Console → Settings → Domains.

​
Adding a Custom Domain

Configure domains in the Console under Custom Domains.
1
Click Add Domain
2
Enter the desired subdomain (e.g., cdr.acme-corp.com.au). It must be a subdomain of your organisation’s root domain.
3
Click Next
4
Create the required DNS records as shown in Console
5
Click Start Verification
  • If DNS records verify successfully, Fiskil will provision TLS certificates and update your instance.
  • Propagation may take time; track progress in the Console.
  • Once a domain is configured, it cannot be changed without assistance. If you need to reset, contact support.
You can configure separate custom domains for staging and production. Switch between environments using the drop-down in the top-right of the Custom Domains menu.

​
Required DNS Records

When enabling a custom domain, multiple DNS records must be created:

​
1. Endpoint Records (CNAME)

  • CNAME records map your custom domain to the Fiskil-assigned subdomains.
  • Required for:
    • HTTPS API endpoints
    • mTLS API endpoints
    • Consent authorization UI
    • Consent dashboard

​
2. CAA Records (TLS Certificates)

  • Two CAA records are required so Fiskil can use Google and Let’s Encrypt to provision TLS certificates.
  • Ensures browsers trust your custom domain.

​
3. Email Records (Authentication)

Fiskil sends emails from your Data Provider domain (e.g., for OTPs and notifications). To ensure deliverability, configure:
  • DKIM & SPF —
    • CNAME records for em***.<custom-domain>
    • s1._domainkey.<custom-domain>
    • s2._domainkey.<custom-domain>
  • DMARC —
    • TXT record for _dmarc.<custom-domain>
    • Defines a DMARC policy to reject unauthenticated messages
Together, these records allow public email servers to verify messages sent from your domain, reducing the risk of spoofing and improving inbox delivery.

​
Best Practices

  • Use separate subdomains for staging and production (e.g., consent.staging.acme-corp.com, consent.acme-corp.com).
  • Configure DNS records early — verification requires propagation and may take hours.
  • Apply strict DMARC policies (p=reject) for production domains.