Data & backend
Custom emails
Send branded transactional email — sign-in links, receipts, notifications — from your own domain.
Vorx apps send transactional email — and you can make it come from you, not a generic no-reply address. Once your domain is set up, sign-up confirmations, password resets and your app's own notifications all send from an address like noreply@notify.acme.com, authenticated with SPF, DKIM and DMARC.
Delivery runs on Resend, a third-party email service used by thousands of apps. Vorx can manage that for you — you never need to create an account — or you can connect your own Resend account.
Authentication emails
Six built-in kinds, sent automatically by your app's auth: confirm signup, password reset, magic link, invite, email change and reauthentication.
App emails
Emails your app decides to send — receipts, alerts, "email the owner when a lead comes in." Ask for them in chat like any other feature.
Before you start
An app with a backend
Email ships with apps that have a Vorx backend — that's where auth and the sending functions live.
A domain you own
The same domain your site uses is fine. You'll add a few DNS records wherever you manage it.
DNS access
Cloudflare, Namecheap, GoDaddy — anywhere you can add records. No nameserver changes needed.
Everything below starts from Project → Settings → Cloud → Email. Setup is a four-step wizard: Sending account → Your domain → DNS records → Done.
Step 1 — Choose a sending account
By default Vorx handles delivery for you through its own Resend account — nothing to sign up for, recommended for most apps. Prefer to own the relationship? Connect your own Resend, SendGrid, or Mailgun account instead: your billing, your sending reputation, and email keeps working even if you ever move off Vorx.
Using your own Resend account?
Create the API key with Full access — a "Sending access only" key won't work, because Vorx also registers your sending domain for you. The key is checked with Resend before it's saved, then stored encrypted and never shown again.
Step 2 — Your domain
Enter the domain you own — acme.com — and Vorx shows you exactly what your emails will come from: noreply@notify.acme.com. Delivery uses the notify subdomain so your main domain's email reputation stays protected; most people never change it. Under Advanced options you can pick a different subdomain, or show emails as sent from your main domain (delivery still uses the subdomain — only the visible address changes).
Step 3 — Add the DNS records
Vorx generates the records that authenticate your email and shows them with copy buttons. For acme.com with the default notify subdomain they look like this:
Type
TXTName / Host
resend._domainkey.notifyValue
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ… (yours is generated for you)Type
TXTName / Host
send.notifyValue
v=spf1 include:amazonses.com ~allType
MXName / Host
send.notifyValue
feedback-smtp.us-east-1.amazonses.comType
TXTName / Host
_dmarc.notifyValue
v=DMARC1; p=none;Enter the names exactly as shown
Record names are relative — your DNS provider adds .acme.com for you. Typing the full hostname yourself creates a doubled name like notify.acme.com.acme.com, the single most common setup mistake. If it happens, Vorx's per-record check tells you precisely which record to fix and how.
Let an AI do it
Click Copy setup instructions for AI to get a ready-to-paste prompt with every record — hand it to an AI assistant with browser access (or your developer) and they can add the records for you.
Vorx re-checks your records whenever you come back to this tab — alt-tab to your registrar, add a record, come back and watch it flip to a green check — or press Check my records any time. Every record gets its own diagnosis (Added, Not added yet, Needs a fix) rather than a bare pass/fail. DNS changes usually appear within an hour, occasionally up to 48 hours.
Verification and activation
Activation is automatic
The moment your domain verifies, Vorx deploys the email functions into your app's backend and connects them to authentication. Sign-up confirmations, password resets and the rest immediately send from your domain — there's no extra switch to flip.
Domain statuses
- Setup needed
Waiting for you to add the DNS records.
- Checking
Some records found; waiting for the rest to appear.
- Finishing
All records are in place — the provider is running its final check, usually under a minute.
- Sending
Verified. Email is going out from your domain.
- At risk
Records that were verified are no longer resolving — mail may bounce or land in spam until they're restored. Vorx re-checks verified domains and flags this for you.
- Failed
The email provider rejected the domain. Remove it and set it up again.
Templates and branding
Email templates are branded with your app's name and edited the same way you edit the rest of your app — ask in chat to change the wording, layout or colours. A few rules are enforced at send time, because deliverability mistakes show up days later as a spam-folder problem:
- App emails always carry an unsubscribe link; authentication emails never do (you can't opt out of a password reset).
- The content card stays white, and messages stay under ~100 KB so Gmail doesn't clip them.
- No scripts or external stylesheets — things spam filters punish.
After setup: the email dashboard
Once your domain is sending, Settings → Cloud → Email becomes a dashboard:
- Usage and delivery — this month's send count against your quota, with delivered / bounced / failed totals.
- Test sends — send yourself any of the six auth emails through the real delivery path.
- Activity log — every message with its delivery status.
- Blocked addresses — addresses that hard-bounced or reported spam are suppressed automatically so they can't hurt your reputation; you can unblock one after it's fixed.
Limits
Each project includes 50,000 emails per month and is rate-limited to 500 per hour — per project, not per workspace, so one app's signup burst can't block another's. Bursts beyond the hourly rate are queued rather than dropped.
A brand-new sending domain sometimes lands in spam at first — that's normal while its reputation builds, and it settles as real recipients receive and open your mail.
FAQ
No. By default Vorx sends through its own account on your behalf. Connecting your own key is optional — it gives you your own billing and reputation, and keeps email working if you ever move off Vorx.
No. Every record lives on the sending subdomain (notify.acme.com), so your main domain's MX records — and your normal inbox — are untouched.
Yes — turn on "Show emails as sent from my main domain" in Step 2's advanced options. Delivery still happens on the subdomain; only the visible address changes.
Usually under an hour once the records are added; DNS can occasionally take up to 48 hours. Vorx checks automatically — you can leave the page and come back.
No — this is for transactional email only: authentication and messages your app sends in response to something a user did. That restriction is a big part of why your mail stays out of spam.
Vorx keeps re-checking verified domains. If a record disappears, the domain flips to "At risk" and the email panel shows exactly which record to restore.
Ask in chat — "send a receipt when an order is placed." Your app gets a sendEmail() helper wired to the same delivery path, with the same guardrails.