Choose a sender domain with an explicit boundary
Copernica documents sender domains as a required part of its sending setup. Its quick guide uses Marketing Suite to select a mailing domain and obtain a generated list of DNS records. Start with the exact account and mailing route, not a generic list of records associated with the vendor name. The documentation also explains that Marketing Suite sender-domain settings take priority when Publisher is used, so the team should identify which configuration governs the intended mail.
Decide whether the route will use the organization's main domain or a dedicated subdomain. The advanced sender-domain guide discusses both choices and highlights the additional care needed around existing main-domain settings. A subdomain can reduce overlap with established infrastructure, but it is not automatically unused, risk-free or exempt from inherited policy. Check existing dependencies before treating it as a clean boundary. Quick sender-domain guide; Sender domains
Read the generated DNS plan by function
When a sender domain is created, Copernica documents generating records on its infrastructure and listing the required customer-side DNS configuration in Marketing Suite. The guide describes functions including click and open tracking, bounce handling, DKIM signatures, SPF authorization and DMARC reporting. These are distinct dependencies, even when the interface presents them together.
For each proposed record, retain the owner name, type, target or value, and its intended function. Identify which values are aliases to provider-managed records and which are TXT policy content. Do not infer that every listed function uses an identical record type. The separate SPF documentation is important because it describes a TXT include mechanism rather than treating SPF as just another interchangeable alias.
Avoid copying values from another sender domain or account. The generated plan should remain associated with its source account and review date. The public documentation supports the workflow, but it is not a substitute for the specific plan the organization will actually authorize. The DNS records; SPF
Understand the provider-managed dependency
Copernica explains that customer-side aliases point to records it manages, allowing provider-side changes such as DKIM rotation or sending-infrastructure updates without requiring every customer to change the corresponding alias. This is a dependency model, not a transfer of control over the entire customer zone. Record exactly which DNS names depend on the provider and who owns their lifecycle.
The practical benefit comes with an ongoing responsibility: inventory the aliases, retain the account relationship, and review them when the service is replaced or the sending domain is retired. Do not remove a DKIM alias solely because a campaign is paused; active routes or queued mail may still depend on the configuration. Conversely, do not leave unmanaged vendor dependencies indefinitely after offboarding.
A vendor-managed target does not guarantee that every future DNS state will remain correct. Monitoring, change review and a documented retirement plan are still organizational responsibilities. This manuscript proposes those controls without claiming that any customer's records were inspected or modified. Provider-managed DNS explanation
Place SPF at the appropriate identity
The SPF documentation distinguishes the bounce subdomain used by Copernica from the organization's main domain. It describes using an include in a TXT SPF policy for the relevant configuration. Do not automatically merge an assumed Copernica mechanism into the root domain simply because the visible From address uses that domain. First identify the actual envelope identity and the account-issued DNS plan.
SPF evaluates SMTP identities under its own rules. An include mechanism invokes another SPF policy during evaluation; a CNAME is a DNS alias. They are not the same protocol operation, even if both create an external dependency. The distinction matters for troubleshooting, record coexistence and SPF evaluation limits.
If a policy already exists at the relevant owner name, review it as one complete policy instead of adding a second competing SPF record. Preserve other authorized sources and evaluate the applicable DNS-dependent terms. The retained provider page contains illustrative names, so use actual generated values rather than deriving a copyable configuration from an example. Copernica SPF; RFC 7208, section 2.4; RFC 7208, section 3.2; RFC 7208, section 4.6.4
Review DMARC before accepting a bundled change
The advanced guide specifically calls attention to possible DMARC conflicts when a main domain already has mail infrastructure. Treat an existing DMARC policy and reporting arrangement as an organization-wide dependency. A new sender-domain package should not silently replace established reporting destinations or change policy for unrelated senders.
The proposed review is to compare the intended visible From domain, expected signing domain and envelope identity with the applicable alignment settings. A provider-managed key can validate successfully while a differently branded From domain does not align. Equally, a working DKIM path does not prove that a newly introduced SPF path has been configured at the correct owner name.
If the generated plan and existing policy cannot be reconciled safely, hold the change for the domain owner and provider to clarify. Do not solve the conflict by weakening policy without an approved decision. Authentication results also do not establish message legitimacy, recipient consent or guaranteed delivery. Subdomain or the main domain?; RFC 9989, section 4.4
Acceptance worksheet for the managed sender domain
Use this proposed worksheet to keep the generated configuration accountable throughout its lifecycle.
- Scope: identify the Marketing Suite account, Publisher dependency if relevant, sender domain and mailing categories.
- Existing use: record current DNS owners, active email routes and any shared-domain policy before proposing changes.
- Generated plan: retain each exact record with its function, account association and provider-managed dependency.
- SPF identity: record the intended envelope or bounce domain and the complete policy review at that name.
- DMARC compatibility: identify the existing policy owner, reporting dependencies and alignment assumptions.
- Verification: retain provider status separately from authoritative DNS evidence and an authorized received-message sample.
- Retirement: name the service owner responsible for queued-mail review, alias removal and post-offboarding validation.
This worksheet is an original operational proposal. It is not an executed DNS inspection, a completed sender-domain configuration or evidence that any generated record has been accepted.
Fictional diagnosis: a root-policy change that did not help
A fictional retailer creates a newsletter sender domain in Marketing Suite. Its DNS administrator sees an SPF reference in the documentation and proposes changing the root domain, although the generated plan identifies a separate bounce subdomain. Meanwhile, the root domain already supports several unrelated business applications.
The reviewer pauses the root change and maps every generated record to its function. The proposed investigation checks the actual envelope identity and the relevant TXT policy rather than treating the visible From address as the SPF lookup name. It also preserves the existing DMARC reporting arrangement while reviewing the new route's alignment. The team has not proved success merely by correcting the plan; it still needs authorized publication and message evidence. This fictional example illustrates a boundary error and does not report a real Copernica incident.