Email authentication for online stores: how do you set up SPF, DKIM and DMARC?

Key takeaways

• A store rarely sends all its mail from one place. Order confirmations, newsletters, receipts and support replies often come from four or more different services.
• Only services that put your domain in the From address need your SPF and DKIM records. A service that sends from its own domain is covered by its own records.
• Set up in this order: list your senders, fix SPF and DKIM for each one, publish DMARC at p=none with a report address, then move to quarantine and finally reject.
• Gmail and Yahoo now expect authenticated mail from every sender, and bulk senders must also publish DMARC (Google, Yahoo).
• Test every step with AdminKit’s free SPF check, DKIM check and DMARC check before and after each DNS change.

Why does email authentication matter more for a store?

For a store, email is part of checkout. A customer who does not get the order confirmation, the shipping notice or the password reset contacts support, or does not come back. Those messages are also exactly what criminals copy: a fake “payment failed, update your card” email that appears to come from your domain is a classic phishing lure.

Three DNS records decide whether receivers trust mail that claims to be from your domain:

• SPF (Sender Policy Framework, RFC 7208) lists the servers allowed to send mail for a domain.
• DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to each message. Receivers check it against a public key in your DNS.
• DMARC (Domain-based Message Authentication, Reporting and Conformance, now RFC 9989) tells receivers what to do when a message fails, and where to send reports.

The large mailbox providers have turned this from good practice into a requirement. Google’s email sender guidelines ask everyone who sends to Gmail to set up SPF or DKIM. Senders of more than 5,000 messages a day to Gmail must set up SPF, DKIM and DMARC, and the From domain must align with the SPF or DKIM domain. Yahoo’s sender best practices set the same bar for bulk senders: SPF and DKIM, plus a DMARC policy of at least p=none. A store that runs a newsletter can cross that line during a single sale.

If you want the full background on how the three records work together, read SPF, DKIM and DMARC explained. This guide focuses on what is different for a store.

Which senders does an online store really have?

Most stores have more senders than the owner thinks. Each app or service you connect may send email on your behalf. The table lists the usual groups. Your store may not have all of them, or may have more.

Sender	Typical mail	Does it use your domain in From?	What you usually set up
Your mailbox provider	Staff mail, replies to customers	Yes	MX, an SPF include, DKIM from the provider’s admin console
Store platform	Order confirmations, shipping notices, password resets, abandoned checkouts	Often, once you connect your domain	DKIM records (often CNAMEs) the platform gives you; sometimes an SPF include
Marketing email service	Newsletters, campaigns, automated flows	Usually yes	DKIM records, a custom bounce (return-path) domain, sometimes an SPF include
Payment or receipt provider	Payment receipts, failed-payment notices	Sometimes; many send from their own domain	Nothing if they use their own domain; DKIM and SPF if they send as yours
Helpdesk	Ticket replies, satisfaction surveys	Usually yes	DKIM records or a forwarding setup the helpdesk documents
Other apps	Review requests, invoices, back-in-stock alerts, shipping updates	Varies	Same check: does it send as your domain?

The key question for every row is the one in the middle column. SPF, DKIM and DMARC are judged against the domains a message actually uses. If your payment provider sends receipts from its own address, its records apply and yours are not involved. You only need to act for services that put your domain in the From address.

How do you find every sender?

Do it from the customer’s side, because that is the mail that matters:

1. Place a test order, then refund or cancel it. Note every email you receive.
2. Trigger a password reset, subscribe to the newsletter, and open a support ticket.
3. For each message, write down the From address and the service that sent it.
4. Open the raw headers of each message and paste them into AdminKit’s email header analyzer. It lists the Authentication-Results verdicts in your browser. The Return-Path line in the same headers is the bounce address that SPF checks. How to read email headers explains each field.

Keep the result as a simple list: service, From address, return-path domain, DKIM signing domain (the d= value) and DKIM selector (the s= value). You will use this list for every step below. Senders you miss today will still show up later in the DMARC reports, which is why DMARC starts in monitoring mode.

In what order should you set things up?

Order matters because DMARC enforcement only becomes safe once SPF and DKIM already work for every sender. RFC 9989 §5.1 describes the same sequence for a domain owner: publish SPF and DKIM for aligned domains, set up a mailbox for aggregate reports, publish DMARC at p=none, fix what the reports show, and only then decide on enforcement.

Step 1: Publish one SPF record that covers every sender

A domain must have exactly one SPF record. RFC 7208 §3.2 says that a receiver that finds more than one returns a permerror, so SPF fails for all your mail. This is the most common store mistake: a new app’s setup page says “add this SPF record”, and the owner adds a second one instead of merging. Merge instead:

v=spf1 include:_spf.mailbox-provider.example include:spf.marketing-tool.example ~all

The example uses placeholder domains. Each include: comes from the provider’s own setup instructions. ~all (softfail) asks receivers to treat other senders as suspicious; -all (fail) asks them to reject. Either is fine once DMARC is in place, because DMARC decides what happens to failing mail.

Watch the lookup count. RFC 7208 §4.6.4 allows at most 10 DNS lookups per SPF check, and every include: uses at least one. A store that keeps adding apps can go over the limit without noticing. Fixing SPF “too many DNS lookups” shows how to get back under it.

Run the SPF check on your domain after every change. It follows each include the way a receiver does, counts the lookups and void lookups against RFC 7208’s limits, and flags syntax errors.

Step 2: Turn on DKIM for each sender that uses your domain

DKIM is the more important of the two for a store. A DKIM signature travels inside the message, so it usually survives simple forwarding. SPF only checks the server that delivered the message, so a customer’s forwarding rule can break it. Many services also send with their own bounce domain, which makes SPF pass for their domain, not yours.

Each service gives you its own DKIM records, usually TXT or CNAME records at <selector>._domainkey.<your domain>. The selector is a short name that lets several services publish keys side by side. Publish each service’s records, then switch on signing in that service’s settings.

Check each one with the DKIM check. Enter your domain and the selector from your sender list. DNS cannot list selectors, so you need the exact name; the tool also lists common selectors by provider. It checks the tag syntax and the key size. For later maintenance, read how to rotate a DKIM key without breaking mail.

Step 3: Publish DMARC at p=none with a report address

Now publish a monitoring record at _dmarc.<your domain>:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourstore.example

p=none changes nothing about delivery. It asks receivers to send aggregate reports (rua) to the address you give. These daily XML files list every source that sent mail as your domain, and whether it passed. Check the record with the DMARC check, which explains in plain language what each tag does.

Step 4: Read the reports and fix every legitimate sender

For each source in the reports, decide whether it is one of yours. If it is, and it fails, fix its DKIM or its return-path domain until DMARC passes. RFC 9989 §5.1.6 says these problems must be fixed before you publish an enforcing policy. AdminKit’s DMARC report analyzer turns a report file into a readable table. Reading DMARC aggregate reports explains each field.

How do you roll out DMARC without losing order emails?

Move one step at a time, and only when the reports show every legitimate sender passing DMARC. A message passes DMARC when SPF or DKIM passes for a domain that matches the From domain. This match is called alignment.

Stage	Record	What receivers do with failing mail	Move on when
Monitor	p=none; rua=...	Deliver as usual and send reports	Every legitimate sender passes, including rare ones
Test quarantine	p=quarantine; t=y; rua=...	Receivers that support RFC 9989 test mode apply one level lower, so none	Reports still look clean
Quarantine	p=quarantine; rua=...	Treat as suspicious, usually the spam folder	No complaints about missing order, reset or support mail
Reject	p=reject; rua=...	Refuse the message during delivery	Keep reading reports; new apps can break it later

The t=y test mode is new in RFC 9989, which replaced RFC 7489 in May 2026. It asks receivers to apply one level below the published policy while you watch the reports. RFC 9989 also removed the old pct tag. Receivers that only implement the older RFC 7489 ignore t=y, so treat it as a softer step, not a guarantee.

Two store-specific timing points:

• Seasonal senders. A campaign tool used only for a holiday sale, or a yearly invoice run, may not appear in a few weeks of reports. RFC 9989 §5.1.7 notes it may take many months of reports to be sure, depending on how often you send.
• Busy periods. Avoid tightening the policy right before a big sale. If something breaks, it breaks when order mail matters most.

Remember spare domains too. Many stores own extra domains, such as an old brand name or a common misspelling, that never send mail. For those, publish v=spf1 -all and a DMARC record with p=reject, so nobody can use them to send mail that passes.

What goes wrong most often for stores?

Symptom	Likely cause	Fix
SPF fails for all mail after adding a new app	Two SPF records on the same domain	Merge them into one record
SPF permerror shows up only after the latest app	Over the 10-lookup limit	Remove unused includes or move a sender to a subdomain
Newsletters fail DMARC though SPF and DKIM pass	The marketing tool signs with its own d= domain and uses its own bounce domain	Set up DKIM for your domain in the tool, or a custom return-path domain
Receipts or helpdesk replies land in spam after p=quarantine	That service sends as your domain without DKIM	Set up its DKIM, or let it send from its own domain
Old store platform still listed after a migration	SPF include and DKIM records never removed	Clean up after the move; see migrating email providers

How do you test your setup with AdminKit?

Run all three checks on your store’s domain now, then again after every DNS change and every new app:

1. SPF check: confirms you have exactly one valid SPF record, shows every include it follows, and counts lookups against the limit of 10.
2. DKIM check: enter your domain and each selector from your sender list to confirm every key is published and valid.
3. DMARC check: shows your current policy, report addresses and alignment settings, and whether DMARC is enforcing or only monitoring.

Then send a real test: place an order, trigger a password reset and send a newsletter test to a mailbox at a large provider. Paste the headers into the email header analyzer and confirm dmarc=pass for each one.

The checks read public DNS only. They need no account and send no mail. Start with the SPF check for your store’s domain: it is the record most often broken by a new app.

For the other parts of protecting a shop, such as public camera ports and blacklisted IPs, see AdminKit’s page for shops. This guide is part of AdminKit’s email authentication cluster.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.