Direct answer: Two vendors can share one visible From domain only if one SPF record authorizes both senders, each vendor signs with its own aligned DKIM selector, and DMARC can align that From with SPF or DKIM. Most split stacks fail in three places: SPF soup (PermError), receipts that SPF-pass but fail alignment, and password resets support cannot find because they never entered the human mailbox.
The split stack operators actually run
The usual pattern is not exotic. People live in Google Workspace or Microsoft 365. Receipts, password resets, and invoices leave through Amazon SES, Resend, Postmark, or another sending API. Both sides use @company.com so the customer sees one brand.
That architecture can work. In 2026 it is also the architecture Gmail, Yahoo, and Outlook consumer mail punish when authentication is sloppy. Bulk-sender rules still require SPF and DKIM to pass, a published DMARC record (at least p=none), and DMARC alignment of the visible From domain. Microsoft’s May 2025 high-volume bar (about 5,000 messages per day to Outlook consumer addresses) is current policy, not a rumor.
The failure is almost never “the API is down.” It is SPF includes plus unaligned DKIM, plus an operations gap nobody named until a customer asked for the reset that support cannot search.
Failure mode 1: SPF soup on the apex
SPF is one v=spf1 TXT record per sending name. Two vendors on company.com means two include: mechanisms (or two IP ranges) in that same record. Teams then leave the old ESP, the CRM, and last year’s newsletter tool sitting in the string.
Nested includes consume the same budget. Crossing RFC 7208’s 10-lookup ceiling returns PermError. DMARC treats that SPF identifier as a fail even if the sending IP would have matched. Do not treat this as a reason to flatten Google or SES on a Friday. Count lookups, delete unused vendors, then move leftover senders off the apex. The lookup arithmetic lives in SPF’s 10 DNS lookup limit — this article will not re-teach it.
A second, quieter PermError: publishing two separate SPF records at the same name, one “for Workspace” and one “for SES.” Receivers do not merge them. They fail the evaluation.
Failure mode 2: receipts fail DMARC while Workspace mail looks fine
Workspace mail often aligns because Google signs with a selector under your domain and the MAIL FROM stays on a Google-authorized path. The app vendor is different.
A vendor that SPF-passes as amazonses.com or resend.dev while the visible From is [email protected] has not satisfied DMARC. Alignment, not a raw SPF pass, is what DMARC evaluates. If DKIM’s d= is the vendor domain instead of company.com (or a parent under relaxed alignment), the receipt fails even when the envelope looks authorized.
Each vendor needs its own DKIM selector. Do not reuse the Workspace selector for SES Easy DKIM, and do not assume “domain verified” means “From aligned.” Custom MAIL FROM / Return-Path is also per sender. Two vendors usually means two bounce domains. Mixing them on one SPF without an inventory is how DMARC reports become unreadable. For the header roles themselves, see From, Reply-To, and Return-Path.
In 2026 those alignment misses do not stay in XML. Non-compliant bulk is spam-foldered or rejected. That is why people-mail can look healthy while invoices disappear.
Failure mode 3: support cannot see what the API sent
Support works in Workspace. The password reset left through SES. Nobody can search Sent for the message the customer received, because that message never entered the human mailbox platform.
That is an operations problem, not a DNS typo. It also shows up when an agent needs the exact invoice PDF, the OTP timing, or proof that a noreply address still went out. Stop sending from noreply@ if humans are expected to answer; the split-stack version of the same mistake is sending from a real-looking address that no teammate can open.
How a split can work without lying about DNS
Two vendors on one From domain is legal if you treat authentication as inventory, not folklore:
- One SPF record at the From / MAIL FROM names you actually use. Authorize both vendors. Stay under 10 DNS-querying terms.
- A dedicated DKIM selector per vendor. Confirm the signature’s
d=can align with the visible From. - A published DMARC record. Alignment must succeed on SPF or DKIM for bulk mail.
- A named bounce domain per sender, so reports and suppressions stay attributable.
- An operations path for app mail: a shared mailbox, a ticket that stores the message ID, or a sending platform whose Sent folder humans can open.
The safer split is often not “two vendors on the apex.” Put people on the organizational domain and send product mail from an authenticated subdomain (mail.company.com, billing.company.com) with its own SPF and DKIM. Apex SPF does not cover that subdomain. Inheritance rules for SPF, DKIM, and DMARC are covered in SPF, DKIM, and DMARC on subdomains.
When collapsing onto one platform is the simpler fix
Keep the split if you have a real reason: a mailbox contract you cannot move this quarter, or a sending vendor with a constraint the mailbox host does not cover. Collapse it when the cost of the split is the incident queue — PermError after every new include, receipts that fail alignment, resets no one can find.
ArawaMail’s documented path is one company-managed Cloudflare domain for mailboxes and the send API. Onboarding order is add the domain, confirm an active Cloudflare zone whose name matches exactly, activate receiving, activate sending, then create accounts and optional API keys. Enabling sending writes DKIM CNAMEs plus custom MAIL FROM MX and SPF on Cloudflare. Mailbox compose and HTTP API sends both require sending-active. The API from domain must be registered, allowed by the API key, and sending-enabled.
Messages sent through the HTTP API are written to the Sent folder in the company database, so administrators can see outbound activity without hopping into a second vendor’s dashboard. That is the documented contrast with SES-only or Resend-only sending. ArawaMail does not offer a multi-vendor SPF console or a “bring your SES plus our inboxes on the same From” mode. If you keep SES or Resend after moving inboxes, that remaining API is still a second vendor: its own selector, its own include, its own lookup budget.
Product comparisons live on the existing pages: ArawaMail vs Amazon SES, ArawaMail vs Resend, ArawaMail vs Zoho Mail. The one-domain thesis — why inboxes and product mail should share authenticated identity — is Keep inboxes and product email on one domain.
How we analyzed this
This piece is an operator failure story, not a feature matrix. Claims about Gmail, Yahoo, and Microsoft bulk-sender rules follow published receiver requirements as they stood for 2026 operations: SPF and DKIM pass, a DMARC record present, From-domain alignment required for bulk. SPF lookup math follows RFC 7208 and the live ArawaMail PermError guide. ArawaMail behavior is limited to public docs: domain onboarding, enable sending, mailbox Sent-folder writes for HTTP API mail, and API-key scope. Exact DKIM hostnames are omitted because they are environment-specific; copy what the console writes on the day you enable sending.
Related guides
Authentication primitives: SPF, DKIM, and DMARC explained. SES domain verification if that vendor stays in the stack: Verify a domain in Amazon SES. Leaving Workspace for people-mail: How to move business email off Google Workspace. Branding context: Custom-domain email vs Gmail.
FAQ
Can two email providers send as the same From domain?
Yes, if one SPF record authorizes both, each has its own aligned DKIM selector, and DMARC can align the visible From with SPF or DKIM. That is a working split, not the default outcome of stacking includes.
Why did SPF return PermError after we added SES to Workspace?
You added another DNS-querying include to a record that was already near the 10-lookup ceiling, or you published a second v=spf1 TXT at the same name. Walk the live include tree before you add anything else.
Why do receipts fail DMARC when Workspace mail is fine?
Workspace is usually aligned. The sending API often SPF-passes on a vendor bounce domain while DKIM d= stays on the vendor. DMARC cares about alignment with the From your customer sees.
Where does the password reset live so support can see it?
Wherever that vendor stores outbound mail. If support only has Workspace, SES-sent resets are invisible there. Use a mailbox platform that writes API sends to Sent, or give support another search path.
Is a sending subdomain safer than two vendors on the apex?
Usually. Humans stay on the organizational domain; app mail gets its own SPF and DKIM. You still need DMARC coverage — inherited or published on the child. See authentication on subdomains.
When should we collapse to one vendor for inboxes and sending?
When the split’s cost is incidents: PermError, unaligned receipts, and mail no teammate can find. One authenticated domain for mailboxes and the send API removes those three seams.