Do I need an SPF record with include:shops.shopify.com?

Shopify's documentation says the CNAME records it gives you configure both DKIM and SPF for your store's sender address, so a separate SPF TXT entry for Shopify is not needed for that purpose. Keep your root SPF record for your mailbox provider, and remember that every include costs DNS lookups against the limit of ten in RFC 7208.

Why does my store email still come from shopifyemail.com after I added the records?

Shopify rewrites the sender whenever authentication is incomplete. The usual causes are a missing record from the CNAME set, a DNS panel that appended your domain twice in the host field, no DMARC record, or more than one _dmarc TXT record on the domain. DNS changes can also take up to 48 hours to process, so give it a day before troubleshooting.

Can I publish p=reject straight away?

You can, and stores that do it often stop receiving their own invoices, review requests or support notifications. Publish p=none with a rua address first, read two weeks of aggregate reports, fix every legitimate sender that fails alignment, then move to quarantine and only after that to reject.

Shopify SPF, DKIM and DMARC: Fix Order Emails in Spam

A customer places an order and the confirmation never shows up. Or it shows up, but the sender reads store+12345@shopifyemail.com instead of your shop. Both problems have the same root cause: your domain has not been authenticated for the mail Shopify sends on your behalf, so Shopify and the receiving mailbox providers are protecting themselves.

This is the order I work in when a store owner sends me that screenshot. It is roughly half an hour of DNS work plus a wait for propagation, and every step below comes from Shopify's own documentation rather than from folklore.

What Shopify actually sends in your name

Your store is a sender even if you never run a campaign. Shopify sends order confirmations, shipping and delivery updates, refund notices, abandoned checkout reminders, account invitations and password resets. Add Shopify Email campaigns on top and the volume climbs quickly.

None of that mail leaves your mailbox. It leaves Shopify's infrastructure with your address in the From header. Meanwhile the mail your team writes by hand leaves Google Workspace, Microsoft 365 or Zoho. One domain, at least two sending paths, and receiving servers judge the domain rather than the path.

That is the whole problem in one sentence: your domain has to vouch for senders that are not you.

Why your store email arrives from shopifyemail.com

Shopify documents this plainly. Since February 1, 2024, Gmail and Yahoo require you to authenticate your domain and publish a DMARC record before you can send from a branded address. If you take no action, Shopify rewrites your sender address to a @shopifyemail.com address so your mail keeps arriving.

The rewrite is a safety net, not a punishment. It does cost you something real, though. A customer waiting on a confirmation sees an address that is not yours, at the exact moment they are deciding whether the purchase went through. Recognition is most of what a transactional email is for.

Two things clear the rewrite: the CNAME records Shopify shows you in the admin, and a DMARC record you publish yourself.

The records Shopify asks for are CNAMEs, not an SPF line

Most guides on this topic tell you to paste include:shops.shopify.com into your SPF record. Shopify's own help center says something different: the CNAME records configure both DKIM and SPF authentication for your sender email, and no separate SPF TXT record is needed for that purpose.

Mechanically, those CNAMEs delegate a subdomain of yours to Shopify. The bounce address of your store mail then lives on that subdomain, and SPF gets evaluated there instead of at your root.

Two consequences worth acting on:

Add every record the admin shows you, in the order shown. Shopify notes that the number of records varies from store to store. A missing record leaves you half authenticated, which fails in exactly the same way as no records at all.
Do not bolt a Shopify include onto your root SPF because a blog post said so. Every include: costs DNS lookups, and SPF returns a PermError once the evaluation goes past ten of them, per RFC 7208 section 4.6.4. If you already fight that ceiling, start with the SPF lookup guide.

Your root SPF record is there for the mail your people send. If those mailboxes are on Google Workspace, Google publishes this record for domains that send only through Workspace:

Type:  TXT
Host:  @
Value: v=spf1 include:_spf.google.com ~all

Microsoft 365 and Zoho document their own include values, so use theirs rather than copying the line above. One rule holds everywhere: exactly one SPF TXT record per domain. Two records are not twice as safe, they are a permanent error that fails every check.

DKIM: what the CNAME chain buys you

DKIM signs each message with a private key held by the sending platform, and the matching public key is published in your DNS. Shopify's CNAME records put that key under your domain, so the signature carries a d= value on your domain. That is what produces DKIM alignment, and alignment is the thing DMARC actually checks.

Three details that cost store owners a day each:

Shopify says DNS changes can take up to 48 hours to process. Nothing you do in the admin speeds that up, and re-adding the records resets your own patience rather than the clock.
Many DNS panels append your domain to whatever you type in the host field. Paste shopifyemail.example.com into one of those and you end up with shopifyemail.example.com.example.com. Read the record back after saving, not before.
If your DNS provider offers a proxy or CDN toggle on individual records, mail records have to stay on plain DNS. A proxied CNAME answers with the proxy instead of the real target, and authentication breaks quietly.

DMARC: the minimum, and what to actually publish

Shopify's stated minimum is v=DMARC1; p=none. That satisfies the requirement and tells you nothing about your mail. Add a reporting address and the same record starts paying for itself:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1

The p=none policy asks receiving servers to change nothing and report what they see. The rua address is where the daily XML summaries land. Every domain should start here, no exceptions.

Shopify calls out two traps by name:

Publish only one DMARC record. Two _dmarc TXT records make validation fail, and your sender address gets rewritten again. This is common on domains that have been through more than one agency.
Avoid strict alignment while you send through platforms. Shopify warns against adkim=s and aspf=s. Strict alignment demands an exact domain match, and platform sending signs from a subdomain, which passes relaxed alignment and fails strict. Relaxed alignment is the default for a reason.

If you bought the domain through Shopify, Shopify configures authentication for you and inserts a v=DMARC1; p=none record when the domain has none. Confirm that rather than assume it, particularly on an older domain where someone may have published a DMARC record years ago and forgotten.

Read two weeks of reports before you tighten anything

Once rua is live, aggregate reports arrive daily from the large receivers. Each row groups messages by sending source and tells you whether SPF and DKIM passed, and whether either one aligned with the domain in the From header. Alignment is the column that matters. A message can pass SPF and still fail DMARC when the passing domain is the platform's rather than yours.

Sort what you see into four buckets: Shopify's sending, your mailbox provider, your marketing platform, and anything you cannot identify. That last bucket is usually not an attacker. It is normally an invoicing tool, a review app, a support desk or a form plugin that someone connected to the domain two years ago.

Only when every legitimate sender aligns do you move the policy up, first to p=quarantine and later to p=reject. Jumping straight to reject is how a store stops receiving its own invoices. The reports are the cheap way to find out what you forgot.

Klaviyo, Mailchimp and the rest of the stack on the same domain

Authenticating Shopify does not authenticate your marketing platform. Each one signs with its own key and needs its own records.

Klaviyo calls it a branded sending domain. Their documentation lists up to three CNAME records or four NS records, plus a TXT record for domain ownership. DMARC is not configured inside Klaviyo, you publish it at your DNS provider. The branded domain also has to match the domain in your From address, so a From address of sales@example.com needs something like send.example.com.
Mailchimp documents two CNAME records for DKIM plus one TXT record for DMARC, following the same shape.

Notice the pattern. All of it is CNAME based, and none of it touches your root SPF budget. That is deliberate, and it is why the advice to add one more include for every new tool ages so badly.

One volume note before you scale up. Google's sender guidelines require bulk senders, meaning senders of more than 5,000 messages a day to Gmail addresses, to set up SPF, DKIM and DMARC, to support one-click unsubscribe on marketing and subscribed messages, and to keep the spam rate reported in Postmaster Tools below 0.30 percent. A store with a healthy list crosses 5,000 in a single campaign, so it is worth meeting those rules before you trip them.

The order I work in

List every system that sends mail as your domain: Shopify, mailbox provider, marketing platform, invoicing, support desk, review app.
Publish or repair exactly one SPF TXT record, covering your mailbox provider.
Add every CNAME record Shopify shows, in the order shown, on plain DNS, then read each one back to confirm it resolves.
Publish one DMARC record at p=none with a working rua address.
Authenticate each marketing platform separately, on its own subdomain.
Wait out propagation, place a test order, and open the raw headers of the confirmation. Paste them into the header analyzer and look for SPF pass, DKIM pass, and DMARC pass with alignment.
Read two weeks of DMARC reports, fix each legitimate sender that fails, then move to quarantine and later to reject.

If a step fails and you cannot tell which one, the free troubleshooter checks your live records and reports what is missing rather than what should be there.

How Guanacos Tech helps

Most store owners can follow the list above. The ones who call us are usually mid-incident, with orders bouncing, a domain that already has three conflicting TXT records, and no appetite for a week inside a DNS panel. We inventory the senders, fix the records in the right order, and watch the reports until the policy can move to reject safely.

The tools on this site cover the diagnosis at no cost. If you want the fix handled and monitored, read how the deliverability work runs and how we work, or book a 15 minute call. We are an independent, Google certified consultancy working in English and Spanish across North America and Latin America.

Shopify SPF, DKIM and DMARC on your own domain: stop order emails landing in spam