Domain & DNS setup

This guide walks Admin through the initial email domain configuration required before you can start sending emails with Engage Studio.

The setup involves four main steps :

Before configuring your domain, collect the following information:

• Your sending domain or subdomain

  • We recommend using a subdomain to avoid conflicts with your corporate email infrastructure.

  • Example: If your brand domain is example.com, consider using mail.example.com.

• TD Write-only APIKEY (Admin)

  • Used to log email events to your Treasure Data tables.

Domain provisioning configures your custom email-sending domain and prepare it for DNS authentication and email delivery. This step is required before DNS records can be added and your domain can be verified.

To configure your domain and sender setup, Navigate to Engage > Sending Configurations > Create New.

Create Domain requires Domain name and Write-only API key you prepared at Step1.

Navigate to your new created domain. Then, click "Start domain deployment "

After deploy your domain (you may need to wait few mins to generate DNS records), click "Verify DNS records ". Then, you'll get DNS records.

Once Treasure Data provisions the domain, customers will receive a set of DNS records, which include:

• SPF (Sender Policy Framework) – TXT record that authorizes Agentic Engage powered by Amazon SES to send emails on behalf of your domain.

• DKIM (DomainKeys Identified Mail) – TXT record used to sign outgoing emails cryptographically, helping to verify message integrity and authenticity.

• DMARC (Domain-based Message Authentication, Reporting, and Conformance) – TXT record that specifies your policy for handling unauthenticated emails

  • If you already have DMARC configuration for the same domain, this DMARC is not necessary to configure. You can ignore pending status for DMARC.

  • Accepted DMARC Policies:

    • p=none : default. This policy instructs receiving email servers to take no specific action if a message fails DMARC checks.The email is delivered as usual, regardless of the DMARC authentication result. However, DMARC reporting mechanisms can be used: the domain owner may receive reports about authentication failures, but recipients see no difference in their inboxes.

    • p=quarantine : Tells receiving mail systems that messages failing DMARC should be treated with suspicion. Emails that do not pass DMARC are typically delivered to the recipient's "spam" or "junk" folder, rather than the main inbox. Recipients may still be able to access the message, but it is not treated as trusted or legitimate.

    • p=reject : Specifies the strictest enforcement. If a message fails DMARC, it should not be accepted. Messages failing DMARC authentication are rejected at the server: they are not delivered at all, and typically the sending server receives a bounce notification. The recipient never sees the failed message in their mailbox.

• Certificate Validation (CNAME) – CNAME record used to verify domain ownership for issuing an SSL/TLS certificate. This certificate enables HTTPS for secure click tracking and image delivery.

• Click Tracking (CNAME) – CNAME record used to rewrite and track link clicks. It redirects links through Engage click tracking endpoint while preserving the original destination.

• Image Hosting (CNAME) – CNAME record used to serve email images from a Content Delivery Network (CDN) under your branded domain. This improves performance and helps ensure image assets are loaded securely via HTTPS, which enhances domain trust and email deliverability.

• MX Record (Mail Exchange) – Specifies the server responsible for accepting emails sent to your domain. Needed to process bounces and auto-replies.

Example of DNS records:

Copy the Zone file to send to your IT team.

DNS verification flow is following:

1. Status starts as SUSPENDED

2. User clicks "Verify Domain" → status becomes DEPLOYING

3. Once records are created, Apply the configuration to your DNS system

4. User clicks "Verify DNS" once the configuration is completed

5. System polls verification status every few minutes for 72 hours

6. On success → status becomes ACTIVE

7. On failure → status reverts to SUSPENDED

Verification statuses:

• Verified : All records successfully validated

• Pending : Waiting for record propagation

• Temporary Failure : DNS issues detected post-verification

• Failure : Verification expired (after 72 hours)

  • If you see this error, please reach out to Treasure Support.

• Not Started : Verification process not yet triggered

The deployment events will be executed automatically, it will take 1-2 days from start to completion. The process is successful when all of the following events are complete.

• UPDATE_TO_SECRET_COMPLETED

• UPDATE_TO_IDENTITY_COMPLETED

• UPDATE_TO_CDN_COMPLETED

• UPDATE_TO_CERTIFICATE_COMPLETED

• UPDATE_TO_ENABLE_IDENTITY_COMPLETED

• UPDATE_TO_ENABLE_CDN_COMPLETED

• UPDATE_TO_DIGITAL_ASSETS_COMPLETED — required for HTML Email Hosting (View in Browser) and serving image content from your own domain

When you create a domain, or change the Write-only API key on an existing domain, Treasure AI verifies that the key can write to the domain's email events database before saving. If the key cannot write to that database, the operation is blocked and an error like the following is shown under the Write-only API key field:

eventWriteOnlyKey - does not have write access to the email events database "delivery_email_<your_domain>". Please contact your administrator and make sure the API key has write permission to the database (including permission to create it if it does not exist).

The database name in the message identifies the events database the key must be able to write to. It follows the pattern delivery_email_<your_domain> (for example, a domain of new-domain.com maps to delivery_email_new_domain_com).

This check runs on both flows:

Create Domain

Edit Write-only API key

To resolve this error:

1. Note the database name shown in the error message (delivery_email_<your_domain>).

2. Make sure the write-only API key has write permission to that database. Note that if the database delivery_email_<your_domain> does not yet exist, the user associated with the key must also have permission to create new databases. For how to grant or verify these permissions, see Database Access Control Matrix. Alternatively, generate a new write-only API key that belongs to a user who already has the required permissions.

3. Re-enter the key and save the domain again.