To authenticate ShopiMind campaigns, verify control of your sending domain, obtain the account's two DKIM CNAME records and validate the published configuration. Treat branded return-path alignment and tracking links as separate routing choices, not interchangeable DKIM records. There is no universal destination or root-domain SPF recipe to copy from this guide.
This article covers native email campaigns in ShopiMind, the ecommerce marketing platform. It does not configure an unrelated product called ShopMind, your staff mailboxes or every application connected to your store. No customer account, DNS change or actual send was used in this review.
On this page
- Prepare the sender and routing plan
- Obtain the account-specific records
- Approve return-path and tracking changes separately
- Publish DNS without breaking other services
- Validate each configured function
- Understand SPF and preserve DMARC
- Prove the actual messages authenticate
- Troubleshooting and FAQs
Prepare the sender and routing plan
Use a domain your organization controls and an authorized ShopiMind account. Have the DNS administrator confirm the authoritative zone and save the current records. Identify the intended visible From address, existing mail routes and any subdomains already used by websites, tracking tools or other senders. Keep mailbox MX, existing DKIM selectors and security policies intact.
The reviewed provider documentation does not establish a universal plan entitlement or exact permission-role name. If the domain controls are absent, ask the account administrator to confirm the correct store and access rather than changing subscriptions or granting unnecessary privileges.
ShopiMind distinguishes domain ownership, authentication, return-path alignment and redirect links. Its delivery infrastructure explanation describes platform-managed sending infrastructure and the separate identities used in outgoing mail. A green ownership indicator is not proof of a passing DKIM signature, and a branded tracking URL is not DMARC authentication.
Obtain the account-specific records
Open Ma boutique > Mes domaines d’envoi, meaning My store > My sending domains. Use the intended domain; the illustrated page also provides Ajouter un domaine for adding one. Establish ownership by the offered email confirmation to a valid domain mailbox or the supplied DNS TXT token. Then open Instructions in the Authentification column. Official domain configuration procedure.
The procedure requires two CNAMEs, with owner prefixes spmdkim1._domainkey and spmdkim2._domainkey beneath your domain. Obtain both complete owner/target pairs from your account. The public illustrations show statuses, not deployable destinations. Do not construct a target, reuse another merchant's record or substitute TXT for an issued CNAME.
Ownership verification only establishes control for the application. If using email confirmation, choose an authorized mailbox and confirm through the verified provider flow; this does not migrate that mailbox. The ownership TXT is a verification token, not a DKIM public key or an SPF policy. Keep these record purposes distinct in the change request.
Approve return-path and tracking changes separately
For a branded return path, open Instructions under Alignement des domaines; for branded redirect links, use Instructions under Liens de redirections. Each function uses its own chosen subdomain and issued CNAME. After publication, Options > Vérifier ma configuration DNS checks the configuration. The completed illustration shows independent successful status indicators. Provider workflow and status examples.
Before publishing either routing alias, compare its exact target and owner with the approved plan. Confirm who owns the chosen subdomain, what it currently serves, and the consequences of directing traffic to ShopiMind. Do not replace a live website, staff-mail route or another service's bounce handler merely because the account offers that hostname. Use separate unused names for the two functions unless the actual provider-issued packet explicitly supports another arrangement.
Return-path customization concerns the envelope identity used for bounces and SPF; tracking customization concerns links. A tracking alias alone cannot make SPF or DKIM align. The provider's general recommendation to share a root domain is not a guarantee of strict DMARC alignment: a child envelope domain may match relaxed alignment while failing strict alignment against the root visible From.
Do not activate an unapproved bounce or tracking destination just to make every status column green. Document which optional functions are intentionally excluded. If the account cannot complete the intended authentication scope without an additional routing change, stop and obtain approval rather than silently broadening the task.
Publish DNS without breaking other services
Use the authoritative DNS zone, not necessarily the company that sold your domain. Save the current records before approved changes. Copy each issued record's type, full owner and destination exactly. These are public DNS values; you should never need to publish a DKIM private key.
Check what your DNS editor appends. For the illustrative full owner selector._domainkey.example.org, an editor for the example.org zone may require only selector._domainkey. In a separately delegated _domainkey.example.org zone, the relative name is selector. These are owner-format examples, not provider selectors or records to publish. A child-zone delegation changes where records must be entered; preserve NS delegations and coordinate with their owner rather than deleting them.
An issued CNAME owner cannot also contain TXT, A, AAAA, MX or another CNAME. If an owner is occupied, investigate dependencies and request a supported alternative where possible; do not overwrite another sender's record. A CNAME destination is a hostname, not a URL, and its trailing-dot treatment depends on the DNS editor. Check the resulting public owner and target instead of trusting the input form alone.
For Cloudflare, authentication aliases should be DNS only, not HTTP-proxied. Where literal CNAME answers are required, turn the applicable per-record Flatten option off when available and ensure whole-zone flattening does not conceal those aliases. Do not disable a global setting without assessing other records and obtaining authorization. Apex flattening is automatic; same-zone targets can be flattened regardless of that setting. If mandatory behavior prevents the required alias answer, stop and coordinate a supported configuration rather than inventing a switch or moving a selector. See Cloudflare proxy status and CNAME flattening controls.
Validate each configured function
Run the account's DNS verification after the approved records are public. Confirm ownership and authentication succeed, and separately confirm the alignment and redirect statuses for the functions actually configured. If a status remains unsuccessful, inspect its own record rather than replacing all records together.
The provider shows a completed configuration, not a separate documented manual signing-toggle sequence. Do not invent an Enable DKIM switch. DNS verification is the documented configuration checkpoint; delivered-message testing is still needed to establish that the intended campaign is signed correctly.
Check the intended campaign's sender identity before testing. Existing store notifications or other integrated applications may use a different route. Do not assume that authenticating ShopiMind automatically authenticates those other streams. Use a minimal controlled audience, not a customer mailing list, for the authorized verification message.
Understand SPF and preserve DMARC
SPF evaluates the SMTP envelope sender, commonly reported as smtp.mailfrom, not automatically the visible From address. A custom routing subdomain and a visible sender domain are different identities. Do not add an apex SPF include merely because the service uses a particular delivery backend. Use only the actual account-issued configuration and investigate the received message's evaluated identity.
If an authorized setup requires an SPF TXT policy, keep one v=spf1 policy at that exact owner, preserving legitimate existing authorizations and qualifiers. The SPF limit is ten evaluated DNS-dependent terms, including nested mechanisms, not simply ten includes. A redirect is ignored when an all mechanism is present. Do not blindly merge or replace a policy, and do not treat a qualifier as a guarantee of delivery or rejection. SPF specification.
DMARC passes when either SPF or DKIM passes and aligns with the visible From. Relaxed alignment uses an Organizational Domain match; strict alignment requires an exact domain match. A child envelope domain may align in relaxed mode but not strict mode. A passing provider-domain signature that does not align is not enough. For the new branded DKIM route, require the intended provider signature to pass and align, even if SPF could independently yield a DMARC pass. Read DKIM alignment and the visible From domain and the current DMARC specification.
Preserve existing direct and applicable inherited DMARC policies and approved reporting destinations. Authentication setup is not permission to downgrade quarantine or reject to none. Only if no applicable policy exists, the owner approves, and a monitoring plan is in place, an initial TXT policy can be v=DMARC1; p=none at _dmarc beneath the actual From domain. For example.org, that full owner is _dmarc.example.org; for news.example.org, it is _dmarc.news.example.org. Enter names relative to the actual authoritative zone and publish only one policy at an owner. This minimal example sends no aggregate reports by itself.
Choose any report recipient deliberately. A destination in a different Organizational Domain from the domain where the DMARC policy was found requires the report-generating receiver to check DNS authorization; a destination within that same Organizational Domain is excepted. DNS authorization does not replace the owner's privacy and data-sharing approval. Do not copy a tutorial's reporting address. See RFC 9990, section 4.
Prove the actual messages authenticate
Provider verification checks DNS configuration. It is not proof that every message stream uses the intended signing domain. After configuration, an authorized administrator should test the actual application route with a controlled, valid recipient. This guide did not perform customer sends or change DNS.
Save the recipient's original message and use authentication results produced inside the actual receiving service's processing boundary. Consult that service's documented handling of externally supplied Authentication-Results, or obtain a receiving administrator's trace. A familiar authserv-id string or header position alone is not proof of authenticity. Ignore injected or otherwise untrusted result fields. Authentication-Results specification.
Record the visible From, envelope sender, intended DKIM signature's signing domain and selector, and the trusted receiver's SPF, DKIM and DMARC results. Acceptance requires the intended provider DKIM signature to pass and align with the intended From under the active alignment policy, plus a trusted receiver DMARC pass. A generic DMARC pass via SPF alone does not prove DKIM works. A rewritten provider From is not proof of brand-domain authentication.
Investigate SPF fail, temperror and permerror separately, even when aligned DKIM makes DMARC pass. Temporary errors suggest a transient lookup problem; permanent errors indicate a configuration/evaluation problem; neither should be silently marked passed. Test materially different sending paths separately. Authentication does not guarantee inbox placement, indexing or search rankings.
Troubleshooting and FAQs
What is the ShopiMind SPF record?
The reviewed native workflow uses account-issued DNS instructions and a separate alignment configuration, not a universal root-SPF include. Identify the actual envelope domain and follow its supported configuration. Do not copy ShopiMind's corporate DNS or replace the staff-mail SPF policy. A branded From address alone does not determine where SPF is evaluated.
Why are there two DKIM CNAMEs?
The current provider instructions require both. Publish the entire issued set, even if one selector appears on today's message. Do not delete the other because it seems unused; changing the supported set can interfere with the provider's signing lifecycle. Ask the provider before retiring a record.
The domain is verified, but authentication is still red
Ownership verification and DKIM are separate columns. Check both DKIM owner/target pairs, public visibility, DNS-only behavior and flattening. A successful confirmation email or ownership token does not establish the signing records.
Authentication is green, but alignment is not
Identify which alignment is being reported. Inspect the separate return-path configuration and actual received envelope domain. Then evaluate SPF and DKIM alignment independently against the visible From. Do not claim every identity is aligned merely because one authentication method makes DMARC pass.
Can I use the same subdomain for tracking and bounces?
Do not assume so. A CNAME owner can point to only one destination and cannot coexist with other ordinary record data. Use the current account's supported instructions and separately approved routing plan. Preserve existing services and request a supported alternative if owners collide.
Why does the DNS editor show the record but verification fails?
Compare the complete public name with the issued owner. Check duplicated suffixes, incorrect authoritative zones, stale caches, missing second selector, conflicting data and concealed CNAME answers. If the records are correct, allow cached responses to expire before retesting. Waiting does not repair a typo.
Can I solve DMARC failures by switching to p=none?
No. Diagnose the actual signature, envelope identity and alignment mode. Weakening enforcement does not correct authentication and may reduce protection for every sender using the policy. Preserve existing direct and inherited policies while fixing the specific route.
The campaign authenticates but still lands in spam
Authentication verifies identities; it is not an inbox-placement guarantee. Investigate permission, list quality, complaints, content and sending practices separately. Do not add arbitrary SPF includes, rotate keys repeatedly or purchase a different IP simply because a test lands in spam.
What should I retain for support?
Record the specific domain/function, public owner/type/target, validation state and check time. For message failures, retain only necessary sanitized trusted receiving results and route details. Do not share private keys, passwords, customer lists or unrelated message contents. Distinguish DNS validation from an actual failed campaign so support can investigate the right layer.
Sources and review limits
This guide uses the official technical domain configuration instructions and delivery infrastructure explanation. Three official illustrations were inspected for the menu, separate status columns and completed configuration. Account-generated targets are deliberately not reproduced.
The review was documentary, not hands-on. No account settings, DNS records, campaigns or customer messages were changed. Static manuscript checks do not establish live CMS rendering, indexation, search rankings or successful customer deployment.