External DNS setup
Worked on UX and product requirements for BYOD external DNS setup in Cloudflare Email Service, including manual DNS record setup mockups and input into polling and notification policy for DNS drift.
Problem
Customers using BYOD or external DNS needed a smoother path to configure Email Service. The setup flow had points where requirements, ownership, and next steps could feel unclear. After setup, DNS drift also needed a clear policy for rechecks, status changes, and customer notifications.
My role
I worked on clarifying the product experience for BYOD setup, translating customer friction into focused product and engineering work, and giving input on polling and notification policy for DNS drift.
What I produced
- A setup flow review mapping where customers using BYOD or non-Cloudflare DNS could get blocked, confused, or unsure who owned the next step
- A UX mockup for manual DNS record setup, showing how customers could copy, add, validate, and troubleshoot required DNS records
- Product requirements for clearer BYOD activation, including the states customers should see before, during, and after DNS configuration
- Input into polling and notification policy for DNS drift, including when records should be rechecked, how configuration changes should be surfaced, and when customers should be notified
- Recommendations for drift states and customer-facing messaging, so customers could distinguish between pending setup, valid configuration, missing records, and records that changed after activation
- Developer experience recommendations for copy, validation messaging, and guidance that make required DNS actions easier to complete
- Engineering-ready task breakdowns tied to specific setup friction points, rather than broad “improve setup” requests
- Customer pain point synthesis for teams managing DNS outside Cloudflare, including assumptions that differ from the default Cloudflare-managed path
Key decisions / tradeoffs
I focused on reducing setup ambiguity while avoiding an overly complex wizard. For drift, the tradeoff was how often to poll and notify: customers needed timely visibility when DNS records changed, but too many checks or alerts could create noise. I pushed for a clearer status model and notification policy that made configuration health visible without making customers feel spammed or overwhelmed.
Outcome
The work created clearer direction for improving external DNS setup and reducing adoption bottlenecks for Email Service customers.
What I learned
A product can be technically powerful and still lose users if setup expectations are not explicit.