Best Of

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.

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.