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 configure, what you own, and what stays on our side of the wall.
The short version
- Email is configured in the dashboard under
Messaging → Email. The page has two tabs: Providers (the account your mail is sent through) and Templates (the emails themselves). The "Connected Apps" page is for mobile-app bundle IDs, not sending credentials. - Sending from your own address needs Professional or above. Until you connect a provider, mail goes out through the shared BetterSuite sender. Below Professional the Providers tab shows the upgrade prompt; the Templates tab is open on every plan.
- What you own either way: the DNS for your sending domain (SPF, DKIM, DMARC). Deliverability lives or dies on these records regardless of who holds the API key.
The shared default sender is managed by BetterSuite staff. You never need to touch it.
Sending from your own address
If you want email coming from your own domain ([email protected] rather than the shared BetterSuite sender), open Messaging → Email → Providers and click Add provider:
- Provider type — SendGrid and MailerSend have native integrations. The list shows the provider types available to your workspace.
- Name — your label for this provider.
- From email, and optionally From name and Reply-to — the sender identity.
- Credentials — encrypted at rest and never shown again. Leave them blank on a later edit to keep the stored values.
- Make this the default sender — the default is used for every email unless a template says otherwise.
Have these ready before you start:
- A restricted API key with
Mail Send-only scope. - The sender address you want to use, e.g.
[email protected]. - The DNS records below, in place on that domain.
If your provider isn't in the list, open a Support ticket and tell us which one you use.
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. To change the copy — different CTA wording, additional disclaimers, a custom footer — open Messaging → Email → Templates. Every scenario (sign-up, receipts, password reset, and so on) sends a built-in default; you can override any of them with your own subject and body, or point it at a template hosted by your provider. Test renders a scenario with sample data, as a dry run or a real send, and Revert to default puts the built-in email back.
Troubleshooting
The failure modes you can investigate yourself are mostly DNS:
- Customers report emails missing — first check your provider's activity log (on the shared sender, open a Support ticket and we'll look). 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 — retry policy, a provider type you don't see in the list — 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.
