DKIM for Shopify: Setup and Verification

DKIM is the email authentication step Shopify merchants most often skip. SPF gets set up because Shopify’s deliverability docs mention it. DMARC gets set up after a deliverability scare. DKIM falls through the cracks — usually because it’s the most fiddly to configure, and the only feedback when it’s broken is that some emails land in spam.

This guide is the Shopify-merchant-specific DKIM setup, including the exact CNAME records you’ll publish for each common email service. For the underlying concepts, see the DKIM records knowledge base entry.

What DKIM does (in 60 seconds)

DKIM adds a cryptographic signature to every email you send. The signature is generated using a private key held by your sending service. The corresponding public key is published in your DNS as a CNAME record. When an inbox provider receives a message, it fetches your public key and verifies the signature.

If the signature checks out, DKIM passes. If the message was modified in transit, or the signature is missing, or the public key isn’t published, DKIM fails.

Where SPF authenticates the sending server, DKIM authenticates the message itself. The two together give DMARC the signals it needs to decide whether to trust an email.

Why Shopify merchants specifically need DKIM

You have multiple sending services. Each one needs its own DKIM key.

This is the part that trips merchants up. SPF is one record at the root of your domain — you add an include for each service, and you’re done. DKIM is a separate CNAME (or TXT) record per service, each with a unique selector and key value.

If you’re using Klaviyo + Mailchimp + Postmark + Gorgias + Google Workspace, that’s at least five separate DKIM keys to publish. Forget one and that service’s emails will fail DMARC alignment, even when SPF passes.

DKIM setup, service by service

Each section below walks through the records you need to publish for the most common services in the Shopify stack. The pattern is the same everywhere: the service generates a key pair, gives you a CNAME or TXT record to publish, and once DNS propagates, it starts signing your outgoing mail.

Shopify (custom sender domain)

If you’ve configured Shopify Admin → Settings → Notifications → Sender email to send from your domain, Shopify generates DKIM keys for you.

Shopify provides two CNAME records that look like:

Host: shopify._domainkey
Points to: shopify1._domainkey.shopify.com

And:

Host: shopify2._domainkey
Points to: shopify2._domainkey.shopify.com

Publish both in your DNS. Once Shopify confirms the records are live, transactional emails will be DKIM-signed from your domain.

Klaviyo

In Klaviyo, go to Settings → Account → Domains and Hosting → Authentication → Set up dedicated sending domain.

Klaviyo will give you two CNAME records, typically:

Host: klaviyo._domainkey
Points to: dkim.klaviyo.com

And:

Host: klaviyo2._domainkey
Points to: dkim2.klaviyo.com

Publish both. After 24–48 hours, Klaviyo will mark your domain as authenticated.

Once Klaviyo DKIM is active, you can also enable a dedicated sending IP — but that’s a separate setting and isn’t required for DKIM to work.

Mailchimp

In Mailchimp, go to Account → Settings → Domains → Authenticate domain.

Mailchimp gives you a CNAME record like:

Host: k1._domainkey
Points to: dkim.mcsv.net

Some Mailchimp accounts get two CNAMEs (k2._domainkey as well). Publish whatever Mailchimp shows you.

Mailchimp may also ask you to publish a “Return-Path” CNAME. That’s their bounce-handling domain. Publish it too if requested.

Postmark

In Postmark, go to Sender Signatures → Domains → Add domain.

Postmark generates a single DKIM TXT record (Postmark uses TXT, not CNAME, for DKIM):

Host: [selector]._domainkey (selector is unique to your Postmark account, often 20231201pm or similar)
Type: TXT
Value: k=rsa; p=MIIBIj... (a long public key string)

Postmark also requires a Return-Path CNAME. Publish both.

SendGrid

SendGrid generates two DKIM CNAMEs and a Return-Path CNAME. Find them in Settings → Sender Authentication.

The selectors are typically s1._domainkey and s2._domainkey.

Google Workspace

If your team sends mail through Gmail (e.g., you@yourstore.com), Google Workspace also needs DKIM.

In Google Admin: Apps → Google Workspace → Gmail → Authenticate email. Google generates a TXT record:

Host: google._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=...

Publish it, then come back to Google Admin and click “Start authentication.” Google verifies it’s live and starts signing.

Microsoft 365 / Outlook

In Microsoft 365 admin: Security → Email & Collaboration → Policies & rules → Threat policies → DKIM.

Microsoft requires two CNAMEs:

selector1._domainkey → selector1-yourdomain-com._domainkey.[tenant].onmicrosoft.com
selector2._domainkey → selector2-yourdomain-com._domainkey.[tenant].onmicrosoft.com

Once published, enable signing in the admin UI.

Gorgias, Help Scout, Zendesk, Front

Each support tool has its own DKIM generation flow:

Gorgias: Settings → Channels → Email → Authentication. Gorgias provides a single TXT record.
Help Scout: Manage → Mailboxes → [your mailbox] → Connection → Custom domain. Help Scout provides a CNAME.
Zendesk: Admin Center → Channels → Email → DKIM. Zendesk provides two TXT records.
Front: Settings → Inboxes → [your inbox] → Settings tab → Domains → Authenticate. Front provides a CNAME.

Don’t skip the support tool. Customer-facing emails from support@yourstore.com are the highest-trust mail you send. They’re also the most often unauthenticated.

Yotpo, Loox, and other product apps

Most product email apps (review requests, post-purchase upsells, referral programs) have DKIM setup buried in their settings under “domain authentication” or similar. Each one needs its own DKIM key published.

A common mistake: a merchant publishes DKIM for Klaviyo and Mailchimp, then a year later installs Yotpo Reviews and forgets to authenticate it. Yotpo’s review request emails start landing in spam, the merchant blames Yotpo, but the problem is the missing DKIM key.

Publishing CNAMEs vs TXT records

Some services generate CNAME records, others generate TXT records. Either is fine — both publish a DKIM public key, just in different DNS record types. The setup steps are the same: log into your DNS provider, create a new record with the correct type, host, and value, and save.

Where merchants go wrong is trying to publish a CNAME as a TXT record or vice versa. The DNS provider may accept it without error, but DKIM verification will fail because the lookup type doesn’t match what’s expected.

Verifying DKIM is working

Send a test email from each of your services to a Gmail address you control. Open the message in Gmail, click the three-dot menu, and choose Show original.

Look for the lines:

DKIM: 'PASS' with domain yourstore.com
Signed-by: yourstore.com

If you see those, DKIM is working for that service.

If you see DKIM: 'FAIL' or DKIM: 'NONE', the most likely causes are:

DNS not yet propagated (wait 24 hours)
The CNAME or TXT was published incorrectly (typo in the host or value)
The service hasn’t been “enabled” on its side after DNS was published (most services require you to click a “verify” button after publishing the record)

A faster check: run a free Recon scan. It checks DKIM presence for your domain, lists which selectors are publishing valid keys, and flags services where DKIM is missing or malformed.

Common DKIM mistakes Shopify merchants make

Publishing the CNAME at the wrong host. Common error: publishing klaviyo._domainkey.yourstore.com as the host, when the host field should just be klaviyo._domainkey (the provider auto-appends your domain).
Forgetting to enable signing on the service side. Publishing the CNAME isn’t enough. Most services have a “verify” or “start signing” button you have to click after DNS propagates.
Setting up DKIM for marketing tools but not transactional or support tools. Order confirmations and support replies are the highest-trust email categories; they’re the ones scammers most want to impersonate. Authenticate them all.
Rotating DKIM keys without updating DNS. Some services rotate keys periodically. If you have a key with s=20240101 and the service rotates to s=20250101, you need to publish the new CNAME and remove the old one.
Treating DKIM as a one-time setup. Whenever you add a new email service, that’s a new DKIM key to publish. Audit your sending services quarterly.

DKIM is one piece of email authentication

DKIM signs the message. SPF authenticates the sending server. DMARC sets the policy.

Without all three, scammers can credibly impersonate your store. Order confirmations, shipping updates, support replies, “your account has been compromised, click here to verify” emails — all of these become viable attacks if your authentication stack is incomplete.

If you haven’t already, the companion guides are:

Get all three in place and you’ve eliminated the most common attack surface against ecommerce brands.

Verify your DKIM setup

Run a free Recon scan and you’ll see which of your sending services have valid DKIM keys, which are missing, and which are misconfigured. Recon also checks SPF, DMARC, SSL, security headers, and the lookalike-domain and clone signals that complete the picture of your brand’s exposure.

Free in the Shopify App Store. No security team required.