Sending email on behalf of customers is a common requirement for SaaS platforms, agencies, marketplaces, CRMs, and white-label products. To do it reliably, you need more than permission to place a customer’s address in the From: field: you need domain authentication, clear tenant boundaries, resilient sending logic, and a process for handling bounces and complaints.

This guide explains how to send email on behalf of customers using any transactional email provider, whether your application delivers through a REST API or an SMTP relay. The same design applies when you send password resets, invoices, appointment notifications, product alerts, support updates, or customer-created campaigns.

Understand what “on behalf of” means in email

There are several identities in a message, and confusing them is the source of many broken implementations. A recipient sees the display name and address in the visible From: header, but receiving systems evaluate other identities as well.

For a typical customer-branded message, the identities may look like this:

From: Acme Billing <billing@acme.example>
Reply-To: Acme Support <support@acme.example>
Return-Path: bounces@bounce.acme.example
DKIM-Signature: d=acme.example; s=mail2026; ...

The visible From: address is the brand identity seen by the recipient. The Reply-To: address tells a mail client where replies should go. The envelope sender, often surfaced later as Return-Path:, is used during SMTP delivery and is normally where delivery status notifications and bounces are directed.

A transactional provider may operate the network, IP addresses, SMTP relay, and message queue, but the customer’s domain should be the identity that authenticates the message. In practice, your platform is an authorized sender for the customer’s domain.

That distinction matters because simply setting From: billing@acme.example does not prove that your platform has permission to use acme.example. Modern mailbox providers evaluate SPF, DKIM, and DMARC to establish whether the domain shown to a recipient is authenticated.

Choose the right multi-tenant sending model

There is no single architecture for customer-domain email. The correct model depends on who owns the brand, who controls DNS, whether recipients expect the customer’s identity, and how much implementation work the customer can reasonably perform.

Model 1: Send from your platform domain

In the simplest model, every message comes from your domain:

From: Acme via Example Platform <notifications@example-platform.com>
Reply-To: support@acme.example

This requires no DNS work from the customer, and it is a practical starting point for early-stage products. However, recipients see your platform’s domain rather than the customer’s. It weakens brand continuity and can create confusion when a user expects messages from acme.example but receives mail from example-platform.com.

Use this model for low-volume operational messages while a customer has not yet verified a domain. Do not present it as equivalent to customer-domain sending.

Model 2: Send from a verified customer domain

This is the preferred model for branded transactional email:

From: Acme Billing <billing@acme.example>
Return-Path: bounces@bounce.acme.example
DKIM-Signature: d=acme.example; s=mail2026; ...

Your customer adds DNS records that authorize your sending service. You then allow their application tenant to use approved addresses or domains. This produces a consistent recipient experience and allows DKIM or SPF to align with the visible From: domain for DMARC.

For most platforms, this should be the default production model.

Model 3: Send from a customer subdomain

A customer may prefer a dedicated mail subdomain, such as:

From: alerts@notify.acme.example
From: receipts@billing.acme.example
From: updates@mailer.acme.example

Subdomains isolate different mail streams and reduce the chance that an operational or marketing program affects the reputation of a primary corporate domain. They also make ownership clearer: notify.acme.example can be reserved for your platform, while acme.example remains available for the customer’s employee mail and other systems.

This is often the best choice when a customer has multiple senders, complex authentication records, or a security team that wants clear separation.

Model 4: Customer-owned SMTP credentials

Some enterprise customers may ask to connect their own SMTP service or email API account. This can be appropriate when they require direct ownership of billing, suppression data, IP reputation, or audit logs.

The trade-off is operational complexity. Your application must store and rotate customer credentials safely, provide per-tenant connection settings, and support differing provider limits and error behavior. It also becomes harder to operate a consistent delivery pipeline.

For most SaaS products, a centrally managed provider with verified customer domains is simpler and safer than accepting arbitrary customer SMTP credentials.

Require domain verification before enabling a customer From address

Never let a tenant claim any arbitrary From: address. Without verification, a malicious user could attempt to impersonate a bank, government agency, competitor, or another customer on your platform.

Your product should treat domain verification as an authorization workflow. A customer proves control of a domain by publishing DNS records, and only then can they send from approved domains or addresses within it.

A sensible verification policy has four rules:

Verify the domain, not just an individual mailbox. Domain authentication is what mailbox providers evaluate, and it scales better than one-off email confirmations.
Require authentication before production sending. Do not allow unrestricted customer-domain sending based only on a user-entered address.
Restrict sending to verified identities. If acme.example is verified, decide explicitly whether that permits every local part, such as anything@acme.example, or only an allowlist such as billing@acme.example and support@acme.example.
Re-check ownership after meaningful changes. If DNS authentication disappears, is replaced, or starts failing, pause new sends from that identity until the issue is reviewed.

A well-designed onboarding screen should explain what the customer needs from their DNS administrator: access to create TXT and CNAME records, the ability to wait for DNS propagation, and a contact who understands which systems already send mail for the domain.

For implementation details on connecting an application to a REST email service or SMTP relay, refer customers and developers to the relevant email API reference and setup guides rather than hard-coding assumptions about a specific transport.

Configure SPF without breaking the customer’s existing senders

SPF, or Sender Policy Framework, is a DNS-based authorization record. It tells a receiving server which hosts are permitted to send mail for an envelope sender domain.

An SPF record is published as a TXT record. A simple example is:

acme.example. IN TXT "v=spf1 include:spf.email-provider.example -all"

This example says that the domain uses SPF version 1, authorizes the hosts identified by spf.email-provider.example, and treats all other senders as unauthorized.

SPF record examples

A customer that sends through both Google Workspace and a transactional provider might publish one combined record:

acme.example. IN TXT "v=spf1 include:_spf.google.com include:spf.email-provider.example -all"

A customer using a dedicated sending IP range might use an ip4 mechanism:

acme.example. IN TXT "v=spf1 ip4:192.0.2.0/24 include:spf.email-provider.example -all"

For a dedicated envelope sender subdomain, the record may belong on that subdomain instead:

bounce.acme.example. IN TXT "v=spf1 include:spf.email-provider.example -all"

The exact include domain comes from the sending provider. Do not guess it, alter it, or replace it with an example value in a production DNS zone.

The one-SPF-record rule

A domain must not publish multiple SPF TXT records beginning with v=spf1. If a customer already has an SPF record, they need to merge the new authorization into the existing record rather than add a second record.

This is a frequent multi-tenant onboarding failure. A customer may copy your provider’s SPF value into a new TXT record while retaining an existing Microsoft 365, Google Workspace, CRM, helpdesk, or ecommerce SPF record. Receivers can return an SPF PermError, making the result unreliable or invalid.

Your setup instructions should say this plainly: add the provider mechanism to the existing SPF record; do not create another v=spf1 record.

SPF lookup limits and why subdomains help

SPF evaluation has a limit of 10 DNS-querying terms. Mechanisms such as include, a, mx, exists, and redirect can consume that budget. Large organizations that authorize numerous vendors can exceed the limit through nested includes, even when the visible record looks short.

This is one reason customer-specific mail subdomains are useful. Instead of constantly editing the root domain’s overloaded SPF record, a customer can dedicate bounce.acme.example or mail.acme.example to a single sending service. It reduces coupling with employee mail and other vendors.

SPF is valuable, but it is not enough on its own. Forwarding can cause SPF to fail because the forwarding server’s IP address is not authorized by the original envelope sender’s policy. That is why DKIM alignment is usually the more durable authentication path for customer-branded messages.

Configure DKIM for customer-controlled authentication

DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to each message. The sending system signs the message with a private key, while recipients retrieve the corresponding public key from DNS.

A receiver uses the signature’s domain (d=) and selector (s=) to find the public key at this DNS name:

<selector>._domainkey.<signing-domain>

For example, if the message has:

DKIM-Signature: v=1; a=rsa-sha256; d=acme.example; s=mail2026; ...

the receiver looks up:

mail2026._domainkey.acme.example

A DKIM public key commonly appears as a TXT record:

mail2026._domainkey.acme.example. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Some providers instead ask customers to publish a CNAME record that delegates a selector to provider-managed DNS:

mail2026._domainkey.acme.example. IN CNAME mail2026.customer-id.provider-dkim.example.

Both approaches are valid when supplied by the provider. A TXT record exposes the public key directly. A CNAME delegation lets the provider manage the key and rotate it without requiring the customer to modify DNS each time.

DKIM choices that matter

When you operate a platform for many customers, require or strongly encourage these DKIM properties:

Sign with the customer’s domain or an aligned subdomain. A signature with d=acme.example aligns naturally with From: billing@acme.example. A signature from only your platform domain may pass DKIM but fail DMARC alignment for the customer’s visible identity.
Use unique selectors or delegated records per customer. This prevents accidental overlap and supports clean key rotation.
Rotate keys deliberately. Publish a new selector, start signing with it, verify results, and only later retire the old selector. Do not delete an active selector before messages signed with it have aged out of mail systems and archives.
Avoid modifying signed content after signing. Changing signed headers or body content can invalidate DKIM. Apply tracking, templates, and message transformations before the final signing step whenever possible.

DKIM is particularly important for transactional email because it remains useful when messages are forwarded. It also gives you a stable domain identity that can be aligned with DMARC even if the envelope sender is on a dedicated bounce subdomain.

Make DMARC alignment the design target

DMARC connects the visible From: domain to SPF and DKIM results. Under DMARC, it is not enough for some unrelated domain to pass SPF or DKIM. At least one passing result must align with the domain in the visible From: address.

For example, this is generally aligned:

From: receipts@acme.example
DKIM d=acme.example

This can also align under relaxed alignment rules:

From: receipts@acme.example
DKIM d=mailer.acme.example

By contrast, this may pass DKIM but not provide DMARC alignment for Acme:

From: receipts@acme.example
DKIM d=example-platform.com

The practical objective is simple: sign customer messages with a DKIM domain that matches, or is an aligned subdomain of, the domain in the visible From: address.

DMARC DNS syntax

A DMARC policy is published at _dmarc.<domain> as a TXT record. A monitoring-first policy might look like this:

_dmarc.acme.example. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@acme.example; adkim=r; aspf=r; pct=100"

The tags mean:

v=DMARC1 identifies the record as DMARC.
p=none asks receivers to monitor rather than quarantine or reject failing messages.
rua=mailto:... requests aggregate reports.
adkim=r uses relaxed DKIM alignment.
aspf=r uses relaxed SPF alignment.
pct=100 applies the policy to all applicable messages.

After a customer has reviewed legitimate sources in aggregate reports, they may choose a stronger enforcement policy:

_dmarc.acme.example. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@acme.example; adkim=r; aspf=r; pct=100"

Or, when confident that all legitimate senders are authenticated:

_dmarc.acme.example. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@acme.example; adkim=r; aspf=r; pct=100"

Do not tell customers to publish p=reject immediately without auditing their legitimate mail sources. They may have forgotten systems that send invoices, recruiting email, helpdesk notifications, scanners, or employee mail. DMARC enforcement is powerful precisely because it can block unauthorized use of a domain.

Major mailbox providers expect authenticated mail. Gmail’s sender guidelines require SPF or DKIM for all senders, while higher-volume senders have additional SPF, DKIM, and DMARC requirements. Yahoo likewise urges SPF, DKIM, and DMARC authentication. These policies make authenticated customer-domain sending operationally important, not merely a branding enhancement.

Separate the visible From domain from bounce processing

Many teams try to use one address for every email function. That makes troubleshooting and DNS management harder. It is usually better to separate recipient-facing branding from automated bounce processing.

A robust pattern is:

Visible From:  billing@acme.example
Reply-To:      support@acme.example
Envelope From: bounce+tenant_42+msg_abc@bounce.acme.example
DKIM domain:   acme.example

The variable local part on the bounce address lets your system correlate a delivery status notification with an individual message and tenant. Never place unprotected personal data, raw recipient addresses, or predictable account identifiers in that local part. Use a signed token, opaque message ID, or database reference instead.

A customer might need to publish DNS for a custom return-path or bounce domain. Depending on the provider, that can include an SPF TXT record, a CNAME delegation, an MX record for receiving bounces, or some combination. Use the exact values generated by the provider because the required hostnames vary.

Do not invent a generic MX target in customer instructions. An incorrect MX record can send bounces to the wrong server or prevent the provider from processing them entirely.

Build tenant isolation into the sending pipeline

Customer-domain authentication proves domain control, but it does not protect customers from each other inside your application. Multi-tenant email needs authorization controls at the API, database, queue, and operational levels.

Store identity ownership explicitly

Model sending identities as first-class records, not free-text fields passed directly from a browser to an email API. At minimum, store:

tenant_id
sending_domain
allowed_from_addresses or local-part policy
verification_status
dkim_status
spf_status
dmarc_status
provider_identity_id
created_at
last_verified_at
suspension_reason

When an application requests an email send, look up the sending identity by tenant ID and verify that the requested From: address belongs to that tenant’s verified domain. Do not trust a tenant-supplied from field without server-side validation.

A basic authorization decision can be expressed as:

allow send only when:
- identity.tenant_id == authenticated_request.tenant_id
- identity.verification_status == verified
- requested From domain is identity.sending_domain or an approved subdomain
- requested local part matches policy
- identity is not suspended

Use separate credentials and metadata

If your provider supports multiple API keys or SMTP credentials, use scopes and credentials appropriate to your architecture. A backend service credential should never be exposed in browser code, customer-facing scripts, mobile apps, or public repositories.

Attach a tenant identifier and your own immutable message ID as provider metadata when the provider supports it. That makes delivery events, bounces, support investigations, and billing reconciliation traceable without parsing the email body.

Avoid putting private customer data in tags or metadata that might appear in logs, webhook payloads, analytics systems, or support exports.

Enforce limits per tenant

One compromised tenant should not consume your entire sending capacity or damage the reputation of all customers. Apply rate limits, volume thresholds, and anomaly detection per tenant and per sending domain.

Useful guardrails include:

maximum messages per minute and per day;
maximum recipient count per API request;
review thresholds for a sudden volume increase;
limits on new domains before they establish a sending history;
separate rules for transactional and promotional content;
automatic pauses after high hard-bounce or complaint rates.

These controls are not only anti-abuse measures. They protect accidental loops, such as a bug that sends a password-reset email every time a user loads a page.

Send through an API or SMTP relay without losing control

Most transactional providers offer both a REST API and an SMTP relay. The best transport is the one your application can use safely and observably.

REST API pattern

An email API commonly accepts a JSON payload containing a sender, recipients, subject, HTML and text content, reply address, headers, attachments, tags, and metadata. The provider may return 202 Accepted when it has accepted the message for asynchronous processing, but that means queue acceptance, not inbox placement or final recipient delivery.

Your application should record the provider’s message identifier and your own idempotency key. If a network timeout occurs after you submit a request, an idempotency key lets you retry without creating duplicate receipts, alerts, or account messages.

Use an explicit template version or content hash for important transactional emails. If a customer disputes a message, you should be able to identify exactly which template and variables were used.

SMTP relay pattern

SMTP is useful for systems that already know how to send mail, such as legacy applications, monitoring software, ecommerce tools, and server-side frameworks. A typical authenticated submission flow uses EHLO, TLS, SMTP authentication, MAIL FROM, RCPT TO, and DATA.

The relay may respond with 250 after accepting a message. As with an API 202, a 250 at submission time usually means the relay accepted responsibility for the next stage; it is not proof that the recipient mailbox accepted the message.

Protect SMTP credentials as carefully as API tokens. Prefer authenticated submission with TLS, use provider-recommended ports and encryption modes, and never run a public unauthenticated relay.

HTTP and SMTP status handling

A durable sending service distinguishes temporary failure from permanent failure.

At the HTTP layer, retrying may be appropriate for timeouts, 429 Too Many Requests, and many 5xx server errors. Do not blindly retry malformed requests or authorization failures such as 400 Bad Request, 401 Unauthorized, or 403 Forbidden.

At the SMTP layer, the first digit is important:

2xx indicates success at that SMTP stage. 250 is a common success response.
4xx indicates a temporary failure. 421, 450, 451, and 452 commonly warrant a bounded retry strategy.
5xx indicates a permanent failure. 550, 551, 552, 553, and 554 usually require suppression, correction, or manual review rather than repeated attempts.

Enhanced status codes provide more context. For example, 5.1.1 commonly identifies an invalid recipient address, while 4.2.2 often signals a temporary mailbox-capacity issue. The descriptive text is not standardized enough to parse as a sole source of truth, so store both the numeric code and the full provider response.

Use exponential backoff with jitter for temporary failures, and set a retry deadline. Retrying a deferred message forever creates stale notifications and unnecessary volume.

Handle bounces, complaints, and suppressions at the tenant level

A successful submission is only the beginning of the delivery lifecycle. Your application needs a way to receive events for delivered, deferred, bounced, complained, and suppressed messages.

Providers usually offer webhooks, event streams, or logs. Verify webhook signatures, enforce HTTPS, protect endpoints from replay where possible, and make event handling idempotent. Providers can deliver duplicate events, and your own queue may retry processing after a timeout.

Classify bounces carefully

A hard bounce generally represents a permanent problem: a nonexistent mailbox, invalid domain, or recipient address that should not be retried. A soft bounce is temporary: mailbox full, recipient server unavailable, transient policy restriction, or rate limiting.

Do not rely exclusively on the words “hard” and “soft,” because classifications vary by provider and recipient system. Base suppression decisions on the actual status code, provider event category, repeated history, and the reason text.

For example:

Suppress immediately for a clear invalid-recipient event such as 5.1.1.
Retry a temporary response such as 4.2.2 according to your normal delivery policy.
Escalate repeated deferrals from the same recipient domain for deliverability review.
Pause a tenant when complaint or invalid-recipient rates indicate poor data quality or abusive use.

Suppressions should be scoped thoughtfully. A global suppression for a recipient can prevent accidental mail from any tenant, but it may be inappropriate if a recipient legitimately expects messages from different independent organizations. Tenant-level suppression is often safer for a true multi-tenant platform, while global blocklists should be reserved for clear abuse, legal restrictions, or explicit recipient requests.

Process complaints and unsubscribe requests

Transactional and marketing mail have different expectations, but recipients should always have a clear way to stop unwanted non-essential messages. Do not hide promotional content inside a message labeled as a receipt or security alert.

For marketing or bulk messages, follow applicable laws and mailbox-provider expectations for consent, identification, and unsubscribe handling. Your system should capture the scope of the unsubscribe: a particular list, a customer tenant, a message category, or all non-transactional mail.

A customer should not be able to override a recipient’s unsubscribe preference through a template change or a new sender alias.

Test authentication and deliverability before scaling

DNS records can be syntactically correct and still fail in practice because of propagation delays, incorrect hostnames, duplicate SPF records, wrong DKIM selectors, or misaligned identities. Test every customer-domain configuration with real messages.

A practical pre-launch checklist

Confirm that DNS records resolve publicly using dig, nslookup, MXToolbox, or another DNS inspection tool.
Send a message to Gmail, Outlook.com, Yahoo Mail, and a controlled corporate mailbox if possible.
Inspect the received message headers for SPF, DKIM, and DMARC results.
Verify that the DKIM d= domain aligns with the visible From: domain.
Confirm that the Reply-To: address receives replies and the envelope sender can process bounces.
Send to a test inbox at mail-tester.com and review authentication, content, and structural findings.
Trigger a controlled invalid-recipient case to ensure bounces enter the correct tenant workflow.
Confirm that webhook signatures, retries, duplicate-event handling, and suppression updates work.

The most useful evidence is the receiver’s authentication result. In raw message headers, look for an Authentication-Results: field similar to:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounce.acme.example;
  dkim=pass header.d=acme.example;
  dmarc=pass header.from=acme.example

A common surprise is an email where SPF passes and DKIM passes but DMARC fails. This nearly always means neither passing identifier aligns with the visible From: domain. Inspect smtp.mailfrom=, header.d=, and header.from= together rather than treating authentication as three unrelated checkboxes.

Monitor reputation and investigate problems by domain

Multi-tenant email operations improve when you can answer three questions quickly: which tenant sent the message, which authenticated domain was used, and what happened after submission.

Build reporting around sending domain and tenant, not only around your overall account. Track acceptance, delivery, deferral, hard-bounce, complaint, suppression, and unsubscribe metrics by tenant and domain.

A sudden change can mean several different things:

A customer imported an old or invalid recipient list.
A product change accidentally increased email frequency.
DNS authentication was removed or modified.
A tenant’s account was compromised.
A receiving domain has temporarily throttled your traffic.
Content, links, or attachment behavior triggered filtering.

Do not diagnose deliverability from an open rate alone. Privacy protections, image blocking, and client behavior make opens an incomplete signal. Authentication outcomes, bounce categories, complaints, delivery events, and recipient-domain deferrals are more operationally useful.

For high-volume sending to Gmail, Google Postmaster Tools can provide domain and reputation signals when available. Provider dashboards and event exports are also useful, but retain your own normalized event history so you can investigate across provider changes or account migrations.

Common implementation mistakes to avoid

The technical work is usually straightforward; the failures are often architectural or procedural.

Letting customers spoof unverified domains

Never accept an arbitrary From: domain merely because a tenant typed it into a form or API call. This creates abuse risk and poor deliverability.

Adding a second SPF record

Customers often create a second v=spf1 TXT record instead of merging mechanisms. This can produce SPF errors and breaks existing mail flows.

Signing only with the platform domain

A provider-domain DKIM signature can be valid but still fail DMARC alignment for a customer-branded From: address. Use an aligned customer domain or subdomain for DKIM.

Treating acceptance as delivery

An SMTP 250 or API 202 means the provider accepted the request or message for processing. It does not mean the recipient received it in the inbox.

Sharing one unbounded sending pool

Without per-tenant limits and monitoring, one bad actor or broken integration can create a platform-wide reputation incident.

Retrying permanent bounces

Repeatedly sending to invalid mailboxes wastes capacity and can harm reputation. Suppress known permanent failures promptly.

Mixing transactional and promotional mail

Password resets, receipts, account security notices, newsletters, and sales outreach have different recipient expectations. Separate their templates, triggers, consent models, and preferably their sending subdomains.

Conclusion: make customer-domain sending an authorization system

To send email on behalf of customers safely, treat the feature as more than a From: field. It is an authorization and deliverability system that connects DNS ownership, sender identity, tenant access control, bounce processing, monitoring, and recipient trust.

Start with verified customer domains or dedicated customer subdomains. Require SPF and DKIM, design for DMARC alignment, and use an envelope sender that supports safe bounce correlation. Then add tenant-scoped credentials, limits, event handling, and a disciplined test process before expanding volume.

The result is a system where customers receive branded delivery, recipients see a coherent identity, and your platform can prove who sent what, from which authorized domain, and how the message performed.

FAQ

Can I use my customer’s From address without changing their DNS?

You can technically place a customer address in the visible From: header, but you should not use it for production customer-branded sending without domain verification and authentication. Mailbox providers may flag, quarantine, or reject unauthenticated mail, and your platform would enable impersonation risk.

Do customers need SPF, DKIM, and DMARC?

DKIM and SPF are both recommended, while DMARC is the alignment and policy layer that connects authentication to the visible From: domain. DKIM is especially important because it can remain valid when a message is forwarded. For meaningful customer-domain sending, configure all three.

Is a subdomain better than the customer’s root domain?

Often, yes. A subdomain such as notify.customer.example separates your platform’s mail from employee mail and other vendors, simplifies SPF management, and limits the operational blast radius. The root domain can still be appropriate when the customer wants the most direct brand identity and can manage the DNS safely.

What does an SMTP 250 response mean?

It usually means the SMTP server accepted the message at that stage of the transaction. It does not guarantee inbox placement or final delivery to the recipient mailbox. Use delivery events and bounce events to understand the final outcome.

Should each customer have separate API keys or SMTP credentials?

Use the level of separation your architecture supports, but always enforce authorization server-side. Per-tenant credentials or scoped identities can improve containment and auditing; a central backend credential can also work when every send is validated against a tenant-owned, verified sending identity.

How to Send Email on Behalf of Your Customers Safely