Stop Fake Emails From Your Store Domain

To stop scammers sending email as your store, publish three DNS records (SPF, DKIM and DMARC) and then tighten your DMARC policy to reject once your real emails pass.

This guide is for owners of small online stores (Shopify, WooCommerce, BigCommerce or custom) who send order emails, receipts and newsletters from their own domain. You will get a plain-English explanation, a step-by-step setup you can start today, and the exact records to copy. You do not need to be technical, but you will need access to wherever your domain's DNS is managed (usually your registrar or Cloudflare).

Cyber Monday is a busy time for scam emails. Customers expect shipping notices, discount codes and receipts, so a fake message that looks like yours is easy to believe. Fixing this takes a few hours of work spread over a few weeks, so it is worth starting now.

Why anyone can send email as your domain

Email was designed without a strong check on who is sending. The "From" line is just text. Without extra protection, a scammer can type orders@yourstore.com into it and some mail systems will deliver the message as if it were you.

This is called email spoofing. The scammer does not need to break into your website or your inbox. They only need to claim your domain name.

Three DNS records fix most of this. DNS (the Domain Name System) is the public address book for your domain. Anyone, including Gmail and Outlook, can look up the records you publish there.

SPF, DKIM and DMARC in plain English

SPF and DKIM do the checking. DMARC is the part that gives the order to block. DMARC also requires that the domain that passed SPF or DKIM matches the domain in the "From" address your customer sees. This is called alignment. All three are open standards: see RFC 7208 (SPF), RFC 6376 (DKIM) and RFC 7489 (DMARC).

There is also a practical reason to set them up. Google's email sender guidelines require authentication for senders, and they ask for all three for bulk senders. Even a small store benefits from meeting that bar, because properly authenticated mail is less likely to land in spam.

Step 0: List everything that sends email as you

This is the step most people skip, and it is the one that prevents broken order emails. Write down every service that sends mail using your domain:

• Your mailbox provider (Google Workspace, Microsoft 365, Zoho, etc.)
• Your store platform (Shopify, WooCommerce, BigCommerce)
• Your newsletter tool (Klaviyo, Mailchimp, etc.)
• Your helpdesk, review app, invoicing tool or SMTP plugin (for example WP Mail SMTP on WordPress)

If you miss one, its emails may fail the checks once you tighten the rules. DMARC reports (step 3) will help you find stragglers.

Step 1: Set up SPF

SPF is one TXT record on your main domain. A TXT record is a DNS entry that holds a line of text.

Each sending service gives you an include: value in its help pages. Combine them in a single record. Here is an example for a store using Google Workspace and Mailchimp:

Type: TXT
Host: @
Value: v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Check your own providers' documentation for the right include: values. Do not copy the ones above unless you use those exact services.

Keep these rules in mind:

• Only one SPF record per domain. Two separate v=spf1 records break SPF. Merge them into one line.
• Maximum of 10 DNS lookups. Each include: can count toward the limit. Too many causes SPF to fail, so remove services you no longer use.
• Use ~all to start. It means "treat other senders as suspicious" (a soft fail). -all is stricter and means "reject others." Once DMARC is at reject, ~all is usually enough. Use -all only if you are sure your sender list is complete and you accept that some receivers may reject forwarded mail before DKIM is checked.

Step 2: Turn on DKIM

DKIM is set up inside each sending service, not by you inventing a record. The service generates a key and shows you one or more DNS records to add, usually as CNAME or TXT entries. A CNAME is a DNS entry that points one name at another.

The usual flow:

1. Open the service's settings and find a section called something like "Authenticate domain," "Domain authentication" or "Sender authentication."
2. Copy the record(s) it shows you into your DNS provider exactly as written.
3. Go back to the service and click verify. DNS changes can take from a few minutes to a few hours.

Do this for every service on your list from step 0. For Google Workspace, the setting lives in the Admin console under Apps, Google Workspace, Gmail, Authenticate email. Each service signs its own mail with its own key, so they do not conflict.

Step 3: Publish DMARC in monitor mode

Start with a DMARC record that watches but blocks nothing. This protects you from locking out your own real emails.

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourstore.com

What each part means:

• v=DMARC1 says this is a DMARC record.
• p=none means "just report, take no action yet."
• rua= is where daily summary reports are sent. Use a real mailbox you can read, or a free reporting service that turns the raw XML reports into something readable.

Leave it for two to four weeks. Read the reports and look for legitimate services whose mail fails DMARC. A service can pass SPF on its own domain but still fail DMARC, because DMARC needs SPF or DKIM to pass using a domain that matches your From address. Enabling DKIM with your own domain in each service usually fixes this. Fix those (go back to steps 1 and 2) until your real mail passes DMARC.

Step 4: Move to quarantine, then reject

Once your real mail passes consistently, raise the policy in stages:

You can ease in with the pct tag, for example p=quarantine; pct=25, which applies the policy to a share of failing mail while you watch for problems. Then move up. The final record looks like this:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourstore.com

This is what actually stops fake emails from your domain. Receivers that honor DMARC will refuse messages that claim to be you but fail the checks. Many large mailbox providers do honor it, but no standard guarantees every receiver will.

To make the timing work for Cyber Monday, aim to be at quarantine or reject before your biggest sending days. Do not change the policy in the middle of a sale, when a surprise failure would cost you the most.

Step 5: Check your work

You can test without any special tools:

1. Use the free email spoofing checker on this site to see whether your SPF and DMARC records exist and are set up sensibly.
2. Send a test order email to a Gmail address, open it, click the three dots, choose Show original, and look for SPF: PASS, DKIM: PASS and DMARC: PASS.
3. If you like the command line, look up your records directly:

dig TXT yourstore.com +short
dig TXT _dmarc.yourstore.com +short

The first lists your TXT records. Look for the one starting with v=spf1. The second shows your DMARC record.

Protect domains and subdomains that never send mail

If you own old or parked domains, or a subdomain that never sends email, lock them down. For a whole domain that sends nothing, publish:

TXT @ : v=spf1 -all
TXT _dmarc : v=DMARC1; p=reject

This tells receivers that nothing legitimate comes from there. Scammers like unused domains because nobody is watching them.

For a subdomain that never sends mail, publish the same two records on that subdomain, with the DMARC record at _dmarc.sub.yourstore.com. If your main domain already has p=reject, subdomains inherit that policy unless you set sp= differently.

SPF is not inherited, so publish the SPF record on the subdomain itself, for example Host: mail with Value: v=spf1 -all. DMARC at your main domain already covers subdomains through its policy unless you set sp=, so a separate _dmarc record on the subdomain is optional.

What DMARC does not stop

Be honest with yourself about the limits. DMARC protects the exact domain you own. It does not stop:

• Lookalike domains, such as yourstore-orders.com or a letter swapped for a similar one. Consider registering the obvious variations, and watch for new ones.
• Display name tricks, where the name says "Your Store" but the address is a random Gmail.
• A hacked mailbox or store admin account. If an attacker is truly logged in as you, the mail passes every check. Use strong, unique passwords and two-step login on your email and store admin.

If you think something like that has already happened, our website hacked page walks through what to do first.

Email records are one slice of your store's security. The free website security check looks at your site from the outside and flags common problems, so it makes a good companion to this fix.

Quick checklist

• [ ] Listed every service that sends email as my domain
• [ ] One merged SPF record, ending in ~all
• [ ] DKIM enabled and verified in every sending service
• [ ] DMARC published with p=none and a report address I read
• [ ] Reports reviewed, and real mail passes
• [ ] Policy raised to quarantine, then reject
• [ ] Unused domains set to v=spf1 -all and DMARC reject
• [ ] Two-step login on email and store admin

Key takeaways

• SPF lists who may send for your domain, DKIM signs each message, and DMARC says what to do with failures.
• List every sending service first, then set up SPF and DKIM for each one before you touch DMARC.
• Start DMARC at p=none, read the reports for a few weeks, then move to quarantine and reject.
• DMARC stops exact-domain spoofing only. Lookalike domains and hacked accounts need separate defenses.
• Finish before your busiest sale dates, and avoid policy changes in the middle of them.

Want a human to look at the rest?

Email records are one piece of the puzzle. If you would like a person to manually check the rest of your site, the Circuit audit is $49 one-time and includes a written report with severity ratings, evidence and exact fixes. It is a focused small-site audit, not an enterprise penetration test or a compliance certificate. See the pricing page for details. If you would rather start free, run the checks above first.