A SaaS platform can send an email that appears to come from a customer's domain without owning that domain. That sounds contradictory until the different jobs in the mail path are separated.
The customer owns the visible sending identity and the DNS zone. The SaaS provider may operate the application, the signing service, and the outbound mail infrastructure. A receiver evaluates the message using all of those signals, but none of them transfer domain ownership by themselves.
That distinction is the key to designing multi-tenant email correctly. The question is not simply "does the platform send mail for the customer?" It is which party can authorize, sign, transport, observe, and stop that mail?
Consider a message with these identities:
From: Acme Billing <billing@example.com>
MAIL FROM: bounces@notify.example.com
DKIM-Signature: ...; d=example.com; s=saas2026;These fields do not have one owner by default.
| Control point | What it controls | Typical owner |
|---|---|---|
Visible From: domain | The identity shown to the recipient and checked by DMARC | Customer/domain owner |
MAIL FROM domain | Bounce routing and the SPF identity | Customer, SaaS provider, or both |
| DKIM signing domain and key | Cryptographic responsibility for the message | Customer, SaaS provider, or delegated signer |
| SMTP connection and sending IP | The host that delivers the message | SaaS provider or its mail infrastructure |
| Application permission | Which tenant and users may trigger messages | SaaS provider and customer administrators |
DMARC ties the first row to the authenticated domain produced by SPF or DKIM. It does not decide who wrote the application code, who owns the queue, or who controls the sending IP. The DMARC specification calls the DNS registrant the Domain Owner, while also allowing that owner to delegate sending to an agent.
The customer controls the domain that appears in the visible From: address, assuming the customer controls its registration and DNS administration. That control includes:
_dmarc.example.comThe SaaS platform cannot make d=example.com an aligned DKIM identity merely by putting example.com in a configuration screen. A receiver will query DNS for the selector under the customer's domain. If the customer has not published the key or delegated that selector, the signature cannot verify.
The same is true of DMARC policy. A platform can recommend p=reject, but the customer's DNS is what publishes that request. A provider that hosts DNS on behalf of a customer may operate the control plane, but the important question remains who can change the record and under whose approval.
Treat every DNS record that authorizes a SaaS sender as a customer-owned security decision, even when the SaaS dashboard creates the record for them.
The platform normally controls the message-generation path. It chooses which tenant is allowed to send, renders the content, places the message in a queue, selects a sending route, and applies rate and abuse controls.
It may also control the outbound SMTP service and the private DKIM key. That does not make the provider the owner of the customer's domain. It makes the provider a delegated signer or sending agent, with authority limited by the DNS configuration and the commercial relationship.
The DKIM specification explicitly supports signing by third parties. The signature identifies the signing domain and associates that domain with message data. It does not assert that the signer owns the author's organization, nor does a valid signature authorize every future message a tenant might request.
This is why a SaaS provider needs controls beyond authentication:
Authentication proves that a configured domain authorized a mechanism. It does not prove that the particular tenant should have been allowed to use it.
There is no single "SaaS DMARC setup." The ownership boundary changes with the delegation model.
The simplest model sends from an address such as notifications@saas.example.org, while the customer is identified in the display name or message content. The platform controls the domain, SPF, DKIM, DMARC, bounce handling, and sending infrastructure.
This gives the provider a clean authorization boundary. A customer cannot accidentally publish a record that affects other tenants, and offboarding is straightforward. The tradeoff is that the customer's own domain is not the authenticated author domain in the visible From: field.
This model is often the safest default when a customer has not completed domain verification. Do not silently rewrite a customer’s visible address into an unauthenticated custom domain. Use a platform-owned address until the customer has completed the required setup.
The customer can create a dedicated subdomain such as mail.example.com or notify.example.com. The platform sends from that subdomain and the customer publishes the required SPF, DKIM, and DMARC records there.
With relaxed DMARC alignment, a signing or envelope domain under the organizational domain can align with the visible address. Strict alignment changes that result, so the exact domains matter. A customer that publishes strict adkim or aspf settings must test the platform's proposed identities rather than assuming a subdomain will work.
A dedicated subdomain limits blast radius. It gives the customer a place to separate SaaS traffic from employee, transactional, and marketing streams, and it makes offboarding less disruptive. The customer still needs to decide what policy applies to that subdomain and whether the parent domain's sp policy is involved.
For a fully branded message, the visible address may be billing@example.com and the platform may sign with d=example.com. The customer then publishes the public key at a selector such as saas2026._domainkey.example.com, often through a TXT record or a CNAME delegation.
The platform holds the private key and signs messages. The customer controls whether the public key exists in DNS. That split is useful, but it creates a high-value offboarding boundary: leaving a selector published may continue to authorize a provider's key even after the customer believes the integration is gone.
The DKIM key-management guidance and selector guidance are worth applying operationally. Use distinct selectors for integrations, document who owns each one, rotate by introducing a new selector, and remove the old selector after messages signed with it have aged out.
DMARC uses the domain in the RFC 5322 From: header as its visible author identity. It then checks whether SPF or DKIM produced a passing authenticated domain that aligns with it. One aligned mechanism is enough for a DMARC pass.
For example:
From: Billing <billing@example.com>
MAIL FROM: bounces@mailer.saas.example.net
DKIM-Signature: ...; d=example.com; s=saas2026;
Authentication-Results: receiver.example.net;
spf=pass smtp.mailfrom=mailer.saas.example.net;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.comHere, the SaaS provider controls the connection and may control the envelope domain, but the customer's DKIM delegation supplies the aligned identity. SPF can be useful for bounce authorization even when DKIM is what makes DMARC pass.
This result would be different if the platform used d=saas.example.net while the visible From domain was example.com. The DKIM signature might be valid, but it would not be aligned. A valid signature from an unrelated domain is not a DMARC pass for the customer's domain.
The DMARC alignment rules also distinguish relaxed and strict matching. Model the exact domains, not just the brand name displayed in the UI.
Several recurring designs fail because they confuse a message header with DNS authority.
That proves only that someone typed the address. It does not prove control of the domain. Require a DNS, email, or web-based verification step before enabling the address, and use a verified-domain allowlist when accepting future From addresses.
The signature can pass DKIM, but it may be unaligned with the customer's visible From domain. The message can still be delivered, but it does not establish the customer's DMARC identity.
SPF authorization for MAIL FROM is not automatically authorization for the visible From: domain. DMARC compares the authenticated SPF domain with the visible domain. The SPF specification describes authorization of the SMTP MAIL FROM identity, not ownership of arbitrary message headers.
That may stop new messages, but it does not remove a DNS record or revoke a private key already held by the provider. Offboarding must include both sides of the boundary: disable the tenant in the platform and remove customer-side DNS authorization.
Before onboarding a custom sending domain, write down the answer to each question:
| Question | Required answer |
|---|---|
| Who owns the visible From domain? | A named customer organization and DNS administrator |
Who can change _dmarc? | The customer or an explicitly authorized DNS operator |
| Who holds the DKIM private key? | A named operational owner with access controls |
| Where is the public DKIM key published? | An exact selector and customer-controlled DNS path |
| What is the SPF identity? | The exact MAIL FROM domain, not just the visible brand domain |
| Who can authorize a new From address? | A tenant administrator and the platform's verified-domain service |
| Who can stop sending immediately? | The platform, the customer, and the DNS owner through separate controls |
| Where do aggregate reports go? | A monitored address with a defined retention and response process |
| What happens at offboarding? | Tenant disablement, key/DNS cleanup, and report verification |
If any answer is "the platform handles it" without a named record, role, or procedure, the control boundary is not documented well enough.
header.from, header.d, smtp.mailfrom, alignment mode, and the actual sending source.The platform should also make the current state visible: verified, pending DNS, authentication failing, suspended, or removed. Hiding these states encourages users to keep sending from identities that have never been authorized.
Offboarding is where ownership assumptions become security incidents. Use a short, explicit runbook:
sp policy still permits an unintended subdomainDo not rely on DNS deletion as the only revocation mechanism. DNS caches create a transition period, and a platform may still have queued messages or credentials. Likewise, deleting a tenant record inside the platform is not enough if the customer continues publishing a provider-controlled selector.
The customer controls the sending identity when the customer controls the domain's DNS authorization and can revoke it. The SaaS provider controls the sending operation when it controls the tenant permission, signing service, queue, and SMTP path. A robust integration makes both facts true and visible.
DMARC is the receiver-facing link between those parties. It confirms that at least one authenticated domain aligns with the visible From domain. It does not transfer domain ownership to the SaaS provider, and it does not validate whether a particular tenant's business use is legitimate.
Multi-tenant SaaS email works best when delegation is narrow: authorize a specific domain or subdomain, use a documented selector, restrict which tenants can use it, and provide a fast path for both parties to revoke access. Shared infrastructure can remain efficient without turning every tenant into an implicit owner of every other tenant's identity.
The most important design artifact is not a green "DKIM passed" indicator. It is the ownership matrix showing who can authorize the domain, who can sign, who can send, who can observe reports, and who can stop the stream. When those answers are explicit, DMARC becomes a useful boundary between a customer's identity and a platform's sending machinery rather than a box checked after the fact.