Distinguish business email from mass email
SAP Cloud for Customer has separate authentication considerations for business messages and mass email. The first-party knowledge article distinguishes transactional uses such as service tickets and quotations from bulk communications such as campaigns and newsletters. Record which route is in scope before requesting activation or editing DNS. Do not assume a business-mail change completes a mass-email rollout. SAP business and mass email distinction
This guide applies to Cloud for Customer, commonly called C4C. It is not a configuration procedure for SAP Marketing Cloud, S/4HANA, Business ByDesign, or another product whose documentation happens to mention DKIM. Confirm the exact product, tenant URL, environment, sending domains, and support component before acting.
Build an inventory of each tenant and every actual visible From domain, including subdomains. Include test and production environments and messages generated by workflows, not just manually sent correspondence. The evidence should identify who owns each identity and which business process depends on it. A tenant URL alone is not a complete domain inventory.
Understand why managed SPF is insufficient
SAP's public business-mail FAQ says SAP maintains its infrastructure SPF and requires customers to complete DKIM configuration. That does not establish alignment for a specific customer's From domain: collect the actual envelope identity and compare it with From. The separate security-guide page was not readable during this review, so no environment-specific envelope suffix or alignment outcome is asserted from it. SAP business-mail FAQ
Adding a provider include to an unrelated customer-domain policy does not change the envelope identity used in the message. Before any SPF edit, record the evaluated identity and the reason the change is required. Maintain one applicable policy at that owner, preserve other legitimate senders, and account for nested DNS evaluation. SPF RFC 7208
For the documented business route, aligned DKIM is the key path to investigate. Do not weaken the domain's DMARC enforcement to conceal the absence of a valid aligned signature. A passing SPF result and a failing DMARC result can be consistent when the successful SPF identity is unrelated to the visible From domain.
Prepare tenant-specific business-mail records
SAP's public FAQ describes three CNAME records per sending domain per tenant, using tenant-specific selector names. It asks customers to supply the domain-to-tenant mapping and to cover all custom domains used for business mail. The sample tenant numbers are placeholders, not public values to copy into a customer zone. SAP business-mail activation FAQ
Obtain or confirm the current exact public owners and targets for the tenant's environment. The public FAQ gives tenant-specific examples, not confirmation of every environment; do not derive a target for an unconfirmed environment from a familiar crm.ondemand.com example. Preserve the support instructions and have the DNS administrator validate the mapping before publication. SAP business-mail FAQ
Check each proposed CNAME owner for existing data. A domain used by more than one business process can already have several selectors; new records must not overwrite unrelated keys. Verify the DNS console's owner-name expansion and publish only the current supported set. Store public values in the change record, but never include private signing material or account credentials.
After publication, retain authoritative lookup results and the domain-to-tenant list for the provider activation request. Use the public FAQ's domain-to-tenant mapping and explicitly confirm the business-mail activation process with SAP for the environment. DNS publication and SAP activation are separate stages. Do not report the work complete merely because a CNAME exists. SAP business-mail FAQ
Handle shared domains across test and production
SAP documents a case in which a production message uses a selector whose name refers to a test tenant because the same domain was activated there first. The article says one selector can be active per domain in that documented situation and that the name alone does not cause a sending problem. SAP selector usage across tenants
Use that explanation carefully. A surprising selector name is not proof of failure, but neither is the article proof that an actual signature is valid. Confirm the provider's domain profile, public key lookup, signing domain, and receiver result. Avoid deleting the test-named record simply to make the production evidence look tidier; it may still serve the active profile.
When a test tenant is retired, review shared signing dependencies before removing DNS. Record which tenant originally established the domain profile, what the provider says remains active, and which production workflows still use it. If a selector change is required, obtain a coordinated transition plan and keep old-key dependencies until the provider confirms retirement is safe.
Treat mass email as a separate activation request
SAP's mass-email activation article describes a sending subdomain, a three-CNAME configuration, and a support incident. It asks for mailing type, recipient category, expected monthly volume, volume per send, tenant, and subdomain. Prepare those operational details rather than submitting only a DNS screenshot. Confirm that the issued records and activation instructions apply to the current mass-email route. SAP mass-email activation
Choose the sending subdomain with the campaign owner and security team. A subdomain can clarify operational ownership, but it does not automatically isolate every reputation or policy concern. Check its existing DNS, the policy discovered for its From domain, reply handling, and any dependencies on other systems before using it.
The mass-email article notes that a generic checker may show an expected error for reserve records while the full three-record set remains required. Treat that as a provider-specific qualification, not permission to ignore arbitrary DNS failures. Have SAP confirm the intended active and reserve state, verify the exact CNAMEs, and prove the signature actually used by a received message. Do not remove reserve records just because they were not used in one test.
Capture business and mass-mail evidence independently
For business mail, select a harmless representative transaction or workflow in each released tenant. For mass mail, use a controlled test audience and a supported campaign test that will not contact unintended recipients. Record the originating object or campaign, timestamp, tenant, and selected sender. A test-tenant result should not silently substitute for production evidence.
At a trusted receiver, preserve the original headers and authentication results. Record the visible From, envelope identity, all DKIM d= signing domains and s= selectors, and the receiver's result for each relevant signature. The selector identifies the DNS public-key lookup; it is not itself the domain that DMARC aligns. DKIM RFC 6376
Apply current DMARC discovery and alignment rules to the observed identities. A passing aligned DKIM path can satisfy DMARC even when SPF passes without alignment. A policy record alone cannot add a signature or correct a mismatched From domain. Review effective policy before changing it, and use only approved reporting destinations. DMARC RFC 9989
If a test fails, preserve the exact failure and public lookup before changing anything. No signature can indicate missing activation or a different route. A missing key can indicate an incorrect selector record or target. A valid signature with the wrong signing domain points to alignment or domain-profile selection. These observations narrow the support request; they do not justify guessing a replacement record.
Fictional example of managed SPF and an unexpected selector
Fictional written case only: C4C-01 assumes a production quotation has From sales@company.example, a passing signature d=company.example, and a selector whose name refers to the test tenant. The exact selector and SPF identity are not supplied, so this is not a reusable DNS recipe. Under the stipulated passing signature, the signing domain exactly aligns; the unexpected selector name alone is not a reason to remove it. The SAP owner should verify the shared-domain profile before retirement. A separate mass-mail route has no activation or receiver evidence and stays open. No tenant, DNS query or message was executed.
Implementation worksheet and release limits
- Scope: exact product, tenant URL, environment, production or test status, business or mass route, and owner.
- Domain map: every visible From domain and subdomain, related workflows, reply owner, and shared profiles.
- DNS: current provider-issued three-record set, environment-specific targets, existing conflicts, TTLs, and lookup evidence.
- Activation: support reference, requested route, domain-to-tenant list, provider response, and active or reserve selector explanation.
- Mass-email planning: mailing purpose, recipient category, expected volumes, chosen subdomain, and controlled test method.
- Message proof: origin reference, From, envelope identity, DKIM d=/s= values, trusted results, effective policy, and alignment decision.
- Recovery: pause authority, previously supported route, shared-selector dependencies, and retirement approval.
Live tenant setup, public DNS, actual activation, received headers, and current screenshots remain unverified. Visual review, human SME approval, and publication are pending. This guide is an unpublished documentary candidate; environment-specific targets, shared-profile behavior, and any untested business or mass route require confirmation before release.
Source availability note
The Resolution text for SAP KB3573096 and KB3728757 was preserved from a successful public retrieval on 8 November 2026 at 04:12:48 UTC. A later independent check returned login-required previews. The shared-selector and business-versus-mass explanations above rely on those preserved primary-source copies; confirm current account applicability with SAP before implementation.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.