Sending email for a SaaS product gets more complicated when customers want their own identity in the From address. The authentication work depends on whether you send from subdomains you control or domains your customers own.
Those two setups share the same SPF, DKIM, and DMARC rules. What changes is who can publish the DNS records, how your sending infrastructure authenticates each message, and how you track problems when a customer's configuration changes.
Start with the From address
The key question is who controls DNS for the domain in the From address:
- Subdomains you control: each customer sends from an address such as
[email protected]. You manage DNS forexample.com. - Customer-owned domains: your platform sends from an address such as
[email protected]. The customer manages that domain's DNS.
Decide which pattern you're supporting before designing the onboarding flow. It determines what you can configure centrally and what you need the customer to do.
Pattern 1: subdomains you control
When tenant subdomains share a parent domain you manage, you can publish a parent DMARC policy that they inherit unless they have their own overriding policy.
For an existing setup where legitimate sending has already been checked, that might look like:
_dmarc.example.com TXT "v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:[email protected]"
Replace the reporting placeholder with the address assigned to your domain in MyDMARC.
p=quarantine requests quarantine for mail that fails DMARC at the parent domain. sp=quarantine explicitly applies the same policy to existing subdomains that inherit it. np=reject requests rejection for failing mail using nonexistent subdomains. Here, np serves a distinct purpose because its policy is stricter than sp.
If you haven't identified and checked your legitimate senders yet, start with monitoring before enforcing quarantine.
The distinction to remember is that DMARC policy inheritance does not automatically configure SPF or DKIM.
SPF checks the envelope sender domain used during delivery. Each domain you use for that purpose needs an appropriate SPF configuration; the root domain's record doesn't automatically cover its subdomains.
A shared DKIM setup can work. For example:
From: [email protected]
DKIM signing domain: example.com
Those domains align under relaxed DMARC alignment. Under strict alignment, they must match exactly. Whether new tenants need additional DNS records therefore depends on your authentication design and sending provider—not just the parent DMARC record. The DMARC specification explains both alignment modes and subdomain policies.
Keep tenant permissions separate from authentication
DMARC doesn't know which customer owns which account in your application.
With relaxed alignment, authentication using customer1.example.com can also align with a From domain of customer2.example.com. Both share the same organizational domain.
Your platform must enforce which From addresses each tenant can use. Validate that permission when sending, and keep signing credentials under appropriate control. A passing DMARC result is not proof that the correct tenant authorized the message.
Pattern 2: customer-owned domains
When a customer wants to send as [email protected], you need their cooperation or delegated DNS access to configure authentication.
Before enabling that address, verify the customer's control of the domain and associate it with the correct tenant. Then provide the exact records required by your sending provider.
Avoid giving every customer a generic instruction to add an SPF include and a DKIM CNAME. The required records depend on your setup:
- DKIM: configure signing with a domain aligned to the customer's From domain. The provider may require TXT records or CNAME records.
- SPF: if you want SPF alignment, configure an aligned envelope sender, often through a custom MAIL FROM or return-path domain. Adding an SPF include to
acme.exampledoesn't help if SPF is actually checked against your provider's unrelated domain. - DMARC: respect the customer's policy and alignment requirements. Configure your sending to meet them rather than asking the customer to weaken their policy.
DMARC passes when at least one authentication mechanism passes and aligns. Aligned DKIM can therefore pass DMARC even when the provider's default envelope sender doesn't align. Amazon SES documents these two authentication paths.
If a customer doesn't want to configure DNS, you can offer an address on your own domain with their brand in the display name. That avoids needing authentication for their domain, but your own sending still needs to authenticate and align correctly.
Make authentication checks part of onboarding
Treat custom-domain setup as an ongoing configuration, not a checkbox completed once.
Before enabling sending, check the required DNS records and verify a test message's authentication results. Recheck the configuration over time, especially after customers change providers or DNS hosting.
Give customers a useful error when something breaks: identify the affected domain and record, explain what needs fixing, and make clear whether sending is paused or uses an agreed fallback address.
Don't silently switch to another customer's identity or keep sending from an address the tenant is no longer authorized to use.
Make reports useful at the customer level
For subdomains that inherit your parent policy, you can collect reports centrally. For customer-owned domains, customers need to configure a reporting destination you can access or share the results with you. External reporting destinations also need the appropriate reporting authorization.
Group results by the visible From domain as well as the sending source. Many customers may use the same provider and IP addresses, so an IP alone won't tell you which customer's authentication needs attention.
MyDMARC helps you inspect sending sources, From domains, and authentication results in the reports it receives. Use that visibility alongside your platform's domain-to-tenant mapping and sending logs to investigate failures.
The useful outcome is specific: knowing which customer's domain has a problem, what failed, and who needs to fix it.