nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What has your real-world experience been with CDN/SSL/DMARC setup in Braze environments?

EmPaulin

Would love to hear real-world experiences from teams managing the infrastructure side of Braze/email setups.

On paper, many of these implementations seem relatively straightforward if the right access and stakeholders are aligned:

CDN records
SSL validation
DKIM/SPF/DMARC
subdomain delegation
DNS propagation
sender authentication
mailbox provider requirements

But in reality, projects often become much more operationally complex once multiple teams get involved (IT, security, networking, agencies, franchise structures, external vendors, etc.).

Curious:

What ended up taking longer than expected?
What created the biggest blockers?
Any lessons learned around SSL mismatches, DNS configuration issues, propagation delays, or ownership confusion?
Did you centralize ownership or distribute it across teams?
What would you do differently if you had to rebuild the setup from scratch?

Would also genuinely love to hear the “war stories” behind implementations that looked simple initially but became unexpectedly complicated once real-world constraints entered the picture.

Find more posts tagged with

workplace and company settings

Accepted answers

Rocky

Yes I definitely understand why this is confusing. When we first send the records, the link tracking record must be pointed directly at the ESP. This is because we must validate that record by doing a check for a string that exactly matches what we've generated; this is for security reasons to authorize you as the owner of the subdomain. Once that has been completed, you may change the value of the link tracking record from the ESP to whichever CDN you plan to use for SSL, in order to redirect the traffic to the CDN

Rocky

The certificate needs to be created for the individual click tracking subdomain you plan to use. So if your click tracking subdomain is links.example.com, an SSL cert for example.com is not enough, you need one for links.example.com.

We do not recommend using wildcard certificates are they are unreliable for this function, however you can use a SAN certificate containing the click tracking subdomains if you have multiple.

All comments

stefanie.baldwin

HI @EmPaulin,
Your question is multifaceted and really invites everyone in to share their experience.

I'll be following this question to learn from others experiences and thoughts.

I'm learning more about the Braze platform everyday and questions like yours help me to go a little deeper. While I can't provide insight as a Braze Customer, I can help to connect you and other folks who may have similar questions with some of our latest resources on aspects of your question.

SSL Mismatches.
I've learned in cases of an SSL Mismatch these are the Braze recommended next steps:

Confirm that:

Your link tracking subdomain points correctly to the CDN via DNS CNAME records.

Your CDN is properly configured to apply SSL certificates to transformed links.

SSL is enabled by Braze after proper setup and verification.

If issues persist, contact your CDN provider for configuration help and your Braze customer success manager to confirm SSL enablement.

More Information on SSL

DNS Configuration Issues
For these issues, Braze recommends

Domain Entry and Record Matching: Ensure the domain is entered correctly and matches what you submitted to Braze. Also verify that the TXT and CNAME DNS records provided by Braze match exactly what you entered in your domain provider's settings.

Domain Usage Restrictions: You cannot use the same subdomain for multiple workspaces or if it is already in use for your main website or sending domain. Subdomains already assigned or with conflicting DNS records cannot be used for Braze landing pages.

Connection Stuck on "Connecting": If your custom domain shows all DNS records as "Connected" but remains stuck on "Connecting" for more than four hours, this may be caused by:
- CAA Records: These restrict which certificate authorities can issue SSL certificates. If your CAA records don’t include LetsEncrypt, Braze cannot issue the required SSL certificate. To fix, add a CAA record with: Record type: CAA and Value: 0 issue "letsencrypt.org".
- Cloudflare Zone Holds: If using Cloudflare, a zone hold security feature may block Braze from creating the custom domain. Temporarily releasing the zone hold can resolve this.

Restarting Validation: After resolving CAA or Cloudflare issues, delete and recreate your custom domain in the Braze dashboard to restart validation.

DNS Record Update Timeframe: For SMS/RCS custom domains, DNS records must be updated within 45 days, or you will need to restart the setup to generate new DNS records.

Removing Custom Domains: Removing a custom domain requires deleting the DNS records from your domain settings. Landing pages using that domain will revert to the Braze default domain.

DNS Provider Resources: Braze provides links to documentation for managing DNS records for common providers such as GoDaddy, Cloudflare, Amazon Route 53, Google Cloud DNS, Bluehost, Dreamhost, and Squarespace.

Customize Landing Page URLS

Self Serve Custom Domains

Propagation Delays
For this type if issue, using Intelligent timing may be helpful - but may lead to challenges if you're also using rate limiting. I think this resource might be a handy one for folks working through that challenge.

Intelligent Timing

Rocky

Hello! Stefanie let me know about this post, I’m Rocky and I manage the Email Operations team at Braze. Over the last ~11 years I have been involved with thousands of email setups, and last year I also conducted a study of some of these questions so we would have a better understanding ourselves.

Overall I will say the issues can be different at different ends of the customer size spectrum. A customer with a smaller dev team of one or two people can make it easier to relay information, get the team together on calls, etc. while a large enterprise team can have dozens of different hands that need to touch the email setup, complicating various steps. On the other hand, that also means larger teams will have focused experts in areas like domain hosting, security, strategy, and email administration, while bottlenecks can occur with smaller teams trying to handle all aspects of integration.

To answer the question “What ended up taking longer than expected” I can point to our findings that within the average email setup, SSL configuration takes roughly 75% of the total time to complete. Anecdotal evidence confirms this as well, as SSL integration is by far the element customers experience the most issues with. The biggest reason for this is that a third party CDN is typically required to handle the link traffic, and each requires its own set of processes and settings which can be confusing. Braze does have a product called Verified Domains currently in beta which will allow customers to delegate their domains directly to Braze through NS records, allowing us to complete not only whitelabel setup but also to handle SSL setup directly through Braze, obviating the SSL setup step. We are also working on improved documentation for third party CDN setups.

Other major blockers include DNS configuration issues, customer security concerns that need to be addressed, and internal delays preventing email setup. DNS configuration issues include mismatches in records (we validate using a string match, and even a trailing space can result in a mismatch), records being accidentally proxied, TTL being unusually long, and DKIM length issues. In terms of security, customers are sometimes concerned about the strictness of our authentications, the information transmitted through link traffic, and ensuring compliance with standards like GDPR. And customer delays can include any gamut of higher-priority projects that take precedence over email setup, sometimes coming into conflict with the organization’s IP warmup plan, contract dates, or overall strategy.

The biggest lesson I’ve learned is to never make assumptions. If you are a customer and are unsure of some aspect of our email setup, please ask. We can usually resolve these questions over a ticket, and I have also been on many a live call where we were able to answer questions and go over a customer’s email setup. Our team tries not to make assumptions either, and we will overcommunicate if need be to ensure everyone is on the same page. It’s vitally important to follow documentation to the letter, especially with SSL setup, as we’ve encountered many situations where a seemingly unimportant step was not followed and the entire setup failed to work until it was fixed. And finally, the issue is almost always something “small”: a missed character, an unclicked button, an empty dropdown, etc. The folks on our customers’ dev teams are intelligent professionals, so we rarely see “big” mistakes, and we’ve trained ourselves to look for the kinds of things that are easily overlooked.

While I can’t speak for our customers in terms of what they would do differently, if I were building an email setup from scratch, the main thing I would do is have a complete plan in place before making any setup decisions with Braze. Know not only your intended sending and tracking subdomains, but also which CDN you intend to use (if any), your IP load distribution, your DMARC policy, your branding strategy, etc. The biggest delay in everyday setup is making changes to something that’s already built, which wastes a customer’s own resources taking down setups that have already been built. I live by the saying “measure twice, cut once”. It will save you a lot of hassle in the short and long term.

I’ll end with a recent example of a “war story” concerning an extremely patient customer of ours. They were experiencing broken links in their emails, but strangely, it was an intermittent issue I could not reproduce. We spent two long days on calls going over their setup with a fine toothcomb. Everything pointed to it being an SSL issue, but their SSL seemed to be correctly configured. We were stumped. Finally, using the Inspect panel in Chrome, we discovered that the customer’s own website was erroneously adding a new cookie to every page visit through their email links, which when combined with Braze link tracking, cumulatively stacked until the amount of cookies became so large it exceeded the limit for traffic. Braze helped correct the issue in the short term by reducing the weight of their wrapped links while they worked internally to fix their cookies. Lesson learned: web traffic is an intricate and complicated system, and the failure could be occurring at points you would not have expected.

EmPaulin

How would this look like per CDN?

Your link tracking subdomain points correctly to the CDN via DNS CNAME records.

— considering that we follow the records sent from Braze.

EmPaulin

The DNS get set up fine with no issues the issues start with the SSL

Where the records sent seem to need adjustments as we move forward.

Any thoughts there?

Rocky

EmPaulin

Great way of explaining it :) thank you so much

EmPaulin

I'm getting different feedback. Does a certificate need to be created by the domain or by each subdomain?

stefanie.baldwin

@EmPaulin, I think @Rocky "Email Deliverability Extraodinairie" has helped to clarify in the posts following but wanted to make sure you have what you need.

Please let us know if you have additional questions

EmPaulin

Yes, "Email Deliverability Extraodinairie" indeed