Confirm the CMS deployment before choosing instructions
Optimizely CMS creates application messages, but the configured transport sends them. Start by recording the CMS version, hosting model, environment and mail integration that handles the affected workflow. A CMS running on DXP, a self-hosted installation and an application with its own third-party relay cannot be assumed to share one SPF or DKIM configuration. Optimizely Campaign is a separate product and its marketing-mail domain records must not be borrowed for CMS notifications.
The first-party DXP email-server page retrieved for this guide is labeled DXP for CMS 12 and Commerce 14. It documents a cloud transactional email service, a SendGrid-backed SMTP configuration and a support-assisted domain-authentication process. This article uses that route as its concrete implementation branch. Applicability to another CMS version, hosting tier or custom integration requires the corresponding current documentation and deployment evidence. The general catalogue label Optimizely CMS is broader than the established configuration scope here. DXP email-server configuration
Before editing configuration, name the application owner, deployment operator, mail administrator and DNS owner. Agree which workflow will demonstrate success: a project notification, a content approval message or another explicitly configured application email. Use synthetic content and a controlled recipient. A marketing newsletter is not an appropriate substitute for a CMS notification test simply because both products carry the same vendor name.
Trace the message from application event to relay
Break the route into event creation, application dispatch, SMTP submission, provider delivery and receiver authentication. Record what evidence is available at each stage. If the application never produces or dispatches a notification, editing SPF cannot create it. If SMTP rejects credentials, the message has not yet reached the stage where the recipient evaluates DMARC.
Optimizely's CMS 13 Projects documentation separately describes notification dispatch and says SMTP settings must be configured for email notifications. This supports checking the trigger and dispatch stage when the actual installation is CMS 13; it does not establish that a CMS 12 deployment has identical job defaults or that the DXP SMTP example applies unchanged. Match configuration instructions to the installed version rather than mixing versioned snippets. CMS 13 project notifications
For every environment, distinguish the effective runtime configuration from a source file that may be overridden during deployment. A staging success can coexist with a production failure caused by a missing setting or a different From address. Collect sanitized settings and application logs through the normal engineering process. Do not expose SMTP credentials, API keys or unrelated production secrets in the evidence packet.
Configure the documented DXP transport through a controlled deployment
The DXP guide says the email configuration is not automatically applied by standard configuration transforms. It describes obtaining the email service credential through the DXP management portal and supplying SMTP settings to the application. Its example includes application notification identity settings as well as transport settings. Use the supported configuration mechanism for the deployed version and environment, and review the resulting effective values. DXP email-server configuration
Treat credential creation, storage and rotation as a separate controlled security operation. This guide does not require a new credential if an approved working credential already exists. Never paste a secret into a public article, repository example, DNS record or support screenshot. Reference the approved secret store and responsible operator instead. Confirm that deployment logs and error reporting do not print the credential when testing.
The documented DXP service is for automated transactional website communication. The guide directs customers needing other SendGrid capabilities, such as their own custom HTML-template use, toward a separately subscribed account or another SMTP provider. Confirm the intended use rather than assuming that access to DXP SMTP is unrestricted access to a customer-managed SendGrid account. A separate account has its own ownership and domain-authentication procedure.
Request authentication for each sending domain
For the documented DXP route, contact Optimizely with the sending domain for assistance activating Sender Authentication. The same guide says DKIM must be requested for each mail-send-domain and requires additional DNS records. Obtain the exact record set and activation plan for the environment before publishing anything. No universal selector, CNAME target or private key can be derived from the product name. DXP domain and DKIM configuration
List every visible From domain used by the relevant notifications. If multisite applications or separately configured workflows use different domains, ask support which authentication configuration covers each one. Do not assume that verifying the primary corporate domain automatically activates every subdomain or alternate brand. Record who must confirm sender-side activation after DNS publication.
The DXP page includes sample SPF policies. Treat them as documentation examples, not complete prescriptions for a production domain. Determine the actual envelope owner, preserve other authorized senders and maintain one valid SPF policy there. Evaluate recursive lookup limits before merging authorization. If the configured transport differs from the documented DXP service, obtain that transport's own current instructions instead. SPF RFC 7208
Publish each supplied DKIM record at the exact owner with the supplied type. Preserve active selectors during a planned transition, resolve CNAME conflicts before saving and keep private keys outside DNS. Query the authoritative servers to verify the resulting name and value; a DNS editor preview is not enough. A public record supports validation only when the actual outgoing message uses its corresponding signing identity. DKIM RFC 6376
Keep sender identity and DMARC policy coordinated
Agree the intended visible From address before the test. A correct SMTP hostname and working credential do not prove that the application uses the approved From domain. Record the effective notification identity and any application-level override separately from the transport configuration. Review reply handling so recipients are not directed to an unattended mailbox without a business decision.
Inspect the current DMARC policy for the visible domain and retain its approved enforcement, alignment and reporting configuration. DMARC succeeds when at least one passing SPF or DKIM identity aligns under the applicable mode. A provider-owned signing domain can pass cryptographic validation without aligning with the organization's visible From domain. Do not respond by weakening the whole domain's policy before examining the supported sender-authentication route. DMARC RFC 9989
Application connectivity, provider authentication and inbox placement are separate acceptance results. A CMS log that says a message was submitted is not a receipt from the final mailbox. A received message with passing DMARC may still be filtered for other reasons. Retain these distinctions in the change report so that one successful layer does not hide an unresolved problem elsewhere.
Reusable CMS and DXP route worksheet
Complete a separate copy for each deployment environment and materially different sending identity.
- CMS version, hosting model, project and environment: ______.
- Exact workflow, synthetic trigger and expected recipient: ______.
- Configuration source, deployment revision and effective runtime settings: ______.
- Transport provider, account owner and approved secret reference only: ______.
- Visible From, display name, reply destination and envelope expectation: ______.
- Support case confirming DXP applicability and each sending domain: ______.
- Issued DNS owners, types, values and activation requirements: ______.
- Existing SPF and DMARC policies and approved change set: ______.
- Authoritative answers, query times and provider verification status: ______.
- Dispatch, SMTP submission and provider delivery evidence: ______.
- Received-message From, envelope, all DKIM d=/s= pairs and trusted results: ______.
- Rollback deployment, DNS restoration plan and human acceptance: pending.
Fictional diagnosis of a production notification failure
This example is fictional. A team successfully tests an approval notification in staging and deploys the application. Production messages use a different visible From domain. SMTP submission succeeds, but an independent receiver reports a valid provider signature that does not align with that production domain. The team proposes copying a Campaign DKIM target into DNS because it also belongs to Optimizely.
The proposed diagnosis compares the effective production identity with the domains covered by the DXP support request. In this scenario, only the staging identity was included. The corrective plan is to request the supported authentication configuration for the production sending domain, publish the issued records and retest the actual approval workflow. Borrowing a Campaign record would not establish that the DXP signer uses it. This is a worked example, not a live test or an assertion about any customer deployment.
Recover at the layer that changed
If the application stops submitting messages, compare the deployment and transport settings before reverting DNS. If domain verification fails, compare the support-issued owners with authoritative answers. If authentication passes but delivery fails, inspect the provider and recipient responses without broadening sender permissions unnecessarily. Preserve evidence before retries so duplicate notifications can be identified.
Rollback should restore the narrowly affected deployment or DNS change, not rotate every credential or reset the whole zone. Retire superseded selectors only after the mail owner confirms that no active or queued route needs them. The documented DXP branch is established, but broader CMS-version applicability, tenant-specific settings, support-issued values, live DNS, received messages, visual review and human SME approval remain pending. No application configuration, credential, DNS record or live workflow was changed for this guide.
Keep transport security out of copied examples
The public page mixes configuration-file examples and includes an SSL-disabled code setting. This article does not approve that setting or a version-mismatched snippet. Have the deployment owner confirm the supported transport and TLS behavior for the actual runtime without exposing credentials. In the fictional case, the provider signature alone does not determine the unspecified SPF result.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.