DMARC for online stores: the spoofed order email problem

Why a store is a target

Your domain is a trust mark. A customer who sees an order confirmation, a refund notice or an invoice from your address has a reason to act on it, and that is exactly what a forged message exploits. Without an email authentication policy, a receiving inbox has no instruction for what to do when someone else sends as your domain, so a forged message can land beside your real ones. The damage is not abstract: refund fraud, phishing and fake invoices all run on a domain the attacker does not own.

Three records decide this. SPF lists the hosts allowed to send mail for the domain. DKIM signs each message so a receiver can check it was not altered in transit. DMARC ties the visible From address to those two and tells the receiver what to do when a message fails, and where to send reports. Publish all three, or the receiver has only a partial signal.

What the study found

The State of Ecommerce SEO 2026 read the public DNS records of 963 stores in September 2026. 19% of 963 stores had no DMARC record at all. 75% of 963 stores were not enforcing DMARC, which means either no record or a monitoring-only policy that asks for reports but takes no action on failing mail. 12% of 963 stores had no SPF record, so even a store that signs its mail gives receivers less to check.

The platform cut is close, with WooCommerce slightly worse on both DMARC checks and slightly better on SPF. No DMARC record: 18% of 713 stores on Shopify and 23% of 250 stores on WooCommerce. Not enforced: 74% of 713 stores and 75% of 250 stores. No SPF: 13% of 713 stores and 8.0% of 250 stores. The WooCommerce group is smaller, 250 stores against 713, so its intervals are wider and a small gap there proves little.

The overall reading is that enforcement is the exception: 75% of 963 stores do not enforce DMARC, and 19% of 963 stores publish no record at all. Neither platform writes your policy for you, which is why the two platforms look so similar here.

Adding SPF, DKIM and DMARC

All three are DNS records on the domain that appears in your emails. The order matters: get SPF and DKIM right first, because a DMARC policy that rejects without them will reject your own real mail.

1. SPF. Add one TXT record at the root of the sending domain listing every host that sends for you. If your store platform sends order and shipping mail on your behalf, keep the include it requires and add the newsletter and support senders as further includes rather than replacing the first. Stay within the lookup limit; if you approach it, send through a subdomain instead.
2. DKIM. The services that send as you provide a public key and a selector. Publish the key as a TXT record at selector._domainkey.yourdomain and turn signing on. Every service that sends as you needs its own selector published.
3. DMARC. Publish a TXT record at _dmarc.yourdomain with a version, a policy and a reporting address. Start at p=none so you collect reports without blocking anything.

On a hosted store, the platform sends transactional mail but the DNS is still yours, so you own the records above. On a self-run store, mail may leave through your web host or a separate mail service; confirm which, and never rely on the host's default sending without SPF and DKIM for it. This is also why the study sees similar numbers on both platforms: the records live on the merchant's domain either way.

Moving to enforcement safely

A monitoring policy asks receivers to report forged mail but to deliver it anyway. It is a starting point, not a finish line. Before you tighten it, use the reports to answer one question: does every legitimate sender of your domain pass SPF or DKIM with alignment? Newsletter tools, support desks, payment notices and the store platform all count.

1. Leave p=none in place for as long as it takes to see a normal week of reports, including the senders you had forgotten.
2. Add SPF or DKIM for any legitimate sender that fails, then confirm it passes.
3. Move to p=quarantine. If you are unsure, set a percentage below one hundred so only part of failing mail is quarantined while you watch.
4. Only when the reports are clean, move to p=reject, the policy that actually stops forgery.

Use a subdomain policy if a service must send from a subdomain, and keep at least one reporting address a person reads. The common failure is a policy that was tightened once and never revisited when a new sender was added.

What the check measures and its limits

The email security check reads the public DNS records for a domain and reports whether SPF, DKIM and DMARC are present and how strict the DMARC policy is. That is the same public view the study used, so it can place your store against these numbers.

It cannot see the mail you send, cannot measure whether your messages land in an inbox, and cannot read your aggregate reports. A missing record is a real finding. A present record is not a guarantee: DKIM is only found for the selectors a public lookup can guess, and a policy can be present but weak. Use the check to find the gap, then verify the senders and the reports yourself. For the pages around the records, see the trust pages guide.

Questions

Keep reading