Optimizely CMS SPF, DKIM and DMARC setup, step by step

For Optimizely CMS on the documented DXP CMS 12/Commerce 14 route, configure the application's approved SMTP transport, then request Sender Authentication and DKIM for each sending domain from Optimizely Support. Publish the records supplied for your deployment, confirm activation, and test a real notification for branded, aligned DKIM and dmarc=pass. Do not use Optimizely Campaign's srv2.de records for this SendGrid-backed DXP route. Optimizely DXP email configuration.

This guide describes a reader-run implementation; no customer account, DNS configuration or delivered message was tested.

On this page

• Choose the correct CMS sending route
• Prepare the deployment and identity worksheet
• Configure transport and request domain authentication
• Handle SPF without disrupting other senders
• Publish DKIM at the right DNS owner
• Preserve or introduce DMARC safely
• Verify DNS and an actual notification
• Troubleshoot and recover
• Frequently asked questions

Choose the correct CMS sending route

The CMS creates the notification; its configured mail transport delivers it. Identify the installed version, hosting model and effective production relay before choosing DNS records.

The current DXP guide is explicitly labeled CMS 12 + COM 14. CMS 13 has its own Projects and notification documentation. An old Episerver brand label, a common vendor logo or a working newsletter does not identify the application notification transport.

Prepare the deployment and identity worksheet

Bring together the application operator, DNS administrator and domain-policy owner. Save the effective settings and DNS before state, not only the configuration committed in source control. Environment overrides can change the running From address or relay.

Record these fields for each environment and brand:

• CMS version, DXP project, environment and deployment revision.
• Notification event, dispatch mechanism and controlled test recipient.
• Approved visible From address and monitored reply destination.
• SMTP provider, account owner and approved secret-store reference, never the secret itself.
• Actual or Support-confirmed SMTP MAIL FROM/Return-Path domain.
• Intended DKIM signing domain, selector and supplied DNS record set.
• Authoritative DNS zone, any separately delegated child zone and change owner.
• Existing SPF, DMARC policy, reporting recipients and rollback plan.

Choose a representative workflow, such as a content-approval notification. A preview or direct SMTP utility send may help isolate a fault but does not prove the application's production workflow is correct. Use synthetic content and avoid placing personal information or credentials in diagnostic screenshots.

Configure transport and request domain authentication

The DXP service supports automated transactional website email. Its documented route uses smtp.sendgrid.net, port 587, and a SendGrid credential available through the DXP management portal's project API tab. Email settings are not automatically applied by standard configuration transforms. Use the installed runtime's supported configuration mechanism and approved secret storage. DXP transport procedure.

Do not paste the documentation's mixed web.config, appSettings.json and code examples into an arbitrary runtime. In particular, an example containing UseSsl = false is not approval to disable transport protection. Have the deployment owner confirm supported TLS behavior and effective runtime settings. Do not regenerate a working credential merely to follow an example.

Then complete the authentication handoff:

1. Give Optimizely Support the intended sending domains and the DXP project/environment through your approved support channel.
2. Request Sender Authentication and DKIM for every mail-send-domain involved.
3. Obtain a complete type/owner/value/TTL worksheet, intended envelope and DKIM identities, and the activation sequence.
4. Publish only the approved records in the correct authoritative zones.
5. Ask Support to verify publication and confirm sender-side activation.
6. Trigger the actual notification and inspect independent receiver results.

Support involvement is the documented workflow. A universal DXP selector, fixed record count or customer-specific CNAME target is not published in that procedure. Do not generate your own DKIM key or access an assumed standalone SendGrid account. Uses beyond the DXP SMTP service may require a separately subscribed service with its own setup. Domain authentication and service boundary.

Handle SPF without disrupting other senders

The DXP documentation gives include:sendgrid.net as its SPF authorization example. Treat it as a mechanism to reconcile with the Support-issued configuration, not a complete policy to overwrite your domain with. If the supplied setup manages the envelope through CNAME records, ask Support which DNS owner supplies SPF; do not add TXT data at a CNAME owner.

SPF evaluates the SMTP MAIL FROM domain. Adding an include to the visible From domain cannot repair a different provider-owned envelope identity. SPF does not inherit from parent domains. Determine the actual envelope owner before editing. SPF identities and record selection.

Where a customer-managed TXT edit is required:

• Edit the one existing v=spf1 policy at that owner. Preserve legitimate senders and its approved terminal qualifier.
• Insert the approved mechanism before all. Do not paste two complete policies together or publish another SPF TXT record.
• Evaluate the complete recursive policy. The maximum is ten evaluated DNS-querying terms using include, a, mx, ptr, exists and redirect, including nested processing. It is not ten visible includes or ten DNS packets.
• Account for the additional MX expansion and void-lookup limits. ip4, ip6 and all do not consume the term budget.
• If the budget is exceeded, remove only confirmed obsolete authorization or redesign with the mail owner. Do not take a one-time snapshot of SendGrid IPs and treat it as a maintained replacement.

RFC 7208 lookup limits and the SPF lookup-limit walkthrough explain this distinction.

Publish DKIM at the right DNS owner

For each Support-issued DKIM record, preserve the exact type and target or public key. A selector is part of the DNS owner, not the From address. Its lookup name is SELECTOR._domainkey.SIGNING_DOMAIN. Publishing that name is only one half of setup: the sender must use the matching private key. DKIM key lookup.

The following is a name-entry example, not a DXP-issued selector. Assume Support supplied the owner SUPPLIED_SELECTOR._domainkey.notify.example.com:

If the DNS editor accepts complete names, follow its documented input convention. Check the resulting owner for a duplicated suffix. A record placed in an inactive parent-zone copy of a delegated child will not answer publicly.

For CNAMEs, resolve any existing same-name record conflict before saving. Do not delete another sender's active selector to make room. Use DNS-only mode and disable flattening for these verification/signing CNAMEs where supported; verify the CNAME remains publicly visible. For TXT keys, preserve the full public p= value and never publish a private key. Cloudflare's CNAME verification guidance.

Preserve or introduce DMARC safely

DMARC compares the visible From domain with a passing SPF MAIL FROM identity or a passing DKIM d= identity. Either aligned path can produce DMARC pass. Relaxed alignment permits the same organizational domain; strict aspf=s or adkim=s requires the relevant domains to match exactly. A provider signature can pass cryptographically while remaining unaligned. Current DMARC standard, RFC 9989.

Inspect _dmarc at the exact From domain and the applicable ancestor policy discovered under RFC 9989. Preserve existing enforcement, alignment and reporting settings. No exact-domain record does not mean no policy applies. Do not create a weaker child policy that overrides inherited protection.

Only when no applicable policy exists, the domain owner approves monitoring, and a reporting mailbox is ready, a first-policy example for From domain notify.example.com is:

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

In zone example.com, the relative owner is _dmarc.notify; in delegated zone notify.example.com, it is _dmarc. Replace the domain and mailbox with approved values. This is not an instruction to replace an established policy. For an apex From domain of example.com, the full owner is _dmarc.example.com; enter _dmarc in zone example.com when the editor appends the zone suffix.

If aggregate reports go to an external organization, approve that recipient and its data handling first. The reporting service must publish the required external-destination authorization. For a policy at notify.example.com and destination reports.example.net, the authorization owner is notify.example.com._report._dmarc.reports.example.net, with TXT v=DMARC1. Do not add forensic reporting by default. RFC 9990 external reporting.

Review all legitimate senders and indirect routes before enforcement. RFC 9989 removes the old pct rollout tag and requires valid DKIM for domains publishing p=reject; SPF-only success is not enough to approve that rollout. Policy interoperability.

Verify DNS and an actual notification

Run these read-only commands after replacing uppercase placeholders with the Support worksheet values. Obtain the authoritative nameserver for the zone that actually owns each record, including delegated children.

dig +short NS AUTHORITATIVE_ZONE
dig @AUTHORITATIVE_NAMESERVER SPF_OWNER TXT +noall +answer
dig @AUTHORITATIVE_NAMESERVER DKIM_OWNER CNAME +noall +answer
dig DKIM_OWNER TXT +noall +answer
dig @AUTHORITATIVE_NAMESERVER _dmarc.FROM_DOMAIN TXT +noall +answer
dig SPF_OWNER TXT +noall +answer

Query TXT directly at the DKIM owner if Support issued a TXT key. For CNAME-based DKIM, verify both the exact alias and the public key reachable through its target. The final recursive queries help expose stale caching; they are not a substitute for authoritative answers. An empty response, NXDOMAIN or SERVFAIL needs diagnosis, not a success label. Compare TTLs and retry after the relevant cache lifetime rather than assuming a fixed propagation period.

After Support confirms activation, trigger a fresh notification in the intended environment. Save the raw message at an independent controlled mailbox. Trust only authentication results added by that receiver or its known inbound security service within its trust boundary. Arbitrary earlier Authentication-Results headers can be forged. Authentication-Results trust boundaries.

Accept the route only when you can record:

1. The correct application event, environment and expected visible From.
2. The actual envelope domain and SPF result, with any SPF error investigated.
3. dkim=pass for the intended branded d= domain and the expected selector, aligned under the applicable mode.
4. dmarc=pass for the visible From domain.
5. The expected recipient, reply behavior and a trace from application dispatch to final receipt.

A DMARC pass obtained solely through SPF does not close a requested DKIM setup. Conversely, a documented nonaligned SPF pass can coexist with aligned DKIM and DMARC pass. Repeat for production, alternate brands and materially different notification paths. Authentication does not guarantee inbox placement.

Troubleshoot and recover

On failure, pause the affected rollout and preserve sanitized logs, DNS answers and headers. Restore only the approved configuration or record change that caused the regression. Keep old selectors available while queued messages or active routes may need them. Never roll back by removing unrelated sender authorization or weakening the whole domain's DMARC policy.