A marketplace can deliver a merchant's words without being authorised to authenticate the merchant's domain. Distinguish who wrote the business content, whose domain appears in From and which service operates the mail stream. These roles may belong to three different parties. A familiar merchant display name does not settle the domain-identity question.
Choose the intended author identity
For a platform-originated order notification, use the platform's approved identity and make the merchant relationship clear in the content. For a merchant-branded route, verify control of the merchant domain and the specific delegation needed for authentication before enabling it. Do not accept a merchant's typed domain as proof of control or copy another seller's configuration into the new tenant.
The worked map separates platform order notices, merchant responses and support updates. Assign each to a named integration or service owner. Record whether From is platform-owned or merchant-owned, which tenant can trigger mail and who can rotate or revoke the signing configuration. A reply address can direct conversation to a merchant without making that address the DMARC author identity.
Test both an allowed and an unaligned case
The fictional merchant case presents seller.test in From while signing as market.test. Even assuming that signature verifies, it fails strict DKIM alignment with seller.test. The platform order and support identities in the route map match their respective From domains; those are assumed configurations, not observed tests. This illustrates why successful signing by the platform does not by itself authorise use of a seller's identity.
Select an honest supported design: a platform-owned From with clear merchant attribution, or a properly verified merchant-domain configuration. The latter requires documented authority and scoped access. Record the approved tenant, domain, selector, DNS proof and revocation owner. These are recommendations for evaluating a system, not claims that a particular marketplace or EmailAuth implements them.
Keep tenant authority in the acceptance test
A cryptographic pass cannot reveal whether the wrong seller account was permitted to select the domain. Add negative application tests: a second merchant must not send as the first merchant, an expired delegation must not remain usable, and removing a merchant must close the relevant sending path. Run such tests only in an authorised test environment and preserve the actual system results separately from these hypothetical identities.
Inventory shared IPs as infrastructure evidence, not merchant identity. One platform range can carry many tenants, including compromised ones. Do not whitelist all messages from that range merely because one order notification is legitimate.
Plan the end of the relationship
Define how queued messages, replies and open support conversations are handled when a merchant leaves. Revoke the exact delegation without disrupting unrelated merchants. Preserve only the reporting and audit evidence the platform is authorised to retain. Consumer disclosures, merchant contracts, data-sharing terms and payment liability need qualified review; neither DKIM nor this route map adjudicates them.
Fictional route map
The following explicit identities are illustrative inputs, not real customer configuration. These domains and accountable roles are hypothetical, not customer approvals or supplied signed messages. No cryptographic test or delivery was executed.
- Platform order notification: Platform messaging lead; From orders.market.test; envelope and DKIM signer orders.market.test.
- Merchant message: Merchant integrations lead; From seller.test; envelope and DKIM signer market.test.
- Platform support: Customer support lead; From support.market.test; envelope and DKIM signer support.market.test.
Check the grant before the signing result
Suppose merchant A has approved a scoped domain configuration, but merchant B can select it through the platform’s sender picker. A correctly aligned signature on the resulting mail would not repair that application authorization failure. Hold the route, preserve permitted diagnostic evidence and test the actual tenant/object boundary with authorized test accounts. Do not send a live impersonation message merely to demonstrate the problem.
OWASP’s multi-tenant guidance, sections 1, 3 and 5, supports trusted tenant context and resource authorization, including delayed work. RFC 9989 Sections 4.4 and 5.3.5 distinguish DKIM alignment from the complete message verdict: other aligned authentication paths must be evaluated. Sections 7.4 and 8 require valid DKIM for p=reject deployment rather than reliance on SPF alone. No merchant grant, selection test or signing operation was executed.