BetterSuite sends transactional email for OTPs, receipts, password resets, driver invites, order confirmations, and platform notifications. This article is the honest state of email delivery on the platform as of today — what you own, what we own, and what's still on our side of the wall.
The short version
- There is no tenant-facing UI for configuring an email sender today. The Ops Console doesn't have an email-provider page, and the owner dashboard's "Connected Apps" surface is for mobile-app bundle IDs, not SMTP credentials.
- The platform-admin email-provider configuration is staff-only. The route exists at
/admin/email-providersbut is gated byPLATFORM_ADMIN— only BetterSuite staff can reach it. The supported provider kinds in the backend are SendGrid and MailerSend with native SDK integrations, plus generic SMTP and HTTP-webhook fallbacks. - What you do own: the DNS for your sending domain (SPF, DKIM, DMARC). Deliverability lives or dies on these records regardless of who holds the API key.
If you need email coming from your own domain ([email protected] rather than a default BetterSuite-owned sender), open a Support ticket from the owner dashboard and we'll provision the provider record on your tenant and verify the sender domain together.
What BetterSuite staff handles
The platform-admin email-providers page (/admin/email-providers) lets us:
- Create a provider row for your tenant, choosing one of:
- SendGrid — native integration calling
api.sendgrid.com/v3/mail/send. - MailerSend — native integration.
- Generic SMTP — host, port, username, password, TLS flags.
- HTTP webhook — for one-off providers behind a custom JSON API; configured per-tenant by a definition row.
- SendGrid — native integration calling
- Store the credentials (encrypted at rest) and the sender identity.
- Mark a provider as the tenant default.
When you open a ticket asking us to set up sending from your domain, we need:
- The provider you've chosen (SendGrid, MailerSend, your own SMTP, or another).
- A restricted API key with
Mail Send-only scope (or SMTP credentials). - The sender address you want to use, e.g.
[email protected]. - Confirmation that the DNS records below are in place — we'll verify them before turning the provider on.
We do not promise day-of turnaround on these; this surface is moving to a self-serve flow in the Ops Console and we'd rather get the schema right than ship a half-built page. Track the work on the public roadmap.
What you own: SPF, DKIM, DMARC
Regardless of who holds the sending credential, the DNS for your sending domain stays with you. Without these records emails land in spam, full stop.
SPF
A TXT record on your sending domain authorising the provider's IP ranges. Your provider will give you the exact value; for SendGrid it looks like:
| Type | Host | Value |
|---|---|---|
| TXT | @ (apex) | v=spf1 include:sendgrid.net ~all |
If you already have an SPF record for marketing email or another vendor, merge them — only one SPF record per domain is allowed.
DKIM
Provider-issued CNAME records (usually 2–3) that publish the public half of the keypair the provider signs your outbound mail with. SendGrid's domain authentication wizard produces them; MailerSend and Postmark each have their own equivalents. Add them exactly as printed, including the trailing dot if the provider includes one.
DMARC
DMARC ties SPF and DKIM together and tells receivers what to do with mail that fails both. Gmail and Yahoo now require a DMARC record on any domain sending bulk mail.
| Type | Host | Value |
|---|---|---|
| TXT | _dmarc | v=DMARC1; p=quarantine; rua=mailto:[email protected] |
Start with p=quarantine. After a few weeks of clean aggregate reports (the rua mailbox), tighten to p=reject for the strongest stance.
Email templates
The default templates work out of the box and pick up your branding (logo, colors, typography) automatically from Owner Dashboard → Branding. There is no tenant-facing template editor today; if you need substantive copy changes — different CTA wording, additional disclaimers, a custom footer — request them through Support along with the provider setup and we'll do the override.
Troubleshooting
Until the self-serve surface lands, the failure modes you can investigate yourself are mostly DNS:
- Customers report emails missing — first check the provider's activity log (we'll grant you access). If the provider says "delivered" but the recipient's inbox says nothing, it's a deliverability problem, not a code one.
- Gmail / Outlook flag as spam — almost always a missing or mis-aligned DKIM, or a missing DMARC. Re-run the provider's domain authentication check.
- Hard-bounce spike — a wrong sender address, or you're sending to a list that wasn't built consensually. Investigate before tightening DMARC further.
For everything else — the underlying API key, retry policy, fallback provider — open a Support ticket.
What's next
- Branding — email templates inherit logo and colours from here automatically.
- Custom Domains — keep your sender domain aligned with your customer-facing domain.
- Stripe Payments — receipts only go out once both PSP and email are wired.
