How to set up SPF, DKIM and DMARC for a Shopify store

What this guide covers

This guide is part of the deliverability hub. It walks through the authentication work that has to happen before a Shopify store can send marketing email with confidence. The steps are ordered: inventory first, records second, enforcement last.

Start with an inventory, not a record

The most common authentication mistake is treating SPF, DKIM and DMARC as three independent checkboxes. They are one system. Before you change a record, write down every system that sends email for the domain.

For a Shopify store that list usually includes Shopify itself, the email platform that sends campaigns and flows, a help desk, a transactional provider and perhaps a review or back-in-stock app. Each sender has its own DKIM selector and its own SPF include. If you add records for one sender and forget another, the missing sender is the one that fails after you enforce DMARC.

The inventory should name the domain each system uses. A store may send marketing mail from a subdomain and order confirmations from the root. That separation is healthy, but it means the records have to be set at the right name. A record at the root does not authenticate a subdomain.

Publish DKIM first

DKIM is the least disruptive record to add because it does not change which servers are allowed to send. It only gives the receiving server a public key to verify a signature.

Each sender provides a selector and a public key. The selector is part of the DNS name, usually something like a vendor-specific label followed by ._domainkey. Copy the selector exactly. If a sender gives you a CNAME target instead of a TXT value, publish the CNAME the sender specifies rather than trying to reconstruct the key by hand.

A DKIM key can be rotated. When a sender rotates its key, the old record stops matching and the new one has to be published. Keep a note of which selector belongs to which sender so a rotation is a planned change rather than a surprise.

Merge SPF into one record

SPF is a common place to get into trouble. The record is a TXT record at the root of the sending domain, and it starts with v=spf1. Every authorized sender adds an include: mechanism. Only one SPF record may exist for a name.

A simplified record looks like this:

v=spf1 include:shopify.example include:mailer.example ~all

The includes in that example are placeholders. Use the exact hostnames your senders publish. The ~all at the end is a soft fail; a -all is a hard fail. Which one you use depends on how confident you are that the inventory is complete.

RFC 7208 limits the evaluation to ten DNS lookups. Each include can consume more than one lookup depending on what it points at. The practical rule is to keep the record short, remove senders you no longer use and check the lookup count before you add another include. A record that exceeds the limit can fail even when every include is legitimate.

Do not create a second record to work around the limit. Two SPF records at the same name are a permanent error. If the record is too long, consolidate senders or move a sender to a subdomain with its own record.

Add DMARC in monitoring mode

DMARC is a TXT record at _dmarc.<domain>. It tells the receiving server what to do when a message fails authentication and where to send reports. It also requires alignment between the From domain and the authenticated domain.

A monitoring record looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

The p=none policy collects data without rejecting mail. The rua address receives aggregate reports. The adkim and aspf settings control relaxed or strict alignment; relaxed alignment is the common starting point because it tolerates subdomains.

DMARC.org describes the move from monitoring to quarantine and then to reject as confidence grows. That order matters. A reject policy on a domain with an unknown sender will reject legitimate mail, and the store may not notice until a customer asks why the order confirmation never arrived.

Verify from the outside

A DNS dashboard is not a verification tool. It shows what the provider thinks it published, not what a receiving resolver sees. Check the records from a neutral resolver or an authentication checker, and test with a real message.

Send a test to a mailbox you control and read the authentication results in the headers. You want SPF and DKIM to pass and to align with the From domain. If DKIM passes for a third-party domain but not for your own, the selector or the key is wrong. If SPF passes for the envelope sender but not for the From domain, the alignment is wrong.

Keep the test message. When a record changes, compare the new headers with the old ones. The difference is usually more informative than a dashboard status.

Read the reports before you enforce

DMARC aggregate reports are XML files that show which senders are using the domain, how many messages they sent and whether they passed authentication. They are not pretty, but they are the evidence you need before you move the policy.

Look for sources you recognize. A report that shows an unknown sender sending a large volume is a signal to investigate, not necessarily a signal to reject. It could be a forgotten app, a forwarding path or a legitimate partner. Confirm before you enforce.

The safe sequence is monitoring, then quarantine with a low percentage, then a full quarantine, then reject. Each step should be followed by a period of reading reports. The exact duration depends on the store's sending patterns; there is no universal calendar.

Keep the system current

Authentication is not a one-time setup. A new app, a new help desk or a new sending domain adds a record. A retired sender leaves an include that costs a DNS lookup. A rotated DKIM key needs a new record. A DMARC report address that nobody reads is worse than no reports because it creates the appearance of monitoring.

Put the records in the same change process as the rest of the store's infrastructure. When a new marketing tool is approved, add its records before the first send. When a tool is removed, remove its include and its key. Review the DMARC reports on a schedule and keep the policy aligned with what the store actually sends.

Related reading

• Sending domain setup explains the product-side domain flow.
• Abandoned checkout best practices covers the flow that often runs first.
• Writing subject lines covers the copy that follows authentication.