VibeWeek
Home/Grow/Custom Email Domain & White-Label Sending: Chat Prompts

Custom Email Domain & White-Label Sending: Chat Prompts

⬅️ Back to 6. Grow

If you're a B2B SaaS where customers send email to their customers through your product (drip campaigns, transactional emails, notifications, marketing sends), you need to support sending from their domain, not yours. Your customer's brand is acme.com; emails to their users should come from support@acme.com, not notifications@yoursaas.com. The sender, the reply-to, the domain authentication (SPF / DKIM / DMARC) — all should look like Acme owns it.

This is technically non-trivial. Each customer adds DNS records (SPF / DKIM / sometimes DMARC) to their domain; you verify the records are correctly configured; you sign outgoing emails with their DKIM private key; you respect their domain's reputation; you handle bounces + complaints back through your platform. Done well, customers' deliverability is preserved + their brand is protected. Done poorly, your customers' emails land in spam, their reputation takes a hit, and they blame you.

When This Belongs

Use custom email domains when:

  • Your product sends email as customers (vs your branded transactional email)
  • Customers have their own domains
  • Deliverability + brand alignment matter (most B2B SaaS)
  • You're past 50+ customers and the "all email from yoursaas.com" stops working

Don't bother when:

  • Pre-revenue / single-tenant
  • Email is purely from your brand (you're the sender, not your customer)
  • Internal tools without external email

Architecture

The standard pattern uses an email provider that supports subdomain-based DKIM signing with custom domains:

I want to support custom email domains for my B2B SaaS. Each customer adds DNS records on their domain; I sign outgoing emails with their DKIM key.

Pick the right email provider for this:
- AWS SES with Configuration Sets: built-in custom domains; cheap; complex DNS setup
- Postmark: clean API; signed-by-postmark domain auth; scales well
- SendGrid: similar; well-supported white-label domains
- Mailgun: good for high-volume; per-domain config
- Resend: modern; supports custom domains
- Customer.io / Loops: bundled with email-marketing platforms

For a transactional + lifecycle SaaS at $5M ARR, recommend the right pick.

Architecture pattern:
1. Customer goes to "Email Settings" in your dashboard
2. Inputs domain (e.g. acme.com)
3. You generate DNS records to add (SPF include, DKIM CNAME, DMARC TXT)
4. Customer adds records via their DNS provider
5. You verify records (poll or manual check button)
6. Once verified, all emails for this customer's tenant go from acme.com with proper signing

Stack: Next.js + your email provider's SDK + DNS verification.

The dominant choice in 2026 for SaaS: Postmark or Resend. Both support modern custom-domain workflows.

DNS Records Customers Add

Three records per custom domain:

SPF (Sender Policy Framework)

Tells receivers which servers are authorized to send for the domain.

acme.com TXT  "v=spf1 include:spf.yourprovider.com -all"

If customer already has SPF, they can't have two SPF records. They need to merge yours into theirs with include:.

DKIM (DomainKeys Identified Mail)

Cryptographically signs outgoing mail. Each customer gets a unique DKIM key pair.

selector1._domainkey.acme.com CNAME selector1.dkim.yourprovider.com
selector2._domainkey.acme.com CNAME selector2.dkim.yourprovider.com

Some providers (Postmark, SendGrid) generate keys on their side and the customer adds CNAMEs pointing to them. Others let you generate the key pair and the customer adds the public key as a TXT record.

DMARC (Domain-based Message Authentication)

Tells receivers what to do if SPF or DKIM fail.

_dmarc.acme.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@acme.com"

For modern email (post-2024 Gmail/Yahoo enforcement for bulk senders), DMARC at minimum p=none is required. Customer typically owns DMARC; you instruct them.

The Onboarding UX

Build the customer-facing UX for adding a custom email domain:

Step 1: Domain Input
- Form: "Email domain (e.g. acme.com)"
- Validation: valid domain format
- Save and proceed

Step 2: Generate DNS Records
- Show 3 boxes: SPF, DKIM (1 or 2 CNAMEs), DMARC (optional + recommended)
- Each box: name, type, value, TTL
- Copy-to-clipboard buttons
- Quick-link to popular DNS providers (Cloudflare, GoDaddy, Namecheap, Route53) with screenshot guides

Step 3: Verification
- "Verify DNS" button
- Backend checks DNS via dig / Node DNS API
- Surfaces specific errors: "SPF record not found" / "SPF doesn't include our send servers" / "DKIM TXT mismatch"
- Auto-retry every 30 minutes for 24 hours (DNS propagation takes time)
- Email customer when verified

Step 4: Confirmation
- "Domain verified — your emails will now send from acme.com"
- Sends a test email to a customer-provided test address

Step 5: Ongoing Monitoring
- Periodic re-verification (DNS records can change)
- Alert if DKIM stops verifying (key rotation; misconfiguration)
- Surface deliverability metrics per domain

Stack: Next.js + Postmark / Resend / Mailgun + Node DNS module.

Sending Email Through the Custom Domain

Build the email-sending logic that uses the customer's verified domain:

For every outgoing email:
1. Look up the recipient's customer / tenant
2. Get the customer's verified email domain (or fall back to your default if not configured)
3. Set the From header: `notifications@<their domain>` (or whatever local part they configure)
4. Set Reply-To similarly
5. Sign with their DKIM key
6. Send through your provider's API

For Postmark:
```ts
client.sendEmail({
  From: `notifications@${customer.emailDomain}`,
  ReplyTo: customer.replyTo || `support@${customer.emailDomain}`,
  // ...
  // Postmark looks up the verified domain config and signs with the right DKIM key
});

Edge cases:

  • Customer hasn't verified their domain yet: fall back to your shared domain (with their name as friendly From: e.g. "Acme via YourSaaS noreply@yoursaas.com")
  • Customer has multiple domains (rare): let them pick or use rules
  • Customer's DNS broke after verification: log + alert; fall back to shared

Stack: Next.js + Postmark.


## Bounce + Complaint Handling

When emails sent from a customer's domain bounce or get marked spam, you need to:

  1. Receive the webhook from your email provider (Postmark / Resend / SES)
  2. Identify which customer's email this is (from message-id or stored metadata)
  3. Update the recipient's status: bounced (hard / soft) or complained
  4. Suppress future sends to that recipient (most providers do this automatically)
  5. Surface metrics to the customer: bounce rate, complaint rate per domain
  6. Alert customer if their bounce rate exceeds a threshold (e.g., >5%)

Per-domain reputation:

  • Track per-customer-domain stats (bounce rate, complaint rate, sending volume)
  • Surface in dashboard: "Your domain reputation is healthy / warning / poor"
  • High bounce/complaint rates can poison the shared sending IP — protect by rate-limiting customers approaching thresholds

Stack: Next.js + Postmark webhooks + Drizzle.


## Multi-Tenant Sending IP Strategy

Your email provider has shared sending IPs by default. As you scale, you may need:

  • Shared IPs (default): customers share the IP pool; reputation shared
  • Dedicated IPs: per-high-volume customer; isolated reputation
  • IP warming: gradually increase send volume on a new IP to build reputation
  • IP rotation: spread load across multiple IPs

Decisions:

  • Below 50K emails/customer/day: shared IPs are fine
  • Above 100K-500K: dedicated IPs
  • Customers with bad list hygiene: isolate their reputation

Implementation:

  • Postmark / SendGrid let you assign customers to specific IPs
  • Dedicated IP costs $80-150/mo per IP typically
  • Surface to customer: "your domain's reputation is X" — informs them why some sends underperform

Stack: Postmark / SendGrid + your provisioning logic.


## Subdomain Strategy: Avoiding Reputation Mixing

Best practice for B2B SaaS supporting custom domains:

Have customers use a SUBDOMAIN, not their main domain, for SaaS-sent email:

  • Customer's brand domain: acme.com
  • Customer's SaaS-sent email: mail.acme.com or send.acme.com (subdomain)
  • DNS records added to the subdomain
  • From address: notifications@send.acme.com

Why:

  • Your sending behavior (volume, content) doesn't affect their main domain reputation
  • Customers can't accidentally use their primary brand for spammy outbound
  • DMARC policy on the main domain stays strict (p=reject) while the subdomain accepts your mail
  • Industry-standard pattern (Mailchimp, Salesforce, Hubspot all do this)

Recommend this in onboarding UX. Make it the default; explicit opt-in for primary domain (rare).

Stack: pure DNS strategy; affects what records you generate.


## Common Pitfalls

**Verifying just one DKIM CNAME.** Some providers issue 2-3 CNAMEs for redundancy + key rotation. Customer adds 1; you verify only one; emails fail to sign properly. Verify all required records.

**Not handling DNS propagation delay.** Customer adds records; clicks verify; immediate failure. They give up. DNS can take 24-48h. Auto-retry; communicate "this can take up to 48 hours."

**SPF conflicts with existing.** Customer already has `v=spf1 include:_spf.google.com -all` for Workspace. Adding yours = two SPF records (invalid). Detect existing SPF; instruct them to merge.

**No fallback for unverified domains.** Customer signs up; doesn't configure custom domain; you can't send anything. Always have a fallback (your shared domain).

**Allowing main-domain configuration as default.** Customer's main acme.com gets associated with bulk send patterns. Reputation poison. Default to subdomain.

**No bounce / complaint visibility.** Customer's domain reputation degrades; they don't know why. Surface metrics + alerts.

**Allowing customers to configure spam-list domains.** Customer types `gmail.com` (yes, this happens). You can't authenticate it. Validate the customer actually owns the domain.

**Periodic re-verification missed.** DNS changes; customer's domain breaks; emails start sending unsigned. Re-verify at least weekly; alert on changes.

**Mixing customer's bounces into your shared reputation.** One bad customer's high bounce rate hurts every other customer on the shared IP. Per-customer rate-limiting + warning system.

**No explicit warning before degraded sending.** Customer's bounce rate is 8%; you keep sending at full volume. Cap volume at high bounce rates; alert.

**Custom Reply-To pointing to your platform.** Customer's customers reply; replies go to noreply@yoursaas.com. Default Reply-To to a customer-configurable address.

**Hard-coded `From` in templates.** Templates have `From: noreply@yoursaas.com` baked in; ignores per-tenant config. Always pull From from config.

**Verifying CNAME by checking host name.** DNS verification via `dig` returns the actual record; case-sensitive issues + trailing dots cause false negatives. Use a robust DNS lib that handles these.

**Forgetting DMARC.** Modern Gmail / Yahoo bulk requirements (Feb 2024+) require DMARC. Customer skips DMARC; emails to Gmail land in spam. Make DMARC part of the onboarding (even if optional, recommend strongly).

**No support for customer-managed DKIM rotation.** Eventually customers want to rotate keys. If your provider doesn't support, you're stuck.

**Allowing custom From local-part without sanity check.** Customer puts From: `paypal@acme.com` — phishing risk. Validate / restrict to brand-aligned values.

**Verification button without rate limiting.** Customer mashes it; you DNS-query 100 times. Rate limit client-side + server-side.

**No way to remove / disconnect domain.** Customer changes domains; can't remove the old one. Build remove flow.

**Sending email from the platform's main domain "as the customer".** From: `Acme via YourSaaS <noreply@yoursaas.com>` works as fallback but feels off-brand to customers. Prioritize getting custom domain verified.

**Subdomain advice ignored.** Customer adds records to acme.com directly; primary domain reputation tied to all your sends. Coach them onto a subdomain.

## See Also

- [Email Deliverability](./email-deliverability-chat.md) — broader deliverability for your own domain
- [Email Template Implementation](./email-template-implementation-chat.md)
- [Notification Providers (VibeReference)](https://viberef.dev/backend-and-data/notification-providers.md)
- [Email Providers (VibeReference)](https://viberef.dev/backend-and-data/email-providers.md) — Postmark / Resend / SES / Mailgun / SendGrid
- [Resend (VibeReference)](https://viberef.dev/backend-and-data/resend.md)
- [AWS SES (VibeReference)](https://viberef.dev/backend-and-data/aws-ses.md)
- [DNS (VibeReference)](https://viberef.dev/cloud-and-hosting/dns.md)
- [DNS Providers (VibeReference)](https://viberef.dev/cloud-and-hosting/dns-providers.md)
- [Domain (VibeReference)](https://viberef.dev/cloud-and-hosting/domain.md)
- [Workspace Branding / Custom Domains / White-Label](./workspace-branding-custom-domains-white-label-chat.md) — broader white-label pattern
- [Multi-Tenancy](./multi-tenancy-chat.md)
- [Roles & Permissions](./roles-permissions-chat.md)
- [In-App Status Banners & System Notifications](./in-app-status-banners-system-notifications-chat.md)
- [Settings & Account Pages](./settings-account-pages-chat.md)
- [Workspace Tenant Switcher](./workspace-tenant-switcher-chat.md)
- [Audit Logs](./audit-logs-chat.md)
- [Sandbox & Test Mode for SaaS APIs](./sandbox-test-mode-saas-apis-chat.md)
- [Plan Upgrade, Downgrade & Mid-Cycle Billing Changes](./plan-upgrade-downgrade-billing-changes-chat.md)
- [Outbound Webhooks](./outbound-webhooks-chat.md)
- [Inbound Webhooks](./inbound-webhooks-chat.md)
- [Webhook Signature Verification](./webhook-signature-verification-chat.md)
- [Customer Notes & Internal Annotations](./customer-notes-internal-annotations-chat.md)
- [CSV / Data Export Patterns](./csv-data-export-patterns-chat.md)
- [In-Product Feature Request & Roadmap Voting](./in-product-feature-request-voting-chat.md)
- [Onboarding Checklist & Setup Progress UI](./onboarding-checklist-setup-progress-chat.md)
- [Microcopy & Product Copy Systems](./microcopy-product-copy-systems-chat.md)
- [Email Warmup & Cold Deliverability Tools (VibeReference)](https://viberef.dev/marketing-and-seo/email-warmup-deliverability-tools.md) — adjacent (cold sending vs transactional)
- [Email Marketing Providers (VibeReference)](https://viberef.dev/marketing-and-seo/email-marketing-providers.md)
- [Newsletter Platforms (VibeReference)](https://viberef.dev/marketing-and-seo/newsletter-platforms.md)