Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Braze email setup is architecture-specific. The DNS records for a delegated domain, a custom return path and DKIM depend on the underlying sending arrangement. Do not build a production zone by copying a generic table from another Braze account. Begin with the records provisioned for your environment and the relationship between the visible From, bounce domain and tracking domain.
Choose the applicable setup route
Braze's self-service guide lists prerequisites: new-customer onboarding, Edit Domain Settings permission, an IP pool and addresses, and a verified domain. If your account does not meet that scope, use the current onboarding or support process rather than assuming the same interface exists.
Plan the domain hierarchy with the onboarding team. The documented self-service model requires a minimum three-level sending subdomain beneath the delegated domain, illustrated by e.marketing.example.com under marketing.example.com. Tracking domains are capped at twice the number of verified domains in the contract; request any increase from the account manager. Record the approved visible From domain, envelope MAIL FROM domain and tracking name separately. Preserve existing zone data and avoid reusing a name that already hosts corporate mail or another application.
Configure the provisioned identities
In the documented Domains setup, add a domain and enter the Mail from and Sending domain values for the IP pool, then choose the verified domain. Sending domains cannot be edited after submission; deletion requires support. Add the tracking subdomain under the appropriate verified or sending domain and select the workspaces that should use the configuration. Use the minimum appropriate workspace scope instead of enabling future access without a business need.
Wait for the sending and tracking domains to be ready. In the workspace's Settings, Email Settings, confirm the new domain is available for the From address and save the intended address. These instructions describe the cited self-service flow, not proof of an account's entitlement or completion.
Match DNS to the actual delivery architecture
References: RFC 7208 §2.4, RFC 1034 §3.6.2, RFC 9989 §4.4.
The Braze DNS reference distinguishes three arrangements. SparkPost uses a TXT DKIM key with CNAME-based return-path and tracking records. SendGrid uses delegated DKIM CNAMEs and a return-path CNAME. Amazon SES uses DKIM CNAMEs plus MX and TXT records for a custom MAIL FROM domain. Use the exact environment-specific names and targets, never the reference's sample customer IDs or region.
Braze documents return-path SPF at a dedicated subdomain, rather than asking users to append its permissions to the corporate apex. SPF is evaluated against the actual envelope identity. A record at the wrong owner cannot repair an unrelated envelope failure. If the supplied architecture uses a CNAME, do not add a competing TXT policy at that same owner.
Establish the effective DMARC policy for the visible From domain. Do not assume that different subdomains will align under strict mode: strict alignment requires exact domain equality. Verify the supported route with actual headers instead of inferring success from shared branding. Keep any organization-wide policy edit separate from initial provisioning.
Verify DNS, message identity and links
References: RFC 6376 §3.6.2, RFC 9989 §5.3.5.
Query the provisioned owner names at authoritative DNS and compare every type and target with the approved list. For a delegated branch, verify that the delegated authority is answering; records left only in the parent editor may not be relevant. Braze requires all four supplied NS entries to be explicitly present: inspect the complete dig NS answer and successful dashboard validation, rather than entering only one line because a lookup already displays four servers. Inspect the public key reached through each DKIM alias and the return-path record set.
Create an innocuous test campaign addressed to a controlled mailbox. Retain From, Return-Path, DKIM d=/s= and trusted Authentication-Results. Confirm at least one passing aligned path for DMARC. Then inspect click-tracking URLs separately. A ready sending domain with a pending tracking domain is not a complete branded-link acceptance result.
Illustrative test matrix: one workspace is allowed to use e.mail.example.com, a second is not, and the chosen bounce identity is under that domain. Check domain availability in both workspaces and the received identities from the allowed one. This is a proposed test, not an observed Braze result.
Handle changes without breaking active sends
If setup stalls, compare authoritative delegation and the provisioned records before changing values. Preserve failed test headers for the onboarding team. Coordinate domain removal with support and active campaigns; deleting records alone is not a safe retirement process. Recheck after architecture changes, new workspaces, domain moves or key rotation. Authentication readiness does not replace volume planning or deliverability monitoring. No live Braze configuration was performed for this article.