Copernica SPF, DKIM and DMARC setup, step by step

On this page: Scope: Marketing Suite, Publisher and other Copernica products · Choose the domain boundary deliberately · Generate the sender-domain DNS plan · DKIM: keep managed aliases, not copied public keys · SPF: use the bounce identity and exact generated include · Decide who controls DMARC before accepting the bundle · Validate public DNS and provider readiness · Prove the actual sending identity · Troubleshooting by symptom · Frequently asked questions

Set up Copernica authentication with SENDER DOMAIN in Marketing Suite, then publish the exact DNS plan shown for that domain. The managed workflow uses DKIM CNAMEs and bounce-domain SPF, with optional provider-managed DMARC. Keep an existing DMARC policy unless its owner approves a change, and verify a received message after DNS validation. Sender-domain quick start · SPF guidance.

Scope: Marketing Suite, Publisher and other Copernica products

This guide covers Marketing Suite's managed sender-domain workflow. Copernica documents that these settings take precedence for mail sent through Publisher too. Do not transfer these steps to an independently configured SMTPeter account or MailerQ deployment simply because the products share an organization. Establish the real sending route first. Managed workflow and Publisher precedence.

For a legacy installation without managed sender domains, ask support to confirm the supported migration and current signing path. Do not mix a historical manual-key procedure with today's generated DNS plan. A successful test from one route is not proof that another product, tenant or integration is authenticated.

Choose the domain boundary deliberately

Copernica allows an organizational domain or a subdomain as the sender domain. A dedicated unused subdomain can reduce conflicts with existing office-mail DNS. If using the organizational domain, review shared DMARC dependencies particularly carefully. The provider maintains records behind the published aliases, including changing infrastructure and rotating keys. Sender-domain architecture.

Make this a documented decision rather than a naming preference. A dedicated newsletter From domain changes the identity recipients see; a bounce hostname serves a different purpose. Both can sit beneath the same organization without being interchangeable. Do not move a working brand address merely to avoid understanding its existing policy.

Record your account, intended From domain, actual transport, DNS zone, campaign owner and security approver. Inventory other senders using the same From domain. Back up existing DNS and policies, including inherited subdomain rules. Have access to Marketing Suite, the authoritative DNS service and a controlled recipient mailbox. Permission to view a dashboard does not automatically authorize changing shared DNS or sending reports to a third party.

Generate the sender-domain DNS plan

Open SENDER DOMAIN in the Marketing Suite menu, add the intended domain and retrieve the recommended records. The dashboard identifies the required DNS changes; publish those exact rows with your DNS administrator and resolve any warnings before relying on the configuration. Official setup.

Classify the generated records before approving them:

Copernica explicitly includes an MX record for bounce and out-of-office processing. Compare its exact owner, priority and destination with the separately authorized bounce-routing plan before publishing. Receiving a generated DNS packet does not itself approve routing bounces or out-of-office replies to that destination. Stop on a mismatch; preserve corporate root MX and shared dependencies. Do not substitute a CNAME beside the SPF TXT at that owner. Copernica MX requirements.

The MX page also describes a CNAME workaround for DNS services without MX support. Do not apply it at an owner that must also hold the issued SPF TXT: a CNAME cannot coexist there. Ask Copernica and the DNS owner to resolve the complete record layout rather than substituting records independently.

The dashboard's DNS plan is the source of your actual names, not this table. No tenant-specific selector, alias target, public key or include is safely derivable from the provider name. Do not paste another customer's screenshot into DNS.

DKIM: keep managed aliases, not copied public keys

In the sender-domain workflow, Copernica uses CNAMEs for DKIM and manages key rotation. Its DKIM documentation describes a customer-domain signature plus a second Copernica-domain signature. Older Publisher key forms may remain visible; an empty manual-key list is not itself a failure when managed sender domains are active. Copernica DKIM.

Publish every issued DKIM alias at the exact owner. The private key stays with the signing system. Do not replace a managed CNAME with a snapshot of the public key merely because a TXT lookup currently returns that key. That would disconnect your record from future provider rotation.

For example, an issued full owner samplekey._domainkey.news.example.com uses relative name samplekey._domainkey.news in the example.com zone, or samplekey._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com is itself delegated, use samplekey there. samplekey is fictional, not a Copernica selector. Preserve the NS delegation and publish at its actual authority, checking for doubled suffixes.

A CNAME owner must not also contain ordinary TXT, MX or other conflicting data. If an issued selector name is already occupied, preserve the existing record while you ask which configuration owns it. DNS syntax, not a dashboard's optimistic description, governs whether those records can coexist. DNS CNAME rules.

When inspecting a message with two signatures, record both results. A passing copernica.com signature alone does not align with a customer's unrelated From domain. A passing aligned SPF result can satisfy DMARC, but completing this DKIM setup also requires the intended customer signature to pass and align.

SPF: use the bounce identity and exact generated include

Copernica's SPF-specific page recommends TXT with an include, rather than treating SPF like the other CNAME aliases. It explains that SPF concerns the envelope address and that its recommended policy belongs on the bounce subdomain, not automatically on the main domain. Use the generated owner and include target. Copernica SPF records.

The SPF page's illustrative bounce-domain wording is not a deployable tenant record. Confirm the account output and actual message identity instead of inferring a hostname from a prose example. A provider-managed dependency authorizes its maintained sending infrastructure; avoid replacing it with a manually copied IP list that can go stale.

Keep one SPF policy per exact owner and preserve existing authorized mechanisms where a shared owner genuinely needs them. SPF's ten-term limit covers evaluated DNS-querying mechanisms and modifiers, including nested paths. It is not a limit of ten visible includes or ten DNS resource records. A root policy is not automatically inherited by the bounce subdomain. RFC 7208.

Preserve the approved terminal qualifier when merging a shared SPF policy. Any all mechanism makes redirect= ineffective, and mechanisms after a matching all are unreachable. Do not add an all that disables a working redirected policy; qualifiers express SPF outcomes, not guaranteed delivery or rejection. Multiple character strings may form one TXT policy, but multiple competing v=spf1 records are invalid. SPF all and redirect and TXT string handling.

Decide who controls DMARC before accepting the bundle

Copernica permits keeping an existing self-hosted DMARC record instead of installing its proposed DMARC CNAME. If you keep your own record, dashboard policy settings do not control it. Delegating a shared organizational policy affects mail outside Copernica too. Copernica DMARC options.

Therefore, do not add a CNAME beside an existing TXT policy or delete an established policy merely to remove a setup warning. Discuss the exception with the policy owner and provider if necessary. Review the exact resulting policy and reporting recipients before approving delegation. A dedicated sender subdomain can still have inherited policy considerations; check effective policy rather than assuming a new hostname is unprotected.

DMARC needs either aligned SPF pass or aligned DKIM pass. Relaxed alignment permits the same Organizational Domain; strict alignment requires an exact domain match. Preserve existing adkim, aspf, policy and reporting choices while diagnosing configuration failures. A subdomain relationship is not enough under strict alignment. RFC 9989.

For a fictional From: newsletter@example.com, a passing intended signature with d=news.example.com aligns under relaxed mode if both share the same Organizational Domain, but not strict mode. A passing d=example.com matches under both. These illustrate comparison rules, not observed Copernica output. See raw DKIM versus aligned DKIM results.

Copernica's DMARC page discusses percentage-based deployment. RFC 9989 removed pct and supersedes RFC 7489 and RFC 9091, so do not rely on that older rollout mechanism. Do not downgrade established enforcement for this integration. Review legitimate routes over representative traffic before tightening policy.

Only if no direct or applicable inherited policy exists, and the owner approves a self-hosted monitoring plan with a working authorized mailbox, an initial example is:

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

Use relative name _dmarc.news in example.com, or _dmarc in a separately delegated news.example.com zone. An apex policy at _dmarc.example.com uses _dmarc in example.com. This is not a generated Copernica value or permission to replace a managed alias, an existing policy or inherited protection. p=none does not prevent spoofed mail from arriving.

If adding aggregate reports to Copernica or another analyzer, obtain the owner's recipient and privacy approval. When the destination host's Organizational Domain differs from that of the domain where the policy was found, the report-generating receiver must check DNS authorization. Destinations within the same Organizational Domain are excepted; different hostnames alone are not enough to trigger this requirement. Protocol authorization does not replace data-sharing approval. RFC 9990 section 4. Retain existing report destinations unless their owner approves a change. Do not enable failure reporting casually because RFC 9991 reports may include sensitive message content. Aggregate reporting · Failure-report privacy.

Validate public DNS and provider readiness

Substitute exact names from the dashboard and, later, the delivered message. These are read-only checks, not a universal Copernica record set:

dig +short CNAME EXACT_DKIM_OWNER
dig +short TXT EXACT_DKIM_OWNER
dig +short TXT EXACT_BOUNCE_DOMAIN
dig +short MX EXACT_BOUNCE_DOMAIN
dig +short TXT _dmarc.EXACT_FROM_DOMAIN
dig +short CNAME _dmarc.EXACT_FROM_DOMAIN

Expected observations:

1. Every DKIM alias points to its issued target, and the resolved key data is available.
2. The bounce-domain SPF policy is valid and retains the generated provider dependency; its MX priority and target match the account-issued routing.
3. The DMARC query returns the intended self-hosted policy or resolves through the approved alias, not conflicting records.
4. The dashboard no longer reports unresolved DNS problems for the chosen managed domain. Copernica identifies green checkmarks as correct settings, red crosses as errors and orange triangles as warnings. Investigate both red and orange results; a green indicator still does not prove message alignment. Copernica DNS validation.

Compare authoritative and recursive responses. Check DNS suffix handling and negative-cache TTLs if the account cannot see a record you believe you saved. A relative-name editor may append the zone; a full-name editor may not. Inspect the final public owner instead of trusting the input box. A SERVFAIL or missing target is a problem to investigate, not a reason to delete other authentication records.

For issued aliases, preserve a literal CNAME answer rather than accepting an IP response as equivalent. In Cloudflare, use DNS only and turn the relevant per-record Flatten option off when available. Zone-wide flatten-all overrides that control and must not suppress the issued aliases; turn it off if applicable only after coordinating effects on other services. Cloudflare flattens apex CNAMEs by default and same-zone targets regardless of this setting. If mandatory behavior prevents the required answer, or shared settings cannot safely be changed, stop and coordinate a supported layout. Never remove shared NS delegations or invent a bypass. Cloudflare verification controls and flattening controls and exceptions.

Prove the actual sending identity

After validation, have an authorized operator send a representative campaign to a controlled mailbox. Read that receiving service's trusted Authentication-Results and original headers. An attacker can prepend a convincing-looking header; establish the receiver's processing boundary using its documentation or administrator confirmation of which service added the results and how externally supplied fields are removed or distinguished. A familiar authserv-id or header position alone is insufficient. If provenance remains uncertain, leave acceptance open. RFC 8601.

Require the intended branded From, not a rewritten provider address. Capture From, smtp.mailfrom, every DKIM d=/s=, the receiver's SPF/DKIM/DMARC outcomes, timestamp and actual route. Confirm a customer-domain DKIM pass aligned under the applicable adkim mode and expected envelope authentication, with dmarc=pass attributable to an aligned passing mechanism. Test each materially different From identity, including Publisher traffic where relevant. Save the findings as evidence, not a generic “DNS is green” comment.

A DMARC pass supplied only by SPF does not complete the DKIM task. Likewise, investigate SPF fail, permerror or temperror even if aligned DKIM carries DMARC: check actual sender authorization, duplicate policies or lookup limits, and DNS errors respectively. Separate a direct-route defect from forwarding effects before changing the policy.

Troubleshooting by symptom

A useful incident record separates these findings. For example, an operator could have a valid managed DKIM alias but an unrelated From domain in the campaign. Replacing that alias would not repair the identity mismatch. Compare the message's actual domains with the intended sender-domain plan first.