Start with the notification rather than the brand name
An employee reminder and a candidate email can appear to come from the same organization while using different sender settings or delivery routes. Start with the notification the business needs to deliver. Record its SuccessFactors module, company ID, datacenter, configured From address and any customer relay. Add a separate inventory row whenever one of those boundaries changes. This guide addresses the SuccessFactors HCM notification route described in SAP’s public support documentation, not every product carrying the SAP name.
The target is a received message that preserves the intended visible identity and has an aligned authentication pass. Publishing a record is an intermediate step. A successful internal delivery can also be misleading if the organization’s gateway has a special exception for SAP traffic. Keep the internal acceptance test and the external authentication test separate.
Prepare the support request and DNS change together
In SAP KBA 2688533, “How to request/enable DKIM or SPF implementation?”, SAP directs DKIM requests to component LOD-SF-PLT-NOT with company ID, datacenter and the complete domain list. Its notes make the configuration datacenter-scoped and allow up to 48 hours after adding the key. The same KBA lists A, SPF and MX prerequisites for SAP’s service. Treat these as provider requirements, not a universal definition of DKIM.
Assign one person to the SAP case and another to the authoritative DNS zone if those responsibilities are split. The handoff should contain the exact domain, requested signing identity, DNS owner, record type, public value, TTL and agreed activation expectations. Keep private keys and credentials out of the worksheet. Do not infer the selector from another SAP implementation or an old screenshot.
Before editing DNS, export the current records and identify who owns any existing record at the proposed DKIM name. A selector collision is a stop condition, not permission to overwrite an active service. Ask SAP to resolve it. If a DNS form adds the domain suffix automatically, enter the owner in the format that produces the required fully qualified name and verify the published result afterward.
Select the current datacenter SPF entry
Use SAP KBA 2087468, “SPF” and “SuccessFactors DC SPF entries”, not a generic list copied from another account. SAP warns against the large all-datacenter include. Its table also identifies replacement entries for migrated datacenters, so a historically correct include is not enough to establish today’s configuration. Confirm the actual hosting location with the tenant owner before choosing an entry.
Keep the configured visible sender in the inventory. The same KBA discusses Single Sender and module-specific addresses, but an address displayed to the user does not tell you which domain a receiving server evaluates for SPF. RFC 7208, section 2.3 specifies the MAIL FROM identity. Obtain it from a controlled received message or the relevant delivery evidence before deciding what an SPF pass proves.
Merge only the required authorization into the existing policy at the appropriate owner. Preserve other legitimate senders. Do not create a second SPF policy, replace the organization’s current ending qualifier without review, or copy a sample that omits existing services. Sections 4.5 and 4.6.4 of RFC 7208 cover record selection and the ten-term limit for DNS-querying mechanisms and modifiers. Count nested lookups, not only the number of visible includes in the top-level string.
The useful change record is a before-and-after policy plus its evaluation review. It should explain why each new SAP authorization is necessary and what event will trigger its removal. A datacenter migration deserves a fresh check rather than an ever-growing list of old and new entries.
Treat a customer relay as a different route
If your tenant uses a customer relay, ask the mail owner to draw the complete path, including any final outbound gateway. The SAP KBA’s “Relay mail through a customer’s mail servers” section describes an alternative arrangement. Its current constraints are not a reason to introduce a relay casually. Confirm the supported configuration and responsibility for delivery with SAP and the receiving mail team before proposing a routing change.
A relay can change the sending IP, the envelope identity, the set of DKIM signatures and the point where content is modified. A test sent through SAP’s default route cannot validate a relayed production path. Likewise, a signature created early in the route may not survive later changes. Record which service is expected to supply the final aligned authentication result.
Do not put relay credentials in a ticket attachment or public DNS record. Use the organization’s approved credential process and SAP’s designated secure channel when a separate relay configuration is authorized. This guide does not configure credentials, change routing or assert that a universal custom Return-Path control exists.
Publish and verify the issued public record
Compare the live authoritative answer with the record supplied for the request. Confirm the owner is not duplicated, the complete public key is present and the record type is correct. Check the result at more than one resolver when cached answers disagree, and retain observation times. A DNS console showing “saved” is not the evidence a receiver uses.
Ask SAP to confirm activation for the listed domains and datacenter. Record the case reference and activation time without treating the passage of 48 hours as proof. If a new test lacks the expected signature, first check that it was generated after activation and came from the intended route. Repeated key regeneration can create additional uncertainty while the original routing issue remains unresolved.
RFC 6376, section 3.5 defines the signing-domain and selector fields used to locate a verification key. Capture every DKIM d= and s= pair from the final message. A provider-domain signature can be technically valid while failing to align with your chosen From domain.
Test each meaningful notification path
Use harmless content and controlled recipients. Avoid real candidate details, employee records, application attachments or production-wide announcements. Where the business needs several notification types, select representative messages without assuming that one success covers them all. Keep the message identifier and UTC send time so the same delivery can be traced through SAP and the receiving system.
For each message, record the visible From domain, receiver-reported envelope identity, all DKIM identities, SPF result, DKIM results and DMARC result. Use the final receiver’s trusted Authentication-Results, not arbitrary similarly named headers carried through the message. Record the policy and alignment mode that the receiver evaluated.
RFC 9989, section 4.4, “Identifier Alignment Explained” requires an aligned passing SPF or DKIM result for DMARC. The worksheet should identify the mechanism providing that pass. “Delivered,” “TLS used” and “SAP appears on our allowlist” are different observations and should not occupy the DMARC evidence field.
If SPF passes under an unrelated envelope domain, adding more SPF authorizations to the visible From domain will not make that particular pass aligned. Investigate the intended DKIM identity and supported route instead. If DKIM fails, distinguish missing key, mismatched selector, malformed public record and post-signing modification before changing policy.
Use the route acceptance worksheet
Create a separate review record for the SuccessFactors domain-and-datacenter worksheet using the fields below. Complete one copy per meaningful sending route. It includes the SAP case, issued DNS record, datacenter authorization, activation confirmation, receiver identities, alignment decision and recovery owner. Leave unobserved fields blank and mark the next action rather than substituting a sample value.
The acceptance record should answer three questions: did SAP activate the intended identity, does public DNS support it, and did the receiver validate a message from that exact route? Require all three. Record separate results for the external test and the organization’s internal gateway so a bypass does not hide the difference.
Fictional worked example: the wrong datacenter assumption
Fictional written case only: SF-01 assumes intended From hiring@careers.example, but the first notification uses a provider From whose exact address is unknown. DKIM, selector and envelope/SPF results are unknown. An old datacenter request is not evidence for the current tenant. The HR systems owner must confirm the current datacenter and notification sender, obtain activation for that route, then inspect a new harmless external message. No DMARC verdict is inferred and no tenant, DNS or message was tested.
Recover without broadening the failure
Pause the affected notification change when business-critical tests fail and use the previously approved delivery route if one exists. Coordinate any reversal with SAP and the mail owner. Do not delete a public key while newly sent or queued messages may still require it, and do not weaken the whole organization’s DMARC policy merely to make one route appear successful.
Retest after datacenter migration, sender-domain changes, relay changes and notification-routing changes. This remains an unpublished implementation draft: live tenant review, account-issued records, DNS observations, received-message identity evidence, visual review and human SME approval are pending. Preserve those as acceptance gates rather than silently treating the documentary research as a completed deployment.
Source availability and implementation confirmation
The two SAP KB pages were retrieved as public text in the preserved 8 November 2026 source snapshots. During this review the initial open again identified public Resolution content, but later section opens returned login-required previews. Detailed instructions above therefore rely on the preserved primary-source copies, not a claim that the full pages remain publicly readable. Confirm the current datacenter entry, service prerequisites and activation workflow with SAP before making changes. No login or access bypass was attempted.
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.