How to Send Email From Your Customer's Domain
Short answer: To send email from your customer's domain, your SaaS platform needs to (1) verify the customer's domain via DNS (SPF, DKIM, DMARC), (2) isolate sending reputation per tenant, and (3) route email through an API that supports delegated sending.
This is the guide we wish existed when we started building Ark. It covers the full architecture for sending email on behalf of customers: from DNS records to reputation isolation to production monitoring. Written for engineering teams at multi-tenant SaaS platforms.
Why SaaS Platforms Send From Customer Domains
When your platform sends email on behalf of a customer, the recipient sees the “from” address. If that address is [email protected], the recipient has no idea who the email is actually from. If it's [email protected] (the customer's own domain) the email is immediately recognizable.
This matters for four reasons:
Brand perception.
Your customers' customers expect email from a domain they recognize. A helpdesk reply from [email protected] looks professional. A reply from [email protected] looks like the business is using a cheap tool.
Deliverability.
Inbox providers like Gmail, Outlook, and Yahoo use domain reputation as a primary spam filtering signal. When your customer sends from their own authenticated domain, they build their own sender reputation. That's better for long-term deliverability than inheriting reputation from a shared platform domain.
Compliance.
Healthcare, finance, and legal companies often require that outbound email comes from the organization's own domain. If your platform serves these verticals, sending from your domain may not be an option.
Open rates.
Recipients check the “from” domain before opening. A recognized domain gets opened. An unfamiliar one gets ignored or flagged.
The question isn't whether to send email from customer domains. It's how to do it correctly across hundreds of them without drowning in DNS support tickets.
At Ark, the majority of our platform customers are sending from their customer's domains within the first week. The setup below is the pattern we see work in production.
Three Approaches to Sending on Behalf of Customers
Before you start configuring DNS records, it's worth understanding the three options. The right approach depends on your customers and how much setup you can ask of them.
| Approach | Setup | Deliverability | Brand | Isolation |
|---|---|---|---|---|
| Shared platform domain | Low | Medium | Poor | None |
| Customer subdomain | Medium | Good | Good | Partial |
| Full customer domain | Higher | Best | Best | Full |
Shared platform domain
All email goes out from [email protected]. The customer's name might appear in the display name (“Acme Corp via YourPlatform”), but the actual sending domain is yours.
This is the easiest option since there are no DNS changes per customer. It's also the worst for deliverability and brand. One bad tenant tanks the shared domain's reputation for everyone. Use it as a fallback while a customer is setting up their domain, not as a permanent solution.
Customer subdomain
Email goes out from [email protected]. The customer adds DNS records for a subdomain rather than their root domain. This is a good middle ground: the email is clearly branded, the subdomain builds its own reputation, and misconfiguration is lower-risk because it doesn't affect the customer's existing email setup.
Full customer domain
Email goes out from [email protected]. This requires DNS records on the customer's root domain, which means coordinating with whatever email system they already have (Google Workspace, Microsoft 365, etc.). More work to set up, but produces the best result.
The right choice depends on your customers. Technical customers (developers, IT teams) can handle full domain setup. Non-technical small businesses do better with subdomains. Most platforms support both and let the customer choose.
DNS Setup: SPF, DKIM, and DMARC
Once you've chosen an approach, the customer needs to add three DNS records. These tell inbox providers that your platform is authorized to send email from their domain. Get these wrong, and email goes to spam or doesn't deliver at all.
SPF: Authorizing Your Platform to Send
SPF (Sender Policy Framework) is a DNS TXT record that lists which servers are allowed to send email for a domain. Your customer adds your platform's sending infrastructure to their SPF record:
v=spf1 include:spf.youremailprovider.com ~allIf the customer already has an SPF record (common with Google Workspace or Microsoft 365), they append your include: to the existing record:
v=spf1 include:_spf.google.com include:spf.youremailprovider.com ~allinclude: counts as one (and can chain to more). If a customer already has 8 lookups and you add 3, the entire SPF record fails silently.DKIM: Cryptographically Signing Email
DKIM lets your platform sign outgoing email with a private key. The corresponding public key is published as a DNS record on the customer's domain. Inbox providers verify the signature to confirm the email wasn't tampered with in transit.
selector._domainkey.acmecorp.com CNAME selector.dkim.youremailprovider.comUse CNAME instead of TXT for DKIM in multi-tenant setups. A CNAME record points to your platform's DKIM key, so you can rotate keys without asking the customer to update their DNS. With a TXT record, every key rotation requires a customer DNS change. At scale, that's hundreds of coordinated updates you don't want to manage.
DMARC: Setting the Policy
DMARC ties SPF and DKIM together. It tells inbox providers what to do when authentication fails:
v=DMARC1; p=none; rua=mailto:[email protected]The p= value is the policy: none (monitor only), quarantine (send failures to spam), or reject (block entirely).
Start customers on p=none. This lets you collect DMARC reports and catch issues before enforcing a strict policy. Setting reject on a domain that isn't fully configured will block legitimate email.
The Order of Operations
SPF first. Authorize your sending infrastructure. This is the most basic check and the one most likely to cause delivery failures if missing.
DKIM second. Add the signing key. This provides cryptographic proof of authenticity and is increasingly required by major inbox providers.
DMARC last. Set the policy to none initially, then tighten it once SPF and DKIM pass consistently.
To verify records have propagated:
# Check SPF
dig +short TXT acmecorp.com | grep spf
# Check DKIM
dig +short CNAME selector._domainkey.acmecorp.com
# Check DMARC
dig +short TXT _dmarc.acmecorp.comReputation Isolation
DNS authentication gets email from a customer domain into the inbox. Reputation isolation keeps it there.
Here's the problem: when multiple tenants send through the same infrastructure, one tenant's behavior affects everyone else. Tenant A sends a spam campaign, gets a flood of complaints, and the sending IP's reputation drops. Now Tenant B's perfectly legitimate transactional email starts hitting spam folders.
This is the single hardest problem in multi-tenant email. It's also the one that most guides skip entirely. At Ark, roughly 40% of our engineering effort goes into reputation isolation and monitoring. It's that important.
Three layers of isolation
IP-level isolation.
Each tenant (or cohort of tenants) gets a dedicated IP address. Since IP reputation is a primary signal for inbox providers, this gives you the strongest isolation. The tradeoff: dedicated IPs need warming, and low-volume tenants may never send enough to keep an IP warm.
Envelope sender separation.
Even on shared IPs, you can use unique return-path domains per tenant. This lets inbox providers track reputation per tenant's sending identity, even when the IP is shared.
Domain reputation.
When each tenant sends from their own authenticated sending domain, that domain builds its own reputation over time. This is the strongest long-term signal.
In practice, the best approach layers all three: domain-level authentication as the foundation, envelope sender separation for additional signal, and dedicated IPs for high-volume tenants.
What to monitor per tenant
- Bounce rate. Hard bounces above 2% indicate list quality issues. Soft bounces above 5% suggest infrastructure problems.
- Spam complaint rate. Above 0.1% is a warning. Above 0.3% triggers throttling at most inbox providers.
- Blocklist presence. Check major blocklists (Spamhaus, Barracuda, SORBS) per sending IP and domain.
API Implementation
Now for the code. The flow for sending email from a customer domain is: create a tenant, add their domain, wait for DNS verification, then send.
Creating a tenant and adding a domain
import Ark from 'ark-email';
const ark = new Ark({ apiKey: process.env.ARK_API_KEY });
// 1. Create a tenant for your customer
const tenant = await ark.tenants.create({
name: 'Acme Corp',
metadata: { plan: 'enterprise', customer_id: 'cust_123' },
});
// 2. Add their sending domain
const domain = await ark.domains.create({
name: 'acmecorp.com',
tenantId: tenant.data.id,
});
// 3. Get the DNS records your customer needs to add
const { spf, dkim, returnPath } = domain.data.dnsRecords;
console.log(`SPF: ${spf.type} ${spf.name} -> ${spf.value}`);
console.log(`DKIM: ${dkim.type} ${dkim.name} -> ${dkim.value}`);
console.log(`Return Path: ${returnPath.type} ${returnPath.name} -> ${returnPath.value}`);Verifying the domain
const result = await ark.domains.verify(domain.data.id);
if (result.data.verified) {
console.log('Domain verified — ready to send');
} else {
const { spf, dkim, returnPath } = result.data.dnsRecords;
console.log(`SPF: ${spf.status}`);
console.log(`DKIM: ${dkim.status}`);
console.log(`Return Path: ${returnPath.status}`);
}Sending email from the customer's domain
const email = await ark.emails.send({
from: '[email protected]', // Customer's verified domain
to: ['[email protected]'],
subject: 'Your order has shipped',
html: '<h1>Order #1234 shipped</h1><p>Tracking: XYZ123</p>',
tag: 'order-shipped',
metadata: { order_id: '1234' },
trackOpens: true,
trackClicks: true,
});
console.log(`Email ID: ${email.data.id}`);
console.log(`Status: ${email.data.status}`);The same flow in Python:
from ark import Ark
import os
client = Ark(api_key=os.environ.get("ARK_API_KEY"))
email = client.emails.send(
from_="[email protected]",
to=["[email protected]"],
subject="Your order has shipped",
html="<h1>Order #1234 shipped</h1><p>Tracking: XYZ123</p>",
tag="order-shipped",
metadata={"order_id": "1234"},
track_opens=True,
track_clicks=True,
)Domain Onboarding at Scale
Setting up one customer domain is straightforward. Setting up your 500th is where things break down.
In production, a multi-tenant platform onboards domains continuously. Some customers set up DNS the same day. Some take weeks. Some configure SPF but forget DKIM. Some abandon the process entirely. Your system needs to handle all of these states.
The onboarding flow
Customer enters their domain through your product's UI.
Your platform generates DNS records by calling your email provider's API to create the domain and get the required SPF, DKIM, and return-path records.
Customer adds records to their DNS ideally with provider-specific instructions. A Cloudflare user needs different guidance than a GoDaddy user.
Automated verification polling checks DNS records at intervals (every 5 minutes for the first hour, then hourly). Don't rely on the customer telling you they're done.
Partial verification handling because SPF might verify before DKIM. Show per-record status so the customer knows exactly what's left.
Completion notification via webhook to your app when all records verify. The domain goes active automatically.
Handling partial DNS states
Domains sit in partial states more often than you'd expect:
- SPF verified, DKIM pending — common when customers add TXT records but miss the CNAME.
- DKIM verified, SPF missing — less common but it happens. DKIM alone provides authentication, but most inbox providers want both.
- All records added, propagation pending — usually completes within an hour, but can take up to 48.
- Records were valid, then broke — DNS records get accidentally deleted or overwritten. Continuous monitoring catches this.
Ark's guided domain onboarding handles these states automatically: DNS provider detection, per-record verification status, and webhook notifications when domains go live or break.
Monitoring and Deliverability
Domains are verified. Email is flowing. Now the work shifts to keeping it healthy. Multi-tenant email requires per-tenant visibility because aggregate metrics hide the problem. One tenant with a 5% complaint rate looks fine in an aggregate 0.2% average.
Set up four tiers of automated response:
Auto-throttle
When bounce or complaint rate exceeds safe thresholds, slow sending for that tenant until resolved.
Auto-pause
Hard bounce rate above 10% or complaint rate above 0.5%. Stop sending for that tenant entirely.
Alert your team
Blocklist detection, domain authentication failure, sustained elevated complaints across any tenant.
Alert the customer
Their DNS records broke, bounce rate is trending up, or they're approaching sending limits.
Ark's white label analytics give you per-tenant delivery metrics out of the box, and usage metering tracks send volume per tenant for your billing system.
Build vs. Buy
Everything above is buildable from scratch. Using a base provider like Amazon SES or Mailgun as the sending layer, you'd need to build: tenant management, domain onboarding, reputation isolation, per-tenant analytics, and ongoing monitoring. For a team of 2 to 5 engineers, that's typically 4 to 8 weeks of focused development for an MVP, plus ongoing maintenance.
When to build
- Fewer than 5 tenants with simple requirements
- Email is your core product (not a feature of it)
- Dedicated infra engineers with email expertise
- Need deep customization no provider supports
When to use a purpose-built solution
- Managing more than a handful of customer domains
- Engineering time is better spent on your core product
- Need reputation isolation without building monitoring infra
- Want domain onboarding to work out of the box
If you build, you can start with SES configuration sets (cheapest, most work) or adapt a single-sender provider like Postmark or Resend (moderate work, some multi-tenant limitations). Or you can use a platform purpose-built for white label email sending like Ark, where the tenant hierarchy, domain onboarding, and reputation isolation are handled for you.