Why your store's email goes to spam.

Start here: check your domain's current status

Before working out what to change, establish what your domain is doing right now. A quick test reports which of the three records are passing, which are failing, and whether there is a problem to solve at all. It is worth having that answer in front of you before reading the rest of this page, because it turns everything below from background reading into a specific list of things to fix.

One thing to get right before you start. Your domain almost certainly sends mail from more than one place. Your store platform sends order confirmations, shipping notices, and password resets. Your regular mailbox provider sends everything you write yourself. Each of those is a separate sending path with its own authentication records, and each has to be tested separately. It is common for the mailbox to be configured correctly while the store platform was never authorized at all, which produces exactly the pattern of your own messages arriving fine while order confirmations go to spam.

1. Open a testing service such as Mail Tester, which gives you a single-use address to send to. You will use a fresh address for each path you test.
2. Test the store platform first. Place a test order on your own store using the address Mail Tester gave you as the customer email, so the order confirmation is sent to it by the platform the same way it is sent to your customers. Do not forward a confirmation from your inbox, you want to test each system that sends mail as your domain.
3. Reload the page. You get back a report saying whether SPF, DKIM, and DMARC passed for that message, and what is missing.
4. Repeat for your regular service with a new address, writing to it from the account you use day to day.
5. Repeat for any marketing or help desk tool by sending a test from inside that tool.

Two things about reading the reports. The overall score covers content and spam heuristics as well as authentication, so look at the authentication lines specifically rather than reacting to the number. And Mail Tester allows a small number of free tests per day, enough for the store and your mailbox, so spread any further tests over more than one day. Results from a free test stay viewable for a week by anyone holding that test address, so use routine messages rather than anything you would not want read.

What your results mean

• Every path passes. Authentication is in order, and whatever is going wrong is probably something else. Check the non-authentication side of deliverability, which is your content, your list, and your complaint rate, and make sure you tested every service that sends as your domain, which the section on senders below helps you inventory.
• Some paths pass and others fail. This is the most common result, and it tells you something precise: your domain's records exist but do not cover the failing sender. Usually that sender is the store platform or a marketing tool that was connected after the mailbox was set up. The fix is to authorize that specific service, which the rest of this page walks through.
• Everything fails, or comes back as none. The records are missing outright. That is the most straightforward case to fix, and the rest of this page explains what each record does, how to see exactly what your domain publishes, and how to put them in place in an order that will not block your own mail along the way.

The rest of this guide will teach you what you need to know to understand these records, how they relate to the email your store sends, and how to fix each one.

Why receiving servers distrust your mail

Email was designed without any way to verify who sent a message. Anyone, anywhere, can put your store's address in the From line, and the message will still be delivered somewhere. That single weakness is the reason spam and phishing work at all, and it is the problem the last twenty years of email standards have been trying to patch.

The patch is verification through DNS. Your domain publishes a small set of public records that answer one question for any server receiving your mail: does the owner of this domain vouch for the service that sent this message? Those records are the only way a receiving server can tell your genuine order confirmation from a forgery wearing your name.

This is why the absence of an answer counts against you. Spam filtering is not a single yes or no decision. Every arriving message is scored against dozens of signals, and the verdict is the total of them. Authentication carries real weight in that total, for a straightforward reason: genuinely forged mail almost never passes these checks, because an attacker cannot publish records on a domain they do not control. So a message that cannot be verified matches the profile of exactly the mail filters exist to catch. The receiving server is not accusing you of anything. It is observing that your message is indistinguishable from a forgery, and scoring it accordingly.

Two things sharpen this for a store specifically. First, the kinds of message you send, order confirmations, shipping notices, payment problems, and password resets, are the favorite disguises of phishing, so receiving servers apply more scrutiny to transactional-looking mail that cannot be verified, not less. Second, authentication is the identity that sending reputation attaches to. A domain that authenticates builds a record with each mailbox provider over time and gets the benefit of it. A domain that does not is effectively anonymous on every send, so a good sending history never accumulates in the first place and cannot come to your rescue.

This matters more for a store than for most senders, because the mail your store sends is the mail a customer most needs to receive. An order confirmation that lands in spam becomes a support ticket, or a chargeback from a customer who believes the order never went through. A password reset in a spam folder is a customer who cannot log in and does not come back. Shipping notifications, refund confirmations, and abandoned cart recovery are all in the same category. None of them are optional, and none of them get read from a spam folder.

Correct records on their own do not guarantee that your email reaches the destination inbox. Receiving servers also weigh your sending reputation, how often recipients mark your mail as spam, whether they open and reply to it, and the content of the message itself. What correct records do is remove the single biggest reason for mail to be filtered, and the largest mailbox providers keep raising the bar on authentication rather than lowering it. Get these records right first. Nothing else you do about deliverability works until they are.

SPF, DKIM, and DMARC in plain language

Three records do the work, and each does a different job. SPF and DKIM are two separate ways of proving a sender was authorized, and each covers a case the other misses. DMARC ties those proofs to the address your customer actually sees and tells receiving servers what to do when the proof fails. That is why you need all three.

SPF: the list of who is allowed to send

SPF is a single TXT record on your domain listing the mail services authorized to send as you. It reads as a list of includes, one per service, ending in a catch-all instruction. A typical record looks like v=spf1 include:_spf.example-provider.com include:example-marketing.com ~all.

Two details about SPF surprise people. First, it checks the hidden envelope address a message was sent with, not the From address your customer sees, which means a message can pass SPF while still appearing to come from somewhere else entirely. Second, SPF cannot vouch for your domain once a message has been forwarded automatically. This is not someone opening your message and clicking Forward, which creates a new message from them and is checked against their own domain. It is a rule or alias on a mail server that relays your message onward unchanged, with your domain still on the From line: a customer's work address that forwards everything to their personal account, an old address that forwards to a new one, or a group alias that delivers to several people. The forwarding server sends your message on from its own address, and whatever it does with the envelope, SPF can no longer prove the message is yours. If it leaves your domain on the envelope, the final receiver sees a server you never authorized and fails the check. If it rewrites the envelope to its own domain, as many providers now do, SPF passes for the forwarder rather than for you, and the From line your customer sees is still your domain, which is the domain that has to match. Both of these details are the reason DKIM exists.

DKIM: a signature the receiver can verify

DKIM has your mail provider add a cryptographic signature to every message it sends for you. Your domain publishes the matching public key in DNS, so any receiving server can check the signature and confirm the message genuinely came from an authorized sender and was not altered along the way. Because the signature travels with the message, DKIM survives forwarding where SPF does not.

DKIM records live at a subdomain built from a selector, in the form selector._domainkey.yourstore.com. The selector is chosen by your mail provider, which matters when you go looking for the record, because you cannot find it without knowing the name.

DMARC: the policy that ties the other two together

DMARC is a TXT record at _dmarc.yourstore.com that does two things. It tells receiving servers what you want done with mail claiming to be from you that fails the checks, and it asks for reports on who is sending as your domain.

It also adds the concept that makes the other two records meaningful, called alignment. DMARC passes when SPF or DKIM passes and the domain that passed matches the domain your customer sees in the From line. This is why a message can pass SPF and still fail DMARC: the sending service authenticated its own domain rather than yours. Alignment is what closes the gap between "some server was allowed to send this" and "your store was allowed to send this."

Finding the specific fault

The test at the top of this page tells you which record is failing. These two methods tell you why, which is what you need before you can fix anything. All three records are public, so you can inspect your own domain exactly the way a receiving mail server does. Neither method requires logging into your DNS or installing anything.

Reading the verdict in a message you have already sent

This tests the real path your mail actually takes, and it works with a message you have already sent rather than a special test.

1. Send a message from your store's address to a mailbox you control somewhere else, ideally at one of the large consumer providers, since that is where your customers are.
2. Open the message there and find the option to view the raw message. Clients name it differently, usually something along the lines of "show original," "view source," or "view message details."
3. Look near the top for a header called Authentication-Results. It contains the three verdicts in plain text, reading something like spf=pass dkim=pass dmarc=pass.

Any fail, softfail, none, or permerror tells you which of the three to go looking at.

Raw headers are dense, and there is no reason to read them by hand. Copy the whole header block and paste it into a header analyzer, which lays the delivery path and the authentication results out as a readable table. Google's Admin Toolbox Messageheader and MXToolbox's Email Header Analyzer both do this free and without an account.

While you have the raw message open, there is one more thing worth grabbing. Find the DKIM-Signature header and note the value after s=. That is your DKIM selector, and it is the piece you need to look the key up in the next section, since a DKIM record cannot be found without it.

Looking your records up directly

A graded test gives you the verdict. Looking the records up tells you what is actually published, which is what you need in order to fix anything. All three of these run in a browser, free and without an account:

• dmarcian's Domain Checker takes your domain and inspects all three records at once, then explains what is wrong in plain language rather than just printing the record. It is the best starting point when you want the faults named rather than the raw records.
• MXToolbox SuperTool runs individual lookups, entered as spf:yourstore.com, dmarc:yourstore.com, or mx:yourstore.com. It flags several of the specific faults in the next section by name, including the lookup limit that quietly breaks a long SPF record.
• Google's Admin Toolbox Dig is a plain DNS lookup in a browser. It shows the raw records with no interpretation, which is what you want when you need to see exactly what is published rather than a tool's reading of it.

Those are independent services with no connection to us, listed because they are free and require no account. Tools come and go, so if one of them has changed by the time you read this, any DNS or DMARC lookup tool does the same job. What matters is which records you ask for, not which site you ask.

If you would rather run the lookups yourself, these commands work on macOS and most Linux systems and have been stable for decades:

• dig TXT yourstore.com lists the TXT records on your domain. Your SPF record is the one beginning v=spf1.
• dig TXT _dmarc.yourstore.com returns your DMARC record, which begins v=DMARC1.
• dig TXT selector._domainkey.yourstore.com returns a DKIM key, with the selector you found in the message header substituted in.
• dig MX yourstore.com shows where your incoming mail is delivered, which is worth confirming at the same time.

On Windows, nslookup -type=TXT yourstore.com does the same job. In every case, an empty result means the record does not exist, which is itself the answer.

What a healthy setup looks like

• Exactly one SPF record, beginning v=spf1, containing an entry for every service that sends as you, and ending in ~all or -all.
• A DKIM key published at your provider's selector, with DKIM signing switched on in that provider's settings, not just present in DNS.
• A DMARC record at _dmarc, with a policy value and a reporting address so you can see who is sending as you.

Reading what you found, and what is broken

Most domains that have a deliverability problem have one of a short list of specific faults. These are worth checking by name.

• No SPF record at all. Nothing vouches for any of your senders. This is common on domains that were set up for a website first and had email added later.
• Two or more SPF records. This is not twice the protection, it is a hard failure. The standard permits exactly one, and a domain publishing two fails the check outright. It usually happens when a new service tells you to "add this record" and the record is added alongside the existing one instead of merged into it. Fix it by combining every entry into a single record.
• Too many lookups in SPF. The record is limited to ten entries that require a further DNS lookup, and each include: for a mail service consumes at least one. Exceed the limit and the whole record errors out, so a domain that stacked up five or six sending tools over the years can fail without a single visible change having been made. Removing services you no longer use is usually the fastest fix.
• An SPF record ending in +all. This authorizes the entire internet to send as your domain, which is the same as publishing nothing while looking like you did something.
• No DKIM. Frequently this is half-finished: the DNS record was published but signing was never enabled in the provider's settings, or the reverse. The header check is what catches this, because DNS looks correct either way.
• No DMARC record. With no DMARC there is no alignment requirement, no policy, and no reports, so you have no way of knowing who is sending as your domain or how your mail is being treated.
• A strict DMARC policy your senders cannot satisfy. The most damaging state on this list, and the reason for the warning further down. A policy of p=reject published before every legitimate sender is authorized instructs the world to throw away your own order confirmations.
• Records that disappeared during a DNS change. A nameserver move that did not carry the TXT records across is a very common cause of mail that authenticated perfectly last month and does not today. If your deliverability changed around the same time as a domain or hosting move, start here. Our guide to DNS and nameservers covers why that happens and how to avoid it.

You send from more places than you think

This is the part that catches stores specifically. A typical online store sends mail through several unrelated services, each of which needs authorizing separately:

• The store platform itself, for order confirmations, shipping notices, and password resets.
• An email marketing or newsletter tool.
• A help desk or shared support inbox.
• Review request and loyalty tools.
• Invoicing or accounting software.
• Your own day-to-day mailbox, which is often a different provider from all of the above.

Every one of those is a separate sender as far as a receiving server is concerned. Adding a new tool without adding it to SPF and enabling DKIM for it is the single most common way a domain that was delivering fine starts landing in spam, and because the change is gradual and only affects the mail from that one tool, it rarely gets connected to the thing that caused it.

The practical habit worth building: when you connect any new service that will send email as your domain, treat publishing its authentication records as part of setting it up, not as a separate task for later.

Fixing it without blocking your own mail

The order here matters, because DMARC is the one record that can actively destroy your own mail if it is published before the groundwork is done.

1. Inventory every service that sends as your domain. Work through the list above and write down what you actually use. Include anything you set up once and forgot.
2. Get the current authentication instructions from each provider. Every one of them documents its own SPF entry and DKIM setup. Use their current documentation rather than an older article, since the values do change.
3. Consolidate into a single SPF record. One record, every service represented once, watching the ten-lookup limit as you go. Remove entries for services you have stopped using.
4. Enable DKIM everywhere it is offered. Publish the record each provider gives you, then confirm signing is actually switched on in that provider's settings.
5. Publish DMARC in monitoring mode first, with a policy of p=none and a reporting address. In this mode nothing is blocked and nothing changes for your customers. You are only asking for visibility.
6. Read the reports until you can account for every sender. They arrive as XML attachments that are close to unreadable by hand, so point the reporting address at a service that turns them into readable summaries rather than trying to open them yourself. Postmark's DMARC Digests is free for weekly summaries on a single domain, which is all one store needs, and several other providers offer a comparable free tier. What you are looking for is any legitimate sender still failing, which means it is not yet authorized correctly.
7. Tighten the policy in stages. Once the reports are clean, move from p=none to p=quarantine, and only later to p=reject. Each step is reversible, and moving in stages means a sender you overlooked shows up as a problem you can fix rather than as mail your customers never received.
8. Re-test after every change, and again after any DNS, nameserver, or platform move. The header check is quick enough to make a habit of.

Common mistakes

• Publishing a strict DMARC policy too early. The most costly error available here, because it breaks the exact mail you most need delivered, silently.
• Adding a second SPF record instead of merging. Two records fail where one would have passed, and the fault is invisible unless you look at the records directly.
• Connecting a new sending tool and forgetting authentication. The mail flows immediately, so nothing looks wrong on the day. The deliverability problem arrives quietly, weeks later.
• Sending store mail from a consumer mailbox address. Using a free provider's address in the From line of mail sent through your store platform fails alignment, because the sending service is not authorized to send as that provider's domain. Store mail should come from your own domain.
• Assuming one passing test covers everything. Each sending service authenticates separately. Test each of them.
• Losing the records in a nameserver change. TXT records are the easiest thing to leave behind in a domain move, and the failure shows up days later as mail quietly going to spam.
• Treating authentication as the whole of deliverability. It is the foundation, not the finished building. Sending relevant mail to people who asked for it still matters, and no record will rescue a list that generates complaints.

---

The reassuring part of all this is that it is finite. Three records, published once, maintained whenever you add a new tool that sends on your behalf. The reason it so often goes wrong is not that it is difficult but that nothing announces the failure: mail keeps sending, no error appears, and the only symptom is customers not replying to messages they never saw.

Getting this right is part of how a store should be set up in the first place, and it is one of the checks worth running before and after any platform move, since authentication records are among the most commonly lost pieces in a domain change. If your order confirmations are landing in spam and you would rather have someone work through the records and the reports than learn DMARC properly, book a call and we will start by checking what your domain publishes today.