How to tell if someone can send email pretending to be your store

What spoofing means for your store

Email was designed without any built-in proof of who sent a message. The From address is just text, so a scammer can type orders@yourstore.com into it the same way you type a name on an envelope. Your customers then get a fake order confirmation, refund notice or password reset that looks like it came from you.

The damage lands on your brand: customers lose money or passwords, then blame the store whose name was on the email. Inbox providers can also start treating your real email with more suspicion. Three DNS records let you tell the world which mail is genuinely yours: SPF, DKIM and DMARC.

SPF, DKIM and DMARC in plain words

• SPF is a published list of the servers allowed to send mail for your domain. It lives in a TXT record on your domain and starts with v=spf1. A domain should have only one SPF record, so new senders are added to it rather than given their own.
• DKIM is a signature. Each service that sends for you signs its messages with a private key, and you publish the matching public key in DNS. A receiving inbox checks the signature to confirm the message wasn't forged or altered.
• DMARC is the rule that ties them together. It tells inboxes what to do when a message claims to be from your domain but fails both SPF and DKIM for that domain, and where to send reports about it.

SPF and DKIM on their own don't protect the From address your customers see. DMARC is the part that does, because it requires the passing check to match the visible domain.

What the DMARC policy actually does

The p= value in your DMARC record is the instruction to inboxes:

• p=none: deliver failing mail as normal, but send me reports. This is monitoring only. It does not stop spoofing.
• p=quarantine: treat failing mail as suspicious, usually by putting it in spam.
• p=reject: refuse failing mail outright. This is the strongest protection.

The rua= tag gives an address for aggregate reports. Large inbox providers send these as daily XML summaries of who sent mail using your domain and whether it passed. They are hard to read raw, so most people forward them to a free or paid DMARC report tool.

How to check your own domain

Your DMARC record is a TXT record at _dmarc on your domain. On a Mac or Linux terminal, run:

dig TXT _dmarc.example.com +short

Replace example.com with your store's domain. A result looks something like this:

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

No result means there is no DMARC record, so nothing tells inboxes to doubt a fake. A result with p=none means you are watching but not yet blocking. You can check SPF the same way with dig TXT example.com +short and look for the line starting with v=spf1. On Windows, nslookup -type=TXT _dmarc.example.com does the same job, or the free scan checks it for you.

A safe way to turn protection on

The risk with DMARC is blocking your own legitimate email. Stores usually send from several services at once, so move in stages:

1. List everything that sends email as your domain: your mailbox provider (for example Google Workspace), your store platform's order and shipping notifications (for example Shopify), your marketing tool (for example Klaviyo), and any help desk or review app.
2. Set up domain authentication in each one. Most of these services give you DNS records to add, usually DKIM keys and sometimes an SPF include.
3. Publish DMARC at p=none with an rua address, and read the reports for a few weeks.
4. When every real sender shows as passing, move to p=quarantine. You can phase it in with the pct= tag, which applies the policy to a share of failing mail.
5. After another quiet period, move to p=reject.

Some providers, including Gmail and Yahoo, now expect bulk senders to have a DMARC record. A p=none record can satisfy that requirement, but it still does not stop anyone from spoofing you. Only quarantine or reject does.

If someone has also registered a domain that looks like yours, DMARC can't help with that, because they control that domain. See what to do about a lookalike domain.