Objective

This document explains how a client can use their own domain name (e.g., myApp.myCompany.com) to access their DAZZM application, instead of the default address (myApp.octopus-esm.com).

This procedure applies to all environments: Production, Test, and Training.

⚙️ Process overview

Using a custom domain requires collaboration between:

• The DAZZM team (network and platform)

• The client (or their IT team)

• And, in some cases, AWS Certificate Manager, which manages the SSL certificates

The process involves three main steps:

🧩 Step 1 - Preparation and URL Validation

1. The client confirms the final URLs to be used for each environment:

   • Production → myApp.myCompany.com

   • Test → test.myApp.myCompany.com

   • Training → training.myApp.myCompany.com

2. The DAZZM team generates the required DNS records for validation (CNAME entries for certificates, email configurations, etc.).

3. This information is sent to the client for creation within their DNS system.

⏳ Important Note

Once a certificate is created, it must be validated within 72 hours.

After that period, the certificate must be regenerated, and new DNS entries will be required.

🔐 Step 2 — SSL Certificate Validation

1. Once the DNS entries have been added, AWS automatically validates the certificates.

2. When validation is successful, the certificates become active and secure the application URLs (HTTPS).

✅ This validation allows DAZZM to host the application under the client’s domain while maintaining security through SSL/TLS encryption.

🌍 Step 3 — Web DNS Configuration

1. After SSL validation, DAZZM provides the Web CNAME records (two per environment).

2. The client or their IT team adds these entries to their DNS.

3. The URLs then become fully functional, for example:

   • myApp.myCompany.com

   • test.myApp.myCompany.com

   • training.myApp.myCompany.com

✉️ Email Configuration

If the application sends emails using the client’s domain, the following records must also be configured:

• SPF

• DKIM

• DMARC

These records ensure that messages are not marked as spam and help maintain proper email deliverability.

⚙️ Alternative Option: DNS Delegation (Optional)

When possible, the client may delegate the relevant subdomains to DAZZM.

This allows DAZZM to directly manage DNS entries (CNAMEs, certificates, renewals, etc.) without requiring the client or their IT team’s intervention for each change.

How it works:

The client adds NS records for the delegated subdomains:

myApp.myCompany.com
test.myApp.myCompany.com
training.myApp.myCompany.com

🔁  This delegates DNS management for those subdomains to DAZZM, while the client retains full control — they can remove the NS records at any time to regain management.

🔍  Since DNS is by nature public, the client can audit the records at any time to verify configuration transparency.

⚠️ Key Considerations

• AWS certificates expire if not validated within 72 hours.

• DNS entries used for certificate validation must remain in place to ensure automatic renewals.

• Close coordination between DAZZM and the client’s IT team is essential to avoid disruptions.

• Certificate DNS entries should always be created before the Web CNAMEs.

• DNS delegation is the most flexible approach (when permitted by client policy).