Shopify SPF, DKIM and DMARC setup, step by step

To authenticate Shopify email from your own domain, open Settings → Notifications → Sender email → Email domain authentication and publish every CNAME record shown for your store. Those CNAMEs handle SPF and DKIM; Shopify says a separate SPF TXT record is unnecessary for this purpose. Third-party domains also need a valid DMARC record. Keep existing authentication records unless Shopify explicitly directs a correction.

This guide covers native customer notifications and Shopify's marketing email route, currently documented under Shopify Messaging. It does not authenticate a connected app's independent mail service or your staff mailbox. No store access, DNS changes, or delivery tests were performed.

Identify the sender address and DNS owner

Start with the Sender email, not the Store email. Shopify uses Store email for merchant account communications and exports; Sender email is the customer-facing identity used for notifications and store marketing. Shopify's email setup documentation explains this distinction.

Write down the exact domain after the @ in the sender address. A store at www.example.com might send from orders@example.com or orders@updates.example.com; these do not identify the same DNS owner. Configure the domain Shopify actually lists for authentication.

Next identify who operates authoritative DNS. The registrar that sold the domain, the storefront host, and the DNS provider can be different organizations. Changing records in an inactive registrar zone will not affect public authentication. Keep the store administrator and DNS administrator involved in the same change request.

A public mailbox such as a personal Gmail address does not give you control of that provider's DNS. Use a domain you control if you want a branded sender. Creating a forwarding address is also different from buying mailbox hosting: receiving customer replies and signing Shopify notifications are separate jobs.

Check plan eligibility and management path

Shopify requires an active paid plan for adding these CNAME records. Its current setup guide excludes client transfer stores, dev stores, and Pause and Build. Confirm eligibility before troubleshooting a missing authentication option. A marketing-account hold can require separate resolution even when DNS is correct.

There are three practical paths:

• Domain purchased through Shopify: Shopify documents automatic SPF, DKIM, and DMARC setup. Confirm the sender domain and current public records; do not create a duplicate policy merely because a generic checklist says to add one.
• Third-party domain with supported automatic authentication: Shopify supports automatic DNS configuration for Cloudflare, GoDaddy, and IONOS. This configures the authentication CNAMEs but does not add DMARC.
• Other third-party domain, or manual configuration preferred: Copy all displayed CNAME pairs to the authoritative DNS provider, then start Shopify's verification check.

These differences are documented in Shopify's current setup workflow. Automatic access to a DNS account should be approved by its owner and reviewed for the intended records. It is not a reason to replace unrelated mail settings.

What records does Shopify require?

Use the list shown for your store, not a record set copied from another merchant. Shopify explicitly says the number of CNAME records can vary. A tutorial promising exactly four records can therefore be incomplete for your account.

There is no safe universal Shopify DKIM target to print here. Selectors and targets must match the store's displayed configuration exactly. Do not add a made-up TXT public key or assume every CNAME serves the same purpose.

Keep mailbox MX records, storefront A/AAAA records, and unrelated verification records unchanged. Adding authentication does not require moving your inbox or website. If a proposed CNAME owner already contains data, stop and identify its owner before replacing anything.

Add CNAME records and complete verification

For manual setup:

1. Open Settings → Notifications and confirm the Sender email.
2. Open Email domain authentication or the displayed authenticate your domain action.
3. Copy every CNAME's complete name and target from the modal. Save a dated configuration record for the DNS administrator.
4. At the authoritative DNS host, add each CNAME using that host's expected name format.
5. Inspect the final full owner name. If the editor appends example.com, enter only the relative portion it expects, avoiding example.com.example.com.
6. Return to Shopify and use the available confirmation action, such as I updated DNS records, to initiate checking.

CNAMEs must remain DNS aliases. Do not replace them with an HTTP redirect, proxy them as a website, or place another record at the same owner. Targets belong in the target field, without a URL scheme or path. Preserve any trailing-dot behavior required by your DNS editor.

For an illustrative issued owner SELECTOR._domainkey.news.example.com, a suffix-appending editor for example.com uses SELECTOR._domainkey.news; one for a separately delegated news.example.com zone uses SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated, use relative SELECTOR in that zone. A full-name field takes the complete issued owner. Replace the placeholder with the actual account selector, preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. DNS zone boundaries.

Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.

For automatic authentication, finish the provider approval window and explicitly return to Shopify. Shopify says closing that window without returning can prevent its check from starting. In that case, open manual setup and use I updated DNS records after confirming what was actually published. Official manual and automatic steps

Why you usually should not add Shopify to apex SPF

Shopify's current CNAME-based workflow handles SPF automatically for this sending route. Do not add include:shops.shopify.com merely because an older guide recommends it. That is not the current documented requirement for native sender-domain authentication.

SPF evaluates the envelope MAIL FROM domain, typically visible in the Return-Path, rather than the address customers see in From. A CNAME at a provider-designated hostname can delegate the relevant authentication lookup without changing your root-domain mailbox SPF.

Retain the SPF policy that authorizes your other services. If an unrelated sender genuinely needs a change, keep one v=spf1 TXT record at that owner, merge only approved mechanisms, preserve the final policy, and check the ten-lookup-term limit including nested includes. These rules come from RFC 7208, not from Shopify's storefront DNS settings.

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

A passing SPF result alone does not establish DMARC alignment. Compare the authenticated envelope domain with the visible From domain. Use the delivered signature and receiver results to determine whether aligned DKIM, aligned SPF, or both supplied the DMARC pass.

Add DMARC without weakening existing protection

Shopify's sender-rewrite guidance requires CNAME authentication and a valid DMARC record to retain the branded sender. For Shopify-purchased domains, it inserts a default monitoring policy when none exists. For third-party domains, check DMARC separately even after automatic CNAME authentication succeeds.

If your From domain has an existing direct or applicable inherited DMARC policy, preserve it and its reporting destinations. Do not add a duplicate or a child monitoring policy that overrides inherited protection, or replace enforcement with p=none to follow a beginner example. Shopify explicitly says existing strict alignment settings do not need to be relaxed for its supported route.

Only if no direct or applicable inherited DMARC policy exists, and the domain owner approves a monitoring plan after reviewing legitimate senders, a first TXT policy for fictional From domain example.com may be v=DMARC1; p=none at full owner _dmarc.example.com. The minimal value requests no reports; provision an approved reporting destination and review process before adding rua. Preserve established enforcement and authorized reports.

For a first policy at full owner _dmarc.example.com, a relative-name field in zone example.com takes _dmarc. For a deliberately approved child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. A full-name field takes the complete owner. These examples do not authorize overriding an inherited policy.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

Review all senders sharing the policy domain before enforcement changes.

DMARC's current standard, RFC 9989, replaces RFC 7489 and removes pct. It requires a passing aligned SPF or DKIM result. Relaxed alignment uses the same organizational domain; strict alignment requires identical domains. A Shopify verification badge does not prove the alignment result for a particular message.

Handle Update recommended without breaking working mail

Shopify distinguishes Update recommended, Propagating, and Authenticated. Update recommended can mean new CNAMEs are available or an existing value differs. Shopify says the domain remains authenticated at this stage and that the update has no fixed deadline, although missing newer records can affect branded sending during a service disruption.

Add missing records and correct mismatches shown in the current screen. Keep previously published required CNAMEs. Do not delete the older set and rebuild from memory. Click I updated DNS records to start checking. Shopify documents a return to Update recommended if records are not found after about a day, while propagation can take up to 48 hours. Check actual answers before repeatedly editing. Update workflow and timing

For Shopify-managed domains, these records are managed for you; a persistent update status should go to Shopify Support rather than prompting unsupported manual changes.

Validate public DNS and customer notifications

Replace every uppercase placeholder before using these read-only command shapes:

dig @AUTHORITATIVE_NAMESERVER SHOPIFY_CNAME_OWNER CNAME +short
dig SHOPIFY_CNAME_OWNER CNAME +short
dig _dmarc.ACTUAL_FROM_DOMAIN TXT +short

Repeat the CNAME query for each displayed record. Expected output is its exact Shopify-provided target. Compare authoritative DNS with a public resolver. If the From subdomain has no direct DMARC record, inspect the applicable inherited policy rather than concluding immediately that there is no policy.

Then check the Shopify status and send an authorized test through the actual route. Use a controlled order-notification event and, where relevant, a permitted marketing test. Avoid triggering real customer transactions merely to test authentication.

Inspect raw headers for visible From, Return-Path, DKIM d= and s=, and the receiving system's SPF, DKIM, and DMARC results. Use trusted receiver-added Authentication-Results, not arbitrary sender-supplied headers. Confirm the intended branded From survived, the expected Shopify signature passes with an aligned signing domain, and the trusted receiver reports DMARC pass. SPF does not also need to align when aligned DKIM supplies that pass. A preview, a green dashboard status, or a message accepted by an SMTP server is not equivalent to this evidence.

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.

Keep redacted results for notifications and marketing separately. Review recurring reports and recheck after a sender-domain change, DNS migration, or authentication update. EmailAuth can help organize source-level reporting, while Shopify and the DNS provider remain responsible for their configuration controls.

Troubleshooting and FAQs

Why does From show shopifyemail.com?

Shopify can rewrite the sender when authentication or DMARC is missing or invalid. Check the actual Sender email, every required CNAME, and duplicate DMARC records. Removing required CNAMEs can trigger this fallback. Rewrite scenarios

Why is authentication successful but marketing unavailable?

Account eligibility, plan restrictions, verification holds, and send limits are separate from DNS. Read the campaign banner and Shopify's marketing deliverability guidance. Do not change DNS to solve an account hold.

Do these records authenticate Klaviyo or another app?

Only if that app actually uses this Shopify sending route. An independent marketing provider needs its own domain authentication, such as the separate Klaviyo branded-sending setup. Inspect delivered headers and app configuration rather than assuming an installed app inherits Shopify's signature.

Does sender authentication give me a branded reply mailbox?

No. Configure receiving, forwarding, and mailbox hosting separately, then test that customer replies reach the right team. Do not replace working MX records for the outbound CNAME setup.

Will this keep every email out of spam?

No. Authentication establishes identities; recipient consent, reputation, content, and receiver filtering still matter. Treat verified DNS, a passing real message, and inbox placement as separate observations.