SAP SuccessFactors SPF, DKIM and DMARC setup, step by step

To authenticate SAP SuccessFactors notifications from your domain, confirm the module and datacenter, add the applicable datacenter-specific SPF authorization, and request DKIM from SAP Cloud Support for the relevant domains. Publish SAP's issued public-key record, confirm activation, then inspect a new notification for passing, aligned branded DKIM and the actual SPF result. An internal allowlist or successful DNS lookup does not establish external DMARC alignment. SAP email security procedure and current datacenter SPF table.

This is a documentary guide. No customer tenant, DNS zone, support case, employment workflow or delivered notification was changed or tested.

Map the notification before selecting DNS records

This guide covers the SuccessFactors-hosted notification route described in SAP's HCM Suite email-security guidance, including its support-managed DKIM and optional customer relay. Record the company ID, module, current datacenter, notification category, visible From address and intended recipient path. Employee reminders, Learning messages and recruiting notifications must not be assumed to have identical sender settings merely because they belong to SuccessFactors.

SAP documents a default system sender and separately configurable Single Sender or module-specific addresses. Those settings affect the address visible to recipients; they do not prove the SMTP envelope or signing domain. Notification delivery and sender settings.

Recruiting Marketing is a separate configuration decision. Its email-campaign Reply-To procedure has its own SPF reference and SAP-managed DKIM request, and warns against changing Reply-To before prerequisites are complete. Do not substitute the HCM datacenter table below for that workflow. Likewise, a Reply-To change is not evidence that the visible From or MAIL FROM changed. Use SAP's Recruiting Marketing campaign procedure for that specific task and obtain the applicable account instructions.

Make a route list rather than one “SAP email” checkbox:

• Hosted notification: company, module, From domain and datacenter.
• Customer-relayed notification: matching recipient domain and every outbound gateway.
• Separate Recruiting Marketing campaign or other module-specific service: its own configuration and acceptance sample.
• Internal recipient path versus external recipient path: a local gateway exception can conceal a problem that an external receiver still sees.

Know which identity each check evaluates

SPF authorizes the connecting server for the SMTP MAIL FROM identity, often reflected by Return-Path after delivery. DKIM verifies a signature using its d= signing domain and s= selector. DMARC compares passing authenticated identities with the visible From domain. SPF identities and DKIM fields.

Either aligned SPF or aligned DKIM can satisfy DMARC. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. A pass for an unrelated SAP-owned envelope domain does not align with example.com. The operational goal here is to verify the branded signature you requested, not merely find an unrelated passing signature or an SPF-only DMARC pass. DMARC alignment.

When a signature passes but DMARC still fails, use the EmailAuth guide to raw DKIM versus aligned DKIM results to keep cryptographic verification separate from the From-domain comparison.

An internal allowlist changes local handling. TLS protects a transport connection. Neither substitutes for these identity checks at an external recipient.

Gather SAP's DKIM prerequisites

The current SAP KBA 2688533 directs requests to SAP Cloud Support under LOD-SF-PLT-NOT, with the company ID, datacenter and full list of relevant mail domains. It also specifies a valid A record, an SPF record and an MX record for its sending service.

Treat those DNS prerequisites as SAP's service requirements, not universal rules that all DKIM implementations require apex A or MX records. Ask SAP to confirm the exact domain to which each prerequisite applies. Do not invent an A address or point corporate MX records at SAP; changing an existing A or MX record can disrupt websites or incoming mail. Record the provider-confirmed full owner for each prerequisite, the DNS owner’s approved A address or address set, and the complete MX set including every numeric priority and target hostname. Compare those with the existing web and inbound-mail design before authorizing any change.

Prepare a change worksheet containing:

• Each exact domain, including any subdomain that needs signing.
• Company and instance identifiers, module and datacenter.
• Whether the mail stays on SAP's hosted route or uses a customer relay.
• Authoritative DNS owner and contact, existing policies and selector inventory.
• SAP-issued full DNS owner, TXT public-key value, selector and requested signing domain.
• Who confirms SAP-side activation and who reviews the delivered test.

SAP performs domain checks, and the KBA describes enablement at datacenter level. Include all affected instances rather than assuming a request in one datacenter covers another. Do not copy another tenant's key or reuse a selector based solely on a screenshot.

Choose the current datacenter-specific SPF entry

Use the datacenter that SAP confirms for the instance, not an assumed country or a number copied from an old login URL. SAP's current SPF table explicitly warns against broad all-datacenter authorizations such as _spf-sfdc.successfactors.com because of excessive SPF evaluation dependencies.

The following are the current documented mappings reviewed for this guide. Recheck the linked table before implementation, especially after a migration. Each row is a mechanism to merge, not a complete replacement policy.

SAP marks DC13, DC16 and DC18 decommissioned rather than providing current entries. For DC57 and DC33, it recommends the .sapsf.eu replacements instead of keeping both old and new includes. The row for DC60 still points to _spf-dc17.sapsf.com; do not construct a hostname simply by inserting the newest datacenter number. Whitespace after include: is not valid syntax, even if a source table visually separates the colon and hostname.

At the approved domain's DNS owner, merge only the required mechanisms into the existing v=spf1 TXT policy. Preserve other authorized senders and its ending qualifier. Do not add a second SPF record or replace an established -all with ~all merely because a sample uses it. Review the full nested policy against the ten DNS-querying-term limit. SPF publication and evaluation rules. If the policy uses redirect=, inspect its target and preserve legitimate authorizations and the approved terminal policy. Any all mechanism makes redirect ignored, wherever either appears. Do not append all to a redirected policy or insert a new include after a matching all; have the mail owner review the complete resulting policy. SPF redirect processing.

After delivery, compare that owner with the receiver's actual smtp.mailfrom. If SPF passes on an unrelated envelope domain, adding more mechanisms to the visible From domain cannot make that identity aligned. Record the limitation and verify branded DKIM; do not invent a custom Return-Path feature.

Publish SAP's issued DKIM key, then confirm activation

SAP generates and retains the private key. The customer publishes the issued public key. Its IT Landscape Requirements, section 4.4.1 describes publishing a DKIM TXT record and updating the support ticket after publication. Use the current request component in KBA 2688533 and the exact returned values.

The structural example below is not a record to paste:

Type: TXT
Full owner: <SAP-issued-selector>._domainkey.<approved-signing-domain>
Value: <complete-public-key-value-issued-by-SAP>

Preserve all key material and the exact supplied record type. If SAP provides a different record package for a separate module, follow that module's verified instructions instead of converting TXT to CNAME yourself. Never put a private key in public DNS or a shared worksheet.

For an illustrative selector sap-selector, the owner depends on the signing domain and DNS zone:

These examples explain DNS names, not a real SAP selector. Verify the resulting full owner and whether the DNS host automatically adds the zone suffix. A key added to the parent zone below an existing delegation may not be authoritative for the child. If _domainkey.hr.example.com is itself delegated, publish the key in that authoritative zone with relative owner sap-selector, producing sap-selector._domainkey.hr.example.com. For delegated _domainkey.example.com, the same selector is also relative sap-selector, producing sap-selector._domainkey.example.com. Follow existing NS authority, preserve shared delegations and other active selectors, and do not remove a delegation to make a parent-zone entry resolve. DNS zone authority.

Inspect any existing record at the intended owner. Do not replace an active selector without coordinating its owner. A CNAME at that exact name cannot coexist with the new TXT key; other selectors can remain independently. Long TXT key material may be represented by multiple quoted strings within one record, but the complete value must be preserved. DKIM key records and DNS alias restrictions.

Update the SAP case when public DNS resolves correctly, and obtain activation confirmation for the listed domains and datacenters. SAP notes that authentication may take up to 48 hours after adding a key. That is an allowance, not an acceptance test. A key in DNS cannot prove that a particular notification is signed.

Treat a customer SMTP relay as a different implementation

SAP's relay guidance describes routing by recipient-domain condition to a customer's SMTP server. It requests the server IP and port and, when required, authentication credentials through SAP's designated secure credential channel. Do not put those credentials in ordinary email, public DNS or the article worksheet.

The KBA currently describes one relay at a time and basic authentication, not an OAuth or Microsoft Graph integration. Replacing an existing relay requires coordination and customer approval. Do not disable modern authentication or weaken a whole Microsoft 365 or Google tenant to fit a legacy route. Have the mail/security owners and SAP confirm an acceptable supported design before any change.

For a relayed route, identify the final outbound IP, MAIL FROM and signing point. A gateway can replace the envelope or add, remove or invalidate a signature through content changes. A successful SAP-direct message to one recipient domain does not validate mail redirected through a relay for another recipient domain.

Keep the previously approved route available for recovery where possible. Retest the exact recipient-domain condition after relay, credential, gateway or sender changes. Relay delivery problems and hosted-notification authentication are related operational concerns, but their DNS authorizations must not be combined indiscriminately.

Keep DMARC reporting and policy under domain ownership

Check the policy applicable to the visible From domain, including inherited policy for subdomains. Preserve existing enforcement, report destinations and alignment settings. A provider setup is not authorization to replace p=reject or p=quarantine with p=none.

Only when there is no direct or applicable inherited policy and the domain owner approves a monitored start, this illustrative TXT value can be considered at the appropriate full owner:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

For visible From domain example.com, the full TXT owner is _dmarc.example.com, entered as _dmarc in the example.com zone. For hr.example.com, it is _dmarc.hr.example.com: enter _dmarc.hr in the parent example.com zone, or _dmarc in a separately delegated hr.example.com zone. Confirm the DNS editor's appended suffix and actual authority; do not create duplicate records or override inherited protection merely to use this example. DMARC policy discovery.

Use an approved working report destination, not the example address. Compare the Organizational Domain where the DMARC policy was found with the Organizational Domain of the report URI's destination host. If they differ, the report-generating receiver must check the destination's DNS authorization before sending aggregate reports; a destination within the same Organizational Domain is excepted. A different hostname alone does not make reporting external. RFC 9990 section 4.

DNS authorization does not replace the domain owner's separate approval to share report data with that recipient. Review access because notification patterns can reveal organizational activity. Preserve existing authorized report destinations. p=none requests observation rather than blocking while legitimate routes are assessed.

Look for different SuccessFactors notification paths and datacenter changes in aggregate reports. Pair that wider view with actual message headers rather than treating one passed sample as a complete sender inventory. An enforcement decision must include other legitimate services and indirect-mail risks. RFC 9989 requires valid DKIM for domains publishing p=reject; do not base enforcement readiness on SPF alone. DMARC deployment considerations.

Verify DNS at the actual names

The following are read-only command patterns, not executed test results. Replace the selector and domains with the issued values. Query the actual MAIL FROM domain for SPF, the actual signing domain for DKIM, and the visible From domain's applicable DMARC policy.

dig A example.com
dig MX example.com
dig TXT example.com
dig TXT SAP_SELECTOR._domainkey.example.com
dig TXT _dmarc.example.com

Confirm SAP's prerequisites at their provider-confirmed full owners without replacing working A or MX values. An A or MX answer is not acceptable merely because it is nonempty: compare the A address set and every MX numeric priority/target pair with the approved worksheet, and have the DNS/mail owner confirm that website and inbound-mail routing remain intact. For SPF, expect one interpretable policy containing the correct current datacenter authorization. For DKIM, expect the exact complete public value at the correct owner. For DMARC, inspect the applicable valid policy and intended reporting destination.

If the sender uses a child domain, do not automatically query only the apex. Check _dmarc.<child-domain> and any applicable parent policy. Query the correct authoritative child-zone servers when delegated, then compare with a recursive resolver. Inspect full response status: NXDOMAIN, no answer, SERVFAIL and timeout require different investigations. Cache expiry does not fix publication in the wrong zone.

Require delivered-message evidence for every important route

After activation, an authorized administrator should produce a new harmless notification through each representative module and route, using controlled recipients. Do not trigger employee changes, candidate decisions or production-wide messages just to create a test. Keep internal-gateway and external-receiver observations separate.

Use the final trusted receiver's Authentication-Results, not an arbitrary header copied through earlier hops. A familiar authserv-id or a header near the top does not prove its origin. Identify the result actually added for this delivery through the receiving service’s authenticated message view or administrator-confirmed trust-boundary handling; if provenance is uncertain, leave acceptance open. Capture From, Return-Path, smtp.mailfrom, all DKIM d=/s= pairs, SPF and DKIM results, and DMARC's header.from. Record the UTC timestamp, module, datacenter and relay condition. Authentication-result trust and forged-header risks.

A route is ready only when:

1. The message uses the intended visible From domain.
2. The intended branded DKIM signature returns pass and aligns under the applicable adkim mode.
3. DMARC returns pass, with the aligned mechanism identified.
4. SPF is evaluated at the actual envelope identity, and any failure or processing error is resolved or explicitly investigated before sign-off.
5. The application route, SAP activation, public DNS and received-message evidence all refer to the same domain and environment.

A provider-domain spf=pass that does not align is different from an SPF failure. Branded DKIM can supply alignment in the former case. In the latter, fail, softfail, permerror or temperror remains a real issue even if DKIM lets DMARC pass. Compare a direct unforwarded delivery when forwarding has changed the connecting IP.

Troubleshoot the failure without widening the change

The current SPF include differs from an older guide. Confirm the tenant's current datacenter, then use SAP's current table. Review DC57/DC33 replacements and remove superseded authorizations only after validating all affected instances.

SPF returns permerror. Check duplicate policies, spaces inside mechanisms, broken dependencies and the complete ten-term evaluation budget. Do not solve a broad include's excessive dependency count by adding another broad include.

SPF returns fail or softfail. Compare the actual envelope domain and connecting IP with the intended route. A customer relay may be the sender requiring authorization; adding SAP hosts elsewhere will not repair that path.

SPF returns temperror. Inspect transient DNS failures and dependency timeouts, then retest. Do not confuse this with the permanent lookup-limit error. SPF result meanings.

The expected DKIM signature is absent. Check activation, domain/datacenter coverage, notification module and message timestamp. A provider-owned passing signature is not proof that your requested branded signing is active.

DKIM is present but fails. Compare selector, signing domain and the exact DNS value. If key lookup succeeds, investigate stale keys and post-signing content modifications in the relay or gateway. Do not keep generating replacement keys without finding the failure stage.

DMARC passes but branded DKIM does not. Aligned SPF may be masking the missing DKIM configuration. Keep the signing task open.

Only internal mail succeeds. Check for local exceptions, rate limits and filtering separately from external authentication. Do not broaden an allowlist as a substitute for fixing identity alignment.

Retest when the notification path changes

Retain before-and-after DNS, SAP completion and redacted receiver evidence with a named HR-systems and mail owner. Review after domain, datacenter, module, relay or signing changes. Coordinate key retirement so queued messages can still validate. A correct setup reduces authentication failures; it does not guarantee delivery, inbox placement or the safety of message content.