Emarsys SPF, DKIM and DMARC setup, step by step

For the SAP Emarsys email platform, now presented as SAP Engagement Cloud | SAP Emarsys in its help documentation, obtain the current DNS table from Management → Account Management → Email Domain Validation. Publish the records for the intended sender, link and bounce domains, validate them, and request SAP Support activation with the successful validation screenshot. A successful DNS check does not itself enable sending. Finish by inspecting a delivered message for branded DKIM, SPF and DMARC results. SAP domain validation and activation.

Confirm which SAP email product you are configuring

SAP's website states that SAP Emarsys is now SAP Engagement Cloud. However, that naming change is not permission to mix DNS records from every SAP product. This guide covers the Emarsys account workflow documented under SAP Engagement Cloud | SAP Emarsys, including marketing email and separately configured transactional sending. Current product identity.

SAP Engagement Cloud, enterprise edition has a separate onboarding guide. Its EU and US cloud-region tables use different edp SPF and DKIM targets and edp01/edp02 selectors. That edition also says it supplies sending, not mailboxes or reply management. Do not apply those records to an existing Emarsys configuration merely because both products use the Engagement Cloud name. Use the documentation and generated settings matching your tenant. Enterprise-edition email domain onboarding.

These instructions also do not configure SAP Cloud for Customer, SAP S/4HANA, employee Microsoft 365 mail or Salesforce's unrelated Sender Authentication Package. If the domain-validation navigation below is absent, establish the product, edition and account permissions with your SAP administrator before editing DNS.

Plan sender, bounce, link and reply handling

There are several domain roles, and changing one can affect more than authentication:

SAP recommends recognizable branded subdomains and warns that repointing an old platform's domains can break links and other functionality in messages already sent. Plan a new subdomain for a migration where appropriate rather than replacing an active tracking alias. Decide explicitly who receives replies. SAP Emarsys DNS planning.

Record the exact From addresses and separate marketing and transactional streams. Confirm the intended bounce-domain assignment with Support when several brands or streams share sending infrastructure. SAP's bounce-domain guidance describes shared, relaxed-aligned and, where feasible, strictly aligned configurations. Its documented per-IP-configuration limitations mean you should not assume every brand automatically gets its own aligned bounce identity. SAP bounce-domain options.

Have both an authorized SAP account administrator and a DNS administrator available. Export the affected zone records and TTLs. Preserve employee-mail SPF authorizations, unrelated DKIM selectors, DMARC policy and inbound MX. If DNS is delegated to SAP or another service, establish who is authoritative before creating records in a non-authoritative control panel.

Get the account's current DNS table

1. Open Management → Account Management → Email Domain Validation.
2. For an existing domain, open Domain and DNS Information to inspect the recommended records and their status.
3. For a new setup, choose Add Domain, enter the sending domain, link domain or both, and select Save & Next.
4. Use Export DNS table to retain the CSV of recommended settings.
5. Compare each full owner, record type and value with the current zone before publishing.

The validation page distinguishes sender, link and bounce domains. SAP requires a validated set for campaign sending and requires at least one sending domain and one link domain before adding more domains. Follow the account's actual required rows, including applicable MX and link records, not just the two protocols named in a search query. Current SAP workflow.

Do not generate independent DKIM keys for this current CNAME-based workflow. Do not send a private key through email because an older third-party tutorial suggests it. SAP's current approach uses provider-hosted public keys through CNAMEs and supports rotation. SAP DKIM implementation.

Publish SPF and distinguish authorization from alignment

Current SAP Emarsys troubleshooting examples use include:spf.emarsys.net. For an otherwise unused sender subdomain, the example pattern is:

Owner: email.example.com
Type: TXT
Value: v=spf1 include:spf.emarsys.net ~all

This is an illustration of the documented Emarsys route, not a universal SAP record or a substitute for your exported table. Do not choose emarsys.net, emarsys.us or an enterprise-edition edp include from an old geographic rule without checking the tenant. Current SAP configuration examples.

If the exact owner already has SPF, merge the required authorization into its single v=spf1 TXT policy before the terminal all mechanism. Preserve still-needed senders and the approved failure qualifier. Never add a second SPF policy, replace the whole organization's SPF with this single-sender example or copy sample IP addresses. Review the ten DNS-lookup-term limit across nested includes. SPF publication and evaluation.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

SPF checks the envelope MAIL FROM domain, not the visible From domain. SAP recommends the sender-domain SPF record, but the actual message's bounce identity remains decisive for SPF evaluation and DMARC alignment. A root-domain SPF change cannot repair a different envelope domain merely by mentioning Emarsys.

For From: news@email.example.com and MAIL FROM at bounces.email.example.com, successful SPF is relaxed-aligned, not strictly aligned. A shared SAP bounce domain may pass SPF without aligning at all. SAP documents strict branded DKIM alignment for the Emarsys route, allowing DMARC to pass when SPF is unaligned. Verify that claim on your delivered message instead of treating it as proof that your configuration is correct. SAP identity and alignment explanation.

Add DKIM and bounce records without disturbing inbound mail

The current Emarsys examples illustrate these records for separate sender and bounce domains:

Use the current exported account values if they differ. Preserve both DKIM selectors. The target name is not a TXT public key, and the bounce alias is not the DKIM record. SAP's current record examples and alternative MX scenarios.

In a zone for example.com, a DNS form that appends the zone normally expects key5._domainkey.email as the relative owner. In a delegated email.example.com zone, it normally expects key5._domainkey. Inspect the saved full name and target so the host does not become email.example.com.example.com. Follow the DNS service's handling of absolute target names and trailing dots.

If the actual _domainkey namespace is itself delegated, publish at that authority: for full owner ISSUED-SELECTOR._domainkey.news.example.com in the delegated _domainkey.news.example.com zone, the relative owner is only ISSUED-SELECTOR. This is a placement illustration, not a provider-issued selector or a new sending-domain assignment. Preserve the existing NS delegation, other selectors and exact issued record type/target. DKIM owner construction, relative DNS names.

A CNAME owner generally cannot carry other record data. If a selector or bounce name is already used, resolve the collision rather than deleting unknown records or putting TXT alongside CNAME. Keep existing selectors belonging to other mail services. DNS aliases.

For Cloudflare-hosted DNS, keep the DKIM and bounce CNAMEs DNS only, not proxied, and unflattened so their aliases remain available to verifiers and mail-related lookups. Cloudflare warns that flattening may prevent a third-party service from seeing the required CNAME. Apply this safeguard to the authentication aliases, not as a blanket change to your website or tracking-domain proxy settings. Cloudflare proxy guidance, CNAME flattening and verification.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

MX changes depend on the selected bounce and reply architecture. SAP documents different cases when sender and bounce domains are identical, when they differ, and when a shared SAP bounce domain is still active. Its mx.eemms.net reply-handling example is conditional. Do not replace your root-domain MX or employee-mail routing with a sample. Have Support confirm the intended MX owner, target, priority and reply service. Copy and verify each priority as well as the hostname; an MX target without the correct priority is an incomplete change specification. If SAP hosts your replies, set the From email addresses under Contacts → Reply Management. Receiving replies and processing bounces are different requirements. SAP DNS settings and Reply Management.

Receiving a Support packet is not separate approval to change routing. Before publication or activation, the routing owner must approve the exact complete MX design: full owner, every numeric priority and target, plus any actual reply-forwarding recipient. Reconcile it with the authorized inbound/reply plan, preserve existing corporate mail, and stop on any mismatch. Compare the complete approved MX set at the authoritative servers and a public recursive resolver, not just one hostname. Validate reply delivery to the specifically approved recipient without silently redirecting unrelated inbound mail.

Keep DMARC under the domain owner's control

SAP's configuration examples include a rejecting policy with strict DKIM and relaxed SPF alignment. Do not blindly overwrite an established record with that example or enforce rejection before all legitimate sending streams have been inventoried and verified.

Inspect _dmarc.email.example.com and any applicable parent policy, including _dmarc.example.com, before adding a subdomain record. Absence at the child does not prove absence of an inherited policy. Preserve current enforcement, reporting recipients and alignment settings unless the security owner approves a change. A new child p=none can weaken inherited enforcement and is not a harmless way to satisfy a setup wizard. DMARC policy discovery and alignment.

For a new domain with no existing or inherited enforcement to weaken, an owner-approved monitoring policy can begin with the following illustrative record, subject to the account's onboarding requirements:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example with the correct policy owner and an authorized, monitored mailbox. Publish only one DMARC policy there. If SAP's onboarding requires a different policy, resolve that with the security owner and Support instead of silently weakening protection or immediately rejecting unverified legitimate mail.

For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

For an external aggregate-report destination, obtain the actual assigned address and complete external-destination authorization. Reports expose information about sending sources, so choose recipients deliberately. Avoid adding failure-report recipients without a separate privacy review. Aggregate-report destination safeguards.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

An EmailAuth sender and alignment review can organize aggregate evidence across Emarsys and other services before enforcement changes. Reports complement direct message checks; they do not replace them.

Validate, request activation and handle legacy migrations

After publishing, select Start validation. Review the domain results and Notification Center outcome. For a new sending or link domain, create the support ticket SAP requires and include the successful-validation screenshot. Ask Support to confirm the sender, branded DKIM and chosen bounce configuration are enabled. The validation tool checks DNS; it does not configure the account for you. SAP validation requirements.

For a legacy Emarsys domain, use a staged migration:

• Obtain the current recommended records and retain the existing working configuration.
• Add the new bounce and DKIM CNAMEs and make the approved SPF update.
• Keep the old Emarsys DKIM record while Support checks and switches the configuration.
• Make conditional MX changes and retire old Emarsys selectors only after Support confirms the new settings, allowing for in-flight mail and cached keys.
• Revalidate and check new messages from every affected stream.

SAP explicitly notes that older or custom setups can produce validation warnings while still authenticating. Investigate the specific warning rather than deleting working records. If TTLs were reduced for a planned migration, restore the approved values afterward. SAP legacy migration sequence.

Verify public DNS and receiver authentication

These are read-only example queries, not records to publish. Substitute the domain and selectors from your exported table:

dig +short NS example.com
dig +short TXT email.example.com
dig +short CNAME key5._domainkey.email.example.com
dig +short CNAME key6._domainkey.email.example.com
dig +short CNAME bounces.email.example.com
dig +short TXT bounces.email.example.com
dig +short MX email.example.com
dig +short TXT _dmarc.email.example.com
dig +short TXT _dmarc.example.com

Confirm expected aliases and the public keys they resolve to, a valid single SPF policy at the identity being evaluated, the applicable DMARC policy and the intended MX service. Compare an authoritative answer with a public resolver if caches differ. For example, use dig @AUTHORITATIVE_NS CNAME key5._domainkey.email.example.com with the real nameserver substituted, then repeat against @1.1.1.1. Do not fix stale cached answers by repeatedly changing correct records.

SAP documents a controlled campaign test under Channels → Email Campaigns → Create Email → Email Settings, using the specific From address being validated. An authorized operator should send to a mailbox they control, open the delivered source and check authentication; SAP also recommends confirming reply reception. Repeat through transactional sending if it has a different configuration. SAP's delivered-message test procedure.

Use the receiving system's trusted Authentication-Results. Record the message ID, UTC time, stream and these observations:

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

• Branded DKIM: dkim=pass for the intended From domain. Confirm the signature's d= and s= and the published selector. For this documented Emarsys route, expect strict alignment, meaning an exact signing-domain match.
• SPF: spf=pass for the actual smtp.mailfrom identity, then determine whether it is relaxed-aligned, strictly aligned or deliberately unaligned.
• DMARC: dmarc=pass for the intended header.from.
• Routing: expected bounce handling, working links and replies reaching the intended destination.

An unrelated provider signature does not satisfy branded-DKIM acceptance. Nor does a DMARC pass excuse a failed intended DKIM signature simply because aligned SPF rescued the result. DKIM identity and selector verification, trusted authentication results.

Troubleshooting

Documentation and verification limits

No customer account, DNS zone, Support activation, test campaign, delivered message or inbox placement was exercised. This guide requires tenant-specific implementation and validation; it does not guarantee delivery or rankings.