Two paths. The easy path provisions a subdomain under the platform's own zone so the builder does no DNS work at all. The own-domain path returns the SPF and DKIM records to add at their DNS host, then polls for verification and flips the account's sending identity when it passes.
Also called: SMTP setup · email from my domain · DKIM SPF records · emails going to spam
- 1The wizard's in-flight state lives on the account's provider binding as pending_domain / pending_mode / pending_dns_records
- 2Verify asks the provider to re-check DNS; on success the live domain and From identity are updated and the binding activates
- 3The provider key is never exposed to the tenant
- 4Deliverability streams (billing / updates / marketing) are separate sending identities so one cannot damage another's reputation
Customer mail sent from a generic platform address lands in spam more often and looks like it came from a stranger, but requiring every builder to edit DNS records before they can send anything stops onboarding dead. Both paths exist: a platform subdomain that needs no DNS work and sends immediately, or the builder's own domain with the exact records to add and a poller that confirms them. A builder starts on the first and moves to the second whenever they are ready.
- Poor deliverability from a shared generic sender
- DNS work blocking onboarding
- Marketing sends damaging transactional reputation
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →