Optivo Marketing SPF, DKIM and DMARC setup, step by step

For a confirmed current Optimizely Campaign client, configure SPF on its technical return-path domain using the documented include:spf.srv2.de, publish the two documented DKIM CNAME owners pointing to dkim.srv2.de, and complete domain verification through self-service or Support. Preserve the domain's existing DMARC policy and verify an actual campaign message for branded, aligned DKIM and dmarc=pass. If your records say only Optivo, first confirm that this is the supported route for that account. Campaign domain setup, Domain Management.

No legacy tenant, customer DNS configuration or delivered message was tested for this guide.

On this page

• Confirm the legacy account and current route
• Map the domains before changing DNS
• Publish the confirmed Campaign records
• Complete Campaign verification and activation
• Check SPF and DKIM without weakening other senders
• Preserve DMARC and reporting controls
• Validate public DNS and received messages
• Troubleshooting and safe recovery
• Frequently asked questions

Confirm the legacy account and current route

A historical Optivo label does not establish a current account's settings. Obtain the tenant URL, client identifier, contracted product, sending workflow and account owner. Ask Support to confirm which current domain-onboarding instructions apply before replacing legacy records.

There is a concrete reason older labels can remain visible: current Campaign documentation describes a Shopware integration using optivo broadmail fields while Campaign assembles and sends the transactional message. That documented integration does not prove every old Optivo account migrated or uses the same configuration. Campaign transactional-mail integration.

If the account cannot be linked to the current Campaign route, stop before DNS changes and obtain the supported legacy procedure. Do not infer selectors or activation from another customer's message. This guide's executable branch begins only after current Campaign applicability is confirmed.

Optimizely CMS application notifications are a different task. The CMS on DXP authentication guide covers its managed SMTP route. Do not mix that service's SendGrid records with Campaign's domain setup.

Map the domains before changing DNS

Use one worksheet per sending client and brand. Record:

Campaign's technical subdomain carries delivery handling and tracking functions. A working tracking link does not prove DKIM; a working reply address does not prove SPF. Campaign authentication roles.

Use a dedicated, approved technical name. Do not repurpose an existing website or mailbox domain without checking its dependencies. Campaign calls this process DNS delegation, but its documented record-based setup does not require you to change the parent domain's nameservers. If Support proposes an actual NS delegation, separately review its scope, existing records and rollback plan.

Publish the confirmed Campaign records

The following is the vendor's documented example, not a discovered configuration for your account. Here the visible sender domain is example.com and the approved technical subdomain is t.example.com. Substitute the actual domains, and reconcile the complete table with your current client instructions before saving.

The verification code must come from the actual Campaign interface. The official setup also shows a DMARC example; do not copy it over an existing or inherited policy. Handle that separately below. Optimizely recommends TTL 900 seconds for these records, but a new TTL does not erase earlier caches or guarantee worldwide visibility in 15 minutes. Complete official record table.

Enter names in the correct authoritative zone

For the same example, these are the relative Name/Host fields when the DNS editor appends its zone automatically:

Use complete names only if your DNS editor expects them. Confirm the final public owner, not just its input-field label. Do not create t.example.com.example.com. If t.example.com is already delegated, records in an inactive parent-zone copy will not control the child's answers.

A, MX and TXT can coexist at the technical owner in this documented design. A CNAME cannot be added there alongside those records. The DKIM CNAMEs belong at their selector owners, not at t.example.com itself. Resolve existing selector conflicts with Support; do not delete another active sender's record. DNS CNAME rules.

Keep authentication and ownership-verification CNAMEs DNS-only. Disable flattening for those names where supported so the expected aliases remain visible. Do not substitute copied target IPs or a public key obtained from a third party. CNAME verification pitfalls.

Complete Campaign verification and activation

Where Self-Service domain management is enabled and you have domain-management permission:

1. Open Administration > Domains.
2. Choose Add Domain..., enter the approved sender domain and technical subdomain, and copy the generated ownership CNAME.
3. Add the domain, publish the full approved record set and the generated verification CNAME.
4. Select the domain and click Check Domain Config.
5. Review Configuration Status and resolve every relevant issue before using the domain.

Campaign permits adding a domain before delegation is complete, but it cannot be used until the prerequisite configuration is in place. If self-service or permissions are unavailable, use Support-assisted domain setup and obtain confirmation that the intended client/domain is ready to send. Do not invent a universally available activation toggle. Official Domain Management procedure.

Verification is domain-level evidence, not proof of every campaign's From setting. Check the actual message configuration and run the production-workflow acceptance test. A status from another client, brand or technical subdomain does not cover this one.

Check SPF and DKIM without weakening other senders

SPF belongs at the SMTP MAIL FROM domain, which Campaign documents as its technical return-path domain. Do not place spf.srv2.de only at the corporate apex and assume it authenticates t.example.com; SPF is not inherited. The From and Reply-To headers do not choose the SPF owner. Campaign SPF and DKIM requirements, SPF identities.

At each affected owner, keep one SPF policy. If a legitimate policy already exists, merge the required mechanism before its terminal all, preserving authorized senders and the approved qualifier. Do not insert a second v=spf1 string or a second SPF TXT record. If the technical domain has unexpected existing use, resolve ownership before changing it rather than blindly merging incompatible routing.

Evaluate nested includes and redirects against SPF's limit of ten evaluated DNS-querying terms: include, a, mx, ptr, exists and redirect. Additional MX/address and void-lookup limits apply. ip4, ip6 and all do not consume that term budget. Fix excessive or invalid dependencies with the mail owner; do not replace the maintained Campaign include with a one-time IP snapshot. RFC 7208 limits, SPF lookup-limit guide.

The documented DKIM owners include selector mailing. Both DNS records are required by the published setup, but do not infer that every message necessarily carries two signatures. Inspect the actual d= and s= values. Acceptance requires a valid signature for the intended branded domain, not merely any passing provider signature. Never publish private signing material. DKIM identity and selector semantics.

Preserve DMARC and reporting controls

Campaign requires SPF and DKIM onboarding and documents default identifier alignment. Those product requirements are distinct from DMARC's message-level rule: one passing aligned SPF or DKIM identity is sufficient for DMARC pass. Strict alignment requires exact domain equality; relaxed alignment allows the same organizational domain. Inspect the actual policy rather than assuming every client uses relaxed defaults. Campaign DMARC guidance, RFC 9989 alignment.

Before creating a record, check _dmarc for the visible From domain and the applicable ancestor policy under RFC 9989's DNS tree walk. Preserve existing p, sp, alignment and approved reporting settings. An absent exact-domain record can still mean inherited enforcement. Do not insert a weaker child policy to make a campaign pass.

Only if there is no applicable policy, a monitored reporting mailbox is ready, and the policy owner approves a first monitoring phase, this example is suitable for review:

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

If the actual From domain is news.example.com, its exact record would instead be _dmarc.news.example.com: enter _dmarc.news in the parent zone or _dmarc in delegated zone news.example.com. Do not publish at _dmarc.t.example.com merely because t is the technical domain when From is example.com.

Approve any external reporting recipient and its data handling before using it. For a policy at example.com with reports sent to reports.example.net, the report receiver must authorize the relationship at example.com._report._dmarc.reports.example.net with TXT v=DMARC1. Use the policy domain actually discovered when constructing this authorization. Avoid forensic reporting by default. RFC 9990 reporting authorization.

Do not copy the vendor page's historical percentage rollout: current RFC 9989 removed pct. Enforce only after reviewing all legitimate senders and indirect flows. Domains publishing p=reject must apply valid DKIM rather than relying on SPF alone. Current DMARC interoperability guidance.

Validate public DNS and received messages

Replace the example names and uppercase nameserver placeholders before running these read-only checks. Use the child zone's nameserver for t.example.com if it is separately delegated, and the parent zone's for the visible-domain selector.

dig @TECHNICAL_ZONE_NS t.example.com A +noall +answer
dig @TECHNICAL_ZONE_NS t.example.com MX +noall +answer
dig @TECHNICAL_ZONE_NS t.example.com TXT +noall +answer
dig @TECHNICAL_ZONE_NS mailing._domainkey.t.example.com CNAME +noall +answer
dig @SENDER_ZONE_NS mailing._domainkey.example.com CNAME +noall +answer
dig @TECHNICAL_ZONE_NS VERIFICATION_CODE.t.example.com CNAME +noall +answer
dig mailing._domainkey.example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answer

Skip the token query if self-service verification is not used. Compare A, MX, SPF and CNAME answers with the current account-approved table. Follow DKIM CNAMEs to a usable public key and verify the actual selected DMARC policy, including ancestors where necessary. Repeat through a recursive resolver after relevant caches expire. SERVFAIL, an empty result or a correct-looking record in the wrong zone is not a pass.

After Campaign verification, send a harmless message through the real campaign or integration to a controlled external recipient. Inspect its raw source. Use only Authentication-Results added by that receiver or its trusted inbound security system; an earlier untrusted header is not proof. Receiver-result provenance.

Record visible From, actual MAIL FROM/Return-Path, all DKIM d=/s= pairs, independent outcomes and alignment. Require the intended branded signature to show dkim=pass, align under the applicable policy, and produce dmarc=pass. Record SPF too: a nonaligned SPF pass differs from fail, permerror or temperror, which require investigation even if DKIM carries DMARC.

Test newsletters, opt-in messages and materially different transactional paths separately. In the documented Shopware integration, Campaign constructs the final email from supplied variables; a successful API call is not a received-message authentication test. Verify bounce routing, expected reply handling and tracking separately without sending real purchases or sensitive transaction details. Transactional-mail architecture.

Troubleshooting and safe recovery

Pause only affected sends where practical. Preserve the current records, status, raw message and timestamp, then restore the narrowly approved before state if rollback is required. Do not delete a legacy selector simply because it has an old name. Active clients or queued messages may depend on it.

Removing a domain from Campaign's list is not a reliable emergency stop: the vendor notes that campaigns already Activated or Sending can continue using it. Stop the affected campaign through its supported controls and coordinate with Support. Domain-removal behavior.