SAP Business ByDesign SPF, DKIM and DMARC setup, step by step

Quick answer: SAP Business ByDesign's documented DKIM process has two owners: your DNS administrator publishes the public key supplied by SAP, then SAP activates the signing profile after you return the support case. A DNS record that resolves correctly is not evidence that SAP has enabled signing. Do not substitute Cloud for Customer, SuccessFactors or an unrelated SAP product's records.

This guide covers Business ByDesign business and mass-email DKIM workflows documented in SAP's August 2026 library. It does not provide a universal SPF include or a custom envelope-domain configuration: those are not established by the ByDesign sources reviewed. The operative August 2026 SAP instructions were reviewed in indexed primary-source text; the directly rendered pages were unavailable. This is documentary guidance, not a tested tenant deployment.

Separate business email from mass email

SAP documents business-email DKIM activation separately from mass-email activation. Identify the actual workflow before requesting anything. Successful signing on an operational notification does not prove that a campaign follows the same configured route.

Make a short inventory: intended visible From domain, sending application workflow, test and production tenants, existing DNS owner and person authorised to approve changes. Include every intended subdomain, not just the company's main domain. Do not add a domain merely because a staff member has typed it into a template; confirm ownership and authorisation first.

Request the appropriate SAP-issued packet

For business email, open a Medium-priority ByDesign support case requesting business-email DKIM activation and list all intended sending domains. SAP's documented sequence is: support supplies a 2048-bit public TXT key and selector; you publish and validate DNS; you return the case; SAP activates the profile. The source notes that the supplied key covers test and production and may be common across multiple listed domains. Confirm the returned packet's exact scope before applying it.

For mass email, complete SAP's two prerequisites:

1. Open Business Configuration > Implementation Projects, select the project, then Edit Project Scope > Questions > Marketing > Campaign Management > Campaign Execution. Scope “Do you want to execute campaigns by directly sending e-mails out of your SAP solution?”
2. Maintain the sending domains under Business Configuration > E-Mail and Fax Settings > Activation of Mass E-Mail.

Open a Medium-priority case with subject “Request to enable DKIM for Mass E-Mails.” Include the tenant URL, all sending domains/subdomains, mailing type (alarm, news or update), recipient categories, monthly volume and volume per send. Use aggregate figures, not a recipient list. Follow the issued packet, validate DNS and return the case for SAP activation. The documented mailing selector is an example, not permission to replace the selector SAP actually issues.

These requests are instructions for your authorised operator. This article does not open a case, configure campaign functionality, or approve a new sending programme for you.

Publish the full public TXT record at the right owner

Get the complete record type, fully qualified owner, selector, sender-domain scope and public TXT value from the SAP case. A DKIM public key belongs in DNS; a private key, account password or session token does not. Do not copy a public key from an example screenshot or another customer.

Suppose the issued selector is SELECTOR_FROM_SAP and the approved signing domain is news.example.com. The owner has this structure:

SELECTOR_FROM_SAP._domainkey.news.example.com

This is an illustration, not a reusable SAP selector. Map it to the authoritative zone correctly:

• In the parent example.com zone, a relative-name editor would normally use SELECTOR_FROM_SAP._domainkey.news.
• If news.example.com is separately delegated, use its actual DNS provider; the relative name there is SELECTOR_FROM_SAP._domainkey.
• If _domainkey.news.example.com itself is delegated, the TXT record belongs in that delegated namespace, with relative name SELECTOR_FROM_SAP.

Some DNS editors expect a full name and others append the zone automatically. Inspect the resulting fully qualified owner before saving. Preserve NS delegations, existing selectors and shared services. A CNAME already at that owner conflicts with publishing a TXT value there; stop and resolve the issued selector or existing dependency with its owner rather than deleting it blindly.

Paste the complete tagged public value as supplied. DNS providers may divide a long TXT value into quoted character strings; the retrieved concatenated value must still represent the issued record. Do not truncate a 2048-bit key to fit a text box. For a DNS-host example, see EmailAuth's IONOS DNS publishing guide, provided the zone is actually hosted there.

Validate DNS, then obtain activation confirmation

Check the authoritative DNS answer and the complete public key syntax before returning the case to SAP. Query the identified authoritative server directly, then compare your recursive resolver:

dig @AUTHORITATIVE_NAMESERVER TXT SELECTOR_FROM_SAP._domainkey.news.example.com +norecurse
dig TXT SELECTOR_FROM_SAP._domainkey.news.example.com

Replace AUTHORITATIVE_NAMESERVER with the nameserver authoritative for the actual record owner, including any child or _domainkey delegation; replace the illustrative selector and domain with the approved values. The first command targets that server; the second uses your configured recursive resolver. A missing answer is not a successful validation; check the zone, delegation, appended suffix and record type. A truncated or malformed key must be corrected. Compare authoritative answers with recursive results when caches still reflect old data. No DNS query was run for your domain by this article.

Return the case with the requested validation evidence and ask SAP to confirm activation for the intended domains and workflow. Do not report completion from a DNS checker alone. Keep three milestones separate: record published, SAP signing enabled, and a genuine message verified.

Handle SPF without copying another SAP product's recipe

SPF evaluates the actual SMTP MAIL FROM identity, not automatically the address readers see in From. Establish the envelope domain from the real sending route and ask SAP for the applicable ByDesign SPF requirements if you are responsible for that domain. An SPF record at your company apex cannot change an envelope domain owned by another organisation.

Do not infer ByDesign IP ranges, includes or custom MAIL FROM controls from Cloud for Customer or Sales Cloud documentation. The common SAP name does not establish shared configuration. This guide intentionally provides no unsupported universal ByDesign SPF constant.

If SAP confirms a customer-managed SPF change is necessary, preserve legitimate existing authorisations and maintain one SPF policy at that evaluated owner. Check the budget of ten evaluated DNS-dependent terms, including nested mechanisms, rather than merely counting visible includes. A redirect is ignored when an all mechanism exists. Do not replace a working policy with a sample or claim that an SPF qualifier guarantees delivery. These behaviours are defined in RFC 7208.

Verify a real message and preserve DMARC protection

After SAP confirms activation, test a harmless message through each intended workflow to an approved external mailbox. Use controlled recipients and non-sensitive content. Do not send a live customer campaign just to test a record.

Inspect authentication results generated inside the receiving service's trusted processing boundary. Its administrator should establish how external Authentication-Results fields are removed or distinguished; a familiar server label or header position alone is not evidence. See RFC 8601.

Record the actual From domain, DKIM d= and s=, signature result, evaluated SPF identity/result and receiver DMARC result. For your intended branded DKIM route, require its signature to pass and align with the intended visible From, alongside receiver dmarc=pass. An unrelated signature or a DMARC pass supplied only by SPF does not prove the requested DKIM setup works.

Under RFC 9989, adkim controls DKIM alignment and aspf controls SPF alignment. Relaxed alignment uses the same Organizational Domain; strict alignment requires an exact domain match. A child envelope domain does not automatically satisfy strict SPF alignment. Do not assume the support-issued key's cross-tenant scope proves every message identity aligns.

Preserve the domain's existing direct or inherited DMARC policy and authorised report destinations. Do not downgrade enforcement, duplicate a policy, or import a report recipient from a tutorial as a DKIM troubleshooting step. A new reporting destination in a different Organizational Domain requires receiver-side DNS authorisation; one in the same Organizational Domain is excepted, as explained in RFC 9990 section 4. That DNS rule is separate from the domain owner's privacy and data-sharing approval.

Troubleshooting and safe rollback

• DNS is correct but no expected signature appears: check SAP's final activation response, the exact workflow and signing domain. Do not keep generating new selectors without resolving the active profile.
• DKIM fails: compare the message selector and signing domain with the issued public record; investigate missing DNS, malformed values, rotation or message modification. Retain the original message privately.
• DKIM passes but DMARC fails: compare the passing signature's domain with the actual From and its alignment mode. A valid signature on the wrong identity is not the required outcome.
• SPF fails while DMARC passes: record whether aligned DKIM supplied the pass. SPF fail, temporary errors and permanent errors remain different findings to diagnose, not a reason to call SPF healthy.
• Only one workflow succeeds: test business and mass-email routes independently and send SAP the minimal relevant evidence. Do not expose passwords, private keys or unnecessary message contents.

Before any DNS change, retain the original record and authorised change plan. If rollback is needed, coordinate it with SAP's signing state; removing a key still used for live signatures can break authentication. Restore only the approved previous state, preserving unrelated mail services, MX, DNSSEC and nameserver delegations.