DMARC, DKIM, and SPF setup for Shopify and Klaviyo

The short answer

Three DNS records authenticate your email, and the build order is fixed: a branded sending domain in Klaviyo first, which switches on SPF and DKIM for the sending subdomain, then a DMARC record on the root domain starting at p=none, then a policy tightened to quarantine and reject only as the reports prove every legitimate sender passes. The whole setup is an afternoon with DNS access, and the mistakes worth avoiding are all in the order.

Why authentication records matter

Google and Yahoo both made SPF, DKIM and DMARC requirements for bulk senders from February 2024, with Google applying them to anyone sending more than 5,000 messages a day to Gmail accounts. The records are not technical complexity for its own sake, they are the basic credential inbox providers now require before trusting a sender at all.

The three records do different but complementary jobs, and the table is worth pinning.

Setting up in Klaviyo

Klaviyo's route to authenticated sending is a branded sending domain on a dedicated subdomain, something like send.yourdomain.com. Setup means adding the DNS records Klaviyo generates, NS records under its recommended dynamic routing or CNAME records where a DNS host cannot support those, plus a TXT record to verify ownership. Those records switch on DKIM and SPF for the subdomain automatically, and Klaviyo generates a starting DMARC record at p=none to satisfy the inbox provider requirements.

The subdomain choice is deliberate rather than cosmetic: it separates marketing reputation from the root domain's transactional and corporate mail, so a rough campaign month cannot drag order confirmations into spam with it. Verify the setup in Klaviyo's domains settings, which should show every record authenticated before the first send.

One trap specific to Shopify-hosted DNS: it does not accept NS records, so stores managing DNS inside Shopify take Klaviyo's CNAME route. Both work, and knowing which applies saves the support ticket.

The root domain still needs auditing

Where other services send from the same root domain, Shopify's notification emails being the usual example, the root domain's own SPF record needs auditing too. SPF allows a maximum of ten DNS lookups, each include statement spends some of them, and years of accumulated services, helpdesk, reviews platform, old ESPs, routinely push established domains over the limit, at which point SPF silently stops validating for everything.

The audit is simple: list every service that sends as the domain, check each still deserves its include, and remove the leavers. Most established brands find at least one ESP they left years ago still authorised to send as them, which is a security finding as much as a hygiene one.

DMARC policy: the staged tightening

1. Start at p=none with a reporting address (the rua tag), which filters nothing and starts the evidence arriving.
2. Read the aggregate reports for a few weeks, through any of the free report parsers, and confirm every legitimate sending source passes SPF or DKIM alignment.
3. Fix the failures the reports surface, which is usually a forgotten service sending unauthenticated.
4. Move to p=quarantine, watch for collateral damage for a fortnight, then p=reject once the reports run clean.

Moving to p=reject early, before all the sending sources are verified, blocks legitimate email, and it is the one mistake in this setup that customers notice before you do. The staged route costs a month of patience and nothing else.

Authentication is the floor of the wider deliverability system rather than the whole of it, and once the records pass, the work moves to the signals and segmentation that keep placement. A new sending domain also starts with no reputation at all, which is what the warming process exists to build.

What breaks it later

Authentication is not a set-and-forget system, because the things that break it are routine business changes nobody connects to email. A DNS host migration that fails to carry every TXT and CNAME record across. A domain consolidation that retires the subdomain the ESP still sends from. A new service added with an SPF include that tips the domain over the ten-lookup limit. Each failure is silent at the point of change and visible weeks later as a deliverability slide with no obvious cause.

The protection is procedural: authentication checks belong on the checklist for any DNS or domain change, and a quarterly glance at the DMARC aggregate reports catches everything else, because a legitimate source newly failing alignment shows up there first. Ten minutes a quarter, and the alternative is diagnosing a reputation problem that was a missing record.

Questions we hear about authentication