KoltrixSending email on behalf of your customers' domains
SaaS platforms that send as their customers need domain verification, per-tenant DKIM and isolated reputation. The architecture and the onboarding flow.
On this page(9 sections)
- The three options for the From address
- Option 1: send from your own domain
- Option 2: send from the customer's domain without authentication
- Option 3: send from the customer's domain, fully authenticated
- Step 1: verify domain ownership
- Step 2: per-tenant DKIM keys
- Step 3: handle SPF and the envelope sender
- Step 4: isolate reputation
- Step 5: build the onboarding flow
- Step 6: keep checking
- Checklist
- Key takeaways
If your SaaS product sends email that appears to come from your customers, such as invoices from their billing address, support replies from their help desk, or notifications from their brand, you are operating a multi-tenant email platform whether you planned to or not. Doing it well means verifying domain ownership, signing with each customer's own DKIM key, and keeping one customer's reputation problems away from everyone else.
The three options for the From address
Option 1: send from your own domain
The simplest approach: messages come from [email protected], perhaps with the customer's name as the display name.
From: Acme Support via YourProduct <[email protected]>
Reply-To: [email protected]It requires no setup from customers and authentication is entirely under your control. The downside is branding, and recipients may not recognize the sender. For many products, this is the right default for new and trial accounts.
Option 2: send from the customer's domain without authentication
Putting [email protected] in the From header while sending from your infrastructure, without the customer's SPF or DKIM, used to sort of work. Today it fails DMARC for any customer with an enforced policy, and Gmail and Yahoo require authentication for bulk senders. Do not build on this.
Option 3: send from the customer's domain, fully authenticated
The customer proves they own the domain, publishes DNS records you provide, and you sign their mail with a DKIM key aligned to their domain. This is what customers expect from a serious product, and it is what the rest of this article covers.
Step 1: verify domain ownership
Before you send a single message as acme.example, confirm that the person who added it controls it. Otherwise any user could configure your product to send as any domain.
The standard method is a DNS challenge:
_yourproduct-verification.acme.example. TXT "yp-verify=4f9c1e7a2b..."Generate a random token per domain and tenant, ask the customer to publish it, and check for it periodically. Only mark the domain verified when the exact token is found. Re-verify occasionally; domains change hands.
Step 2: per-tenant DKIM keys
Generate a separate DKIM key pair for each customer domain. Do not share one key across tenants: a single compromised or replayed key would then affect every customer, and you could not revoke it for one without breaking all.
There are two common ways to publish the public key:
CNAME delegation (recommended):
yp1._domainkey.acme.example. CNAME yp1.acme-example.dkim.yourproduct.example.The customer publishes a CNAME once, and you host the actual key record in your own DNS. You can rotate keys without asking the customer to change anything. Many platforms ask for two CNAMEs so they can alternate during rotation.
Direct TXT: the customer publishes the key itself. It works, but every rotation requires customer action, which in practice means keys never get rotated.
Use 2048-bit RSA keys. Store private keys in a secrets manager or a key management service, scoped per tenant, and never expose them through your application's admin interfaces.
Step 3: handle SPF and the envelope sender
SPF is checked against the envelope sender (Return-Path), not the From header. You have two choices:
- Use a bounce subdomain on the customer's domain, such as
bounces.acme.example, with an SPF record and MX pointing to your infrastructure. This gives an aligned SPF pass and routes bounces back to you. It requires more DNS records from the customer. - Use your own bounce domain, such as
bounces.yourproduct.example. SPF passes for your domain but does not align with the customer's domain. DMARC then relies entirely on aligned DKIM, which is fine as long as DKIM is solid.
Many platforms start with the second option for simplicity and offer the first as an advanced setting. Avoid asking customers to add your include: to their root SPF record unless you truly need it; they may already be near the ten-lookup limit.
Step 4: isolate reputation
In a multi-tenant system, one customer with a bad list can damage delivery for everyone sharing the same infrastructure. Mitigations:
- Per-tenant DKIM domains already help, since much of modern reputation attaches to the signing and From domains.
- Separate IP pools for different risk tiers: new accounts, established accounts, and high-volume accounts on dedicated IPs.
- Per-tenant sending limits that start low for new accounts and grow with good behavior.
- Per-tenant suppression lists and metrics: bounce and complaint rates tracked per customer, with automatic throttling or suspension when they exceed thresholds.
- Acceptable use policies that are actually enforced.
Step 5: build the onboarding flow
Most customers adding a domain are not email experts. A good flow:
- Customer enters their domain.
- You display the exact records to add, with copy buttons, and explain each in one sentence.
- You check DNS automatically every few minutes and show per-record status: found, missing, or incorrect.
- When the verification and DKIM records pass, you enable sending from that domain.
- You recommend, but do not require, a DMARC record if they have none, and explain that a missing or
p=nonepolicy is acceptable to start.
Show clear errors for common mistakes: a CNAME entered as TXT, the domain name appended twice by a DNS provider that auto-appends the zone, or a record added to the wrong domain.
Step 6: keep checking
DNS can change at any time. Customers migrate DNS providers and lose records, or remove them by accident. Re-check records on a schedule, and when a DKIM record disappears, alert the customer and fall back to sending from your own domain rather than sending unauthenticated mail that will fail DMARC.
Checklist
- Default new tenants to your own domain with a customer display name and Reply-To.
- Verify domain ownership with a per-tenant DNS token.
- Generate a separate DKIM key per customer domain, published via CNAME delegation.
- Choose an envelope strategy: customer bounce subdomain or your own bounce domain with aligned DKIM.
- Isolate reputation with per-tenant limits, metrics, suppression and IP pools.
- Build a guided onboarding flow with automatic DNS checks.
- Re-check DNS continuously and fall back safely when records disappear.
Key takeaways
- Sending as customers' domains requires verified ownership and per-tenant DKIM, not just a From header.
- CNAME-delegated DKIM keys let you rotate keys without customer involvement.
- Aligned DKIM alone is enough for DMARC; a customer bounce subdomain adds aligned SPF.
- Per-tenant limits and metrics stop one customer from harming everyone else.
- Keep monitoring DNS after onboarding, and fall back safely when records break.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
