Confirm what the Optivo name means in this account
An inventory entry labeled Optivo Marketing is not enough to select current DNS instructions. Optimizely's acquisition announcement establishes the historical relationship between Optivo and Episerver. Current Optimizely Campaign integration documentation also retains optivo broadmail labels in a specific Shopware workflow. These sources support a product lineage and explain why a legacy name may still appear, but they do not prove that every account described as Optivo Marketing uses the same current tenant, interface or domain configuration. Optivo acquisition announcement Campaign transactional-mail integration
Begin with the tenant URL, contracted service, account owner, client identifier and actual send path. Obtain a current support confirmation linking the legacy account to the applicable Campaign documentation. If that relationship cannot be established, stop before publishing new provider records. The useful work at that point is a route inventory and an evidence request, not an invented Optivo setup.
This guide therefore describes a conditional Campaign implementation after identity confirmation. It does not silently substitute a successor product for an unverified legacy service. No legacy tenant was accessed for this article, and the account-specific mapping remains an explicit scope hold. Keep that limitation visible in the change ticket and in any implementation estimate.
Map the visible sender and technical return path
For a confirmed Campaign route, separate the visible From domain from the technical return-path domain. The current authentication guide places SPF on the technical return-path domain and describes DKIM CNAME records associated with both the technical and visible sending domains. Capture the actual domains and complete owner names from the tenant's supported setup rather than constructing them from the guide's examples. Campaign email authentication
The visible From is what recipients see. The SMTP envelope identity is used for bounce handling and SPF evaluation. DKIM signs with a domain and selector recorded in the message. These identities can be related without being identical. A tracking link, landing page or image hostname is another separate domain role and does not prove the message is authenticated.
Inventory each campaign client, brand and sending workflow. Newsletters, opt-in messages and transactional integration traffic may need separate test rows even when they share infrastructure. Record which system constructs the content, which initiates the send and which service performs final delivery. An API request accepted by an integration is not equivalent to a message received with aligned authentication.
Obtain the current domain setup before publication
Ask support or the authorized account administrator for the current domain configuration associated with this client. The record set should identify the technical return path, visible sender domain, selectors, exact record types and values, any delegated zone boundaries, and provider-side verification or activation steps. Ask who controls each DNS zone and which changes are prerequisites rather than optional branding features.
The current Campaign guide publishes general SPF and DKIM examples, but a CNAME target alone does not establish the required owner or selector for an unknown legacy account. This article intentionally omits copyable DNS values. Do not infer the record owner from another customer's mail, reuse historical screenshots or combine records from Campaign and Optimizely DXP. Each instruction must correspond to the confirmed sending route.
If the plan involves delegation, establish precisely what is delegated. Moving nameservers for a subdomain can transfer control over more than a single email-authentication record. Capture existing website, verification and mail dependencies within that boundary. Do not repurpose a live subdomain without checking those dependencies and obtaining approval from its service owner. A record-level CNAME and a nameserver delegation have different operational scope.
Preserve SPF and DKIM ownership during the change
At each evaluated SPF owner, inspect the existing policy and other authorized senders. Merge only the authorization required by the confirmed route, preserving one candidate policy and the approved treatment of other sources. Evaluate includes and redirects against SPF's lookup limits. An SPF record at the corporate apex does not automatically apply to a separately evaluated technical return-path domain. SPF RFC 7208
For DKIM, preserve the exact selector and signing-domain relationship in the issued instructions. Resolve existing records at each owner before publishing CNAMEs. If another sender owns a conflicting selector, coordinate a supported alternative or transition rather than deleting the old key. Keep private signing material with the signing service; DNS contains only public validation data or delegation. DKIM RFC 6376
Save the complete before state and verify the after state at authoritative DNS. Check the intended fully qualified owner rather than the label shown in a management screenshot. Record which administrative surface controls future changes: a DNS provider, a delegated zone, or the Campaign service. If these responsibilities are unclear, leave activation pending rather than declaring that propagation is the only remaining step.
Evaluate alignment under the actual DMARC policy
Campaign's DMARC guide describes default identifier alignment and recommends checking received messages. Treat that as the documented product design, not evidence that a particular legacy account, customized sender domain or newly changed workflow currently aligns. A passing authentication result must be compared with the visible From domain under the domain's actual alignment settings. Campaign DMARC implementation
DMARC can succeed through at least one passing aligned SPF or DKIM path. It does not require both paths to pass simultaneously. Strict alignment requires matching domain identities; related subdomains should not be assumed to satisfy it. Use the current DMARC specification to interpret policy discovery and alignment, especially where a provider overview simplifies those rules. DMARC RFC 9989
The provider recommends an enforcement policy, but that recommendation does not authorize an immediate domain-wide policy replacement. Inventory legitimate senders, inspect the existing policy and agree a controlled rollout with the domain owner. Preserve approved report recipients and account for third-party report processing. Reports provide additional observations over time; their absence is not proof that no authentication failures exist.
Test the actual campaign or integration workflow
After identity confirmation, DNS verification and provider activation, send a controlled message through the workflow that will be used in production. Record the client, campaign or transactional template, trigger, sender identity and timestamp. Use a small authorized test audience with synthetic content. A preview rendering or an integration API success response cannot stand in for independent received-message evidence.
For a Shopware integration that uses the legacy optivo broadmail label, the current documentation describes passing transaction variables to Campaign, where the message is assembled and sent. That is a reason to test the final Campaign delivery, not proof that the shop's own mail server is the outbound signer. Confirm that the actual integration and version match before applying this description. Campaign transactional-mail integration
Preserve the raw received message and the trusted receiving system's authentication results. Record From, envelope, each DKIM d= and s= pair, individual outcomes and DMARC alignment. Test materially different brands and transactional routes separately. Also verify expected bounce and reply behavior without treating successful replies as evidence that SPF or DKIM passed.
Reusable legacy Optivo route worksheet
Use this worksheet to distinguish a verified implementation from a merely plausible successor-product mapping.
- Legacy service label, tenant URL, client identifier and account owner: ______.
- Current product identity confirmed by support, with date and reference: ______.
- Applicable documentation version and unsupported legacy features: ______.
- Workflow type, integration version, trigger and sending client: ______.
- Visible From domain, technical return path and intended DKIM identities: ______.
- DNS host, delegation boundaries and dependent services: ______.
- Issued owner, type and value for every required record: ______.
- Existing SPF and DMARC policies and approved changes: ______.
- Provider verification or activation evidence: ______.
- Authoritative DNS captures and independent message reference: ______.
- Trusted authentication results, alignment mode and outcome: ______.
- Recovery owner, visual walkthrough and human approval: pending.
Fictional diagnosis of a legacy label and a strict policy
This scenario is fictional. A retailer's integration still displays optivo broadmail, but its contract and support response identify the active sending client as Campaign. Its messages pass SPF for a technical subdomain and DKIM for a related domain. A newly enforced strict alignment setting causes the retailer's expected From identity to fail DMARC alignment.
The proposed diagnosis compares the exact domains in the trusted receiver results with the policy's alignment modes. It does not assume that a shared organizational domain is enough under strict settings. The administrator asks Campaign support for the supported identity configuration for the intended From domain, while the security owner reviews whether the strict policy was deliberate. The next step is a controlled message after an approved change, not copying a different product's DNS recipe. This illustrates how to reason about the failure; no actual customer test has been performed.
Recover without losing other campaign dependencies
If the new configuration fails, pause only the affected sends when practical and preserve the provider response, DNS answers and received message. Restore the narrow approved before state when rollback is justified. Do not remove all legacy selectors or delegated records because their names look obsolete; another active client or queued message may still depend on them. Confirm retirement with the account and DNS owners.
The documentary evidence establishes current Campaign concepts and a historical Optivo connection. It does not establish the exact legacy tenant's applicability, issued record set or successful operation. Product mapping, tenant walkthrough, live DNS, real received-message evidence, visual review and human SME approval remain pending. The article is a complete scoped preparation and verification guide, not a claim of completed authentication for every service carrying the Optivo name.
Separate documented onboarding from message evaluation
Campaign’s onboarding guidance calls for both SPF and DKIM configuration. That product requirement is compatible with DMARC evaluating whether at least one passing mechanism aligns on a particular message. Do not confuse a documented default identity design with evidence that an uninspected legacy client follows it.
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.